Le DNS d’OpenVPN reste après SIGKILL : vérifiez d’abord le propriétaire

Le DNS cesse de résoudre après qu’un client OpenVPN a été tué, et le premier réflexe est de réécrire /etc/resolv.conf. Cette modification peut casser un résolveur qui fonctionne alors que le véritable état obsolète se trouve ailleurs. La question à régler d’abord est de savoir qui possède les réglages DNS installés par le tunnel, et si la sortie qui a ignoré le nettoyage a réellement compté.

Trois conditions décident de la réparation : le signal qui a terminé le processus, le composant du résolveur qui a reçu les réglages, et la présence éventuelle du lien du tunnel. Répondez-y dans cet ordre et le correctif suit généralement sans toucher à un fichier global.

Déterminez quel type de sortie a eu lieu

Dans l’édition Community d’OpenVPN, SIGINT comme SIGTERM sont des demandes de sortie propre. SIGKILL ne peut pas être intercepté : il ne peut être ni bloqué ni traité, donc aucune routine d’arrêt n’a la possibilité de s’exécuter. Un Ctrl+C normal dans un terminal au premier plan produit SIGINT, tandis qu’un superviseur qui cesse d’attendre escalade généralement vers SIGKILL. La différence compte, car seul le second cas garantit que les crochets ont été ignorés.

L’exécution dans screen ou tmux ne change pas le signal envoyé par Ctrl+C. Vérifiez ce que le processus a réellement reçu, et non ce que fait habituellement le terminal.

Lorsqu’un service ou un gestionnaire de connexions exécute le tunnel, arrêtez cette connexion via son propriétaire au lieu de tuer le pid. Un gestionnaire peut relancer le processus, vous laissant un tunnel neuf et un état de résolveur confus. Un processus autonome n’a besoin que d’une demande d’arrêt ordinaire pour que le nettoyage s’exécute.

Déterminez qui possède le résolveur

systemd-resolved, un script de style resolvconf et une simple réécriture de fichier sont trois propriétaires différents. Le premier garde les réglages par lien en mémoire et les abandonne quand l’interface disparaît. Le second conserve des enregistrements qui persistent jusqu’à ce que quelque chose les retire. Le troisième écrit un fichier et laisse la restauration à celui qui l’a écrit.

Identifiez le propriétaire avant de choisir une commande de réparation. Le même symptôme a trois réponses correctes différentes selon celui qui est utilisé.

Un VPN géré par NetworkManager possède peut-être déjà les changements de résolveur. Ajouter un second assistant par-dessus crée deux propriétaires en concurrence pour le même lien, et l’état du perdant réapparaît à la reconnexion suivante. Si un gestionnaire est aux commandes, corrigez le réglage dans le gestionnaire plutôt que dans un script.

Ce que le crochet down peut et ne peut pas faire

Le script down s’exécute une fois l’appareil TUN/TAP fermé. Ajouter down-pre inverse cet ordre et exécute le script tant que l’appareil existe encore, ce que requièrent les assistants qui ont besoin du lien actif.

Aucune des deux directives ne fait exécuter un crochet après SIGKILL. Les privilèges ne sont pas non plus restaurés par down-pre : si le démon descend vers un user ou group ou entre dans un chroot, le crochet s’exécute avec les droits que cela lui laisse. Un crochet appelé peut tout de même échouer à mettre à jour le résolveur. La référence OpenVPN couvre les signaux et le cycle de vie du rappel.

Vérifiez l’erreur propre au crochet à côté du statut de sortie du processus. Un nettoyage absent et un nettoyage échoué se ressemblent dans le résolveur et diffèrent dans les journaux.

Vérifiez l’état qui reste réellement

Sur un système utilisant systemd-resolved, resolvectl status montre quel lien porte encore les serveurs DNS du VPN ou les domaines de routage. Ce lien peut appartenir à une connexion disparue ou à un autre tunnel encore actif.

Une interface qui disparaît emporte sa configuration par lien, donc un crochet ignoré peut coexister avec un DNS propre. Si le lien est encore enregistré et appartient exclusivement à la connexion arrêtée, le gestionnaire propriétaire devrait le retirer. Si un script plus ancien a réécrit un fichier de résolveur global, cherchez plutôt l’étape de restauration documentée de ce script.

Récupérez sans voler un autre lien

Quand les réglages par lien sont à vous de gérer, resolvectl revert prend le nom du lien et efface la configuration DNS d’exécution de cette interface. C’est une action d’exécution et non une modification de profil, donc la configuration persistante de la connexion reste intacte. Nommez le mauvais lien et vous effacez le DNS d’un tunnel qui fonctionne, c’est pourquoi le nom vient de la sortie d’état.

Confirmez que /etc/resolv.conf est un lien symbolique géré avant de le modifier, puis arrêtez le client normalement une fois de plus et regardez de nouveau le DNS. Si le second arrêt nettoie, le problème précédent était la sortie forcée et non la configuration.