Usted preguntó: " ¿Puede alguien explicar por qué se produce este problema en primer lugar? "
Basándose en lo informado en las FAQ oficiales de OpenVPN Apuesto a que está causado por un problema de enrutamiento dentro del motor OpenVPN.
Para aclarar mejor el escenario, permítanme referirme al siguiente diagrama:
![]()
Aquí puedes ver:
- un "servidor" OpenVPN conectado a la red interna de la SEDE (10.0.1.0/24)
- un "cliente" OpenVPN ejecutándose en un Sitio Remoto, y conectado a la red remota 192.168.1.0/24
También
- estamos asumiendo que el túnel OpenVPN está establecido y:
- El "servidor" OpenVPN es accesible a través de su propio tun con dirección 10.10.0.1. También la dirección P2P, utilizada por la interfaz tun es 10.10.0.2 ( esto es importante para la discusión posterior, así que vamos a enfatizarlo )
- El "cliente" OpenVPN tiene un tun interfaz con IP 10.10.0.2
Ahora, vamos a suponer que:
- el "Cliente" OpenVPN ha redefinido su puerta de enlace por defecto, para redirigir dentro del túnel todo el tráfico IP saliente;
- el "Cliente" OpenVPN tiene activado IP_FORWARDING y, como tal, puede enrutar paquetes procedentes de su LAN interna (192.168.1.0/24) ( Hago hincapié en este punto, ya que es fundamental para nuestra discusión ).
Con este escenario en marcha, comprobemos en detalle qué ocurre cuando R_PC1 (192.168.1.2) envía un paquete, como una eco-solicitud, a L_PC1 (10.0.1.2):
- después de salir de R_PC1 NIC, el paquete llega al cliente OpenVPN;
- cliente OpenVPN (que está configurado para actuar como un enrutador común), enrutarlo según su tabla de enrutamiento. Como su puerta de enlace por defecto es el túnel, envía el paquete al túnel;
- El paquete llega a la interfaz tun del servidor OpenVPN. OpenVPN lo "verá" y, como (el servidor OpenVPN) sabe que 10.0.1.2 es una dirección perteneciente a su subred LAN, "reenviará" el paquete, de TUN a LAN;
- Paquete alcanzado L_PC1.
Así que todo está bien...
Ahora comprobemos qué ocurre con la eco-respuesta que L_PC1 responde a R_PC1.
- La eco-respuesta sale del NIC L_PC1 y llega a la interfaz LAN del servidor OpenVPN (10.0.1.1);
Ahora, si queremos que el servidor OpenVPN pueda alcanzar el sitio remoto, necesitamos definir el enrutamiento con una "ruta estática". Algo como:
route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2
Tenga en cuenta la dirección P2P utilizada como pasarela .
Estas rutas estáticas funcionarán a nivel de sistema operativo. En otras palabras, son necesarias para que el sistema operativo enrute correctamente el paquete. Significa algo así como: "Por favor, todo el tráfico dirigido a la subred 192.168.1.0/24 necesita ser reenviado al motor OpenVPN, con el que el SO puede hablar a través de la dirección P2P". Gracias a tal ruta estática, ahora...
- el paquete abandona el contexto de enrutamiento del sistema operativo y llega a OpenVPN. La instancia de OpenVPN que se ejecuta en el servidor OpenVPN. Por lo tanto, en este punto, el sistema operativo no tiene nada más que hacer y todo el enrutamiento (dentro de la VPN) se deja al software del servidor OpenVPN.
Así que, ahora, el problema es: como, el software servidor openvpn, podrá decidir la ruta de un paquete, con SRC_IP 10.0.1.2 y DST_IP 192.168.1.2 ?
Tenga en cuenta que, en función de la configuración del servidor OpenVPN, sabe nada sobre la red 192.168.1.0/24, ni sobre el host 192.168.1.2. Es no un cliente conectado. Es no un cliente local. ¿Y entonces? OpenVPN, también, sabe que es no el "OS-Router", por lo que realmente no quiere (y puede....) enviar el paquete de vuelta a la pasarela local. Así que la única opción, aquí, es lanzar un error. Exactamente el error que estás experimentando
Para decirlo con el lenguaje de las FAQ: " ...no sabe cómo encaminar el paquete a esta máquina, así que lo desecha... ".
¿Cómo podemos resolver el problema?
Como puede ver en la documentación oficial la opción iroute sirve exactamente a nuestro ámbito:
--iroute network [netmask]
Generate an internal route to a specific client. The netmask
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server
to a particular client, regardless of where the client is
connecting from. Remember that you must also add the route to the
system routing table as well (such as by using the --route
directive). The reason why two routes are needed is that the
--route directive routes the packet from the kernel to OpenVPN.
Once in OpenVPN, the --iroute directive routes to the specific
client.
Así que necesitas una:
--iroute 192.168.1.0 255.255.255.0
a aplicar (al servidor) cuando su cliente OpenVPN se conecte, por ejemplo a través de un archivo de configuración ad-hoc definido en el servidor (client-config-dir, etc.).
Si se pregunta por qué este problema no suceder en el paso 2) anterior, entiendo que OpenVPN Client conoce cómo enrutarlo, porque sabe que el túnel VPN es una pasarela por defecto.
Lo mismo no se puede hacer en OpenVPN Server, porque allí la puerta de enlace predeterminada es típicamente no anulado. Además, considere que podría tener un único servidor OpenVPN con un montón de clientes OpenVPN: cada cliente sabe cómo llegar al servidor pero... ¿cómo puede, el servidor, decidir cuál es el cliente que actúa como puerta de enlace para una subred desconocida?
En cuanto a su primera pregunta( ¿Pueden redactarse las normas necesarias de forma genérica/única? ), lo siento pero no entiendo muy bien tu problema. ¿Podría explicarlo con más detalle?
