Pourquoi une route VPN supprimée revient après une reconnexion

Une route que vous avez supprimée à la main revient après la reconnexion suivante, et la table est exactement comme avant. Ce n’est pas un bug de routage : quelque chose recrée l’entrée à partir de la configuration ou d’une action du cycle de vie de la connexion. La plupart des runbooks s’arrêtent à la table active, ce qui explique pourquoi la suppression semble fonctionner une minute puis échoue. Identifiez le propriétaire, modifiez-le, et prouvez-le lors d’une reconnexion.

Qui a installé la route

Commencez par une liste de candidats plutôt que par un correctif. Un profil VPN peut porter ses propres routes, un serveur peut les pousser à la connexion, un profil de gestionnaire de réseau peut les déclarer, une unité de démarrage ou un script peut les ajouter, et les implémentations IPsec installent des routes pour les sélecteurs de trafic qu’elles négocient. Les règles de routage par politique peuvent aussi rediriger complètement le trafic vers une autre table.

Le moment où elles apparaissent les sépare plus vite que l’archéologie de configuration. Une entrée qui apparaît à l’instant où l’interface monte appartient au client ; une qui arrive une seconde plus tard vient généralement d’un push du serveur ; une qui est présente au démarrage appartient à la configuration enregistrée. Relevez la table avant et après une connexion, une déconnexion et un redémarrage, et le motif nommera le propriétaire. Une route qui ne revient qu’au redémarrage du service pointe vers une unité et non vers le VPN.

Lisez la table avant de la modifier

Regardez la vue du noyau lui-même plutôt qu’un fichier enregistré. La colonne protocole indique ce qui a installé chaque entrée:

ip route show
ip route show table all
ip rule show

Le champ protocole, la métrique et le numéro de table vous disent si vous regardez une entrée statique, une entrée créée par le noyau ou quelque chose ajouté par un démon. La liste des règles compte parce qu’une recherche peut quitter entièrement la table principale, ce qui rend une modification à cet endroit invisible pour l’application que vous dépannez. Lisez la ligne de gauche à droite : destination, passerelle, périphérique, protocole et métrique.

Demandez ensuite au noyau quelle route il utiliserait réellement. Une adresse protégée est une meilleure sonde qu’une adresse publique :

ip route get 10.20.5.7

Changez le propriétaire, pas le symptôme

Une fois le propriétaire connu, la modification lui appartient. Retirez la route du profil client, corrigez la route poussée sur le serveur ou modifiez la connexion du gestionnaire de réseau au lieu d’ajouter une route persistante concurrente qui l’emporte par métrique. Deux règles qui se combattent produisent une table que personne ne pourra expliquer plus tard.

Conservez l’exclusion du point de terminaison. Une route d’hôte qui envoie l’adresse publique du serveur VPN lui-même via la passerelle physique est ce qui maintient les paquets du tunnel externe en circulation; supprimez-la et le tunnel essaie de se porter lui-même. Sur un profil de tunneling divisé, le même soin s’applique aux sous-réseaux locaux censés contourner le tunnel.

Reconnectez-vous et vérifiez les deux chemins

Reconnectez-vous, puis vérifiez les deux destinations en une seule passe. L’adresse protégée et le point de terminaison exclu répondent à des questions différentes :

ip route get 10.20.5.7
ip route get 198.51.100.20

La première devrait se résoudre via l’interface du tunnel et la seconde via la passerelle physique. Si les deux passent par le tunnel, l’exclusion manque ; si aucune ne le fait, le changement de profil n’a pas pris effet et vous regardez un autre propriétaire que celui que vous pensiez.

Notez l’objet de la route, son propriétaire et combien de temps elle doit vivre. Cette note est ce qui empêche la personne suivante de répéter le même cycle de suppression et de reconnexion.