LAN detrás de una sesión de AWS Client VPN: qué se reenvía

El portátil se conecta al punto de enlace de AWS Client VPN, llega a la subred privada y todo parece saludable. El escritorio de la misma LAN no llega a nada, aunque el host Linux también tiene una interfaz de puente y ambas máquinas están en el mismo cable. Nada está mal configurado en el túnel; la pieza que falta es el enrutamiento, y el puente es una pista falsa.

Extender una sesión de Client VPN a una LAN es un papel de puerta de enlace. No es un segmento Ethernet estirado dentro de un servicio gestionado.

El host funciona y la LAN no

La interfaz de túnel del equipo Linux tiene una dirección dentro del CIDR del cliente de Client VPN, y el punto de enlace ha enviado rutas para los rangos de la VPC. Una petición hecha en ese equipo es tráfico generado localmente: elige una ruta, sale por el túnel y obtiene una respuesta. Ese camino nunca toca el código de reenvío, la interfaz LAN ni ninguna regla de cortafuegos que gobierne el tránsito.

El tráfico de otro dispositivo de la LAN es un flujo distinto. Llega a la interfaz LAN, necesita una ruta que apunte al túnel, necesita el reenvío habilitado, necesita un cortafuegos que lo permita y necesita que la respuesta vuelva por el mismo host. Cuatro requisitos, y la prueba que funciona con el portátil no demuestra ninguno. Desde el escritorio el fallo parece extraño: el túnel está activo, las credenciales son válidas y el destino simplemente nunca responde. El defecto es local al camino de reenvío de la puerta de enlace, no al servicio.

No todos los clientes pueden ser puerta de enlace

AWS afirma que su aplicación de escritorio Client VPN no admite reenvío IP, y que otros clientes podrían hacerlo. Esa restricción decide la arquitectura antes de escribir ningún comando. Si el único cliente disponible es la aplicación oficial de escritorio, una puerta de enlace Linux que reenvía para la LAN no es una configuración que pueda terminar, y ninguna cantidad de masquerading lo cambiará.

El cliente sustituto también debe coincidir con el método de autenticación del punto de enlace y con la política que pretende aplicar. Los puntos de enlace basados en certificados, en directorio y con SAML no aceptan las mismas configuraciones de cliente, y un cliente de terceros que se autentica pero ignora las rutas enviadas no es una mejora.

Trate la elección del cliente como parte de la revisión del diseño. Determina si el patrón de reenvío de LAN está disponible y determina qué identidad ve el punto de enlace para cada dispositivo detrás de la puerta de enlace. Registre el cliente y la configuración del punto de enlace contra la que se probó. Un cambio de cliente seis meses después puede eliminar en silencio la capacidad que el diseño asumía.

Dirija la LAN al túnel y tradúzcala

Con un cliente compatible en su sitio, el resto es trabajo ordinario de puerta de enlace. Los dispositivos de la LAN necesitan una ruta para el rango de la VPC que apunte al host Linux, y el host necesita el reenvío habilitado. Si quiere que la VPC vea el tráfico como el cliente conectado y no como una dirección LAN arbitraria, traduzca el origen a la salida.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Limite la regla a la interfaz de túnel y al rango de la VPC, como arriba, en lugar de hacer masquerading de todo lo que reenvía el host. La regla más estrecha es más fácil de razonar y no cambia en silencio tráfico que debía conservar su dirección de origen original.

Haga que la ruta de la LAN llegue automáticamente si puede: una opción DHCP, un anuncio de router o una ruta estática empujada por lo que gestiona la LAN. Una ruta que solo existe en una máquina de prueba hará que el diseño parezca roto en el momento en que alguien más lo intente.

La respuesta también necesita un camino

Una vez que la petición llega a la VPC, la respuesta debe volver por los mismos estados de traducción y encontrar la ruta de la LAN en la puerta de enlace. Esa parte suele funcionar cuando la regla de masquerading está en su sitio, porque el mapeo vive en el host que lo hizo. Se rompe cuando el lado de la VPC tiene una ruta que envía la respuesta a otro lugar, y por eso importan tanto la ruta del CIDR del cliente como la asociación de subred en el punto de enlace.

Mire los contadores, no solo el ping. Una regla de masquerading con cero paquetes le dice que la petición nunca llegó a la interfaz de túnel, lo que apunta de vuelta a la ruta de la LAN o a la propia tabla de enrutamiento del cliente. Una regla con paquetes pero sin respuestas apunta al lado de la VPC, a las reglas de autorización o a un grupo de seguridad que no acepta el origen traducido. Lea ambas direcciones antes de cambiar nada, porque un contador que crece solo en un lado es un camino de un solo sentido, no uno lento.

Recuerde que el punto de enlace es un servicio gestionado. No hay archivo de configuración del servidor que editar ni directiva client-config que añadir, así que las instrucciones escritas para un servidor OpenVPN autogestionado con rutas personalizadas de subred de cliente no se trasladan. En AWS las palancas son la asociación de subred, las reglas de autorización y las tablas de enrutamiento de la VPC.

La identidad compartida es la parte que la política debe responder

Cada dispositivo detrás de la puerta de enlace usa la sesión VPN de la puerta de enlace. Las reglas de autorización del punto de enlace conceden acceso a un usuario o a un grupo, y desde el punto de vista del servicio hay exactamente un usuario en esa sesión. El reenvío local no multiplica esa identidad en autenticación por dispositivo, ni extiende las comprobaciones de postura del dispositivo a la impresora del rincón.

Eso puede ser aceptable, o puede ser la razón por la que se rechaza el diseño. Depende de lo que los recursos de la VPC asuman sobre quién llama. Una identidad compartida que encaja con el modelo de autorización está bien; una que convierte en silencio una única sesión autenticada en acceso a toda la LAN es un hallazgo que espera ser escrito.

Si el requisito es realmente conectar todo un sitio a una VPC, compare un diseño admitido de sitio a sitio antes de extender un cliente de acceso remoto. La semántica es distinta, y una sesión de cliente con NAT es un mal sustituto de un enlace de sitio cuando la VPC necesita iniciar conexiones hacia la LAN.

Decida el cliente, la ruta, la traducción y la historia de identidad en ese orden. Cada uno limita al siguiente, y el orden explica por qué el host funciona mientras la LAN no.