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

Sí, esta pregunta se ha hecho cientos de veces, y he buscado en 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 intento enrutar TODO el tráfico a través de la VPN.

He agregado las pushbanderas en server.conf:

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

Cuando me conecto desde el cliente, el cliente genera:

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

Intenté usar las banderas en el 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

He probado esto usando un servidor OpenVPN y configurando la opción redirect-gateway def1 en la configuración del cliente y el 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 uso:

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

También lo probé con la opción de redirección de puerta de enlace def1 agregada al comando openvpn y obtuve 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

¿Quizás olvidó modificar su NAT? Ejecute esos 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

Subtítulo:

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

Después de buscar la respuesta, parece que he resuelto esto, tal vez parcialmente, pero al menos de manera muy simple:

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

En la tabla de Wireshark, tales cadenas como DNS están ausentes: 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 portátil). Cuando exploro el wlan0tráfico (externo entre el portátil y el enrutador WiFi) solo obtengo paquetes TCP grises.

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

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

Agregue la siguiente directiva al archivo de configuración del servidor:

push "redirect-gateway def1"

Si su configuración de VPN está en una red inalámbrica, donde todos los clientes y el servidor están en la misma subred inalámbrica, agregue la bandera local:

push "redirect-gateway local def1"

Al presionar la opción de redirección de puerta de enlace a los clientes, todo el tráfico de red IP que se origina en las máquinas del cliente pasa a través del servidor OpenVPN. El servidor deberá estar configurado para manejar este tráfico de alguna manera, como por ejemplo, conectándolo a Internet o enrutando a través del proxy HTTP del sitio del servidor.

En Linux, puede usar 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 supone 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 de 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 deberá manejarlas. Esto se puede lograr mediante la inserción de una dirección de servidor DNS para conectar clientes que reemplazarán la configuración normal del servidor DNS durante el tiempo que la VPN esté activa. Por ejemplo:

push "dhcp-option DNS 10.8.0.1"

configurará clientes de Windows (o clientes que no sean de Windows con algunas secuencias de comandos adicionales del lado del cliente) para usar 10.8.0.1 como su servidor DNS. Cualquier dirección que sea accesible desde los clientes puede usarse como la dirección del servidor DNS.

Si su cliente OpenVPN está en Windows 10 (o similar) hay otro problema a tener en cuenta, el orden vinculante de las NIC. La configuración del servidor DNS existente en el adaptador LAN o Wifi puede tener prioridad sobre la configuración del servidor DNS para la interfaz del túnel, por lo que a pesar de que todo está configurado correctamente desde un punto de vista OpenVPN, Windows continúa utilizando el servidor DNS original.

Puede arreglar esto como se describe en esta publicación del foro de Microsoft.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/1cc5b647-6e51-482b-8998-ac5c3900938c/how-to-force-vpn-clients-to-use-the-dnsserver-from- its-vpn-adapter-not-the-dnsserver-from-their? forum = winserverNIS

Enfrenté el mismo problema y descubrí que cuando usaba el script de configuración PiVPN para Open VPN, la configuración del servidor contiene la línea:

presione "redirect-gateway def1 bypass-dhcp"

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

En el cliente Tunnelblick necesita agregar esta línea en el cliente.ovpn la línea:

redirect-gateway def1 bypass-dhcp

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