Estoy intentando configurar un servidor y un cliente openvpn, con todo el tráfico del cliente enrutado a través del servidor. Actualmente puedo acceder al servidor a través del cliente, pero cuando habilito 'push "redirect-gateway def1"' en el servidor, el cliente pierde toda capacidad de conectarse a Internet, VPN o de otro modo. Además, ya no puede conectarse al servidor, aunque la conectividad LAN sigue siendo buena. El archivo de configuración de mi servidor es:
local ***.***
port 1194
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway local def1"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
y aquí está el cliente:
client
dev tun
proto tcp
remote ***.*** 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert laptop.crt
key laptop.key
ns-cert-type server
comp-lzo
verb 3
En el servidor, habilité el reenvío de IP y habilité el enrutamiento a través de iptables:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
pero el cliente todavía no puede conectarse a nada en la VPN o en Internet.
Respuesta1
Como referencia, la sección correspondiente del CÓMO esaquí, aunque sospecho que lo has seguido.
Lo primero que intentaría es eliminar el 'local', es decir, el comando debería ser
push "redirect-gateway def1"
y no
push "redirect-gateway local def1"
La bandera local sólo funciona si todos sus clientes están en la misma subred.
Un par de cosas más a tener en cuenta son que el tráfico DNS se enruta a través de la VPN, por lo que no podrás resolver direcciones a menos que hayas solucionado eso. DHCP también se puede reenviar, aunque no parece que eso deba suceder en su caso, ya que está utilizando una VPN enrutada, no un puente, pero de todos modos podría valer la pena verificarlo.
Respuesta2
Si está "enviando" una nueva puerta de enlace al cliente, entonces también necesitará enviar algunas rutas, en particular la ruta a la subred donde reside esa puerta de enlace. Eso le dará acceso a Internet a través de la VPN. Si la red donde reside la puerta de enlace es diferente de aquella donde reside el servidor VPN, entonces también necesitará rutas adicionales para que el cliente pueda acceder a estas otras redes. Además, es posible que también desee enviar servidores DNS al cliente, porque de lo contrario el cliente no podrá resolver los nombres de ninguno de los objetivos en la red a la que ahora está conectado.
Aquí hay un extracto de nuestro archivo de configuración del servidor OpenVPN:
# Empujar la ruta al cliente para vincularlo a nuestro local # punto final virtual. # presione "ruta 10.180.0.1 255.255.255.255" # Empujar cualquier ruta que el cliente necesite para ingresar # a la red local. # presione "ruta 10.171.0.0 255.255.0.0" presione "ruta 10.172.0.0 255.255.0.0" presione "ruta 10.173.0.0 255.255.0.0" presione "ruta 10.174.0.0 255.255.0.0" presione "ruta 10.175.0.0 255.255.0.0" presione "ruta 10.176.0.0 255.255.0.0" presione "ruta 10.177.0.0 255.255.0.0" presione "ruta 10.181.0.0 255.255.0.0" presione "ruta 10.182.0.0 255.255.0.0" presione "ruta 192.168.61.0 255.255.255.0" # Enviar opciones de DHCP a clientes de Windows. # presione "opción-dhcp DOMINIO nuestro-dominio-interno.com" presione "opción dhcp DNS 10.abc" presione "opción dhcp WINS 10.bcd"
Todas estas son redes internas y ni siquiera implementamos una nueva puerta de enlace (como la mayoría de nuestros usuarios se conectan desde lejos, es mejor que accedan a Internet a través de su puerta de enlace predeterminada y nosotros no somos fanáticos del control).
Respuesta3
En realidad, el problema fue que NAT no estaba configurado correctamente. Se solucionó y la VPN está funcionando ahora.