Hvers vegna resolv.conf sýnir DNS VPN-þíns en uppflettingar hunsa það

Ekkert í annálunum virðist rangt: tengið er uppi, leysirinn tilkynnir DNS-miðlara VPN-þíns og skráin á disknum telur hann upp. Samt leysist innra hýsinna enn um staðbundna beininn. Þessar þrjár fullyrðingar stangast ekki á, því skráin, ástand hverrar tengingar og slóð uppflettingar eru ólíkir hlutir sem deila tilviljunarkenndu nafni. Hér á eftir kemur slóðin sem fyrirspurn fer í raun á vél með systemd-resolved.

Þrír hlutir sem heita resolv.conf

Á vél með resolved er /etc/resolv.conf venjulega táknræn hlekkur á /run/systemd/resolve/stub-resolv.conf. Sá áfangastaður geymir vistfang staðbundins stub-hlustara, 127.0.0.53, auk leitarlénanna sem resolved reiknaði. Þetta er sýn á ástandið, ekki ástandið sjálft.

Ástandið býr í stillingum resolved fyrir hverja tengingu, og þess vegna getur resolvectl status stangast á við skrána og samt haft rétt fyrir sér. Hver tenging ber eigin miðlara og eigin leiðarlén, og stub-hlustarinninn leitar ráða í þeim gögnum þegar fyrirspurn berst. Handbók systemd-resolved lýsir mynduðu skránum og líkaninu fyrir hverja tengingu; aðskilnaður sýnar og ástands er sá hluti sem vert er að muna. Að breyta áfangastað táknræna hlekksins breytir því sem hefðbundnir biðlarar lesa, ekki því sem leysirinn veit.

Þriðji hluturinn, /run/systemd/resolve/resolv.conf, fletir hverja tengingu í einn miðlaralista. Forrit sem beint er að þeirri skrá sendir fyrirspurnir beint á skráðu miðlarana og sleppir stub-hlustaranum, svo stefna hverrar tengingar gildir ekki lengur um það. Þess vegna geta tvö forrit á sömu vél svarað sama nafni á ólíkan hátt, og hvort tveggja er heilt.

Fylgdu einni uppflettingu gegnum NSS

glibc les /etc/nsswitch.conf til að ákveða hver svarar nafni. hosts-lína sem inniheldur resolve beinir spurningunni til nss-resolve, sem spyr resolved um D-Bus og fær svarið fyrir tenginguna. Lína með aðeins files dns sendir fyrirspurnina á það vistfang sem /etc/resolv.conf geymir.

Þessi eina lína útskýrir flest ágreiningsefni milli vafra og dig. dig les resolv.conf beint og snertir NSS aldrei, svo það prófar stub-hlustarann eða miðlara ofar í stað slóðarinnar sem forritið notar. getent hosts internal.example fer gegnum NSS, og að bera svar þess saman við svar dig er fyrsta gagnlega mælingin.

Forrit sem hafa eigin leysi með í för, eða tala DNS yfir HTTPS við fastan endapunkt, fara fram hjá báðum slóðum. Ekkert í resolv.conf eða í ástandi resolved takmarkar þau.

Athugaðu hver á skrána og hvert hún vísar

Lestu hlekkjaröðina áður en þú breytir nokkru, því eigur ráða hvaða skrá er réttmæt. Hver skipun hér að neðan les aðeins ástand.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Fyrsta línan prentar hlekkinn og áfangastað hans saman, og venjuleg skrá í eigu VPN-skripts þýðir að leysirinn meðhöndlar þá skrif aldrei sem inntak. Staðaúttakið telur upp miðlara fyrir hverja tengingu auk leiðarlénanna sem ráða hvert hver fyrirspurn fer. nsswitch-línan segir hvort stub-hlustarinninn sé yfirhöfuð hafður til ráða, svo stub-vistfang í skránni án resolve þar þýðir að fyrirspurnir ná til staðbundins hlustara meðan ekkert stýrir skiptingunni. Síðasti listinn skiptir líka máli, því vél án stub-resolv.conf keyrir ekki fyrirkomulagið sem lýst er hér.

Ef röðin endar á skrá sem önnur pakki stýrir, eru VPN-biðlarinn og sá pakki þeir tveir eigendur sem þarf að samræma. Að skipta um hlekk kastar vinnu annars eigandans og lætur vinnu hins standa.

Gerðu við hjá eiganda hlekksins

VPN-tenging ætti að skrá miðlara sína og lén sín á eigin tengingu og draga þau svo til baka við aftengingu. resolved-samþætting NetworkManager og eigin hjálpari biðlarans virka bæði þannig; skript sem bara endurskrifar resolv.conf gerir það ekki.

Á tengingu sem þegar er til sýna keyrslustillingar kerfið. resolvectl dns tun0 10.40.0.53 tengir miðlara, og resolvectl domain tun0 '~corp.example' tengir leiðarlén. Tildað er burðarstafurinn: það takmarkar fyrirspurnir fyrir þá viðskeyti við þessa tengingu og lætur allt annað í friði, á meðan sama gildi án þess verður leitarlén og skiptingin gufar upp. Þessi vistföng eru rannsóknardæmi, ekki varanleg stilling. Staðfestu með resolvectl query host.corp.example og lestu hvaða tenging svaraði.

Skráður miðlari þarf samt leið. Þegar fyrirspurnin nær réttri tengingu og rennur út á tíma er gallinn í aðgengi gegnum göngin en ekki í eign leysisins.

Hvernig vinnandi ástand lítur út

Heilbrigð niðurstaða er samkvæm í öllum þremur sýnum: miðlarar hverrar tengingar passa við það sem VPN-ið úthlutaði, leiðarlénin ná aðeins yfir innri viðskeyti, og forritið sem skiptir máli leysir innra nafn á meðan opinbert nafn fylgir enn staðbundinni slóð. Ein farsæl fyrirspurn sannar minna en sú samsvörun.

Aftengdu svo og endurtaktu báðar fyrirspurnirnar. Biðlari sem lætur lénin sín vera skráð eftir niðurrif framleiðir vél sem bregst við innri uppflettingum klukkustundum síðar, án opinnar göngu og án augljósrar orsakar.