Table de routage ou recherche réelle : où va le trafic VPN

Un vidage de la table de routage est le diagnostic le moins utile dans le dépannage VPN et le plus souvent collé. Quarante lignes de préfixes vous disent ce que la machine pourrait faire, pas ce qu'elle a fait pour la requête qui a échoué. Le mécanisme que vous voulez vraiment est la recherche : pour cette source et cette destination, quelle règle a correspondu, quelle table a été consultée, et quelle interface et quel saut suivant en sont sortis. Partez d'une destination et d'une source, lisez ensuite la table avec cette question en tête, et la même sortie devient une preuve au lieu d'un bruit.

Une table est un ensemble de candidats, pas une décision

Chaque entrée décrit un préfixe et quoi faire du trafic qui y correspond : l'envoyer vers une interface, le remettre à un saut suivant, ou le rejeter. Rien dans cette liste n'est ordonné par intention, et l'entrée qui paraît la plus spécifique à un humain n'est pas toujours celle que le noyau sélectionne, car la sélection suit la correspondance de préfixe la plus longue et, entre préfixes égaux, la métrique.

Le premier geste est donc d'interroger le noyau plutôt que de lire la liste. La commande de recherche répond pour une destination, et avec un argument de source elle répond pour la paire exacte qu'utiliserait une connexion transférée ou liée :

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Chaque adresse ci-dessus est un exemple de documentation. Le point est la forme de la réponse : interface, adresse source choisie, passerelle et table d'où vient l'entrée. Si cette sortie ne correspond pas à l'interface attendue, vous avez localisé le problème en une commande, et aucune lecture de la table complète ne vous aurait dit quel candidat l'a emporté.

La recherche parcourt d'abord les règles, puis les tables

Sous Linux, la décision se fait en deux étapes. Les règles de politique sont évaluées par ordre de priorité, et la première règle qui correspond nomme une table à consulter ; cette table effectue alors la correspondance de préfixe la plus longue. Une règle peut correspondre sur la source, la destination, la marque de pare-feu, l'interface ou une combinaison, ce qui explique qu'un vidage de la table principale puisse être parfaitement exact et totalement hors sujet pour le paquet que vous étudiez.

ip rule show
ip route show table all | head -40
ip route show table 100

Si une règle envoie le trafic de votre pool VPN vers la table 100, alors c'est la table 100 qui compte, et la table principale est un leurre. C'est aussi le mécanisme du routage basé sur la source sur un routeur : la même destination peut avoir deux réponses différentes selon l'origine du paquet, et seule la recherche avec un argument de source révèle laquelle s'applique.

IPv6 a ses propres règles et tables. Un design qui fait tourner les deux familles a besoin des deux recherches, et une réponse IPv4 qui fonctionne ne dit rien du chemin v6 qu'un client double pile peut préférer.

Ce que le client VPN installe

Les clients ne remplacent généralement pas la route par défaut, car cela casserait le chemin extérieur du tunnel lui-même. Ils installent quelque chose de plus spécifique qui gagne par la longueur du préfixe : une paire de demi-routes par défaut couvrant 0.0.0.0/1 et 128.0.0.0/1 est l'astuce classique, puisque les deux sont des préfixes plus longs que 0.0.0.0/0 et couvrent ensemble tout l'espace. D'autres installent des préfixes privés précis plus une règle de politique, et certains ajoutent une marque pour que seul le trafic sélectionné soit capturé.

C'est pourquoi "le VPN n'a pas changé ma route par défaut" n'est pas une preuve d'échec. Vérifiez ce qu'il a effectivement ajouté, et si la destination concernée tombe dans ces préfixes :

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Deux demi-routes sont faciles à manquer dans un vidage parce qu'elles ne ressemblent pas à une route par défaut. Une configuration de split-tunnel qui a oublié d'inclure un préfixe produit exactement le symptôme que vous traquez : l'application qui devrait utiliser le tunnel résout et se connecte localement à la place. Comparez les préfixes installés aux destinations dont l'utilisateur a réellement besoin, pas aux adresses que vous avez testées par hasard. Une liste de split-tunnel qui couvre le serveur de fichiers mais pas son résolveur produit une connexion qui résout vers une adresse publique puis échoue à s'authentifier, ce qui ressemble à un problème de mot de passe et est un problème de route.

La route extérieure doit survivre aussi

Le tunnel est lui-même du trafic. Les paquets portant la charge encapsulée vont vers l'adresse du pair via l'interface physique, et ce chemin ne doit pas être routé de nouveau dans le tunnel. Quand c'est le cas, vous obtenez la panne caractéristique où le tunnel s'établit puis cesse de faire passer le trafic, car le transport du tunnel est désormais à l'intérieur du tunnel.

Vérifiez l'adresse du pair comme vous avez vérifié la destination intérieure, et confirmez qu'elle résout vers l'interface physique plutôt que vers le tunnel :

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Une route récursive, une règle de politique qui attrape le pair, ou une route par défaut remplacée par un client full-tunnel sont les trois causes habituelles. Toutes trois sont visibles dans la recherche extérieure, et aucune n'est visible dans un vidage de la table principale pris après coup.

Ce que la sortie de routage ne peut pas vous dire

Une recherche correcte signifie que le noyau enverrait le paquet quelque part de sensé. Cela ne signifie pas que le pare-feu l'autorise, que la politique IPsec le couvre, que la règle NAT le traduit, ou que le côté distant a une route de retour. Chacun de ces points est une étape ultérieure, et les notes de transfert de strongSwan décrivent la chaîne qu'un paquet doit traverser aux deux extrémités.

Elle ne tient pas compte non plus de la liaison au niveau applicatif. Un processus peut se lier à une interface, poser une marque ou utiliser son propre résolveur et se connecter avec un nom qui résout différemment de ce que vous avez testé. Quand la recherche est juste et que la connexion échoue encore, la question suivante est quel processus la fait et si ce processus voit la même table que vous.

Gardez donc le diagnostic ordonné : nommez la destination et la source, lancez la recherche, ne lisez que la table et la règle nommées par la recherche, puis testez l'étape suivante. Cette séquence garde une enquête de routage en quelques minutes et laisse une trace que quelqu'un d'autre peut suivre, ce qu'une table collée ne fait jamais.