Comment le tunnel fractionné décide quel trafic utilise le VPN

Le tunnel fractionné est une politique de routage exprimée sous forme d’un ensemble de règles, et le client n’est que ce qui les installe. La séparation se produit à deux endroits : des règles de correspondance qui choisissent un chemin pour chaque paquet, et des liaisons qui maintiennent une application sur une interface quoi que dise la table. Le mécanisme sur lequel votre client s’appuie explique la plupart des surprises que les gens signalent.

Une politique que vous pouvez énoncer en une ligne est testable. Une politique décrite comme une navigation plus rapide ne l’est pas, et elle ne vous dira pas quelle règle changer quand une requête part du mauvais côté.

Le client installe des règles, le noyau fait le choix

Quand le tunnel monte, le client ajoute des routes et souvent des règles de politique à la même table que vos autres interfaces utilisent. Chaque paquet atteint alors une recherche qui compare sa destination à chaque préfixe candidat et garde la correspondance la plus spécifique, tandis que la priorité tranche les égalités entre des règles qui pointent vers des tables différentes. Rien dans cette recherche ne sait que le paquet vient d’un onglet de navigateur plutôt que d’une tâche de sauvegarde. La règle qui gagne est celle qui fixe le chemin, et vous pouvez la lire avant et après le changement.

C’est pourquoi un tunnel fractionné peut sembler arbitraire. Deux destinations dans une même application peuvent emprunter des chemins différents simplement parce qu’un préfixe est plus étroit que l’autre.

Le même choix existe sur chaque plateforme, même si les noms changent. Windows pousse la décision dans sa plateforme de filtres, Android expose une liste d’autorisations par application via son service VPN, et macOS attache le tunnel à un périphérique qui obéit encore à la table de routage. Les notes de routage de Microsoft valent la lecture pour le cas Windows, et un guide écrit pour une plateforme se transpose rarement sans changement sur une autre.

La liaison par application et les préfixes de destination sont des outils différents

Une politique de destination demande où va le paquet et consulte la table de routage ou une règle de politique. Une politique par application demande quel programme a ouvert la socket, et la plateforme maintient ce programme sur l’interface du tunnel même quand une route plus précise pointe ailleurs. La seconde est plus forte parce qu’elle survit aux changements de table, mais elle ne couvre que les processus que la plateforme peut attribuer. Un processus auxiliaire, un navigateur intégré ou un service qui ouvre sa propre connexion peut ne pas hériter de la liaison que vous supposiez.

Aucune des deux approches ne survit à une politique fondée sur les noms sans aide. Les adresses des grands sites tournent entre les réseaux de contenu, si bien qu’épingler un nom d’hôte à quelques préfixes produit une règle qui cesse discrètement de correspondre. Une politique qui doit suivre des noms a besoin d’un composant conscient du résolveur plutôt que d’une route statique.

Le DNS et l’interrupteur d’arrêt suivent leurs propres règles

La résolution de noms est une décision distincte du routage des paquets, et un tunnel fractionné veut généralement deux résolveurs : celui de l’entreprise pour les noms internes, celui local pour tout le reste. Le client peut installer des paramètres DNS par interface, remettre les requêtes à un résolveur relais ou laisser la valeur par défaut du système intacte. Un navigateur doté de son propre résolveur chiffré contourne les trois dispositions. Testez une requête au lieu de supposer que le résolveur a suivi la route.

Un interrupteur d’arrêt ajoute un filtre par-dessus, et ce filtre ne distingue pas toujours une exclusion voulue d’une fuite accidentelle. Certains clients bloquent tout hors du tunnel tandis que d’autres autorisent les exclusions que la politique déclare, alors lisez le comportement que le vôtre applique avant de vous fier à l’un ou l’autre.

Vérifiez la séparation des deux côtés

Testez le chemin inclus et le chemin exclu séparément, et jugez le résultat au nom de l’interface plutôt qu’à une adresse publique. Ces commandes supposent un hôte Linux dont le périphérique de tunnel est déjà levé. Remplacez 203.0.113.10 par une destination que votre politique route vers l’intérieur, et 198.51.100.25 par une qu’elle envoie vers l’extérieur.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Lisez les deux premières réponses ensemble, car l’interface nommée dans chacune montre si la séparation a placé cette destination sur le tunnel. La requête au résolveur montre quel serveur a répondu au nom interne, et la dernière commande prouve que le périphérique de tunnel peut acheminer une requête. Un échec sur la deuxième ligne alors que la première réussit signifie que la politique fait exactement ce qu’on lui a dit.

Répétez l’ensemble après une reconnexion et après un changement de réseau. Le renouvellement du bail et le brassage des interfaces sont là où une séparation cesse de correspondre à l’intention pour laquelle elle a été construite, et une sortie enregistrée à chaque exécution rend la dérive évidente.