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

Intet i logfilerne ser forkert ud: grænsefladen er oppe, resolvers rapporterer VPN'ens DNS-server, og filen på disken lister den. Alligevel slås et internt værtsnavn stadig op via den lokale router. De tre udsagn modsiger ikke hinanden, fordi filen, tilstanden per link og opslagsvejen er forskellige objekter, der tilfældigvis deler et navn. Det følgende er den vej, en forespørgsel faktisk tager på en vært med systemd-resolved.

Tre objekter kaldet resolv.conf

På en vært med resolved er /etc/resolv.conf normalt et symbolsk link til /run/systemd/resolve/stub-resolv.conf. Det mål indeholder adressen på en lokal stub-lytter, 127.0.0.53, plus de søgedomæner, resolved har beregnet. Det er en visning af tilstanden, ikke tilstanden selv.

Tilstanden lever i resolveds konfiguration per link, og derfor kan resolvectl status være uenig med filen og stadig have ret. Et link bærer sine egne servere og sine egne routingdomæner, og stubben konsulterer disse data, når en forespørgsel ankommer. Manualen for systemd-resolved beskriver de genererede filer og modellen per link; opdelingen mellem visning og tilstand er den del, der er værd at huske. At ændre det symbolske links mål ændrer, hvad traditionelle klienter læser, ikke hvad resolvers ved.

Et tredje objekt, /run/systemd/resolve/resolv.conf, flader hvert link ud til én serverliste. Et program, der peger på den fil, sender forespørgsler direkte til de listede servere og springer stubben over, så politik per link gælder ikke længere for det. To programmer på samme maskine kan derfor svare forskelligt på samme navn, og ingen af dem er i stykker.

Følg et opslag gennem NSS

glibc læser /etc/nsswitch.conf for at afgøre, hvem der svarer på et navn. En hosts-linje med resolve sender spørgsmålet til nss-resolve, som spørger resolved over D-Bus og får svaret per link. En linje med kun files dns sender forespørgslen til den adresse, /etc/resolv.conf holder.

Den ene linje forklarer de fleste uenigheder mellem en browser og dig. dig læser resolv.conf direkte og rører aldrig NSS, så den tester stubben eller en opstrøms server i stedet for den vej, programmet bruger. getent hosts internal.example går gennem NSS, og at sammenligne dens svar med dig's er den første brugbare måling.

Programmer, der har deres egen resolver indbygget, eller taler DNS over HTTPS med et fast endepunkt, omgår begge veje. Intet i resolv.conf eller i resolved-tilstanden begrænser dem.

Tjek, hvem der ejer filen, og hvor den peger hen

Læs linkkæden, før du ændrer noget, fordi ejerskab afgør, hvilken fil der er autoritativ. Hver kommando nedenfor læser kun tilstand.

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

Den første linje udskriver linket og dets mål sammen, og en almindelig fil ejet af et VPN-script betyder, at resolvers aldrig behandler den skrivning som input. Statusoutputtet lister servere per link plus de routingdomæner, der afgør, hvor hver forespørgsel går hen. nsswitch-linjen siger, om stubben overhovedet konsulteres, så en stub-adresse i filen uden resolve der betyder, at forespørgsler når den lokale lytter, mens intet styrer opdelingen. Den sidste liste betyder også noget, fordi en vært uden stub-resolv.conf ikke kører den ordning, der beskrives her.

Hvis kæden ender i en fil, som en anden pakke styrer, er VPN-klienten og den pakke de to ejere, der skal forliges. At erstatte linket kasserer den ene ejers arbejde og lader den andens blive.

Ret ved linkets ejer

En VPN-forbindelse bør registrere sine servere og sine domæner på sit eget link og derefter trække dem tilbage ved afbrydelse. NetworkManagers resolved-integration og en klients egen hjælper fungerer begge sådan; et script, der kun omskriver resolv.conf, gør ikke.

På et link, der allerede findes, viser køretidsindstillingerne mekanismen. resolvectl dns tun0 10.40.0.53 knytter en server til, og resolvectl domain tun0 '~corp.example' knytter et routingdomæne til. Tilden er det bærende tegn: den begrænser forespørgsler for det suffiks til dette link og lader alt andet være, mens den samme værdi uden den bliver et søgedomæne, og opdelingen fordamper. De adresser er laboratorieeksempler, ikke en varig konfiguration. Bekræft med resolvectl query host.corp.example og læs, hvilket link der svarede.

En registreret server har stadig brug for en rute. Når forespørgslen når det rigtige link og løber tør for tid, ligger fejlen i nåbarhed gennem tunnelen og ikke i resolverens ejerskab.

Sådan ser en fungerende tilstand ud

Et sundt resultat er konsistent i alle tre visninger: serverne per link matcher det, VPN'en udleverede, routingdomænerne dækker kun interne suffikser, og det program, der betyder noget, slår et internt navn op, mens et offentligt navn stadig følger den lokale vej. Et vellykket opslag beviser mindre end den enighed.

Afbryd derefter forbindelsen, og gentag begge opslag. En klient, der lader sine domæner være registreret efter nedrivningen, giver en maskine, der fejler på interne opslag timer senere, uden åben tunnel og uden nogen oplagt årsag.