Comment distinguer les routes poussées par le VPN des routes statiques sous Linux

Un préfixe apparaît sur le portable quand le tunnel monte, donc on a l'impression que le VPN l'a installé. C'est peut-être le cas, mais le même résultat peut venir d'un script client exécuté à la connexion, d'un profil de connexion qui liste le sous-réseau, ou d'une route statique présente depuis le début et qui n'a commencé à fonctionner qu'une fois l'interface existante. Choisir le mauvais propriétaire signifie que la route revient après chaque nettoyage, et la personne suivante répète la même correction. La séquence ci-dessous sépare les trois avant de changer quoi que ce soit.

Étape 1 : nommer le mécanisme qui installe les préfixes

Différents protocoles fournissent la joignabilité de différentes manières, et appeler tout cela une annonce masque la distinction. Un serveur OpenVPN pousse une directive de route par le canal de contrôle et le client l'installe sauf si un filtre pull la bloque. Une configuration WireGuard liste localement les préfixes autorisés, que le client utilise à la fois pour le routage des clés cryptographiques et pour les routes qu'il ajoute. Un tunnel IPsec négocie des sélecteurs de trafic avec le pair, et le noyau installe des routes à partir de ces sélecteurs.

Identifiez lequel de ces mécanismes votre tunnel utilise avant de lire la moindre table. Une route poussée à la connexion n'est pas une annonce de protocole de routage et ne promet pas que le préfixe est joignable derrière l'extrémité distante. Notez le mécanisme à côté du préfixe, car il décide où se situe la correction.

Étape 2 : comparer la table sur une connexion

Enregistrez la table principale tunnel baissé, montez-le, enregistrez à nouveau et comparez les deux captures. Tout ce qui est apparu appartient au cycle de vie de la connexion, et tout ce qui est resté appartient à la configuration locale.

Capturez-la avec ip route show table main > /tmp/route-down.txt, connectez-vous et capturez de nouveau. Faites de même pour ip -6 route si le site utilise IPv6, car un préfixe absent y produit des pannes qui semblent sans rapport avec le routage.

Étape 3 : lire la métrique, pas seulement la présence

Deux entrées pour le même préfixe peuvent coexister, et le noyau choisit la métrique la plus basse. Une route statique de métrique 50 continuera de gagner contre une route poussée à 100 même si les deux sont visibles, c'est pourquoi « la route est là » et « le trafic l'utilise » sont deux affirmations différentes.

Interrogez le noyau directement avec ip route get 10.20.5.7 et lisez l'interface qu'il indique. Si le trafic sort par l'adaptateur physique alors qu'une route du tunnel siège dans la table, la métrique ou la longueur du préfixe l'explique, pas le client VPN. Répétez la recherche pour un hôte que vous savez derrière le tunnel et pour un autre que vous savez ne pas l'être, et la différence montre si le découpage se comporte comme prévu.

Étape 4 : trouver les entrées qui survivent au tunnel

Les routes statiques survivent à une déconnexion par conception, et c'est de là que viennent les entrées obsolètes. Une route persistante pointant vers une interface qui n'existe plus peut engloutir un sous-réseau en silence, et une route pointant vers un nom d'interface réutilisé peut envoyer du trafic privé par la mauvaise porte après un redémarrage.

Vérifiez le côté persistant à l'endroit utilisé par votre distribution, qu'il s'agisse d'une unité systemd-networkd, d'un profil NetworkManager ou d'un script dans le répertoire up du client. Corriger la table vivante avec ip route del ne tient que jusqu'à la prochaine connexion. Traitez cette suppression comme un test de l'hypothèse plutôt que comme la réparation.

Quand l'extrémité distante fournit la mauvaise couverture, remontez-le à l'opérateur au lieu de tout filtrer. Abandonner tous les réglages poussés jette aussi le DNS et la politique de tunnel divisé dont dépend le profil.

Étape 5 : confirmer le chemin de retour avant d'accuser le client

Pour un site à site ou un sous-réseau derrière le tunnel, le côté distant a besoin d'une route de retour vers l'adresse de votre client et du transfert activé sur la passerelle. Un chemin à sens unique ressemble exactement à un bug de routage du client, sauf que la poignée de main et le paquet sortant réussissent tous deux.

Le filtrage du chemin inverse ajoute un second piège sur les passerelles Linux. Une réponse arrivant sur une interface différente de celle que la route prédit est rejetée par le mode strict, et les chemins asymétriques via deux fournisseurs le déclenchent de manière fiable. Les compteurs de rejet sur la passerelle, et non sur le client, vous disent si le filtrage est la cause.

Étape 6 : tester la ressource, pas le ping

Une fois la route choisie correcte, ouvrez la ressource réelle et confirmez le trafic de retour. Une réponse ping prouve le chemin dans un sens et rien sur le service, et un service qui répond sur une connexion en cache prouve encore moins.

Répétez ensuite toute la vérification après une reconnexion. La valeur de la séquence est qu'elle prédit ce que fera la prochaine connexion, c'est pourquoi la comparaison et la métrique appartiennent toutes deux au ticket.