Verouderde VPN-rekord uit die resolvconf-databasis verwyder

’n Interne naam los steeds op na die VPN-bediener ’n dag nadat die tonnel gesluit het, en die resolver-lêer kom steeds met daardie inskrywing terug. Waar Debian se resolvconf die toestand besit, word daardie lêer uit verskaffersrekords saamgestel, en een van hulle is die oorblyfsel. Om die rekord te verwyder neem ’n minuut; om te bewys dat dit veilig is om te verwyder, is die werklike werk. Hierdie hekke loop in volgorde, en ’n mislukte hek beëindig die prosedure in plaas daarvan om jou na die volgende stap te stuur.

Bevestig dat resolvconf die toestand besit

Identifiseer eers die eienaar, want dieselfde simptoom onder systemd-resolved vereis ander opdragte en ’n ander herstelling. Die resolvconf-pakket hou ’n databasis onder /run/resolvconf en wys /etc/resolv.conf na die lêer wat hy uit daardie databasis bou. Twee lesings besleg die vraag: die teiken van die simboliese skakel, en of die pakket geïnstalleer en aktief is. ’n Teiken onder /run/systemd/resolve beteken die ander ontwerp, waar niks hieronder van toepassing is.

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

As die skakel elders heen wys of die pakket ontbreek, stop hier. ’n Versoenbaarheidsomhulsel wat die naam geleen het en deur ’n ander resolver-bestuurder verskeep is, besit nie hierdie databasis nie.

Die databasis hou insette, nie die antwoord nie

Die databasis hou insette en die lêer is ’n uitset, dus is die lys van insette die enigste manier om te sien watter program die inskrywing geïnstalleer het wat jy kwyt wil raak. Die rekords is kort, en hul sleutels is die handvatsels wat jy later nodig het. Lees hulle voordat jy besluit watter een verouderd is, want ’n naam wat soos ’n VPN-koppelvlak lyk, kan aan ’n ander kliënt behoort. Hou private adresse en interne soekdomeine buite gedeelde diagnostiek; die sleutel alleen identifiseer gewoonlik die rekord.

sudo resolvconf --list
sudo resolvconf -i

Die eerste opdrag druk verskafde rekords sonder om hulle te verwerk, en die tweede lys die koppelvlakke wat tans DNS-konfigurasie verskaf. Sleutels word gewoonlik uit ’n koppelvlaknaam plus die verskaffende program gebou. Die resolvconf-handleiding beskryf die databasis wat daardie sleutels aanspreek.

Kopieer die sleutel uit die uitset in plaas daarvan om dit te herbou. ’n Inskrywing heet nie tun0 bloot omdat ’n ou script daardie naam gebruik het nie.

Bewys dat die rekord geen eienaar het nie

’n Rekord is veilig om te verwyder wanneer geen lewende verbinding dit geïnstalleer het nie. Korreleer die sleutel met die verbinding wat dit geskep het, en bevestig dan dat daardie verbinding weg is. Daardie korrelasie is die hele hek, en dit is die stap wat die meeste oorgeslaan word op pad na die verwyderopdrag. As die bewyse dubbelsinnig is, behandel die rekord as lewendig en stop.

Prosesname is swak bewyse. OpenConnect roep vpnc-script, so ’n kontrole vir ’n proses vpnc sê niks oor watter rekord tans geldig is nie. ’n Varswaterverbinding kan ook ’n koppelvlaknaam hergebruik wat ’n ou een agtergelaat het, wat die sleutel ouer laat lyk as wat dit is. Vergelyk die bedieneradres binne die rekord met die adresse van tonnels wat nog staan, en stop as hulle ooreenstem.

’n Normale ontkoppeling deur die bestuurder wat dit besit, is die eerste oplossing. Dit onttrek wat daardie verbinding geïnstalleer het en laat ander verskaffers onaangeraak.

Kontroleer die verwydering en die herskrywing

Nadat die rekord as verouderd bevestig is, verwyder dit volgens die presiese sleutel en lees dan die resultaat eerder as om dit te aanvaar. Die opdrag verander resolver-toestand vir elke toepassing op die gasheer, so voer dit uit in ’n venster wat jy beheer. Sit die sleutel tussen aanhalingstekens, want dit bevat karakters wat die dop andersins sou uitbrei. Die plekhouer in die blok staan vir die sleutel wat jy uit die lys gekopieer het, nie vir ’n letterlike string nie.

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

Verwydering voer die opdateringskripte uit wanneer opdatering geaktiveer is; met opdaterings gedeaktiveer stel dit die opdatering uit, so ’n verwyderde rekord en ’n herskryfde lêer is aparte gebeure. Lees die lys weer en bevestig dat die sleutel weg is voordat jy na die lêer kyk. Vra dan een naam wat nog deur die oorblywende verskaffers behoort op te los, en een openbare naam, en vergelyk albei met wat jy voor die verandering gesien het. As ’n private naam heeltemal ophou oplos, het daardie rekord dit nog gedra.

resolvconf -u voer net daardie opdateringskripte uit. Dit identifiseer of verwyder nooit ’n verouderde rekord nie, en herbou uit verouderde insette lewer dieselfde ongewenste lêer.

’n Onderbroke ontkoppelingshaak laat die rekord agter

’n Eenmalige opruiming herstel die toestand van vandag, en die volgende onderbroke afskakeling sit die rekord terug. Stap die aftakelpad na: die kliënt se ontkoppelingshaak, die helper wat daardie haak roep, en wat gebeur wanneer enige van die twee doodgemaak word. ’n Onderbroke afskakeling is die gewone oorsprong, want die haak het glad nie geloop nie. Teken die haak se uitgangstatus een keer aan, en jy sal weet of dit stilweg misluk.

Hou opstelling en opruiming onder een eienaar. ’n Tweede script wat koppelvlakname raai, sal uiteindelik ’n ander verbinding se rekord verwyder, wat erger is as die verouderde inskrywing waarmee jy begin het. Die eienaar moet ook besluit wanneer ’n rekord verouderd is, want hy weet watter verbinding dit geïnstalleer het.

Toets dan die lewensiklus: koppel, ontkoppel, lys die rekords weer. Die inskrywing wat vanself verdwyn, is die enigste bewys dat die herstelling standhou.