Por qué los clientes de Access Server no son accesibles desde la LAN

El portátil se conecta, el túnel está activo y las peticiones a un servicio interno se quedan colgadas al conectar. En el propio servicio la petición llega desde una dirección como 10.90.0.25, la respuesta sale hacia la puerta de enlace predeterminada y no vuelve nada, porque esa puerta no tiene ni idea de dónde vive 10.90.0.25. Desde el otro extremo, el mismo fallo parece un host interno que no puede hacer ping a un cliente conectado. Ambos son un solo objeto que falta: una ruta de vuelta al grupo de clientes VPN, que solo la red privada puede añadir.

Lee la dirección de origen que ve el servicio

Ese único campo decide todo lo demás. Si el servicio interno ve la dirección del grupo, Access Server enruta en lugar de ocultar el tráfico de los clientes, y cada respuesta debe enrutarse de vuelta al grupo. Si en cambio ve la dirección privada del propio servidor, el servidor hace masquerade y la ruta de vuelta ya funciona, a costa de perder cualquier identidad por cliente en los registros y las reglas de acceso del servicio.

Compara ambos extremos antes de cambiar nada. En el servidor, lista las interfaces del túnel y sus direcciones; en el cliente, confirma cuál de esas direcciones tiene realmente; en el host interno, mira una conexión activa.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

El último comando es el que falla en el caso roto: o informa que el prefijo del túnel no es accesible o, peor, devuelve tu puerta de enlace predeterminada, y así es como las respuestas acaban en internet.

No supongas un solo grupo. Un servidor puede tener un rango dinámico más asignaciones estáticas por usuario, y la dirección estática puede quedar completamente fuera del prefijo dinámico. Si solo enrutas el rango que recuerdas, los usuarios con direcciones fijas siguen rotos y todos los demás informan que el problema está resuelto.

Añade la ruta donde se decide la respuesta

La ruta pertenece a la puerta de enlace que el servicio interno ya usa, no al servicio, salvo que enrute su propio tráfico. Apúntala a la dirección privada accesible de Access Server, que es un valor distinto de la dirección del túnel que tiene un cliente.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

En una red de nube la misma afirmación se convierte en una entrada de tabla de rutas cuyo destino es la instancia o la interfaz de red donde se ejecuta el servidor, con la comprobación de origen y destino desactivada en esa interfaz. Fíjate en lo que esa entrada no hace: una ruta no es una concesión de acceso, así que los grupos de seguridad, las ACL de red y el cortafuegos del host todavía tienen que permitir el tráfico.

Hazla persistente y mantén honestos los tamaños de los grupos. Dos grupos no contiguos necesitan dos rutas, y un grupo que crece más allá de su prefijo configurado genera en silencio clientes cuyas respuestas no tienen adónde ir. Si controlas los rangos de los grupos, elige un resumen que puedas enrutar una vez y dejar tranquilo.

El reenvío y los filtros deben coincidir con la ruta

El enrutamiento es solo la mitad del camino. Hay que permitir que el servidor reenvíe entre el túnel y la interfaz privada, lo que en Linux significa net.ipv4.ip_forward más una cadena de reenvío que permita el par de interfaces, y en un host endurecido normalmente una regla explícita por dirección.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

El filtrado con estado explica un síntoma que lleva a la gente por el camino equivocado. Una respuesta dentro de un flujo establecido no necesita una regla de entrada nueva, así que una conexión que se cuelga tras el SYN-ACK no está bloqueada por una regla de aceptación ausente; se está descartando o enrutando mal. Mantén esa distinción, porque separa un cambio de enrutamiento de un cambio de cortafuegos.

Las rutas de vuelta asimétricas son la versión más silenciosa del mismo problema. Si dos rutas llegan al grupo y la respuesta toma la que sale por una interfaz distinta de aquella por la que llegó la petición, el filtrado estricto de ruta inversa la descarta y el flujo falla solo para algunos clientes.

Enrutado o enmascarado: elige a conciencia

El modo enrutado conserva la dirección del grupo del cliente en el servicio, lo que hace posibles el registro y la política por cliente, y a cambio cada red interna que deba responder a un cliente necesita la ruta del grupo. El modo enmascarado elimina ese requisito porque las respuestas vuelven al servidor, pero el servicio ya no distingue un cliente de otro y no puede iniciar nada hacia un cliente concreto.

Cambiar ese comportamiento en un servidor en producción corta las sesiones existentes, así que prueba primero con un cliente y un flujo. Si el cambio es la respuesta correcta, es una decisión de configuración en el servidor, no algo que se sortee añadiendo rutas que luego serán innecesarias.

Una subred detrás del cliente es una tarea aparte

Llegar a un dispositivo en la propia LAN del portátil no es lo mismo que llegar a la dirección del túnel del portátil. Requiere que el cliente actúe como puerta de enlace de subred: una red declarada en el lado del cliente, el reenvío activado en el sistema operativo del cliente y una ruta en esa LAN de vuelta hacia el cliente. Añadir una ruta de red privada para el rango doméstico del portátil no hace esto, y crea conflictos cuando dos usuarios tienen el mismo rango doméstico.

La dirección también es una cuestión de política. El permiso para que un cliente abra una conexión a un servicio interno no permite automáticamente que un host interno abra una conexión a ese cliente. Comprueba la política de acceso del servidor y el cortafuegos del host del cliente antes de concluir que el camino está roto.

Verifica con un flujo y una captura

Demuestra el camino con una sola conexión en lugar de una prueba general de accesibilidad. Observa el mismo flujo en ambos extremos: la petición que llega al servicio y la respuesta que sale de él.

tcpdump -ni any host 10.90.0.25 and port 443

Antes de la corrección la captura muestra la respuesta saliendo hacia una puerta de enlace que no la enrutará. Después de la corrección la respuesta sale hacia el servidor y el flujo se completa. Luego confirma la ruta que la puerta usaría para una segunda dirección de cliente, para que un grupo que no has cubierto aparezca ahora y no dentro de una semana.

Termina con las cuatro comprobaciones que cierran el asunto: la dirección de origen en el servicio coincide con el modo que pretendías, la puerta tiene ruta a cada grupo en uso, el reenvío y los filtros permiten ambas direcciones, y un flujo real se completa de extremo a extremo. Preguntas frecuentes de enrutamiento de Access Server expone el mismo principio para la versión instalada, cuya interfaz de configuración admitida puede diferir de las guías antiguas.