Urejanje resolv.conf ne odpravi težave z DNS po prekinitvi VPN

Prekinete VPN, ping 1.1.1.1 se še odziva, in vsako iskanje imena visi, dokler stran končno ne obupa. Nato cat /etc/resolv.conf pokaže imenski strežnik, ki je kdaj obstajal samo znotraj predora, običajno prvi na seznamu. Če izbrišete to vrstico, se zdi, da je težava odpravljena za približno deset minut, dokler je mirovanje, gostovanje Wi-Fi ali ponovni zagon ne vrne. Datoteka, ki ste jo uredili, ni nastavitev; je upodobitev stanja povezave, ki je v lasti druge komponente.

Zakaj en zastarel vnos stane sekunde na vsako poizvedbo

Resolver glibc prehodi seznam imenskih strežnikov po vrsti in počaka, da poteče časovna omejitev, preden poskusi naslednjega, in resolv.conf(5) omejuje ta seznam na tri vnose. Postavite resolver na strani predora, na primer 10.8.0.1, na vrh, potem ko je predor izginil, in vsaka poizvedba plača časovno omejitev, preden pade na strežnik, ki odgovori. Zato je simptom videti kot mrtva povezava in ne kot napaka DNS: brskalniki blokirajo, jim zmanjka časa in včasih postrežejo predpomnjen naslov, ki pozneje zastara.

To tudi pojasni, zakaj pritožba pride kot „internet je pokvarjen“. Ping na naslov IP dokaže, da je povezava v redu, zato je napaka videti kot v aplikaciji. Seznam resolverjev je prva stvar, ki jo je treba prebrati, in zadnja, ki jo je treba urediti.

Mit: resolv.conf je nastavitvena datoteka

Vprašajte, kaj je ta pot v resnici, preden jo spremenite:

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

Na gostitelju s systemd-resolved je simbolna povezava na stub datoteko, ki kaže na 127.0.0.53, in pravi strežniki živijo v stanju za vsako povezavo, ki ga izpiše resolvectl. Na gostitelju z NetworkManagerom je to lahko datoteka, ki jo NetworkManager zapiše iz aktivne povezave. Pri nekaterih odjemalcih ponudnikov je to navadna datoteka, ki se ob povezavi prepiše na mestu in, če nimate sreče, ob prekinitvi nikoli ne obnovi. To so trije različni lastniki, in ročno urejanje prvih dveh ali ne naredi ničesar ali pa zdrži do naslednjega omrežnega dogodka.

resolvectl status je pogled, ki pove resnico: strežniki DNS za vsako povezavo, usmerjevalne domene in ali povezava predora še obstaja. resolvectl query example.com gre dlje in pokaže, kateri vmesnik je odgovoril. Uporabite oba, preden se dotaknete datoteke, in upoštevajte, da brskalnik z lastnim varnim DNS vse to ignorira.

Poiščite lastnika, preden karkoli uredite

Običajno se tri komponente potegujejo za isto nastavitev: systemd-resolved, NetworkManager in to, kar je namestil odjemalec VPN. Najprej prepoznajte živo:

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

Če je resolved aktiven in simbolna povezava kaže na njegov stub, je globalna datoteka ustvarjen izhod in vaše urejanje je kozmetično. Če povezavo poseduje NetworkManager, strežniki pripadajo profilu povezave, zato je popravek sprememba lastnosti prek nmcli in ne urejanje datoteke. Če teče daemon ponudnika, naslednjo povezavo preživi le njegova lastna pot obnovitve.

Počistite stanje povezave, ki jo je odjemalec pustil za seboj

Ubit odjemalec ne more izvesti svoje kljuke za čiščenje. SIGKILL ni mogoče ujeti sploh, SIGINT in SIGTERM pa je mogoče, zato predor, ki se je po prisilnem ubijanju „kar ustavil“, pogosto pusti na mestu tako registracijo vmesnika kot vnos resolverja. Poiščite točen PID in pošljite signal samo njemu:

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

Ne segajte po pkill -f vpn ali killall vpn, preden preberete celoten seznam ujemanj. -f se ujema s celo ukazno vrstico, zato lahko konča ovijalno skripto, sejo urejevalnika ali nepovezan proces, katerega pot vsebuje ta niz. Končanje napačnega procesa sredi dela je način, kako težava z resolverjem postane izgubljena datoteka.

resolvectl revert ponastavi izvajalno konfiguracijo DNS te povezave, kar je ožje od ponovnega zagona resolverja in veliko ožje od urejanja globalne datoteke. Če je povezava predora popolnoma izginila, systemctl restart NetworkManager znova zgradi stanje povezave in to je korak, h kateremu se izvorne niti vedno znova vračajo. Bodite pozorni na upravitelja storitev z Restart=always, ker lahko ubit odjemalec in njegove nastavitve DNS takoj postavi nazaj.

Druga smer: potisnjen DNS, ki ni nikoli prispel

Zrcalna slika zastarelega vnosa je predor brez vsakega uporabnega resolverja. Možnost DNS v profilu je zahteva; komponenta, ki upravlja povezavo, jo mora predati resolverju. Če dnevnik kaže, da je bil strežnik prejet, povezava predora pa ne nosi nobenih nastavitev DNS, manjka integracija, ne strežnik.

Preizkusite predajo tako, da jo izvedete ročno, kar loči „strežnik je napačen“ od „nihče ga ni uporabil“:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Usmerjevalna domena, ki ujame vse, pošlje vsako ime na to povezavo, kar želi odjemalec polnega predora in česar razdeljeni DNS ne sme uporabljati. Te nastavitve izginejo ob naslednji povezavi. Če jih želite v NetworkManageru narediti trajne, izklopite samodejni DNS, nastavite strežnik na povezavi in dodajte domeno:

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 podjetniški predor, ki naj odgovarja le na notranja imena, naštejte te cones z vodilno tildo namesto ujemanja vsega, da bodo javna imena še naprej uporabljala lokalni resolver.

Obhodi, ki postanejo naslednja odpoved

Kopiranje resolv.conf pred povezavo in obnovitev po njej je legitimna vrstica v runbooku in je obhod, ne popravilo. Odpove prav takrat, ko je pomembno, ker se ob sesutju ali prisilnem ponovnem zagonu obnovitev izpusti. Zapišite ga kot obhod, da naslednja oseba ne bo gradila nanj.

Izklop systemd-resolved in trdo kodiranje javnih strežnikov je druga priljubljena poteza. Naredi povezovanje in prekinitev predvidljiva in odstrani DNS za vsako povezavo za vsa druga omrežja, kar pokvari razdeljeni DNS za notranja imena in izniči namen predora, ki naj bi poizvedbe zadržal znotraj sebe. Namestitev resolvconf in pripenjanje javnih strežnikov stane enako z dodatno plastjo. Obravnavajte katero koli od njiju kot diagnozo: če obnovi brskanje, ste se naučili, da je kriva integracija resolverja, ne da so javni strežniki pravilni.

Trajno popravilo je en lastnik na plast: odločite, katera komponenta ima DNS povezave predora in katera globalno privzeto vrednost, to zapišite in odstranite druge s poti. Nato po prekinitvi preverite z imenom, ki ga razreši samo VPN. Če zasebno ime še odgovarja, registracija ni bila odstranjena; če se nič ne razreši, datoteka kaže na strežnik, ki ne obstaja več. Oboje je vidno v resolvectl, preden odprete brskalnik.