VPN tok over DNS og ødela lokale navn: reparer listen

Tunnelen kommer opp, intranettet lastes, og skrivernavnet slutter å slås opp. Eller motsatt: lokale navn virker fortsatt mens alt inne i bedriftsnettet går ut på tid. Begge symptomene kommer fra samme sted, en resolverliste som VPN-klienten skrev om da den koblet til.

Reparer listen bevisst, og håndter deretter push-mekanismen separat. Ruter er et tredje tema og ikke det som repareres her.

Hvilken liste programmene faktisk bruker

Windows slår opp via innstillinger på grensesnittnivå og ikke via det en dialog viser, så start med de effektive listene per grensesnitt. Aliaset betyr mer enn det viste navnet, fordi hver kommando nedenfor henvender seg til et grensesnitt. Tar du feil av aliaset, lander reparasjonen på feil adapter. Det vil se ut til å virke til neste tilkobling, når tunnelens egen oppføring kommer tilbake.

Spørsmålet er hvilke servere som havnet foran, og om de kom som statiske oppføringer eller som DHCP-lease. Begge fakta avgjør hvilken reparasjon du har til rådighet.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Les utdataene for tunneladapteren og for den fysiske, og noter hver adresse på hver av dem. En statisk oppføring kan fjernes av en policy eller et skript; en DHCP-levert oppføring er bundet til leasen og kommer tilbake, noe som endrer reparasjonen du bør velge. Navn i fjernnettet slås opp av den annonserte resolveren, navn på det lokale LAN-et av den fysiske adapteren, og spørringen går til den listen som konsulteres først.

Fjern de push-ede serverne, eller ranger dem lavere

Slett de push-ede serverne når ingenting inne i tunnelen trenger dem, fordi den fysiske adapterens egne resolvere tar over igjen. Behold dem bare hvis fjernnettet eier soner som bare serverne der kan svare på, og i så fall sett en lokal resolver foran dem. De to kommandoene nedenfor dekker begge valgene, så velg den som passer situasjonen i stedet for å kjø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 adressene forblir tilgjengelige men slutter å være standardsvaret på hver spørring. Flagget validate=no hopper over en tilgjengelighetstest som ofte feiler mens tunnelen fortsatt faller til ro, så bekreft resultatet med show-kommandoen i stedet for å stole på utgangskoden.

To grenser er verdt å kjenne før du stoler på dette. Windows sletter ikke servere som kom over DHCP gjennom netsh, og disse verdiene består som DhcpNameServer under registreringsnøkkelen til grensesnittet, så en registerendring er en siste utvei som må sjekkes på nytt etter neste lease. Adapterbindingsrekkefølgen er heller ikke en pålitelig rangeringsmekanisme, fordi en VPN-klient kan sette inn sin egen oppføring øverst i listen.

Hvor push kan filtreres

En bedre reparasjon fjerner valget før det brukes. Community OpenVPN-klienten kan filtrere et push-et direktiv etter navn, noe som lar serverens konfigurasjon være urørt.

pull-filter ignore "dhcp-option DNS "

Mellomrommet på slutten hører til treffet, og filteret navngir valget og ikke en serveradresse. Hvis profilen også inneholder et block-outside-dns-direktiv, endrer fjerningen av det lekkasjebeskyttelsen og ikke navneoppslaget, så avgjør det separat i stedet for å slå de to endringene sammen.

For ett enkelt gjenstridig vertsnavn er én linje i Windows hosts-fil mer stabilt enn å omorganisere resolvere for hele maskinen. Det er også usynlig for den neste personen, så noter det der maskinens konfigurasjon dokumenteres.

Få reparasjonen til å overleve en ny tilkobling

Navneoppslaget må testes to ganger, én gang mot en valgt server og én gang i den formen et program bruker. Det paret skiller et resolver-rekkefølgeproblem fra en server som ikke svarer i det hele tatt. Hopper du over den første testen, blir de to årsakene filtret sammen.

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

Koble til tunnelen på nytt og gjenta begge kommandoene. Det du endret manuelt varer bare til neste tilkobling, fordi klienten bygger opp resolvertilstanden på nytt mens den reiser adapteren. Sett netsh-linjene i det støttede tilkoblingsskriptet til klienten din, la skriptet avslutte med suksess, og legg til en kort ventetid før det kjøres. En klient som bruker DNS etter skriptet, overskriver resultatet uansett.

Hvis offentlige navn slås opp og interne fortsatt feiler etter reparasjonen, er resolverlisten ikke lenger den mistenkte. Spørringen når sannsynligvis ikke serveren i det hele tatt, noe som peker på ruting eller en brannmurregel og ikke på nok en DNS-innstilling. Noter grensesnittaliaset og adressene du endte på, fordi begge varierer mellom maskiner og ingen av dem overlever en gjenoppbygging alene.