Une application liée à l’adresse du VPN emprunte toujours la mauvaise route

Une application se lie à l’adresse du VPN, et la connexion sort pourtant par la route par défaut ordinaire. Rien n’a échoué dans le bind : il a fait exactement ce qu’un bind fait. Lier une socket à une adresse locale choisit l’adresse source que le noyau place dans l’en-tête. Cela n’installe aucune route et ne crée aucune règle de politique qui enverrait les paquets portant cette source dans un tunnel particulier.

Le reste de ce runbook est l’ordre de vérification que j’utilise, avec la commande qui produit chaque observation.

Ce qu’un bind décide réellement

Un bind attribue une adresse locale à la socket. Le noyau exécute ensuite la même recherche de route qu’il aurait faite autrement, sauf si une règle de politique change la table que cette recherche consulte.

C’est pourquoi un paquet peut partir avec une adresse source VPN sur une interface physique. De l’autre côté, il arrive depuis une plage privée que le réseau n’attendait pas sur ce chemin, le trafic de retour n’a pas de route vers l’arrière, et la connexion se bloque ou se réinitialise.

La référence des sockets IP de Linux documente la sémantique du bind. La moitié routage vit dans ip-rule et ip-route, et ce sont des pages de manuel séparées pour une raison.

Confirmer que l’adresse appartient à cet espace de noms

Une adresse que vous pouvez lier doit exister sur une interface à l’intérieur de l’espace de noms réseau où l’application s’exécute. Une adresse de pair, une adresse de passerelle, ou une adresse qui n’existe que dans un autre espace de noms ne peut pas être liée, et l’appel échoue avec EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Lancez ces trois commandes dans le même contexte que l’application : même espace de noms, et même utilisateur si vous pouvez l’obtenir. Un vieux schéma net30 ne prouve rien sur l’adresse que votre topologie actuelle a attribuée au client. Lisez l’interface réellement active.

Lire la recherche pour cette source et cette destination

Une seule commande répond à la question que le bind n’a pas résolue :

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

La première ligne affiche la route qu’emprunterait un paquet de cette source vers cette destination, y compris l’interface de sortie et la source préférée. Si elle nomme l’interface physique, le bind et la route sont en désaccord, et le paquet partira avec une source vers laquelle le chemin ne peut pas revenir.

ip rule show vous dit ensuite si une règle aurait sélectionné une autre table. Les priorités comptent ici, car la première règle correspondante gagne et une règle fourre-tout placée au-dessus de la vôtre rend votre règle invisible.

N’installez une règle de politique que si c’est la conception

Le routage basé sur la source est une conception délibérée, pas une réparation pour une application. Si le propriétaire de la politique veut que le trafic du sous-réseau du tunnel utilise le tunnel, la règle appartient à sa configuration et non à une commande ponctuelle sur votre portable.

Une forme viable est une table dédiée avec une route par défaut via le tunnel, plus une règle qui envoie la plage source du VPN dans cette table. Ajoutez les exceptions dont la conception a besoin, car une table contenant seulement un défaut de tunnel capturera des destinations censées rester locales ou joignables par le chemin physique.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Annulez avec ip rule del et ip route flush table 100. Tout ce qui est ajouté ainsi disparaît au redémarrage, sauf si un gestionnaire l’écrit, ce qui est à la fois une propriété de sécurité et une raison de ne pas garder l’unique copie dans l’historique de votre shell.

Vérifier avec trois observations

Enregistrez la source demandée par l’application, la route sélectionnée par la recherche, et la source que le serveur a réellement vue.

Ces trois éléments peuvent diverger, et chaque divergence pointe vers un endroit différent. Une capture sur l’interface du tunnel prouve que le paquet est parti avec la bonne source. Une capture sur l’interface physique prouve qu’il est parti du mauvais côté. La vue côté serveur est la seule qui prouve le chemin de bout en bout.

Si l’application propose une option de liaison à un périphérique ou un mode de routage par application, traitez-la comme un mécanisme différent avec des contraintes différentes. Des réglages d’apparence similaire ne se résolvent pas tous vers la même décision du noyau.