Supprimer un enregistrement VPN obsolète de la base resolvconf

Un nom interne se résout encore vers le serveur VPN un jour après la fermeture du tunnel, et le fichier du résolveur revient sans cesse avec cette entrée. Là où le resolvconf de Debian possède l’état, ce fichier est assemblé à partir d’enregistrements de fournisseurs, et l’un d’eux est le reste. Supprimer l’enregistrement prend une minute ; prouver qu’il est sûr de le supprimer est le vrai travail. Ces portes s’exécutent dans l’ordre, et une porte échouée termine la procédure au lieu de vous envoyer à l’étape suivante.

Confirmer que resolvconf possède l’état

Identifiez d’abord le propriétaire, car le même symptôme sous systemd-resolved exige d’autres commandes et une autre réparation. Le paquet resolvconf tient une base de données sous /run/resolvconf et pointe /etc/resolv.conf vers le fichier qu’il construit à partir de cette base. Deux lectures tranchent la question : la cible du lien symbolique, et le fait que le paquet soit installé et actif. Une cible sous /run/systemd/resolve signifie l’autre conception, où rien de ce qui suit ne s’applique.

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

Si le lien pointe ailleurs ou si le paquet manque, arrêtez-vous ici. Un enrobage de compatibilité qui a emprunté le nom, fourni par un autre gestionnaire de résolveur, ne possède pas cette base de données.

La base contient des entrées, pas la réponse

La base contient des entrées et le fichier est une sortie, donc lister les entrées est le seul moyen de voir quel programme a installé l’entrée que vous voulez voir disparaître. Les enregistrements sont courts, et leurs clés sont les poignées dont vous aurez besoin plus tard. Lisez-les avant de décider laquelle est obsolète, car un nom qui ressemble à une interface VPN peut appartenir à un autre client. Gardez les adresses privées et les domaines de recherche internes hors des diagnostics partagés ; généralement la clé seule identifie l’enregistrement.

sudo resolvconf --list
sudo resolvconf -i

La première commande imprime les enregistrements fournis sans les traiter, et la seconde liste les interfaces qui fournissent actuellement la configuration DNS. Les clés sont conventionnellement construites à partir d’un nom d’interface plus le programme fournisseur. Le manuel de resolvconf décrit la base de données que ces clés adressent.

Copiez la clé depuis la sortie au lieu de la reconstruire. Une entrée ne s’appelle pas tun0 simplement parce qu’un ancien script a utilisé ce nom.

Prouver que l’enregistrement n’a pas de propriétaire

Un enregistrement est sûr à supprimer quand aucune connexion vivante ne l’a installé. Corrélez la clé avec la connexion qui l’a créée, puis confirmez que cette connexion a disparu. Cette corrélation est toute la porte, et c’est l’étape la plus souvent sautée en chemin vers la commande de suppression. Si les preuves sont ambiguës, traitez l’enregistrement comme vivant et arrêtez-vous.

Les noms de processus sont une preuve faible. OpenConnect appelle vpnc-script, donc vérifier la présence d’un processus vpnc ne dit rien sur l’enregistrement actuel. Une nouvelle connexion peut aussi réutiliser un nom d’interface qu’une ancienne a laissé derrière elle, ce qui fait paraître la clé plus ancienne qu’elle ne l’est. Comparez l’adresse du serveur dans l’enregistrement avec les adresses des tunnels encore montés, et arrêtez-vous si elles correspondent.

Une déconnexion normale via le gestionnaire propriétaire est le premier remède. Elle retire ce que cette connexion a installé et laisse les autres fournisseurs intacts.

Vérifier la suppression et la réécriture

Une fois l’enregistrement confirmé obsolète, supprimez-le par la clé exacte puis lisez le résultat au lieu de le supposer. La commande change l’état du résolveur pour chaque application de l’hôte, donc exécutez-la dans une fenêtre que vous contrôlez. Mettez la clé entre guillemets, car elle contient des caractères que le shell développerait autrement. L’espace réservé dans le bloc représente la clé que vous avez copiée depuis la liste, pas une chaîne littérale.

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

La suppression exécute les scripts de mise à jour quand la mise à jour est activée ; avec les mises à jour désactivées, elle diffère la mise à jour, donc un enregistrement supprimé et un fichier réécrit sont deux événements distincts. Relisez la liste et confirmez que la clé a disparu avant de regarder le fichier. Interrogez ensuite un nom qui devrait encore se résoudre via les fournisseurs restants et un nom public, et comparez les deux avec ce que vous avez vu avant le changement. Si un nom privé cesse complètement de se résoudre, cet enregistrement le portait encore.

resolvconf -u exécute seulement ces scripts de mise à jour. Il n’identifie ni ne supprime jamais un enregistrement obsolète, et reconstruire à partir d’entrées obsolètes reproduit le même fichier indésirable.

Un crochet de déconnexion tué laisse l’enregistrement derrière lui

Un nettoyage ponctuel restaure l’état du jour, et l’extinction interrompue suivante remet l’enregistrement. Parcourez le chemin de démontage : le crochet de déconnexion du client, l’assistant que ce crochet appelle, et ce qui se passe quand l’un ou l’autre est tué. Une extinction interrompue est l’origine habituelle, car le crochet n’a pas tourné du tout. Consignez une fois le statut de sortie du crochet et vous saurez s’il échoue en silence.

Gardez la configuration et le nettoyage sous un seul propriétaire. Un second script qui devine les noms d’interface finira par supprimer l’enregistrement d’une autre connexion, ce qui est pire que l’entrée obsolète avec laquelle vous avez commencé. Le propriétaire devrait aussi décider quand un enregistrement est obsolète, car il sait quelle connexion l’a installé.

Puis exercez le cycle de vie : connectez, déconnectez, listez de nouveau les enregistrements. La disparition spontanée de l’entrée est la seule preuve que la réparation tient.