AWS Client VPN conectado, pero EC2 sigue sin responder

Mi portátil decía conectado. El cliente de AWS Client VPN mostraba su estado verde, el punto de enlace registraba una sesión y aun así no podía abrir un puerto de MongoDB en una instancia EC2 de una subred privada. Nada estaba obviamente roto: el certificado era válido, el perfil venía de la consola y el túnel transportaba tráfico. El error era mío, porque leía conectado como autorizado.

El inicio de sesión responde exactamente a una pregunta: ¿puede esta identidad establecer una sesión? Todo lo que viene después lo deciden reglas separadas que nunca ven tu certificado. Una sesión que se autentica y un paquete que llega son dos éxitos distintos, y la brecha entre ambos es donde viven la mayoría de los avisos del tipo la VPN está levantada pero el host no es accesible.

Las comprobaciones siguientes son el orden que uso ahora.

Qué demuestra realmente una sesión conectada

Durante el handshake, el punto de enlace valida el certificado del cliente contra su almacén de confianza, o redirige el navegador a tu proveedor de identidad cuando SAML está configurado. Si eso pasa, el cliente recibe una dirección del CIDR de cliente del punto de enlace y la consola muestra una conexión activa. En ningún momento de ese intercambio se pregunta si puedes llegar a 10.0.4.17 en el puerto 27017.

El permiso hacia un destino es un objeto aparte en el punto de enlace. Cada flujo se compara con las reglas de autorización, y cada una empareja un CIDR de destino con el grupo al que se concede la regla. Cuando ninguna regla cubre el destino, el punto de enlace acepta la sesión y descarta el tráfico. No hay banner, ni bucle de reconexión, ni nada en la interfaz del cliente que diga denegado.

Compare la regla de autorización con el recurso, no con la VPC

Enumere las reglas y póngalas junto a la dirección que la instancia tiene de verdad:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

La salida muestra un CIDR de destino y un id de grupo por regla. Dentro se esconden dos fallos. La regla puede autorizar 10.0.0.0/16 mientras la instancia está en una VPC emparejada en 10.1.0.0/16; la ruta de peering existe, pero nadie escribió una regla de autorización para el segundo rango. O la regla apunta a un grupo del directorio al que el usuario pertenece en el directorio, pero no en el grupo que evalúa el punto de enlace.

Escriba la regla más estrecha que cubra el destino, y añada una segunda solo cuando de verdad haga falta un segundo CIDR. Una regla amplia 0.0.0.0/0 de un inicio rápido funciona, y por eso sobrevive hasta producción y esconde el modelo.

Dos tablas de rutas deciden si el paquete se mueve

Una ruta del punto de enlace asigna un CIDR de destino a una de las subredes con las que está asociado el punto de enlace. Eso es medio camino. La tabla de rutas propia de la subred todavía tiene que saber cómo reenviar el paquete, y eso importa en el momento en que el destino está detrás de una conexión de peering, una pasarela de tránsito o un rango local accesible por un túnel de sitio a sitio.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Busque una ruta cuyo destino coincida con el CIDR del recurso y cuyo objetivo sea una subred asociada. Si falta la ruta, añádala. Si está presente y el host sigue mudo, la brecha está del lado de la VPC, así que compare con la tabla de rutas de la subred de asociación.

Un ajuste del lado del cliente rompe el enrutamiento sin romper el túnel: un perfil que contiene route-nopull. La directiva le dice a un cliente basado en OpenVPN que ignore las rutas que empuja el servidor, así que la interfaz sube solo con la dirección propia del punto de enlace y el destino simplemente no tiene ruta. Compruebe con ip route show en Linux o netstat -rn en macOS si existe una ruta por la interfaz tun. Si no existe, quite route-nopull del perfil exportado y vuelva a conectarse para que se apliquen las rutas empujadas.

Los grupos de seguridad no ven la dirección de tu cliente

Esta es la parte que tuve mal durante una tarde entera. Para un punto de enlace IPv4 asociado a una subred, el servicio traduce la dirección de origen del cliente a la dirección de la interfaz de red del punto de enlace en esa subred. El paquete que llega a la instancia no lleva la dirección que mostraba tu cliente, así que una regla de grupo de seguridad que permita el conjunto de clientes, digamos 172.16.0.0/22, no coincide con nada.

Permita el puerto desde el grupo de seguridad del punto de enlace, que va unido a la interfaz de la asociación, y no desde el CIDR de cliente. Referenciar el grupo es más duradero que codificar una dirección en duro, porque la dirección de la interfaz no es tuya para controlarla. Las ACL de red no guardan estado, así que donde existan entradas personalizadas, tanto la dirección de entrada como la de salida deben permitir el flujo.

Conéctate también a la dirección privada de la instancia. Una IP pública saca el paquete de la VPC y lo vuelve a meter por otro camino con otras reglas, así que una prueba por la dirección pública no dice nada del camino privado.

Un orden de aislamiento que se detiene en el primer fallo

Recórralos en orden y deténgase donde uno falle. Cada paso descarta una capa en lugar de todas.

1. Confirme qué identidad usó la sesión y qué grupo evalúa el punto de enlace. Un certificado de un almacén de confianza no es el mismo principal que una aserción SAML del directorio.
2. Confirme que una regla de autorización cubre el CIDR del recurso para ese grupo.
3. Confirme que existe una ruta del punto de enlace y apunta a una subred asociada, y luego que la tabla de rutas de la subred puede reenviar más allá.
4. Confirme que el grupo de seguridad permite el puerto desde la interfaz del punto de enlace y no desde el conjunto de clientes.
5. Pruebe desde dentro de la VPC, con una sesión SSM en otra instancia de la misma subred, para separar un problema de aplicación de un problema del camino del cliente.

Cuando los pasos no son concluyentes, esta tabla es mi recurso:

Dos detalles de la cuenta producen síntomas que parecen fallos de permisos. Cada usuario necesita un certificado de cliente distinto; compartir uno entre dos máquinas hace que las sesiones se desplacen mutuamente, y el resultado es un bucle de reconexión en lugar de una denegación. Cuando se crea un punto de enlace nuevo, la consola muestra un nombre DNS que algunas versiones del cliente solo aceptan con el prefijo aleatorio que aparece en la página del punto de enlace, así que copie el nombre completo en lugar de reconstruirlo.

Si el quinto paso te deja atascado, saca el registro de conexiones del punto de enlace y lee las entradas de autorización antes de cambiar nada. El registro nombra el destino que se comprobó y la regla que coincidió o no, lo que reduce la pregunta de cuatro capas a una sola respuesta.