Pysäytä kahden Linux-palvelun kilpailu /etc/resolv.confista

DNS palaa jatkuvasti takaisin, VPN:n uudelleenyhdistäminen kumoaa korjauksesi, ja lopulta joku tiimissä ehdottaa tiedoston lukitsemista. Tämä sarja on oire, ei ratkaisu: kaksi komponenttia uskoo kumpikin omistavansa /etc/resolv.conf, ja viimeiseksi kirjoittava voittaa. Tiedoston lukitseminen ei ratkaise omistusristiriitaa, se vain piilottaa sen ja rikkoo samalla komponentin, jota todella halusit. Käy alla olevat neljä tarkistusta läpi järjestyksessä ja korjaa järjestely sillä tasolla, joka sen omistaa, ei tiedostossa.

Tarkistus 1: onko se symbolinen linkki, ja mihin

Aloita itse tiedostosta, sillä muokkaamasi polku ei ehkä ole tiedosto lainkaan. Symbolinen linkki resolverin ajonaikaiseen hakemistoon käyttäytyy täysin eri tavalla kuin tavallinen tiedosto, jonka asiakasskripti kirjoittaa uudelleen:

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

Linkki systemd-resolvedin stub-polkuun tarkoittaa, että tiedoston sisältö luodaan, ja käsin tehty muokkaus korvataan seuraavassa tapahtumassa. Tavallisen nameserver-rivejä sisältävän tiedoston kirjoittaa yleensä se asiakas tai DHCP-koukku, joka ajetaan yhdistettäessä. Molemmat ovat laillisia; tärkeää on tietää, kumpi sinulla on, ennen kuin muutat mitään.

Tarkistus 2: mikä daemon on käynnissä

Selvitä, mikä on todella aktiivinen, ei mikä on asennettu. Nykyaikaisessa jakelussa voi olla useita resolvereita, ja vastaaja on se, joka pitää porttia 53 loopback-rajapinnalla:

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

Tilatuloste nimeää linkkikohtaiset DNS-palvelimet ja reititysverkkotunnukset, ja se on kartta, jonka tarvitset split DNS:ää varten. Jos sisäiset nimet on vietävä sisäiselle palvelimelle ja kaikki muu julkiselle, tämä käytäntö elää linkkikohtaisissa verkkotunnuksissa, ja sen litistäminen tiedoston staattiseksi nameserver-luetteloksi kadottaa eron hiljaisesti.

NetworkManagerin oma kokoonpano päättää, mitä näistä backendeista se käyttää. Sen dns=-asetus pääkokoonpanotiedostossa valitsee sen sisäisen resolverin, dnsmasqin, systemd-resolvedin ja nonen välillä, ja jakelu on ehkä valinnut puolestasi. Lue tämä asetus ennen kuin päätät, mitä “DNS:n korjaaminen” tällä isännällä tarkoittaa.

Tarkistus 3: mitä VPN-asiakas saa kirjoittaa

Tässä ristiriita yleensä elää. VPN-asiakas, joka kirjoittaa resolveritiedoston suoraan uudelleen, taistelee jokaista palvelua vastaan, joka myös ylläpitää sitä, ja häviäjä on se, joka ajetaan ensin. Uudemmat OpenVPN-julkaisut voivat luovuttaa DNS-asetukset systemd-resolvedille sen sijaan, että kirjoittaisivat tiedoston uudelleen, mikä on se yhteistyöhaluinen käytös, jota haluat; vanhemmat skriptit ja käsin kirjoitetut koukut kutsuvat usein vanhentunutta apuohjelmaa tai yksinkertaisesti ylikirjoittavat tiedoston.

WireGuardin tilanne on muodoltaan samanlainen: rajapinnan kokoonpano ei itse hallitse DNS:ää, sen tekevät sen ympärillä olevat työkalut, resolveriapurin tai resolved-integraation kautta. Jos kaksi tällaista apuria on asennettu, molemmat yrittävät soveltaa maailmankuvaansa yhdistettäessä.

Lue asiakkaan up- ja down-koukut sen sijaan, että arvaisit. Muutama rivi shelliä tiedostossa /etc/openvpn/up.sh tai vastaavassa hakemistossa selittää käytöksen, joka muuten näyttää satunnaiselta, ja ne ovat myös paikka, jossa voit saada asiakkaan tekemään yhteistyötä kilpailemisen sijaan.

Tarkistus 4: korjaa se omistajan luona, ei tiedostossa

Kun tiedät omistajan, määritä DNS kyseisen omistajan tukeman rajapinnan kautta. systemd-resolvedille se tarkoittaa linkkikohtaisia asetuksia ja reititysverkkotunnuksia staattisen tiedoston sijaan; NetworkManagerille se tarkoittaa yhteysprofiilin DNS-asetuksia ja valittua backendia; resolvconf-integraatiota käyttävälle jakelulle se tarkoittaa kirjoittamista kyseisen apurin kautta.

Älä tee tiedostosta muuttumatonta. Muuttumattomuusattribuutti pysäyttää lailliset DHCP-uudistukset ja VPN-päivitykset yhdessä niiden kanssa, joita vastaan taistelit, ja jättää järjestelmän tilaan, jossa seuraava pakettipäivitys tai uudelleenyhdistäminen tuottaa vian, jota kukaan ei voi selittää kokoonpanosta. Se kätkee omistusristiriidan, joka on juuri se asia, jota yritit ratkaista.

Kun kahden komponentin todella on elettävä rinnakkain, anna niille eri työt. Anna verkkohallinnan omistaa rajapintatason kokoonpano, anna VPN-asiakkaan tuoda linkkikohtainen DNS ja verkkotunnukset saman integraation kautta, ja poista kolmas skripti, joka kirjoittaa tiedoston suoraan. systemd-resolvedin dokumentaatio kertoo sen tukemat tilat ja mitä kukin niistä näyttää tiedostossa /etc/resolv.conf. Valitse tila, joka vastaa sitä, kuinka paljon käytäntöä sinun on säilytettävä. Jos split DNS on tärkeä, stub-järjestely linkkikohtaisine verkkotunnuksineen säilyttää sen, kun taas tila, joka kopioi ylävirran palvelimet tiedostoon, litistää sen hiljaisesti.

Varmista uudelleenyhdistämisen jälkeen, ei muokkauksen jälkeen

Tiedosto, joka näyttää oikealta heti muutoksesi jälkeen, ei todista mitään, koska seuraava tapahtuma ei ole vielä tapahtunut. Käynnistä sarja, joka ennen rikkoi sen: laske tunneli alas ja ylös, uudista DHCP-vuokra tai vaihda rajapintaa, ja lue sitten samat arvot uudelleen.

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

Vahvista sitten ero, jolla on merkitystä: sisäinen nimi ratkeaa sisäisen palvelimen kautta, kun taas julkinen nimi toimii edelleen. Kokoonpano, joka lähettää kaiken sisäiselle palvelimelle, näyttää hyvältä, kunnes joku yrittää päästä internetiin tunnelin kautta, ja kokoonpano, joka lähettää kaiken julkiselle, vuotaa sisäisiä nimiä.

Kirjaa omistaja, backend ja symbolisen linkin tila käyttöönoton muistiinpanoihin. Se yksi kappale muuttaa tulevan pakettipäivityksen tapauksesta tarkistuskohdaksi, ja se estää seuraavaa henkilöä löytämästä samaa ristiriitaa uudelleen chattr-komennolla.