Pourquoi votre VPN tombe quand le Wi-Fi change ou qu’un câble Ethernet est branché
'Un nouvel SSID, une itinérance entre points d’accès et un câble branché cassent un tunnel à trois endroits différents. Vérifiez l’adresse source, puis la route, puis le protocole.'
Deux choses sont signalées comme une seule panne : l’ordinateur portable est passé sur un autre réseau Wi-Fi, ou un câble a été branché alors que le Wi-Fi restait actif. Le client affiche toujours connecté, l’icône semble saine, et le tunnel ne transporte rien. En dessous, seules trois pièces d’état peuvent bouger - la liaison, l’adresse locale, la route par défaut - et c’est celle qui a bougé qui décide si le tunnel se rétablit seul ou exige une reconnexion. Je les vérifie dans cet ordre, parce que modifier les paramètres du compte n’en a jamais réparé aucune.
Liaison, adresse et route bougent indépendamment
L’itinérance entre points d’accès d’un même réseau est généralement un événement de couche 2. La radio se réassocie, l’interface conserve son adresse et sa passerelle, et rien de ce dont dépend le tunnel ne change, ce qui explique qu’une traversée de grand bureau passe parfois inaperçue. Rejoindre un autre SSID n’est pas cela : l’ancienne interface peut tomber, le DHCP attribue une nouvelle adresse, une nouvelle passerelle et de nouveaux résolveurs, et le flux externe qu’utilisait le tunnel cesse d’exister.
L’Ethernet ajoute une troisième forme. Le Wi-Fi ne tombe jamais, donc aucun événement de liaison ne se déclenche, mais l’interface filaire apparaît avec sa propre adresse et gagne souvent la route par défaut sur la métrique. Le tunnel continue sur un chemin qui n’est plus préféré, ou le client garde son socket épinglé au réseau sans fil sur lequel il a démarré. Depuis le navigateur, les deux se ressemblent : les pages se figent à l’instant où le câble s’enclenche.
La première question n’est donc pas de savoir si le Wi-Fi a changé. Elle est de savoir si l’adresse à laquelle vous êtes lié, ou la route vers le point de sortie, a changé pendant que le tunnel était actif.
Le socket externe est épinglé à une adresse qui vient de disparaître
Chaque tunnel est un flux externe : une adresse et un port locaux qui parlent à l’adresse et au port du serveur. Sous Linux, c’est un socket UDP lié à l’ancienne source ; quand l’interface qui porte l’adresse est retirée, les envois échouent avec EADDRNOTAVAIL ou sortent par la nouvelle interface avec une source que le serveur n’a jamais vue.
Le côté distant garde son propre épinglage. Une SA IKEv2 sans MOBIKE est identifiée par la paire d’adresses, et une session OpenVPN est liée à l’adresse du pair qu’elle a apprise, et un mappage NAT appartient à l’adresse privée, au port et à l’adresse publique qui l’ont créé. Passez derrière un autre NAT et chaque réponse part vers un mappage qui n’existe plus. Rien n’est mal configuré sur votre machine ; le quintuplet pointe vers un réseau que vous avez quitté.
Lisez l’état avant de théoriser :
ss -unpaffiche l’adresse et le port locaux que chaque socket de tunnel détient réellement.ip route get 203.0.113.10imprime l’adresse source et l’interface que le noyau utiliserait pour le point de sortie à cet instant.wg show wg0 endpoints,swanctl --list-sasou le journal du client montre l’adresse du pair à laquelle le côté distant croit parler.
Si l’adresse du socket et la recherche de route ne concordent pas, vous avez trouvé la rupture, et aucun changement d’identifiants n’y touchera.
Ce que chaque protocole fait d’une nouvelle adresse source
Les clients absorbent le changement à des degrés divers, et le tableau est ce que je compare à la configuration du client plutôt que de deviner d’après le comportement de reconnexion.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
La règle d’itinérance de WireGuard ne fonctionne que dans un sens : le client doit d’abord émettre depuis la nouvelle adresse. Un socket encore lié à l’ancienne interface ne le fait jamais, ce qui explique qu’un tunnel puisse sembler vivant pendant que son minuteur de poignée de main vieillit. description du protocole énonce précisément la condition de mise à jour du point de sortie, et cela vaut la peine d’être lu avant de modifier une configuration.
MOBIKE se négocie, il ne se suppose pas. Si le serveur ne le propose pas, le client doit rétablir, et c’est un fait que vous confirmez depuis la liste des SA ou le journal plutôt que d’un indicateur qui tourne.
La préférence de route décide du chemin, pas l’icône Wi-Fi
Les deux interfaces étant actives, le noyau choisit selon la métrique et la longueur de préfixe. ip route show default liste les candidats et ip route get 203.0.113.10 tranche la décision réelle, y compris l’adresse source. Une route par défaut filaire à la métrique 100 et une sans fil à 600 signifient que le point de sortie bouge à l’instant où le câble s’enclenche, tandis que chaque application qui a ouvert un socket plus tôt garde son ancienne source.
Windows fait de même avec des métriques d’interface automatiques, biaisées par la vitesse de la liaison. Get-NetRoute -DestinationPrefix 0.0.0.0/0 trie les candidats et Find-NetRoute -RemoteIPAddress 203.0.113.10 renvoie l’interface et la source que la pile choisirait. Un client qui lie son socket externe à une interface continue de l’utiliser après le basculement de la métrique ; c’est une décision de liaison, pas un défaut de routage.
Android rend la séparation visible : ConnectivityManager signale les réseaux disponibles et une valeur par défaut distincte, et une application VPN qui lie un socket à un objet Network conserve ce lien jusqu’à le refaire. Sous macOS, scutil --nwi imprime l’interface principale et l’ordre que le système utiliserait.
DNS, MTU et IPv6 bougent avec le rattachement
Un nouveau rattachement apporte de nouveaux résolveurs. Avec systemd-resolved, le DNS est par liaison, resolvectl status montre quelle liaison répond à un nom, et un réseau invité qui distribue son propre résolveur peut laisser le DNS poussé par le tunnel inutilisé jusqu’à ce que la liaison soit de nouveau préférée. Un portail captif empire les choses : la première requête HTTPS reçoit la réponse du portail au lieu du point de sortie, et le client enregistre un serveur mort.
Le MTU du chemin change aussi. Ethernet et Wi-Fi portent généralement 1500 octets, PPPoE 1492, et les liaisons mobiles souvent moins. Un tunnel qui hérite d’un MTU plus petit se bloque sur les gros paquets alors que les petites requêtes passent, ce qui se lit comme une connexion à moitié cassée. ping -M do -s 1472 203.0.113.10 envoie un paquet de 1500 octets avec DF positionné ; le silence signifie que le chemin est plus petit que vous ne le pensiez.
IPv6 est l’autre moitié. Un réseau qui distribue un nouveau préfixe change la source qu’un client double pile utiliserait, et un tunnel uniquement v4 laisse le trafic v6 en dehors jusqu’à ce que la politique suive. ip -6 route show default et ip -6 addr show répondent à la question de savoir si la nouvelle liaison a un chemin v6.
Reproduisez la transition au lieu de la décrire
Choisissez une requête inoffensive et lancez les trois mêmes commandes de part et d’autre du changement : ip -br addr, ip route show default, ip route get 203.0.113.10. Regardez ensuite si le tunnel émet encore des paquets - tcpdump -ni any udp port 51820 pour WireGuard, le port correspondant pour tout le reste. Des paquets sortant de l’ancienne source signifient un problème de liaison de socket. Des paquets sortant de la nouvelle source sans réponse signifient le côté distant ou le NAT sur le chemin.
Notez quel événement a coïncidé avec la première panne: chute de la liaison, changement d’adresse ou changement de route par défaut. Ils désignent des responsables différents - un client qui doit se relier, une adresse qui doit être réacquise, ou une route qui appartient à un fichier de configuration et non à une règle de contournement permanente.
Avant de le déclarer réparé, confirmez que le blocage du trafic direct tient toujours pendant l’interruption et que les noms se résolvent par le nouveau rattachement. Si le client conserve l’ancien point de sortie après le basculement, corrigez d’abord le réglage d’itinérance ou de float. S’il itinère correctement et ne reçoit toujours pas de réponse, examinez l’identité du pair côté serveur et le NAT sur le chemin, et gardez les deux contextes réseau dans le compte rendu pour que la personne suivante puisse les comparer.