VPN-DNS fungerer, men .local-navn feiler fortsatt: hvem løser dem?

To maskiner på samme VPN, samme vertsnavn, og bare én av dem løser det: forskjellen er vanligvis ikke tunnelen, men hvilken resolver som svarte. På en Linux-skrivebord kan navnet gå gjennom navnetjenestebryteren, gjennom stubben til systemd-resolved eller gjennom en resolver programmet hadde med seg, og hver av dem bruker sin egen regel på samme suffiks. Det er ved suffikset reglene skilles, fordi .local ikke er en nøytral etikett. Finn ut hvilken vei det feilende programmet faktisk tar, før du endrer rekkefølgen noe kjører i.

To resolvere, to forskjellige svar

Et tradisjonelt glibc-oppslag går gjennom hosts:-linjen i nsswitch.conf og spør hver modul etter tur til én svarer. En klient som snakker med systemd-resolved via stub-lytteren, spør i stedet én enkelt prosess, og den prosessen bruker policy per lenke pluss sine egne spesialtilfeller. Et program som leverer sin egen resolver, eller lenker et bibliotek som gjør det, kan omgå begge. Ett vertsnavn kan derfor ha tre eiere på én maskin, og bare én av dem vet hva VPN-et mente.

Identifiser eieren før du endrer noe, fordi rettelsen er forskjellig for hver av de tre. En nettleser og et kommandolinjeverktøy på samme skrivebord kan med rette være uenige, og den uenigheten er sporet, ikke feilen. Hvis nettleseren løser navnet og verktøyet ikke, feilsøker du en resolvervei og ikke en VPN-rute. Bekreft ruten separat, slik at en rutingsfeil ikke forveksles med en navnetjenestefeil. Når begge er enige, ligger feilen oppstrøms for verten, og resolverkonfigurasjonen her er ikke enda en endring verdt.

Hvilken kommando som faktisk spurte resolveren din

To skrivebeskyttede kommandoer svarer på beslektede spørsmål, og å sammenligne dem lokaliserer problemet raskere enn å lese konfigurasjonen. Bruk et ekte internt navn og hold utdata privat, fordi interne poster fremdeles er interne. Kjør begge i samme økt som det feilende programmet kjører i:

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

Den første spør gjennom de konfigurerte modulene, som er det et typisk program opplever. Den andre spør systemd-resolved direkte og rapporterer lenken, protokollen og serveren som svarte. Å spørre bedriftsserveren på adresse beviser bare at serveren har posten, fordi det ikke sier noe om hvorvidt programmet noen gang spurte den. Les lenken som bærer VPN-et, og domenene den hevder, og sammenlign deretter listen med suffikset i det feilende navnet.

Hvorfor .local hopper over unicast-sonen din

referansen til systemd-resolved opplyser at navn med flere etiketter som ender på .local, vanligvis går til multicast-DNS når mDNS er aktivert, i stedet for vanlig unicast-DNS. RFC 6762 setter av det navnerommet for link-lokal multicast, så en bedriftssone kan ha en korrekt post som aldri blir spurt om det suffikset. Tunnelen kan rute resolveren perfekt og likevel tape kappløpet. En ping som lykkes fra en hurtigbuffer, sier ingenting om oppslaget som nettopp skjedde.

Det finnes et dokumentert unntak, og det avgjør de fleste av disse tilfellene: når en lenke erklærer det suffikset som søkedomene eller rutingsdomene, holder daemonen det på unicast-veien og hopper over det spesielle multicast-tilfellet. Det er policy per lenke og ikke en global preferanse. To maskiner med samme VPN-server kan oppføre seg ulikt når én nettverksprofil erklærer domenet og den andre ikke, så les den aktive profilen og ikke den du husker at du redigerte.

Det snevre unntaket slår en global omorganisering

For en eksisterende sone du ikke kan gi nytt navn, la resolver- og VPN-eierne erklære domenet på forbindelsen som bærer det. En rutingsdomeneoppføring for det ene suffikset pluss den tiltenkte serveradressen er en liten endring med en navngitt eier, og den bor sammen med lenken i stedet for i en håndredigert fil.

Den overlever også en frakobling, fordi lenkepolicyen brukes på nytt når lenken kommer tilbake. Å redigere den felles nsswitch.conf er det fristende og det dyrere alternativet, fordi det endrer oppslagsatferd for hvert navn på maskinen, inkludert lokal oppdagelse. Å deaktivere multicast-daemonen er heller ikke likeverdig: det fjerner den lokale atferden uten å lære noen resolver om bedriftssonen. Hvis tjenesten er ny og ikke arvet, legg den under et underdomene organisasjonen din kontrollerer, og hopp over konkurransen helt. Velg det snevre unntaket når navnet er festet i fastvaren eller trykt på en etikett, og velg et nytt underdomene når du fremdeles kontrollerer klienten.

Hva som skal bevises etter endringen

Bevis rettelsen med programmets eget oppslag i stedet for et verktøy du installerte for å teste, og tøm enhver hurtigbuffer som kunne svare på dets vegne. Bekreft deretter resolverveien og lenken som ga svaret. Kontroller til slutt at lokal oppdagelse oppfører seg som før endringen, fordi skriveren som slutter å dukke opp, er den delen folk legger merke til sist. Disse tre kommandoene kontrollerer navnet, veien og TLS-identiteten i den rekkefølgen:

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 feil sertifikat får fremdeles en streng klient til å feile, så kontroller navnet programmet forventer når oppslaget virker. Bekreft at tjenesten godtar forbindelser fra VPN-adressen og ikke bare fra kontorområdet. Skriv domeneomfanget, serveren og eieren inn i dokumentasjonen for forbindelsen. Ellers griper neste person som møter denne feilen, etter den samme globale redigeringen du nettopp unngikk.