Pourquoi un point d'accès redirige-t-il le DNS avant que le VPN ne se connecte ?
Un point d'accès réécrit les requêtes sur son propre réseau, et un point de terminaison en nom d'hôte est résolu avant qu'aucun tunnel n'existe. Suivez quel résolveur a répondu à chaque requête.
Rejoindre un réseau d'hôtel place deux décisions DNS devant vous à des moments différents : les requêtes que l'appareil effectue pendant la connexion, et celles effectuées une fois le tunnel établi. Un point d'accès peut influencer les premières via le réseau qu'il contrôle. Les secondes dépendent de la politique du client lui-même, ce qui est une chose distincte à examiner.
Parcourez la connexion dans l'ordre, du premier bail DHCP à la requête qui a résolu un nom privé. Deux pannes qui semblent identiques dans un ticket d'assistance se séparent alors nettement : l'une s'est produite avant l'existence du tunnel, l'autre à l'intérieur de celui-ci.
Ce que le point d'accès peut toucher et ce qu'il ne peut pas
Le réseau d'accès distribue une adresse de résolveur via DHCP et peut intercepter le port 53 vers cette adresse. Cela suffit pour répondre à chaque requête non protégée par une adresse de portail ou une page de blocage. Cela suffit aussi à casser un client VPN dont le point de terminaison est écrit comme un nom d'hôte.
Ce que le point d'accès ne peut pas faire, c'est lire ou réécrire une requête une fois qu'elle circule dans un tunnel établi, à supposer que le tunnel la transporte réellement. L'interception suppose de voir la question en clair.
Les requêtes quittent tout de même le tunnel pour des raisons étrangères au point d'accès : le réglage DNS sécurisé du navigateur, une règle de split-DNS qui garde un suffixe d'entreprise sur le résolveur local, ou un client configuré pour exclure le DNS du tunnel. Chacune est un choix côté client, et chacune ressemble à une interférence du point d'accès vue de l'extérieur.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
La requête d'amorçage a lieu avant que le tunnel n'existe
Un client à qui l'on donne un nom d'hôte doit d'abord le résoudre, et à cet instant aucun tunnel ne protège la requête. Si le point d'accès répond par une adresse de portail, la négociation échoue ou se bloque. S'il ne répond rien, le client signale une erreur de nom et le tunnel ne démarre jamais. L'un ou l'autre résultat explique un journal de tunnel vide qui, sinon, paraît anodin.
Les systèmes d'exploitation effectuent aussi leurs propres contrôles de connectivité et leur découverte de portail, décrits dans les RFC 8910 et RFC 8952, et ces requêtes sortent avant qu'aucun VPN ne soit actif. Les voir dans un journal de proxy est un comportement attendu et non la preuve d'une fuite.
Le correctif pratique consiste à donner au client un point de terminaison qui ne nécessite aucune requête. Quand cela est impossible, terminez d'abord la connexion, puis connectez-vous.
Déterminez quel résolveur a répondu
Interrogez le système plutôt que le navigateur, et exécutez la requête deux fois : une fois via le résolveur que l'appareil utilise actuellement, une fois contre une adresse fixe.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Une réponse de la première commande différente de la troisième vous indique que le résolveur local renvoie autre chose, ce que fait justement un point d'accès qui redirige. Un échec de la troisième accompagné d'un succès de la première désigne le portail : le résolveur local a servi une adresse de connexion tandis que le port 53 sortant était abandonné. Des délais d'attente sur les deux signifient que le réseau écarte le DNS jusqu'à la fin de l'authentification.
Répétez après la connexion et comparez. Une réponse en cache survit à la transition, alors videz le cache ou interrogez un nouveau nom pour la seconde observation.
Gardez les résolutions ultérieures sur le chemin voulu
Un profil de tunnel complet qui capture aussi le DNS est l'arrangement le plus simple : chaque requête de chaque application va au résolveur imposé par le tunnel, et le réseau local ne voit que du trafic chiffré. Prouvez-le en résolvant un nom interne et un nom public après la connexion, puis en comparant les deux réponses avec ce que le résolveur du tunnel renvoie seul.
Le split-DNS exige une liste de domaines écrite avec intention : les suffixes d'entreprise par le tunnel, tout le reste en local, et aucun chevauchement entre les deux.
Le DNS sécurisé du navigateur se situe hors de cette politique, donc s'il doit être désactivé pour que le profil se comporte de manière prévisible, désactivez-le pour ce profil et non pour la machine. Faites-le dans les réglages du navigateur, pas en modifiant le résolveur système, afin que le changement soit visible la prochaine fois. Notez la réponse, le résolveur et l'étape de connexion sur une ligne par test. Un rapport disant que le DNS a échoué sur le Wi-Fi de l'hôtel décrit un symptôme ayant au moins trois causes différentes.