Eliminació d’un registre VPN obsolet de la base de dades resolvconf

Un nom intern encara es resol cap al servidor VPN un dia després que el túnel es tanqui, i el fitxer del resolutor torna a aparèixer amb aquella entrada. On el resolvconf de Debian posseeix l’estat, aquell fitxer es munta a partir de registres de proveïdors, i un d’ells és la resta. Suprimir el registre porta un minut; demostrar que és segur de suprimir és la feina de veritat. Aquestes portes van en ordre, i una porta fallida acaba el procediment en lloc d’enviar-vos al pas següent.

Confirmeu que resolvconf posseeix l’estat

Identifiqueu primer el propietari, perquè el mateix símptoma sota systemd-resolved necessita ordres diferents i una reparació diferent. El paquet resolvconf manté una base de dades sota /run/resolvconf i apunta /etc/resolv.conf cap al fitxer que construeix a partir d’aquella base. Dues lectures resolen la qüestió: l’objectiu de l’enllaç simbòlic i si el paquet és instal·lat i actiu. Un objectiu sota /run/systemd/resolve significa l’altre disseny, on res del que hi ha a sota no s’aplica.

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

Si l’enllaç apunta a un altre lloc o el paquet falta, atureu-vos aquí. Un embolcall de compatibilitat que va manllevar el nom, subministrat per un altre gestor de resolutors, no posseeix aquesta base de dades.

La base de dades conté entrades, no la resposta

La base de dades conté entrades i el fitxer és una sortida, així que llistar les entrades és l’única manera de veure quin programa va instal·lar l’entrada que voleu treure. Els registres són curts, i les seves claus són els mànecs que necessitareu més endavant. Llegiu-los abans de decidir quin és obsolet, perquè un nom que sembla una interfície VPN pot pertànyer a un altre client. Manteniu les adreces privades i els dominis de cerca interns fora dels diagnòstics compartits; normalment la clau sola identifica el registre.

sudo resolvconf --list
sudo resolvconf -i

La primera ordre imprimeix els registres subministrats sense processar-los, i la segona llista les interfícies que actualment forneixen configuració DNS. Les claus es construeixen convencionalment a partir d’un nom d’interfície més el programa proveïdor. El manual de resolvconf descriu la base de dades a què adrecen aquestes claus.

Copieu la clau de la sortida en lloc de reconstruir-la. Una entrada no es diu tun0 només perquè un script antic utilitzés aquell nom.

Demostreu que el registre no té propietari

Un registre és segur de suprimir quan cap connexió viva l’ha instal·lat. Relacioneu la clau amb la connexió que la va crear i després confirmeu que aquella connexió ha desaparegut. Aquesta correlació és tota la porta, i és el pas que més sovint s’omet de camí cap a l’ordre de supressió. Si l’evidència és ambigua, tracteu el registre com a viu i atureu-vos.

Els noms de procés són evidència feble. OpenConnect crida vpnc-script, així que comprovar si hi ha un procés vpnc no diu res sobre quin registre és actual. Una connexió nova també pot reutilitzar un nom d’interfície que una d’antiga va deixar enrere, cosa que fa que la clau sembli més antiga del que és. Compareu l’adreça del servidor dins del registre amb les adreces de túnels que encara estan aixecats, i atureu-vos si coincideixen.

Una desconnexió normal a través del gestor propietari és el primer remei. Retira el que aquella connexió va instal·lar i deixa els altres proveïdors intactes.

Comproveu la supressió i la reescriptura

Amb el registre confirmat obsolet, suprimiu-lo per la clau exacta i després llegiu el resultat en lloc de suposar-lo. L’ordre canvia l’estat del resolutor per a cada aplicació de l’amfitrió, així que executeu-la en una finestra que controleu. Posa la clau entre cometes, perquè conté caràcters que la shell expandiria d’altra manera. El marcador de posició del bloc representa la clau que heu copiat de la llista, no una cadena literal.

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

La supressió executa els scripts d’actualització quan l’actualització està habilitada; amb les actualitzacions deshabilitades ajorna l’actualització, així que un registre suprimit i un fitxer reescrit són esdeveniments separats. Torneu a llegir la llista i confirmeu que la clau ha desaparegut abans de mirar el fitxer. Després consulteu un nom que encara s’hauria de resoldre a través dels proveïdors restants i un nom públic, i compareu tots dos amb el que vèieu abans del canvi. Si un nom privat deixa de resoldre’s del tot, aquell registre encara el portava.

resolvconf -u només executa aquests scripts d’actualització. Mai no identifica ni suprimeix un registre obsolet, i reconstruir a partir d’entrades obsoletes reprodueix el mateix fitxer no desitjat.

Un hook de desconnexió mort deixa el registre enrere

Una neteja puntual restaura l’estat d’avui, i la següent aturada interrompuda torna a posar el registre. Recorreu el camí de desmuntatge: el hook de desconnexió del client, l’ajudant que aquest hook crida i què passa quan es mata qualsevol dels dos. Una aturada interrompuda és l’origen habitual, perquè el hook no es va executar gens. Registreu l’estat de sortida del hook una vegada i sabreu si falla en silenci.

Manteniu la configuració i la neteja sota un sol propietari. Un segon script que endevina noms d’interfície finalment suprimirà el registre d’una altra connexió, cosa pitjor que l’entrada obsoleta amb què vau començar. El propietari també hauria de decidir quan un registre és obsolet, perquè sap quina connexió el va instal·lar.

Després exerciteu el cicle de vida: connecteu, desconnecteu, torneu a llistar els registres. Que l’entrada desaparegui tota sola és l’única prova que la reparació aguanta.