Sustabdykite dviejų Linux paslaugų varžybas dėl /etc/resolv.conf

DNS nuolat grįžta į ankstesnę būseną, VPN prisijungimas iš naujo atšaukia jūsų pataisą, ir galiausiai kas nors komandoje pasiūlo užrakinti failą. Ši seka yra simptomas, o ne sprendimas: du komponentai abu mano valdantys /etc/resolv.conf, ir laimi tas, kuris rašo paskutinis. Failo užrakinimas neišsprendžia nuosavybės konflikto, jis tik jį paslepia ir tuo pačiu sugadina komponentą, kurio iš tikrųjų norėjote. Atlikite keturis patikrinimus žemiau iš eilės ir sutvarkykite išdėstymą tame lygmenyje, kuris jam priklauso, o ne pačiame faile.

Patikrinimas 1: ar tai simbolinė nuoroda, ir į ką

Pradėkite nuo paties failo, nes kelias, kurį redaguojate, gali būti visai ne failas. Simbolinė nuoroda į sprendėjo vykdymo katalogą elgiasi visiškai kitaip nei paprastas failas, kurį perrašo kliento scenarijus:

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

Nuoroda į systemd-resolved stub kelią reiškia, kad failo turinys generuojamas, o rankinis redagavimas bus perrašytas per kitą įvykį. Paprastą failą su nameserver eilutėmis paprastai rašo tas klientas arba DHCP kabliukas, kuris paleidžiamas prisijungiant. Abu variantai teisėti; svarbu žinoti, kurį turite, prieš ką nors keisdami.

Patikrinimas 2: kuris demonas veikia

Išsiaiškinkite, kas iš tikrųjų aktyvu, o ne kas įdiegta. Šiuolaikinėje distribucijoje gali būti keli sprendėjai, o atsako tas, kuris laiko 53 prievadą loopback sąsajoje:

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

Būsenos išvestis nurodo DNS serverius pagal ryšį ir maršrutizavimo domenus, o tai yra žemėlapis, kurio reikia split DNS. Jei vidiniai vardai turi eiti į vidinį serverį, o visa kita – į viešą, ši politika gyvena domenuose pagal ryšį, o jos suplokštinimas į statinį nameserver sąrašą faile tyliai praranda šį skirtumą.

NetworkManager savoji konfigūracija nusprendžia, kurį iš šių backendų jis naudoja. Jo dns= nustatymas pagrindiniame konfigūracijos faile pasirenka tarp jo vidinio sprendėjo, dnsmasq, systemd-resolved ir none, o distribucija galėjo pasirinkti už jus. Perskaitykite šį nustatymą prieš nuspręsdami, ką „DNS taisymas“ reiškia šiame serveryje.

Patikrinimas 3: ką VPN klientui leidžiama rašyti

Čia paprastai ir gyvena konfliktas. VPN klientas, kuris tiesiogiai perrašo sprendėjo failą, kovos su bet kuria paslauga, kuri jį taip pat prižiūri, ir pralaimi tas, kuris paleidžiamas pirmas. Naujausi OpenVPN leidimai gali perduoti DNS nustatymus systemd-resolved, o ne perrašyti failą – tai yra bendradarbiavimo elgsena, kurios norite; senesni scenarijai ir ranka rašyti kabliukai dažnai kviečia pasenusį pagalbinį įrankį arba tiesiog perrašo failą.

WireGuard situacija forma panaši: sąsajos konfigūracija pati DNS nevaldo, tai daro įrankiai aplink ją, per sprendėjo pagalbininką arba resolved integraciją. Jei įdiegti du tokie pagalbininkai, abu prisijungdami bandys pritaikyti savo pasaulio vaizdą.

Skaitykite kliento up ir down kabliukus, o ne spėliokite. Kelios shell eilutės /etc/openvpn/up.sh arba lygiaverčiame kataloge paaiškina elgseną, kuri kitaip atrodo atsitiktinė, ir tai taip pat vieta, kur galite priversti klientą bendradarbiauti, o ne konkuruoti.

Patikrinimas 4: taisykite pas savininką, o ne faile

Kai žinote savininką, konfigūruokite DNS per to savininko palaikomą sąsają. systemd-resolved atveju tai reiškia nustatymus pagal ryšį ir maršrutizavimo domenus vietoj statinio failo; NetworkManager atveju – ryšio profilio DNS nustatymus ir pasirinktą backendą; distribucijai su resolvconf integracija – rašymą per tą pagalbininką.

Nedarykite failo nekeičiamo. Nekeičiamumo požymis sustabdo teisėtus DHCP atnaujinimus ir VPN atnaujinimus kartu su tais, su kuriais kovojote, ir palieka sistemą būsenoje, kai kitas paketo atnaujinimas ar prisijungimas iš naujo sukelia gedimą, kurio niekas negali paaiškinti iš konfigūracijos. Jis paslepia nuosavybės konfliktą, o tai yra būtent tai, ką bandėte išspręsti.

Kai du komponentai tikrai turi sugyventi, duokite jiems skirtingus darbus. Leiskite tinklo tvarkytuvei valdyti sąsajos lygmens konfigūraciją, leiskite VPN klientui per tą pačią integraciją prisidėti DNS ir domenais pagal ryšį, ir pašalinkite trečią scenarijų, kuris tiesiogiai rašo failą. systemd-resolved dokumentacija aprašo palaikomus režimus ir ką kiekvienas jų atskleidžia /etc/resolv.conf. Pasirinkite režimą, atitinkantį politikos kiekį, kurį turite išsaugoti. Jei split DNS svarbus, stub išdėstymas su domenais pagal ryšį jį išsaugo, o režimas, kuris kopijuoja upstream serverius į failą, tyliai jį suplokština.

Tikrinkite po prisijungimo iš naujo, o ne po redagavimo

Failas, kuris atrodo taisyklingai iškart po jūsų pakeitimo, nieko neįrodo, nes kitas įvykis dar neįvyko. Suaktyvinkite seką, kuri anksčiau jį sugadindavo: nuleiskite ir vėl pakelkite tunelį, atnaujinkite DHCP nuomą arba perjunkite sąsają, tada dar kartą perskaitykite tas pačias reikšmes.

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

Tada patvirtinkite svarbų skirtumą: vidinis vardas išsprendžiamas per vidinį serverį, o viešas vardas vis dar veikia. Konfigūracija, kuri viską siunčia į vidinį serverį, atrodo gerai, kol kas nors nepabando pasiekti interneto per tunelį, o konfigūracija, kuri viską siunčia į viešą, nutekina vidinius vardus.

Įrašykite savininką, backendą ir simbolinės nuorodos režimą diegimo pastabose. Ta viena pastraipa paverčia būsimą paketo atnaujinimą iš incidento į peržiūros punktą ir neleidžia kitam žmogui iš naujo atrasti to paties konflikto su chattr komanda.