Waarom je /etc/hosts-regel de DNS van de VPN niet bereikt

Je hebt een naam aan /etc/hosts toegevoegd, verbinding gemaakt met de VPN en verwachtte dat de registratie voor iedereen zichtbaar zou worden. Dat gebeurt niet, en de verrassing komt meestal met een tweede symptoom: de naam lost op je eigen machine op en faalt bij een collega, wat op een kapotte VPN DNS-dienst lijkt en in werkelijkheid het hosts-bestand is dat precies doet waarvoor het is ontworpen. Een hosts-bestand is lokale naamresolutieconfiguratie, geen zone-update, en niets in een normale VPN-verbinding uploadt het.

Hosts is een lokale overschrijving, geen zone-update

Het bestand is een lijst met toewijzingen die naamdienstbibliotheken raadplegen voordat, of in plaats van, ze een DNS-server vragen. Een regel als 10.40.0.20 build.corp.example verandert wat applicaties op die ene machine concluderen. Hij maakt geen registratie aan, reist niet door de tunnel, en de DNS-server waar de tunnel naar wijst heeft geen idee dat hij bestaat.

Daarom is de fout asymmetrisch. Je client krijgt een antwoord uit het bestand. Een andere client vraagt het VPN DNS-server, die niets teruggeeft, en de applicatie meldt dat de naam niet bestaat. Beide machines gedragen zich correct; slechts één heeft een overschrijving die de ander nooit heeft gezien.

Twee opdrachten, twee verschillende componenten

De snelste manier om de discussie te stoppen is het verschil zichtbaar te maken in twee opdrachten, beide uitgevoerd op de client met de hosts-regel:

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

De eerste vraagt het eigen zoekpad van het systeem, dat op een typisch glibc-systeem lokale bestanden leest vóór DNS. De tweede stuurt een DNS-query rechtstreeks naar de server op dat adres en raadpleegt helemaal geen lokale bestanden. Wanneer de eerste jouw regel teruggeeft en de tweede NXDOMAIN, heb je bewezen dat de registratie niet in DNS bestaat en dat je machine antwoordt vanuit een lokale overschrijving.

De volgorde is configureerbaar, en het loont om die te controleren voordat je iets over een specifieke distributie concludeert. Kijk naar de hosts:-regel in /etc/nsswitch.conf; hosts: files dns raadpleegt eerst bestanden. Kopieer dat voorbeeld niet over een werkende configuratie alleen om de volgorde te wijzigen, want echte systemen vermelden vaak extra bronnen en voorwaardelijke service-regels die het voorbeeld niet bevat.

systemd-resolved vertroebelt de test

Op een systeem met systemd-resolved bedient de lokale stub ook namen uit de hosts-database. Een query naar 127.0.0.53 is dus geen onafhankelijke test van de externe server, ook al ziet hij eruit als een DNS-query en gedraagt hij zich zo. Je kunt bevestigen wat de resolver weet en welke servers hij zou vragen met:

resolvectl query build.corp.example
resolvectl status

De statusuitvoer noemt de DNS-servers per link, en zo kom je erachter of de VPN-link überhaupt een resolver heeft gekregen. Die vraag staat los van de hosts-regel en is degene die het waard is om te stellen wanneer een privénaam voor alle gebruikers faalt en niet voor één.

Applicaties kunnen nog een laag toevoegen. Een browser met zijn eigen DNS-over-HTTPS-instelling, een container met zijn eigen resolverconfiguratie of een runtime die opzoekingen voor de hele levensduur van het proces cachet, kunnen elk anders antwoorden dan het systeem. Test de applicatie die je belangrijk vindt in plaats van aan te nemen dat één opdracht elk programma op de machine beschrijft.

Wat een naam echt over de VPN deelt

Als een privénaam voor iedereen moet werken, heeft hij een eigenaar nodig die de resolver van iedereen kan bereiken. Het nette antwoord is de registratie in een beheerde zone publiceren en die zone oplosbaar maken via het bedoelde VPN DNS-pad. Dan heeft de registratie één bron van waarheid, een auditspoor en een levenscyclus, en niemand hoeft te onthouden welke laptop een lokale overschrijving draagt.

Hosts-bestanden distribueren is een legitiem alternatief, en het is endpointbeheer in plaats van naamdienst. Als je daarvoor kiest, moet het bestand worden uitgerold, geversioneerd en verwijderd door wat de vloot beheert, en zo moet het in het ontwerp worden beschreven. ‘De VPN regelt dat’ is geen beschrijving van dat proces.

Dynamische DNS-registratie is een derde mechanisme, met eigen machtigingen, update-authenticatie en registratielevensduur. Het volgt niet uit een hosts-regel, en het volgt ook niet uit een client die simpelweg verbinding maakt, tenzij de server en de client beide daarvoor zijn geconfigureerd. Een registratie die vanzelf verschijnt is een signaal dat iemand veilige updates heeft ingeschakeld en een client die zichzelf registreert, en die configuratie hoort in het ontwerpdocument en niet in een troubleshooting-thread. Als niemand kan benoemen wie die instelling bezit, behandel de automatische registratie dan als ongeverifieerd en houd de beheerde zone als bron van waarheid.

Een opgeloste naam is geen route

Naamresolutie en bereikbaarheid zijn gescheiden, en een verouderde lokale toewijzing is de klassieke manier om ze te verwarren. Een hosts-regel die naar een adres wijst dat is verhuisd, blijft de verouderde host kiezen lang nadat DNS is gecorrigeerd, en het symptoom lijkt op een routeringsfout bij een naam die goed oplost.

Dus wanneer het rapport ‘de naam lost op maar de dienst is niet bereikbaar’ is, vergelijk de systeemopzoeking met een expliciete query naar het VPN DNS-server, en controleer daarna het adres dat je kreeg tegen het adres dat de dienst werkelijk gebruikt. De systemd-resolved-referentie documenteert de lokale bronnen die hij raadpleegt, en dat is de kaart die je voor die vergelijking nodig hebt.

Herstel daarna de overschrijving via de eigenaar. Een regel uit je eigen hosts-bestand verwijderen doet niets voor de twaalf laptops die dezelfde regel van een uitrolscript hebben gekregen, en dat is de versie van dit probleem die mensen werkelijk hebben.