Routez tout le trafic via OpenVPN

39

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

Le titre dit tout, vraiment.

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

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

J'ai ajouté les pushdrapeaux dans server.conf:

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

Lorsque je me connecte à partir du client, le client génère:

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 indicateurs 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 même, quand je vais sur whatsmyip.org, il est toujours indiqué que mes clients sont ip.

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

Merci beaucoup

vpn openvpn Vraiment chanceux
la source
Avez-vous essayé push "route 0.0.0.0 0.0.0.0"ou similaire de pousser des itinéraires? N'oubliez pas le parcours dans le VPN!
lub
Oui, cela se fait automatiquement quand on utilise le push "redirect-gateway def1" ... Il ajoute 0.0.0.0 mask 127.0.0.0 et 127.0.0.0 mask 127.0.0.0 (dépassant la route par défaut sans supprimer celle déjà présente)
Juste Chanceux vraiment
Je suis préoccupé si vous exécutez le client en tant que "Exécuter en tant qu'administrateur" dans Windows! Ce problème peut survenir si vous exécutez le client Windows OVPN sans exécuter l'administrateur.
Kousha

Réponses:

35

J'ai testé cela en utilisant un serveur OpenVPN et en configurant l'option def1 de la passerelle de redirection dans la configuration client et serveur fonctionne bien. Lorsque j'accède à whatismyip.org, je vois l'adresse IP de mon serveur OpenVPN. Ci-dessous 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é avec l'option de redirection-passerelle def1 ajoutée à la commande openvpn et 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
cioby23
la source
J'ai essayé ça aujourd'hui ... Toujours pas de chance. Je remarque que vous utilisez un adaptateur TUN plutôt qu'un adaptateur TAP ... Je vais plutôt tenter cela et vous faire rapport: D
Vraiment chanceux
1
OK, utiliser un adaptateur TUN semble fonctionner ... Bien que les routes que je dois attribuer me troublent un peu ... J'utilise 192.168.1.0/24 pour le réseau VPN et 192.168.0.0/ 24 est mon serveur LAN. Donc, dans la configuration de mon serveur, j'ai ajouté route 192.168.1.0 255.255.255.0et, push "route 192.168.0.0 255.255.255.0"mais mon client n'a accès à aucun autre sous-réseau, mis à part le réseau 192.168.1.0/24 ... Je vais en parler un peu plus
Just Lucky Really
20

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 virtuelle VPN
  • eth0: votre carte réseau normale
  • 10.8.0.0: votre bloc IP de réseau VPN
chickahoona
la source
1
Cette étape de modification NAT est très cruciale. Je ne pouvais tout simplement pas que cela fonctionne sans exécuter les 3 commandes ci-dessus.
Nitesh Kumar Anand
6
notez que ces commandes doivent être exécutées sur le serveur openvpn, pas sur le client.
Kem Mason
1
J'ai constaté que seule la modification de la nattable fonctionnait également sur mon serveur.
Ginhing
1
Devons-nous conserver les règles iptables au cas où le serveur openVPN serait redémarré?
Dwils
@DWils Oui, vous devez les mettre dans un script de démarrage. Consultez cette question: askubuntu.com/questions/270693/…
Arne
1

Après une recherche difficile de la réponse, il semble que j'ai résolu ce problème, peut-être partiellement, mais au moins très simplement:

J'utilise les packages Xubuntu 14.04 et OpenVPN à partir de la source principale. Dans Paramètres> Système> Réseau , j'ai remplacé l'adresse DNS préinstallée 127.0.1.1par celle de Google 8.8.8.8. À présent, je peux voir tout le trafic transitant par le serveur VPN.

Dans la table de Wireshark, une chaîne telle que DNS est absente: toutes les données passent comme un canal crypté via TCP. Je peux voir le trafic DHCP et DNS quand je regarde tun0(interne du cahier). Lorsque j'explore le wlan0trafic (externe entre l'ordinateur portable et le routeur WiFi), je ne reçois 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 de caractères en chiffres et qu'elle va dans le flux commun comme un paquet de données habituel.

Je serai heureux de connaître vos considérations, ce ne sera pas une surprise si je me trompe complètement

Xrobot
la source
J'ai oublié: cette méthode présente un avantage indiscutable: elle fonctionne même si un serveur VPN ne prend pas en charge le réacheminement DNS.
xrobot
En passant, nous pourrions faire une astuce: si nous envoyons de temps en temps de fausses requêtes DNS innocentes visibles, indirectement, cela pourrait être une confirmation de notre fidélité au Big Brother.
xrobot
1

Ajoutez la directive suivante au fichier de configuration du serveur:

push "redirect-gateway def1"

Si votre configuration VPN est sur un réseau sans fil, où tous les clients et le serveur sont sur le même sous-réseau sans fil, ajoutez l'indicateur local:

push "redirect-gateway local def1"

En poussant l'option de passerelle de redirection vers les clients, tout le trafic réseau IP provenant des ordinateurs clients passera par le serveur OpenVPN. Le serveur devra être configuré pour gérer ce trafic d'une manière ou d'une autre, par exemple en le mettant en NAT sur Internet ou en le routant via le proxy HTTP du site du serveur.

Sous Linux, vous pouvez utiliser une commande telle que celle-ci pour NAT le trafic du client VPN sur Internet:

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

Cette commande suppose que le sous-réseau VPN est 10.8.0.0/24 (tiré de la directive server de la configuration du serveur OpenVPN) et que l'interface Ethernet locale est eth0.

Lorsque la passerelle de redirection est utilisée, les clients OpenVPN acheminent les requêtes DNS via le VPN, et le serveur VPN doit les gérer. Cela peut être accompli en transmettant une adresse de serveur DNS à la connexion des clients, qui remplacera leurs paramètres de serveur DNS normaux pendant la période d'activation du VPN. Par exemple:

push "dhcp-option DNS 10.8.0.1"

configurera les clients Windows (ou les clients non-Windows avec des scripts supplémentaires côté client) pour utiliser 10.8.0.1 comme serveur DNS. Toute adresse accessible depuis les clients peut être utilisée comme adresse du serveur DNS.

Pol Hallen
la source
0

Si votre client OpenVPN est sous Windows 10 (ou similaire), il existe un autre problème à surveiller: l'ordre de liaison des cartes réseau. Les paramètres de serveur DNS existants sur l'adaptateur LAN ou Wifi peuvent avoir la priorité sur ceux du serveur DNS pour l'interface de tunnel. Ainsi, même si tout est configuré correctement d'un point de vue OpenVPN, Windows continue d'utiliser le serveur DNS d'origine.

Vous pouvez résoudre ce problème comme décrit dans cet article du forum Microsoft.

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

JudgedByDredd
la source
pas une réponse à la question
pim
0

J'ai rencontré le même problème et découvert lors de l'utilisation du script de configuration PiVPN pour Open VPN, la configuration du serveur contient la ligne suivante:

appuyez sur "redirect-gateway def1 bypass-dhcp"

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

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

passerelle de redirection def1 bypass-dhcp

et cela devrait fonctionner parfaitement. Au moins c'est ce qui s'est passé sur mon Mac.

Peter
la source