VPN overtog DNS og brød lokale navne: ret listen

Tunnelen kommer op, intranettet indlæses, og printerens navn holder op med at slå op. Eller omvendt: lokale navne virker stadig, mens alt inde i virksomhedsnetværket løber ud. Begge symptomer kommer samme sted fra, en resolverliste som VPN-klienten skrev om, da den koblede til.

Ret listen bevidst, og tag derefter push-mekanismen særskilt. Ruter er et tredje emne og ikke det, der rettes her.

Hvilken liste programmer faktisk bruger

Windows slår op via indstillinger på grænsefladeniveau i stedet for via det, en dialog viser, så start med de effektive lister per grænseflade. Aliaset betyder mere end det viste navn, fordi hver kommando nedenfor henvender sig til en grænseflade. Tager du fejl af aliaset, lander rettelsen på den forkerte adapter. Det vil se ud til at virke indtil næste genopkobling, hvor tunnelens egen post vender tilbage.

Spørgsmålet er, hvilke servere der endte forrest, og om de kom som statiske poster eller som en DHCP-lease. Begge fakta afgør, hvilken rettelse du har til rådighed.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Læs outputtet for tunneladapteren og for den fysiske adapter, og notér hver adresse på hver af dem. En statisk post kan fjernes af en politik eller et script; en DHCP-leveret post er bundet til leasen og vender tilbage, hvilket ændrer den rettelse, du bør vælge. Navne i fjernnetværket slås op af den annoncerede resolver, navne på det lokale LAN af den fysiske adapter, og forespørgslen går til den liste, der konsulteres først.

Fjern de push'ede servere, eller rangér dem lavere

Slet de push'ede servere, når intet inde i tunnelen har brug for dem, fordi den fysiske adapters egne resolvere tager over igen. Behold dem kun, hvis fjernnetværket ejer zoner, som kun dets servere kan svare på, og i så fald skal du sætte en lokal resolver foran dem. De to kommandoer nedenfor dækker begge valg, så vælg den, der passer til situationen, i stedet for at køre begge.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Indeks 1 konsulteres først, så de push'ede adresser forbliver tilgængelige, men holder op med at være standardsvaret på hver forespørgsel. Flaget validate=no springer en tilgængelighedstest over, som ofte fejler, mens tunnelen stadig falder til, så bekræft resultatet med show-kommandoen i stedet for at stole på exitkoden.

To grænser er værd at kende, før du stoler på dette. Windows sletter ikke servere, der kom over DHCP gennem netsh, og disse værdier består som DhcpNameServer under grænsefladens registreringsnøgle, så en registreringsændring er en sidste udvej, der skal tjekkes igen efter den næste lease. Adapterbindingens rækkefølge er heller ikke en pålidelig rangeringsmekanisme, fordi en VPN-klient kan indsætte sin egen post øverst på listen.

Hvor push kan filtreres

En bedre rettelse fjerner valgmuligheden, før den anvendes. Community OpenVPN-klienten kan filtrere et push'et direktiv efter navn, hvilket holder serverens konfiguration urørt.

pull-filter ignore "dhcp-option DNS "

Det afsluttende mellemrum hører til matchningen, og filteret navngiver valgmuligheden frem for en serveradresse. Hvis profilen også indeholder et block-outside-dns-direktiv, ændrer fjernelsen af det lækbeskyttelsen frem for navneopslag, så afgør det separat i stedet for at slå de to ændringer sammen.

For et enkelt stædigt værtsnavn er én linje i Windows hosts-filen mere stabilt end at omarrangere resolvere for hele maskinen. Det er også usynligt for den næste person, så notér det, hvor maskinens konfiguration dokumenteres.

Få rettelsen til at overleve en genopkobling

Navneopslag skal testes to gange, én gang mod en valgt server og én gang i den form, et program bruger. Det par adskiller et resolver-rækkefølgeproblem fra en server, der slet ikke svarer. Springes den første test over, bliver de to årsager filtret sammen.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Genopkobl tunnelen, og gentag begge kommandoer. Alt, hvad du har ændret manuelt, holder kun til næste forbindelse, fordi klienten genopbygger sin resolvertilstand, mens den rejser adapteren. Sæt netsh-linjerne i det understøttede forbindelsesscript til din klient, lad scriptet afslutte med succes, og tilføj en kort pause, før det kører. En klient, der anvender DNS efter scriptet, overskriver resultatet alligevel.

Hvis offentlige navne slås op, og interne stadig fejler efter rettelsen, er resolverlisten ikke længere den mistænkte. Forespørgslen når sandsynligvis slet ikke serveren, hvilket peger på routing eller en firewallregel frem for endnu en DNS-indstilling. Notér grænsefladealiaset og de adresser, du endte med, fordi begge varierer mellem maskiner, og ingen af dem overlever en genopbygning alene.