VPN connecté mais rien ne passe : deux endroits à vérifier

Un tunnel peut annoncer « connecté » alors que rien ne l’atteint, et ces deux faits vivent à des endroits différents. L’un est la table de routage, qui peut encore envoyer des paquets vers un périphérique que personne ne possède. L’autre est le résolveur, qui peut encore lister un serveur sur un lien disparu. Le changement de réseau n’a pas endommagé le profil, il a orpheliné l’état appartenant à la connexion précédente, et la réparation dépend de celui des deux que vous regardez réellement.

D’abord, demander au noyau quel périphérique il utiliserait

Une liste de routes montre ce qui existe ; une recherche de route montre ce qui se passerait. Interrogez une adresse publique et lisez le nom du périphérique dans la réponse, car ce seul champ décide si le paquet arrive quelque part d’utile. Quand la réponse nomme un périphérique tunnel, le noyau lui remet les paquets même si aucun processus client ne tourne encore derrière cette interface. Quand la réponse nomme l’adaptateur physique alors que le client se dit connecté, le tunnel est monté et n’est simplement pas le chemin choisi.

Le second cas est le cas habituel après qu’un câble a remplacé le sans-fil, et il se présente comme un VPN cassé.

ip route show default
ip route get 203.0.113.9

Lisez ensuite les entrées par défaut, car une route ajoutée par la connexion de base précédente peut survivre à un changement de lien et se placer devant la nouvelle. Une route par défaut via un périphérique qui est en panne est pire que pas de route par défaut, parce que le noyau la préfère toujours. Notez la métrique à côté de chaque entrée, car cet ordre explique la préférence plus vite que les noms d’interface.

Ensuite, lire le résolveur par lien, pas par fichier

La résolution de noms porte son propre état et sa propre péremption. Un résolveur qui liste les serveurs DNS par lien conserve les serveurs d’un lien tunnel qui est en panne mais toujours enregistré, et chaque requête attend alors un serveur qui ne répondra pas. Le symptôme est un réseau qui semble mort alors que la table de routage est parfaite.

Inspectez l’état par lien plutôt que le fichier, car sur beaucoup de distributions ce fichier est un lien symbolique vers le résolveur et le modifier ne fait rien ou est vite écrasé. Regardez quel lien possède quels serveurs et quel domaine de recherche, puis demandez si le lien tunnel devrait encore être enregistré. S’il ne devrait pas, désactivez la connexion qui le possède au lieu de modifier à la main un état généré. Un nom qui se résout alors que la recherche de route envoie les paquets ailleurs est une troisième faute, distincte.

resolvectl status
resolvectl query app.internal.example

Si les adresses se résolvent et que les connexions échouent, le résolveur va bien et la route non. Si les adresses ne se résolvent pas du tout, c’est ici qu’il faut commencer.

Comment une route périmée survit au changement

Le client ne possède pas le réseau à lui seul. Sur un hôte NetworkManager, un profil VPN est activé par-dessus une connexion de base, et les paramètres de connexion permettent à cette base de nommer le VPN qui doit la suivre. Quand la base change parce qu’un autre profil devient préféré, le tunnel suit sur la nouvelle base ou reste sans aucune.

Un profil VPN ne se monte pas tout seul, donc l’appariement compte bien plus que la préférence de connexion automatique du profil lui-même.

Lisez la liste active et notez quelle base est montée avant de toucher au tunnel. Si la base est listée et le tunnel non, la route manque plutôt que d’être périmée et le correctif est l’activation. Si l’activation du tunnel se plaint qu’aucune connexion source n’existe, la base avec laquelle il était apparié a disparu, alors montez-la d’abord ou réparez l’appariement au lieu de réessayer le tunnel. Réessayer un profil dont le parent est absent produit la même erreur à chaque fois, ce qui est un signal utile plutôt qu’une nuisance.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Distinguer l’état périmé d’un parent manquant

Trois états expliquent presque tous les rapports, et chacun demande une réparation différente. Une route par défaut via un périphérique qui existe encore mais ne porte plus le tunnel est un état périmé, effacé soit en supprimant l’entrée, soit en redémarrant le profil responsable. Un périphérique tunnel dont le processus client a disparu est un échec de nettoyage, donc le chemin de déconnexion mérite l’attention plutôt que la table de routage. Aucun périphérique tunnel du tout signifie que le parent ou l’appariement manque et que la table de routage n’a jamais été impliquée.

Un redémarrage cache lequel des trois vous aviez, et c’est exactement pourquoi il ressemble à un correctif.

Après la réparation, demandez au noyau une adresse publique et une adresse interne, puis interrogez un nom interne. Quand l’adresse fonctionne et le nom non, vous avez trouvé un problème de portée de domaine dans le résolveur plutôt qu’un problème de routage. Notez quel état vous avez trouvé, car le prochain changement de réseau reproduira celui que vous avez laissé en place.