Uređivanje resolv.conf ne popravlja DNS nakon prekida VPN-a

Prekinete VPN, ping 1.1.1.1 još odgovara, a svako traženje imena visi prije nego što stranica konačno odustane. Zatim cat /etc/resolv.conf pokaže poslužitelj imena koji je ikada postojao samo unutar tunela, obično prvi na listi. Brisanje tog retka izgleda kao da rješava problem na desetak minuta, dok ga suspendiranje, Wi-Fi roaming ili restart ne vrate natrag. Datoteka koju ste uredili nije postavka; ona je prikaz stanja veze koje posjeduje druga komponenta.

Zašto jedan zastarjeli unos košta sekunde po svakom upitu

glibc resolver prolazi kroz listu poslužitelja imena redom i čeka istek vremena prije nego što pokuša sljedeći, a resolv.conf(5) ograničava tu listu na tri unosa. Stavite resolver s tunelske strane kao što je 10.8.0.1 na vrh nakon što tunel nestane i svaki upit plaća timeout prije nego što padne na poslužitelj koji odgovara. Zato simptom izgleda kao mrtva veza, a ne kao DNS greška: preglednici blokiraju, isteknu im vremena i ponekad posluže keširanu adresu koja kasnije zastari.

To također objašnjava zašto žalba dolazi kao „internet je pokvaren“. Ping na IP adresu dokazuje da je veza u redu, što kvar čini sličnim problemu u aplikaciji. Lista resolvera je prva stvar koju treba pročitati i posljednja koju treba urediti.

Mit: resolv.conf je datoteka s postavkama

Pitajte što je putanja zapravo prije nego što je promijenite:

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

Na hostu sa systemd-resolved to je simbolička veza na stub datoteku koja pokazuje na 127.0.0.53, a pravi poslužitelji žive u stanju po vezi koje ispisuje resolvectl. Na hostu s NetworkManagerom to može biti datoteka koju NetworkManager zapisuje iz aktivne veze. Kod nekih klijentskih programa dobavljača to je obična datoteka koja se prepisuje na mjestu pri spajanju i, ako nemate sreće, nikad se ne vraća pri prekidu. To su tri različita vlasnika, a ručno uređivanje prva dva ili ne radi ništa ili traje do sljedećeg mrežnog događaja.

resolvectl status je prikaz koji govori istinu: DNS poslužitelji po vezi, domene usmjeravanja i postoji li tunelska veza još. resolvectl query example.com ide dalje i pokazuje koje je sučelje odgovorilo. Koristite oboje prije nego što dotaknete datoteku i imajte na umu da preglednik s vlastitim sigurnim DNS-om sve to ignorira.

Nađite vlasnika prije nego što bilo što uredite

Tri komponente obično se natječu za istu postavku: systemd-resolved, NetworkManager i što god je VPN klijent instalirao. Prvo identificirajte onu koja je živa:

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

Ako je resolved aktivan i simbolička veza pokazuje na njegov stub, globalna datoteka je generirani izlaz i vaše uređivanje je kozmetičko. Ako NetworkManager posjeduje vezu, poslužitelji pripadaju profilu veze, pa je popravak promjena svojstva kroz nmcli, a ne uređivanje datoteke. Ako radi demon dobavljača, samo njegov vlastiti put vraćanja preživljava sljedeće spajanje.

Očistite stanje veze koje je klijent ostavio za sobom

Ubijeni klijent ne može izvršiti svoju kuku za čišćenje. SIGKILL se uopće ne može uhvatiti, dok SIGINT i SIGTERM mogu, pa tunel koji je „samo stao“ nakon prisilnog ubijanja često ostavlja i registraciju sučelja i unos resolvera na mjestu. Nađite konkretni PID i pošaljite signal samo njemu:

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

Ne posežite za pkill -f vpn ili killall vpn prije nego što pročitate cijelu listu podudaranja. -f podudara cijeli naredbeni redak, pa može prekinuti omotni skript, sesiju uređivača ili nepovezani proces čija putanja sadrži taj niz. Prekidanje pogrešnog procesa usred rada način je na koji problem resolvera postaje izgubljena datoteka.

resolvectl revert resetira runtime DNS konfiguraciju te veze, što je uže od restarta resolvera i mnogo uže od uređivanja globalne datoteke. Ako je tunelska veza potpuno nestala, systemctl restart NetworkManager ponovno gradi stanje veze i to je korak kojem se izvorne teme stalno vraćaju. Pazite na upravitelja servisima s Restart=always, jer može vratiti ubijeni klijent i njegove DNS postavke ravno natrag.

Drugi smjer: gurnuti DNS koji nikad nije stigao

Zrcalna slika zastarjelog unosa je tunel bez ikakvog upotrebljivog resolvera. DNS opcija u profilu je zahtjev; komponenta koja upravlja vezom mora ga predati resolveru. Ako zapisnik pokazuje da je poslužitelj primljen, ali tunelska veza ne nosi nikakve DNS postavke, nedostaje integracija, a ne poslužitelj.

Testirajte predaju tako što ćete je izvesti ručno, što odvaja „poslužitelj je pogrešan“ od „nitko ga nije primijenio“:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Domena usmjeravanja koja hvata sve šalje svako ime na tu vezu, što je ono što klijent punog tunela želi i što podijeljeni DNS ne smije koristiti. Te postavke nestaju pri sljedećem spajanju. Da biste ih učinili trajnima u NetworkManageru, onemogućite automatski DNS, postavite poslužitelj na vezu i dodajte domenu:

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

Za korporativni tunel koji treba odgovarati samo na interna imena, navedite te zone s vodećom tildom umjesto hvatanja svega, tako da javna imena nastave koristiti lokalni resolver.

Zaobilazna rješenja koja postaju sljedeći ispad

Kopiranje resolv.conf prije spajanja i vraćanje nakon toga legitiman je redak u runbooku i to je zaobilazno rješenje, a ne popravak. Ono zakaže točno kad je važno, jer rušenje ili prisilni reboot preskoče vraćanje. Zapišite to kao zaobilazno rješenje da sljedeća osoba ne gradi na njemu.

Onemogućavanje systemd-resolved i tvrdo kodiranje javnih poslužitelja drugi je popularan potez. Čini spajanje i prekid predvidivima i uklanja DNS po vezi za svaku drugu mrežu, što kvari podijeljeni DNS za interna imena i obesmišljava svrhu tunela namijenjenog držanju upita unutar njega. Instaliranje resolvconfa i prikvačivanje javnih poslužitelja košta isto uz dodatni sloj. Tretirajte bilo koje od toga kao dijagnostiku: ako vrati pregledavanje, naučili ste da je kriva integracija resolvera, a ne da su javni poslužitelji ispravni.

Trajno rješenje je jedan vlasnik po sloju: odlučite koja komponenta posjeduje DNS tunelske veze, a koja globalni zadani, zapišite to i uklonite ostale iz putanje. Zatim provjerite nakon prekida imenom koje samo VPN razrješava. Ako privatno ime još odgovara, registracija nije uklonjena; ako se ništa ne razrješava, datoteka pokazuje na poslužitelj koji više ne postoji. Oboje je vidljivo u resolvectl prije nego što otvorite preglednik.