VPN tok over DNS og braut lokale namn: reparer lista

Tunnelen kjem opp, intranettet lastar, og skrivarnamnet sluttar å slåast opp. Eller motsett: lokale namn verkar framleis medan alt inne i bedriftsnettet går ut på tid. Begge symptoma kjem frå same stad, ei resolverliste som VPN-klienten skreiv om då han kopla til.

Reparer lista medvite, og handsame deretter push-mekanismen separat. Ruter er eit tredje tema og ikkje det som blir reparert her.

Kva liste programma faktisk brukar

Windows slår opp via innstillingar på grensesnittnivå og ikkje via det ein dialog viser, så start med dei effektive listene per grensesnitt. Aliaset tyder meir enn det viste namnet, fordi kvar kommando nedanfor vender seg til eit grensesnitt. Tek du feil av aliaset, landar reparasjonen på feil adapter. Det vil sjå ut til å verke til neste tilkopling, når den eigne oppføringa til tunnelen kjem tilbake.

Spørsmålet er kva tenarar som hamna framst, og om dei kom som statiske oppføringar eller som DHCP-leige. Begge fakta avgjer kva reparasjon du har til rådvelde.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Les utdataa for tunneladapteren og for den fysiske, og noter kvar adresse på kvar av dei. Ei statisk oppføring kan fjernast av ein policy eller eit skript; ei DHCP-levert oppføring er bunden til leiga og kjem tilbake, noko som endrar reparasjonen du bør velje. Namn i fjernnettet blir slått opp av den annonserte resolveren, namn på det lokale LAN-et av den fysiske adapteren, og spørjinga går til den lista som blir konsultert først.

Fjern dei pusha tenarane, eller ranger dei lågare

Slett dei pusha tenarane når ingenting inne i tunnelen treng dei, fordi dei eigne resolverane til den fysiske adapteren tek over igjen. Hald dei berre dersom fjernnettet eig soner som berre tenarane der kan svare på, og i så fall set ein lokal resolver framfor dei. Dei to kommandoane nedanfor dekkjer begge vala, så vel den som passar situasjonen i staden for å køyre 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 blir konsultert først, så dei pusha adressene blir verande tilgjengelege men sluttar å vere standardsvaret på kvar spørjing. Flagget validate=no hoppar over ein tilgjengelegheitstest som ofte feilar medan tunnelen framleis fell til ro, så stadfest resultatet med show-kommandoen i staden for å stole på utgangskoden.

To grenser er verd å kjenne før du stolar på dette. Windows slettar ikkje tenarar som kom over DHCP gjennom netsh, og desse verdiane blir verande som DhcpNameServer under registreringsnøkkelen til grensesnittet, så ei registerendring er ei siste utveg som må sjekkast på nytt etter neste leige. Adapterbindingsrekkjefølgja er heller ikkje ein påliteleg rangeringsmekanisme, fordi ein VPN-klient kan setje inn si eiga oppføring øvst i lista.

Kvar push kan filtrerast

Ein betre reparasjon fjernar valet før det blir brukt. Community OpenVPN-klienten kan filtrere eit pusha direktiv etter namn, noko som lèt konfigurasjonen til tenaren vere urørt.

pull-filter ignore "dhcp-option DNS "

Mellomrommet på slutten høyrer til treffet, og filteret namngir valet og ikkje ei tenaradresse. Dersom profilen òg inneheld eit block-outside-dns-direktiv, endrar fjerninga av det lekkasjevernet og ikkje namneoppslaget, så avgjer det separat i staden for å slå dei to endringane saman.

For eitt einaste gjenstridig vertsnamn er éi line i Windows hosts-fil meir stabilt enn å omorganisere resolverar for heile maskinen. Det er òg usynleg for den neste personen, så noter det der konfigurasjonen til maskinen blir dokumentert.

Få reparasjonen til å overleve ei ny tilkopling

Namneoppslaget må testast to gonger, éin gong mot ein vald tenar og éin gong i den forma eit program brukar. Det paret skil eit resolver-rekkjefølgjeproblem frå ein tenar som ikkje svarar i det heile. Hoppar du over den første testen, blir dei to årsakene filtra saman.

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

Kopla til tunnelen på nytt og gjenta begge kommandoane. Det du endra manuelt varer berre til neste tilkopling, fordi klienten byggjer opp resolvertilstanden på nytt medan han reiser adapteren. Set netsh-linjene i det støtta tilkoplingsskriptet til klienten din, lèt skriptet avslutte med suksess, og legg til ei kort ventetid før det blir køyrt. Ein klient som brukar DNS etter skriptet, overskriv resultatet uansett.

Dersom offentlege namn blir slått opp og interne framleis feilar etter reparasjonen, er resolverlista ikkje lenger den mistenkte. Spørjinga når truleg ikkje tenaren i det heile, noko som peikar på ruting eller ein brannmurregel og ikkje på nok ei DNS-innstilling. Noter grensesnittaliaset og adressene du enda på, fordi begge varierer mellom maskinar og ingen av dei overlever ein gjenoppbygging åleine.