Interne namn feilar på VPN medan offentlege nettstader løyser seg fint

Éin brukar melder at intranettvertsnamnet ikkje løyser seg over VPN. Ei andre melding, frå same maskina, seier at ein lekkasjetest framleis viser spørjingar som den lokale løysaren svarar på. Dei høyrest ut som eitt problem og er to, med ulike prov, og den vanlege reparasjonen for det første gjer det andre verre. Skil dei før du rører ei innstilling.

To symptom som ikkje er éin feil

At eit internt namn ikkje løyser seg, tyder at spørsmålet gjekk til ein stad som ikkje har noko svar på det. Spørjingar som forlèt tunnelen, tyder at spørsmålet gjekk til feil stad sjølv når svaret var tilgjengeleg. Det er motsette feil: den eine er eit manglande svar, den andre ein ekstra destinasjon.

Fella er at å leggje til kontorløysaren overalt rettar det første og garanterer det andre. Å leggje til ein offentleg løysar overalt gjer det motsette.

Skriv ned båe observasjonane med tidsstempel, og gå deretter gjennom dei fire kontrollane nedanfor i rekkjefølgje.

Kva adapter som får spørsmålet til løysaren sin

På Windows vel DNS-klienten tenarar etter bindingsrekkjefølgja til adapteret, og tunneleadapteret er ikkje automatisk først. Opne dei avanserte innstillingane til adapteret og flytt tilkoplinga for ekstern tilgang over det fysiske adapteret, og kople til på nytt slik at endringa gjeld ei fersk økt.

Bindingsrekkjefølgja er berre halvparten. Klienten må òg vite kva namn som høyrer til det adapteret, og det er eit suffiksspørsmål, ikkje eit rekkjefølgjespørsmål.

Legg ipconfig /all frå den fungerande maskina ved sida av den frå den berbare maskina, båe tekne medan tunnelen er oppe. Den fungerande maskina vil vise eit tilkoplingsspesifikt DNS-suffiks på kontoradapteret, og den berbare maskina kan vise ingen på tunnelen. Den skilnaden forklarer ein heil klasse meldingar om at tenaren er der og namnet likevel feilar, for utan suffiks blir det korte namnet aldri fullført til sona kontorløysaren tener.

Eit kort namn treng suffiks før det treng rute

Å skrive eit ukvalifisert vertsnamn ber løysaren gjette eit domene. Gjettinga kjem frå suffikslista som er knytt til tilkoplinga, og om den lista er tom, går spørjinga ut som éi etikett som ingen privat sone vil matche.

Kopier suffikset frå den fungerande maskina til IPv4-eigenskapane til VPN-adapteret på DNS-fana, og kople til på nytt. På Linux er motstykket søkjedomenet på tunnellenkja, som systemd-resolved viser per lenkje i staden for globalt.

Hald dei to innstillingane kvar for seg i notata. Eit suffiks endrar kva det blir spurt om; løysaradressa endrar kven det blir spurt. Å rette den eine medan den andre er feil gir eit resultat som verkar tilfeldig.

Spør løysaren direkte først, så namnet

Ei direkte spørjing til kontorløysaren skil eit namneproblem frå eit ruteproblem, fordi ho omgår løysarvalet til klienten heilt.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Den første kommandoen ber ein bestemt tenar om eit fullt kvalifisert namn. Svarar han, er løysaren og ruta dit i orden, og feilen ligg i valet eller suffikset. Timar han ut, er adressa feil eller utilgjengeleg, og problemet er ruting, ikkje DNS. Den andre kommandoen viser kva som skjer med det korte namnet, og den tredje skriv ut løysarkonfigurasjonen per lenkje på ein systemd-vert.

Sjå opp for jokerteiknsvar, som nokre nettverk returnerer for ukjende namn. Eit svar som ser rimeleg ut er ikkje prov for at den tiltenkte tenaren svara, så samanlikn den returnerte adressa med den den interne tenesta faktisk brukar. Om adressa høyrer til ei parkeringsside eller ein proxy, svara løysaren, men svaret var aldri ditt. Den skilnaden sparer ein time med å jage ein tunnel som fungerte heile tida.

På Linux erstattar ein VPN-klient som skriv om /etc/resolv.conf dei lokale løysarane heilt. vpnc tilbyr DNSUpdate no for å stoppe det, og systemd-resolved kan rute berre dei oppgitte domena til tunnellenkja. Båe framgangsmåtane held offentlege namn hos den lokale løysaren medan interne namn blir sende til kontoret.

Lekkasjar er ei regel, ikkje ein avkrysningsboks

Namneoppslag er ein UDP-utveksling til port 53, så ein tunnel som ber webtrafikk men ikkje UDP, lèt spørjinga bli liggjande på den fysiske vegen. Prov det ved å fange trafikk på det fysiske nettverkskortet medan eit offentleg namn blir løyst. Ei spørjing som er synleg på det grensesnittet i lesbar form, tyder at tunnelen ikkje ber ho.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Om spørjinga dukkar opp på det grensesnittet i lesbar form, ber ikkje tunnelen ho. Reparasjonen er ei regel som tillèt port 53 berre til løysaren VPN-en skauv ut og forkastar andre destinasjonar, pluss ein klientkonfigurasjon som ikkje stille forkastar det påskutne alternativet.

Den siste delen tyder meir enn han ser ut som. Start OpenVPN med route-nopull, og det påskutne DNS-alternativet forsvinn saman med rutene, med mindre pull-filteret blir utvida for å behalde det. Ein klient som ignorerer dhcp-option DNS, vil halde fram med å bruke det han hadde før. Kvar endring på tenarsida treng ei fersk økt for å verke, sidan løysarlista blir levert når tunnelen kjem opp, og ei gammal økt held fram med å vise den gamle tilstanden.

Noter kva feil du faktisk observerte før du lukkar saka. Eit manglande internt svar og ei spørjing som rømmer frå tunnelen krev ulike reparasjonar, og ei suffiksendring som rettar det første kan stille forverre det andre. Den som tek over saka neste gong vil stole på etiketten, så gjer etiketten nøyaktig.