resolv.conf redagavimas nepataiso DNS po VPN atsijungimo

Atsijungiate VPN, ping 1.1.1.1 vis dar atsako, o kiekviena vardo užklausa kabo, kol puslapis pagaliau pasiduoda. Tada cat /etc/resolv.conf rodo vardų serverį, kuris kada nors egzistavo tik tunelio viduje, dažniausiai pirmas sąraše. Tos eilutės ištrynimas atrodo išsprendžia problemą maždaug dešimčiai minučių, kol sustabdymas, Wi-Fi klajonė ar perkrovimas ją grąžina. Failas, kurį redagavote, nėra nuostata; tai saitos būsenos atvaizdavimas, priklausantis kitam komponentui.

Kodėl vienas pasenęs įrašas kainuoja sekundes kiekvienai užklausai

glibc sprendiklis eina per vardų serverių sąrašą iš eilės ir palaukia, kol baigsis laiko limitas, prieš bandydamas kitą, o resolv.conf(5) riboja šį sąrašą trimis įrašais. Įdėkite tunelio pusės sprendiklį, pavyzdžiui, 10.8.0.1, į sąrašo viršų po to, kai tunelio nebėra, ir kiekviena užklausa sumoka laiko limitą, prieš pereidama prie serverio, kuris atsako. Todėl simptomas atrodo kaip mirusi jungtis, o ne DNS klaida: naršyklės blokuoja, baigiasi laikas ir kartais pateikia podėlyje laikomą adresą, kuris vėliau pasensta.

Tai taip pat paaiškina, kodėl skundas ateina kaip „internetas sugedo“. Ping į IP adresą įrodo, kad saitas veikia, todėl gedimas atrodo esantis programoje. Sprendiklių sąrašas yra pirmas dalykas, kurį reikia perskaityti, ir paskutinis, kurį reikia redaguoti.

Mitas: resolv.conf yra nuostatų failas

Paklauskite, kas iš tikrųjų yra tas kelias, prieš jį keisdami:

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

systemd-resolved kompiuteryje tai simbolinė nuoroda į stub failą, rodantį į 127.0.0.53, o tikrieji serveriai gyvena būsenoje pagal saitus, kurią spausdina resolvectl. NetworkManager kompiuteryje tai gali būti failas, kurį NetworkManager įrašo iš aktyvios jungties. Kai kuriuose gamintojų klientuose tai paprastas failas, perrašomas vietoje prisijungiant ir, jei nepasisekė, niekada neatkuriamas atsijungiant. Tai trys skirtingi savininkai, o pirmųjų dviejų redagavimas ranka arba nieko nedaro, arba laikosi iki kito tinklo įvykio.

resolvectl status yra vaizdas, kuris sako tiesą: DNS serveriai pagal saitus, maršrutizavimo domenai ir ar tunelio saitas dar egzistuoja. resolvectl query example.com eina toliau ir parodo, kuri sąsaja atsakė. Naudokite abu prieš liesdami failą ir atminkite, kad naršyklė su savo saugiu DNS viso to nepaiso.

Raskite savininką prieš ką nors redaguodami

Paprastai trys komponentai varžosi dėl tos pačios nuostatos: systemd-resolved, NetworkManager ir tai, ką įdiegė VPN klientas. Pirmiausia nustatykite gyvąjį:

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

Jei resolved aktyvus ir simbolinė nuoroda rodo į jo stub, pasaulinis failas yra sugeneruota išvestis, o jūsų redagavimas kosmetinis. Jei jungtį valdo NetworkManager, serveriai priklauso jungties profiliui, tad pataisa yra nmcli savybės pakeitimas, o ne failo redagavimas. Jei veikia gamintojo demonas, kitą prisijungimą išgyvena tik jo paties atkūrimo kelias.

Išvalykite saitos būseną, kurią paliko klientas

Nužudytas klientas negali paleisti savo valymo kablio. SIGKILL apskritai negalima pagauti, o SIGINT ir SIGTERM galima, todėl tunelis, kuris po priverstinio nužudymo „tiesiog sustojo“, dažnai palieka vietoje ir sąsajos registraciją, ir sprendiklio įrašą. Raskite konkretų PID ir siųskite signalą tik jam:

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

Nesiekite pkill -f vpn ar killall vpn, kol neperskaitėte viso atitikmenų sąrašo. -f atitinka visą komandų eilutę, todėl gali užbaigti apvalkalo scenarijų, redaktoriaus sesiją ar nesusijusį procesą, kurio kelyje yra ta eilutė. Neteisingo proceso užbaigimas darbo viduryje yra būdas, kuriuo sprendiklio problema tampa pamestu failu.

resolvectl revert atstato tos saitos vykdymo laiko DNS konfigūraciją, o tai siauriau nei sprendiklio perkrovimas ir daug siauriau nei pasaulinio failo redagavimas. Jei tunelio saitas visiškai išnyko, systemctl restart NetworkManager atkuria jungties būseną, ir tai yra žingsnis, prie kurio šaltinio gijos nuolat grįžta. Stebėkite paslaugų tvarkyklę su Restart=always, nes ji gali nužudytą klientą ir jo DNS nuostatas tiesiog grąžinti.

Kita kryptis: stumiamas DNS, kuris taip ir neatėjo

Pasenusio įrašo veidrodinis atvaizdas yra tunelis visiškai be tinkamo sprendiklio. DNS parinktis profilyje yra prašymas; jungtį valdantis komponentas turi jį perduoti sprendikliui. Jei žurnale matyti, kad serveris gautas, bet tunelio saitas neperneša jokių DNS nuostatų, trūksta integracijos, o ne serverio.

Išbandykite perdavimą atlikdami jį ranka, tai atskiria „serveris neteisingas“ nuo „niekas jo nepritaikė“:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Visą pagaunantis maršrutizavimo domenas siunčia kiekvieną vardą į tą saitą, ko nori viso tunelio klientas ir ko padalintas DNS neturi naudoti. Šios nuostatos išnyksta kitą kartą prisijungus. Kad jos būtų nuolatinės NetworkManager, išjunkite automatinį DNS, nustatykite serverį jungtyje ir pridėkite domeną:

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

Įmonės tuneliui, kuris turi atsakyti tik į vidinius vardus, išvardykite tas zonas su pradiniu tildės ženklu, o ne su viską pagaunančiu, kad vieši vardai ir toliau naudotų vietinį sprendiklį.

Apėjimo būdai, kurie tampa kitu gedimu

resolv.conf kopijavimas prieš prisijungiant ir atkūrimas po to yra teisėta runbook eilutė, ir tai apėjimo būdas, o ne taisymas. Jis žlunga būtent tada, kai tai svarbu, nes strigtis ar priverstinis perkrovimas praleidžia atkūrimą. Užrašykite tai kaip apėjimo būdą, kad kitas žmogus ant jo nestatytų.

systemd-resolved išjungimas ir viešų serverių kietasis kodavimas yra kitas populiarus žingsnis. Jis daro prisijungimą ir atsijungimą nuspėjamus ir pašalina DNS pagal saitus visiems kitiems tinklams, o tai sugriauna padalintą DNS vidiniams vardams ir sužlugdo tunelio, skirto užklausas išlaikyti jo viduje, tikslą. resolvconf įdiegimas ir viešų serverių prisegimas kainuoja tiek pat su papildomu sluoksniu. Traktuokite bet kurį kaip diagnostiką: jei jis atkuria naršymą, sužinojote, kad kalta sprendiklio integracija, o ne tai, kad vieši serveriai yra teisingi.

Ilgalaikė pataisa yra vienas savininkas kiekvienam sluoksniui: nuspręskite, kuris komponentas valdo tunelio saitos DNS, o kuris pasaulinį numatytąjį, užrašykite tai ir pašalinkite kitus iš kelio. Tada po atsijungimo patikrinkite vardu, kurį išsprendžia tik VPN. Jei privatus vardas vis dar atsako, registracija nebuvo pašalinta; jei niekas neišsprendžiama, failas rodo į serverį, kurio nebėra. Abu matomi resolvectl prieš atidarant naršyklę.