VPN-DNS fungerar, men .local-namn misslyckas fortfarande: vem löser dem?

Två maskiner på samma VPN, samma värdnamn, och bara en av dem löser det: skillnaden är oftast inte tunneln utan vilken resolver som svarade. På ett Linux-skrivbord kan namnet gå genom namnservicelagret, genom systemd-resolveds stub eller genom en resolver som programmet hade med sig, och var och en tillämpar sin egen regel på samma suffix. Det är vid suffixet reglerna går isär, eftersom .local inte är en neutral etikett. Ta reda på vilken väg det misslyckade programmet faktiskt tar innan du ändrar ordningen något körs i.

Två resolvrar, två olika svar

En traditionell glibc-sökning går genom hosts:-raden i nsswitch.conf och frågar varje modul i tur och ordning tills en svarar. En klient som pratar med systemd-resolved via stub-lyssnaren frågar i stället en enda process, och den processen tillämpar policy per länk plus sina egna specialfall. Ett program som levererar sin egen resolver, eller länkar ett bibliotek som gör det, kan kringgå båda. Ett värdnamn kan därför ha tre ägare på en maskin, och bara en av dem vet vad VPN:et avsåg.

Identifiera ägaren innan du ändrar något, eftersom åtgärden skiljer sig för var och en av de tre. En webbläsare och ett kommandoradsverktyg på samma skrivbord kan med rätta vara oense, och den oenigheten är ledtråden, inte felet. Om webbläsaren löser namnet och verktyget inte gör det, felsöker du en resolverväg och inte en VPN-rutt. Bekräfta rutten separat, så att ett routningsfel inte förväxlas med ett namnservicefel. När båda är överens ligger felet ovanför värden, och resolverkonfigurationen här är inte ännu en ändring värd.

Vilket kommando som faktiskt frågade din resolver

Två skrivskyddade kommandon svarar på närbesläktade frågor, och att jämföra dem lokaliserar problemet snabbare än att läsa konfigurationen. Använd ett riktigt internt namn och håll utdata privat, eftersom interna poster fortfarande är interna. Kör båda i samma session som det misslyckade programmet körs i:

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

Den första frågar genom de konfigurerade modulerna, vilket är vad ett typiskt program upplever. Den andra frågar systemd-resolved direkt och rapporterar länken, protokollet och servern som svarade. Att fråga företagsservern på adress bevisar bara att servern har posten, eftersom det inte säger något om huruvida programmet någonsin frågade den. Läs länken som bär VPN:et och de domäner som den hävdar, och jämför sedan listan med suffixet i det misslyckade namnet.

Varför .local hoppar över din unicast-zon

referensen för systemd-resolved anger att namn med flera etiketter som slutar på .local normalt går till multicast-DNS när mDNS är aktiverat, i stället för till vanlig unicast-DNS. RFC 6762 reserverar den namnrymden för link-local multicast, så en företagszon kan ha en korrekt post som aldrig tillfrågas för det suffixet. Tunneln kan routa resolvern perfekt och ändå förlora kapplöpningen. En ping som lyckas från cachen säger ingenting om uppslaget som just skedde.

Det finns ett dokumenterat undantag, och det avgör de flesta av dessa fall: när en länk deklarerar suffixet som sökdomän eller routningsdomän håller daemonen det på unicast-vägen och hoppar över specialfallet multicast. Det är policy per länk och inte en global preferens. Två maskiner med samma VPN-server kan bete sig olika när en nätverksprofil deklarerar domänen och den andra inte, så läs den aktiva profilen och inte den du minns att du redigerade.

Det snäva undantaget slår en global omordning

För en befintlig zon som du inte kan byta namn på, låt resolver- och VPN-ägarna deklarera domänen på anslutningen som bär den. En routningsdomänpost för det enda suffixet plus den avsedda serveradressen är en liten ändring med en namngiven ägare, och den bor med länken i stället för i en handredigerad fil.

Den överlever också en frånkoppling, eftersom länkens policy tillämpas igen när länken kommer tillbaka. Att redigera den delade nsswitch.conf är det frestande och det dyrare alternativet, eftersom det ändrar uppslagsbeteendet för varje namn på maskinen, inklusive lokal upptäckt. Att inaktivera multicast-daemonen är inte heller likvärdigt: det tar bort det lokala beteendet utan att lära någon resolver om företagszonen. Om tjänsten är ny och inte ärvd, lägg den under en underdomän som din organisation kontrollerar och hoppa över konkurrensen helt. Välj det snäva undantaget när namnet är låst i firmware eller tryckt på en etikett, och välj en ny underdomän när du fortfarande kontrollerar klienten.

Vad som ska bevisas efter ändringen

Bevisa åtgärden med programmets eget uppslag i stället för ett verktyg du installerade för att testa, och töm alla cachar som skulle kunna svara i dess ställe. Bekräfta sedan resolvervägen och länken som gav svaret. Kontrollera till sist att lokal upptäckt beter sig som före ändringen, eftersom skrivaren som slutar dyka upp är den del folk märker sist. Dessa tre kommandon kontrollerar namnet, vägen och TLS-identiteten i den ordningen:

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

En korrekt adress med fel certifikat får fortfarande en strikt klient att misslyckas, så kontrollera namnet som programmet förväntar sig när uppslaget fungerar. Bekräfta att tjänsten accepterar anslutningar från VPN-adressen och inte bara från kontorsintervallet. Skriv domänomfånget, servern och ägaren i anslutningens dokumentation. Annars griper nästa person som möter felet efter samma globala ändring som du just undvek.