VPN het DNS oorgeneem en plaaslike name gebreek: herstel die lys

Die tonnel kom op, die intranet laai, en die drukker se naam hou op om opgelos te word. Of andersom: plaaslike name werk steeds terwyl alles binne die korporatiewe netwerk uittyd. Albei simptome kom van dieselfde plek, 'n oplosserlys wat die VPN-kliënt herskryf het toe dit verbind het.

Herstel die lys doelbewus en hanteer dan die stootmeganisme afsonderlik. Roetes is 'n derde onderwerp en nie die een wat hier reggemaak word nie.

Watter lys programme werklik gebruik

Windows los op deur instellings op koppelvlakvlak eerder as deur wat 'n dialoog ook al wys, so begin met die effektiewe lyste per koppelvlak. Die alias saak maak meer as die vertoonnaam, want elke opdrag hieronder rig hom tot 'n koppelvlak. Kry die alias verkeerd en die herstel beland op die verkeerde adapter. Dit sal lyk of dit werk tot die volgende herverbinding, wanneer die tonnel se eie inskrywing terugkeer.

Die vraag is watter bedieners vooraan beland het, en of hulle as statiese inskrywings of as 'n DHCP-huurkontrak gekom het. Albei feite bepaal watter herstel vir jou beskikbaar is.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Lees die uitset vir die tonneladapter en vir die fisiese een, en let op elke adres op elkeen. 'n Statiese inskrywing kan deur 'n beleid of 'n skrip verwyder word; een wat deur DHCP verskaf is, is aan die huurkontrak gebind en sal terugkeer, wat die herstel verander wat jy moet kies. Name in die afgeleë netwerk los op vanaf die geadverteerde oplosser, name op die plaaslike LAN vanaf die fisiese een, en die navraag gaan na watter lys eerste geraadpleeg word.

Verwyder die gestote bedieners, of rangskik hulle laer

Skrap die gestote bedieners wanneer niks binne die tonnel hulle nodig het nie, want die fisiese adapter se eie oplossers neem weer oor. Hou hulle net as die afgeleë netwerk sones besit wat sy bedieners alleen kan antwoord, en plaas in daardie geval 'n plaaslike oplosser voor hulle. Die twee opdragte hieronder dek albei keuses, so kies die een wat by die situasie pas eerder as om albei uit te voer.

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 word eerste geraadpleeg, so die gestote adresse bly beskikbaar maar hou op om die verstekantwoord vir elke navraag te wees. Die validate=no-vlag slaan 'n bereikbaarheidstoets oor wat dikwels misluk terwyl die tonnel nog besig is om te stabiliseer, so bevestig die resultaat met die show-opdrag eerder as om die uitgangskode te vertrou.

Twee beperkings is die moeite werd om te ken voordat jy hierop staatmaak. Windows sal nie bedieners skrap wat oor DHCP deur netsh gekom het nie, en daardie waardes bly as DhcpNameServer onder die koppelvlak se registersleutel voort, so 'n registerwysiging is 'n laaste uitweg wat ná die volgende huurkontrak weer nagegaan moet word. Adapterbindingsorde is ook nie 'n betroubare rangskikkingsmeganisme nie, want 'n VPN-kliënt kan sy eie inskrywing boaan die lys invoeg.

Waar die stoot gefiltreer kan word

'n Beter herstel verwyder die opsie voordat dit toegepas word. Die Community OpenVPN-kliënt kan 'n gestote direktief by naam filtreer, wat die bediener se konfigurasie onaangeraak laat.

pull-filter ignore "dhcp-option DNS "

Die spasie aan die einde hoort by die passing en die filter noem die opsie eerder as 'n bedieneradres. As die profiel ook 'n block-outside-dns-direktief bevat, verander die verwydering daarvan lekbeskerming eerder as naamoplossing, so besluit dit afsonderlik eerder as om die twee wysigings saam te bundel.

Vir 'n enkele hardnekkige gasheernaam is een reël in die Windows hosts-lêer standvastiger as om oplossers vir die hele masjien te herrangskik. Dit is ook onsigbaar vir die volgende persoon, so teken dit aan waar die masjien se konfigurasie ook al gedokumenteer is.

Maak die herstel 'n herverbinding oorleef

Naamoplossing moet twee keer getoets word, een keer teen 'n gekose bediener en een keer in die vorm wat 'n toepassing gebruik. Daardie paar skei 'n oplosserorde-probleem van 'n bediener wat glad nooit antwoord nie. Om die eerste toets oor te slaan laat die twee oorsake verstrengel.

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

Verbind die tonnel weer en herhaal albei opdragte. Wat jy met die hand verander het, oorleef net tot die volgende verbinding, want die kliënt bou sy oplosserstatus weer op terwyl dit die adapter opbring. Sit die netsh-lyne in die ondersteunde verbindingskrip vir jou kliënt, laat daardie skrip suksesvol afsluit, en voeg 'n kort wagtyd by voordat dit uitgevoer word. 'n Kliënt wat DNS ná die skrip toepas, sal die resultaat in elk geval oorskryf.

As publieke name oplos en interne name ná die herstel steeds misluk, het die oplosserlys opgehou om die verdagte te wees. Die navraag bereik waarskynlik glad nie die bediener nie, wat op roetering of 'n firewall-reël dui eerder as op nog 'n DNS-instelling. Teken die koppelvlakalias en die adresse waarop jy besluit het aan, want albei verskil tussen masjiene en nie een oorleef 'n herbou op sy eie nie.