Hvorfor resolv.conf viser VPN-DNS-en din, men oppslag ignorerer den

Ingenting i loggene ser galt ut: grensesnittet er oppe, resolvers rapporterer VPN-ens DNS-server, og filen på disken lister den opp. Likevel slås et internt vertsnavn fortsatt opp via den lokale ruteren. De tre utsagnene motsier ikke hverandre, fordi filen, tilstanden per lenke og oppslagsveien er forskjellige objekter som tilfeldigvis deler et navn. Det følgende er veien en spørring faktisk tar på en vert med systemd-resolved.

Tre objekter kalt resolv.conf

På en vert med resolved er /etc/resolv.conf vanligvis en symbolsk lenke til /run/systemd/resolve/stub-resolv.conf. Det målet inneholder adressen til en lokal stub-lytter, 127.0.0.53, pluss søkedomenene resolved har beregnet. Det er en visning av tilstanden, ikke tilstanden selv.

Tilstanden lever i resolveds konfigurasjon per lenke, og derfor kan resolvectl status være uenig med filen og fortsatt ha rett. Hver lenke bærer sine egne servere og sine egne rutingsdomener, og stubben konsulterer disse dataene når en spørring kommer inn. Håndboken for systemd-resolved beskriver de genererte filene og modellen per lenke; skillet mellom visning og tilstand er den delen som er verdt å huske. Å endre målet for den symbolske lenken endrer det tradisjonelle klienter leser, ikke det resolvers vet.

Et tredje objekt, /run/systemd/resolve/resolv.conf, flater ut hver lenke til én serverliste. Et program som peker på den filen, sender spørringer rett til de oppførte serverne og hopper over stubben, så policyen per lenke gjelder ikke lenger for det. To programmer på samme maskin kan derfor svare forskjellig på samme navn, og ingen av dem er ødelagt.

Følg ett oppslag gjennom NSS

glibc leser /etc/nsswitch.conf for å avgjøre hvem som svarer på et navn. En hosts-linje med resolve sender spørsmålet til nss-resolve, som spør resolved over D-Bus og får svaret per lenke. En linje med bare files dns sender spørringen til adressen /etc/resolv.conf holder.

Den ene linjen forklarer de fleste uenighetene mellom en nettleser og dig. dig leser resolv.conf direkte og berører aldri NSS, så den tester stubben eller en oppstrøms server i stedet for veien programmet bruker. getent hosts internal.example går gjennom NSS, og å sammenligne svaret med dig sitt er den første nyttige målingen.

Programmer som har sin egen resolver innebygd, eller snakker DNS over HTTPS med et fast endepunkt, omgår begge veiene. Ingenting i resolv.conf eller i resolved-tilstanden begrenser dem.

Sjekk hvem som eier filen, og hvor den peker

Les lenkekjeden før du endrer noe, fordi eierskap avgjør hvilken fil som er autoritativ. Hver kommando nedenfor leser bare tilstand.

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

Den første linjen skriver ut lenken og målet sammen, og en vanlig fil eid av et VPN-skript betyr at resolvers aldri behandler den skrivingen som input. Statusutdataene lister servere per lenke pluss rutingsdomenene som avgjør hvor hver spørring går. nsswitch-linjen sier om stubben i det hele tatt konsulteres, så en stub-adresse i filen uten resolve der betyr at spørringene når den lokale lytteren mens ingenting styrer delingen. Den siste listen betyr også noe, fordi en vert uten stub-resolv.conf ikke kjører ordningen som beskrives her.

Hvis kjeden ender i en fil som en annen pakke styrer, er VPN-klienten og den pakken de to eierne som må forenes. Å erstatte lenken kaster den ene eierens arbeid og lar den andres bli stående.

Reparer hos lenkens eier

En VPN-tilkobling bør registrere serverne og domenene sine på sin egen lenke, og deretter trekke dem tilbake ved frakobling. NetworkManagers resolved-integrasjon og en klients egen hjelper fungerer begge slik; et skript som bare skriver om resolv.conf, gjør det ikke.

På en lenke som allerede finnes, viser kjøretidsinnstillingene mekanismen. resolvectl dns tun0 10.40.0.53 knytter til en server, og resolvectl domain tun0 '~corp.example' knytter til et rutingsdomene. Tilden er det bærende tegnet: den begrenser spørringer for det suffikset til denne lenken og lar alt annet være, mens samme verdi uten den blir et søkedomene og delingen fordamper. Adressene er laboratorieeksempler, ikke en varig konfigurasjon. Bekreft med resolvectl query host.corp.example og les hvilken lenke som svarte.

En registrert server trenger fortsatt en rute. Når spørringen når riktig lenke og går ut på tid, ligger feilen i tilgjengelighet gjennom tunnelen og ikke i resolverens eierskap.

Hvordan en fungerende tilstand ser ut

Et sunt resultat er konsistent i alle tre visningene: serverne per lenke samsvarer med det VPN-en delte ut, rutingsdomenene dekker bare interne suffikser, og programmet som betyr noe, slår opp et internt navn mens et offentlig navn fortsatt følger den lokale veien. Ett vellykket oppslag beviser mindre enn den enigheten.

Koble deretter fra og gjenta begge oppslagene. En klient som lar domenene sine være registrert etter nedrivingen, gir en maskin som feiler på interne oppslag timer senere, uten åpen tunnel og uten åpenbar årsak.