Por qué los clientes de OpenVPN se pierden los selectores IPsec de la puerta de enlace

Haz ping a un host detrás del túnel IPsec remoto desde la puerta de enlace y responde limpiamente, así que el túnel parece sano y el tique avanza. Después un cliente conectado prueba el mismo host y no recibe nada. Ese ping nunca fue una prueba del flujo del cliente, porque salió con la propia dirección de origen de la puerta de enlace y coincidió con otro selector IPsec. Entender por qué los dos casos divergen es la mayor parte de la solución.

El ping de la puerta de enlace prueba un flujo que tu cliente nunca usa

La dirección de origen decide qué política se aplica. Un paquete generado en la puerta de enlace sale con una dirección de su LAN local o de su extremo del túnel, y la política que coincide con él se escribió exactamente para ese caso. El paquete de un cliente llega a la interfaz OpenVPN con una dirección del pool de clientes, que es un selector completamente distinto.

Por eso el fallo parece un problema de enrutamiento cuando en realidad es un problema del alcance de la política. La accesibilidad desde la puerta de enlace demuestra que el par está activo y que las propuestas se negociaron, y no demuestra nada sobre si el pool está protegido.

Empuja el prefijo remoto que la aplicación necesita de verdad

Toma el par ilustrativo 10.8.0.0/24 para los clientes conectados y 172.30.239.0/25 para la red remota protegida. Lo que un cliente necesita es una ruta hacia ese segundo prefijo, no hacia la LAN de la puerta de enlace ni hacia otra dirección de túnel. Una ruta empujada al pool es lo que hace que el cliente entregue ese tráfico a la puerta de enlace. Sin ella, el paquete nunca llega a la decisión de política que estás depurando.

En un servidor Community que acepta rutas empujadas, la directiva toma la máscara real: push "route 172.30.239.0 255.255.255.128". Access Server configura el mismo destino mediante los ajustes de red privada o de reglas de acceso de la versión instalada, con el modo enrutado o traducido elegido a propósito. Editar las cadenas de cortafuegos generadas en lugar de la configuración propietaria es como una instalación funcional se vuelve imposible de reproducir.

Después de conectar, lee la tabla de rutas del cliente y no la intención del servidor. Una ruta que solo cubre el pool significa que el empuje nunca llegó, y una ruta por defecto por el túnel es más amplia que este requisito y te sorprenderá más adelante. Comprueba la máscara y también el prefijo, porque un /25 empujado como /24 envía el tráfico de direcciones vecinas por un camino que no puede llevarlo. Luego confirma que el cliente eligió la interfaz del túnel para ese destino.

Haz que los selectores incluyan el pool de clientes

Para el acceso enrutado que conserva las direcciones de los clientes, la política IPsec tiene que proteger el tráfico entre el pool y el prefijo remoto. Los selectores escritos para la LAN propia de la puerta de enlace admiten el ping y descartan la petición del cliente, y esa es exactamente la asimetría que inició esta investigación.

Inspecciona la política negociada y también las propuestas configuradas, por ejemplo con ipsec statusall en strongSwan o el comando de estado equivalente de tu implementación. Con IPsec basado en políticas, la ruta ordinaria puede apuntar a una interfaz física mientras el tráfico coincidente sigue cifrado, así que un dispositivo de túnel ausente no demuestra nada. Compara los pares de selectores con el pool y el prefijo que anotaste.

El NAT de origen genérico en la puerta de enlace también puede romper la coincidencia. Si una regla de masquerade reescribe el origen del cliente antes de la comprobación de política, el paquete ya no se parece al selector que escribiste. Es una razón por la que una regla de masquerade amplia es una mala solución para un segundo VPN: cambia qué política se aplica y qué dirección registra el lado remoto. Exime el tráfico que pretendes enrutar, o tradúcelo a propósito y actualiza los selectores.

Elige enrutamiento o traducción a propósito

El enrutamiento mantiene la dirección del cliente visible para el lado remoto, así que los registros remotos y las reglas por origen siguen teniendo sentido, y exige que la puerta de enlace remota conozca el camino de vuelta al pool. La traducción esconde el pool tras una sola dirección, lo que elimina el problema de la ruta de vuelta y destruye la identidad de cada cliente.

Elige un diseño y escríbelo, porque los dos necesitan selectores distintos y un orden de cortafuegos distinto. Un masquerade aplicado a medias queda entre ambos y no satisface a ninguno. La elección escrita es también lo que permite al siguiente ingeniero distinguir un fallo de una decisión deliberada.

Cierra el bucle con el reenvío y la respuesta

La puerta de enlace tiene que reenviar el protocolo y el destino que pretendes, lo que significa reenvío IP activado y una cadena de reenvío que permita el par. Luego el lado remoto tiene que devolver las respuestas por el camino IPsec, y eso es una decisión de enrutamiento en su puerta de enlace y no en la tuya. Ambas mitades son configuración corriente, y ambas son fáciles de dejar a medias. Pruébalas por separado para que una regla de reenvío ausente no se confunda con un túnel roto.

Verifica con una petición real de cliente a aplicación, observando cómo cruza la interfaz OpenVPN, la decisión IPsec y el host remoto. Inspecciona la respuesta como una observación aparte, porque una petición que llega y una respuesta que nunca vuelve se ven iguales desde el asiento del cliente. Una petición trazada vale más que cualquier número de pings desde la puerta de enlace.

Mantén estrecha la autorización de destino mientras pruebas, y confirma que un cliente sin la regla no puede llegar al servicio. Una ruta instalada más una asociación establecida no es lo mismo que un acceso concedido.