Une application liée à une interface ? Son chemin VPN n’est pas celui par défaut

Une application de la machine sort par le VPN et une autre non, et les deux utilisateurs jurent n’avoir rien changé. La différence est souvent une décision de liaison prise par l’application elle-même : un socket attaché à un périphérique, une adresse source choisie avant la connexion ou un espace de noms doté de sa propre table de routage. Chacune change la route appliquée, et aucune n’apparaît dans un contrôle d’IP générique dans le navigateur.

Trois liaisons différentes, trois effets différents

Se lier à un périphérique et se lier à une adresse source sont des opérations proches aux conséquences différentes. Une liaison à un périphérique peut forcer le trafic à sortir par une interface et contourner la recherche de route normale pour ce socket. La liaison à une adresse source passe encore par la sélection de route, mais la source choisie peut correspondre à une règle de politique et envoyer le paquet ailleurs. La distinction paraît théorique jusqu’à ce qu’une règle route par source. Alors elle décide de tout.

L’espace de noms réseau est le troisième cas. Il a ses propres interfaces et sa propre table de routage, donc une application à l’intérieur ne subit pas du tout la valeur par défaut de l’hôte. Traiter les trois comme une seule et même chose produit des explications assurées qui ne résistent pas au premier test.

Déterminez ce que l’application définit réellement

Lisez la configuration réseau de l’application ou son comportement documenté avant de toucher aux routes. Si elle expose un choix d’interface, un champ d’adresse source ou une option d’espace de noms, ce réglage est la première chose à inspecter. Sinon, la liaison peut être interne et visible seulement via le traçage ou ses propres diagnostics.

Sous Linux, des options de socket comme SO_BINDTODEVICE ont une portée et des exigences de droits documentées, et un processus non privilégié peut ne pas pouvoir les définir du tout. Cette contrainte est un indice utile : si l’option ne peut pas être appliquée, l’application n’est probablement pas la source de la différence.

Le routage par politique lit la source

Lorsque le routage par politique est configuré, une règle peut choisir une table selon la source du paquet. Un socket qui lie une adresse source peut donc suivre une règle que le chemin par défaut ne touche jamais, même si aucune interface n’est nommée explicitement.

Reproduisez la recherche avec la même famille d’adresses, la même source et le même espace de noms que l’application. Une recherche de route générique depuis un shell dans l’espace de noms de l’hôte répond à une autre question, et ce décalage est la raison la plus fréquente pour laquelle une route qui fonctionne semble cassée.

Tunnel divisé et processus auxiliaires

Le tunnel divisé par application ajoute une couche. Le client peut faire correspondre le paquet ou le processus de l’application, et un assistant qui ouvre son propre socket est un sujet distinct. Un lanceur et son service en arrière-plan peuvent produire des connexions différentes sous le même nom visible.

Vérifiez si la règle de tunnel divisé couvre le processus qui se connecte réellement. Si l’application se lie à une interface précise et que le client VPN fait correspondre par paquet, les deux décisions peuvent diverger sans qu’aucune soit fausse.

Testez le chemin propre à l’application

Lancez une nouvelle requête depuis l’application après chaque changement. Un navigateur qui affiche la sortie souhaitée n’est pas une preuve équivalente pour un autre programme lié à une autre interface, et les connexions en cache peuvent continuer à utiliser l’ancien chemin longtemps après un changement de réglage. Fermez l’ancienne session avant de juger la nouvelle règle. Sinon, le test mesure le passé.

La référence des sockets Linux documente SO_BINDTODEVICE et ses exigences. Lisez d’abord la configuration de l’application elle-même, reproduisez la recherche dans le même contexte et décidez seulement ensuite si la route ou la liaison doit changer.