Añadir una subred local a una VPN de AWS: VGW frente a Transit Gateway

Una VPN Site-to-Site existente transporta 10.60.0.0/16, una nueva red de servicio aparece detrás de la misma puerta de enlace local como 10.70.0.0/16, y alguien pregunta si hace falta un proxy. Normalmente no: una ruta enrutada puede transportar el prefijo, pero solo si tres cosas encajan, y cuáles tres depende de la arquitectura de AWS que ya ejecuta. Una puerta de enlace privada virtual tiene un límite de tabla de rutas; un transit gateway añade un segundo. Acertar el anuncio y equivocar la tabla produce una sesión que parece sana y no entrega nada.

Publique un prefijo que la puerta de enlace pueda entregar de verdad

La puerta de enlace local necesita una ruta hacia la nueva red antes de que cualquier anuncio tenga sentido. Anunciar 10.70.0.0/16 por BGP dice a AWS dónde enviar los paquetes de ese rango; no crea la ruta de reenvío local que hace que el rango sea alcanzable en el otro extremo. Confirme que la puerta de enlace tiene una ruta para el prefijo que apunta al dispositivo que lo mantiene, y que el dispositivo está configurado para responder por esas direcciones. La política de exportación y los límites de prefijos aceptados son la siguiente restricción, porque un prefijo que la sesión filtra no llega nunca a AWS.

Mantenga los agregados y las rutas más específicas deliberados. Las rutas solapadas que llegan de dos direcciones son una decisión de diseño, no un detalle que se descubre después.

Ruta uno: el límite de la puerta de enlace privada virtual

Con una puerta de enlace privada virtual, la documentación de enrutamiento de AWS VPN describe dos modos de distribución, rutas estáticas y anuncios BGP, y ambos dependen de la tabla de rutas de subred que la aplicación usa realmente. La propagación es cómoda cuando controla todo el rango, y una ruta explícita es más fácil de razonar cuando quiere el destino junto al objetivo. En cualquier caso, la comprobación es la misma: ¿la tabla de la subred concreta de la aplicación contiene una ruta funcional hacia el objetivo de la VPN para el prefijo nuevo, y gana frente a algo más específico?

Una sesión BGP sana demuestra que el canal existe. No dice nada sobre si una tabla de subred determinada ha consumido la ruta.

Ruta dos: el transit gateway añade una tabla

Un transit gateway divide esa única pregunta en dos. La subred de la VPC tiene que enviar el destino a la conexión del transit gateway, y luego la tabla de rutas del transit gateway tiene que seleccionar la conexión de la VPN para ese mismo prefijo. Las decisiones de asociación y propagación determinan qué redes conectadas reciben la ruta, así que un prefijo puede anunciarse correctamente desde la VPN y aun así no llegar nunca a la VPC cuya tabla nunca se asoció con la tabla de rutas correcta.

El fallo habitual es una ruta que existe en una tabla y no en la otra, con cada equipo convencido de que su lado es correcto. Cuando compara las dos arquitecturas, este límite extra es toda la diferencia: más sitios donde mirar y un control más preciso de quién recibe la ruta.

La propagación de rutas tampoco concede el prefijo a cada conexión. Lo distribuye a las tablas configuradas para recibirlo.

La ruta de retorno es una decisión de política propia

El tráfico que llega es solo la mitad del intercambio. La nueva red local necesita una ruta de vuelta hacia los prefijos de origen de AWS a través de la puerta de enlace correcta, y la política de seguridad de ambos extremos tiene que permitir ese par de origen y destino. Si el túnel negocia un ámbito de protección con selectores de tráfico, el prefijo nuevo tiene que estar dentro, o el paquete se descarta antes de consultar cualquier tabla de rutas.

El solapamiento de direcciones es la otra trampa. Los rangos disjuntos y con propiedad explícita mantienen esto simple; los rangos solapados implican traducción o un rediseño, y ninguno de los dos es una variante intercambiable de la misma receta.

Pruebe con un origen en la red nueva y un destino en la subred de la aplicación, y repita en la otra dirección. Una prueba unidireccional demuestra una sola dirección.

Cuándo el proxy es de verdad el mejor límite

Un proxy se gana su sitio cuando el requisito es una interfaz de servicio estrecha, cuando la aplicación ya espera esa arquitectura o cuando no se puede hacer que la ruta de red transporte el prefijo sin una traducción que no quiere. No es la solución de reserva para una entrada de tabla de rutas que nadie comprobó.

Decida en este orden: reenvío local, anuncio, límite de tabla, política de retorno. Arregle el primero que falle y solo entonces pregunte si la ruta enrutada es siquiera la respuesta correcta.