Ce que le routage par politiques change au trafic VPN, et ce qu'il ne change pas

Le routage par politiques répond à une autre question que celle que posent la plupart des notes de dépannage. La table principale indique où va une destination ; les règles de politique indiquent quelle table est consultée tout court, et elles peuvent en décider à partir de l'adresse source, d'une marque de paquet, ou de l'interface par laquelle un paquet est arrivé. Quand un tunnel se comporte de façon incohérente, l'ensemble de règles est souvent la raison et la table de routage souvent pas.

Les règles choisissent la table, puis la table choisit la route

Chaque règle porte une priorité, une condition de correspondance et une table cible. Le noyau parcourt les règles par ordre de priorité et s'arrête à la première correspondance, puis effectue une recherche ordinaire du plus long préfixe dans cette table. Une règle pointant vers une table vide retombe sur ce que sélectionne la règle suivante, et c'est ainsi qu'une règle soigneusement écrite peut sembler ne rien faire.

C'est pourquoi afficher la table principale explique rarement un client VPN qui fonctionne. Les clients insèrent souvent des règles à de faibles numéros de priorité, bien avant la règle par défaut de la table principale, si bien que le paquet n'atteint jamais la route que vous fixiez. Baisser une métrique dans la table principale ne change rien pour le trafic déjà détourné.

Une règle peut aussi transformer volontairement un préfixe en trou noir ou le rendre inatteignable. Certains clients ajoutent une telle règle comme coupe-circuit, et la chute ressemble alors à un tunnel cassé plutôt qu'à un tunnel configuré.

Lisez l'ensemble de règles comme une séquence, non comme une liste

Affichez les règles avec leurs priorités et les tables auxquelles elles renvoient, puis affichez chaque table qui porte une route par défaut ou une route de tunnel. L'ordre est la partie qui compte, et c'est la partie qu'une capture d'écran omet souvent :

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Les deux dernières commandes sont celles qui transforment une théorie en observation, car elles demandent ce que le noyau ferait pour cette source et cette marque. Si la réponse change quand la marque change, une règle fondée sur la marque est en jeu et tout test qui omet la marque teste un autre paquet. La connexion extérieure mérite sa propre règle. Un tunnel qui route tout le trafic à travers lui-même doit exclure l'adresse de point de terminaison à laquelle il se connecte, sinon les paquets chiffrés sont renvoyés dans le tunnel qu'ils viennent de quitter. La plupart des clients insèrent cette exclusion automatiquement, et un ensemble de règles édité à la main est l'endroit où elle manque.

Marques et sockets : deux façons dont les clients répartissent le trafic

Certains clients marquent les paquets dans le pare-feu et ajoutent une règle qui correspond à la marque. D'autres utilisent le routage au niveau du socket, en posant une route sur le socket avant qu'il ne se connecte. Le premier est visible dans ip rule ; le second ne l'est pas, et il n'apparaîtra pas dans une recherche générique.

Si un programme de test se comporte différemment de l'application qu'il est censé représenter, vérifiez si l'application pose une marque ou se lie à un périphérique. Cette différence n'est pas un mystère une fois le mécanisme nommé, et elle explique pourquoi un curl depuis un shell et un onglet de navigateur peuvent emprunter des chemins différents sur la même machine. Les deux techniques relèvent du routage par politiques au sens large : elles choisissent un chemin avec autre chose que la destination. Ni l'une ni l'autre n'autorise le trafic, et ni l'une ni l'autre ne remplace les règles du pare-feu ou les identifiants que le pair attend.

Traçez la propriété avant d'ajouter une autre règle

Les règles sont installées par quelque chose. Un client VPN, un gestionnaire de réseau et un script écrit à la main peuvent chacun ajouter des règles au démarrage, et la logique de reconnexion peut laisser l'ensemble précédent derrière elle. Deux règles périmées d'un profil antérieur continueront d'orienter le trafic longtemps après la suppression du profil.

Déterminez quel processus possède la règle d'après sa priorité et sa forme, et vérifiez si ce propriétaire réécrit l'ensemble à chaque connexion. Si oui, une règle manuelle ajoutée aujourd'hui disparaît demain, et le correctif appartient à la configuration du client plutôt qu'à un fichier d'historique du shell. Purger tout l'ensemble de règles pour tester est un raccourci tentant au coût prévisible : il retire aussi les règles dont le client a besoin pour maintenir son propre tunnel. Supprimez une règle à la fois, ou testez sur une machine que vous pouvez redémarrer.

Prouvez la portée avec deux flux, pas un

Un correctif ne se vérifie qu'avec un flux qui devrait être touché et un flux qui ne devrait pas l'être. Choisissez une destination que la politique route dans le tunnel, et une qui doit rester dehors, puis comparez les recherches et les captures pour les deux :

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Quand les deux recherches renvoient des interfaces différentes, la règle fait quelque chose. Quand elles renvoient la même interface, la règle correspond plus largement que prévu, et c'est la défaillance qui envoie silencieusement tout un sous-réseau dans un tunnel prévu pour une seule application.

Notez les priorités des règles et le service propriétaire dans le ticket, avec les deux adresses de test. La personne suivante dispose alors d'une paire reproductible au lieu d'une description de symptôme, et peut dire en une minute si le routage par politiques est encore en jeu.