Usuario de puerta de enlace en Access Server: enrutar la LAN de la sucursal de un cliente

Puede hacer ping a la dirección de túnel de un cliente OpenVPN y aun así no llegar a ningún host de la LAN que hay detrás. Access Server le asigna al cliente una dirección del pool de VPN, y la dirección del pool es lo único que el servidor sabe que posee. El prefijo de la sucursal es un hecho aparte que hay que declarar, y aun así la sucursal necesita un reenviador y la central una ruta de retorno. Una ruta escrita en el lugar equivocado parece una solución y no cambia nada.

Dos direcciones, dos reclamos de propiedad distintos

Cuando un cliente se conecta, Access Server le asigna una dirección del pool de VPN configurado, por ejemplo 10.90.0.0/24. Esa asignación es un arrendamiento para un solo host. Nada en la conexión dice que el mismo cliente también está delante de 10.60.0.0/24, y el servidor no adivinará: un prefijo LAN solo es alcanzable a través de un cliente concreto si un administrador lo declara.

Por eso una ruta estática en otra máquina no sirve. La ruta dice envía 10.60.0.0/24 a esta dirección, pero si la dirección pertenece a un cliente que nunca se marcó como puerta de enlace, el servidor no tiene motivo para entregar allí esos paquetes, y la pila del cliente puede descartarlos. La declaración y la ruta son dos mitades de un mismo mecanismo.

Qué instala en realidad el ajuste de puerta de enlace

En la interfaz de administración la declaración es una propiedad de usuario: active Configure VPN gateway en el usuario conector e introduzca el prefijo real de la sucursal en Network on the VPN client side. Ese usuario se autentica como cualquier otro, así que necesita una política de credenciales apta para un dispositivo sin supervisión, y su perfil de inicio automático es un secreto, no un archivo de comodidad.

Detrás de esa casilla el servidor trata el prefijo como alcanzable a través de la dirección del pool de ese cliente, y la configuración de enrutamiento en Access Controls decide qué se anuncia a los demás clientes: las rutas que se envían a los clientes normales y las reglas de acceso que permiten tráfico desde las redes de la central hacia direcciones y subredes de clientes. Active el enrutamiento para las redes que deben llegar a la sucursal y mantenga corta la lista de redes permitidas.

Una directiva al estilo Community pegada en un archivo generado no participa en este modelo. El producto es dueño de la tabla de enrutamiento que envía; una línea editada a mano se sobrescribe en la siguiente generación o se ignora.

Complete las rutas de retorno de ambas redes

Un plan concreto: central 10.40.0.0/24, sucursal 10.60.0.0/24, pool de VPN 10.90.0.0/24 y Access Server accesible en una dirección privada del lado de la central. El router de la central necesita rutas para el prefijo de la sucursal y para el pool, ambas hacia Access Server. Sin ellas el túnel lleva la petición y la respuesta sale por la puerta de enlace predeterminada, lo que produce la clásica conexión semiabierta.

En la sucursal el conector debe reenviar los paquetes que no van dirigidos a él: reenvío IP en su sistema operativo más un permiso de reenvío limitado a las interfaces de túnel y LAN; en Linux es net.ipv4.ip_forward=1 junto con las reglas de la cadena forward, en Windows es routing and remote access. Después los host de la sucursal necesitan una ruta de retorno: o el conector es su puerta de enlace predeterminada, o la puerta de enlace existente lleva rutas específicas para los prefijos de la central y del pool.

La tabla de enrutamiento del conector no reconfigura todos los host de la LAN de la sucursal. Si los host apuntan a otro router, las rutas de retorno pertenecen allí, y ese router debe aceptar que la dirección de origen que ve no es un vecino de la subred local.

Lea un fallo como un camino, no como un permiso

Pruebe en un orden fijo. Primero un servicio permitido desde Access Server hacia un host de la sucursal, luego el mismo servicio desde un host normal de la central, luego la dirección inversa si la política lo permite. Si la primera pasa y la segunda falla, el problema son las rutas enviadas o las reglas de acceso. Si ambas pasan pero no llegan respuestas, examine el reenvío en la sucursal y la ruta de retorno en la central.

El cortafuegos del host es el siguiente sospechoso, porque con acceso enrutado el destino ve como origen una dirección de la central o del pool. Una regla escrita para la subred local no coincidirá y el paquete se descarta después de que el enrutamiento funcionara perfectamente.

Dos diseños necesitan más que este patrón. Los prefijos superpuestos entre sedes vuelven ambiguo el destino y exigen reenumeración o traducción, y un Access Server en clúster necesita que cada nodo tenga un camino funcional hacia el conector de la sucursal, no un solo nodo que retenga la ruta. Aplique los cambios por la vía normal de guardado y actualización, reconecte el conector y verifique de nuevo desde ambos extremos; reiniciar por completo cada máquina no forma parte del procedimiento.

El tutorial site-to-site de Access Server enumera los mismos ajustes en el orden del producto; vale la pena seguirlo una vez antes de adaptar el diseño a sus propios prefijos.