Perte de connexion régulière VPNClient

Toujours les problèmes de perte de connexion VPN avec la commande suivante, j’arrive à relancer la connexion VPN sans rebooter la machine :

systemctl stop ynh-hotspot.service && systemctl start ynh-vpnclient.service && systemctl start ynh-hotspot.service

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

Quelques observations complémentaires :

Sur le contexte

  • Le problème ne se présente pas si le wifi du hotspot n’a pas d’IPv6
  • Le problème ne se présente pas si la brique est connectée à un réseau local qui n’a que de l’IPv4.

Pour les personnes qui rencontrent le problème, une solution est donc de désactiver l’IPv6 du hotspot (en supprimant le préfixe dans le config panel de l’app et en rechargeant la configuration). Ou alors de supprimer l’IPv6 de son LAN ou de mettre de mettre en place un autre réseau sans IPv6 auquel connecter sa brique.

NB : Le problème est reproductible sur une brique fraichement installée (à confirmer néanmoins si elle a le comportement de “perdre” l’IPv6 assignée à son interface eth0, mais lorsqu’on supprime cette interface, et qu’on simule une perte de connexion, le problème se manifeste bien).

Sur le moment où cela arrive

  • Une activation de ynh-vpnclient-checker.service juste après la suppression de l’IPv6 sur eth0 peut également provoquer le problème.
  • Il semble que ce soit moins la coupure “physique” de connexion elle-même (par manque de connexion ou par suppression d’une adresse assignée sur eth0) que la détection de cette coupure par le système qui entraine le problème au moment où s’active ynh-vpnclient-checker.service.
    Je ne sais pas si j’emploie les bons mots, mais je constate qu’une activation du service pendant que le câble est débranché ne suffit pas, il faut aussi que l’interface tun0 soit supprimée. En effet, je constate que quand le câble est débranché (et donc que la coupure est simulée), il peut y avoir un moment où tun0 reste monté alors qu’il n’y a plus de connexion via eth0. Si ynh-vpnclient-checker.service se déclenche à ce moment-là, ça n’a pas d’effet et le VPN se reconnecte par la suite.
  • Je constate quelques cas où le problème ne se reproduit pas quand j’essaie de le reproduire.
    Il y a donc potentiellement un paramètre supplémentaire qui intervient que je n’ai pas encore identifié.

Sur le rôle de ynh-vpnclient-checker.service

  • Dans la même situation de connectivité, je constate une différence entre l’action de ynh-vpnclient-checker.service et un redémarrage du service VPN : si je redémarre ynh-vpnclient pendant une coupure ou après la suppression de tun0, le service apparaît toujours en fonctionnement dans l’interface de Yunhost et n’a pas le statut “Failed”.
    Le VPN n’a pas de difficultés à se reconnecter.
  • En revanche, l’action de ynh-vpnclient-checker.service entraine une situation où le service apparaît comme arrêté avec le statut “Failed”. C’est dans ce cas que le VPN ne parvient plus à se reconnecter.

Une piste pour résoudre le problème est donc peut-être à chercher du côté de ynh-vpnclient-checker.service.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.