Que IP de orixe usa unha pasarela NAT de AWS cara a unha VPN?

Abres a consola de VPC porque un socio preguntou que rango de orixe chegará pola VPN de sitio a sitio. A páxina de pasarelas NAT mostra unha pasarela pública cunha Elastic IP asociada, e a tentación é enviar ese enderezo e seguir adiante. É a resposta correcta para a ruta de internet e a resposta equivocada para a ruta da VPN, e a diferenza está en a que pasarela apunta a táboa de rutas. Percorre a ruta antes de escribir a lista de enderezos permitidos.

Comeza na páxina de pasarelas NAT, non na lista de enderezos permitidos

A páxina de pasarelas NAT diche a subrede, o tipo e a Elastic IP, e eses tres campos abondan para comezar. O que non diche é a ruta que toma o tráfico despois. Iso vén das táboas de rutas asociadas á subrede da pasarela NAT.

Le primeiro o tipo, porque público ou privado decide se máis adiante aparecerá unha pasarela de internet na cadea. Despois le a subrede, porque alí vive a segunda ruta.

Segue as dúas traducións

Tanto as pasarelas NAT públicas como as privadas traducen a orixe IPv4 privada da carga de traballo ao enderezo IPv4 privado da propia pasarela NAT. Esa primeira tradución ocorre independentemente do tipo. A segunda tradución é a que se esquece: unha pasarela NAT pública entrega o tráfico á pasarela de internet, que asigna o enderezo á Elastic IP asociada.

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

Na ruta privada non hai ningunha pasarela de internet na cadea. Cando o tráfico sae por unha pasarela de tránsito ou unha pasarela privada virtual, a guía de pasarelas NAT documenta o enderezo privado da pasarela NAT como a orixe que recibe o lado remoto. Ese é o enderezo que o socio debe permitir, non a Elastic IP.

A ruta da VPN adoita mostrar o enderezo privado

Para unha carga de traballo en 10.20.1.0/24 que alcanza un prefixo do socio, a táboa de rutas da subrede da carga apunta á pasarela NAT, e a táboa de rutas da subrede da pasarela NAT apunta á ruta da pasarela privada. Os dous saltos importan, e só o segundo decide o que ve o socio. Se a subrede NAT non ten ningunha ruta cara á ruta da VPN, o paquete nunca chega, e iso é un fallo distinto dun enderezo de orixe equivocado.

Verifica esa segunda ruta antes de falar de enderezos. Unha ruta ausente e unha orixe informada mal parecen idénticas para un socio que simplemente non ve tráfico.

Cando unha segunda tradución cambia a resposta

AWS tamén ofrece unha asignación NAT explícita e correspondente un a un sobre unha asociación de pasarela de tránsito. Esa asignación pode traducir a orixe outra vez antes de que o servizo remoto a vexa, e non é o comportamento predeterminado que só encamiña. Como hai que configurala a propósito, trátaa como unha excepción de deseño e non como algo que herdas por accidente. Se ninguén do teu equipo lembra tela activado, supón que non está ata que lerás a asociación.

Se o teu deseño a usa, a lista de enderezos permitidos debe describir a asignación final e non o enderezo da pasarela NAT. A mesma precaución se aplica ás rutas de dispoñibilidade: cando participan varios enderezos de pasarela, o conxunto de orixes esperado é a unión, non un enderezo representativo. Anota a que tradución pertence cada enderezo, porque unha lista sen procedencia é imposible de auditar máis tarde.

A unha pasarela NAT privada non se lle pode dar servizo de internet apuntándoa a unha pasarela de internet; AWS documenta que ese tráfico se descarta. Escolle o tipo a partir da ruta completa, non da palabra VPN do requisito.

Escribe o contrato sobre o que o teu socio pode actuar

O contrato utilizable ten catro partes: a dirección desde a que se inician os fluxos, a identidade traducida que verá o socio, a ruta de volta para esa identidade e o alcance de protección que se aplica. Os fluxos da pasarela NAT inícianse desde o lado de orixe admitido, así que non é un servizo de reenvío de portos de entrada para expor unha carga de traballo privada. Dicilo en voz alta cedo evita unha revisión de deseño na que cada lado supuña que o outro iniciaba.

A tradución compra alivio do solapamento de enderezos e unha política de orixe predicible, e cóstache a identidade individual da carga de traballo nos rexistros do socio. Se a auditoría necesita atribución por carga de traballo, mantén esa identidade na capa de aplicación en lugar de tentar recuperala dun enderezo de orixe traducido.

Despois volve comprobar as dúas táboas de rutas tras calquera cambio, porque unha asociación nova ou unha subrede reasociada reescribe a resposta en silencio.