Que IP de origem usa um gateway NAT da AWS para uma VPN?

Abre a consola VPC porque um parceiro perguntou que intervalo de origem chegará pela VPN de site para site. A página dos gateways NAT mostra um gateway público com um Elastic IP associado, e a tentação é enviar esse endereço e seguir em frente. É a resposta certa para o caminho da internet e a resposta errada para o caminho da VPN, e a diferença está em qual gateway aponta a tabela de rotas. Percorra a rota antes de escrever a lista de endereços permitidos.

Comece na página dos gateways NAT, não na lista de endereços permitidos

A página dos gateways NAT diz-lhe a sub-rede, o tipo e o Elastic IP, e estes três campos bastam para começar. O que não diz é o caminho que o tráfego segue depois. Isso vem das tabelas de rotas associadas à sub-rede do gateway NAT.

Leia primeiro o tipo, porque público ou privado decide se, mais adiante na cadeia, aparecerá um gateway de internet. Depois leia a sub-rede, porque é lá que vive a segunda rota.

Siga as duas traduções

Tanto os gateways NAT públicos como os privados traduzem a origem IPv4 privada da carga de trabalho para o endereço IPv4 privado do próprio gateway NAT. Esta primeira tradução ocorre independentemente do tipo. A segunda tradução é a que as pessoas esquecem: um gateway NAT público entrega o tráfego ao gateway de internet, que mapeia o endereço para o Elastic IP associado.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

No caminho privado não existe nenhum gateway de internet na cadeia. Quando o tráfego sai através de um gateway de trânsito ou de um gateway privado virtual, o guia dos gateways NAT documenta o endereço privado do gateway NAT como a origem que o lado remoto recebe. É esse endereço que o parceiro deve permitir, não o Elastic IP.

O caminho da VPN mostra normalmente o endereço privado

Para uma carga de trabalho em 10.20.1.0/24 que alcança um prefixo do parceiro, a tabela de rotas da sub-rede da carga aponta para o gateway NAT, e a tabela de rotas da sub-rede do gateway NAT aponta para o caminho do gateway privado. Ambos os saltos contam, e só o segundo decide o que o parceiro vê. Se a sub-rede NAT não tiver qualquer rota para o caminho da VPN, o pacote nunca chega, e isso é uma falha diferente de um endereço de origem errado.

Verifique essa segunda rota antes de falar de endereços. Uma rota em falta e uma origem mal comunicada parecem idênticas a um parceiro que simplesmente não vê tráfego.

Quando uma segunda tradução altera a resposta

A AWS também oferece um mapeamento NAT explícito e correspondente um para um numa associação de gateway de trânsito. Esse mapeamento pode traduzir a origem outra vez antes de o serviço remoto a ver, e não é o comportamento predefinido que apenas encaminha. Como tem de ser configurado deliberadamente, trate-o como uma exceção de conceção e não como algo que herda por acidente. Se ninguém da sua equipa se lembra de o ter ativado, assuma que está ausente até ter lido a associação.

Se o seu desenho o usar, a lista de endereços permitidos tem de descrever o mapeamento final e não o endereço do gateway NAT. A mesma cautela aplica-se aos caminhos de disponibilidade: quando participam vários endereços de gateway, o conjunto de origens esperado é a união, não um endereço representativo. Anote a que tradução pertence cada endereço, porque uma lista sem proveniência é impossível de auditar mais tarde.

Não se pode dar serviço de internet a um gateway NAT privado apontando-o para um gateway de internet; a AWS documenta que esse tráfego é descartado. Escolha o tipo a partir do caminho completo, não da palavra VPN no requisito.

Escreva o contrato sobre o qual o seu parceiro pode agir

O contrato utilizável tem quatro partes: a direção a partir da qual os fluxos são iniciados, a identidade traduzida que o parceiro verá, a rota de retorno para essa identidade e o âmbito de proteção que se aplica. Os fluxos do gateway NAT são iniciados do lado de origem suportado, pelo que não é um serviço de reencaminhamento de portas de entrada para expor uma carga de trabalho privada. Dizê-lo em voz alta cedo evita uma revisão de desenho em que cada lado assumia que o outro iniciava.

A tradução compra alívio da sobreposição de endereços e uma política de origem previsível, e custa-lhe a identidade individual da carga de trabalho nos registos do parceiro. Se a auditoria precisar de atribuição por carga de trabalho, mantenha essa identidade na camada de aplicação em vez de tentar recuperá-la de um endereço de origem traduzido.

Depois verifique novamente as duas tabelas de rotas após qualquer alteração, porque uma nova associação ou uma sub-rede reassociada reescreve a resposta em silêncio.