Rimuovere un record VPN obsoleto dal database di resolvconf

Un nome interno continua a risolversi verso il server VPN un giorno dopo la chiusura del tunnel, e il file del resolver continua a ripresentarsi con quella voce. Dove resolvconf di Debian possiede lo stato, quel file viene assemblato dai record dei fornitori, e uno di essi è il residuo. Eliminare il record richiede un minuto; dimostrare che è sicuro eliminarlo è il vero lavoro. Questi cancelli si eseguono in ordine, e un cancello fallito termina la procedura invece di mandarvi al passo successivo.

Confermate che resolvconf possiede lo stato

Identificate prima il proprietario, perché lo stesso sintomo sotto systemd-resolved richiede comandi diversi e una riparazione diversa. Il pacchetto resolvconf tiene un database sotto /run/resolvconf e punta /etc/resolv.conf al file che costruisce da quel database. Due letture risolvono la questione: la destinazione del symlink e se il pacchetto è installato e attivo. Una destinazione sotto /run/systemd/resolve significa l’altro progetto, dove nulla di quanto segue si applica.

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

Se il collegamento punta altrove o il pacchetto manca, fermatevi qui. Un wrapper di compatibilità che ha preso in prestito il nome, distribuito da un altro gestore di resolver, non possiede questo database.

Il database contiene input, non la risposta

Il database contiene input e il file è un output, quindi elencare gli input è l’unico modo per vedere quale programma ha installato la voce che volete eliminare. I record sono brevi, e le loro chiavi sono le maniglie che vi serviranno dopo. Leggeteli prima di decidere quale sia obsoleto, perché un nome che sembra un’interfaccia VPN può appartenere a un altro client. Tenete gli indirizzi privati e i domini di ricerca interni fuori dalle diagnostiche condivise; la sola chiave di solito identifica il record.

sudo resolvconf --list
sudo resolvconf -i

Il primo comando stampa i record forniti senza elaborarli, e il secondo elenca le interfacce che attualmente forniscono la configurazione DNS. Le chiavi sono convenzionalmente costruite da un nome di interfaccia più il programma che la fornisce. Il manuale di resolvconf descrive il database a cui quelle chiavi si riferiscono.

Copiate la chiave dall’output invece di ricostruirla. Una voce non si chiama tun0 solo perché uno script vecchio usava quel nome.

Dimostrate che il record non ha proprietario

Un record è sicuro da eliminare quando nessuna connessione attiva lo ha installato. Correlate la chiave con la connessione che l’ha creata, poi confermate che quella connessione è sparita. Quella correlazione è l’intero cancello, ed è il passo più spesso saltato sulla strada verso il comando di eliminazione. Se le prove sono ambigue, trattate il record come attivo e fermatevi.

I nomi dei processi sono prove deboli. OpenConnect chiama vpnc-script, quindi un controllo su un processo vpnc non dice nulla su quale record sia quello corrente. Una connessione nuova può anche riusare un nome di interfaccia lasciato indietro da una vecchia, il che fa sembrare la chiave più vecchia di quanto sia. Confrontate l’indirizzo del server dentro il record con gli indirizzi dei tunnel ancora attivi, e fermatevi se coincidono.

Una disconnessione normale tramite il gestore proprietario è il primo rimedio. Ritira ciò che quella connessione aveva installato e lascia intatti gli altri fornitori.

Verificate la rimozione e la riscrittura

Con il record confermato obsoleto, eliminatelo con la chiave esatta e poi leggete il risultato invece di darlo per scontato. Il comando cambia lo stato del resolver per ogni applicazione sull’host, quindi eseguitelo in una finestra che controllate. Mettete la chiave tra virgolette, perché contiene caratteri che la shell altrimenti espanderebbe. Il segnaposto nel blocco rappresenta la chiave che avete copiato dall’elenco, non una stringa letterale.

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

L’eliminazione esegue gli script di aggiornamento quando l’aggiornamento è abilitato; con gli aggiornamenti disabilitati rinvia l’aggiornamento, quindi un record rimosso e un file riscritto sono due eventi separati. Rileggete l’elenco e confermate che la chiave sia sparita prima di guardare il file. Poi interrogate un nome che dovrebbe ancora risolversi tramite i fornitori rimanenti e un nome pubblico, e confrontate entrambi con ciò che avevate visto prima della modifica. Se un nome privato smette del tutto di risolversi, quel record lo stava ancora trasportando.

resolvconf -u esegue solo quegli script di aggiornamento. Non identifica né elimina mai un record obsoleto, e ricostruire da input obsoleti riproduce lo stesso file indesiderato.

Un hook di disconnessione ucciso lascia il record dietro di sé

Una pulizia una tantum ripristina lo stato di oggi, e il prossimo arresto interrotto rimette il record. Percorrete il percorso di smontaggio: l’hook di disconnessione del client, l’helper che quell’hook chiama, e cosa succede quando uno dei due viene ucciso. Un arresto interrotto è l’origine abituale, perché l’hook non è mai stato eseguito affatto. Registrate una volta lo stato di uscita dell’hook e saprete se sta fallendo in silenzio.

Tenete configurazione e pulizia sotto un solo proprietario. Un secondo script che indovina i nomi delle interfacce finirà per eliminare il record di un’altra connessione, il che è peggio della voce obsoleta con cui avete iniziato. Il proprietario dovrebbe anche decidere quando un record è obsoleto, perché sa quale connessione lo ha installato.

Poi esercitate il ciclo di vita: connettete, disconnettete, elencate di nuovo i record. La scomparsa spontanea della voce è l’unica prova che la riparazione regge.