Por qué EC2 no puede llegar a tu portátil con AWS Client VPN
Client VPN traduce las direcciones IPv4 del cliente a la interfaz del punto de enlace. Por eso funciona la respuesta y no una conexión nueva desde EC2.
Un portátil conectado mediante AWS Client VPN llega a una aplicación de EC2 sin problemas. Luego pruebas lo contrario, desde EC2 a la dirección que se asignó al cliente, y la conexión se queda colgada o se rechaza. Esa asimetría rara vez se debe a una regla de grupo de seguridad que falte. En un punto de enlace de Client VPN asociado a subredes de VPC, AWS traduce las direcciones IPv4 del cliente a la interfaz de red del punto de enlace, así que no existe una dirección de VPC de entrada que represente a tu portátil.
Empieza por lo que muestra la captura
Haz una captura en el host de EC2 mientras el cliente se conecta y lee la dirección de origen que ve realmente la aplicación. Si es la interfaz del punto de enlace del lado de la VPC y no una dirección del grupo de clientes, la traducción queda confirmada antes de cambiar una sola regla.
El grupo de clientes es un rango de asignación, no una subred con una ruta de retorno. Esa distinción es donde fallan la mayoría de estas investigaciones.
La traducción que explica la asimetría
Tres flujos se confunden entre sí, y solo uno de ellos es el que la gente prueba.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
La descripción de los componentes de Client VPN explica que las direcciones IPv4 del cliente se traducen a la interfaz del punto de enlace, lo que basta para ver por qué la fila central no tiene con qué coincidir.
Una conexión nueva necesita una ruta, un paso de resolución de direcciones y una decisión de autorización. El estado de traducción de la sesión de otra persona no aporta ninguno de los tres.
Por qué una respuesta no es una conexión nueva
Una respuesta TCP se compara con una entrada existente, y por eso el camino de vuelta funciona sin ninguna regla de entrada. Un SYN nuevo del host de EC2 no tiene ninguna entrada con la que coincidir, así que se convierte en un intento de salida normal hacia un destino al que la VPC no sabe llegar.
También por eso es engañoso describirlo como tráfico que solo va en un sentido. El tráfico de vuelta fluye de forma continua en estas sesiones. La parte que no tiene camino es el inicio.
Qué sigue rompiendo una sesión que debería funcionar
Los grupos de seguridad, las listas de control de acceso de red y el cortafuegos del propio portátil importan para las conexiones que deberían funcionar. Un ping fallido es lo que menos te dice, porque la política de ICMP suele ser independiente de la política de TCP que te interesa.
Escribe esas reglas respecto al origen traducido, no a la dirección del cliente. Las reglas ligadas a la dirección que nunca aparece en la red son el fallo autoinfligido más común de este diseño.
Cuando la VPC realmente tiene que iniciar la conversación
Si un servicio tiene que avisar a un puesto de trabajo, invierte la dirección y deja que el cliente mantenga un canal de salida persistente al que responda el servicio. Si toda una red remota debe ser accesible desde la VPC, elige una arquitectura que publique sus prefijos y su política de acceso en lugar de suponer que Client VPN ya lo hace. El acceso cliente a cliente es un tercer caso, más estrecho, con sus propios objetos de ruta y autorización. Nada de esto es una casilla de verificación en el punto de enlace existente.
Mantén honesto también el alcance de la explicación de IPv4. La documentación actual de AWS separa IPv6, donde esa traducción no se aplica, y otros modelos de conexión que enrutan de forma distinta.
Prueba en tres pasos etiquetados: el cliente abre una sesión permitida, el servicio de la VPC responde a esa sesión y un host de la VPC abre una sesión nueva hacia el cliente. Que los dos primeros funcionen y el tercero falle es la forma esperada de este diseño, no un defecto que haya que perseguir con reglas de cortafuegos.