Le filtrage DNS par VPN a empêché un site de se charger : lisez la réponse
Un résolveur filtrant peut bloquer un seul nom pendant que le tunnel fonctionne. Lisez le type de réponse, découvrez à qui appartient le résolveur et ne changez que ce que vous contrôlez.
Un nom échoue alors que le tunnel est actif, et le navigateur parle d’une erreur réseau, alors que la cause réelle est la réponse DNS que le résolveur a renvoyée. Un résolveur filtrant peut retenir, refuser ou réécrire un seul nom et laisser toutes les autres requêtes fonctionner. Le tunnel transporte la requête ; le résolveur décide de la réponse. Examinez cette réponse avant de toucher aux paramètres de chiffrement.
Le tunnel est actif, donc le chiffrement n’est pas le suspect
L’état de la connexion vous dit si les paquets circulent, pas si un nom se résout. La résolution est une requête vers le serveur avec lequel le client est configuré, et une politique locale peut répondre à un domaine autrement qu’à tous les autres. Côté navigateur, toutes ces réponses se fondent en une erreur générique, et c’est pourquoi le voyant d’état prouve si peu.
Notez d’abord trois choses : le résolveur utilisé par le client, le code de réponse du nom qui échoue et la même requête pour un nom qui devrait fonctionner. Interrogez le résolveur directement avec dig example.com @10.20.0.1 et lisez la ligne d’état, pas le message du navigateur. Si le nom de contrôle se résout et que celui qui échoue renvoie une réponse de politique, la preuve est complète. Si les deux échouent, le filtre n’est pas encore en cause.
Quatre réponses, quatre propriétaires différents
Un résolveur filtrant n’a pas une seule façon de dire non, et la forme du refus indique une étape suivante différente. Notez le code de réponse, car le navigateur réécrit les quatre en quelque chose qui ressemble à une connexion coupée.
| Answer | What it points at |
|---|---|
| NXDOMAIN | The name is withheld: a policy entry or a zone decision removed it |
| Refused | The resolver declines to answer; usually an access or policy rule |
| Replacement address | A redirect to a block page or sinkhole you can query and inspect |
| No answer at all | Weakest evidence: reachability, load or routing, not necessarily policy |
Comparez la réponse au tableau avant d’attribuer quoi que ce soit au tunnel. Un refus et un nom retenu signifient tous deux que le résolveur a pris une décision, tandis que le silence signifie que la requête n’a jamais reçu de réponse. Cette différence décide si vous poursuivez un propriétaire de politique ou un chemin réseau.
Deux navigateurs peuvent suivre deux politiques
Un navigateur qui embarque son propre résolveur chiffré n’a pas besoin d’utiliser le serveur que le système d’exploitation distribue, il peut donc ignorer la politique pour laquelle le tunnel a été construit. Deux navigateurs sur une même machine se contredisent alors sur le même nom d’hôte, et aucun n’est en panne. Vérifiez à quel résolveur chaque application est liée avant de qualifier le filtre d’incohérent.
Lorsque les deux applications utilisent le résolveur du tunnel et qu’une seule échoue, la différence est dans l’application, pas dans DNS. Notez l’adresse du résolveur par application, car ce détail disparaît à la fermeture de la fenêtre.
Changez ce qui vous appartient, escaladez ce qui ne vous appartient pas
Votre prochaine étape dépend de qui possède le résolveur vers lequel vous pointez. Celui que vous exploitez vous-même est une fonction que vous pouvez lire et configurer : vérifiez l’option de filtrage documentée et ses exceptions, puis autorisez le nom concerné. Celui que votre employeur ou votre fournisseur exploite est un ticket avec le domaine, la réponse exacte et l’heure.
Ne remplacez jamais par un résolveur public pour forcer l’ouverture du site, car les noms privés cessent de se résoudre et une politique délibérée cesse de s’appliquer. Le changement étroit garde aussi la preuve intacte, pour que le propriétaire puisse comparer votre rapport à ses propres enregistrements. Après le changement, refaites le test d’origine de l’application plutôt qu’une requête depuis un shell.
Une page de blocage n’est pas un certificat de confiance
Une page de remplacement qui présente son propre certificat déclenchera un avertissement d’identité HTTPS, et la redirection ne rend pas ce certificat valide. Ne cliquez pas à travers elle parce que le tunnel est actif ; l’avertissement est une décision de confiance distincte qui doit tout de même être correcte.
Le diagnostic se ferme lorsque le nom qui échoue renvoie une réponse de politique et qu’un nom de contrôle en renvoie une normale via le même résolveur. À ce stade, la réparation est un changement de politique, pas un changement de tunnel, et les RFC 1035 codes de réponse sont ce que vous citez dans le rapport. Gardez les deux noms et les réponses ensemble ; c’est toute l’affaire.