AWS Client VPN conectado pero sin acceso a internet: comprobación de rutas

Está conectado al endpoint de AWS Client VPN, la subred privada responde y, aun así, cada página pública agota el tiempo de espera. Esa combinación reduce el problema a uno de tres objetos del lado gestionado: la ruta que instala el cliente, la ruta del endpoint junto con su regla de autorización, o el siguiente salto de la subred asociada. Las compruebo en ese orden porque cada fallo se ve distinto desde el cliente. Esta guía cubre el endpoint gestionado asociado a la VPC, no un servidor OpenVPN en una instancia EC2 ni una conexión de Cloud WAN o Transit Gateway.

Empiece por lo que el cliente enruta realmente

Un estado conectado demuestra la sesión TLS y la asignación de CIDR al cliente, nada más. Pregunte al sistema operativo adónde iría una dirección pública mientras el túnel está activo. En Linux, ip route get 1.1.1.1 debería nombrar la interfaz del túnel; en macOS, netstat -rn -f inet | head -5 muestra la entrada predeterminada; en Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 imprime la interfaz elegida y el siguiente salto.

Después lea el indicador de túnel dividido, porque decide si las rutas publicadas del endpoint son los únicos destinos que el cliente envía al túnel:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Con SplitTunnel en true, un destino público usa el túnel solo cuando el endpoint publica una ruta que lo cubre, así que una 0.0.0.0/0 ausente deja ese tráfico en la interfaz local. Con el valor en false, el cliente captura el tráfico, pero el endpoint aún debe enrutarlo y autorizarlo; si no, los paquetes entran en el túnel y se detienen allí. Vuelva a conectar el cliente tras cambiar cualquiera de los dos ajustes, porque las rutas y los servidores DNS se entregan en el momento de la conexión y un cliente en marcha puede conservar su conjunto anterior.

Lea la ruta del endpoint y la regla de autorización por separado

Son dos objetos, y crear uno no crea el otro. Enumere las rutas del endpoint y busque una predeterminada cuyo destino sea una subred asociada:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Cada ruta tiene exactamente una subred de destino, así que tres asociaciones necesitan una ruta predeterminada correspondiente cada una. AWS documenta este requisito de cobertura, y el síntoma práctico de un hueco es un usuario que trabaja desde una subred y se atasca desde otra, lo que se lee como un fallo intermitente en lugar de una ruta ausente. La documentación oficial del escenario de Client VPN describe la disposición de subred pública a la que pertenecen estas rutas.

La autorización es el segundo objeto. Cuando ninguna regla cubre el destino público, el túnel transporta el paquete y el servicio lo descarta, así que los recursos privados siguen funcionando mientras internet no lo hace:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Una regla para el CIDR de la VPC no dice nada sobre 0.0.0.0/0. Añadir las piezas que faltan para un túnel completo significa una ruta por subred asociada más una regla de autorización que pueda auditar después:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all concede el destino a todos los clientes del endpoint, así que manténgalo solo mientras el túnel deba ser completo; una regla vinculada a un grupo de directorio es preferible cuando tiene grupos a los que vincularla.

Siga el paquete fuera de la subred asociada

La ruta del endpoint decide que AWS entrega el paquete a esa subred. No decide el siguiente salto más allá, que vive en la tabla de rutas VPC propia de la subred:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Una ruta predeterminada utilizable apunta a una internet gateway para una subred pública, o a una NAT gateway para una privada, y un estado blackhole significa que el destino se eliminó y el camino ahora muere en silencio. Son tablas distintas de la lista de rutas del endpoint, y reparar una no repara la otra.

En este salto hay dos filtros. El grupo de seguridad aplicado a la asociación de red de destino debe permitir el tráfico de salida hacia el destino público, y cualquier ACL de red aplicable debe permitir la solicitud y el tráfico de retorno en puertos efímeros. Un grupo de seguridad de asociación restrictivo es una causa habitual de que el acceso privado funcione y el público no.

Elija la primera capa a partir del síntoma en lugar de cambiar las tres a la vez:

Separe el fallo de DNS de una ruta muerta

La resolución de nombres falla de forma distinta al reenvío, y el túnel completo hace que la diferencia importe porque ahora se llega al resolutor empujado a través del túnel. Si el endpoint especifica servidores DNS de la VPC, sus direcciones necesitan cobertura de ruta y autorización como cualquier otro destino. Consulte el resolutor directamente para ver qué fallo tiene: dig +short example.com @10.0.0.2, o nslookup example.com 10.0.0.2 en Windows.

Cuando una URL numérica responde y una con nombre no, deje de editar la ruta predeterminada y trabaje en DNS. Una solicitud a una dirección IP no demuestra nada sobre un host virtual con nombre y su certificado, así que mantenga una prueba con nombre en la comprobación final.

El tiempo ayuda. Una conexión TCP que no recibe respuesta en unos segundos apunta al enrutamiento o a un filtro, mientras que una solicitud que se cuelga dentro de la búsqueda de nombre apunta al resolutor. Cambiar la ruta predeterminada mientras el resolutor es inalcanzable suele convertir un fallo en dos.

Revierta con limpieza y luego verifique el camino de salida

Ambos objetos eran aditivos, así que revertir es borrar y no reparar:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Vuelva a conectar y confirme por qué camino sale el tráfico. Compare la dirección pública observada con la dirección IP elástica de la NAT gateway, o con la internet gateway que pretendía usar, y compruebe que un recurso privado sigue respondiendo en la misma sesión.

Termine con una lista corta y trate el último elemento como parte del cambio y no como documentación:

• Una 0.0.0.0/0 ruta de endpoint para cada subred asociada.
• Una regla de autorización que cubra 0.0.0.0/0 para los clientes a los que quiere servir.
• Una ruta predeterminada de VPC que no esté en estado blackhole en cada subred asociada.
• Salida del grupo de seguridad de la asociación, más el tráfico de retorno de la ACL.
• Direcciones del resolutor enrutadas y autorizadas, verificadas con una solicitud con nombre.
• Una reversión registrada para la ruta y la regla.

Una nota de alcance: este es un camino IPv4. Un cliente de pila doble conserva la conectividad IPv6 que ya tenga, así que una ruta predeterminada IPv6 es una decisión aparte con su propia autorización y no un efecto secundario de esta.