Stöðvið tvær Linux-þjónustur sem keppa um /etc/resolv.conf

DNS fer sífellt aftur í fyrra horf, endurtenging VPN afturkallar viðgerðina þína, og að lokum stingur einhver í teyminu upp á að læsa skránni. Sú röð er einkenni, ekki lausn: tvær einingar telja báðar að þær eigi /etc/resolv.conf, og sá sem skrifar síðastur vinnur. Að læsa skránni leysir ekki eignarhaldsátökin, það felur þau aðeins og brýtur á sama tíma eininguna sem þú vildir í raun. Farðu í gegnum fjórar prófanirnar hér að neðan í röð og lagaðu fyrirkomulagið á því stigi sem á það, ekki á skránni.

Prófun 1: er þetta táknræn tenging, og hvert

Byrjaðu á skránni sjálfri, því slóðin sem þú breytir er kannski alls ekki skráin. Táknræn tenging í keyrslumöppu leysanda hegðar sér gjörólíkt venjulegri skrá sem biðlaraforrit skrifar yfir:

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

Tenging á stub-slóð systemd-resolved þýðir að innihald skrárinnar er búið til, og handvirk breyting verður yfirskrifuð við næsta atburð. Venjulega skrá með nameserver-línum skrifar venjulega sá biðlari eða DHCP-krókur sem keyrir við tengingu. Bæði eru lögmæt; það sem skiptir máli er að vita hvor þú hefur áður en þú breytir einhverju.

Prófun 2: hvaða daemon keyrir

Finndu út hvað er í raun virkt, ekki hvað er uppsett. Á nútíma dreifingu geta verið nokkrir leysendur, og sá sem heldur porti 53 á loopback-tenginu svarar:

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

Stöðuúttakið nefnir DNS-þjónana á hverri tengingu og leiðarstengur, og það er kortið sem þú þarft fyrir split DNS. Ef innri nöfn verða að fara á innri þjón og allt annað á almennan, býr sú stefna í lénunum á hverri tengingu, og að slétta hana í fastan nameserver-lista í skránni tapar þeim greinarmun hljóðlega.

Eigin stilling NetworkManager ræður því hvaða bakenda hann notar. Stillingin dns= í aðalstillingaskránni velur á milli innri leysanda hans, dnsmasq, systemd-resolved og none, og dreifingin kann að hafa valið fyrir þig. Lestu þá stillingu áður en þú ákveður hvað “að laga DNS” þýðir á þessum vélbúnaði.

Prófun 3: hvað VPN-biðlarinn má skrifa

Hér býr átökin venjulega. VPN-biðlari sem skrifar yfir leysandaskrána beint mun berjast við hverja þjónustu sem einnig viðheldur henni, og sá tapar sem keyrir fyrst. Nýjustu útgáfur af OpenVPN geta afhent systemd-resolved DNS-stillingarnar í stað þess að skrifa yfir skrána, sem er sú samvinnuhegðun sem þú vilt; eldri skriptur og handskrifaðir krókar kalla oft á úrelt hjálpartæki eða skrifa einfaldlega yfir skrána.

Staða WireGuard er svipuð að formi: tengistillingin sjálf stýrir ekki DNS, tólin í kringum hana gera það, í gegnum leysandahjálpara eða resolved-samþættingu. Ef tveir slíkir hjálparar eru uppsettir munu báðir reyna að láta heimsmynd sína gilda við tengingu.

Lestu upp- og niður-króka biðlarans í stað þess að giska. Nokkrar línur af shell í /etc/openvpn/up.sh eða sambærilegri möppu útskýra hegðun sem virðist ella tilviljunarkennd, og þar er einnig hægt að fá biðlarann til að vinna saman í stað þess að keppa.

Prófun 4: lagaðu það hjá eigandanum, ekki í skránni

Þegar þú þekkir eigandann skaltu stilla DNS í gegnum studda viðmótið hans. Fyrir systemd-resolved þýðir það stillingar á hverri tengingu og leiðarstengur í stað fastrar skrár; fyrir NetworkManager þýðir það DNS-stillingar tengisniðsins og valinn bakenda; fyrir dreifingu með resolvconf-samþættingu þýðir það að skrifa í gegnum þann hjálpara.

Ekki gera skrána óbreytanlega. Óbreytanleikaeiginleikinn stöðvar lögmætar DHCP-endurnýjanir og VPN-uppfærslur ásamt þeim sem þú barðist við, og skilur kerfið eftir í ástandi þar sem næsta pakkauppfærsla eða endurtenging veldur bilun sem enginn getur útskýrt út frá stillingunni. Hann felur eignarhaldsátökin, sem eru einmitt það sem þú varst að reyna að leysa.

Þar sem tvær einingar verða virkilega að vera saman skaltu gefa þeim ólík störf. Láttu netstjórann eiga stillingu á tengistigi, láttu VPN-biðlarann leggja til DNS og lén á hverri tengingu í gegnum sömu samþættingu, og fjarlægðu þriðju skriptuna sem skrifar skrána beint. Skjöl systemd-resolved útlista þá ham sem hann styður og hvað hver þeirra sýnir í /etc/resolv.conf. Veldu þann ham sem passar við hversu mikilli stefnu þú þarft að halda. Ef split DNS skiptir máli varðveitir stub-fyrirkomulagið með lénum á hverri tengingu það, en hamurinn sem afritar yfirþjóna í skrána sléttir það hljóðlega út.

Staðfestu eftir endurtengingu, ekki eftir breytinguna

Skrá sem virðist rétt strax eftir breytinguna þína sannar ekkert, því næsti atburður hefur ekki átt sér stað enn. Kveiktu á röðinni sem áður braut hana: taktu tunnilinn niður og upp, endurnýjaðu DHCP-leiguna eða skiptu um tengið, og lestu svo sömu gildin aftur.

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

Staðfestu síðan þann greinarmun sem skiptir máli: innra nafnið leysist í gegnum innri þjóninn á meðan almenna nafnið virkar enn. Stilling sem sendir allt á innri þjóninn virðist góð þar til einhver reynir að ná internetinu í gegnum tunnilinn, og stilling sem sendir allt á þann almennu lekur innri nöfnum.

Skráðu eigandann, bakendann og táknrænu tengingarhaminn í dreifingaskýringarnar. Sú eina málsgrein breytir framtíðar pakkauppfærslu úr atviki í yfirferðaratriði, og kemur í veg fyrir að næsta manneskja enduruppgötvi sömu átök með chattr skipun.