OpenVPN a poussé un serveur DNS, mais Linux l’ignore

Le serveur DNS poussé est dans le journal, le tunnel est monté et les noms internes échouent toujours. Rien n’est cassé dans la poussée elle-même ; le réglage est arrivé et s’est arrêté là. Une option DNS poussée est un message au client, pas une instruction au résolveur du système d’exploitation, et la remise entre les deux est là où la plupart de ces cas se terminent. Cinq vérifications, dans l’ordre, trouvent la remise qui n’a pas eu lieu.

Vérification une : comment la connexion démarre

Le propriétaire de la connexion détermine qui peut appliquer les réglages du résolveur. Une commande openvpn directe depuis un shell ne possède rien d’autre que son propre processus, tandis qu’une unité systemd, NetworkManager ou un client d’éditeur ont chacun leur propre façon de publier le DNS. Lisez la liste des processus et le nom de l’unité avant d’en supposer un seul.

Un processus en ligne de commande n’est pas automatiquement une connexion NetworkManager, et une connexion NetworkManager n’est pas automatiquement ce qui a écrit resolv.conf. Ces deux suppositions expliquent la plupart des heures perdues dans cette enquête. Demandez quel composant publierait le DNS pour l’interface que vous voyez réellement.

Notez le propriétaire avant de continuer. Chaque vérification ultérieure en dépend.

Vérification deux : ce que le lien du résolveur contient réellement

Sur un hôte systemd-resolved, resolvectl status liste chaque lien avec ses serveurs DNS et ses domaines. Trouvez le lien du tunnel et lisez ses entrées, et ne supposez pas que l’interface s’appelle tun0, car la numérotation suit l’ordre de création. Si l’adresse poussée est absente du lien, c’est la remise qui a échoué, pas la requête.

Si l’adresse est présente, la question suivante est quels domaines ce lien revendique. Un lien sans liste de domaines ne répond qu’aux noms pour lesquels on l’interroge directement, ce qui est rarement ce que veut un déploiement split-DNS. L’adresse seule est nécessaire mais pas suffisante.

Comparez le nom du lien dans la sortie du résolveur avec le nom de l’interface dans le journal du VPN avant de tirer une conclusion. Un écart à cet endroit signifie généralement que la ligne du journal vient d’un autre processus.

Vérification trois : si l’espace de noms choisit ce lien

Un résolveur peut contenir le bon serveur et ne pas être consulté pour autant. Le domaine par lien décide quelles requêtes vont vers quel lien, et sans domaine de routage l’espace de noms privé retombe sur ce que dit le lien par défaut. C’est pourquoi resolvectl query peut réussir pour le nom interne alors qu’une application échoue encore. L’application utilise peut-être un chemin de résolveur complètement différent.

Vérifiez l’attribution de domaine, pas seulement l’adresse du serveur. Un domaine écrit comme ~corp.example est un domaine de routage, et le tilde change la façon dont le nom est mis en correspondance.

Si l’application a son propre résolveur, testez avec le même mécanisme qu’elle utilise plutôt qu’avec l’outil système. Un outil de requête qui contourne le résolveur système réussira quel que soit l’état du lien.

Vérification quatre : un propriétaire, pas deux

Si NetworkManager gère déjà le VPN et l’état du résolveur, ajouter un script de crochet sans rapport crée des rédacteurs concurrents. Le crochet fourni par le paquet pour systemd-resolved est une intégration prise en charge, et il attend un cycle de vie précis : script-security 2, un chemin up, up-restart, un chemin down et down-pre. Ces options font que l’enregistrement et le retrait se produisent aux bons moments plutôt qu’à la seule première connexion.

Utilisez le chemin installé par le paquet plutôt qu’un chemin illustratif copié d’un guide. Les permissions comptent aussi, car le crochet s’exécute après la baisse des privilèges.

Modifier un script de résolveur de la distribution pour changer sa cible de sortie enregistre un contournement propre à un hôte. Ce n’est pas une réparation générale.

Vérification cinq : le même résultat après une reconnexion

Reconnectez-vous et relisez le lien. Un enregistrement qui apparaît une fois et disparaît à la transition suivante est la panne pour laquelle toute cette liste de contrôle existe. Testez après une mise en veille, après une reconnexion forcée et après un redémarrage du service de résolveur. Chaque transition éprouve une hypothèse d’ordre différente.

Ce n’est que lorsque les cinq vérifications passent lors d’une reconnexion que vous pouvez dire que les réglages poussés sont utilisés. Tout ce qui précède est un instantané d’un moment chanceux.