Peatage kaks Linuxi teenust, mis võistlevad /etc/resolv.confi pärast

DNS taastub ikka ja jälle, VPN-i taasühendus tühistab teie paranduse ja lõpuks soovitab keegi meeskonnas faili lukustada. See jada on sümptom, mitte lahendus: kaks komponenti arvavad mõlemad, et neile kuulub /etc/resolv.conf, ja võidab see, kes kirjutab viimasena. Faili lukustamine ei lahenda omandikonflikti, vaid ainult peidab selle, lõhkudes samal ajal komponendi, mida te tegelikult tahtsite. Käige allolevad neli kontrolli järjekorras läbi ja parandage korraldus sellel tasandil, kellele see kuulub, mitte failil.

Kontroll 1: kas see on sümbollink ja kuhu

Alustage failist endast, sest tee, mida muudate, ei pruugi üldse fail olla. Sümbollink resolveri käituskataloogi käitub täiesti teisiti kui tavaline fail, mille kliendiskript üle kirjutab:

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

Link systemd-resolvedi stub-teele tähendab, et faili sisu genereeritakse, ja käsitsi muutmine kirjutatakse järgmise sündmuse korral üle. Tavalise nameserver-ridadega faili kirjutab tavaliselt see klient või DHCP-konks, mis ühendamisel töötab. Mõlemad on õiguspärased; oluline on teada, kumb teil on, enne kui midagi muudate.

Kontroll 2: milline deemon töötab

Uurige, mis on tegelikult aktiivne, mitte mis on paigaldatud. Kaasaegses distributsioonis võib olla mitu resolverit ja vastab see, mis hoiab loopback-liidesel porti 53:

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

Olekuväljund nimetab lingipõhised DNS-serverid ja marsruutimisdomeenid, mis on kaart, mida split-DNS-i jaoks vajate. Kui sisemised nimed peavad minema sisemisse serverisse ja kõik muu avalikku, elab see poliitika lingipõhistes domeenides, ja selle lamedaks muutmine failis olevaks staatiliseks nameserveri loendiks kaotab selle eristuse vaikselt.

NetworkManageri enda konfiguratsioon otsustab, millist neist backendidest see kasutab. Selle säte dns= põhikonfiguratsioonifailis valib selle sisemise resolveri, dnsmasqi, systemd-resolvedi ja none'i vahel, ja distributsioon võis valida teie eest. Lugege seda sätet enne, kui otsustate, mida “DNS-i parandamine” selles hostis tähendab.

Kontroll 3: mida tohib VPN-klient kirjutada

Siin konflikt tavaliselt elabki. VPN-klient, mis kirjutab resolverifaili otse üle, võitleb iga teenusega, mis seda samuti hooldab, ja kaotaja on see, kes jookseb esimesena. Uuemad OpenVPN väljalasked saavad DNS-i sätted anda systemd-resolvedile, selle asemel et faili üle kirjutada, mis on koostöövaimuline käitumine, mida te soovite; vanemad skriptid ja käsitsi kirjutatud konksud kutsuvad sageli vananenud abiprogrammi või lihtsalt kirjutavad faili üle.

WireGuardi olukord on vormilt sarnane: liidese konfiguratsioon ise DNS-i ei halda, seda teevad selle ümber olevad tööriistad, resolveri abiprogrammi või resolved-integratsiooni kaudu. Kui kaks sellist abiprogrammi on paigaldatud, püüavad mõlemad ühendamisel kehtestada oma maailmapilti.

Lugege kliendi üles- ja allakonksusid, selle asemel et oletada. Paar rida shelli failis /etc/openvpn/up.sh või samaväärses kataloogis selgitavad käitumist, mis muidu tundub juhuslik, ja need on ka koht, kus saate kliendi panna koostööd tegema, mitte võistlema.

Kontroll 4: parandage seda omaniku juures, mitte failis

Kui teate omanikku, seadistage DNS selle omaniku toetatud liidese kaudu. systemd-resolvedi puhul tähendab see lingipõhiseid sätteid ja marsruutimisdomeene staatilise faili asemel; NetworkManageri puhul ühendusprofiili DNS-sätteid ja valitud backendit; resolvconf-integratsiooniga distributsiooni puhul selle abiprogrammi kaudu kirjutamist.

Ärge tehke faili muutumatuks. Muutumatuse atribuut peatab õiguspärased DHCP uuendused ja VPN-i värskendused koos nendega, mille vastu te võitlesite, ja jätab süsteemi olekusse, kus järgmine paketiuuendus või taasühendus tekitab tõrke, mida keegi konfiguratsiooni põhjal seletada ei oska. See varjab omandikonflikti, mis on täpselt see, mida te lahendada püüdsite.

Kus kaks komponenti peavad tõesti koos eksisteerima, andke neile erinevad tööd. Laske võrguhalduril omada liidesetasandi konfiguratsiooni, laske VPN-kliendil panustada lingipõhise DNS-i ja domeenidega sama integratsiooni kaudu ning eemaldage kolmas skript, mis kirjutab faili otse. systemd-resolvedi dokumentatsioon kirjeldab režiime, mida see toetab, ja mida igaüks neist failis /etc/resolv.conf näitab. Valige režiim, mis vastab sellele, kui palju poliitikat peate hoidma. Kui split-DNS on oluline, säilitab stub-korraldus lingipõhiste domeenidega selle, samas kui režiim, mis kopeerib upstream-serverid faili, lamedab selle vaikselt.

Kontrollige pärast taasühendust, mitte pärast muutmist

Fail, mis näeb vahetult pärast teie muudatust õige välja, ei tõesta midagi, sest järgmine sündmus pole veel toimunud. Käivitage jada, mis varem selle rikkus: laske tunnel alla ja üles, uuendage DHCP-liisingut või lülitage liidest, seejärel lugege samu väärtusi uuesti.

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

Seejärel kinnitage eristus, mis loeb: sisemine nimi laheneb sisemise serveri kaudu, samal ajal kui avalik nimi töötab endiselt. Konfiguratsioon, mis saadab kõik sisemisse serverisse, näeb hea välja seni, kuni keegi proovib tunnelist internetti jõuda, ja konfiguratsioon, mis saadab kõik avalikku, lekitab sisemisi nimesid.

Märkige omanik, backend ja sümbollingi režiim juurutamismärkmetesse. See üks lõik muudab tulevase paketiuuenduse intsidendist ülevaatamise punktiks ja takistab järgmisel inimesel sama konflikti käsuga chattr uuesti avastada.