Le tunnel divisé exclut le navigateur, pas ses requêtes DNS

Navigateur exclu du tunnel, la page d’IP publique confirme que son trafic sort par la connexion domestique, et le wiki interne ne s’ouvre toujours pas. La résolution de noms est allée ailleurs, et cet ailleurs est généralement le résolveur configuré par le VPN. Le chemin des données et le chemin du résolveur sont des décisions distinctes dans la plupart des conceptions de tunnel divisé. Vérifiez lequel le navigateur a réellement utilisé avant de déclarer l’exclusion défaillante.

Le chemin des données et celui du résolveur se séparent

Une exclusion retire les paquets d’une application du tunnel, ce qui est une décision de routage et de pare-feu sur le chemin des données. La résolution de noms est une autre recherche : un processus interroge le résolveur du système, et ce résolveur décide quel serveur reçoit la question.

Les deux peuvent être intentionnels et différents. Un déploiement professionnel peut garder les espaces de noms internes sur le résolveur d’entreprise tout en envoyant la navigation publique choisie hors du tunnel, précisément parce que les noms internes ne se résolvent nulle part ailleurs. Le cas déroutant est l’inverse : un site public échoue parce que le navigateur n’a jamais interrogé le résolveur attendu par le déploiement. Notez la route et le résolveur séparément, et la moitié des discussions disparaît.

Trouvez quel processus pose la question

Un navigateur peut utiliser le résolveur du système, son propre service DNS chiffré, ou un résolveur que le système d’exploitation attribue par réseau. Le premier suit la politique de la plateforme, le deuxième contourne entièrement cette politique, et le troisième dépend du lien vers lequel la requête est routée.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Lisez la configuration effective avant de tester : quels liens portent des serveurs DNS, quels espaces de noms ils revendiquent, et si une politique par nom remplace la valeur par défaut. Sous Linux, le DNS divisé utilise des domaines de routage ; sous Windows, la table de politique de résolution de noms fait le même travail pour les espaces de noms. Ni l’une ni l’autre n’est visible depuis une page de test de fuite.

Décidez quel résolveur doit voir quel nom

Écrivez le mappage prévu avant de changer quoi que ce soit : noms internes vers le résolveur d’entreprise, noms publics vers le service que la politique autorise, et exceptions avec un responsable. Sans cette liste, chaque étiquette du test de fuite devient un débat de politique que personne ne peut trancher.

Vérifiez ensuite le réglage propre au navigateur, car le DNS chiffré d’un navigateur s’applique avant que le système d’exploitation ne reçoive la requête. Un utilisateur qui l’a activé pour contourner un portail captif a silencieusement remplacé le résolveur choisi par le déploiement. C’est une décision de configuration et non une fuite, et elle mérite une décision plutôt qu’une liste de blocage.

Ne réécrivez pas chaque champ DNS pour qu’une étiquette de test passe au vert. L’étiquette décrit une requête d’un processus à un instant.

Vérifiez requête et connexion séparément

Testez les deux chemins séparément. Le test de connexion montre la route des données, et le test du résolveur montre qui a reçu le nom.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Interrogez aussi le résolveur explicitement, afin qu’un échec soit attribué au serveur et non au chemin. Redémarrez ensuite le navigateur et répétez, car les applications mettent en cache les réponses négatives et un échec ancien paraît persistant.

Après un changement approuvé, notez la route des données et le destinataire du résolveur sur deux lignes distinctes avec la date. Si le comportement revient à la prochaine reconnexion, c’est le profil qui le fournit qu’il faut corriger, pas le navigateur.