Inspectez le routage par politiques de Linux avant de modifier la route par défaut

Un hôte VPN répond sur une interface et refuse de renvoyer les réponses par le tunnel, et la route par défaut semble correcte. C’est ici que la table principale cesse d’être toute l’histoire. Linux peut sélectionner une table de routage par paquet à l’aide de règles de politique, et le VPN en a peut-être installé une. Lisez les règles avant de toucher à la route par défaut.

L’ordre compte : d’abord les règles, ensuite la table que chaque règle sélectionne.

Lisez les règles par ordre de priorité

Exécutez ip rule show et lisez de haut en bas. Le numéro de priorité contrôle l’ordre d’évaluation, et un numéro plus faible est vérifié plus tôt. La règle par défaut à 32766 est généralement la dernière qui compte. Si la liste est longue, enregistrez-la dans un fichier avant de changer quoi que ce soit.

Pour chaque règle, notez la priorité, la correspondance (source, marque, interface ou destination) et la table à laquelle elle renvoie. Une règle sans table utilisable est une impasse, pas une route.

Faites de même pour IPv6 avec ip -6 rule show. Une politique qui n’existe que dans la famille IPv4 laisse l’autre famille sur la table principale.

Lisez la table que chaque règle sélectionne

Utilisez ip route show table <name or number> pour chaque table référencée. Comparez ses routes avec l’interface et le prochain saut que vous attendez. Une table vide ou incomplète explique une panne que la table principale ne peut pas expliquer.

La table principale peut encore contenir la route par défaut, et c’est normal. Si une règle envoie d’abord votre flux vers la table 51820, la route par défaut principale ne concerne pas ce paquet.

Cherchez le nom de la table dans /etc/iproute2/rt_tables si le numéro ne vous est pas familier. Cette recherche prend une seconde et évite un long détour.

Découvrez qui a installé la règle

NetworkManager, wg-quick et d’autres scripts peuvent installer des règles dynamiquement. Supprimer une règle à chaud peut être annulé à la prochaine reconnexion. Vérifiez la configuration du gestionnaire avant d’ajouter une règle concurrente.

wg-quick, par exemple, ajoute une règle marquée et une table pour les adresses autorisées du tunnel. C’est cette règle qui fait contourner la route par défaut principale au trafic vers ces adresses. Si vous la supprimez sans changer la configuration, le prochain démarrage la rétablira.

Préservez la route externe du point de terminaison et l’accès de gestion pendant votre examen. Ne videz pas toutes les règles sur une passerelle distante active pour simplifier la sortie. Une session de gestion qui survit au changement fait partie du test.

Testez le contexte source qui compte

Un ip route get générique répond à une autre question que le flux de l’application. Ajoutez l’adresse source, et la marque si le VPN en utilise une, pour voir le chemin que prend le paquet réel. Testez une destination incluse et une exclue avec le même contexte source. Répétez ensuite pour IPv6 si l’hôte est en double pile.

Après une correction approuvée, relancez les deux mêmes recherches et comparez. Tenez un registre de la règle prévue, de la table et de la durée pendant laquelle la règle survit à un redémarrage. C’est ce registre qui rend le prochain redémarrage du service explicable plutôt que mystérieux. La page de manuel d’ip-rule documente les sélecteurs de correspondance et la syntaxe des tables.