Ta bort en inaktuell VPN-post från resolvconf-databasen

Ett internt namn löses fortfarande till VPN-servern en dag efter att tunneln stängdes, och resolverfilen kommer ständigt tillbaka med den posten. Där Debians resolvconf äger tillståndet sätts filen ihop av leverantörsposter, och en av dem är resten. Att radera posten tar en minut; att bevisa att det är säkert är det egentliga arbetet. Dessa portar körs i ordning, och en port som misslyckas avslutar proceduren i stället för att skicka dig vidare till nästa steg.

Bekräfta att resolvconf äger tillståndet

Identifiera ägaren först, eftersom samma symtom under systemd-resolved kräver andra kommandon och en annan reparation. Paketet resolvconf håller en databas under /run/resolvconf och pekar /etc/resolv.conf mot filen som det bygger från den databasen. Två läsningar avgör frågan: symlänkens mål, och om paketet är installerat och aktivt. Ett mål under /run/systemd/resolve betyder den andra konstruktionen, där inget nedan gäller.

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

Om länken pekar någon annanstans eller paketet saknas, stanna här. Ett kompatibilitetshölje som har lånat namnet, och som levereras av en annan resolverhanterare, äger inte den här databasen.

Databasen håller indata, inte svaret

Databasen håller indata och filen är utdata, så att lista indata är det enda sättet att se vilket program som installerade posten du vill bli av med. Posterna är korta, och deras nycklar är handtagen du behöver senare. Läs dem innan du avgör vilken som är inaktuell, eftersom ett namn som ser ut som ett VPN-gränssnitt kan tillhöra en annan klient. Håll privata adresser och interna sökdomäner utanför delad diagnostik; nyckeln ensam identifierar oftast posten.

sudo resolvconf --list
sudo resolvconf -i

Det första kommandot skriver ut levererade poster utan att bearbeta dem, och det andra listar gränssnitten som för närvarande tillhandahåller DNS-konfiguration. Nycklar byggs vanligen av ett gränssnittsnamn plus programmet som levererar det. resolvconf-handboken beskriver databasen som dessa nycklar adresserar.

Kopiera nyckeln ur utdata i stället för att bygga den på nytt. En post heter inte tun0 bara för att ett gammalt skript använde det namnet.

Bevisa att posten inte har någon ägare

En post är säker att radera när ingen levande anslutning installerade den. Korrelera nyckeln med anslutningen som skapade den, och bekräfta sedan att den anslutningen är borta. Den korrelationen är hela porten, och det är steget som oftast hoppas över på vägen till raderingskommandot. Om bevisningen är tvetydig, behandla posten som levande och stanna.

Processnamn är svaga bevis. OpenConnect anropar vpnc-script, så en kontroll av en vpnc-process säger inget om vilken post som är aktuell. En ny anslutning kan också återanvända ett gränssnittsnamn som en gammal lämnade efter sig, vilket får nyckeln att se äldre ut än den är. Jämför serveradressen i posten med adresserna för tunnlar som fortfarande är uppe, och stanna om de stämmer.

En normal frånkoppling via hanteraren som äger anslutningen är det första botemedlet. Den drar tillbaka det som anslutningen installerade och lämnar andra leverantörer orörda.

Kontrollera borttagningen och omskrivningen

När posten är bekräftat inaktuell, radera den med den exakta nyckeln och läs sedan resultatet i stället för att anta det. Kommandot ändrar resolverläget för varje program på värden, så kör det i ett fönster du kontrollerar. Sätt nyckeln inom citattecken, eftersom den innehåller tecken som skalet annars skulle expandera. Platshållaren i blocket står för nyckeln du kopierade från listan, inte för en bokstavlig sträng.

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

Raderingen kör uppdateringsskripten när uppdatering är påslagen; med uppdateringar avstängda skjuts uppdateringen upp, så en borttagen post och en omskriven fil är två separata händelser. Läs listan igen och bekräfta att nyckeln är borta innan du tittar på filen. Fråga sedan efter ett namn som fortfarande borde lösas via de återstående leverantörerna och ett publikt namn, och jämför båda med det du såg före ändringen. Om ett privat namn helt slutar lösas bar den posten det fortfarande.

resolvconf -u kör bara de uppdateringsskripten. Det identifierar eller raderar aldrig en inaktuell post, och att bygga om från inaktuella indata återskapar samma oönskade fil.

En dödad frånkopplingskrok lämnar posten kvar

En engångsstädning återställer dagens tillstånd, och nästa avbrutna avstängning sätter tillbaka posten. Gå nedrivningsvägen: klientens frånkopplingskrok, hjälparen som kroken anropar, och vad som händer när någon av dem dödas. En avbruten avstängning är det vanliga ursprunget, eftersom kroken aldrig kördes alls. Logga krokens utgångsstatus en gång och du vet om den misslyckas tyst.

Håll installation och städning under en enda ägare. Ett andra skript som gissar gränssnittsnamn kommer till slut att radera en annan anslutnings post, vilket är värre än den inaktuella post du började med. Ägaren bör också avgöra när en post är inaktuell, eftersom den vet vilken anslutning som installerade den.

Träna sedan livscykeln: anslut, koppla från, lista posterna igen. Att posten försvinner av sig själv är det enda beviset på att reparationen håller.