VPN-DNS fungerer, men .local-namn feilar framleis: kven løyser dei?

To maskinar på same VPN, same vertsnamn, og berre ein av dei løyser det: skilnaden er vanlegvis ikkje tunnelen, men kva resolver som svara. På ein Linux-skrivebord kan namnet gå gjennom namnetenestebrytaren, gjennom stubben til systemd-resolved eller gjennom ein resolver programmet hadde med seg, og kvar av dei brukar si eiga regel på same suffiks. Det er ved suffikset reglane skil seg, fordi .local ikkje er ei nøytral etikett. Finn ut kva veg det feilande programmet faktisk tek, før du endrar rekkjefølgja noko køyrer i.

To resolverar, to ulike svar

Eit tradisjonelt glibc-oppslag går gjennom hosts:-linja i nsswitch.conf og spør kvar modul etter tur til éin svarar. Ein klient som snakkar med systemd-resolved via stub-lyttaren, spør i staden éin enkelt prosess, og den prosessen brukar policy per lenkje pluss sine eigne spesialtilfelle. Eit program som leverer sin eigen resolver, eller lenkjer eit bibliotek som gjer det, kan omgå båe. Eitt vertsnamn kan difor ha tre eigarar på éin maskin, og berre éin av dei veit kva VPN-et meinte.

Identifiser eigaren før du endrar noko, fordi rettinga er ulik for kvar av dei tre. Ein nettlesar og eit kommandolinjeverktøy på same skrivebord kan med rette vere usamde, og den usemja er sporet, ikkje feilen. Viss nettlesaren løyser namnet og verktøyet ikkje, feilsøkjer du ein resolverveg og ikkje ein VPN-rute. Stadfest ruta separat, slik at ein rutingsfeil ikkje blir forveksla med ein namnetenestefeil. Når båe er samde, ligg feilen oppstraums for verten, og resolverkonfigurasjonen her er ikkje endå ei endring verd.

Kva kommando som faktisk spurde resolveren din

To skriveverna kommandoar svarar på skyldte spørsmål, og å samanlikne dei lokaliserer problemet raskare enn å lese konfigurasjonen. Bruk eit ekte internt namn og hald utdata privat, fordi interne postar framleis er interne. Køyr båe i same økta som det feilande programmet køyrer i:

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

Den første spør gjennom dei konfigurerte modulane, som er det eit typisk program opplever. Den andre spør systemd-resolved direkte og rapporterer lenkja, protokollen og tenaren som svara. Å spørje bedriftstenaren på adresse beviser berre at tenaren har posten, fordi det ikkje seier noko om programmet nokon gong spurde han. Les lenkja som ber VPN-et, og domena ho hevdar, og samanlikn deretter lista med suffikset i det feilande namnet.

Kvifor .local hoppar over unicast-sona di

referansen til systemd-resolved opplyser at namn med fleire etikettar som endar på .local, vanlegvis går til multicast-DNS når mDNS er slått på, i staden for vanleg unicast-DNS. RFC 6762 set av det namnerommet for link-lokal multicast, så ei bedriftssone kan ha ein korrekt post som aldri blir spurt om det suffikset. Tunnelen kan rute resolveren perfekt og likevel tape kappløpet. Ein ping som lukkast frå ein hurtigbuffer, seier ingenting om oppslaget som nettopp skjedde.

Det finst eit dokumentert unntak, og det avgjer dei fleste av desse tilfella: når ei lenkje erklærer det suffikset som søkjedomene eller rutingsdomene, held daemonen det på unicast-vegen og hoppar over det spesielle multicast-tilfellet. Det er policy per lenkje og ikkje ei global preferring. To maskinar med same VPN-tenar kan oppføre seg ulikt når éin nettverksprofil erklærer domenet og den andre ikkje, så les den aktive profilen og ikkje den du hugsar at du redigerte.

Det snevre unntaket slår ei global omorganisering

For ei eksisterande sone du ikkje kan gje nytt namn, la resolver- og VPN-eigarane erklære domenet på sambandet som ber det. Ein rutingsdomeneoppføring for det eine suffikset pluss den tiltenkte tenaradressa er ei lita endring med ein namngjeven eigar, og ho bur saman med lenkja i staden for i ei handredigert fil.

Ho overlever òg ein fråkopling, fordi lenkjepolicyen blir brukt på nytt når lenkja kjem tilbake. Å redigere den felles nsswitch.conf er det freistande og det dyrare alternativet, fordi det endrar oppslagsåtferd for kvart namn på maskinen, inkludert lokal oppdaging. Å slå av multicast-daemonen er heller ikkje likeverdig: det fjernar den lokale åtferda utan å lære nokon resolver om bedriftssona. Viss tenesta er ny og ikkje arva, legg ho under eit underdomene organisasjonen din kontrollerer, og hopp over konkurransen heilt. Vel det snevre unntaket når namnet er fest i fastvaren eller trykt på ein etikett, og vel eit nytt underdomene når du framleis kontrollerer klienten.

Kva som skal provast etter endringa

Prov rettinga med programmets eige oppslag i staden for eit verktøy du installerte for å teste, og tøm ein kvar hurtigbuffer som kunne svare på vegner av det. Stadfest deretter resolvervegen og lenkja som gav svaret. Til slutt kontrollerer du at lokal oppdaging oppfører seg som før endringa, fordi skrivaren som sluttar å dukke opp, er den delen folk legg merke til sist. Desse tre kommandoane kontrollerer namnet, vegen og TLS-identiteten i den rekkjefølgja:

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

Ei korrekt adresse med feil sertifikat får framleis ein streng klient til å feile, så kontroller namnet programmet ventar når oppslaget verkar. Stadfest at tenesta godtek samband frå VPN-adressa og ikkje berre frå kontorområdet. Skriv domeneomfanget, tenaren og eigaren inn i dokumentasjonen for sambandet. Elles grip neste person som møter denne feilen, etter den same globale redigeringa du nettopp unngjekk.