Kvifor /etc/hosts-oppføringa di ikkje når DNS-en til VPN-en

Du la til eit namn i /etc/hosts, kopla til VPN-en og venta at oppføringa skulle dukke opp for alle. Det gjer ho ikkje, og overraskinga kjem vanlegvis med eit andre symptom: namnet slår opp på maskina di og feilar hos ein kollega, noko som ser ut som ein øydelagd VPN DNS-teneste og eigentleg er hosts-fila som gjer nøyaktig det ho vart laga for. Ei hosts-fil er lokal namneoppløysingskonfigurasjon, ikkje ei soneoppdatering, og ingenting i ei vanleg VPN-tilkopling lastar ho opp.

Hosts er ei lokal overstyring, ikkje ei soneoppdatering

Fila er ei liste over tilordningar som namnetenestebibliotek konsulterer før, eller i staden for, å spørje ein DNS-server. Ei linje som 10.40.0.20 build.corp.example endrar kva applikasjonar på den eine maskina konkluderer. Ho opprettar ikkje ei oppføring, ho reiser ikkje gjennom tunnelen, og DNS-serveren tunnelen peikar på, anar ikkje at ho finst.

Difor er feilen asymmetrisk. Klienten din får eit svar frå fila. Ein annan klient spør VPN DNS-serveren, som ikkje returnerer noko, og applikasjonen rapporterer at namnet ikkje finst. Begge maskinene oppfører seg rett; berre éi av dei har ei overstyring den andre aldri har sett.

To kommandoar, to ulike komponentar

Den raskaste måten å stoppe diskusjonen på er å gjere skilnaden synleg i to kommandoar, begge køyrde på klienten som har hosts-oppføringa:

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

Den første spør den eigenlege oppslagsvegen til systemet, som på eit typisk glibc-system les lokale filer før DNS. Den andre sender ei DNS-førespurnad direkte til serveren på den adressa og konsulterer ikkje lokale filer i det heile. Når den første returnerer oppføringa di og den andre returnerer NXDOMAIN, har du prova at oppføringa ikkje finst i DNS, og at maskina di svarar frå ei lokal overstyring.

Rekkjefølgja kan konfigurerast, og det er verdt å sjekke ho før du konkluderer noko om ein bestemt distribusjon. Sjå på hosts:-linja i /etc/nsswitch.conf; hosts: files dns konsulterer filer først. Ikkje kopier det dømet over ein fungerande konfigurasjon berre for å endre rekkjefølgja, fordi ekte system ofte listar opp fleire kjelder og vilkårsbundne tenesteoppføringar som dømet ikkje inneheld.

systemd-resolved slører testen

På eit system som brukar systemd-resolved, tener den lokale stubben også namn frå hosts-databasen. Difor er ei førespurnad til 127.0.0.53 ikkje ein uavhengig test av fjernserveren, sjølv om ho ser ut som og oppfører seg som ei DNS-førespurnad. Du kan stadfeste kva resolveren veit og kva serverar han ville spørje med:

resolvectl query build.corp.example
resolvectl status

Statusutdataa namngir DNS-serverane per kopling, og det er slik du finn ut om VPN-koplinga i det heile fekk ein resolver. Det spørsmålet er skilt frå hosts-oppføringa og er det som er verdt å stille når eit privat namn feilar for alle brukarar og ikkje for éin.

Applikasjonar kan leggje til endå eit lag. Ein nettlesar med si eiga DNS-over-HTTPS-innstilling, ein container med sin eigen resolverkonfigurasjon eller eit køyretidsmiljø som bufar oppslag i levetida til prosessen kan kvar svare annleis enn systemet. Test applikasjonen du bryr deg om i staden for å anta at éin kommando skildrar kvart program på maskina.

Kva som eigentleg deler eit namn gjennom VPN-en

Viss eit privat namn skal verke for alle, treng det ein eigar som resolveren til alle kan nå. Det reine svaret er å publisere oppføringa i ei administrert sone og gjere den sona oppløyseleg gjennom den tiltenkte VPN DNS-vegen. Då har oppføringa éin sanningkjelde, eit revisjonsspor og ein livssyklus, og ingen treng å hugse kva laptop som ber ei lokal overstyring.

Å distribuere hosts-filer er eit legitimt alternativ, og det er endepunktadministrasjon snarare enn namneteneste. Viss du vel det, må fila rullast ut, versjonerast og fjernast av det som administrerer flåten, og det bør skildrast slik i designet. «VPN-en tek seg av det» er ikkje ei skildring av den prosessen.

Dynamisk DNS-registrering er ein tredje mekanisme, med eigne løyve, oppdateringsautentisering og levetid for oppføringa. Han følgjer ikkje av ei hosts-oppføring, og han følgjer heller ikkje av at ein klient berre koplar til, med mindre serveren og klienten begge er konfigurerte for det. Ei oppføring som dukkar opp av seg sjølv, er eit signal om at nokon har slått på trygge oppdateringar og ein klient som registrerer seg sjølv, og den konfigurasjonen høyrer heime i designoppføringa og ikkje i ein feilsøkingstråd. Viss ingen kan namngje kven som eig den innstillinga, handsam den automatiske oppføringa som uverifisert og hald den administrerte sona som sanningkjelde.

Eit oppslått namn er ikkje ei rute

Namneoppløysing og tilgjenge er skilt, og ei utdatert lokal tilordning er den klassiske måten å forveksle dei på. Ei hosts-oppføring som peikar på ei adresse som har flytta, vil halde fram med å velje den utdaterte verten lenge etter at DNS er retta, og symptomet ser ut som ein rutefeil på eit namn som slår opp fint.

Så når rapporten er «namnet slår opp, men tenesta er ikkje tilgjengeleg», samanlikn systemoppslaget med ei eksplisitt førespurnad til VPN DNS-serveren, og sjekk deretter adressa du fekk mot den tenesta faktisk brukar. systemd-resolved-referansen dokumenterer dei lokale kjeldene han konsulterer, og det er kartet du treng for den samanlikninga.

Rett deretter overstyringa gjennom eigaren. Å fjerne ei linje frå di eiga hosts-fil gjer ingenting for dei tolv laptopane som fekk same linje frå eit distribusjonsskript, og det er den versjonen av dette problemet folk faktisk har.