así que tengo en la configuración un servidor openvpn ejecutándose en la subred 192.168.7.0/24. El servidor openvpn ofrece una configuración de servidores semicompleja, por lo que cambiar la subred solo se considera un último recurso (aunque espero no llegar allí)
El problema es que algunos usuarios se quejan de que en la oficina doméstica no pueden usar algunos recursos de la red aunque tienen el VPN activado. Una mirada más profunda mostró que usan para sus redes domésticas la misma subred que para el servidor OpenVPN. por lo tanto, las solicitudes se enrutan internamente en lugar de enviarse a través de la VPN.
No es posible cambiar a IPv6 y usar NAT para tal cosa es extremadamente sucio.
Intenté forzar a los clientes vpn a usar el servidor vpn como GW predeterminado presionando "redirect-gateway def1" o/y presionando "redirect-gateway local def1" en el lado de configuración del servidor, sin suerte.
¿algunas ideas?
muchas gracias
Respuesta1
El problema con la redirección de la puerta de enlace es que en la tabla de enrutamiento las entradas más específicas anulan las menos específicas. Por lo tanto, presionar la puerta de enlace generalmente no es de gran ayuda, ya que cada computadora contiene una /24entrada de ruta de alcance de enlace para la red local, que por supuesto es más específica que la ruta predeterminada anunciada, por lo que se usará en su lugar.
Si realmente no desea cambiar la subred VPN, lo mejor que puede hacer es enviar rutas específicas para los recursos en la red VPN, ya que una ruta para un host simple anulará la entrada del alcance del enlace.
Es posible que desee "hacer trampa" y enviar dos /25redes (es decir, 192.168.7.0/25y 192.168.7.128/25), que son más específicas que la /24red local, y estas dos cubren casi toda la subred VPN (menos los hosts en el "borde", es decir , anfitriones 127y 128). En este caso, también desea presionar las directivas redirect-localo redirect-local def1para asegurarse de no perder la puerta de enlace predeterminada y, con ella, la conexión del cliente al servidor VPN.
Sin embargo, en mi opinión, la mejor solución es cambiar la subred VPN a algo "feo" que probablemente no colisione con las redes domésticas (por ejemplo, bastantes personas configuran su red doméstica en algo como 10.287.29.0/24). Esta puede ser una tarea desalentadora, pero es la forma "limpia". Además, es la mejor manera de asegurarse de no encontrar sorpresas debido a la superposición de subredes.