AWS Client VPN o un bastión para llegar a una VPC con peering

Un endpoint de Client VPN puede llegar a una VPC que tiene peering con su VPC asociada, y no necesita un bastión para que eso sea legítimo. La decisión que vale la pena es dónde cambia de manos el tráfico: una ruta de endpoint que aterriza en la subred de asociación y cruza la conexión de peering, o un host en la VPC con peering que termina la sesión. Ambos caminos funcionan y fallan en lugares distintos, así que la decisión es sobre propiedad y auditoría, no sobre lo que AWS permite. Así elijo entre ellos, y las cuatro entradas que hacen que el camino enrutado funcione.

Dos caminos, un endpoint, propietarios distintos

En el camino enrutado, el tráfico del cliente llega al endpoint, se traduce a la dirección de la interfaz de red de Client VPN en la subred de asociación y sale de esa subred por la conexión de peering de A a B. La VPC B no termina ninguna sesión de VPN; ve tráfico normal de la VPC A, por eso su ruta de retorno apunta a la VPC A y no al grupo de clientes.

En el camino del bastión, el cliente llega primero a un host. Un bastión en A sigue dejando que el último salto cruce la conexión de peering, así que conserva el trabajo de peering y añade una sesión. Un bastión en B también necesita un camino desde el cliente, y cuando ese camino es la misma ruta de endpoint, tiene el diseño enrutado más un salto. El bastión solo quita trabajo cuando ya existe, ya tiene aprobación y lo que hay detrás necesita una frontera de sesión y no una de red.

Cuatro entradas hacen funcionar el camino enrutado

AWS documenta este escenario en la página Client VPN how-it-works, y en la práctica se reduce a cuatro entradas que poseen dos o tres equipos. Los rangos son ilustrativos; el rango con peering debe ser único y el rango de retorno debe coincidir con su plan.

Ruta y permiso son controles separados. Una ruta de endpoint correcta sin una regla de autorización que coincida no le da nada al cliente; una regla de autorización para un destino que el endpoint no puede enrutar le da un agujero negro. Ambas deben nombrar el mismo rango.

La ruta del endpoint apunta a una subred de la propia VPC del endpoint, nunca a la conexión de peering. Las tablas de rutas de la VPC apuntan a la conexión de peering, nunca a una instancia ni a una interfaz. Copiar un valor entre ambas se guarda sin queja y no enruta nada.

Como la subred de asociación traduce el origen del cliente, B debe enrutar de vuelta a la VPC A, no al grupo de clientes. Enviar el rango de clientes por la conexión de peering parece simétrico, pasa la revisión y falla en silencio porque B nunca ve un paquete con origen de cliente.

Grupos de seguridad y el último metro de permiso

El enrutamiento mete paquetes en B; B sigue decidiendo. Para una conexión de peering activa en la misma región, un grupo de seguridad en B puede referenciar el grupo aplicado a la asociación de Client VPN, lo que mantiene la regla estrecha y sobrevive a los cambios de dirección. Donde una referencia de grupo no es viable, permita el rango de la subred de asociación de forma explícita en lugar de ampliarlo a 0.0.0.0/0, que convierte un error de enrutamiento en un tiempo de espera sin explicación.

Después revise lo que el enrutamiento nunca toca: las ACL de red de ambas subredes, la lista de permitidos o la audiencia del token de la aplicación, y el DNS. El peering no copia zonas alojadas privadas, así que el portátil puede tener una ruta que funciona hacia una dirección que no puede resolver, y una conexión de peering no añade confianza a un certificado. Apunte el endpoint a un resolutor que responda por B y luego confirme que el nombre privado y el certificado coinciden.

Cuándo el bastión es la respuesta honesta

Mantengo tres disparadores para elegir un bastión a propósito. La VPC con peering pertenece a un equipo que no añadirá una ruta de retorno para su rango o no aceptará una referencia de grupo. El acceso debe aprobarse o registrarse por sesión y la aplicación no puede cargar con eso. O el último salto debe quedarse dentro de B porque el servicio solo resuelve allí y su identidad TLS está fijada a un nombre interno.

Nada de eso es un rodeo al hecho de que el peering no es transitivo. La no transitividad limita lo que pueden hacer los recursos de B: no pueden usar A como tránsito hacia una tercera VPC con la que A tiene peering. Nunca significó que un usuario de VPN no pueda llegar a una VPC con peering directo, y un bastión construido para sortear esa mala lectura es un host que se parchea sin motivo.

El error inverso cuesta más con el tiempo: haga pasar a cada equipo por el único bastión que ya existe y luego descubra que su grupo de seguridad, su tabla de rutas y su ventana de parcheo son la dependencia de producción. Anote qué disparador sirve el host y retírelo cuando el disparador desaparezca.

Transit Gateway y varias asociaciones cambian la aritmética

Si el endpoint está conectado directamente a un Transit Gateway en lugar de a una subred, el modelo cambia: los clientes ya no se traducen a una dirección de interfaz en una subred de asociación, y las tablas de rutas de la pasarela deben llevar el rango de clientes más la conexión que lleva a la VPC con peering. Es más limpio a escala, pero el trabajo se traslada de cuatro entradas a las tablas de rutas de la pasarela.

Varias asociaciones multiplican las comprobaciones. La ruta del endpoint pertenece al endpoint, pero cada subred de asociación necesita una tabla de rutas con un siguiente salto de peering real. Una sesión puede tener éxito por una asociación mientras otra no tiene camino de retorno, así que pruebe cada una.

Orden de verificación que encuentra el fallo rápido

Ejecute estas en orden; cada paso puede pasar mientras el siguiente falla, y un tiempo de espera del cliente casi nunca dice cuál se rompió.

1. Resuelva el nombre de la aplicación desde el cliente y compruebe que la dirección está dentro del rango con peering.
2. Conéctese y lea el registro de conexiones del endpoint de la asociación que terminó la sesión.
3. En esa subred de asociación, confirme que la tabla de rutas apunta el rango con peering a una conexión de peering activa.
4. En la subred de recursos de B, confirme una entrada de retorno para el rango de la interfaz y reglas de grupo coincidentes.
5. Pruebe una operación permitida y un recurso que debe seguir inalcanzable; el segundo atrapa restos de depuración.
6. Vuelva a conectarse tras cualquier cambio de ruta split-tunnel, porque un túnel en marcha no tomará un conjunto de rutas nuevo.

Merece la pena memorizar dos síntomas. Un SYN que llega a B sin respuesta casi siempre es la ruta de retorno que falta. Una conexión que se completa y luego se reinicia suele ser el grupo, la ACL o la aplicación. Ninguno aparece en el registro del endpoint como causa, así que mantenga las cuatro entradas con un propietario junto a cada una.

Si no se cumple ninguno de los tres disparadores, termine el camino enrutado y registre esas cuatro entradas. Si se cumple uno, mantenga el bastión solo para esa frontera y deje la ruta del endpoint para servicios que no necesitan una sesión delante.