Le DNS de votre VPN est-il vraiment utilisé ? Capturez le port 53 et voyez

Demandez à la plupart des gens ce qu’un client VPN fait du DNS et ils diront qu’il règle le résolveur, donc les requêtes circulent dans le tunnel. Le poussé est réel ; l’hypothèse qu’il devienne une requête ne l’est pas. Entre une option poussée et un paquet sur le fil se tiennent trois étapes, et chacune échoue indépendamment de façons qui ressemblent toutes à un serveur DNS cassé. C’est pourquoi une page de test de fuite et un navigateur qui fonctionne peuvent se contredire au sujet de la même machine au même moment.

Une option poussée n’est pas une requête

La première étape est que le serveur propose des réglages, par exemple une option DNS poussée nommant un résolveur à l’intérieur du tunnel. La deuxième étape est que le client applique ces réglages à une interface. La troisième étape est qu’une application envoie réellement une requête à cette adresse. Un échec à la deuxième étape laisse l’option visible dans le journal de connexion tandis que la liste des résolveurs reste inchangée, et un échec à la troisième étape laisse une liste de résolveurs parfaitement correcte inutilisée.

L’essentiel du dépannage fond ces trois étapes en une et blâme le serveur VPN, qui est généralement la seule partie capable de prouver qu’elle a fait sa part. Lisez plutôt l’état réel du résolveur du client, puis regardez une requête partir. Ces deux observations séparent la configuration du routage et de la politique, et elles coûtent environ cinq minutes. Gardez les captures, car l’ingénieur suivant veut l’avant et l’après plutôt qu’une description.

Vérifiez ce que l’interface détient réellement

Sous Linux, le résolveur système peut être le simple fichier, NetworkManager ou systemd-resolved, et lequel d’entre eux le possède décide où atterrit un serveur poussé. Un processus OpenVPN en ligne de commande ne met pas à jour le résolveur système de lui-même, donc l’intégration documentée est un script up/down ou un gestionnaire de connexions qui sait déjà appliquer les réglages. Lancer les deux est un moyen efficace de créer une course.

resolvectl status
cat /etc/resolv.conf

Sous Windows la liste est par adaptateur, donc l’adaptateur du tunnel peut détenir les serveurs internes tandis que l’adaptateur physique garde les locaux et gagne pour certains noms. Comparez les deux adaptateurs plutôt que celui que vous supposez actif.

Suivez une requête hors de la machine

Capturez les deux interfaces simultanément, puis résolvez un nom qui devrait utiliser le résolveur interne. Cette paire de captures répond à ce qu’aucune sortie de configuration ne peut répondre.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Une requête qui apparaît sur l’interface physique et jamais dans le tunnel signifie que le client a choisi le mauvais résolveur. Une requête sur aucune des deux signifie que l’application a répondu depuis le cache, interrogé un stub à l’écoute sur loopback ou utilisé un résolveur chiffré dont le trafic n’apparaît jamais comme port 53. Capturez aussi les réponses, pas seulement les requêtes, car une requête qui sort par le tunnel avec une réponse d’une adresse publique est une autre panne qu’aucune réponse qui arrive.

Le pare-feu qui n’accepte que son propre DNS

Les clients commerciaux installent parfois leurs propres chaînes de filtrage. Un modèle documenté autorise le DNS vers le résolveur propre du client et jette tout le trafic UDP restant sur le port 53 qui tente de quitter une interface non loopback, y compris le trafic que l’utilisateur a délibérément routé ailleurs. Les requêtes du démon disparaissent sans trace, ce qui se lit comme une panne du résolveur plutôt que comme un filtre.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Si une règle de rejet est évaluée avant votre exception, une règle ajoutée à la fin n’est jamais atteinte, donc insérez-la en première position et limitez la destination au résolveur que vous visez réellement.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Cette exception est diagnostique plutôt que politique. Si la règle du fournisseur est délibérée, la réparation prise en charge consiste à configurer le client pour autoriser ce résolveur et à consigner la décision, car une règle insérée ne survivra pas à la prochaine mise à jour du client.

Pourquoi une page de fuite prouve moins qu’il n’y paraît

Ce qu’une page de test de fuite montre, c’est le résolveur qui a parlé à l’opérateur du test, pas celui que votre machine a consulté. Un relais local qui récurse vers l’extérieur met sa propre adresse de sortie sur cette page, et les requêtes chiffrées peuvent laisser la page entièrement vide. Les deux résultats sont mal lus, l’un comme fuite et l’autre comme garantie, et aucune des deux lectures ne découle de l’observation.

La preuve défendable est la capture : interface, adresse de destination, réponse et horodatage. Prenez-en une avant que le tunnel monte et une après, et comparez-les la prochaine fois qu’un nom échoue. Cette paire dit aussi à la personne suivante si la panne venait de la résolution, du routage ou de la politique d’accès du résolveur lui-même.