Hindi inaayos ng pag-edit ng resolv.conf ang DNS pagkatapos humiwalay ang VPN

Humiwalay ka sa VPN, sumasagot pa rin ang ping 1.1.1.1, at bawat paghahanap ng pangalan ay nakabitin bago tuluyang sumuko ang pahina. Pagkatapos ay ipinapakita ng cat /etc/resolv.conf ang isang name server na kailanman ay umiral lamang sa loob ng tunnel, karaniwang una sa listahan. Ang pagbura sa linyang iyon ay tila nag-aayos nito nang mga sampung minuto, hanggang sa isang suspend, isang Wi-Fi roaming o isang restart ang magbalik nito. Ang file na in-edit mo ay hindi ang setting; ito ay isang paglalarawan ng link state na pag-aari ng ibang bahagi.

Bakit ang isang lumang entry ay nagkakahalaga ng mga segundo bawat paghahanap

Ang glibc resolver ay dumadaan sa listahan ng name server ayon sa pagkakasunod-sunod at hinihintay ang isang timeout bago subukan ang susunod, at resolv.conf(5) ay nililimitahan ang listahang iyon sa tatlong entry. Ilagay ang isang resolver sa gilid ng tunnel gaya ng 10.8.0.1 sa tuktok pagkatapos mawala ang tunnel, at bawat paghahanap ay nagbabayad ng timeout bago bumagsak sa isang server na sumasagot. Iyon ang dahilan kung bakit ang sintomas ay mukhang patay na koneksyon at hindi error sa DNS: nagba-block ang mga browser, nauubusan ng oras at kung minsan ay naghahain ng naka-cache na address na later ay nagiging luma.

Ipinapaliwanag din nito kung bakit dumarating ang reklamo bilang «sira ang internet». Ang ping sa isang IP address ay nagpapatunay na maayos ang link, na nagpapamukhang kasalanan ng application ang sira. Ang listahan ng resolver ang unang bagay na dapat basahin at ang huling bagay na dapat i-edit.

Ang alamat: ang resolv.conf ay isang settings file

Itanong kung ano talaga ang path bago mo ito baguhin:

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

Sa host na may systemd-resolved ito ay simbolikong link sa isang stub file na tumuturo sa 127.0.0.53, at ang tunay na mga server ay nakatira sa estado bawat link na ipinapalimbag ng resolvectl. Sa host na may NetworkManager ito ay maaaring file na isinusulat ng NetworkManager mula sa aktibong koneksyon. Sa ilang kliyente ng vendor ito ay simpleng file na muling isinusulat sa lugar kapag kumokonekta at, kung hindi ka mapalad, hindi kailanman naibabalik kapag humihiwalay. Tatlong magkaibang may-ari iyon, at ang pag-edit sa unang dalawa sa pamamagitan ng kamay ay maaaring walang gawin o tumagal hanggang sa susunod na kaganapan sa network.

Ang resolvectl status ang view na nagsasabi ng totoo: mga DNS server bawat link, mga routing domain at kung umiiral pa ang tunnel link. Ang resolvectl query example.com ay lumalayo pa at ipinapakita kung aling interface ang sumagot. Gamitin ang pareho bago hawakan ang isang file, at tandaan na ang browser na may sariling secure DNS ay binabalewala ang lahat ng ito.

Hanapin ang may-ari bago mag-edit ng anuman

Karaniwang tatlong bahagi ang nag-aagawan para sa parehong setting: systemd-resolved, NetworkManager at ang inilagay ng kliyente ng VPN. Tukuyin muna ang buhay:

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

Kung aktibo ang resolved at ang simbolikong link ay tumuturo sa stub nito, ang global file ay generated na output at ang iyong edit ay kosmetiko. Kung pag-aari ng NetworkManager ang koneksyon, ang mga server ay nabibilang sa profile ng koneksyon, kaya ang pag-aayos ay pagbabago ng property sa nmcli at hindi pag-edit ng file. Kung may tumatakbong daemon ng vendor, tanging ang sarili nitong landas ng pagbabalik ang nakakaligtas sa susunod na koneksyon.

Linisin ang link state na iniwan ng kliyente

Ang isang patay na kliyente ay hindi makakapagpatakbo ng sarili nitong cleanup hook. Ang SIGKILL ay hindi mahuhuli kahit kaunti, samantalang ang SIGINT at SIGTERM ay nahuhuli, kaya ang tunnel na «tumigil lang» pagkatapos ng sapilitang pagpatay ay kadalasang nag-iiwan ng parehong pagpaparehistro ng interface at ng entry ng resolver sa lugar. Hanapin ang partikular na PID at ipadala ang signal doon lamang:

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

Huwag umabot sa pkill -f vpn o killall vpn bago basahin ang buong listahan ng tugma. Ang -f ay tumutugma sa buong command line, kaya maaari nitong tapusin ang isang wrapper script, isang editor session o isang walang kaugnayang proseso na ang path ay naglalaman ng string. Ang pagtatapos sa maling proseso sa gitna ng trabaho ang paraan kung paano nagiging nawawalang file ang problema sa resolver.

Ang resolvectl revert ay nagre-reset ng runtime DNS configuration ng link na iyon, na mas makitid kaysa sa pag-restart ng resolver at mas makitid nang labis kaysa sa pag-edit ng global file. Kung tuluyang nawala ang tunnel link, ang systemctl restart NetworkManager ay muling bumubuo ng estado ng koneksyon at iyon ang hakbang na palaging binabalikan ng mga source thread. Mag-ingat sa service manager na may Restart=always, dahil maaari nitong ibalik nang direkta ang isang patay na kliyente at ang mga setting nito sa DNS.

Ang kabilang direksyon: DNS na itinulak ngunit hindi dumating

Ang salamin ng lumang entry ay isang tunnel na walang anumang magagamit na resolver. Ang DNS option sa profile ay isang kahilingan; dapat itong ibigay ng bahaging namamahala sa koneksyon sa resolver. Kung ipinapakita ng log na natanggap ang server ngunit walang dalang setting ng DNS ang tunnel link, ang kulang ay ang integrasyon, hindi ang server.

Subukan ang paghahatid sa pamamagitan ng paggawa nito nang manu-mano, na naghihiwalay sa «mali ang server» mula sa «walang naglapat nito»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Ang routing domain na humuhuli sa lahat ay nagpapadala ng bawat pangalan sa link na iyon, na siyang gusto ng full-tunnel client at siyang hindi dapat gamitin ng split DNS. Nawawala ang mga setting na ito sa susunod na koneksyon. Upang gawin silang permanente sa NetworkManager, patayin ang automatic DNS, itakda ang server sa koneksyon at idagdag ang domain:

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

Para sa tunnel ng kumpanya na dapat tumugon lamang sa panloob na pangalan, ilista ang mga zone na iyon na may nangungunang tilde sa halip na humuli sa lahat, upang ang mga pampublikong pangalan ay patuloy na gumamit ng lokal na resolver.

Mga pansamantalang solusyon na nagiging susunod na pagkawala

Ang pagkopya ng resolv.conf bago kumonekta at ibalik ito pagkatapos ay isang lehitimong linya sa isang runbook, at ito ay pansamantalang solusyon at hindi pag-aayos. Nabigo ito kapag mahalaga, dahil ang isang crash o sapilitang reboot ay lumalaktaw sa pagbabalik. Isulat ito bilang pansamantalang solusyon upang ang susunod na tao ay hindi magtayo dito.

Ang pagpatay sa systemd-resolved at pag-hardcode ng mga pampublikong server ang isa pang sikat na hakbang. Ginagawa nitong mahulaan ang pagkonekta at paghihiwalay at inaalis ang DNS bawat link para sa bawat iba pang network, na sumisira sa split DNS para sa panloob na pangalan at nagpapawalang-bisa sa layunin ng tunnel na inilaan upang itago ang mga query sa loob nito. Ang pag-install ng resolvconf at pag-pin ng mga pampublikong server ay nagkakahalaga ng pareho na may dagdag na layer. Ituring ang alinman sa mga ito bilang diagnosis: kung naibalik nito ang pag-browse, natutunan mo na ang integrasyon ng resolver ang may kasalanan, hindi na tama ang mga pampublikong server.

Ang matibay na pag-aayos ay isang may-ari bawat layer: magpasya kung aling bahagi ang may-ari ng DNS ng tunnel link at alin ang may-ari ng global default, isulat iyon at alisin ang iba sa landas. Pagkatapos ay i-verify pagkatapos humiwalay gamit ang isang pangalan na tanging ang VPN ang nireresolba. Kung sumasagot pa rin ang isang pribadong pangalan, hindi inalis ang pagpaparehistro; kung wala nang nireresolba, ang file ay tumuturo sa isang server na wala na. Pareho silang nakikita sa resolvectl bago mo buksan ang browser.