52 votes

Acheminer tout le trafic via OpenVPN

Oui, cette question a été posée des centaines de fois, et j'ai cherché partout, en vain.

Le titre dit tout, en fait.

J'ai un serveur OpenVPN (sur ubuntu), et je peux m'y connecter via mon client (Windows 8) ...

Le problème commence lorsque j'essaie d'acheminer TOUT le trafic via le VPN.

J'ai ajouté le push dans le fichier server.conf :

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

Lorsque je me connecte à partir du client, le client sort :

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

J'ai essayé d'utiliser les drapeaux côté client lors de l'ouverture de la connexion :

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

Mais quand je vais sur whatsmyip.org, c'est toujours l'ip de mon client qui s'affiche.

Quelqu'un a-t-il rencontré ce problème et réussi à le résoudre ?

Merci beaucoup

49voto

cioby23 Points 2475

J'ai testé cela en utilisant un serveur OpenVPN et en configurant la fonction redirect-gateway def1 dans la configuration du client et du serveur fonctionne correctement.

Lorsque j'accède à whatismyip.org Je vois l'IP de mon serveur OpenVPN.

Voici la configuration client que j'utilise :

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

J'ai également testé en ajoutant l'option redirect-gateway def1 à la commande openvpn et j'ai obtenu le même résultat. La configuration du serveur est :

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

30voto

httpete Points 121

Peut-être avez-vous oublié de modifier votre NAT ? Exécutez ces 3 commandes en tant que root

Commandes :

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

Légende :

  • tun0 : votre carte réseau VPN virtuelle
  • eth0 : votre carte réseau normale
  • 10.8.0.0 : bloc d'ip de votre réseau VPN

1voto

xrobot Points 11

Après avoir longuement cherché la réponse, il semble que j'aie résolu le problème, peut-être partiellement, mais au moins très simplement :

J'utilise Xubuntu 14.04 et le paquet OpenVPN de la source principale. En ce qui concerne Réglages > Système > Réseau J'ai remplacé l'adresse DNS préinstallée par l'adresse suivante 127.0.1.1 avec Google 8.8.8.8 et je peux maintenant voir tout le trafic qui passe par le serveur VPN.

Dans le tableau de Wireshark, une chaîne telle que DNS est absente : toutes les données passent comme TCP par un canal crypté. Je peux voir le trafic DHCP et DNS lorsque je regarde la page tun0 (interne du carnet). Lorsque j'explore wlan0 (externe entre l'ordinateur portable et le routeur WiFi), je n'obtiens que des paquets TCP gris.

Je pense que cela se produit parce que la requête DNS n'est pas nécessaire dans le décodage des caractères en nombres et qu'elle passe dans le flux commun comme un paquet de données habituel.

Je serais heureux de connaître vos considérations, il ne serait pas surprenant que je me trompe complètement.

1voto

J'ai rencontré le même problème et j'ai découvert qu'en utilisant le setup PiVPN script pour Open VPN, la configuration du serveur contient la ligne :

push "redirect-gateway def1 bypass-dhcp"

déjà. Sur le client IOS, tout est routé à travers le tunnel automatiquement (c'est ce que dit le journal).

Sur le client Tunnelblick, vous devez ajouter cette ligne dans le fichier client.ovpn fichier :

redirect-gateway def1 bypass-dhcp

et il devrait fonctionner parfaitement. C'est en tout cas ce qui s'est passé sur mon Mac.

0voto

Usman Ali Maan Points 11

Côté serveur, trouver server.conf et d'y ajouter cette ligne

push "redirect-gateway autolocal"

Il redirigera tout le trafic côté client à travers le tunnel.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X