Pigilan ang dalawang serbisyo ng Linux na nag-aagawan sa /etc/resolv.conf

Paulit-ulit na bumabalik ang DNS sa dating estado, binabaligtad ng muling pagkonekta ng VPN ang ayos mo, at sa huli may nagmumungkahi sa team na i-lock ang file. Ang sekwensyang iyon ay sintomas, hindi solusyon: dalawang bahagi ang parehong naniniwala na pag-aari nila ang /etc/resolv.conf, at ang huling nagsusulat ang panalo. Ang pag-lock ng file ay hindi nag-aayos ng labanan sa pagmamay-ari, tinatago lamang nito at sinisira ang bahaging talagang gusto mo. Gawin ang apat na pagsusuri sa ibaba nang sunod-sunod, at ayusin ang kaayusan sa antas na nagmamay-ari nito, hindi sa file.

Pagsusuri 1: ito ba ay symlink, at saan

Magsimula sa file mismo, dahil ang path na ine-edit mo ay maaaring hindi ang file. Ang symlink papunta sa runtime directory ng resolver ay kumikilos nang lubos na iba kaysa sa ordinaryong file na muling isinusulat ng script ng kliyente:

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

Ang link papunta sa stub path ng systemd-resolved ay nangangahulugang ang nilalaman ng file ay ginagawa, at ang manu-manong pag-edit ay mapapatungan sa susunod na pangyayari. Ang ordinaryong file na may mga linyang nameserver ay karaniwang isinusulat ng kliyente o DHCP hook na tumatakbo kapag kumonekta. Pareho silang lehitimo; ang mahalaga ay malaman kung alin ang mayroon ka bago ka magbago ng kahit ano.

Pagsusuri 2: aling daemon ang tumatakbo

Alamin kung ano ang talagang aktibo, hindi kung ano ang naka-install. Maaaring may ilang resolver sa isang modernong distribusyon, at ang may hawak ng port 53 sa loopback interface ang sumasagot:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

Binabanggit ng output ng status ang mga DNS server bawat link at ang mga routing domain, na siyang mapa na kailangan mo para sa split DNS. Kung ang mga panloob na pangalan ay dapat pumunta sa panloob na server at lahat ng iba sa pampublikong server, ang patakarang iyon ay nasa mga domain bawat link, at ang pagpapapantay nito sa isang static na listahan ng nameserver sa file ay tahimik na nawawala ang pagkakaibang iyon.

Ang sariling configuration ng NetworkManager ang nagpasya kung alin sa mga backend na ito ang ginagamit. Ang setting nitong dns= sa pangunahing configuration file ay pumipili sa pagitan ng panloob na resolver, dnsmasq, systemd-resolved at none, at maaaring pinili na ito ng distribusyon para sa iyo. Basahin ang setting na iyon bago magpasya kung ano ang ibig sabihin ng “pag-aayos ng DNS” sa host na ito.

Pagsusuri 3: ano ang pinapayagang isulat ng VPN client

Dito karaniwang nakatira ang labanan. Ang VPN client na direktang nagsusulat muli ng file ng resolver ay makikipag-away sa anumang serbisyong nag-aalaga rin nito, at ang natatalo ay ang unang tumatakbo. Ang mga bagong release ng OpenVPN ay maaaring magbigay ng mga setting ng DNS sa systemd-resolved sa halip na muling isulat ang file, na siyang kooperatibong pag-uugali na gusto mo; ang mga lumang script at manu-manong isinulat na hook ay madalas na tumatawag ng lumang helper o sinasadyang pinapataob ang file.

Ang sitwasyon ng WireGuard ay katulad sa hugis: ang configuration ng interface mismo ay hindi namamahala ng DNS, ang mga tool sa paligid nito ang gumagawa, sa pamamagitan ng resolver helper o integrasyon ng resolved. Kung may dalawang ganoong helper na naka-install, parehong susubukang ipatupad ang kanilang pananaw sa mundo kapag kumonekta.

Basahin ang up at down hook ng client sa halip na manghula. Ang ilang linya ng shell sa /etc/openvpn/up.sh o katumbas na direktoryo ay nagpapaliwanag ng pag-uugaling mukhang random kung hindi, at doon mo rin mapapakooperate ang client sa halip na makipagkompetensya.

Pagsusuri 4: ayusin ito sa may-ari, hindi sa file

Kapag alam mo na ang may-ari, i-configure ang DNS sa pamamagitan ng interface na sinusuportahan ng may-ari na iyon. Para sa systemd-resolved, nangangahulugan ito ng mga setting bawat link at mga routing domain sa halip na static na file; para sa NetworkManager, ang mga setting ng DNS ng profile ng koneksyon at ang napiling backend; para sa distribusyong gumagamit ng integrasyon ng resolvconf, ang pagsulat sa pamamagitan ng helper na iyon.

Huwag gawing hindi mababago ang file. Pinipigilan ng hindi mababagong attribute ang mga lehitimong pag-renew ng DHCP at pag-update ng VPN kasama ng mga nilalabanan mo, at iniiwan ang system sa estadong ang susunod na pag-upgrade ng package o muling pagkonekta ay gumagawa ng pagkabigo na walang makapagpapaliwanag mula sa configuration. Itinatago nito ang labanan sa pagmamay-ari, na siyang eksaktong bagay na sinusubukan mong ayusin.

Kung saan talagang kailangang magkasama ang dalawang bahagi, bigyan sila ng magkaibang trabaho. Hayaang pagmamay-ari ng network manager ang configuration sa antas ng interface, hayaang mag-ambag ang VPN client ng DNS at mga domain bawat link sa pamamagitan ng parehong integrasyon, at alisin ang ikatlong script na direktang nagsusulat ng file. Inilalahad ng dokumentasyon ng systemd-resolved ang mga mode na sinusuportahan nito at kung ano ang ibinubunyag ng bawat isa sa /etc/resolv.conf. Piliin ang mode na tumutugma sa dami ng patakarang kailangan mong panatilihin. Kung mahalaga ang split DNS, pinapanatili ito ng stub arrangement na may mga domain bawat link, habang ang mode na kumokopya ng upstream server sa file ay tahimik na nagpapapantay nito.

I-verify pagkatapos ng muling pagkonekta, hindi pagkatapos ng pag-edit

Ang file na mukhang tama kaagad pagkatapos ng pagbabago mo ay walang pinapatunayan, dahil hindi pa nangyayari ang susunod na pangyayari. I-trigger ang sekwensyang dating sumisira nito: ibaba at itaas ang tunnel, i-renew ang DHCP lease o ilipat ang interface, pagkatapos ay basahin muli ang parehong mga halaga.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

Pagkatapos, kumpirmahin ang pagkakaibang mahalaga: nareresolba ang panloob na pangalan sa pamamagitan ng panloob na server habang gumagana pa rin ang pampublikong pangalan. Ang configuration na nagpapadala ng lahat sa panloob na server ay mukhang maayos hanggang may sumubok na maabot ang internet sa tunnel, at ang configuration na nagpapadala ng lahat sa pampubliko ay naglalabas ng mga panloob na pangalan.

Itala ang may-ari, backend at mode ng symlink sa mga tala ng deployment. Ang nag-iisang talata na iyon ay ginagawang item ng pagsusuri ang isang pag-upgrade ng package sa hinaharap mula sa insidente, at pinipigilan ang susunod na tao na muling matuklasan ang parehong labanan gamit ang utos na chattr.