Interne navn feiler på VPN mens offentlige nettsteder løses fint

Én bruker melder at intranettvertsnavnet ikke løses over VPN. En andre melding, fra samme maskin, sier at en lekketest fortsatt viser spørringer besvart av den lokale resolveren. De høres ut som ett problem og er to, med ulike bevis, og den vanlige reparasjonen for det første gjør det andre verre. Skill dem før du rører en innstilling.

To symptomer som ikke er én feil

At et internt navn ikke løses betyr at spørsmålet gikk et sted som ikke har noe svar på det. Spørringer som forlater tunnelen betyr at spørsmålet gikk til feil sted selv når svaret var tilgjengelig. Det er motsatte feil: den ene er et manglende svar, den andre en ekstra destinasjon.

Fellen er at å legge til kontoresolveren overalt fikser det første og garanterer det andre. Å legge til en offentlig resolver overalt gjør det motsatte.

Skriv ned begge observasjonene med tidsstempel, og gå deretter gjennom de fire kontrollene nedenfor i rekkefølge.

Hvilken adapter som får spørsmålet til sin resolver

På Windows velger DNS-klienten servere etter adapterens bindingsrekkefølge, og tunneleadapteren er ikke automatisk først. Åpne adapterens avanserte innstillinger og flytt tilkoblingen for ekstern tilgang over den fysiske adapteren, og koble til på nytt slik at endringen gjelder en fersk økt.

Bindingsrekkefølgen er bare halvparten. Klienten må også vite hvilke navn som hører til den adapteren, og det er et suffiksspørsmål, ikke et rekkefølgespørsmål.

Legg ipconfig /all fra den fungerende maskinen ved siden av den fra den bærbare maskinen, begge tatt mens tunnelen er oppe. Den fungerende maskinen vil vise et tilkoblingsspesifikt DNS-suffiks på kontoadapteren, og den bærbare maskinen kan vise ingen på tunnelen. Den forskjellen forklarer en hel klasse meldinger om at serveren er der og navnet likevel feiler, for uten suffiks blir det korte navnet aldri fullført til sonen kontoresolveren betjener.

Et kort navn trenger suffiks før det trenger rute

Å skrive et ukvalifisert vertsnavn ber resolveren gjette et domene. Gjetningen kommer fra suffikslisten som er knyttet til tilkoblingen, og hvis den listen er tom, går spørringen ut som én etikett som ingen privat sone vil matche.

Kopier suffikset fra den fungerende maskinen til VPN-adapterens IPv4-egenskaper på DNS-fanen, og koble til på nytt. På Linux er ekvivalenten søkedomenet på tunnellenken, som systemd-resolved viser per lenke i stedet for globalt.

Hold de to innstillingene atskilt i notatene. Et suffiks endrer hva som spørres om; resolveradressen endrer hvem som spørres. Å fikse den ene mens den andre er feil gir et resultat som virker tilfeldig.

Spør resolveren direkte først, så navnet

En direkte spørring til kontoresolveren skiller et navneproblem fra et ruteproblem, fordi den omgår klientens resolservalg helt.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Den første kommandoen ber en bestemt server om et fullt kvalifisert navn. Hvis den svarer, er resolveren og ruten dit i orden, og feilen ligger i valget eller suffikset. Hvis den timer ut, er adressen feil eller utilgjengelig, og problemet er ruting, ikke DNS. Den andre kommandoen viser hva som skjer med det korte navnet, og den tredje skriver ut resolverkonfigurasjonen per lenke på en systemd-vert.

Se opp for jokertegnsvar, som enkelte nettverk returnerer for ukjente navn. Et svar som ser rimelig ut er ikke bevis for at den tiltenkte serveren svarte, så sammenlign den returnerte adressen med den den interne tjenesten faktisk bruker. Hvis adressen tilhører en parkeringsside eller en proxy, svarte resolveren, men svaret var aldri ditt. Den forskjellen sparer en time med å jage en tunnel som fungerte hele tiden.

På Linux erstatter en VPN-klient som skriver om /etc/resolv.conf de lokale resolverne helt. vpnc tilbyr DNSUpdate no for å stoppe det, og systemd-resolved kan rute bare de oppgitte domenene til tunnellenken. Begge tilnærmingene holder offentlige navn hos den lokale resolveren mens interne navn sendes til kontoret.

Lekkasjer er en regel, ikke en avkrysningsboks

Navneoppslag er en UDP-utveksling til port 53, så en tunnel som bærer webtrafikk men ikke UDP, lar spørringen bli liggende på den fysiske veien. Bevis det ved å fange trafikk på det fysiske nettverkskortet mens et offentlig navn løses. En spørring som er synlig på det grensesnittet i lesbar form betyr at tunnelen ikke bærer den.

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

Hvis spørringen dukker opp på det grensesnittet i lesbar form, bærer ikke tunnelen den. Reparasjonen er en regel som tillater port 53 bare til resolveren VPN-en skjøv ut og forkaster andre destinasjoner, pluss en klientkonfigurasjon som ikke stille forkaster det påskutte alternativet.

Den siste delen betyr mer enn den ser ut som. Start OpenVPN med route-nopull, og det påskutte DNS-alternativet forsvinner sammen med rutene, med mindre pull-filteret utvides for å beholde det. En klient som ignorerer dhcp-option DNS, vil fortsette å bruke det den hadde før. Enhver endring på serversiden trenger en fersk økt for å virke, siden resolverlisten leveres når tunnelen kommer opp, og en gammel økt fortsetter å vise den gamle tilstanden.

Noter hvilken feil du faktisk observerte før du lukker saken. Et manglende internt svar og en spørring som rømmer fra tunnelen krever ulike reparasjoner, og en suffiksendring som fikser det første kan stille forverre det andre. Den som tar over saken neste gang vil stole på etiketten, så gjør etiketten nøyaktig.