Redaktimi i resolv.conf nuk e rregullon DNS-në pas shkëputjes së VPN-së

Ju shkëputni VPN-në, ping 1.1.1.1 përsëri përgjigjet, dhe çdo kërkim emri varet para se faqja më në fund të dorëzohet. Pastaj cat /etc/resolv.conf tregon një server emrash që ka ekzistuar ndonjëherë vetëm brenda tunelit, zakonisht i pari në listë. Fshirja e asaj rreshti duket se e rregullon për rreth dhjetë minuta, derisa një pezullim, një roaming Wi-Fi ose një rindezje ta kthejë. Skedari që redaktuate nuk është cilësimi; është një paraqitje e gjendjes së lidhjes që zotërohet nga një komponent tjetër.

Pse një hyrje e vjetruar kushton sekonda për çdo kërkim

Zgjidhësi i glibc përshkon listën e serverëve të emrave sipas radhës dhe pret skadimin e një afati kohor përpara se të provojë tjetrin, dhe resolv.conf(5) e kufizon atë listë në tre hyrje. Vendos një zgjidhës nga ana e tunelit si 10.8.0.1 në krye pasi tuneli të ketë ikur, dhe çdo kërkim paguan afatin kohor përpara se të bjerë në një server që përgjigjet. Kjo është arsyeja pse simptoma duket si lidhje e vdekur dhe jo si gabim DNS: shfletuesit bllokohen, u mbaron koha dhe ndonjëherë shërbejnë një adresë të ruajtur në cache që më vonë vjetrohet.

Kjo shpjegon gjithashtu pse ankesa vjen si «interneti është prishur». Një ping drejt një adrese IP provon që lidhja është në rregull, gjë që e bën defektin të duket i aplikacionit. Lista e zgjidhësve është gjëja e parë për të lexuar dhe e fundit për të redaktuar.

Miti: resolv.conf është një skedar cilësimesh

Pyetni çfarë është në të vërtetë rruga përpara se ta ndryshoni:

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

Në një host me systemd-resolved është një lidhje simbolike drejt një skedari stub që tregon 127.0.0.53, dhe serverët e vërtetë jetojnë në gjendjen për çdo lidhje që printon resolvectl. Në një host me NetworkManager mund të jetë një skedar që NetworkManager shkruan nga lidhja aktive. Në disa klientë të furnitorëve është një skedar i thjeshtë i rishkruar në vend gjatë lidhjes dhe, nëse nuk jeni me fat, nuk rikthehet kurrë gjatë shkëputjes. Këta janë tre pronarë të ndryshëm, dhe redaktimi me dorë i dy të parëve ose nuk bën asgjë ose zgjat deri në ngjarjen tjetër të rrjetit.

resolvectl status është pamja që thotë të vërtetën: serverë DNS për çdo lidhje, domenet e rrugëtimit dhe nëse lidhja e tunelit ekziston ende. resolvectl query example.com shkon më tej dhe tregon cila ndërfaqe u përgjigj. Përdorni të dyja përpara se të prekni një skedar, dhe mbani parasysh se një shfletues me DNS të sigurt të vetin i injoron të gjitha këto.

Gjeni pronarin përpara se të redaktoni çdo gjë

Zakonisht tre komponentë konkurrojnë për të njëjtin cilësim: systemd-resolved, NetworkManager dhe çfarë ka instaluar klienti i VPN-së. Identifikoni së pari atë të gjallë:

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

Nëse resolved është aktiv dhe lidhja simbolike tregon stub-in e tij, skedari global është dalje e gjeneruar dhe redaktimi juaj është kozmetik. Nëse NetworkManager zotëron lidhjen, serverët i përkasin profilit të lidhjes, kështu që rregullimi është një ndryshim vetie përmes nmcli dhe jo redaktim skedari. Nëse një demon i furnitorit është duke punuar, vetëm rruga e tij e rikthimit i mbijeton lidhjes tjetër.

Pastroni gjendjen e lidhjes që la klienti

Një klient i vrarë nuk mund të ekzekutojë grep-in e vet të pastrimit. SIGKILL nuk kapet fare, ndërsa SIGINT dhe SIGTERM kapen, kështu që një tunel që «thjesht u ndal» pas një vrasjeje të detyruar shpesh lë në vend si regjistrimin e ndërfaqes ashtu edhe hyrjen e zgjidhësit. Gjeni PID-në e saktë dhe dërgoni sinjalin vetëm atij:

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

Mos u shtrini drejt pkill -f vpn ose killall vpn përpara se të lexoni listën e plotë të përputhjeve. -f përputhet me të gjithë rreshtin e komandës, kështu që mund të përfundojë një skript mbështjellës, një sesion redaktori ose një proces të palidhur, rruga e të cilit përmban atë varg. Përfundimi i procesit të gabuar në mes të punës është mënyra se si një problem zgjidhësi bëhet një skedar i humbur.

resolvectl revert rivendos konfigurimin DNS të kohës së ekzekutimit të asaj lidhjeje, që është më i ngushtë se rindezja e zgjidhësit dhe shumë më i ngushtë se redaktimi i skedarit global. Nëse lidhja e tunelit ka humbur plotësisht, systemctl restart NetworkManager rindërton gjendjen e lidhjes dhe është hapi ku fijet e burimit kthehen vazhdimisht. Kini kujdes me një menaxher shërbimesh me Restart=always, sepse mund të kthejë një klient të vrarë dhe cilësimet e tij DNS direkt.

Drejtimi tjetër: DNS i shtyrë që nuk arriti kurrë

Imazhi pasqyrë i hyrjes së vjetruar është një tunel pa asnjë zgjidhës të përdorshëm. Një opsion DNS në profil është një kërkesë; komponenti që menaxhon lidhjen duhet t’ia dorëzojë zgjidhësit. Nëse regjistri tregon se serveri u prit, por lidhja e tunelit nuk mbart asnjë cilësim DNS, mungon integrimi, jo serveri.

Testoni dorëzimin duke e bërë me dorë, çka ndan «serveri është i gabuar» nga «askush nuk e zbatoi»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Domeni i rrugëtimit që kap gjithçka dërgon çdo emër drejt asaj lidhjeje, çka dëshiron një klient tuneli të plotë dhe çka DNS i ndarë nuk duhet të përdorë. Këto cilësime zhduken në lidhjen tjetër. Për t’i bërë të përhershme në NetworkManager, çaktivizoni DNS-në automatike, vendosni serverin në lidhje dhe shtoni domenin:

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

Për një tunel kompanie që duhet të përgjigjet vetëm për emrat e brendshëm, listoni ato zona me një tildë fillestare në vend të kapjes së gjithçkaje, që emrat publikë të vazhdojnë të përdorin zgjidhësin lokal.

Zgjidhje të përkohshme që bëhen ndërprerja tjetër

Kopjimi i resolv.conf përpara lidhjes dhe rikthimi i tij pas është një rresht legitim në një runbook, dhe është zgjidhje e përkohshme dhe jo riparim. Ai dështon pikërisht kur ka rëndësi, sepse një rrëzim ose një rindezje e detyruar e kalon rikthimin. Shkruajeni si zgjidhje të përkohshme që personi tjetër të mos ndërtojë mbi të.

Çaktivizimi i systemd-resolved dhe kodimi i fortë i serverëve publikë është lëvizja tjetër popullore. I bën lidhjen dhe shkëputjen të parashikueshme dhe heq DNS-në për çdo lidhje për çdo rrjet tjetër, gjë që prish DNS-në e ndarë për emrat e brendshëm dhe asgjëson qëllimin e një tuneli të menduar për t’i mbajtur kërkesat brenda. Instalimi i resolvconf dhe fiksimi i serverëve publikë kushton të njëjtën gjë me një shtresë shtesë. Trajtojeni njërën prej tyre si diagnozë: nëse e kthen shfletimin, keni mësuar se integrimi i zgjidhësit është fajtori, jo se serverët publikë janë të saktë.

Rregullimi i qëndrueshëm është një pronar për çdo shtresë: vendosni cili komponent zotëron DNS-në e lidhjes së tunelit dhe cili zotëron parazgjedhjen globale, shkruajeni dhe hiqni të tjerët nga rruga. Pastaj verifikoni pas një shkëputjeje me një emër që zgjidh vetëm VPN-ja. Nëse një emër privat përsëri përgjigjet, regjistrimi nuk u hoq; nëse asgjë nuk zgjidhet, skedari tregon një server që nuk ekziston më. Të dyja shihen në resolvectl përpara se të hapni një shfletues.