Tengo una red OpenVPN con un servidor y dos clientes. Cuando configuro mi ruta predeterminada en C1 para pasar por S (que tiene habilitado el reenvío de IP y NATing), todo funciona como se esperaba. El problema es que si apunto la ruta predeterminada C1 a C2 (que también está configurada correctamente para el tráfico NAT de VPN a Internet), S captura el tráfico de todos modos y lo reenvía. Cuando hago tcpdump en C2, no hay señales de que llegue nada allí. ¿Es posible configurar el cliente como puerta de enlace para otros clientes en OpenVPN o es propiedad del sistema que los paquetes se enruten por evento del servidor si la ruta del cliente apunta a otro cliente?
Editar:
Los corchetes representan mi red virtual (no existe físicamente). C1/C2/S pueden hacer ping entre sí dentro de la red sin problemas. Quiero enrutar el tráfico desde C1 a C2 a Internet. Puedo enrutar desde C1 (y probablemente desde C2) a través de S a Internet, pero el enrutamiento a través de C2 no funciona ya que S reenvía los paquetes. Esto parece ser un problema porque el servidor OpenVPN no quiere enviar paquetes a donde deberían ir.
[C1-S(NAT)] -- Internet Internet--[(NAT)C2/]
Respuesta1
Responder esto completamente es difícil sin conocer la topología de red que intenta describir. Aunque creo que puedo decir que, en general, es posible hacer lo que pides.
Considere el siguiente escenario:
C1 -- R1 --(NAT)-- Internet --(NAT)-- R2 -- C2
Aquí, si hay un túnel OpenVPN (correctamente configurado) creado entre R1 y R2, entonces C1 puede hablar con C2 y viceversa.
Este escenario es más difícil de corregir:
C2 -- R1 --(NAT)-- Internet --(NAT)-- R2 -- C3 C1/\C4
Donde C2 y C3 son los puntos finales de OpenVPN y C1 debería usar la VPN para llegar a C4. El primer obstáculo es establecer el túnel OpenVPN entre C2 y C3, probablemente utilizando el reenvío de puertos desde R1 y R2 de UDP 1190 a C2 y C3 respectivamente.
El siguiente es hacer que C1 use C2 como forma de llevar paquetes a C4. Eso implica configurar la tabla de enrutamiento en C1 y C4. C1 establece la ruta a la red de C4 a través de C2 y C4 establece la ruta a la red de C1 a través de C3. Ambas rutas deberían tener prioridad sobre la predeterminada. Entonces, tal vez en C1: {ruta agregar 192.168.3.0 gw 192.168.2.2} y en C4: {ruta agregar 192.168.1.0 gw 192.168.3.2}. Esto supone que las direcciones de C2 y C3 son 192.168.2.2 y 192.168.3.2 respectivamente, y que C1 y C4 están en la misma red que C2 y C3 respectivamente.
Con suerte, esto será suficiente para responder su pregunta y demostrar que es mucho más fácil configurar la VPN en la puerta de enlace predeterminada que configurar la VPN en un cliente, pero existen casos de uso para ambos.
Editar: Con esta topología y descripción del problema, creo que hay problemas de enrutamiento en C1 y C2... La ruta predeterminada de C1 debe apuntar a la dirección VPN de C2 como enrutador. Eso obligará a C1 a usar la VPN para enviar paquetes a C2, luego C2 decide qué hacer con ellos.
En el caso de que C2 utilice su propia conexión a Internet, como ha mostrado, la ruta predeterminada de C2 debería ser su propia conexión a Internet.
Si, en cambio, C2 no tiene realmente su propia ruta a Internet y pasa por S, entonces S debería ser el enrutador predeterminado de C2.
Respuesta2
Me enfrenté a este problema antes, tenía un cliente VPN funcionando, lo que me impedía acceder a otro dispositivo en la LAN de mi casa. Tuve que configurar una ruta estática a la segunda máquina, ya que el cliente vpn agregará automáticamente una ruta predeterminada y reenviará todo el tráfico al servidor.
Si está bien que el tráfico de C1 a C2 pase a través del servidor, debe habilitar la directiva de cliente a cliente en server.conf para que los clientes puedan comunicarse entre sí a través de la VPN. De forma predeterminada, los clientes sólo podrán acceder al servidor.
Controlarhttp://openvpn.net/index.php/open-source/documentation/howto.htmlen "Inclusión de varias máquinas en el lado del cliente cuando se utiliza una VPN enrutada (dev tun)".