Kvifor resolv.conf viser VPN-DNS-en din, men oppslag ignorerer han

Ingenting i loggane ser gale ut: grensesnittet er oppe, resolvers rapporterer DNS-tenaren til VPN-en, og fila på disken listar han opp. Likevel blir eit internt vertsnamn framleis slått opp via den lokale rutaren. Dei tre utsegnene motseler ikkje kvarandre, fordi fila, tilstanden per lenkje og oppslagsvegen er ulike objekt som tilfeldigvis deler eit namn. Det følgjande er vegen ein spørjing faktisk tek på ein vert med systemd-resolved.

Tre objekt kalla resolv.conf

På ein vert med resolved er /etc/resolv.conf vanlegvis ei symbolsk lenkje til /run/systemd/resolve/stub-resolv.conf. Det målet inneheld adressa til ein lokal stub-lyttar, 127.0.0.53, pluss søkjedomenane resolved har rekna ut. Det er ei vising av tilstanden, ikkje tilstanden sjølv.

Tilstanden bur i konfigurasjonen til resolved per lenkje, og difor kan resolvectl status vere usamd med fila og framleis ha rett. Kvar lenkje ber sine eigne tenarar og sine eigne rutingsdomene, og stubben konsulterer desse dataa når ei spørjing kjem inn. Handboka for systemd-resolved skildrar dei genererte filene og modellen per lenkje; skiljet mellom vising og tilstand er den delen som er verdt å hugse. Å endre målet for den symbolske lenkja endrar det tradisjonelle klientar les, ikkje det resolvers veit.

Eit tredje objekt, /run/systemd/resolve/resolv.conf, flatar ut kvar lenkje til éi tenarliste. Eit program som peikar på den fila, sender spørjingar rett til tenarane som er oppførte og hoppar over stubben, så policyen per lenkje gjeld ikkje lenger for det. To program på same maskin kan difor svare ulikt på same namn, og ingen av dei er øydelagde.

Følg eitt oppslag gjennom NSS

glibc les /etc/nsswitch.conf for å avgjere kven som svarar på eit namn. Ei hosts-linje med resolve sender spørsmålet til nss-resolve, som spør resolved over D-Bus og får svaret per lenkje. Ei linje med berre files dns sender spørjinga til adressa /etc/resolv.conf held.

Den eine linja forklarar dei fleste usemjene mellom ein nettlesar og dig. dig les resolv.conf direkte og rører aldri NSS, så han testar stubben eller ein oppstraums tenar i staden for vegen programmet brukar. getent hosts internal.example går gjennom NSS, og å samanlikne svaret med dig sitt er den første nyttige målinga.

Program som har sin eigen resolver innebygd, eller snakkar DNS over HTTPS med eit fast endepunkt, går utanom begge vegane. Ingenting i resolv.conf eller i resolved-tilstanden avgrensar dei.

Sjekk kven som eig fila, og kvar ho peikar

Les lenkjekjeda før du endrar noko, fordi eigarskap avgjer kva fil som er autoritativ. Kvar kommando nedanfor les berre tilstand.

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

Den første linja skriv ut lenkja og målet saman, og ei vanleg fil eigd av eit VPN-skript betyr at resolvers aldri behandlar den skrivinga som inn-data. Statusutdata listar tenarar per lenkje pluss rutingsdomena som avgjer kvar kvar spørjing går. nsswitch-linja seier om stubben i det heile blir konsultert, så ei stub-adresse i fila utan resolve der betyr at spørjingane når den lokale lyttaren medan ingenting styrer delinga. Den siste lista betyr òg noko, fordi ein vert utan stub-resolv.conf ikkje køyrer ordninga som er skildra her.

Viss kjeda endar i ei fil som ein annan pakke styrer, er VPN-klienten og den pakken dei to eigarane som må forsonast. Å erstatte lenkja kastar arbeidet til den eine eigaren og lèt det til den andre bli ståande.

Reparer hos eigaren av lenkja

Ei VPN-tilkopling bør registrere tenarane og domena sine på si eiga lenkje, og deretter trekkje dei tilbake ved fråkopling. resolved-integreringen til NetworkManager og eigen hjelpar hjå ein klient fungerer begge slik; eit skript som berre skriv om resolv.conf, gjer det ikkje.

På ei lenkje som alt finst, viser køyretidsinnstillingane mekanismen. resolvectl dns tun0 10.40.0.53 knyter til ein tenar, og resolvectl domain tun0 '~corp.example' knyter til eit rutingsdomene. Tilden er det berande teiknet: han avgrensar spørjingar for det suffikset til denne lenkja og lèt alt anna vere, medan same verdi utan han blir eit søkjedomene og delinga fordampar. Adressene er laboratoriedøme, ikkje ein varig konfigurasjon. Stadfest med resolvectl query host.corp.example og les kva lenkje som svara.

Ein registrert tenar treng framleis ei rute. Når spørjinga når rett lenkje og går ut på tid, ligg feilen i tilgjenge gjennom tunnelen og ikkje i eigarskapen til resolvers.

Korleis ein fungerande tilstand ser ut

Eit sunt resultat er konsistent i alle tre visingane: tenarane per lenkje svarar til det VPN-en delte ut, rutingsdomena dekkjer berre interne suffiks, og programmet som betyr noko, slår opp eit internt namn medan eit offentleg namn framleis følgjer den lokale vegen. Eitt vellukka oppslag bevisar mindre enn den semja.

Kopla deretter frå og gjenta begge oppslaga. Ein klient som lèt domena sine bli registrerte etter nedrivinga, gir ei maskin som feilar på interne oppslag timar seinare, utan open tunnel og utan openberr årsak.