resolv.conf aanpassen lost DNS na het verbreken van de VPN niet op

Je verbreekt de VPN, ping 1.1.1.1 antwoordt nog, en elke naamopzoeking blijft hangen voordat de pagina het eindelijk opgeeft. Dan toont cat /etc/resolv.conf een naamserver die ooit alleen binnen de tunnel bestond, meestal bovenaan de lijst. Die regel verwijderen lijkt het ongeveer tien minuten op te lossen, tot een slaapstand, een Wi-Fi-roaming of een herstart hem terugzet. Het bestand dat je hebt bewerkt is niet de instelling; het is een weergave van linkstatus die een ander onderdeel bezit.

Waarom één verouderde vermelding seconden per opzoeking kost

De glibc-resolver loopt de lijst met naamservers op volgorde af en wacht een time-out af voordat hij de volgende probeert, en resolv.conf(5) beperkt die lijst tot drie vermeldingen. Zet een resolver aan de tunnelkant zoals 10.8.0.1 bovenaan nadat de tunnel weg is, en elke opzoeking betaalt de time-out voordat hij doorvalt naar een server die antwoordt. Daarom lijkt het symptoom op een dode verbinding en niet op een DNS-fout: browsers blokkeren, lopen vast en serveren soms een gecachet adres dat later verouderd raakt.

Dat verklaart ook waarom de klacht binnenkomt als „het internet is stuk“. Een ping naar een IP-adres bewijst dat de link in orde is, waardoor de fout op de toepassing lijkt. De resolverlijst is het eerste dat je leest en het laatste dat je bewerkt.

De mythe: resolv.conf is een instellingenbestand

Vraag wat het pad werkelijk is voordat je het wijzigt:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

Op een systemd-resolved-host is het een symbolische koppeling naar een stub-bestand dat naar 127.0.0.53 wijst, en de echte servers leven in de status per link die resolvectl afdrukt. Op een NetworkManager-host kan het een bestand zijn dat NetworkManager uit de actieve verbinding schrijft. Bij sommige leveranciersclients is het een gewoon bestand dat bij het verbinden ter plaatse wordt herschreven en, als je pech hebt, bij het verbreken nooit wordt teruggezet. Dat zijn drie verschillende eigenaren, en de eerste twee met de hand bewerken doet of niets of houdt tot de volgende netwerkgebeurtenis.

resolvectl status is de weergave die de waarheid vertelt: DNS-servers per link, routeringsdomeinen en of de tunnelverbinding nog bestaat. resolvectl query example.com gaat verder en laat zien welke interface heeft geantwoord. Gebruik beide voordat je een bestand aanraakt, en bedenk dat een browser met eigen beveiligde DNS dit alles negeert.

Vind de eigenaar voordat je iets bewerkt

Meestal concurreren drie onderdelen om dezelfde instelling: systemd-resolved, NetworkManager en wat de VPN-client heeft geïnstalleerd. Identificeer eerst de levende:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Als resolved actief is en de symbolische koppeling naar zijn stub wijst, is het globale bestand gegenereerde uitvoer en is je bewerking cosmetisch. Als NetworkManager de verbinding bezit, horen de servers bij het verbindingsprofiel, dus de oplossing is een nmcli-eigenschapswijziging en geen bestandsbewerking. Als er een leveranciersdaemon draait, overleeft alleen zijn eigen herstelpad de volgende verbinding.

Ruim de linkstatus op die de client heeft achtergelaten

Een gedood proces kan zijn opruimhaak niet uitvoeren. SIGKILL kun je helemaal niet afvangen, SIGINT en SIGTERM wel, dus een tunnel die na een geforceerde kill „gewoon stopte“, laat vaak zowel de interfaceregistratie als de resolververmelding staan. Zoek de specifieke PID en stuur het signaal alleen naar die:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Grijp niet naar pkill -f vpn of killall vpn voordat je de volledige trefferlijst hebt gelezen. -f vergelijkt met de hele opdrachtregel, dus het kan een wrapperscript, een editorsessie of een ongerelateerd proces beëindigen waarvan het pad de tekenreeks bevat. Het verkeerde proces midden in het werk beëindigen is hoe een resolverprobleem een verloren bestand wordt.

resolvectl revert zet de DNS-configuratie tijdens runtime van die link terug, wat smaller is dan de resolver herstarten en veel smaller dan het globale bestand bewerken. Als de tunnelverbinding helemaal weg is, bouwt systemctl restart NetworkManager de verbindingsstatus opnieuw op, en dat is de stap waar de brondraden steeds naar terugkeren. Let op een servicemanager met Restart=always, want die kan een gedode client en zijn DNS-instellingen zo terugzetten.

De andere richting: gepushte DNS die nooit aankwam

Het spiegelbeeld van de verouderde vermelding is een tunnel zonder enige bruikbare resolver. Een DNS-optie in het profiel is een verzoek; het onderdeel dat de verbinding beheert, moet het aan de resolver overhandigen. Als het log laat zien dat de server is ontvangen maar de tunnelverbinding geen DNS-instellingen draagt, ontbreekt de integratie, niet de server.

Test de overdracht door het handmatig te doen, wat „de server is verkeerd“ scheidt van „niemand heeft het toegepast“:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Het routeringsdomein dat alles vangt, stuurt elke naam naar die link, wat een full-tunnelclient wil en wat gesplitste DNS niet mag gebruiken. Deze instellingen verdwijnen bij de volgende verbinding. Om ze blijvend te maken in NetworkManager, schakel automatische DNS uit, zet de server op de verbinding en voeg het domein toe:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Voor een bedrijfstunnel die alleen interne namen moet beantwoorden, som je die zones op met een leidende tilde in plaats van alles te vangen, zodat openbare namen de lokale resolver blijven gebruiken.

Workarounds die de volgende storing worden

resolv.conf kopiëren voordat je verbindt en daarna terugzetten is een legitieme regel in een runbook, en het is een workaround en geen reparatie. Hij faalt precies wanneer het ertoe doet, omdat een crash of een gedwongen herstart het terugzetten overslaat. Schrijf het op als workaround zodat de volgende persoon er niet op voortbouwt.

systemd-resolved uitschakelen en openbare servers hard coderen is de andere populaire zet. Het maakt verbinden en verbreken voorspelbaar en haalt DNS per link weg voor elk ander netwerk, wat gesplitste DNS voor interne namen breekt en het doel van een tunnel ondermijnt die queries binnen wil houden. resolvconf installeren en openbare servers vastpinnen kost hetzelfde met een extra laag. Behandel een van beide als diagnose: als het browsen terugkeert, heb je geleerd dat de resolverintegratie schuldig is, niet dat de openbare servers juist zijn.

De blijvende oplossing is één eigenaar per laag: bepaal welk onderdeel de DNS van de tunnelverbinding bezit en welk de globale standaard, schrijf dat op en haal de andere uit het pad. Controleer daarna na een verbreking met een naam die alleen de VPN oplost. Als een privénaam nog antwoordt, is de registratie niet verwijderd; als niets wordt opgelost, wijst het bestand naar een server die niet meer bestaat. Beide zijn zichtbaar in resolvectl voordat je een browser opent.