AWS Site-to-Site VPN hacia NAT Gateway: VGW frente a Transit Gateway

Todos dibujan el mismo diagrama la primera vez: VPN hacia la VPC, NAT gateway hacia internet, listo. Pero AWS no admite ese camino cuando la VPN termina en una virtual private gateway, y el fallo es tan silencioso que los equipos lo reconstruyen más de una vez. El diseño que funciona necesita una transit gateway, lo que cambia la pasarela y las tablas de rutas en ambos lados. Compare las dos formas antes de dibujar nada.

La topología que parece obvia y no está admitida

La documentación de NAT gateway de AWS traza una línea que sorprende a quien solo ha construido diseños de una sola VPC: el tráfico de una conexión Site-to-Site VPN no se puede enrutar a una NAT gateway a través de una virtual private gateway. El tipo de pasarela donde termina la VPN decide si existe algún camino de traducción. El error sobrevive porque el estado del túnel es UP y una instancia EC2 de la misma subred llega a internet sin problema. Ninguna de las dos observaciones prueba la dirección averiada.

En la práctica el paquete llega con una dirección de origen de la red local y no encuentra ningún siguiente salto admitido que lo traduzca. Según las tablas, se descarta en el límite de salida y, como el túnel sigue UP mientras una instancia de la misma subred llega a internet, el fallo se reporta como un problema de firewall local.

Virtual private gateway frente a transit gateway

Una virtual private gateway pertenece a una sola VPC. Termina la VPN, instala rutas en las tablas de esa VPC y se detiene ahí. No tiene modelo de adjunto, así que no puede entregar tráfico a otra VPC ni a un segmento de salida compartido. Ese alcance de una sola VPC es toda la limitación, y ninguna ruta que añada dentro de la VPC lo cambia.

Una transit gateway es un concentrador regional donde la VPN, cada VPC en spoke y una VPC de servicios compartidos aparecen como adjuntos. Tiene sus propias tablas de rutas, que eligen qué adjunto recibe un prefijo dado.

Ese concentrador es lo que hace posible la salida centralizada. La VPN aterriza como un adjunto, la VPC de salida como otro, y una tabla de rutas de transit gateway envía los prefijos hacia internet del primero al segundo. Con una virtual private gateway no hay un segundo adjunto al que enviar nada, por eso el diseño no se puede parchear después.

El camino de salida admitido, salto a salto

El diseño de referencia tiene cinco saltos y cada flecha es una decisión de enrutamiento que debe configurar. El tráfico sale de la red local hacia el adjunto Site-to-Site VPN, la tabla de transit gateway lo reenvía al adjunto de la VPC de salida, donde la tabla de subred lo manda a una NAT gateway pública. La NAT gateway traduce el origen y la internet gateway saca el paquete.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Dos detalles deciden si funcionan los últimos saltos. La NAT gateway debe ser pública, con una elastic IP y una ruta a una internet gateway, porque una NAT gateway privada traduce entre redes y nunca se convierte en salida a internet.

Planifique una NAT gateway por Availability Zone que quiera atender, con cada tabla de subred apuntando a la local. Mantenga la tabla de transit gateway y las tablas de la VPC como objetos separados en sus notas, porque una elige un adjunto y la otra un recurso dentro de la VPC. Una ruta por defecto solo en una de las dos deja medio camino indefinido y produce los fallos parciales más difíciles de atribuir.

El camino de vuelta es donde fallan estos diseños

Una NAT gateway es stateful para los flujos que ya ha visto, así que las respuestas de una conexión saliente vuelven sin una regla de entrada nueva. Esa propiedad no publica un servicio local en internet, y tratarla como si lo hiciera es cómo un equipo pierde un día depurando una conexión que nunca se iba a establecer. Para el tráfico originado por el cliente deben coincidir cuatro rutas: la política local, la tabla de transit gateway, la tabla de subred de salida y la tabla de subred de NAT. Si falla la última, la petición sale del edificio mientras la respuesta muere dentro de AWS.

Valide con un cliente real detrás de la VPN y mire qué dirección de origen pública presenta. Si es la elastic IP de la NAT gateway, hay traducción; si es otra cosa, está midiendo otra salida.

La versión asimétrica de este fallo conviene reconocerla pronto. Cuando la tabla de subred NAT de una Availability Zone tiene la ruta de vuelta al prefijo del cliente y otra no, las conexiones nuevas funcionan o fallan según la zona donde cae el flujo, y el patrón se malinterpreta como internet inestable. Compare las tablas de subred de cada zona que atiende en lugar de arreglar la que abrió el ticket, porque la ruta que falta es todo el fallo y al otro lado no hay que cambiar nada.

Cuándo un proxy explícito es el mejor diseño

Un proxy HTTP en una instancia de la VPC de salida es una alternativa legítima y a menudo más barata. Los clientes se configuran para usarlo, el proxy abre su propia conexión hacia fuera y el camino de vuelta es su problema en vez de un rompecabezas de enrutamiento simétrico. Para pocas aplicaciones eso elimina la mayor parte del trabajo de transit gateway. También da registros por usuario que una NAT gateway no puede producir.

No es transparente, sin embargo. Todo lo que ignora la configuración del proxy y cada protocolo que no sea HTTP no seguirán ese camino.

La elección depende de qué hablan realmente sus aplicaciones y cuánta identidad necesita en los registros. Donde hablan HTTP, el proxy se gana su lugar; donde necesita salida general para protocolos arbitrarios, el diseño con transit gateway es el que AWS admite. Decidirlo por adelantado es más barato que descubrirlo después de construir las tablas.