Le DNS privé de Pritunl échoue ? Ajoutez une route de résolveur étroite

Les noms privés se résolvent pour tout le monde sur le réseau d’entreprise et expirent pour tout le monde sur le VPN. Le résolveur répond à la passerelle, la route vers celui-ci existe, et la requête ne reçoit toujours aucune réponse. Ce qui manque n’est pas un autre résolveur public ni une route plus large : c’est une adresse source à laquelle le serveur DNS privé accepte de répondre.

Confirmez que le résolveur refuse votre pool de clients

Commencez par prouver que la panne concerne la source et non la joignabilité. Depuis un client connecté, interrogez directement le résolveur privé et observez si la requête expire ou revient comme un refus. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 qui expire alors que la même requête depuis la passerelle réussit indique une politique d’accès sur le résolveur. Une réponse SERVFAIL indique un endroit complètement différent, généralement la zone ou le redirectionnaire amont.

Notez l’adresse du client avant de tester. ip -4 addr show tun0 sur le client, ou le bail affiché dans la console, vous dit quel pool le résolveur voit.

Confirmez ensuite que le chemin existe. Une route qui envoie l’adresse du résolveur dans le tunnel est un préalable, pas la solution ; si les paquets n’arrivent jamais, la politique de source n’est jamais consultée. Vérifiez-le avec ip route get 10.40.0.53 sur le client.

Ajoutez une route d’hôte au lieu de tout traduire

Le guide DNS privé de Pritunl décrit le remède étroit : une route /32 avec NAT pour l’adresse du résolveur, cette adresse étant choisie comme serveur DNS des clients. La route change la source que le résolveur voit uniquement pour le trafic DNS. Le trafic applicatif conserve la conception préservant la source que vous avez choisie pour lui.

Configurez-la via le propriétaire de routes pris en charge du serveur, après avoir vérifié les routes existantes pour tout chevauchement. Dans l’exemple ci-dessus, la destination est 10.40.0.53/32 avec NAT activé, et le pool de clients reste 10.90.0.0/24. Ne traduisez pas toute la plage privée pour corriger un seul service, car chaque politique en aval qui repose sur l’adresse réelle du client commencera à voir la passerelle à la place. Confirmez l’adresse que le résolveur reçoit réellement en observant son journal de requêtes pendant une recherche de test. Une route d’hôte seule ne prouve rien sur la traduction ni sur l’autorisation.

Le résolveur doit encore autoriser la source traduite sur UDP et TCP, et ses réponses doivent pouvoir revenir. Changer la source ne peut pas créer une zone ni un enregistrement manquant.

Décidez si le serveur ou le client envoie la requête

Pritunl documente aussi un dispositif de proxy DNS lié à VPN Client DNS Mapping, où le serveur transfère les requêtes amont pour les clients. Dans ce modèle, la source amont appartient au contexte réseau propre au serveur, et une exception côté client est la mauvaise solution.

Identifiez quel modèle est actif avant d’ajouter quoi que ce soit. Trois réparations qui se chevauchent, un proxy, un remplacement du résolveur côté client et un script NAT manuel signifient généralement que personne n’a établi : quel composant est censé envoyer la requête. Vérifiez aussi le bootstrap : un résolveur uniquement privé ne peut pas être le seul moyen de trouver le point de terminaison avant que le tunnel existe, et une modification permanente du résolveur ne devrait pas survivre à la connexion.

Testez une recherche privée, pas une page web publique

Après avoir appliqué le changement et vous être reconnecté, inspectez la configuration effective du résolveur du client, puis résolvez un nom dont vous savez qu’il n’existe que dans la zone privée. dig intranet.example.net sans serveur explicite montre ce que le client utilise réellement. Faites suivre d’une requête vers l’adresse renvoyée par cette recherche, car la résolution et l’accès au service sont des étapes distinctes. Un navigateur qui charge des sites publics via DNS-over-HTTPS ne prouve rien sur le chemin du résolveur privé du système d’exploitation. Un résolveur secondaire public n’est pas non plus une autorité pour une zone interne.

Notez l’adresse du résolveur, la route /32 et le paramètre DNS du client ensemble dans les notes du serveur. La moitié de cette configuration restaurée seule reproduit la panne d’origine.

Enfin, confirmez que le tunnel achemine toujours la destination de l’application après la réussite du DNS. La route, l’accès au service et l’authentification restent indépendants de la résolution de noms, et une recherche qui fonctionne ne dit rien sur le débit. Si la page privée est lente mais se résout, le résolveur a fait son travail et le problème s’est déplacé vers le chemin.