Perte de connexion régulière VPNClient

Support
22

Bonjour,

Je rencontre le même problème depuis quelques semaines (pas de coupures tous les jours, mais régulièrement, de manière apparement assez aléatoire : parfois 1 fois en 2 semaines, parfois 2 fois en 2h). Une autre personne utilisant un VPN de chez Neutrinet l’avait eu précédemment (la solution avait été de réinstaller la brique from scratch).

Hier soir, j’ai finalement identifié ce qui suscite ce comportement entre les services hotspot et VPN, et dans quelles conditions le problème survient (en tous cas chez moi).

Reproduire le problème :

Chez moi, le problème survient quand différentes conditions sont réunies :

  • lorsque l’interface eth0 a “perdu” son IPv6 (alors qu’elle se voit assigner IPv4 et IPv6 au démarrage de la brique)
  • lorsque la brique subit une perte de connexion au niveau du réseau local (coupure au niveau du FAI (pas celui du VPN), ou retrait du câble au niveau de la box ou du switch)
  • lorsque ynh-vpnclient-checker.service s’active à ce moment-là et détecte la coupure (et donc, détecte le service vpn comme “failed”)
  • lorsqu’il y a de l’IPv6 sur l’interface du hotspot (ou au moins sur une des interfaces du hotspot, si plusieurs wifi sont actifs).

Voici à quoi ressemblent mes interfaces réseaux quand le problème est survenu :

admin@ytopia:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether *** brd ff:ff:ff:ff:ff:ff
    inet 192.xxx.xxx.xxx/24 brd 192.xxx.xxx.255 scope global dynamic eth0
       valid_lft 73596sec preferred_lft 73596sec
    inet6 fe80::xxxx:xxxx/128 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether *** brd ff:ff:ff:ff:ff:ff
    inet 10.0.xxx.xxx/24 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 2001:913:xxxx:xxxx::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
5: hotspot1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether *** brd ff:ff:ff:ff:ff:ff
    inet xxx.xxx.xxx.xxx/24 scope global hotspot1
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

Ici, j’ai deux interfaces wlan0 et hotspot1 qui correspondent à deux wifi. On constate que seule l’une des deux - wlan0 - a une IPv6 (c’est normal, l’autre wifi n’est configuré qu’en IPv4).

Et surtout, on constate qu’eth0 n’a qu’une adresse link-local et pas d’IPv6 routable assignée.

Ce qu’il se passe :

Dans ce cas de figure, ynh-vpnclient-checker.service détecte qu’il n’y a plus de connexion et arrête le service VPN. Il tente de le relancer par la suite à intervales réguilers mais cela échoue.

La raison pour laquelle le VPN ne parvient pas à se reconnecter est qu’il tente de joindre le service VPN en IPv6 plutôt qu’en IPv4 - ce qui forcément marche beaucoup moins bien puisque eth0 n’a plus d’IPv6.

Ce comportement ne semble s’appliquer que pour le serveur VPN, les autres domaines sont bien résolus en IPv4 par défaut :

admin@ytopia:~$ ping framasoft.org
PING framasoft.org (144.76.131.212) 56(84) bytes of data.
64 bytes from edna.framasoft.org (144.76.131.212): icmp_seq=1 ttl=56 time=27.3 ms
64 bytes from edna.framasoft.org (144.76.131.212): icmp_seq=2 ttl=56 time=26.5 ms
64 bytes from edna.framasoft.org (144.76.131.212): icmp_seq=3 ttl=56 time=26.2 ms
64 bytes from edna.framasoft.org (144.76.131.212): icmp_seq=4 ttl=56 time=25.9 ms
64 bytes from edna.framasoft.org (144.76.131.212): icmp_seq=5 ttl=56 time=26.0 ms
^C
--- framasoft.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 9ms
rtt min/avg/max/mdev = 25.890/26.372/27.325/0.546 ms


admin@ytopia:~$ ping -6 framasoft.org
connect: Network is unreachable

admin@ytopia:~$ ping vpn.neutrinet.be
PING vpn.neutrinet.be(dynamic-2001-0913-1000-0011-0000-0000-0000-0202.v6.reverse.neutri.net (2001:913:1000:11::202)) 56 data bytes
^C
--- vpn.neutrinet.be ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 178ms

admin@ytopia:~$ ping -4 vpn.neutrinet.be
PING vpn.neutrinet.be (80.67.181.20) 56(84) bytes of data.
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=1 ttl=58 time=10.1 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=2 ttl=58 time=9.45 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=3 ttl=58 time=9.63 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=4 ttl=58 time=9.91 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=5 ttl=58 time=9.71 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=6 ttl=58 time=10.1 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=7 ttl=58 time=10.4 ms
^C
--- vpn.neutrinet.be ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 15ms
rtt min/avg/max/mdev = 9.453/9.896/10.444/0.306 ms

La cause de ce comportement apparaît être l’IPv6 restée assignée à l’interface wlan0, qui, pour une raison ou une autre, force la résolution domaine en IPv6.

En effet, si on l’a supprime :

admin@ytopia:~$ sudo ip addr del 2001:913:xxxx:xxxx::1/64 dev wlan0

… et qu’on refait un ping vers vpn.neutrinet.be

admin@ytopia:~$ ping vpn.neutrinet.be    
PING vpn.neutrinet.be (80.67.181.20) 56(84) bytes of data.
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=1 ttl=58 time=10.5 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=2 ttl=58 time=10.3 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=3 ttl=58 time=10.0 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=4 ttl=58 time=9.80 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=5 ttl=58 time=163 ms
64 bytes from vpn.louise.neutri.net (80.67.181.20): icmp_seq=6 ttl=58 time=9.43 ms
^C
--- vpn.neutrinet.be ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 11ms
rtt min/avg/max/mdev = 9.432/35.456/162.637/56.878 ms
admin@ytopia:~$

La résolution du domaine se fait bien en IPv4 par défaut.

A ce moment-là, si on relance le VPN (ou qu’on attend que ynh-vpnclient-checker.service le relance), le VPN peut se reconnecter.

En fait, lorsqu’on arrête ynh-hotspot pour redémarrer le VPN, cela fonctionne parce qu’arrêter le hotspot supprime les données des interfaces réseaux liées au hotspot… et supprime donc cette IPv6 attachée à wlan0.

Questions en suspens à investiguer :

  1. Pourquoi et à quel moment, alors qu’IPv4 et IPv6 sont bien assignées au démarrage sur eth0, l’une des deux interfaces est supprimée de l’interface ?

  2. Pourquoi une IPv6 restée assignée à wlan0 force la résolution DNS du domaine du serveur VPN en IPv6 (et juste celle-là) même lorsque la connexion se fait via eth0 (et comment y remédier) ?

  3. Pourquoi certaines briques développent ce comportement et pas d’autres ?
    En sachant que ça ne semble pas être en lien à une version particulière de ynh-hotspot ou de ynh-vpnclient puisque l’autre personne de Neutrinet qui avait rencontré le problème avait commencé à l’avoir déjà en avril ou mai de l’année dernière (et pas de version testing sur aucune de nos brique)…

Pour la 2), une piste pour remédier au problème serait - à l’inverse - de forcer la résolution de vpn.neutrinet.be en IPv4 pour qu’elle se fasse ainsi dans tous les cas… Mais resolv.conf me signale " DO NOT EDIT THIS FILE BY HAND – YOUR CHANGES WILL BE OVERWRITTEN"… il faut donc voir où cette manip pourrait se faire sans que ça ne soit écrasé par une autre config… :face_with_monocle:

Et ça ne serait probablement pas une solution infaillible puisque j’ai déjà eu aussi chez moi des cas (plus rares) où la brique n’est même plus accessible en IPv4 sur le réseau local et où j’ai trouvé dans syslog :

Dec 17 20:41:35 ytopia avahi-daemon[522]: Withdrawing address record for xxx.xxx.xxx.xxx on eth0.
Dec 17 20:41:35 ytopia avahi-daemon[522]: Leaving mDNS multicast group on interface eth0.IPv4 with address xxx.xxx.xxx.xxx.
Dec 17 20:41:35 ytopia avahi-daemon[522]: Interface eth0.IPv4 no longer relevant for mDNS.
Dec 17 20:41:36 ytopia ntpd[6264]: Deleting interface #3 eth0, xxx.xxx.xxx.xxx#123, interface stats: received=362, sent=362, dropped=0, active_time=318030 secs
Dec 17 20:41:36 ytopia ntpd[6264]: xxx.xxx.xxx.1 local addr xxx.xxx.xxx.254 -> <null>

Ca me semble néanmoins quand même une piste à investiguer… pour réduire un peu le nombre de downtime de mon serveur mail… :sweat_smile:

1 Like