VPN-DNS virker, men .local-navne fejler stadig: hvem opløser dem?

To maskiner på samme VPN, samme værtsnavn, og kun én af dem opløser det: forskellen er normalt ikke tunnelen, men hvilken resolver der svarede. På en Linux-skrivebord kan navnet gå gennem navnetjenesteskifteren, gennem systemd-resolveds stub eller gennem en resolver, som programmet har haft med sig, og hver af dem anvender sin egen regel på det samme suffiks. Det er ved suffikset, reglerne skilles, fordi .local ikke er en neutral etiket. Find ud af, hvilken vej det fejlende program faktisk tager, før du ændrer den rækkefølge, hvori noget kører.

To resolvere, to forskellige svar

Et traditionelt glibc-opslag går gennem hosts:-linjen i nsswitch.conf og spørger hvert modul efter tur, indtil et svarer. En klient, der taler med systemd-resolved gennem stub-lytteren, spørger i stedet en enkelt proces, og den proces anvender politik pr. link plus sine egne særlige tilfælde. Et program, der leverer sin egen resolver eller linker et bibliotek, som gør det, kan omgå begge. Et værtsnavn kan derfor have tre ejere på én maskine, og kun én af dem ved, hvad VPN’et havde til hensigt.

Identificér ejeren, før du ændrer noget, fordi rettelsen er forskellig for hver af de tre. En browser og et kommandolinjeværktøj på samme skrivebord kan med rette være uenige, og den uenighed er sporet frem for fejlen. Hvis browseren opløser navnet og værktøjet ikke, fejlretter du en resolvervej og ikke en VPN-rute. Bekræft ruten separat, så en ruteringsfejl ikke forveksles med en navnetjenestefejl. Når begge er enige, ligger fejlen opstrøms for værten, og resolverkonfigurationen her er ikke endnu en redigering værd.

Hvilken kommando spurgte faktisk din resolver

To skrivebeskyttede kommandoer besvarer beslægtede spørgsmål, og at sammenligne dem lokaliserer problemet hurtigere end at læse konfiguration. Brug et rigtigt internt navn, og hold output privat, fordi interne poster stadig er interne. Kør begge i samme session, som det fejlende program kører i:

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

Den første spørger gennem de konfigurerede moduler, hvilket er det, et typisk program oplever. Den anden spørger systemd-resolved direkte og rapporterer det link, den protokol og den server, der svarede. At forespørge virksomhedens server på adresse beviser kun, at serveren har posten, fordi det intet siger om, hvorvidt programmet nogensinde spurgte den. Læs det link, der bærer VPN’et, og de domæner, det hævder, og sammenlign derefter listen med suffikset i det fejlende navn.

Hvorfor .local springer din unicast-zone over

systemd-resolveds reference oplyser, at navne med flere etiketter, der ender på .local, normalt går til multicast DNS, når mDNS er aktiveret, i stedet for til almindelig unicast DNS. RFC 6762 reserverer det navnerum til link-lokal multicast, så en virksomhedszone kan have en korrekt post, som aldrig bliver spurgt om det suffiks. Tunnelen kan rute resolveren perfekt og alligevel tabe kapløbet. En ping, der lykkes fra en cache, siger intet om det opslag, der netop er sket.

Der er en dokumenteret undtagelse, og den afgør de fleste af disse tilfælde: når et link erklærer det suffiks som søgedomæne eller ruteringsdomæne, holder daemonen det på unicast-vejen og springer det særlige multicast-tilfælde over. Det er politik pr. link frem for en global præference. To maskiner med samme VPN-server kan opføre sig forskelligt, når én netværksprofil erklærer domænet og den anden ikke, så læs den aktive profil i stedet for den, du husker at have redigeret.

Den snævre undtagelse slår en global omarrangering

For en eksisterende zone, du ikke kan omdøbe, skal resolver- og VPN-ejere erklære domænet på den forbindelse, der bærer det. En ruteringsdomænepost for det ene suffiks plus den tilsigtede serveradresse er en lille ændring med en navngiven ejer, og den bor sammen med linket i stedet for i en håndredigeret fil.

Den overlever også en afbrydelse, fordi linkpolitikken anvendes igen, når linket vender tilbage. At redigere den fælles nsswitch.conf er det fristende og det dyrere alternativ, fordi det ændrer opslagsadfærd for hvert navn på maskinen, inklusive lokal opdagelse. At deaktivere multicast-daemonen er heller ikke ensbetydende: det fjerner den lokale adfærd uden at lære nogen resolver om virksomhedszonen. Hvis tjenesten er ny snarere end arvet, skal du placere den under et underdomæne, din organisation kontrollerer, og springe konkurrencen helt over. Vælg den snævre undtagelse, når navnet er fastlåst i firmware eller trykt på en etiket, og vælg et nyt underdomæne, når du stadig kontrollerer klienten.

Hvad skal bevises efter ændringen

Bevis rettelsen med programmets eget opslag i stedet for et værktøj, du installerede for at teste, og ryd enhver cache, der kunne svare på dets vegne. Bekræft derefter resolvervejen og det link, der gav svaret. Kontrollér til sidst, at lokal opdagelse stadig opfører sig som før ændringen, fordi den printer, der holder op med at dukke op, er den del, folk lægger mærke til sidst. Disse tre kommandoer kontrollerer navnet, vejen og TLS-identiteten i den rækkefølge:

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 adresse med det forkerte certifikat får stadig en streng klient til at fejle, så kontrollér det navn, programmet forventer, når opløsningen virker. Bekræft, at tjenesten accepterer forbindelser fra VPN-adressen og ikke kun fra kontorets område. Skriv domæneomfanget, serveren og ejeren ind i forbindelsens dokumentation. Ellers griber den næste person, der møder denne fejl, efter den samme globale redigering, som du netop undgik.