Usted preguntó: " ¿Alguien puede explicar por qué este problema ocurre en primer lugar? "
Según lo informado en las preguntas frecuentes oficiales de OpenVPN , apuesto a que es causado por un problema de enrutamiento dentro del motor de 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 que se ejecuta en un sitio remoto y se conecta a la red remota 192.168.1.0/24
también
- estamos asumiendo que el túnel OpenVPN está establecido y:
- Se puede acceder al "servidor" de OpenVPN a través de su propia interfaz tun , con la 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 una discusión posterior, así que enfaticemos )
- El "cliente" OpenVPN tiene una interfaz tun con IP 10.10.0.2
Ahora, supongamos que:
- el "Cliente" de OpenVPN ha redefinido su puerta de enlace predeterminada, para redirigir dentro del túnel todo el tráfico IP saliente;
- OpenVPN "Client" tiene habilitado IP_FORWARDING y, como tal, puede enrutar paquetes provenientes de su LAN interna (192.168.1.0/24) ( estoy enfatizando este punto, ya que es crítico para nuestra discusión ).
Con tal escenario en su lugar, verifiquemos en detalle qué sucede cuando R_PC1 (192.168.1.2) envía un paquete, como una solicitud de eco, a L_PC1 (10.0.1.2):
- después de abandonar la NIC R_PC1, el paquete llega al cliente OpenVPN;
- Cliente OpenVPN (que está configurado para actuar como un enrutador común), enrute de acuerdo con su tabla de enrutamiento. Como su puerta de enlace predeterminada 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 (servidor OpenVPN) sabe que 10.0.1.2 es una dirección que pertenece a su subred LAN, "reenvía" el paquete, de TUN a LAN;
- El paquete alcanza L_PC1.
Entonces todo está bien ...
Ahora verifiquemos qué sucede con la respuesta de eco que L_PC1 responde a R_PC1.
- echo-reply deja la NIC L_PC1 y alcanza la interfaz LAN del servidor OpenVPN (10.0.1.1);
Ahora, si queremos que OpenVPN Server pueda llegar al sitio remoto, debemos 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 puerta de enlace .
Dichas rutas estáticas operarán a nivel del sistema operativo. En otras palabras, es necesario que el sistema operativo enrute correctamente el paquete. Significa algo como: "Por favor, todo el tráfico dirigido a la subred 192.168.1.0/24 debe reenviarse al motor OpenVPN, con el que el sistema operativo puede comunicarse a través de la dirección P2P". Gracias a esa 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. Entonces, en este punto, el sistema operativo no tiene nada más que hacer y toda la ruta (dentro de la VPN) se deja al software del servidor OpenVPN.
Entonces, ahora, el problema es: ¿cómo, el software del 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, según la configuración del servidor OpenVPN, no sabe nada acerca de la red 192.168.1.0/24 ni del 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 en realidad no quiere (y puede ....) enviar el paquete de regreso a la puerta de enlace local. Entonces, la única opción, aquí, es generar un error. Exactamente el error que estás experimentando
Para decirlo con el lenguaje de las preguntas frecuentes: " ... no sabe cómo enrutar el paquete a esta máquina, por lo que deja caer el paquete ... ".
Cómo podemos resolver el problema?
Como puede ver en la documentación oficial , la opción iroute sirve exactamente para nuestro alcance:
--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.
Entonces necesitas un:
--iroute 192.168.1.0 255.255.255.0
se 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 ocurre en el paso 2) anterior, entiendo que OpenVPN Client sabe cómo enrutarlo, porque sabe que el túnel VPN es una puerta de enlace predeterminada.
No se puede hacer lo mismo en OpenVPN Server, porque allí la puerta de enlace predeterminada normalmente no se anula. 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 escribirse las reglas requeridas de forma genérica / única? ), Lo siento, pero no entiendo su problema. ¿Puedes reformular proporcionando más detalles?