AWS Client VPN con túnel dividido: qué rutas deberías publicar
El túnel dividido es una lista de rutas, no una casilla. Decide adónde va el tráfico de internet, qué prefijos privados publicar y qué resolutor usar.
La consola ofrece un interruptor de túnel dividido, así que la decisión parece una casilla de verificación. No lo es. Lo que realmente llega al cliente es el conjunto de rutas publicadas del punto final, y esa lista decide qué prefijos privados usan el túnel, si el tráfico general de internet se queda local o sale por AWS, y con qué resolutor puede hablar todavía el cliente. Tres preguntas resuelven el diseño, y cada una puede responderse mal mientras la conexión sigue funcionando.
Un indicador de túnel dividido no es una lista de destinos
AWS describe el túnel dividido como la adición de rutas del punto final a la tabla de rutas del cliente al establecer la conexión. Una ruta para la VPC privada limita el túnel a ese destino; todo lo demás sigue el camino ordinario del cliente. Una ruta predeterminada es una instrucción distinta con un efecto distinto, por eso la documentación del túnel dividido advierte contra publicar 0.0.0.0/0 en un punto final configurado para este modo: suele romper la conectividad en lugar de ampliarla. La tabla de rutas del punto final es la política, y la tabla de rutas del cliente es el resultado que puedes inspeccionar.
Lee la tabla de rutas del punto final y las rutas instaladas del cliente juntas. La etiqueta describe una intención; las rutas describen qué ocurre.
Primera decisión: ¿debe quedarse local el tráfico general de internet?
Si la navegación debe usar la conexión propia del usuario, publica solo los destinos privados que necesita el trabajo y detente ahí. No añadas una ruta de internet porque un tutorial de túnel completo incluyera una, y no asumas que la ruta extra mejora la seguridad. Cambia la ruta, no añade una política y normalmente cuesta una latencia que no presupuestaste.
Si el tráfico de internet debe salir por AWS, construye la arquitectura de acceso a internet documentada: ruta del punto final, reglas de autorización, el camino de la subred asociada, política de seguridad y una salida superior que funcione. Una ruta predeterminada por sí sola no aporta nada de eso.
Segunda decisión: ¿qué prefijos privados y autorizados por quién?
Publica el conjunto más pequeño de destinos que sirve a la carga real, y comprueba que cada subred asociada puede enrutar hacia ellos. El objetivo de ruta del punto final y el enrutamiento VPC de la subred son capas distintas, y una ruta que existe en una no es prueba de la otra. La autorización es otra cosa aparte: un destino puede ser alcanzable y aun así denegarse porque el grupo del cliente no tiene una regla que lo permita.
Probar una sola sesión correcta demuestra un solo camino. Comprueba cada subred asociada, porque una asociación de subred añadida más tarde es exactamente donde suele vivir la ruta que falta.
Cuando un destino debe ser alcanzable por nombre, ten en cuenta que la siguiente pregunta es la resolución de nombres, no la de la ruta.
Tercera decisión: ¿qué resolutor sigue al túnel?
Un cliente puede recibir un servidor DNS solo accesible a través de la VPN, y ese resolutor solo funciona si su dirección está dentro de una ruta autorizada. Verifica ambas mitades: la dirección del resolutor sigue una ruta publicada y el servidor responde a los nombres que pide la aplicación. Una petición que tiene éxito por dirección mientras falla por nombre de host apunta al nombrado, no al enrutamiento, y depurar el túnel en ese caso desperdicia la tarde.
Los nombres públicos deberían resolverse como antes de la conexión, otra razón para ser precisos sobre lo que publicas.
Cambia el conjunto de rutas y luego verifica ambos mundos
AWS documenta que cambiar las rutas en un punto final de túnel dividido restablece las conexiones de los clientes. Planifica el cambio teniéndolo en cuenta: aplícalo, vuelve a conectar con el cliente compatible y lee de nuevo las rutas instaladas en lugar de confiar en el estado aplicado antes de la edición. Un estado aplicado obsoleto es la razón más común de que un cambio correcto parezca roto.
Acepta el diseño solo cuando un recurso privado y un destino público se comporten como se pretende, por nombre y por dirección, en las familias de direcciones que realmente admites. Un túnel que autentica no es lo mismo que un túnel que divide correctamente.
Escribe la lista de rutas en el runbook junto al razonamiento, para que la siguiente persona distinga una exclusión intencionada de una olvidada.