Le tunnel est actif, alors pourquoi le nom privé échoue-t-il encore ?

Tout dans la connexion semble correct : le tunnel est actif et la console affiche le point de terminaison privé, mais chaque requête échoue à la résolution de noms. Le réflexe naturel est d'accuser le tunnel, qui s'avère généralement innocent. La requête est envoyée à un serveur qui ne sait rien de la zone privée. Aucun changement de routage ne modifiera cette réponse, car le problème est de savoir à qui l'on a demandé.

Quel résolveur la requête a-t-elle atteint ?

Trouvez le résolveur attaché à chaque lien avant même de regarder le tunnel. Linux expose les serveurs par lien via la commande d'état du résolveur, et macOS affiche les résolveurs à portée dans sa sortie de configuration DNS. Si la réponse vient encore de la box domestique, le lien du tunnel n'a jamais été consulté.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Deux étapes sont confondues ici : un serveur qui pousse une adresse de résolveur, et un client qui l'installe sur le lien actif. Un profil peut contenir l'option, et un journal peut montrer son arrivée, alors que le système d'exploitation continue d'utiliser l'ancien serveur. Comparez le journal à ce que le lien rapporte, et faites confiance au lien.

Utilisez une adresse à laquelle le réseau cloud répond vraiment

Les réseaux cloud répondent généralement aux noms privés via une adresse réservée décalée de deux depuis la base de la plage, ainsi un réseau commençant à 10.0.0.0 répond à 10.0.0.2. Certains fournisseurs publient aussi un résolveur local au lien qui fonctionne sans connaître la plage, ce qui aide lorsque le réseau a été construit par quelqu'un d'autre. Interrogez directement l'adresse candidate avant de la pousser à qui que ce soit. Une adresse qui n'est pas un résolveur ressemble exactement à un rejet du pare-feu, car la requête ne reçoit tout simplement jamais de réponse.

Si la requête directe répond depuis l'intérieur du réseau mais pas à travers le tunnel, le résolveur est correct et le chemin entre les deux points ne l'est pas. Ce résultat déplace l'enquête vers les routes, le transfert et les règles d'accès plutôt que vers le profil du client.

Un tunnel ne transporte pas l'espace de noms

Les paquets passent ; les noms non. Chaque côté doit savoir quel espace de noms appartient à l'autre, et c'est un objet distinct détenu par celui qui possède la zone. La forme habituelle est un transfert pour un espace de noms, pointé vers un résolveur joignable par le tunnel.

En pratique, chaque direction a besoin de sa propre règle, car le côté qui possède la zone doit transmettre la requête. Les deux directions exigent que la source de la requête soit routée et autorisée, et le côté qui répond doit renvoyer les réponses par le tunnel plutôt que vers Internet. Gardez le transfert étroit, afin que seul l'espace de noms privé dépende du lien. Envoyer chaque requête à travers lui transforme une petite dépendance en panne totale à l'instant où le tunnel tombe.

Parcourez les frontières dans l'ordre

Testez le résolveur installé sur le lien actif, puis une requête directe à ce résolveur, puis la même requête depuis le côté distant, et enfin l'application qui utilise le même nom. Chaque étape isole une frontière, ainsi un échec vous indique où regarder au lieu de relancer l'enquête. Une réponse qui fonctionne alors que l'application échoue indique la confiance dans le certificat ou une politique API plutôt que le DNS. Ces défauts sont réels, et aucun changement de résolveur ne les réparera.

Notez quelle étape a échoué. Cette seule ligne est ce dont la personne suivante a besoin, et l'enregistrer prend dix secondes.

Gardez la chaîne là où la personne suivante peut la trouver

Consignez le résolveur poussé, la règle de transfert, la source de requête autorisée et le point de terminaison qui répond au même endroit. Lorsque le nom privé échoue à nouveau, le registre montre si le tunnel a bougé, si l'adresse du résolveur a changé ou si une règle a été resserrée. Sans lui, chaque incident repart de zéro et se termine par les mêmes trois suppositions.

Gardez le registre assez court pour rester exact : quatre lignes, une date et le nom de celui qui possède chaque partie. Un registre périmé est pire qu'aucun, car il paraît faisant autorité alors qu'il est faux.