Le DNS ne résout plus quand le kill switch du VPN bloque le port 53
Un kill switch peut bloquer le DNS volontairement. Comparez la résolution uniquement dans le tunnel avec une exception pour un résolveur local, puis déterminez quelle couche a réellement échoué.
Quand le kill switch fait tomber le tunnel, il emporte le chemin du DNS avec lui, et le résolveur qui reste n'est que rarement celui que vous attendez. Deux conceptions abordent ce moment très différemment : bloquer tous les paquets DNS qui ne sont pas dans le tunnel, oulaisser un résolveur debout comme exception. Les deux se défendent. Depuis un onglet de navigateur, les symptômes semblent presque identiques, donc le premier travail est de déterminer quelle conception vous avez réellement déployée.
Je garde cette distinction sous les yeux, car le correctif est opposé dans chaque cas. Une conception a besoin d'une exception plus large, l'autre d'une plus étroite. Deviner vous coûte soit la confidentialité, soit un après-midi.
Deux conceptions DNS pour la même panne
La conception A traite le résolveur comme un service parmi d'autres derrière le tunnel. Les règles du pare-feu autorisent UDP et TCP 53 uniquement sur l'interface du tunnel, et l'adresse remise au client est un résolveur à l'intérieur du tunnel. Quand le tunnel tombe, les requêtes s'arrêtent, et c'est le résultat voulu, pas une panne.
La conception B garde un résolveur joignable sur le réseau local, généralement le routeur en 192.168.1.1 ou le stub du système d'exploitation en 127.0.0.53, au motif que la résolution de noms ne devrait pas mourir avec le tunnel. C'est pratique sur un LAN domestique où le routeur résout pour toute la maison. Sur le Wi-Fi d'un hôtel ou d'un aéroport, la même exception pointe vers le serveur de quelqu'un d'autre, et chaque nom que vous tapez est divulgué même si votre trafic web reste bloqué.
La frontière, c'est qui possède le résolveur. Si vous faites confiance au résolveur local, une exception est un trou petit et honnête. Sinon, la conception tunnel uniquement est la seule qui tienne, et le prix est qu'un tunnel tombé emporte tous les noms.
Pourquoi la résolution du client VPN lui-même fonctionne encore
Le client doit résoudre le nom d'hôte de la passerelle avant qu'un tunnel existe, donc un blocage strict ne doit pas couvrir le chemin d'amorçage du client. La plupart des clients mettent en cache l'adresse du point de terminaison ou fournissent une exception d'amorçage documentée pour cet hôte unique. Si votre jeu de règles bloque cette résolution, le tunnel ne revient jamais et les journaux montrent un client qui n'atteint pas son propre serveur, ce qui est un défaut de politique et non de DNS.
Le DNS scindé est l'autre endroit où cela apparaît. Le client pousse une zone interne vers un résolveur privé et laisse tout le reste au résolveur système. Après une chute, les noms publics peuvent encore se résoudre tandis que les internes expirent, car la zone privée n'a plus de route. Pour l'utilisateur, c'est « le VPN a cassé internet » ; pour le journal du résolveur, c'est une requête qui n'est jamais arrivée.
Avec systemd-resolved, vous voyez la scission directement.resolvectl statusliste les serveurs DNS par lien et les domaines de routage, et une fois le tunnel tombé, le domaine interne continue de pointer vers un serveur sur un lien qui n'existe plus. Le stub en 127.0.0.53 accepte encore la requête, puis attend un amont qui ne répondra pas, et c'est pourquoi la panne prend des secondes au lieu de revenir immédiatement.
Le DNS chiffré ne contourne pas un filtre de paquets
DNS over HTTPS et DNS over TLS passent par 443 et 853, donc une règle qui bloque le port 53 n'a rien dit à leur sujet. Bloquer « DNS » par port est une politique sur un port, pas sur la résolution de noms. Si votre kill switch bloque tout le trafic hors du tunnel, DoH est couvert par accident. Si vous avez ménagé une autorisation pour un portail captif ou un résolveur public, il ne l'est pas.
Les contrôles côté client sont le levier le moins cher. Firefox abandonne son résolveur DoH quand le nom canariuse-application-dns.netne se résout pas, et c'est pourquoi les réseaux gérés publient ce domaine en NXDOMAIN ; une politique d'entreprise peut aussi le figer désactivé. Android Private DNS et le DNS sécurisé de Chrome ont leurs propres commutateurs et leurs propres valeurs par défaut. Les désactiver est plus fiable que de courir après les adresses de résolveurs, car la liste d'adresses change et votre jeu de règles non.
Il existe une version de cela qui ne parle pas du tout de fuites. Une application avec un résolveur épinglé a toujours besoin d'un chemin réseau pour l'atteindre. Le chiffrement change qui peut lire la requête, pas si le paquet peut quitter la machine, donc un blocage de l'appareil entier défait le réglage sans y toucher.
Associez le symptôme à la couche
La plupart des signalements arrivent en une phrase, et cette phrase nomme souvent déjà la couche. Le tableau ci-dessous est ce que je passe en revue avant de toucher une règle ; le but est de décider si la requête a été bloquée, mal dirigée ou jamais envoyée.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Les deux premières lignes sont celles que les gens diagnostiquent mal. Une chute silencieuse et un refus ressemblent tous deux à « le DNS est cassé » dans un navigateur, mais un seul des deux signifie que votre kill switch fait son travail. Un refus signifie que quelque chose a répondu, donc le blocage n'est pas là où vous croyez.
Rétablissez la politique de résolution, puis prouvez-la
Corrigez la conception, pas le symptôme. Pour une résolution tunnel uniquement, autorisez 53 sur l'interface du tunnel, poussez le résolveur interne avec la configuration du tunnel et laissez le lien physique sans aucune autorisation DNS. Avec wg-quick, la ligneDNS =est celle qui écrit le résolveur dans la configuration de l'interface, donc un tunnel qui l'omet laisse l'ancien résolveur en place et chaque requête sur le mauvais chemin.Le manuel de wg-quickdocumente ce comportement par plateforme.
Vérifiez ensuite dans cet ordre. Sous Linux,resolvectl statusaffiche le lien actif,dig +short example.comteste un nom public,dig @10.8.0.1 internal.example.comteste le privé, etsudo tcpdump -ni any port 53montre quelle interface les paquets utilisent pendant que vous exécutez les deux. Sous Windows,Get-DnsClientServerAddress -AddressFamily IPv4etResolve-DnsName example.comdonnent les deux mêmes faits : qui est configuré, et qui répond.
Terminez par le test négatif. Déconnectez le tunnel, confirmez qu'un nom public neuf échoue, confirmez que le nom privé échoue, etconfirmez qu'aucun paquet du port 53 n'a quitté l'adaptateur physique. Un blocage qui ne tient que pour des réponses en cache ne tient pas du tout.
Liste de vérification avant de fermer le ticket :
- Le résolveur utilisé pendant la panne est celui que la politique prévoit.
- La résolution du point de terminaison par le client reste autorisée, par cache ou par exception.
- DoH et DoT sont soit couverts par le blocage, soit désactivés par politique.
- Les zones privées échouent fermées, pas ouvertes, une fois le tunnel disparu.