NAT IPv4 para IPv6 na AWS

Question

A AWS oferece suporte à conexão com serviços externos somente IPv4 a partir de um nó somente IPv6 usando NAT64. Existe um equivalente para o inverso?

Para fins de contexto, tenho um cluster EKS, que atualmente é somente IPv4, todos em sub-redes privadas. A comunicação com qualquer IP externo é feita por meio de um gateway NAT (normalmente para webhooks ou solicitações de saída semelhantes). Agora, alguns serviços externos estão migrando para somente IPv6. Existe uma maneira de conectar-se a eles sem migrar todo o cluster para IPv6? Como o EKS não suporta redes dual-stack, a migração pode ser um projeto bastante grande e arriscado.

Answer 1

Não, o destino IPv4 de origem IPv6 não é tão fácil. Comparado a seguir o outro caminho, ou IPv6 nativo.

DNS64 + NAT64, um mecanismo de transição usado em redes somente IPv6 para conexão com v4, é simples. Um pequeno prefixo v6 pode conter todo o espaço de endereço v4. O Fancy DNS gera registros AAAA neste prefixo quando o resultado possui apenas um registro A. E o NAT de pilha dupla tem uma conversão simples de 1 para 1 sem estado, que é rápida e não precisa de configuração.

Contraste com ir para o outro lado. Digamos que o endereço do serviço remoto seja 2001:db8:114:6614:240e:6d9d:8a1d:59d3 Todo o espaço de endereço IPv4 de 32 bits pode conter apenas os dois últimos grupos de dígitos, a 8a1d:59d3parte. Portanto, truques sofisticados de DNS e aplicativos não modificados não funcionarão. Teoricamente, um proxy de pilha dupla poderia encerrar as conexões v4 e fazer com que as conexões v6 fossem encerradas. Mas como você conseguirá passar os endereços v6 e analisar o tráfego do aplicativo em busca de nomes em DNS ou TLS? E como manter os fluxos, NAT com estado?

No entanto, o Kubernetes tem suas próprias ideias sobre redes e o EKS não é exceção. Embora não seja apenas um NAT64,EKS possui designs de pilha dupla.v6 atribuído a pods, mas também um host apenas v4 que recebe NAT algumas vezes no caso de v4 para a Internet.

Observe como é simples a v6 no aplicativo para a v6 na Internet, saindo do gateway de saída da Internet sem NAT. Obter essa conectividade com recursos externos da v6 é o motivo para sua organização fazer isso. Além de eliminar preocupações sobre o dimensionamento de sub-redes para o número de pods.

Implementar isso na internet moderna é um projeto, sim. A primeira coisa emuma lista de verificação para IPv6 no EKSé que o cluster deve ser criado com v6.

Você pode fazer este projeto. Crie um segundo cluster com este novo design. Inicie novos aplicativos nele e migre outros quando houver oportunidade de manutenção. Tenha um plano de reversão caso haja algum problema, para voltar a ser como era antes. Na pior das hipóteses, o cluster antigo poderia ser reconstruído como estava. Afinal, isso é infraestrutura como código.

Answer 2

A opção está bastante escondida nos documentos, mas é possível fazer a saída IPv6 de um cluster IPv4 EKS. Isto pode ser feito usando oENABLE_V6_EGRESSopção no complemento vpc-cni.

Isso configura cada pod com um endereço privado de nó no intervalo "fd00::ac:00/118". Para endpoints externos, o pod executa NAT por meio do nó.

Tecnicamente, isso não é "IPv4 para IPv6 NAT", mas atinge o objetivo de saída IPv6 em um cluster IPv4 EKS.

Etapas necessárias:

1. Atribua blocos IPv6 na VPC e nas sub-redes e ative "Atribuição automática de endereço IPv6" nas sub-redes. Adicione um gateway de Internet somente de saída e configure as tabelas de roteamento adequadamente.
2. Gire todos os nós para obter um endereço IPv6 atribuído a cada um.
3. Certifique-se de que o complemento vpc-cni esteja na versão 1.13+.
4. Atualize o complemento vpc-cni com a seguinte configuração: {"env":{"ENABLE_V6_EGRESS":"true"},"init":{"env":{"ENABLE_V6_EGRESS":"true"}}}. Faça isso somente depois de girar todos os nós, caso contrário, a implementação falhará.