Hvorfor /etc/hosts-oppføringen din ikke når VPN-ens DNS

Du la til et navn i /etc/hosts, koblet til VPN-en og forventet at oppføringen skulle dukke opp for alle. Det gjør den ikke, og overraskelsen kommer vanligvis med et andre symptom: navnet slår opp på maskinen din og feiler hos en kollega, noe som ser ut som en ødelagt VPN DNS-tjeneste og egentlig er hosts-filen som gjør nøyaktig det den ble laget for. En hosts-fil er lokal navneoppløsningskonfigurasjon, ikke en soneoppdatering, og ingenting i en vanlig VPN-tilkobling laster den opp.

Hosts er en lokal overstyring, ikke en soneoppdatering

Filen er en liste over tilordninger som navnetjenestebiblioteker konsulterer før, eller i stedet for, å spørre en DNS-server. En linje som 10.40.0.20 build.corp.example endrer hva applikasjoner på den ene maskinen konkluderer. Den oppretter ikke en oppføring, den reiser ikke gjennom tunnelen, og DNS-serveren tunnelen peker på, aner ikke at den finnes.

Derfor er feilen asymmetrisk. Klienten din får et svar fra filen. En annen klient spør VPN DNS-serveren, som ikke returnerer noe, og applikasjonen rapporterer at navnet ikke finnes. Begge maskinene oppfører seg riktig; bare én av dem har en overstyring den andre aldri har sett.

To kommandoer, to forskjellige komponenter

Den raskeste måten å stoppe diskusjonen på er å gjøre forskjellen synlig i to kommandoer, begge kjørt på klienten som har hosts-oppføringen:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Den første spør systemets egen oppslagsvei, som på et typisk glibc-system leser lokale filer før DNS. Den andre sender en DNS-spørring direkte til serveren på den adressen og konsulterer ikke lokale filer i det hele tatt. Når den første returnerer oppføringen din og den andre returnerer NXDOMAIN, har du bevist at oppføringen ikke finnes i DNS, og at maskinen din svarer fra en lokal overstyring.

Rekkefølgen kan konfigureres, og det er verdt å sjekke den før du konkluderer noe om en bestemt distribusjon. Se på hosts:-linjen i /etc/nsswitch.conf; hosts: files dns konsulterer filer først. Ikke kopier det eksempelet over en fungerende konfigurasjon bare for å endre rekkefølgen, fordi ekte systemer ofte lister opp flere kilder og betingede tjenesteoppføringer som eksempelet ikke inneholder.

systemd-resolved slører testen

På et system som bruker systemd-resolved, betjener den lokale stubben også navn fra hosts-databasen. Derfor er en spørring til 127.0.0.53 ikke en uavhengig test av fjernserveren, selv om den ser ut som og oppfører seg som en DNS-spørring. Du kan bekrefte hva resolveren vet og hvilke servere den ville spurt med:

resolvectl query build.corp.example
resolvectl status

Statusutdataene navngir DNS-serverne per kobling, og det er slik du finner ut om VPN-koblingen i det hele tatt fikk en resolver. Det spørsmålet er atskilt fra hosts-oppføringen og er det som er verdt å stille når et privat navn feiler for alle brukere og ikke for én.

Applikasjoner kan legge til enda et lag. En nettleser med sin egen DNS-over-HTTPS-innstilling, en container med sin egen resolverkonfigurasjon eller et kjøretidsmiljø som bufrer oppslag i prosessens levetid kan hver svare annerledes enn systemet. Test applikasjonen du bryr deg om i stedet for å anta at én kommando beskriver hvert program på maskinen.

Hva som egentlig deler et navn gjennom VPN-en

Hvis et privat navn skal virke for alle, trenger det en eier som alles resolver kan nå. Det rene svaret er å publisere oppføringen i en administrert sone og gjøre den sonen oppløselig gjennom den tiltenkte VPN DNS-veien. Da har oppføringen én sannhetskilde, et revisjonsspor og en livssyklus, og ingen trenger å huske hvilken laptop som bærer en lokal overstyring.

Å distribuere hosts-filer er et legitimt alternativ, og det er endepunktadministrasjon snarere enn navnetjeneste. Hvis du velger det, må filen rulles ut, versjoneres og fjernes av det som administrerer flåten, og det bør beskrives slik i designet. «VPN-en tar seg av det» er ikke en beskrivelse av den prosessen.

Dynamisk DNS-registrering er en tredje mekanisme, med egne tillatelser, oppdateringsautentisering og oppføringens levetid. Den følger ikke av en hosts-oppføring, og den følger heller ikke av at en klient bare kobler til, med mindre serveren og klienten begge er konfigurert for det. En oppføring som dukker opp av seg selv, er et signal om at noen har aktivert sikre oppdateringer og en klient som registrerer seg selv, og den konfigurasjonen hører hjemme i designoppføringen og ikke i en feilsøkingstråd. Hvis ingen kan navngi hvem som eier den innstillingen, behandle den automatiske oppføringen som uverifisert og hold den administrerte sonen som sannhetskilde.

Et oppslått navn er ikke en rute

Navneoppløsning og tilgjengelighet er atskilt, og en utdatert lokal tilordning er den klassiske måten å forveksle dem. En hosts-oppføring som peker på en adresse som har flyttet, vil fortsette å velge den utdaterte verten lenge etter at DNS er rettet, og symptomet ser ut som en rutingfeil på et navn som slår opp fint.

Så når rapporten er «navnet slår opp, men tjenesten er ikke tilgjengelig», sammenlign systemoppslaget med en eksplisitt spørring til VPN DNS-serveren, og sjekk deretter adressen du fikk mot den tjenesten faktisk bruker. systemd-resolved-referansen dokumenterer de lokale kildene den konsulterer, og det er kartet du trenger for den sammenligningen.

Rett deretter overstyringen gjennom eieren. Å fjerne en linje fra din egen hosts-fil gjør ingenting for de tolv laptopene som fikk samme linje fra et distribusjonsskript, og det er den versjonen av dette problemet folk faktisk har.