Ndalni dy shërbime Linux që konkurrojnë për /etc/resolv.conf

DNS vazhdimisht kthehet në gjendjen e mëparshme, rilidhja e VPN-së anulon korrigjimin tuaj dhe në fund dikush në ekip sugjeron bllokimin e skedarit. Kjo sekuencë është një simptomë, jo një zgjidhje: dy komponentë të dy mendojnë se zotërojnë /etc/resolv.conf, dhe fiton ai që shkruan i fundit. Bllokimi i skedarit nuk e zgjidh konfliktin e pronësisë, thjesht e fsheh dhe në të njëjtën kohë prish komponentin që në të vërtetë dëshironit. Kryeni katër kontrollet më poshtë sipas radhës dhe rregulloni strukturën në nivelin që e zotëron, jo në skedar.

Kontrolli 1: a është lidhje simbolike, dhe nga çfarë

Filloni me vetë skedarin, sepse shtegu që po redaktoni mund të mos jetë fare skedari. Një lidhje simbolike në drejtorinë e ekzekutimit të një zgjidhësi sillet krejt ndryshe nga një skedar i zakonshëm që një skript klienti e rishkruan:

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

Një lidhje drejt një shtegu stub të systemd-resolved do të thotë që përmbajtja e skedarit gjenerohet, dhe redaktimi manual do të mbishkruhet në ngjarjen tjetër. Një skedar i zakonshëm me rreshta nameserver zakonisht shkruhet nga klienti ose grepa DHCP që ekzekutohet gjatë lidhjes. Të dyja janë legjitime; e rëndësishme është të dini se cilin keni përpara se të ndryshoni diçka.

Kontrolli 2: cili demon po ekzekutohet

Zbuloni çfarë është në të vërtetë aktive, jo çfarë është e instaluar. Në një shpërndarje moderne mund të jenë të pranishëm disa zgjidhës, dhe përgjigjet ai që mban portën 53 në ndërfaqen loopback:

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

Rezultati i statusit emërton serverët DNS për çdo lidhje dhe domenet e rrugëzimit, që është harta që ju nevojitet për split DNS. Nëse emrat e brendshëm duhet të shkojnë te një server i brendshëm dhe gjithçka tjetër te një publik, ajo politikë jeton në domenet për çdo lidhje, dhe rrafshimi i saj në një listë statike nameserver në skedar e humb atë dallim në heshtje.

Konfigurimi i vetë NetworkManager vendos cilin prej këtyre backend-eve përdor. Cilësimi dns= në skedarin kryesor të konfigurimit zgjedh midis zgjidhësit të tij të brendshëm, dnsmasq, systemd-resolved dhe none, dhe shpërndarja mund të ketë zgjedhur në vendin tuaj. Lexoni atë cilësim përpara se të vendosni çfarë do të thotë “rregullimi i DNS” në këtë host.

Kontrolli 3: çfarë lejohet të shkruajë klienti VPN

Këtu zakonisht jeton konflikti. Një klient VPN që rishkruan drejtpërdrejt skedarin e zgjidhësit do të luftojë me çdo shërbim që e mirëmban gjithashtu, dhe humbësi është ai që ekzekutohet i pari. Versionet e reja të OpenVPN mund t'i dorëzojnë cilësimet e DNS systemd-resolved në vend që të rishkruajnë skedarin, që është sjellja bashkëpunuese që dëshironi; skriptet më të vjetra dhe grepat e shkruara me dorë shpesh thërrasin një mjet ndihmës të vjetruar ose thjesht mbishkruajnë skedarin.

Situata e WireGuard është e ngjashme në formë: konfigurimi i ndërfaqes nuk e menaxhon vetë DNS-in, e bëjnë mjetet përreth, përmes një ndihmësi zgjidhësi ose integrimit resolved. Nëse janë instaluar dy ndihmës të tillë, të dy do të përpiqen të zbatojnë vizionin e tyre të botës gjatë lidhjes.

Lexoni grepat up dhe down të klientit në vend që të hamendësoni. Disa rreshta shell në /etc/openvpn/up.sh ose në një drejtori ekuivalente shpjegojnë një sjellje që përndryshe duket e rastësishme, dhe pikërisht aty mund ta bëni klientin të bashkëpunojë në vend që të konkurrojë.

Kontrolli 4: rregullojeni te pronari, jo në skedar

Pasi ta dini pronarin, konfiguroni DNS përmes ndërfaqes që mbështet ai pronar. Për systemd-resolved kjo do të thotë cilësime për çdo lidhje dhe domene rrugëzimi në vend të një skedari statik; për NetworkManager cilësimet e DNS të profilit të lidhjes dhe backend-i i zgjedhur; për një shpërndarje me integrim resolvconf shkrimi përmes atij ndihmësi.

Mos e bëni skedarin të pandryshueshëm. Atributi i pandryshueshmërisë ndalon përtëritjet legjitime të DHCP dhe përditësimet e VPN së bashku me ato me të cilat po luftonit, dhe e lë sistemin në një gjendje ku përditësimi i ardhshëm i paketave ose rilidhja prodhon një dështim që askush nuk mund ta shpjegojë nga konfigurimi. E fsheh konfliktin e pronësisë, që është pikërisht ajo që po përpiqeshit të zgjidhnit.

Aty ku dy komponentë duhet vërtet të bashkëjetojnë, jepuni punë të ndryshme. Lëreni menaxherin e rrjetit të zotërojë konfigurimin në nivel ndërfaqeje, lëreni klientin VPN të kontribuojë me DNS dhe domene për çdo lidhje përmes të njëjtit integrim, dhe hiqni skriptin e tretë që shkruan drejtpërdrejt skedarin. Dokumentacioni i systemd-resolved shpjegon mënyrat që mbështet dhe çfarë zbulon secila prej tyre në /etc/resolv.conf. Zgjidhni mënyrën që përputhet me sasinë e politikës që duhet të mbani. Nëse split DNS ka rëndësi, struktura stub me domene për çdo lidhje e ruan atë, ndërsa mënyra që kopjon serverët upstream në skedar e rrafshon atë në heshtje.

Verifikoni pas një rilidhjeje, jo pas redaktimit

Një skedar që duket i saktë menjëherë pas ndryshimit tuaj nuk provon asgjë, sepse ngjarja tjetër nuk ka ndodhur ende. Aktivizoni sekuencën që dikur e priste: ulni dhe ngrini tunelin, përtëritni qiranë DHCP ose ndërroni ndërfaqen, dhe pastaj lexoni përsëri të njëjtat vlera.

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

Pastaj konfirmoni dallimin që ka rëndësi: emri i brendshëm zgjidhet përmes serverit të brendshëm ndërsa emri publik vazhdon të funksionojë. Një konfigurim që dërgon gjithçka te serveri i brendshëm duket mirë derisa dikush të përpiqet të arrijë internetin përmes tunelit, dhe një konfigurim që dërgon gjithçka te ai publik zbulon emra të brendshëm.

Shënoni pronarin, backend-in dhe mënyrën e lidhjes simbolike në shënimet e vendosjes. Ai një paragraf e kthen një përditësim të ardhshëm paketash nga incident në pike rishikimi, dhe e pengon personin tjetër të rizbulojë të njëjtin konflikt me komandën chattr.