Sletning af en forældet VPN-post fra resolvconf-databasen

Et internt navn slår stadig op på VPN-serveren en dag efter, at tunnelen er lukket, og resolver-filen kommer igen med den post. Hvor Debians resolvconf ejer tilstanden, samles den fil af leverandørposter, og en af dem er resten. Det tager et minut at slette posten; at bevise, at det er sikkert at slette den, er det egentlige arbejde. Disse kontrolpunkter kører i rækkefølge, og et mislykket kontrolpunkt afslutter proceduren i stedet for at sende dig videre til næste trin.

Bekræft, at resolvconf ejer tilstanden

Identificer ejeren først, for det samme symptom under systemd-resolved kræver andre kommandoer og en anden reparation. Pakken resolvconf holder en database under /run/resolvconf og peger /etc/resolv.conf mod den fil, den bygger ud fra den database. To aflæsninger afgør spørgsmålet: mål for det symbolske link, og om pakken er installeret og aktiv. Et mål under /run/systemd/resolve betyder det andet design, hvor intet nedenfor gælder.

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

Hvis linket peger et andet sted hen, eller pakken mangler, skal du stoppe her. En kompatibilitetsindpakning, der har lånt navnet og leveres af en anden resolver-manager, ejer ikke denne database.

Databasen indeholder input, ikke svaret

Databasen indeholder input, og filen er et output, så at liste input er den eneste måde at se, hvilket program der installerede den post, du vil af med. Posterne er korte, og deres nøgler er de håndtag, du får brug for senere. Læs dem, før du beslutter, hvilken der er forældet, for et navn, der ligner en VPN-grænseflade, kan tilhøre en anden klient. Hold private adresser og interne søgedomæner ude af delt diagnostik; normalt identificerer nøglen alene posten.

sudo resolvconf --list
sudo resolvconf -i

Den første kommando udskriver leverede poster uden at behandle dem, og den anden viser de grænseflader, der i øjeblikket leverer DNS-konfiguration. Nøgler bygges normalt af et grænsefladenavn plus det leverende program. resolvconf-manualen beskriver den database, som disse nøgler henviser til.

Kopier nøglen ud af outputtet i stedet for at genopbygge den. En post hedder ikke tun0 blot, fordi et gammelt script brugte det navn.

Bevis, at posten ikke har nogen ejer

En post er sikker at slette, når ingen levende forbindelse har installeret den. Korrelér nøglen med den forbindelse, der oprettede den, og bekræft derefter, at forbindelsen er væk. Den korrelation er hele kontrolpunktet, og det er det trin, der oftest springes over på vej til slettekommandoen. Hvis beviserne er tvetydige, skal du behandle posten som levende og stoppe.

Procesnavne er svage beviser. OpenConnect kalder vpnc-script, så et tjek for en proces vpnc siger intet om, hvilken post der er aktuel. En ny forbindelse kan også genbruge et grænsefladenavn, som en gammel efterlod, hvilket får nøglen til at se ældre ud, end den er. Sammenlign serveradressen inde i posten med adresserne på tunneler, der stadig er oppe, og stop, hvis de matcher.

En normal afbrydelse gennem den ejende manager er det første middel. Det trækker tilbage, hvad den forbindelse installerede, og lader andre leverandører være urørte.

Kontroller sletningen og omskrivningen

Når posten er bekræftet forældet, skal du slette den efter den præcise nøgle og derefter læse resultatet i stedet for at antage det. Kommandoen ændrer resolver-tilstanden for hver applikation på værten, så kør den i et vindue, du kontrollerer. Sæt nøglen i anførselstegn, fordi den indeholder tegn, som shellen ellers ville udvide. Pladsholderen i blokken står for den nøgle, du kopierede fra listen, ikke for en bogstavelig streng.

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

Sletning kører opdateringsscriptene, når opdatering er aktiveret; med opdateringer deaktiveret udsætter den opdateringen, så en fjernet post og en omskrevet fil er separate hændelser. Læs listen igen, og bekræft, at nøglen er væk, før du ser på filen. Spørg derefter på et navn, der stadig bør slå op gennem de resterende leverandører, og et offentligt navn, og sammenlign begge med det, du så før ændringen. Hvis et privat navn holder helt op med at slå op, var det den post, der stadig bar det.

resolvconf -u kører kun disse opdateringsscript. Det identificerer eller sletter aldrig en forældet post, og genopbygning ud fra forældede input giver den samme uønskede fil.

En dræbt afbrydelseskrog efterlader posten

En engangsoprydning gendanner dagens tilstand, og den næste afbrudte nedlukning sætter posten tilbage. Gå nedtagningsvejen igennem: klientens afbrydelseskrog, den hjælper som krogen kalder, og hvad der sker, når en af dem dræbes. En afbrudt nedlukning er den sædvanlige oprindelse, fordi krogen slet ikke kørte. Log krogens exitstatus én gang, og du ved, om den fejler i stilhed.

Hold opsætning og oprydning under én ejer. Et andet script, der gætter på grænsefladenavne, vil med tiden slette en anden forbindelses post, hvilket er værre end den forældede post, du startede med. Eieren bør også afgøre, hvornår en post er forældet, fordi den ved, hvilken forbindelse der installerede den.

Afprøv derefter livscyklussen: forbind, afbryd, list posterne igen. At posten forsvinder af sig selv er det eneste bevis på, at reparationen holder.