47 votos

Dirigir todo el tráfico a través de OpenVPN

Sí, esta pregunta se ha hecho cientos de veces, y he buscado por todas partes, sin éxito.

El título lo dice todo realmente.

Tengo un servidor OpenVPN (En ubuntu), y puedo conectarme a él a través de mi cliente (Windows 8) ...

El problema comienza cuando trato de enrutar TODO el tráfico a través de la VPN.

He añadido el push banderas en server.conf:

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

Cuando me conecto desde el cliente, el cliente sale:

Wed May 07 21:38:40 2014 SENT CONTROL [StretchVPN-CA]: 'PUSH_REQUEST' (status=1)
Wed May 07 21:38:41 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,route-gateway <Remote Router IP>,ping 10,ping-restart 120,ifconfig 192.168.0.201 255.255.255.0'
Wed May 07 21:38:41 2014 OPTIONS IMPORT: timers and/or timeouts modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ifconfig/up options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route-related options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed May 07 21:38:41 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed May 07 21:38:41 2014 open_tun, tt->ipv6=0
Wed May 07 21:38:41 2014 TAP-WIN32 device [Local Area Connection 4] opened: \\.\Global\{1F145805-92FC-454E-8FD9-0A6017DD4AD1}.tap
Wed May 07 21:38:41 2014 TAP-Windows Driver Version 9.9
Wed May 07 21:38:41 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.0.201/255.255.255.0 on interface {1F145805-92FC-454E-8FD9-0A6017DD4AD1} [DHCP-serv: 192.168.0.0, lease-time: 31536000]
Wed May 07 21:38:41 2014 Successful ARP Flush on interface [35] {1F145805-92FC-454E-8FD9-0A6017DD4AD1}
Wed May 07 21:38:46 2014 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD <Remote Router IP> MASK 255.255.255.255 172.20.10.1
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 Initialization Sequence Completed

He intentado usar las banderas del lado del cliente al abrir la conexión:

openvpn --config "C:\Program Files\OpenVPN\config\client.ovpn" --redirect-gateway def1 --route-method exe

Pero aún así, cuando voy a whatsmyip.org, todavía dice que mis clientes ip.

¿Alguien ha tenido este problema y ha logrado resolverlo?

Muchas gracias.

0 votos

¿Intentaste push "route 0.0.0.0 0.0.0.0" ¿o similar a las rutas de empuje? ¡No olvides la ruta de vuelta en el VPN!

0 votos

Sí, esto se hace automáticamente cuando se utiliza el push "redirect-gateway def1" ... Añade la máscara 0.0.0 127.0.0 y la máscara 127.0.0.0 127.0.0 (superando la ruta por defecto sin borrar la que ya existe)

0 votos

Me preocupa si está ejecutando el cliente como "Ejecutar como administrador" en Windows. Este problema puede ocurrir si se ejecuta el cliente OVPN Windows sin la ejecución del administrador.

46voto

cioby23 Puntos 1517

He probado esto usando un servidor OpenVPN y configurando el redirect-gateway def1 en la configuración del cliente y del servidor funciona bien.

Cuando accedo a whatismyip.org Veo la IP de mi servidor OpenVPN.

A continuación se muestra la configuración del cliente que utilizo:

client
dev tun
proto udp
# THE IP OF THE REMOTE OPENVPN SERVER:
remote ip_address port
resolv-retry infinite
nobind
persist-key
persist-tun
# THE CSR FILE:
pkcs12 certificate.p12
ns-cert-type server
cipher AES-256-CBC
comp-lzo
redirect-gateway def1
verb 3

He probado también añadiendo la opción redirect-gateway def1 al comando openvpn y he conseguido el mismo resultado. La configuración del servidor es:

port 1194
proto udp
dev tun

dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ca /etc/openvpn/easy-rsa/keys/ca.crt
# ENSURE THE DOMAIN NAME/FILENAME IS CORRECT:
cert /etc/openvpn/easy-rsa/keys/cert.crt
key /etc/openvpn/easy-rsa/keys/cert.key

server 10.5.3.0  255.255.255.0
# YOUR LOCAL SERVER IP HERE:
client-config-dir ccd
route 10.5.3.0 255.255.255.0
ifconfig-pool-persist ipp.txt
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun

status log/openvpn-status.log 5
status-version 2
log-append log/openvpn.log
verb 3  # verbose mode
management localhost port /etc/openvpn/management-password

# ROUTE THE CLIENT'S INTERNET ACCESS THROUGH THIS SERVER:
push "redirect-gateway def1"
push "remote-gateway vpn_server_ip"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 60

0 votos

Lo he intentado hoy... Todavía no hay suerte. Me he dado cuenta de que estás usando un adaptador TUN en lugar de un adaptador TAP ... Lo intentaré y te informaré :D

1 votos

Okie, el uso de un adaptador TUN parece estar funcionando ... Aunque me están dando un poco de problemas las rutas que tengo que asignar ... Estoy usando 192.168.1.0/24 para la red VPN, y 192.168.0.0/24 es mi LAN del servidor. Así que en mi configuración del servidor, he añadido route 192.168.1.0 255.255.255.0 y push "route 192.168.0.0 255.255.255.0" pero mi cliente no tiene acceso a ninguna otra subred aparte de su red 192.168.1.0/24 ... Voy a hurgar un poco más

0 votos

Opción "remote-gateway" no reconocida o faltan parámetros extra :/

29voto

httpete Puntos 111

¿Tal vez se olvidó de modificar su NAT? Ejecute estos 3 comandos como root

Comandos:

iptables -I FORWARD -i tun0 -o eth0 \
         -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
         -j ACCEPT

iptables -t nat -I POSTROUTING -o eth0 \
          -s 10.8.0.0/24 -j MASQUERADE

Título:

  • tun0: su tarjeta de red virtual VPN
  • eth0: su tarjeta de red normal
  • 10.8.0.0: su bloque de ip de la red VPN

2 votos

Este paso de modificación de la NAT es muy importante. No he podido conseguir que esto funcione sin ejecutar los 3 comandos anteriores.

7 votos

Tenga en cuenta que estos comandos deben ejecutarse en el servidor openvpn, no en el cliente.

1 votos

He comprobado que sólo modificando el nat tabla también estaba trabajando en mi servidor.

4voto

Pol Hallen Puntos 116

Añada la siguiente directiva al archivo de configuración del servidor:

push "redirect-gateway def1"

Si la configuración de su VPN es a través de una red inalámbrica, donde todos los clientes y el servidor están en la misma subred inalámbrica, añada la flag local:

push "redirect-gateway local def1"

La opción redirect-gateway para los clientes hará que todo el tráfico de red IP que se origine en las máquinas de los clientes pase a través del servidor OpenVPN. El servidor tendrá que ser configurado para lidiar con este tráfico de alguna manera, como por ejemplo NATing a Internet, o el enrutamiento a través del proxy HTTP del sitio del servidor.

En Linux, puede utilizar un comando como este para NAT el tráfico del cliente VPN a Internet:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Este comando asume que la subred VPN es 10.8.0.0/24 (tomada de la directiva del servidor en la configuración del servidor OpenVPN) y que la interfaz ethernet local es eth0.

Cuando se utiliza redirect-gateway, los clientes de OpenVPN enrutarán las consultas DNS a través de la VPN, y el servidor VPN tendrá que gestionarlas. Esto se puede conseguir enviando una dirección de servidor DNS a los clientes que se conecten, que sustituirá su configuración normal de servidor DNS durante el tiempo que la VPN esté activa. Por ejemplo:

push "dhcp-option DNS 10.8.0.1"

configurará a los clientes de Windows (o a los clientes que no son de Windows con algún script extra del lado del cliente) para que usen 10.8.0.1 como su servidor DNS. Cualquier dirección que sea alcanzable desde los clientes puede ser utilizada como dirección del servidor DNS.

1voto

xrobot Puntos 1

Después de una ardua búsqueda de la respuesta parece que he resuelto esto, tal vez parcialmente, pero al menos de forma muy sencilla:

Uso Xubuntu 14.04 y el paquete OpenVPN de la fuente principal. En Configuración > Sistema > Red He sustituido la dirección DNS preinstalada 127.0.1.1 con Google 8.8.8.8 y ahora puedo ver todo el tráfico que pasa por el servidor VPN.

En la tabla de Wireshark tal cadena como DNS está ausente: todos los datos van como TCP a través del canal encriptado. Puedo ver el tráfico DHCP y DNS cuando miro tun0 (interno del cuaderno). Cuando exploro wlan0 tráfico (externo entre el portátil y el router WiFi) sólo obtengo paquetes TCP grises.

Creo que ocurre porque la consulta DNS no es necesaria en la decodificación de caracteres a números y va en el flujo común como un paquete de datos habitual.

Estaré encantado de conocer sus consideraciones, no será sorpresa si estoy completamente equivocado

0 votos

Se me olvidaba: este método tiene una ventaja indiscutible: funciona incluso si un servidor VPN no soporta el enrutamiento DNS.

0 votos

Por cierto, podríamos hacer un truco: si enviamos de vez en cuando falsas consultas DNS visibles e inocentes, indirectamente podría ser la confirmación de nuestra lealtad al Gran Hermano.

1voto

Me enfrenté al mismo problema y descubrí que cuando se utiliza la configuración PiVPN script para Open VPN, la configuración del servidor contiene la línea:

push "redirect-gateway def1 bypass-dhcp"

ya. En el cliente IOS todo se enruta a través del túnel automáticamente (eso es lo que dice el registro).

En el cliente de Tunnelblick debe añadir esta línea en el archivo client.ovpn archivo:

redirect-gateway def1 bypass-dhcp

y debería funcionar perfectamente. Al menos lo hizo en mi Mac.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X