Een verouderd VPN-record uit de resolvconf-database verwijderen

Een interne naam lost nog steeds op naar de VPN-server, een dag nadat de tunnel is gesloten, en het resolverbestand blijft met die vermelding terugkomen. Waar de resolvconf van Debian de status bezit, wordt dat bestand samengesteld uit records van leveranciers, en een daarvan is het restant. Het record verwijderen kost een minuut; bewijzen dat het veilig is om te verwijderen is het echte werk. Deze poorten worden in volgorde uitgevoerd, en een mislukte poort beëindigt de procedure in plaats van u naar de volgende stap te sturen.

Bevestig dat resolvconf de status bezit

Identificeer eerst de eigenaar, want hetzelfde symptoom onder systemd-resolved vereist andere opdrachten en een andere reparatie. Het resolvconf-pakket houdt een database onder /run/resolvconf en wijst /etc/resolv.conf naar het bestand dat het uit die database opbouwt. Twee metingen beslechten de vraag: het doel van de symlink, en of het pakket geïnstalleerd en actief is. Een doel onder /run/systemd/resolve betekent het andere ontwerp, waarbij niets hieronder van toepassing is.

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

Als de koppeling ergens anders heen wijst of het pakket ontbreekt, stop dan hier. Een compatibiliteitsschil die de naam heeft geleend en door een andere resolverbeheerder wordt geleverd, bezit deze database niet.

De database bevat invoer, niet het antwoord

De database bevat invoer en het bestand is uitvoer, dus invoer opsommen is de enige manier om te zien welk programma de vermelding heeft geïnstalleerd die u kwijt wilt. De records zijn kort, en hun sleutels zijn de handvatten die u later nodig hebt. Lees ze voordat u besluit welke verouderd is, want een naam die op een VPN-interface lijkt kan bij een andere client horen. Houd privéadressen en interne zoekdomeinen buiten gedeelde diagnostiek; de sleutel alleen identificeert het record meestal.

sudo resolvconf --list
sudo resolvconf -i

De eerste opdracht drukt geleverde records af zonder ze te verwerken, en de tweede somt de interfaces op die momenteel DNS-configuratie leveren. Sleutels worden gewoonlijk opgebouwd uit een interfacenaam plus het leverende programma. De handleiding van resolvconf beschrijft de database die die sleutels adresseren.

Kopieer de sleutel uit de uitvoer in plaats van hem opnieuw op te bouwen. Een vermelding heet niet tun0 alleen omdat een oud script die naam gebruikte.

Bewijs dat het record geen eigenaar heeft

Een record is veilig te verwijderen wanneer geen enkele levende verbinding het heeft geïnstalleerd. Koppel de sleutel aan de verbinding die hem heeft gemaakt, en bevestig dan dat die verbinding weg is. Die correlatie is de hele poort, en het is de stap die het vaakst wordt overgeslagen op weg naar de verwijderopdracht. Als het bewijs dubbelzinnig is, behandel het record dan als levend en stop.

Procesnamen zijn zwak bewijs. OpenConnect roept vpnc-script aan, dus een controle op een vpnc-proces zegt niets over welk record actueel is. Een nieuwe verbinding kan ook een interfacenaam hergebruiken die een oude heeft achtergelaten, waardoor de sleutel ouder lijkt dan hij is. Vergelijk het serveradres in het record met de adressen van tunnels die nog actief zijn, en stop als ze overeenkomen.

Een normale verbreking via de beheerder die de verbinding bezit is het eerste middel. Die trekt terug wat die verbinding heeft geïnstalleerd en laat andere leveranciers ongemoeid.

Controleer het verwijderen en het herschrijven

Als het record bevestigd verouderd is, verwijder het dan met de exacte sleutel en lees daarna het resultaat in plaats van het aan te nemen. De opdracht wijzigt de resolverstatus voor elke toepassing op de host, dus voer hem uit in een venster dat u beheert. Zet de sleutel tussen aanhalingstekens, want hij bevat tekens die de shell anders zou uitbreiden. De plaatsaanduiding in het blok staat voor de sleutel die u uit de lijst hebt gekopieerd, niet voor een letterlijke tekenreeks.

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

Verwijderen voert de updatescripts uit wanneer bijwerken is ingeschakeld; met bijwerken uitgeschakeld stelt het de update uit, zodat een verwijderd record en een herschreven bestand twee afzonderlijke gebeurtenissen zijn. Lees de lijst opnieuw en bevestig dat de sleutel weg is voordat u naar het bestand kijkt. Vraag dan één naam op die nog via de resterende leveranciers zou moeten oplossen en één openbare naam, en vergelijk beide met wat u voor de wijziging zag. Als een privénaam helemaal niet meer oplost, droeg dat record hem nog steeds.

resolvconf -u voert alleen die updatescripts uit. Het identificeert of verwijdert nooit een verouderd record, en opnieuw opbouwen uit verouderde invoer reproduceert hetzelfde ongewenste bestand.

Een gedode verbrekingshaak laat het record achter

Een eenmalige opruiming herstelt de toestand van vandaag, en de volgende onderbroken afsluiting zet het record terug. Ga het afbraakpad na: de verbrekingshaak van de client, de helper die die haak aanroept, en wat er gebeurt als een van beide wordt gedood. Een onderbroken afsluiting is de gebruikelijke oorzaak, omdat de haak helemaal niet liep. Registreer één keer de exitstatus van de haak en u weet of hij stil faalt.

Houd installatie en opruiming onder één eigenaar. Een tweede script dat interfacenamen raadt, zal uiteindelijk het record van een andere verbinding verwijderen, wat erger is dan de verouderde vermelding waarmee u begon. De eigenaar moet ook beslissen wanneer een record verouderd is, omdat hij weet welke verbinding het heeft geïnstalleerd.

Test daarna de levenscyclus: verbind, verbreek, som de records opnieuw op. Dat de vermelding vanzelf verdwijnt is het enige bewijs dat de reparatie standhoudt.