Å endre resolv.conf rettar ikkje DNS etter at VPN-en koplar frå

Du koplar frå VPN-en, ping 1.1.1.1 svarar framleis, og kvart namneoppslag heng før sida til slutt gir opp. Då viser cat /etc/resolv.conf ein namneserver som berre nokon gong har eksistert inne i tunnelen, som regel først i lista. Å sletta den linja ser ut til å retta det i om lag ti minutt, heilt til ein kvilemodus, ein Wi-Fi-roaming eller ein omstart set den tilbake. Fila du endra er ikkje innstillinga; ho er ei framstilling av lenkjetilstand som ein annan komponent eig.

Kvifor ein utdatert oppføring kostar sekund per oppslag

glibc-resolveren går gjennom namneserverlista i rekkjefølgje og ventar ut eit tidsavbrot før han prøver den neste, og resolv.conf(5) avgrensar den lista til tre oppføringar. Set ein resolver på tunnelsida som 10.8.0.1 øvst etter at tunnelen er borte, og kvart oppslag betaler tidsavbrotet før det fell gjennom til ein server som svarar. Difor ser symptomet ut som eit daudt samband og ikkje som ein DNS-feil: nettlesarar blokkerer, går tom for tid og leverer stundom ei bufra adresse som seinare vert utdatert.

Det forklarar òg kvifor klaga kjem som «internett er øydelagt». Ein ping til ei IP-adresse beviser at lenka er i orden, noko som får feilen til å sjå ut som applikasjonen sin. Resolverlista er det første ein skal lesa og det siste ein skal endre.

Myten: resolv.conf er ei innstillingsfil

Spør kva stien faktisk er før du endrar han:

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

På ein systemd-resolved-vert er ho ei symbolsk lenkje til ei stub-fil som peikar på 127.0.0.53, og dei verkelege serverane bur i tilstanden per lenkje som resolvectl skriv ut. På ein NetworkManager-vert kan ho vera ei fil som NetworkManager skriv frå den aktive tilkoplinga. Hos nokre leverandørklientar er ho ei vanleg fil som vert skriven på nytt på staden ved tilkopling og, om du er uheldig, aldri gjenoppretta ved fråkopling. Det er tre ulike eigarar, og manuell endring av dei to første gjer anten ingenting eller held til neste nettverkshending.

resolvectl status er visninga som seier sanninga: DNS-serverar per lenkje, rutingsdomene og om tunnellenkja framleis finst. resolvectl query example.com går lenger og viser kva grensesnitt som svara. Bruk begge før du rører ei fil, og hugs at ein nettlesar med eigen trygg DNS ignorerer alt dette.

Finn eigaren før du endrar noko

Tre komponentar kappast vanlegvis om same innstillinga: systemd-resolved, NetworkManager og det VPN-klienten har installert. Identifiser den levande først:

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

Viss resolved er aktiv og den symbolske lenkja peikar på stubben, er den globale fila generert utdata og endringa di kosmetisk. Viss NetworkManager eig tilkoplinga, høyrer serverane til tilkoplingsprofilen, så rettinga er ei nmcli-eigenskapendring og ikkje ei filendring. Viss ein leverandørdemon køyrer, er det berre hans eigen gjenopprettingsveg som overlever neste tilkopling.

Rydd opp i lenkjetilstanden klienten la att

Ein drepen klient kan ikkje køyre oppryddingskroken sin. SIGKILL kan ikkje fangast i det heile, medan SIGINT og SIGTERM kan, så ein tunnel som «berre stoppa» etter eit tvinga drap, let ofte både grensesnittregistreringa og resolveroppføringa stå. Finn den konkrete PID-en og send signalet berre til den:

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

Ikkje grip etter pkill -f vpn eller killall vpn før du har lese heile trefflista. -f matchar heile kommandolinja, så han kan avslutte eit innpakningsskript, ein redaktørsesjon eller ein urelatert prosess der stien inneheld strengen. Å avslutte feil prosess midt i arbeidet er måten eit resolverproblem vert ei tapt fil på.

resolvectl revert nullstiller køyretids-DNS-konfigurasjonen for den lenkja, noko som er smalare enn å starte resolveren på nytt og mykje smalare enn å endre den globale fila. Viss tunnellenkja er heilt borte, byggjer systemctl restart NetworkManager opp tilkoplingstilstanden på nytt, og det er trinnet kjeldetrådane stadig vender tilbake til. Ver merksam på ein tenestebehandlar med Restart=always, for han kan setje ein drepen klient og DNS-innstillingane hans rett tilbake.

Den andre retninga: pusht DNS som aldri kom fram

Spegelbiletet av den utdaterte oppføringa er ein tunnel heilt utan brukbar resolver. Eit DNS-val i profilen er ei førespurnad; komponenten som styrer tilkoplinga, må overlevere han til resolveren. Viss loggen viser at serveren vart motteken, men tunnellenkja ikkje ber nokon DNS-innstillingar, manglar integreringa, ikkje serveren.

Test overleveringa ved å gjere det manuelt, noko som skil «serveren er feil» frå «ingen brukte han»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Rutingsdomenet som fangar alt, sender kvart namn til den lenkja, som er det ein fulltunnelklient vil ha og det delt DNS ikkje må bruke. Desse innstillingane forsvinn ved neste tilkopling. For å gjere dei varige i NetworkManager, slå av automatisk DNS, set serveren på tilkoplinga 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 ein bedriftstunnel som berre skal svare på interne namn, list opp desse sonene med ein lelande tilde i staden for å fange alt, slik at offentlege namn framleis brukar den lokale resolveren.

Mellombels løysingar som vert den neste utfalla

Å kopiere resolv.conf før tilkopling og gjenopprette han etterpå er ei legitim linje i ein runbook, og det er ei mellombels løysing og ikkje ein reparasjon. Ho sviktar akkurat når det gjeld, fordi eit krasj eller ein tvinga omstart hoppar over gjenopprettinga. Skriv det ned som ei mellombels løysing, slik at neste person ikkje byggjer på ho.

Å slå av systemd-resolved og hardkode offentlege serverar er det andre populære trekket. Det gjer tilkopling og fråkopling føreseieleg og fjernar DNS per lenkje for alle andre nettverk, noko som øydelegg delt DNS for interne namn og underminerer føremålet med ein tunnel som skal halde spørjingar inni seg. Å installere resolvconf og feste offentlege serverar kostar det same med eit ekstra lag. Behandle kven som helst av dei som ein diagnose: viss han gjenopprettar surfing, har du lært at resolverintegreringa er skuldig, ikkje at dei offentlege serverane er riktige.

Den varige rettinga er éin eigar per lag: avgjer kva komponent som eig DNS-en til tunnellenkja og kven som eig den globale standarden, skriv det ned og fjern dei andre frå stien. Stadfest deretter etter ei fråkopling med eit namn som berre VPN-en løyser. Viss eit privat namn framleis svarar, vart registreringa ikkje fjerna; viss ingenting vert løyst, peikar fila på ein server som ikkje finst lenger. Begge er synlege i resolvectl før du opnar ein nettlesar.