Un cache de routes VPN masque-t-il votre changement ? Vérifiez trois choses

Vider le cache de routes est le premier réflexe quand un changement ne prend pas effet, et sur un Linux moderne c’est un effort inutile : le cache de routes IPv4 global a été supprimé il y a des années, donc ip route show cache n’affiche rien et il n’y a rien à effacer. L’état qui vous trompe vit une couche plus haut : dans un socket, une correspondance NAT, un résolveur ou un gestionnaire de réseau qui a réappliqué l’ancien profil. Trois questions séparent ces cas : le mauvais chemin vient-il d’un nouveau flux ou d’une ancienne connexion, votre plateforme met-elle des routes en cache, et l’état est-il dans le routage ou au-dessus. Répondez-y avant de réinitialiser une interface.

Vérification un : l’ancien chemin vient-il d’un nouveau flux ?

Une connexion établie conserve la route avec laquelle elle a été créée. C’est pourquoi une session SSH sur le tunnel survit à un changement de table de routage tandis qu’une nouvelle session prend immédiatement le nouveau chemin, et pourquoi « le changement n’a rien fait » signifie souvent « l’ancien socket le retient encore ». Testez avec un nouveau processus, pas avec la fenêtre que vous avez déjà ouverte.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

La dernière commande affiche l’adresse que la nouvelle connexion a réellement atteinte, ce qui est le moyen le moins coûteux de voir le chemin réel sans faire confiance à une fenêtre d’état. Comparez-la à l’adresse source que l’espace de noms ou l’interface était censé utiliser.

Si un nouveau flux prend le bon chemin et que l’ancien ne se rétablit pas, cessez de regarder le routage. La route était bonne ; la session était ancienne.

Vérification deux : votre plateforme garde-t-elle seulement un cache de routes ?

Sous Linux la réponse est non, au sens où l’entendent la plupart des guides. Il n’y a pas de cache de destinations global à jeter, et l’entrée par socket qui retient une route choisie est libérée avec le socket. La section cache du manuel d’ip-route décrit un comportement historique, pas quelque chose que vous pouvez vider sur un noyau actuel.

Les autres plateformes diffèrent, et c’est là que la copie de conseils tourne mal. Windows garde un cache de destinations que vous pouvez vider avec netsh interface ip delete destinationcache. BSD et macOS exposent des recherches par destination via route -n get, et leurs caches expirent selon leur propre calendrier. Une commande qui fonctionne sur l’une d’elles ne fait absolument rien sous Linux, ce qui explique pourquoi le même correctif semble échouer pour la moitié des gens qui l’essaient.

Une table NAT ou conntrack n’est pas un cache de routes, même si elle produit le même symptôme. Un flux traduit avant votre changement conserve sa traduction, et conntrack -L le montrera longtemps après que la politique de routage a avancé. C’est un état obsolète, mais effacer des routes n’y touchera pas.

Vérification trois : l’état est-il dans le routage, ou au-dessus ?

Lisez la recherche actuelle avant de lire quoi que ce soit d’autre : ip route get pour la destination, puis la même commande avec from et l’adresse source, puis ip rule show. Si ces trois concordent avec votre intention, le routage n’est pas la couche à corriger, et l’observation obsolète venait d’ailleurs.

Trois suspects habituels siègent au-dessus du routage. Un gestionnaire de réseau peut réinstaller une route depuis un profil enregistré quelques secondes après que vous l’avez supprimée, si bien que votre changement semble revenir ; vérifiez nmcli connection show --active et l’état de l’unité avant de modifier à nouveau la table. Le cache d’un résolveur renvoie une ancienne adresse, ce qui ressemble à une défaillance de routage jusqu’à ce que vous interrogiez le même nom avec un outil qui contourne le cache. Le pool de connexions d’une application garde un socket fonctionnel vers l’ancienne destination et ne demande jamais au noyau une nouvelle décision.

Ce que les trois réponses vous permettent de conclure

Rassemblez les réponses et la réparation s’énonce souvent d’elle-même. Un nouveau flux qui prend le mauvais chemin sur une plateforme sans cache de routes signifie que la politique est réellement mauvaise, alors lisez les règles et la table installées par le tunnel. Un nouveau flux qui prend le bon chemin tandis que l’ancienne session bloque signifie que le problème est l’application ou le socket. Des routes correctes avec une observation cassée dans les deux cas signifient que l’état est au-dessus du routage.

Résistez au rafraîchissement générique. Redémarrer la pile réseau ou supprimer toutes les routes sur une machine dont la route par défaut est le tunnel peut couper précisément la connexion que vous utilisez pour la réparer, et cela détruit la preuve qui vous aurait dit quelle couche a échoué.

Si vous devez vraiment effacer quelque chose, effacez la plus petite chose qui corresponde au diagnostic : les sockets d’un processus, une entrée conntrack, le cache du résolveur. Répétez ensuite le même test de nouveau flux et notez ce qui a changé.

Gardez les trois états séparés dans vos notes

La configuration enregistrée, la recherche actuelle et le flux observé sont trois faits différents, et les fondre dans « le cache » est ce qui rend la panne difficile à reproduire. Notez le profil ou l’unité qui possède la route, la sortie de ip route get, et la source et la destination de la connexion réelle.

Notez à côté la plateforme et la version du client, car un correctif qui vide un cache de destinations Windows n’est pas un correctif applicable à un hôte Linux, et une procédure copiée entre les deux enseigne la mauvaise leçon. Quand vous confiez le problème à quelqu’un d’autre, ces trois lignes lui permettent de reproduire l’état défaillant au lieu de deviner.