VPN morte après la veille : tunnel perdu ou application obsolète ?

Le capot s’ouvre, l’icône sans fil revient et le VPN s’affiche toujours comme connecté. La première page interne se bloque alors jusqu’au délai d’expiration, et un nouvel onglet fait de même. Trois choses différentes peuvent produire cette image et exigent trois correctifs différents : un tunnel qui n’a pas survécu à la veille, un profil que personne n’a demandé à réactiver, ou une application qui tient encore une session morte depuis des heures. Les comparer est plus rapide que de réinstaller quoi que ce soit.

Trois choses peuvent être cassées après le réveil

Le premier candidat est le tunnel lui-même. L’interface peut encore exister avec une adresse alors que l’association avec le pair a disparu, c’est pourquoi un voyant n’est pas la preuve d’un chemin qui fonctionne. Une poignée de main plus ancienne que la veille est l’indice, et une seule commande suffit pour la voir.

Le deuxième est l’activation. Beaucoup de clients se reconnectent seuls ; d’autres non, et un profil que personne ne demande à revenir reste là et semble configuré. Cet échec est silencieux par conception, parce que rien n’a signalé d’erreur.

Le troisième est l’application. Un onglet de navigateur, une session SSH ou une connexion à une base de données peuvent survivre à un changement de réseau en tant que descripteur de fichier alors que le transport en dessous est mort. Une nouvelle session fonctionne alors parfaitement, ce qui vous dit que le tunnel était bon depuis le début.

Comparez les trois avant de changer quoi que ce soit, car les correctifs ne se recoupent pas. Redémarrer un client qu’on n’a jamais invité à repartir gaspille la preuve dont vous aviez besoin. Notez à quel candidat le symptôme correspond avant de toucher une configuration. Cette seule phrase décide généralement du reste de l’enquête.

Premièrement : le tunnel est-il revenu ?

Regardez l’interface et l’état du pair plutôt que le texte d’état du client. Une interface avec une adresse et sans poignée de main récente est un tunnel qui n’existe que de nom.

ip -brief addr show
wg show
ip route show table all | head -20

Si l’interface manque complètement, le tunnel n’a pas survécu et la question devient qui aurait dû le ramener. S’il est présent mais que la poignée de main est ancienne, l’association avec le pair doit être rétablie, et le client attend peut-être du trafic pour la déclencher.

Vérifiez aussi les routes et la configuration DNS. Un tunnel peut revenir sans ses routes, ce qui produit l’état déroutant où l’interface est active et où les noms internes se résolvent encore par le mauvais serveur.

Deuxièmement : quelque chose lui a-t-il demandé de revenir ?

C’est ici que la comparaison se justifie. Un profil de greffon OpenVPN et une connexion WireGuard native sont traités différemment par NetworkManager, et la référence des paramètres de connexion indique clairement que connection.autoconnect n’active pas les profils VPN ; le mécanisme pour monter un VPN avec une connexion est connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Si une reconnexion manuelle répare le problème à chaque fois, c’est la signature d’une activation absente et non d’un tunnel cassé. Le journal montrera généralement l’interface qui tombe et rien qui la ramène.

Résistez à l’envie d’ajouter tout de suite un hook de veille. Un hook qui se déclenche avant que le réseau soit rétabli fait la course avec le processus même qu’il cherche à aider, et il transforme un problème reproductible en problème intermittent.

Troisièmement : l’application garde-t-elle un état ancien ?

Ouvrez une session entièrement nouvelle vers la même destination avant de toucher au VPN. Si la nouvelle session fonctionne et que l’ancienne non, le tunnel est bon et l’application tient une connexion morte.

C’est la moins coûteuse des trois vérifications et la plus souvent sautée, parce que la fenêtre qui échoue est juste à l’écran. Fermez-la, rouvrez-la et notez si le problème survit. Si la nouvelle session fonctionne, arrêtez complètement l’enquête sur le tunnel. Si elle échoue aussi, l’application est un symptôme et non une cause.

Certaines applications se rétablissent d’elles-mêmes après un délai, c’est pourquoi le symptôme peut sembler se corriger seul au bout de quelques minutes. Ce comportement désigne l’application et non le tunnel, et il vaut la peine de le noter séparément. Un collègue qui dit que cela s’est réparé tout seul décrit ce schéma, pas une chance.

Rendez la comparaison reproductible

Gardez les variables petites : un réseau d’accès, une durée de veille et la même première requête à chaque fois. Enregistrez ensuite deux résultats : si une reconnexion manuelle le répare et si une autre veille ramène la panne.

Cette dernière observation est celle qui sépare le plus fiablement les trois candidats. Une nouvelle session qui fonctionne après une ancienne en échec n’est pas un problème de tunnel, et aucune réinstallation du client n’y changera rien.

Le keepalive persistant de WireGuard ne figure dans ce tableau qu’en tant que keepalive de mappage NAT. Il envoie des paquets pour maintenir un mappage ouvert ; il n’empêche pas la machine de se mettre en veille et il ne peut pas continuer d’envoyer tant que le processus est suspendu.

Notez dans le ticket ce que vous avez trouvé : laquelle des trois choses était cassée, ce qui l’a réparée et comment vous l’avez reproduit. La prochaine personne qui ouvrira un capot un lundi vous remerciera, et la réponse n’aura pas à être redécouverte de zéro.