Comment lire le routage DNS VPN par lien depuis resolvectl

Lancez resolvectl status et vous obtenez un mur de blocs par lien, chacun avec ses propres serveurs et sa propre ligne de domaines. La ligne qui décide du routage est la liste de domaines, pas l'adresse du serveur de noms, car le stub local transmet chaque requête au lien qui revendique le nom. Lisez ces revendications avant de lire la réponse, puis interrogez le nom et vérifiez quel lien l'a produit. Une mauvaise réponse du bon lien est un problème différent d'une bonne réponse du mauvais lien.

Ce que chaque bloc par lien vous dit

Chaque bloc liste les serveurs que le résolveur utilisera pour cette interface, la liste de domaines et si le lien est la route par défaut. La liste de domaines est un ensemble de revendications, et le résolveur applique la correspondance du suffixe le plus long : une requête pour host.corp.example est revendiquée par un lien portant corp.example avant un lien ne portant que la route par défaut. Deux liens qui revendiquent le même suffixe laissent le résultat à la priorité et à l'ordre, c'est pourquoi les doublons méritent l'attention en premier. La ligne du serveur courant montre lequel des serveurs listés est utilisé à ce moment-là.

Une adresse stub comme 127.0.0.53 dans /etc/resolv.conf dit seulement que le stub est devant. Elle ne nomme pas l'amont qui a répondu, c'est pourquoi un diagnostic fondé sur resolv.conf seul s'enlise.

Lisez correctement les trois types d'entrée de domaine

Le tilde change le comportement de recherche, pas le routage. Une entrée sans tilde est à la fois un domaine de routage et un domaine de recherche, donc les noms en dessous sont envoyés à ce lien et les noms à une seule étiquette reçoivent le suffixe. Une entrée avec tilde route le même suffixe tout en le gardant hors de la liste de recherche. C'est pourquoi retirer un tilde change quels noms nus se résolvent, et pourquoi un tilde manquant est un problème de recherche et non une panne de DNS divisé.

L'entrée de route par défaut revendique tout ce qu'aucun autre lien ne couvre. Un profil de tunnel complet la veut généralement et un profil divisé généralement pas, car les noms publics voyagent alors vers le résolveur privé et peuvent y échouer. Lisez le tableau selon l'intention du profil au lieu de copier des indicateurs entre profils. Quand deux liens revendiquent le même suffixe, réglez la question de priorité avant de modifier autre chose.

Interrogez un nom et voyez quel lien a répondu

La sous-commande query imprime l'adresse, le protocole et le lien ou la portée qui ont produit la réponse. Testez un nom que le suffixe privé devrait revendiquer et un nom public ordinaire, puis comparez les sources signalées. Si le nom privé répond depuis le lien sans fil, la revendication manque ou le tunnel est en panne ; si un nom public sur un profil divisé répond depuis le tunnel, la route par défaut est trop large. Ces deux échecs se ressemblent dans un navigateur et s'opposent dans cette sortie.

resolvectl status
resolvectl query host.corp.example

Surveillez aussi le protocole signalé, car une réponse en cache ou issue du fichier hosts peut arriver sans qu'aucun amont soit interrogé. Une réponse issue du cache prouve que le nom s'est résolu à un moment donné, pas que la politique actuelle le route correctement.

Gardez le routage des noms séparé du routage des paquets

Une décision du résolveur ne crée pas de chemin. Le serveur choisi a encore besoin d'une route vers son adresse, et l'adresse renvoyée a encore besoin d'une route vers le réseau privé, si bien qu'une politique DNS correcte peut coexister avec une connexion qui ne s'ouvre jamais. Quand un nom se résout et que l'application échoue, inspectez l'adresse et la route au lieu de changer DNS de nouveau. La résolution de noms et l'accessibilité sont deux questions avec deux propriétaires différents.

Les applications peuvent contourner entièrement le résolveur du système via leur propre réglage DNS sécurisé ou un résolveur intégré. Le résultat de resolvectl décrit le chemin du système, et un navigateur qui l'ignore sera en désaccord avec chaque test que vous faites. Vérifiez ce réglage avant de conclure que la politique est cassée.

Notez l'adresse vers laquelle le nom s'est résolu à côté du lien. Un nom correct pointant vers la mauvaise adresse est un problème d'enregistrement, pas de routage.

Revérifiez après le changement de lien

Une reconnexion ou un changement de réseau sans fil reconstruit l'état du lien, et un gestionnaire de réseau peut réinstaller ses domaines et serveurs par-dessus tout ce qui a été réglé à la main. Interrogez ensuite les deux mêmes noms et comparez avec la ligne de base enregistrée. Si une modification manuelle a disparu, la correction appartient au profil de connexion et non à une commande shell. C'est l'enregistrement avant et après qui rend cela visible.

Ne partagez que les noms et le contexte de serveurs dont le rapport a besoin, car les suffixes internes révèlent la topologie. La documentation de systemd-resolved sur le routage des domaines couvre la règle de la correspondance la plus longue et le comportement du tilde, et une seule lecture évite la plupart des erreurs du tableau ci-dessus : routage des requêtes dans systemd-resolved.