1 votes

Håkon Hægland avatar

OpenVPN : La redirection du trafic ne fonctionne pas

Demandé el 19 de Mai, 2015
Quand la question a-t-elle été
648 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

en résumé (après des heures de débogage avec @krisFR) : Au moins sous Debian 8, n'utilisez jamais les interfaces virtuelles (eth0:1) pour OpenVPN, appliquez plutôt la nouvelle version debian iproute2 méthodes (approche manuelle) décrites ici : https://wiki.debian.org/NetworkConfiguration#iproute2_method . Il acheminera le trafic très bien.

J'essayais de configurer OpenVPN sur une machine où tout le trafic client devait être envoyé sur le tunnel, donc cela fait partie de la configuration de mon serveur :

local x.x.x.243
port 443
proto udp
dev tun
server 172.31.1.0 255.255.255.0 
push "redirect-gateway def1 bypass-dhcp"

Et la configuration de mon client :

pull
resolv-retry infinite
mute-replay-warnings 
redirect-gateway def1
script-security 1

Le client est en mesure de se connecter au VPN et peut envoyer un ping à l'hôte VPN à l'adresse suivante 172.31.1.1 Cependant, si j'essaie d'envoyer un ping à google.com par domaine ou IP, j'obtiens un message d'erreur. Request timeout for icmp_seq 0 message...

Quelle peut en être la cause ? Remarque : j'ai désinstallé tous les pare-feu et je règle actuellement IPTables sur :

iptables -A INPUT -i eth0:1 -m state --state NEW -p udp --dport 443 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0:1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0:1 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.31.1.0/24 -o eth0:1 -j MASQUERADE
iptables -A OUTPUT -o tun+ -j ACCEPT

Merci.

J'ai donc essayé de faire un ping sur le client 213.30.5.46 (une des IP de Google) et cela n'a pas fonctionné, mais j'ai obtenu ce résultat :

Écoute sur l'IP du VPN sortant (eth0:1) : tcpdump -i eth0 -t host x.x.x.243

IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 113
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP vpn.exampledomain.com.https > [CLIENT_IP x..].51060: UDP, length 81
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145

Au même moment, en écoutant sur tun0, j'ai eu ça : tcpdump -i tun0

23:40:39.864798 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 0, length 64
23:40:40.925951 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 256, length 64
23:40:41.886679 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 512, length 64
23:40:42.906125 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 768, length 64

Voici la sortie de iptables -L -n -v :

Chain INPUT (policy ACCEPT 34772 packets, 2265K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  eth0:1 *       0.0.0.0/0            0.0.0.0/0            state NEW udp dpt:443
   13  1092 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1437 96985 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tun+   eth0:1  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  eth0:1 tun+    0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 32574 packets, 7919K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   13  1092 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0

Note : /proc/sys/net/ipv4/ip_forward est réglé sur 1 .

Ciblé tcpdump -i eth0:1 -t host 213.30.5.46 pendant l'envoi de la destination :

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0:1, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 0, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 256, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 512, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 768, length 64

Rien ne s'affiche sur le client, le ping finit par s'arrêter.

L'adresse IP utilisée par OpenVPN local x.x.x.243 est configuré sur \etc\network\interfaces comme eth0:1 juste après eth0 comme :

 auto eth0:1
  iface eth0:1 inet static
   address x.x.x.243
   gateway x.x.x.129
   netmask 255.255.255.128
   dns-nameservers x.x.x.4 x.x.x.104
Demandé el 19 de Mai, 2015 par Håkon Hægland

Réponse

Trop de publicités?

2voto

krisFR avatar
krisFR Points 12580

Comme vous l'avez dit, nous passons des heures ensemble à déboguer cela...

Au vu de tous les tests que nous avons effectués et de toutes les traces que nous avons récupérées, il apparaît finalement que nous avions des comportements étranges concernant l'interface virtuelle. eth0:1 .

Par exemple : http://lartc.org/howto/lartc.iproute2.html

La plupart des distributions Linux, et la plupart des UNIX, utilisent actuellement le vénérable système arp, ifconfig et route. Bien que ces outils fonctionnent, ils montrent comportement inattendu sous Linux 2.2 et plus. Par exemple, les tunnels GRE font aujourd'hui partie intégrante du routage, mais nécessitent des outils complètement différents. des outils complètement différents.

Avec iproute2, les tunnels font partie intégrante de l'ensemble des outils.

Nous avons décidé de passer à iproute2 (essayez au moins) en modifiant /etc/network/interfaces pour changer la manière d'assigner plusieurs IPs à l'ordinateur. eth0 interface.

Après cela, tout s'est bien passé et a fonctionné !

iproute2 exemple :

auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 192.168.1.42
    netmask 255.255.255.0
    gateway 192.168.1.1

iface eth0 inet static
    address 192.168.1.43
    netmask 255.255.255.0

Plus d'informations sur iproute2 ici :

Répondu el 20 de Mai, 2015 par krisFR (12580 Points )

Questions en vedette

Top Tags

Dans notre réseau

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:

Yandex
X