At redigere resolv.conf løser ikke DNS, når VPN’en kobles fra

Du kobler VPN’en fra, ping 1.1.1.1 svarer stadig, og hvert navneopslag hænger, før siden til sidst giver op. Så viser cat /etc/resolv.conf en navneserver, der kun nogensinde har eksisteret inde i tunnelen, som regel først på listen. At slette den linje ser ud til at løse det i cirka ti minutter, indtil en suspendering, en Wi-Fi-roaming eller en genstart sætter den tilbage. Filen, du redigerede, er ikke indstillingen; den er en gengivelse af forbindelsestilstand, som en anden komponent ejer.

Hvorfor én forældet post koster sekunder pr. opslag

glibc-resolveren går gennem navneserverlisten i rækkefølge og venter en timeout ud, før den prøver den næste, og resolv.conf(5) begrænser den liste til tre poster. Sæt en resolver på tunnelsiden som 10.8.0.1 øverst, efter at tunnelen er væk, og hvert opslag betaler timeouten, før det falder igennem til en server, der svarer. Det er derfor, symptomet ser ud som en død forbindelse i stedet for en DNS-fejl: browsere blokerer, løber tør for tid og leverer nogle gange en cachet adresse, der senere bliver forældet.

Det forklarer også, hvorfor klagen kommer som »internettet er i stykker«. Et ping til en IP-adresse beviser, at forbindelsen er fin, hvilket får fejlen til at ligne noget i programmet. Resolverlisten er det første, man skal læse, og det sidste, man skal redigere.

Myten: resolv.conf er en indstillingsfil

Spørg, hvad stien egentlig er, før du ændrer den:

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

På en systemd-resolved-vært er den et symbolsk link til en stub-fil, der peger på 127.0.0.53, og de rigtige servere bor i tilstand pr. forbindelse, som resolvectl udskriver. På en NetworkManager-vært kan den være en fil, som NetworkManager skriver fra den aktive forbindelse. Hos nogle leverandørklienter er den en almindelig fil, der genskrives på stedet ved forbindelse og, hvis du er uheldig, aldrig gendannes ved afbrydelse. Det er tre forskellige ejere, og manuel redigering af de to første gør enten ingenting eller holder til den næste netværkshændelse.

resolvectl status er den visning, der siger sandheden: DNS-servere pr. forbindelse, routingdomæner og om tunne-forbindelsen stadig findes. resolvectl query example.com går videre og viser, hvilken grænseflade der svarede. Brug begge, før du rører en fil, og husk, at en browser med sin egen sikre DNS ignorerer det hele.

Find ejeren, før du redigerer noget

Tre komponenter konkurrerer normalt om den samme indstilling: systemd-resolved, NetworkManager og hvad VPN-klienten nu har installeret. Identificér først den levende:

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

Hvis resolved er aktiv, og det symbolske link peger på dens stub, er den globale fil genereret output, og din redigering er kosmetisk. Hvis NetworkManager ejer forbindelsen, tilhører serverne forbindelsesprofilen, så rettelsen er en nmcli-egenskabsændring frem for en filredigering. Hvis en leverandørdæmon kører, er dens egen gendannelsesvej den eneste, der overlever næste forbindelse.

Ryd forbindelsestilstanden, som klienten efterlod

En dræbt klient kan ikke køre sit oprydningshook. SIGKILL kan slet ikke fanges, mens SIGINT og SIGTERM kan, så en tunnel, der »bare stoppede« efter et tvunget kill, efterlader ofte både grænsefladeregistreringen og resolverposten på plads. Find den konkrete PID, og send signalet til netop den:

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

Grib ikke efter pkill -f vpn eller killall vpn, før du har læst hele matchlisten. -f matcher hele kommandolinjen, så den kan afslutte et wrapper-script, en editorsession eller en urelateret proces, hvis sti indeholder strengen. At afslutte den forkerte proces midt i arbejdet er måden, hvorpå et resolverproblem bliver en tabt fil.

resolvectl revert nulstiller den kørende DNS-konfiguration for den forbindelse, hvilket er snævrere end at genstarte resolveren og meget snævrere end at redigere den globale fil. Hvis tunne-forbindelsen er helt væk, genopbygger systemctl restart NetworkManager forbindelsestilstanden, og det er det trin, som kildetrådene bliver ved med at vende tilbage til. Hold øje med en tjenestestyring med Restart=always, for den kan sætte en dræbt klient og dens DNS-indstillinger direkte tilbage.

Den anden retning: skubbet DNS, som aldrig nåede frem

Spejlbilledet af den forældede post er en tunnel helt uden brugbar resolver. En DNS-indstilling i profilen er en anmodning; den komponent, der styrer forbindelsen, skal give den videre til resolveren. Hvis loggen viser, at serveren blev modtaget, men tunne-forbindelsen ikke bærer nogen DNS-indstillinger, mangler integrationen, ikke serveren.

Test overdragelsen ved at gøre det manuelt, hvilket adskiller »serveren er forkert« fra »ingen anvendte den«:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Routingdomænet, der fanger alt, sender hvert navn til den forbindelse, hvilket er det, en full-tunnel-klient vil have, og det, som delt DNS ikke må bruge. Disse indstillinger forsvinder ved næste forbindelse. For at gøre dem varige i NetworkManager skal du slå automatisk DNS fra, sætte serveren på forbindelsen og tilføje domænet:

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 "~."

Til en virksomhedstunnel, der kun skal svare på interne navne, skal du liste de zoner med en indledende tilde i stedet for at fange alt, så offentlige navne fortsat bruger den lokale resolver.

Midlertidige løsninger, der bliver den næste nedbrud

At kopiere resolv.conf før forbindelse og gendanne den bagefter er en legitim linje i en runbook, og det er en midlertidig løsning frem for en reparation. Den fejler præcis, når det gælder, fordi et nedbrud eller en tvungen genstart springer gendannelsen over. Skriv det ned som en midlertidig løsning, så den næste person ikke bygger videre på den.

At slå systemd-resolved fra og hardkode offentlige servere er det andet populære træk. Det gør forbindelse og afbrydelse forudsigelige og fjerner DNS pr. forbindelse for alle andre netværk, hvilket ødelægger delt DNS for interne navne og undergraver formålet med en tunnel, der skal holde forespørgsler inde i sig. At installere resolvconf og fastgøre offentlige servere koster det samme med et ekstra lag. Behandl enhver af dem som en diagnose: hvis den genopretter browsing, har du lært, at resolverintegrationen er skyldig, ikke at de offentlige servere er korrekte.

Den holdbare rettelse er én ejer pr. lag: beslut, hvilken komponent der ejer tunne-forbindelsens DNS, og hvilken der ejer den globale standard, skriv det ned, og fjern de andre fra stien. Verificér derefter efter en afbrydelse med et navn, som kun VPN’en opløser. Hvis et privat navn stadig svarer, blev registreringen ikke fjernet; hvis intet opløses, peger filen på en server, der ikke findes længere. Begge er synlige i resolvectl, før du åbner en browser.