Openvpn ne marche qu'en ipV6 mais pas en ipV4... !?!

oZen · Février 21, 2016, 10:03pm

Bonjour,

Voila quelques jours que je cherche à faire marcher “openvpn” sur ma jessie (updatée/upgradée tout bien, tout bien).

Il faut que je vous dise en préambule que mon “provider” de VPN, IPVanish, pour ne pas le citer, ne fournit pas de support ipV6…

Mais un truc plutôt curieux se produit. Il se trouve qu’openvpn en collaboration avec les serveurs d’IPVanish ne semble s’accommoder que de l’ipV6… Pas au comment de la connection au(x) server(s) (que j’ai testé(s) par dizaines), là tout se passe bien que je soit en ipV6 ou 4 mais c’est après que ça part en cacahuète:

Quand je suis donc connecté et en ipV6 no problème pour pinger un server quelconque faire un wget d’un fichier quelconque histoire de savoir ce que mon VPN à dans le ventre ou avoir tout autre activité sur internet.
Par contre ! Dès que je bascule en ipV4 sur la freebox ou que je désactive l’ipV6 dans sysctl.conf (l’effet est le même dans les faits). BIM ! Si la connexion au serveur vpn se fait correctement, après, impossible de pinger quoi que ce soit, idem pour wget, etc…

J’ai soulevé l’hypothèse suivante: En ipV6, je me vois attribué une ipV4, seul protocole géré par, IPVanish, du coup après avoir tenté de “résoudre” un serveur que je ping en ipV4, devant l’échec, le système doit basculer en ipV6 pour voir si la résolution DNS passe pas mieux par là. Et c’est effectivement le cas puisque c’est mon IP(V6) publique habituelle… Du coup mon VPN n’a absolument plus aucun intérêt. Rajoutez à ça les récents problèmes de “DNS leaks” et là c’est le pompon…

Moi je voudrais bien passer en ipV4 mais encore faudrait il que je le puisse !
Notez que mon Raspberry sous Raspbian à exactement le même comportement…

Si quelqu’un a un éclair de génie, je suis plus que preneur !
Merci d’avance !

PascalHambourg · Février 21, 2016, 10:03pm

Je trouve cette description confuse et manquant de faits concrets.
Serait-il possible de d’exposer en détail dans chaque configuration (IPv6 activé ou désactivé) :

les paramètres IPv4 et IPv6 avec [mono]ip addr ; ip -4 route ; ip -6 route[/mono],
le contenu du fichier /etc/resolv.conf,
les commandes exécutées et leurs résultats ?

oZen · Février 21, 2016, 10:03pm

Merci pour ta réponse !
Heu oui exact, un peu confus…

voila donc, en IPv6 activé d’abord:

ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:19:e3:62:c1:75 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:19:e3:08:e0:ee brd ff:ff:ff:ff:ff:ff inet 192.168.0.14/24 brd 192.168.0.255 scope global dynamic wlan0 valid_lft 862468sec preferred_lft 862468sec inet6 2a01:e35:2f4f:bc40:9f4:790b:8ec5:fe68/64 scope global temporary dynamic valid_lft 86386sec preferred_lft 84263sec inet6 2a01:e35:2f4f:bc40:219:e3ff:fe08:e0ee/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86386sec preferred_lft 86386sec inet6 fe80::219:e3ff:fe08:e0ee/64 scope link valid_lft forever preferred_lft forever

ip -4 route default via 192.168.0.254 dev wlan0 proto static metric 1024 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.14

ip -6 route 2a01:e35:2f4f:bc40::/64 dev wlan0 proto kernel metric 256 expires 86122sec fe80::/64 dev wlan0 proto kernel metric 256 mtu 1480 default via fe80::207:cbff:fe36:2697 dev wlan0 proto static metric 1024

Puis en IPv6 désactivé:

ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:19:e3:62:c1:75 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:19:e3:08:e0:ee brd ff:ff:ff:ff:ff:ff inet 192.168.0.13/24 brd 192.168.0.255 scope global dynamic wlan0 valid_lft 863844sec preferred_lft 863844sec inet6 fe80::219:e3ff:fe08:e0ee/64 scope link valid_lft forever preferred_lft forever

ip -4 route default via 192.168.0.254 dev wlan0 proto static metric 1024 169.254.0.0/16 dev wlan0 scope link metric 1000 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.13

ip -6 route fe80::/64 dev wlan0 proto kernel metric 256

Le contenu de /etv/resolv.conf:

# Generated by NetworkManager nameserver 212.27.40.240 nameserver 212.27.40.241
(A priori on est bien chez Free… Ici j’avais essayé de rajouter ceux de google, les fameux 8.8.8.8, mais sans succès pour mon affaire)

Et puis je lance openvpn de cette manière:

openvpn --config ipvanish-FR-Paris-par-a01.ovpn Mon Nov 9 22:55:02 2015 DEPRECATED OPTION: --tls-remote, please update your configuration Mon Nov 9 22:55:02 2015 OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec 1 2014 Mon Nov 9 22:55:02 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08 Mon Nov 9 22:55:02 2015 WARNING: file 'auth.txt' is group or others accessible Mon Nov 9 22:55:02 2015 Deprecated TLS cipher name 'DHE-RSA-AES256-SHA', please use IANA name 'TLS-DHE-RSA-WITH-AES-256-CBC-SHA' Mon Nov 9 22:55:02 2015 Deprecated TLS cipher name 'DHE-DSS-AES256-SHA', please use IANA name 'TLS-DHE-DSS-WITH-AES-256-CBC-SHA' Mon Nov 9 22:55:02 2015 Deprecated TLS cipher name 'AES256-SHA', please use IANA name 'TLS-RSA-WITH-AES-256-CBC-SHA' Mon Nov 9 22:55:02 2015 Socket Buffers: R=[212992->131072] S=[212992->131072] Mon Nov 9 22:55:02 2015 UDPv4 link local: [undef] Mon Nov 9 22:55:02 2015 UDPv4 link remote: [AF_INET]81.171.107.2:443 Mon Nov 9 22:55:02 2015 TLS: Initial packet from [AF_INET]81.171.107.2:443, sid=e168bf7e d4b6ce09 Mon Nov 9 22:55:02 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Mon Nov 9 22:55:03 2015 VERIFY OK: depth=1, /C=US/ST=FL/L=Winter_Park/O=IPVanish/OU=IPVanish_VPN/CN=IPVanish_CA/emailAddress=support@ipvanish.com Mon Nov 9 22:55:03 2015 VERIFY X509NAME OK: /C=US/ST=FL/L=Winter_Park/O=IPVanish/OU=IPVanish_VPN/CN=par-a01.ipvanish.com/emailAddress=support@ipvanish.com Mon Nov 9 22:55:03 2015 VERIFY OK: depth=0, /C=US/ST=FL/L=Winter_Park/O=IPVanish/OU=IPVanish_VPN/CN=par-a01.ipvanish.com/emailAddress=support@ipvanish.com Mon Nov 9 22:55:03 2015 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Mon Nov 9 22:55:03 2015 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Mon Nov 9 22:55:03 2015 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Mon Nov 9 22:55:03 2015 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Mon Nov 9 22:55:03 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Mon Nov 9 22:55:03 2015 [par-a01.ipvanish.com] Peer Connection Initiated with [AF_INET]81.171.107.2:443 Mon Nov 9 22:55:05 2015 SENT CONTROL [par-a01.ipvanish.com]: 'PUSH_REQUEST' (status=1) Mon Nov 9 22:55:05 2015 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 198.18.0.1,dhcp-option DNS 198.18.0.2,rcvbuf 262144,explicit-exit-notify 5,route-gateway 172.20.32.1,topology subnet,ping 20,ping-restart 40,ifconfig 172.20.32.182 255.255.252.0' Mon Nov 9 22:55:05 2015 OPTIONS IMPORT: timers and/or timeouts modified Mon Nov 9 22:55:05 2015 OPTIONS IMPORT: explicit notify parm(s) modified Mon Nov 9 22:55:05 2015 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified Mon Nov 9 22:55:05 2015 Socket Buffers: R=[131072->425984] S=[131072->131072] Mon Nov 9 22:55:05 2015 OPTIONS IMPORT: --ifconfig/up options modified Mon Nov 9 22:55:05 2015 OPTIONS IMPORT: route options modified Mon Nov 9 22:55:05 2015 OPTIONS IMPORT: route-related options modified Mon Nov 9 22:55:05 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Mon Nov 9 22:55:05 2015 ROUTE_GATEWAY 192.168.0.254/255.255.255.0 IFACE=wlan0 HWADDR=00:19:e3:08:e0:ee Mon Nov 9 22:55:05 2015 TUN/TAP device tun0 opened Mon Nov 9 22:55:05 2015 TUN/TAP TX queue length set to 100 Mon Nov 9 22:55:05 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mon Nov 9 22:55:05 2015 /sbin/ip link set dev tun0 up mtu 1500 Mon Nov 9 22:55:05 2015 /sbin/ip addr add dev tun0 172.20.32.182/22 broadcast 172.20.35.255 Mon Nov 9 22:55:05 2015 /sbin/ip route add 81.171.107.2/32 via 192.168.0.254 Mon Nov 9 22:55:05 2015 /sbin/ip route add 0.0.0.0/1 via 172.20.32.1 Mon Nov 9 22:55:05 2015 /sbin/ip route add 128.0.0.0/1 via 172.20.32.1 Mon Nov 9 22:55:05 2015 Initialization Sequence Completed

Mais en ipV6 désactivé ça me donne ça par exemple:

ping google.fr ping: unknown host google.fr

Voilà ça fait beaucoup de copier/coller, j’espère ne pas m’être trompé. N’hésitez pas à me demander si besoin…
Merci beaucoup d’avance !

PascalHambourg · Février 21, 2016, 10:03pm

J’aurais préféré les adresses, routes et DNS quand le VPN est monté.

Il y a des règles iptables ?
Que donnent les tests de connectivité IP (traceroute) vers des adresses, sans résolution DNS ?

oZen · Février 21, 2016, 10:03pm

[quote=“PascalHambourg”]J’aurais préféré les adresses, routes et DNS quand le VPN est monté.

Il y a des règles iptables ?
Que donnent les tests de connectivité IP (traceroute) vers des adresses, sans résolution DNS ?[/quote]

Ha bah oui, c’est un peu bête de ma part…

Alors non pas de règles iptables.
Pour le reste je recommence tout depuis le départ avec la connexion au VPN:

IPv6 activé:
/etc/resolv.conf:

[code]# Generated by NetworkManager
nameserver 212.27.40.240
nameserver 212.27.40.241
nameserver 2a01:e00::2

NOTE : il se peut que le solveur libc ne prenne pas en charge plus$

Les serveurs de noms listés ci-dessous peuvent ne pas être reconnu$

nameserver 2a01:e00::1[/code]

ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:19:e3:62:c1:75 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:19:e3:08:e0:ee brd ff:ff:ff:ff:ff:ff inet 192.168.0.12/24 brd 192.168.0.255 scope global dynamic wlan0 valid_lft 863599sec preferred_lft 863599sec inet6 2a01:e35:2f4f:bc40:4055:6a56:72d8:1c98/64 scope global temporary dynamic valid_lft 86372sec preferred_lft 85394sec inet6 2a01:e35:2f4f:bc40:219:e3ff:fe08:e0ee/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86372sec preferred_lft 86372sec inet6 fe80::219:e3ff:fe08:e0ee/64 scope link valid_lft forever preferred_lft forever 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 172.20.32.182/22 brd 172.20.35.255 scope global tun0 valid_lft forever preferred_lft forever

ip -4 route 0.0.0.0/1 via 172.20.32.1 dev tun0 default via 192.168.0.254 dev wlan0 proto static metric 1024 81.171.107.2 via 192.168.0.254 dev wlan0 128.0.0.0/1 via 172.20.32.1 dev tun0 172.20.32.0/22 dev tun0 proto kernel scope link src 172.20.32.182 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.12

ip -6 route 2a01:e35:2f4f:bc40::/64 dev wlan0 proto kernel metric 256 expires 85916sec fe80::/64 dev wlan0 proto kernel metric 256 mtu 1480 default via fe80::207:cbff:fe36:2697 dev wlan0 proto static metric 1024

traceroute google.fr traceroute to google.fr (216.58.211.99), 30 hops max, 60 byte packets 1 172.20.32.1 (172.20.32.1) 71.459 ms 71.635 ms 72.269 ms 2 81.171.106.241 (81.171.106.241) 73.696 ms 72.536 ms 74.759 ms 3 google.equinix-ix.fr (195.42.145.65) 73.074 ms 74.547 ms 74.731 ms 4 209.85.251.28 (209.85.251.28) 75.816 ms 75.771 ms 75.858 ms 5 72.14.233.83 (72.14.233.83) 79.340 ms 96.373 ms 97.998 ms 6 par03s15-in-f3.1e100.net (216.58.211.99) 104.045 ms 75.385 ms 76.565 ms

IPv6 désactivé:
/etc/resolv.conf:

ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:19:e3:62:c1:75 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:19:e3:08:e0:ee brd ff:ff:ff:ff:ff:ff inet 192.168.0.12/24 brd 192.168.0.255 scope global dynamic wlan0 valid_lft 863905sec preferred_lft 863905sec inet6 fe80::219:e3ff:fe08:e0ee/64 scope link valid_lft forever preferred_lft forever 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 172.20.32.182/22 brd 172.20.35.255 scope global tun0 valid_lft forever preferred_lft forever

ip -4 route 0.0.0.0/1 via 172.20.32.1 dev tun0 default via 192.168.0.254 dev wlan0 proto static metric 1024 81.171.107.2 via 192.168.0.254 dev wlan0 128.0.0.0/1 via 172.20.32.1 dev tun0 169.254.0.0/16 dev wlan0 scope link metric 1000 172.20.32.0/22 dev tun0 proto kernel scope link src 172.20.32.182 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.12

ip -6 route fe80::/64 dev wlan0 proto kernel metric 256

traceroute google.fr google.fr: Nom ou service inconnu Cannot handle "host" cmdline arg `google.fr' on position 1 (argc 1)

Merci encore pour ton aide

PascalHambourg · Février 21, 2016, 10:03pm

J’avais demandé un traceroute vers une adresse IPv4, pas vers un nom d’hôte puisqu’on savait déjà que la résolution DNS ne marchait pas.

D’après le résultat des commandes [mono]ip[/mono], la connectivité IPv4 (via le VPN) et IPv6 (via le FAI) devrait être présente. Par contre, le fichier [mono]/etc/resolv.conf[/mono] ne contient que des adresses de DNS du FAI, en IPv4 et en IPv6. Il est habituel que les FAI n’autorisent les requêtes DNS sur ces serveurs récursifs que depuis leurs clients. Or quand tu sors par le VPN, tu n’es pas considéré comme client de ton FAI (c’est un peu le but). Donc les requêtes DNS en IPv4 passant par le VPN échouent, tandis que les requêtes DNS en IPv6 passant par le FAI fonctionnent. Mais si tu désactives l’IPv6, il ne reste que les serveurs DNS en IPv4 qui ne répondent pas via le VPN.

Remarque :
Quand l’IPv6 est activé, tes requêtes DNS sortent en clair de ta box vers les serveurs DNS du FAI. Bonjour la confidentialité (quelqu’un a parlé de fuites DNS ?).
Sans oublier que tout site disponible en IPv6 est accédé par défaut en IPv6 (modifiable avec [mono]/etc/gai.conf[/mono]), donc hors du VPN.

Dans les logs d’openvpn je vois passer des adresses de DNS poussées par le serveur :

Mais on ne les retrouve pas dans le fichier [mono]/etc/resolv.conf[/mono] lorsque le VPN est monté. A noter que ce fichier est généré par NetworkManager, donc si tu ne lances pas openvpn via le plugin de NetworkManager, les modifications apportées au fichier directement par openvpn risquent d’être écrasées. Il faudrait essayer d’installer le paquet [mono]resolvconf[/mono] qui est suggéré par le paquet [mono]openvpn[/mono] et qui permet de gérer l’ensemble des sources de DNS.

oZen · Février 21, 2016, 10:03pm

Hop !

Le traceroute vers une IPv4:

traceroute 173.194.67.94 traceroute to 173.194.67.94 (173.194.67.94), 30 hops max, 60 byte packets 1 172.20.32.1 (172.20.32.1) 46.197 ms 48.412 ms 49.908 ms 2 81.171.106.241 (81.171.106.241) 69.378 ms 62.668 ms 63.112 ms 3 195.42.145.65 (195.42.145.65) 57.830 ms 57.090 ms 58.983 ms 4 209.85.251.28 (209.85.251.28) 62.022 ms 63.947 ms 69.167 ms 5 209.85.245.70 (209.85.245.70) 69.898 ms 209.85.245.83 (209.85.245.83) 69.920 ms 70.813 ms 6 209.85.242.229 (209.85.242.229) 74.995 ms 216.239.51.196 (216.239.51.196) 145.370 ms 216.239.51.110 (216.239.51.110) 82.322 ms 7 * 216.239.51.153 (216.239.51.153) 172.689 ms * 8 * * * 9 173.194.67.94 (173.194.67.94) 64.939 ms 66.018 ms 67.268 ms

Ca semble confirmer tes soupçons si je comprends un minimum ce que tu me racontes.

Je vais m’intéresser à resolvconf et essayer de comprendre comment ça marche et ça pourrait m’aider.
Merci pour ton aide à toi en tous les cas

GOGI · Février 21, 2016, 10:03pm

Salut,

J’ai eu à peu de choses près le même souci que toi, sauf que chez moi c’est l’inverse.
Essaies de configurer tes connexions VPN à travers Network-Manager depuis le menu en haut à droite sur ton bureau (là où tu vas pour éteindre ton PC par exemple, mais dans la section réseau, tu peux trouver des tutoriels sur internet). Ils seront d’autant plus faciles d’accès lorsque tu voudras te connecter plutôt que de taper à chaque fois dans la console…

Et tu peux t’appuyer également sur ce post pour ta machine, chez moi ça a marché comme ça : https://www.debian-fr.org/mise-a-jour-debian-derriere-un-vpn-t53661.html en ajoutant quelques lignes à [mono]/etc/sysctl.conf[/mono].
Sinon désactiver l’IPv6 au niveau de la Freebox où dans les paramètres de tes connexions en glissant le bouton dans l’onglet IPv6 ne suffit pas, ça ne marche pas. D’ailleurs tu peux voir que même en IPv6 “désactivé” tu as “inet6” qui traîne dans les retours console.

PascalHambourg · Février 21, 2016, 10:03pm

Voilà, c’est pareil sauf qu’en fait c’est l’inverse. Bref, c’est complètement différent.
Dans ton cas, une route IPv6 défaut vers le VPN qui est en fait un trou noir.
Dans son cas, la non modification de resolv.conf par le VPN (anormal) et les DNS du FAI injoignables via le VPN (normal).
Désactiver l’IPv6 ne résoudra pas son problème. Au contraire, il le provoque.

Le seul point commun entre vos deux problèmes, c’est qu’ils sont révélateurs des fuites par IPv6 ou DNS.