Å redigere resolv.conf fikser ikke DNS etter at VPN-en kobles fra

Du kobler fra VPN-en, ping 1.1.1.1 svarer fortsatt, og hvert navneoppslag henger før siden til slutt gir opp. Da viser cat /etc/resolv.conf en navneserver som bare noen gang har eksistert inne i tunnelen, som regel først i listen. Å slette den linjen ser ut til å fikse det i omtrent ti minutter, helt til en hvilemodus, en Wi-Fi-roaming eller en omstart setter den tilbake. Filen du redigerte, er ikke innstillingen; den er en gjengivelse av lenketilstand som en annen komponent eier.

Hvorfor én utdatert oppføring koster sekunder per oppslag

glibc-resolveren går gjennom navneserverlisten i rekkefølge og venter ut en tidsavbrudd før den prøver den neste, og resolv.conf(5) begrenser den listen til tre oppføringer. Sett en resolver på tunnelsiden som 10.8.0.1 øverst etter at tunnelen er borte, og hvert oppslag betaler tidsavbruddet før det faller gjennom til en server som svarer. Derfor ser symptomet ut som en død forbindelse og ikke som en DNS-feil: nettlesere blokkerer, går tom for tid og leverer noen ganger en bufret adresse som senere blir utdatert.

Det forklarer også hvorfor klagen kommer som «internett er ødelagt». En ping til en IP-adresse beviser at lenken er i orden, noe som får feilen til å se ut som applikasjonens. Resolverlisten er det første man skal lese og det siste man skal redigere.

Myten: resolv.conf er en innstillingsfil

Spør hva stien faktisk er før du endrer den:

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

På en systemd-resolved-vert er den en symbolsk lenke til en stub-fil som peker på 127.0.0.53, og de virkelige serverne bor i tilstanden per lenke som resolvectl skriver ut. På en NetworkManager-vert kan den være en fil som NetworkManager skriver fra den aktive tilkoblingen. Hos noen leverandørklienter er den en vanlig fil som skrives på nytt på stedet ved tilkobling og, hvis du er uheldig, aldri gjenopprettes ved frakobling. Det er tre forskjellige eiere, og manuell redigering av de to første gjør enten ingenting eller holder til neste nettverkshendelse.

resolvectl status er visningen som sier sannheten: DNS-servere per lenke, rutingsdomener og om tunnellenken fortsatt finnes. resolvectl query example.com går lenger og viser hvilket grensesnitt som svarte. Bruk begge før du rører en fil, og husk at en nettleser med egen sikker DNS ignorerer alt dette.

Finn eieren før du redigerer noe

Tre komponenter konkurrerer vanligvis om samme innstilling: systemd-resolved, NetworkManager og det VPN-klienten har installert. Identifiser den levende først:

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

Hvis resolved er aktiv og den symbolske lenken peker på stubben, er den globale filen generert utdata og redigeringen din kosmetisk. Hvis NetworkManager eier tilkoblingen, tilhører serverne tilkoblingsprofilen, så rettelsen er en nmcli-egenskapsendring og ikke en filredigering. Hvis en leverandørdemon kjører, er det bare dens egen gjenopprettingsvei som overlever neste tilkobling.

Rydd opp i lenketilstanden klienten la igjen

En drept klient kan ikke kjøre oppryddingskroken sin. SIGKILL kan ikke fanges i det hele tatt, mens SIGINT og SIGTERM kan, så en tunnel som «bare stoppet» etter en tvungen drap, etterlater ofte både grensesnittregistreringen og resolveroppføringen på plass. Finn den konkrete PID-en og send signalet bare til den:

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

Ikke grip etter pkill -f vpn eller killall vpn før du har lest hele trefflisten. -f matcher hele kommandolinjen, så den kan avslutte et innpakningsskript, en redaktørsesjon eller en urelatert prosess hvis sti inneholder strengen. Å avslutte feil prosess midt i arbeidet er måten et resolverproblem blir en tapt fil på.

resolvectl revert nullstiller kjøretids-DNS-konfigurasjonen for den lenken, noe som er smalere enn å starte resolveren på nytt og mye smalere enn å redigere den globale filen. Hvis tunnellenken er helt borte, bygger systemctl restart NetworkManager opp tilkoblingstilstanden på nytt, og det er trinnet kildetrådene stadig vender tilbake til. Vær oppmerksom på en tjenestebehandler med Restart=always, for den kan sette en drept klient og DNS-innstillingene dens rett tilbake.

Den andre retningen: pushet DNS som aldri kom frem

Speilbildet av den utdaterte oppføringen er en tunnel helt uten brukbar resolver. Et DNS-alternativ i profilen er en forespørsel; komponenten som styrer tilkoblingen, må overlevere den til resolveren. Hvis loggen viser at serveren ble mottatt, men tunnellenken ikke bærer noen DNS-innstillinger, mangler integrasjonen, ikke serveren.

Test overleveringen ved å gjøre det manuelt, noe som skiller «serveren er feil» fra «ingen anvendte den»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Rutingsdomenet som fanger alt, sender hvert navn til den lenken, som er det en fulltunnelklient vil ha og det delt DNS ikke må bruke. Disse innstillingene forsvinner ved neste tilkobling. For å gjøre dem varige i NetworkManager, slå av automatisk DNS, sett serveren på tilkoblingen og legg til domenet:

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

For en bedriftstunnel som bare skal svare på interne navn, list opp disse sonene med en ledende tilde i stedet for å fange alt, slik at offentlige navn fortsatt bruker den lokale resolveren.

Midlertidige løsninger som blir den neste utfall

Å kopiere resolv.conf før tilkobling og gjenopprette den etterpå er en legitim linje i en runbook, og det er en midlertidig løsning og ikke en reparasjon. Den svikter akkurat når det gjelder, fordi et krasj eller en tvungen omstart hopper over gjenopprettingen. Skriv det ned som en midlertidig løsning, slik at neste person ikke bygger på den.

Å slå av systemd-resolved og hardkode offentlige servere er det andre populære trekket. Det gjør tilkobling og frakobling forutsigbar og fjerner DNS per lenke for alle andre nettverk, noe som ødelegger delt DNS for interne navn og undergraver formålet med en tunnel som skal holde spørringer inni seg. Å installere resolvconf og feste offentlige servere koster det samme med et ekstra lag. Behandle hvilken som helst av dem som en diagnose: hvis den gjenoppretter surfing, har du lært at resolverintegrasjonen er skyldig, ikke at de offentlige serverne er riktige.

Den varige rettelsen er én eier per lag: avgjør hvilken komponent som eier tunnellenkens DNS og hvilken som eier den globale standarden, skriv det ned og fjern de andre fra stien. Verifiser deretter etter en frakobling med et navn som bare VPN-en løser opp. Hvis et privat navn fortsatt svarer, ble registreringen ikke fjernet; hvis ingenting løses opp, peker filen på en server som ikke finnes lenger. Begge er synlige i resolvectl før du åpner en nettleser.