Eliminarea unei înregistrări VPN vechi din baza de date resolvconf

Un nume intern se rezolvă în continuare către serverul VPN la o zi după ce tunelul s-a închis, iar fișierul resolverului tot revine cu acea intrare. Acolo unde Debian resolvconf deține starea, acel fișier este asamblat din înregistrările furnizorilor, iar una dintre ele este restul. Ștergerea înregistrării durează un minut; dovada că este sigur să o ștergi este munca reală. Aceste porți rulează în ordine, iar o poartă eșuată încheie procedura în loc să vă trimită la pasul următor.

Confirmați că resolvconf deține starea

Identificați mai întâi proprietarul, pentru că același simptom sub systemd-resolved cere comenzi diferite și o reparație diferită. Pachetul resolvconf ține o bază de date în /run/resolvconf și îndreaptă /etc/resolv.conf către fișierul pe care îl construiește din acea bază. Două citiri lămuresc întrebarea: ținta legăturii simbolice și dacă pachetul este instalat și activ. O țintă în /run/systemd/resolve înseamnă cealaltă construcție, unde nimic de mai jos nu se aplică.

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

Dacă legătura indică altundeva sau pachetul lipsește, opriți-vă aici. Un înveliș de compatibilitate care a împrumutat numele, livrat de un alt manager de resolver, nu deține această bază de date.

Baza de date ține intrări, nu răspunsul

Baza de date ține intrări, iar fișierul este o ieșire, așa că listarea intrărilor este singura cale de a vedea ce program a instalat intrarea de care vreți să scăpați. Înregistrările sunt scurte, iar cheile lor sunt mânerele de care veți avea nevoie mai târziu. Citiți-le înainte de a decide care este veche, pentru că un nume care arată ca o interfață VPN poate aparține altui client. Țineți adresele private și domeniile de căutare interne în afara diagnosticelor partajate; cheia singură identifică de obicei înregistrarea.

sudo resolvconf --list
sudo resolvconf -i

Prima comandă tipărește înregistrările furnizate fără a le procesa, iar a doua listează interfețele care oferă în prezent configurație DNS. Cheile sunt construite de obicei dintr-un nume de interfață plus programul furnizor. Manualul resolvconf descrie baza de date către care trimit acele chei.

Copiați cheia din ieșire în loc să o reconstruiți. O intrare nu se numește tun0 doar pentru că un script vechi a folosit acel nume.

Dovediți că înregistrarea nu are proprietar

O înregistrare este sigură de șters când nicio conexiune activă nu a instalat-o. Corelați cheia cu conexiunea care a creat-o, apoi confirmați că acea conexiune a dispărut. Acea corelație este întreaga poartă și este pasul cel mai des omis pe drumul spre comanda de ștergere. Dacă dovezile sunt ambigue, tratați înregistrarea ca activă și opriți-vă.

Numele proceselor sunt dovezi slabe. OpenConnect apelează vpnc-script, așa că verificarea unui proces vpnc nu spune nimic despre care înregistrare este cea curentă. O conexiune nouă poate refolosi un nume de interfață lăsat de una veche, ceea ce face cheia să pară mai veche decât este. Comparați adresa serverului din înregistrare cu adresele tunelurilor încă active și opriți-vă dacă se potrivesc.

O deconectare normală prin managerul proprietar este primul remediu. Retrage ce a instalat acea conexiune și lasă ceilalți furnizori neatinși.

Verificați eliminarea și rescrierea

După ce înregistrarea este confirmată veche, ștergeți-o cu cheia exactă și apoi citiți rezultatul în loc să îl presupuneți. Comanda schimbă starea resolverului pentru fiecare aplicație de pe host, așa că rulați-o într-o fereastră pe care o controlați. Puneți cheia între ghilimele, pentru că are caractere pe care shell-ul le-ar extinde altfel. Substituentul din bloc reprezintă cheia copiată din listă, nu un șir literal.

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

Ștergerea rulează scripturile de actualizare când actualizarea este activată; cu actualizările dezactivate amână actualizarea, așa că o înregistrare eliminată și un fișier rescris sunt două evenimente separate. Recitiți lista și confirmați că cheia a dispărut înainte de a vă uita la fișier. Apoi interogați un nume care ar trebui să se rezolve în continuare prin furnizorii rămași și un nume public, și comparați-le pe amândouă cu ce ați văzut înainte de schimbare. Dacă un nume privat încetează complet să se rezolve, acea înregistrare îl mai purta.

resolvconf -u rulează doar acele scripturi de actualizare. Nu identifică și nu șterge niciodată o înregistrare veche, iar reconstruirea din intrări vechi reproduce același fișier nedorit.

Un cârlig de deconectare ucis lasă înregistrarea în urmă

O curățare unică restaurează starea de azi, iar următoarea oprire întreruptă pune înregistrarea la loc. Parcurgeți calea de demontare: cârligul de deconectare al clientului, ajutorul pe care îl cheamă cârligul și ce se întâmplă când unul dintre ele este ucis. O oprire întreruptă este originea obișnuită, pentru că cârligul nu a rulat deloc. Înregistrați o dată starea de ieșire a cârligului și veți ști dacă eșuează în tăcere.

Țineți configurarea și curățarea sub un singur proprietar. Un al doilea script care ghicește nume de interfețe va șterge în cele din urmă înregistrarea altei conexiuni, ceea ce este mai rău decât intrarea veche cu care ați început. Proprietarul ar trebui să decidă și când o înregistrare este veche, pentru că știe ce conexiune a instalat-o.

Apoi exersați ciclul de viață: conectați-vă, deconectați-vă, listați din nou înregistrările. Dispariția de la sine a intrării este singura dovadă că reparația rezistă.