Tunnel divisé : pourquoi un lien s’ouvre hors du VPN que vous avez configuré
Le routage suit le processus qui ouvre la socket, pas l’application qui vous a montré le lien. Prouvez quel programme se connecte avant d’élargir vos exclusions.
Faire passer une application par un tunnel ne transporte pas son routage vers tout ce que cette application lance, même si l’interface suggère le contraire. Un lien remet une requête à un autre programme, ce programme ouvre sa propre socket, et la plateforme applique les règles au nouveau processus plutôt qu’à celui qui a affiché le texte. C’est ce second processus que la politique du tunnel voit réellement, et ce n’est pas celui que vous avez configuré.
Une application incluse peut donc ouvrir un navigateur qui se trouve hors du tunnel. Un navigateur exclu peut rendre du travail à une application qui se trouve à l’intérieur. Les deux sens de cette surprise sont un comportement ordinaire.
La partie du flux de travail que personne n’a configurée
La politique par application s’écrit contre l’identité d’un exécutable ou d’un paquet, et chaque connexion est évaluée au moment où elle est créée. Le navigateur, la visionneuse de documents, le lecteur multimédia et la feuille de partage du système portent chacun leur propre identité, et chacun reçoit son propre verdict. Un lien profond transporte des données, pas une politique.
C’est pourquoi l’observation paraît arbitraire : le même clic est routé de deux façons selon le gestionnaire qui y répond. Un client de messagerie dans le tunnel ouvre un lien dans un navigateur qui vit hors du tunnel, et la page se charge depuis votre adresse domestique. Un navigateur hors du tunnel ouvre un document dans une visionneuse qui vit à l’intérieur, et le fichier arrive par la sortie. Aucun des deux résultats n’est un défaut du client.
Un gestionnaire déjà en cours d’exécution aggrave les choses. Si le navigateur est déjà ouvert, le lien devient un message vers un processus existant, et ce processus conserve le routage qu’il avait au démarrage. Fermer puis rouvrir le gestionnaire change le résultat, et c’est pourquoi le problème ne se reproduit jamais à la demande.
| Platform | Policy object | What it is evaluated against |
|---|---|---|
| Android | Per-app VPN allowlist | Package name of the process opening the socket |
| Windows | Application traffic filters | Application path in the filter rule |
| Linux | UID or cgroup routing rules | Owner of the socket, which can be a different program |
Quel processus a réellement établi la connexion
Mesurez le côté qui reçoit au lieu de raisonner à son sujet. Laissez le tunnel actif, cliquez sur un lien inoffensif et regardez les sockets que détient le nouveau programme.
ss -tnp state established '( dport = :443 )' Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess
La première commande nomme le processus derrière chaque socket établie sous Linux, et la seconde fait de même sous Windows en résolvant l’identifiant du processus propriétaire. Comparez le nom du processus avec ceux de votre politique. Si le nom est le navigateur et que le navigateur est exclu, le clic a quitté le tunnel par conception et non par défaut. Associer une règle de politique à une socket vivante, c’est toute la méthode.
Répétez le contrôle avec le gestionnaire déjà lancé, puis fermé. Les deux résultats peuvent différer, et cette différence explique la plupart des rapports intermittents sur des liens qui s’échappent d’un tunnel.
La couverture est une propriété du flux de travail
Si une tâche doit rester dans le tunnel du début à la fin, chaque composant qu’elle peut atteindre doit être dans la politique : le lanceur, le gestionnaire, la visionneuse et tout intermédiaire que la plateforme insère entre eux. Une couverture plus large est souvent la réponse honnête, et elle coûte moins cher que d’auditer chaque cible de partage.
Exclure un intermédiaire du système pour réparer une application est une erreur courante. Les intermédiaires sont partagés, donc l’exclusion suit toutes les autres applications qui empruntent le même chemin, généralement sans que personne ne le remarque avant qu’un rapport n’arrive des semaines plus tard. Lisez ce qui dépend encore du composant avant de l’exclure.
Gardez l’identité séparée du routage. Un lien peut transporter un jeton de session ou un identifiant de compte, quelle que soit la sortie qui reçoit la requête. Un clic correctement routé peut encore dire à la destination exactement qui l’a suivi.
Documentez le flux de travail, pas la première case à cocher. Quand une tâche couvre quatre programmes, le schéma avec quatre programmes est celui qui prédit où va le trafic, et le réglage d’une seule application n’en est qu’une ligne.