Hvorfor din /etc/hosts-post ikke når VPN’ens DNS

Du tilføjede et navn til /etc/hosts, oprettede VPN-forbindelsen og forventede, at posten ville dukke op for alle. Det gør den ikke, og overraskelsen kommer normalt med et andet symptom: navnet slår op på din maskine og fejler hos en kollega, hvilket ser ud som en ødelagt VPN DNS-tjeneste, men i virkeligheden gør hosts-filen præcis det, den blev designet til. En hosts-fil er lokal navneopløsningskonfiguration, ikke en zoneopdatering, og intet i en normal VPN-forbindelse uploader den.

Hosts er en lokal tilsidesættelse, ikke en zoneopdatering

Filen er en liste over tilknytninger, som navnetjenestebiblioteker konsulterer, før de spørger en DNS-server, eller i stedet for. En linje som 10.40.0.20 build.corp.example ændrer, hvad programmer på netop den maskine konkluderer. Den opretter ikke en post, den rejser ikke gennem tunnelen, og den DNS-server, tunnelen peger på, aner ikke, at den findes.

Derfor er fejlen asymmetrisk. Din klient får et svar fra filen. En anden klient spørger VPN DNS-serveren, som intet returnerer, og programmet rapporterer, at navnet ikke findes. Begge maskiner opfører sig korrekt; kun den ene har en tilsidesættelse, som den anden aldrig har set.

To kommandoer, to forskellige komponenter

Den hurtigste måde at stoppe diskussionen på er at gøre forskellen synlig i to kommandoer, begge kørt på den klient, der har hosts-posten:

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

Den første spørger systemets egen opslagsvej, som på et typisk glibc-system læser lokale filer før DNS. Den anden sender en DNS-forespørgsel direkte til serveren på den adresse og konsulterer slet ikke lokale filer. Når den første returnerer din post, og den anden returnerer NXDOMAIN, har du bevist, at posten ikke findes i DNS, og at din maskine svarer fra en lokal tilsidesættelse.

Rækkefølgen kan konfigureres, og det er værd at tjekke, før du konkluderer noget om en bestemt distribution. Se på hosts:-linjen i /etc/nsswitch.conf; hosts: files dns konsulterer filer først. Kopiér ikke det eksempel over en fungerende konfiguration bare for at ændre rækkefølgen, fordi rigtige systemer ofte angiver yderligere kilder og betingede tjenesteposter, som eksemplet ikke indeholder.

systemd-resolved slører testen

På et system, der bruger systemd-resolved, leverer den lokale stub også navne fra hosts-databasen. Derfor er en forespørgsel til 127.0.0.53 ikke en uafhængig test af fjernserveren, selv om den ser ud som og opfører sig som en DNS-forespørgsel. Du kan bekræfte, hvad resolveren ved, og hvilke servere den ville spørge, med:

resolvectl query build.corp.example
resolvectl status

Statusoutputtet angiver DNS-serverne per link, og det er sådan, du finder ud af, om VPN-linket overhovedet har fået en resolver. Det spørgsmål er adskilt fra hosts-posten og er det, der er værd at stille, når et privat navn fejler for alle brugere og ikke for én.

Programmer kan tilføje endnu et lag. En browser med sin egen DNS-over-HTTPS-indstilling, en container med sin egen resolverkonfiguration eller en runtime, der cacher opslag i processens levetid, kan hver især svare anderledes end systemet. Test det program, du interesserer dig for, i stedet for at antage, at én kommando beskriver alle programmer på maskinen.

Hvad der egentlig deler et navn gennem VPN’en

Hvis et privat navn skal virke for alle, har det brug for en ejer, som alles resolver kan nå. Det rene svar er at udgive posten i en administreret zone og gøre den zone opløselig gennem den tilsigtede VPN DNS-vej. Så har posten én kilde til sandhed, et revisionsspor og en livscyklus, og ingen behøver at huske, hvilken laptop der bærer en lokal tilsidesættelse.

At distribuere hosts-filer er et legitimt alternativ, og det er endpoint-administration snarere end navnetjeneste. Hvis du vælger det, skal filen udrulles, versionsstyres og fjernes af det, der administrerer flåden, og det bør beskrives sådan i designet. “VPN’en klarer det” er ikke en beskrivelse af den proces.

Dynamisk DNS-registrering er en tredje mekanisme med sine egne tilladelser, opdateringsgodkendelse og postlevetid. Den følger ikke af en hosts-post, og den følger heller ikke af, at en klient blot forbinder, medmindre serveren og klienten begge er konfigureret til det. En post, der dukker op af sig selv, er et signal om, at nogen har aktiveret sikre opdateringer og en klient, der registrerer sig selv, og den konfiguration hører til i designposten snarere end i en fejlfindingsdiskussion. Hvis ingen kan navngive, hvem der ejer den indstilling, skal den automatiske post behandles som uverificeret, og den administrerede zone holdes som kilden til sandhed.

Et opløst navn er ikke en rute

Navneopløsning og tilgængelighed er adskilte, og en forældet lokal tilknytning er den klassiske måde at forveksle dem. En hosts-post, der peger på en adresse, som er flyttet, vil fortsætte med at vælge den forældede vært længe efter, at DNS er rettet, og symptomet ligner en routingfejl på et navn, der slår fint op.

Så når rapporten er “navnet slår op, men tjenesten kan ikke nås”, sammenlign systemets opslag med en eksplicit forespørgsel til VPN DNS-serveren, og tjek derefter den adresse, du fik, mod den, tjenesten faktisk bruger. systemd-resolved-referencen dokumenterer de lokale kilder, den konsulterer, og det er det kort, du har brug for til den sammenligning.

Ret derefter tilsidesættelsen gennem dens ejer. At fjerne en linje fra din egen hosts-fil gør intet for de tolv laptops, der fik samme linje fra et udrulningsscript, og det er den version af problemet, folk faktisk har.