¿Qué IP de origen usa una puerta de enlace NAT de AWS hacia una VPN?

Abre la consola de VPC porque un socio preguntó qué rango de origen llegará por la VPN de sitio a sitio. La página de puertas de enlace NAT muestra una puerta pública con una Elastic IP asociada, y la tentación es enviar esa dirección y seguir adelante. Es la respuesta correcta para la ruta de internet y la respuesta equivocada para la ruta de la VPN, y la diferencia está en a qué puerta apunta la tabla de rutas. Recorra la ruta antes de escribir la lista de direcciones permitidas.

Empiece en la página de puertas de enlace NAT, no en la lista de permitidas

La página de puertas de enlace NAT le dice la subred, el tipo y la Elastic IP, y esos tres campos bastan para empezar. Lo que no le dice es la ruta que toma el tráfico después. Eso viene de las tablas de rutas asociadas a la subred de la puerta de enlace NAT.

Lea primero el tipo, porque público o privado decide si más adelante aparecerá una puerta de enlace de internet en la cadena. Después lea la subred, porque ahí vive la segunda ruta.

Siga las dos traducciones

Tanto las puertas de enlace NAT públicas como las privadas traducen el origen IPv4 privado de la carga de trabajo a la dirección IPv4 privada propia de la puerta de enlace NAT. Esa primera traducción ocurre con independencia del tipo. La segunda traducción es la que se olvida: una puerta de enlace NAT pública entrega el tráfico a la puerta de enlace de internet, que asigna la dirección a la 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

En la ruta privada no hay ninguna puerta de enlace de internet en la cadena. Cuando el tráfico sale por una puerta de enlace de tránsito o una puerta de enlace privada virtual, la guía de puertas de enlace NAT documenta la dirección privada de la puerta de enlace NAT como el origen que recibe el lado remoto. Esa es la dirección que el socio debe permitir, no la Elastic IP.

La ruta de la VPN suele mostrar la dirección privada

Para una carga de trabajo en 10.20.1.0/24 que alcanza un prefijo del socio, la tabla de rutas de la subred de la carga apunta a la puerta de enlace NAT, y la tabla de rutas de la subred de la puerta de enlace NAT apunta a la ruta de la puerta de enlace privada. Ambos saltos importan, y solo el segundo decide qué ve el socio. Si la subred NAT no tiene ninguna ruta hacia la ruta de la VPN, el paquete nunca llega, y eso es un fallo distinto de una dirección de origen equivocada.

Verifique esa segunda ruta antes de hablar de direcciones. Una ruta ausente y un origen informado erróneamente se ven idénticos para un socio que simplemente no ve tráfico.

Cuando una segunda traducción cambia la respuesta

AWS también ofrece una asignación NAT explícita y correspondiente uno a uno sobre una asociación de puerta de enlace de tránsito. Esa asignación puede traducir el origen otra vez antes de que el servicio remoto lo vea, y no es el comportamiento predeterminado que solo enruta. Como hay que configurarla a propósito, trátela como una excepción de diseño y no como algo que hereda por accidente. Si nadie de su equipo recuerda haberla activado, suponga que no está hasta que haya leído la asociación.

Si su diseño la usa, la lista de permitidas debe describir la asignación final y no la dirección de la puerta de enlace NAT. La misma precaución se aplica a las rutas de disponibilidad: cuando participan varias direcciones de puerta de enlace, el conjunto de orígenes esperado es la unión, no una dirección representativa. Anote a qué traducción pertenece cada dirección, porque una lista sin procedencia es imposible de auditar más tarde.

A una puerta de enlace NAT privada no se le puede dar servicio de internet apuntándola a una puerta de enlace de internet; AWS documenta que ese tráfico se descarta. Elija el tipo a partir de la ruta completa, no de la palabra VPN del requisito.

Escriba el contrato sobre el que su socio puede actuar

El contrato utilizable tiene cuatro partes: la dirección desde la que se inician los flujos, la identidad traducida que verá el socio, la ruta de retorno para esa identidad y el alcance de protección que se aplica. Los flujos de la puerta de enlace NAT se inician desde el lado de origen admitido, así que no es un servicio de reenvío de puertos de entrada para exponer una carga de trabajo privada. Decirlo en voz alta pronto evita una revisión de diseño en la que cada lado suponía que el otro iniciaba.

La traducción compra alivio del solapamiento de direcciones y una política de origen predecible, y le cuesta la identidad individual de la carga de trabajo en los registros del socio. Si la auditoría necesita atribución por carga de trabajo, mantenga esa identidad en la capa de aplicación en lugar de intentar recuperarla de una dirección de origen traducida.

Después vuelva a comprobar ambas tablas de rutas tras cualquier cambio, porque una asociación nueva o una subred reasociada reescribe la respuesta en silencio.