VPN-DNS werkt, maar .local-namen falen nog steeds: wie lost ze op?

Twee machines op dezelfde VPN, dezelfde hostnaam, en slechts één ervan lost hem op: het verschil is meestal niet de tunnel maar welke resolver heeft geantwoord. Op een Linux-desktop kan die naam via de naamdienstschakelaar, via de stub van systemd-resolved of via een resolver die de toepassing zelf meebracht lopen, en elk daarvan past zijn eigen regel toe op hetzelfde achtervoegsel. Het achtervoegsel is waar de regels uiteenlopen, omdat .local geen neutraal label is. Zoek uit welk pad het falende programma werkelijk neemt voordat je de volgorde verandert waarin iets draait.

Twee resolvers, twee verschillende antwoorden

Een traditionele glibc-lookup loopt door de hosts:-regel in nsswitch.conf en vraagt elk module om de beurt tot één antwoordt. Een client die via de stub-listener met systemd-resolved praat, vraagt in plaats daarvan één proces, en dat proces past beleid per verbinding plus zijn eigen speciale gevallen toe. Een toepassing die zijn eigen resolver meebrengt, of een bibliotheek linkt die dat doet, kan beide omzeilen. Eén hostnaam kan dus drie eigenaren op één machine hebben, en slechts één van hen weet wat de VPN bedoelde.

Bepaal de eigenaar voordat je iets verandert, want de oplossing verschilt voor elk van de drie. Een browser en een opdrachtregelprogramma op dezelfde desktop kunnen het legitiem oneens zijn, en die onenigheid is de aanwijzing, niet de fout. Als de browser de naam oplost en het programma niet, debug je een resolverpad en geen VPN-route. Bevestig de route apart, zodat een routeringsfout niet wordt aangezien voor een naamdienstfout. Als beide het eens zijn, ligt de fout stroomopwaarts van de host en is de resolverconfiguratie hier geen volgende bewerking waard.

Welk commando je resolver werkelijk bevroeg

Twee alleen-lezen commando’s beantwoorden verwante vragen, en ze vergelijken lokaliseert het probleem sneller dan de configuratie lezen. Gebruik een echte interne naam en houd de uitvoer privé, want interne records blijven intern. Voer beide uit in dezelfde sessie waarin het falende programma draait:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

De eerste vraagt via de geconfigureerde modules, wat een typisch programma meemaakt. De tweede vraagt systemd-resolved rechtstreeks en meldt de verbinding, het protocol en de server die antwoordde. De bedrijfsserver op adres bevragen bewijst alleen dat de server het record heeft, want het zegt niets over de vraag of de toepassing hem ooit heeft bevraagd. Lees de verbinding die de VPN draagt en de domeinen die hij claimt, en vergelijk die lijst dan met het achtervoegsel in de falende naam.

Waarom .local je unicast-zone overslaat

de referentie van systemd-resolved meldt dat namen met meerdere labels die op .local eindigen, bij ingeschakelde mDNS normaal naar multicast-DNS gaan in plaats van naar gewone unicast-DNS. RFC 6762 houdt die naamruimte vrij voor link-local multicast, dus een bedrijfszone kan een correct record hebben waarnaar voor dat achtervoegsel nooit wordt gevraagd. De tunnel kan de resolver perfect routeren en de race alsnog verliezen. Een geslaagde ping uit een cache zegt niets over de lookup die zojuist plaatsvond.

Er is een gedocumenteerde uitzondering, en die beslecht de meeste van deze gevallen: wanneer een verbinding dat achtervoegsel als zoekdomein of routeringsdomein declareert, houdt de daemon het op het unicast-pad en slaat het speciale multicast-geval over. Dat is beleid per verbinding en geen globale voorkeur. Twee machines met dezelfde VPN-server kunnen zich anders gedragen wanneer het ene netwerkprofiel het domein declareert en het andere niet, dus lees het actieve profiel en niet het profiel waarvan je denkt dat je het hebt bewerkt.

De smalle uitzondering verslaat een globale herordening

Voor een bestaande zone die je niet kunt hernoemen, laat de resolver- en VPN-eigenaren het domein declareren op de verbinding die het draagt. Een routeringsdomein-item voor dat ene achtervoegsel plus het bedoelde serveradres is een kleine wijziging met een genoemde eigenaar, en het woont bij de verbinding in plaats van in een handmatig bewerkt bestand.

Hij overleeft ook een verbreking, omdat het verbindingsbeleid opnieuw wordt toegepast wanneer de verbinding terugkomt. De gedeelde nsswitch.conf bewerken is het verleidelijke en het duurdere alternatief, omdat het het opzoekgedrag voor elke naam op de machine verandert, inclusief lokale ontdekking. De multicast-daemon uitschakelen is ook niet gelijkwaardig: het verwijdert het lokale gedrag zonder enige resolver over de bedrijfszone te leren. Als de dienst nieuw is en niet geërfd, plaats hem onder een subdomein dat je organisatie beheert en sla de competitie volledig over. Kies de smalle uitzondering wanneer de naam in firmware vastligt of op een label is gedrukt, en kies een nieuw subdomein wanneer je de client nog beheert.

Wat na de wijziging te bewijzen

Bewijs de oplossing met de eigen lookup van de toepassing in plaats van met een hulpmiddel dat je om te testen hebt geïnstalleerd, en leeg elke cache die in zijn plaats zou kunnen antwoorden. Bevestig daarna het resolverpad en de verbinding die het antwoord gaf. Controleer ten slotte dat lokale ontdekking zich gedraagt zoals voor de wijziging, want de printer die verdwijnt is het deel dat mensen het laatst opmerken. Deze drie commando’s controleren de naam, het pad en de TLS-identiteit in die volgorde:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Een correkt adres met het verkeerde certificaat laat een strikte client alsnog falen, dus controleer de naam die de toepassing verwacht zodra de resolutie werkt. Bevestig dat de dienst verbindingen vanaf het VPN-adres accepteert en niet alleen vanuit de kantoorrange. Schrijf het domeinbereik, de server en de eigenaar in de documentatie van de verbinding. Anders grijpt de volgende persoon die deze fout tegenkomt naar dezelfde globale bewerking die je zojuist vermeed.