Windows VPN verkeerde DNS-bediener: metriek, bindorde of agtervoegsel

'n Windows-kliënt kan 'n werkende tonnel hê, die korporatiewe resolveerder dra en steeds interne name na die tuisroeteerder stuur. Drie verskillende meganismes bepaal watter bediener antwoord, en hulle faal op verskillende maniere. Jy hoef nie al drie reg te maak nie: die simptoom sê vir jou watter een aan die werk is. Die besluitboom hieronder neem 'n paar minute en voorkom die gewone uitkoms, waar 'n metrieverandering, 'n herordening van die registering en 'n NRPT-reël saam land en niemand weet watter een iets gedoen het nie.

Drie meganismes besluit, en gewoonlik is een verkeerd

Die koppelvlakmetriek orden adapters vir 'n gegewe adresfamilie. Die bindingsorde onder Tcpip\Linkage is 'n masjienwye lys koppelvlak-identifiseerders wat ouer kodepaaie nog raadpleeg. Die Naamresolusie-beleidstabel (NRPT) bind 'n naamruimte aan spesifieke bedieners, en die agtervoegsellys besluit of 'n kort naam hoegenaamd uitgebrei word. Hulle is onafhanklik, en daarom verloor 'n korrekte resolveerder op die VPN-adapter teen 'n verouderde voorkeur elders.

Nie een van hierdie meganismes is die oorkant van die tonnel nie. As die bediener wat die VPN stoot die naam nie kan oplos nie, is elke kliëntkant-instelling net versiering, so die eerste besluit is of die resolveerder self kan antwoord wanneer jy dit direk vra.

Besluit een: kan die gestote resolveerder hoegenaamd antwoord?

Vra die bediener uitdruklik en vergelyk dit met 'n gewone opsoek. Die verskil tussen die antwoorde skei 'n seleksieprobleem van 'n bereikbaarheidsprobleem, en dit is die vinnigste vertakking hier:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

As die eerste slaag en die tweede misluk, is die resolveerder bereikbaar en kies Windows sleg; gaan na die naamruimte- en ordebesluite hieronder. As die eerste ook misluk, sal niks op die kliënt help nie: kyk of UDP en TCP 53 die bediener deur die tonnel bereik, of geen gasheer-firewall op die bediener die poel laat val nie, en of die bediener se eie aanstuurders gesond is.

Stop by hierdie vertakking. Om 'n NRPT-reël op 'n resolveerder toe te pas wat jy nie kan bereik nie, lewer dieselfde faling met meer konfigurasie om terug te draai, en dit verberg die werklike fout agter 'n reël wat gesaghebbend lyk.

Besluit twee: een naamruimte, of elke navraag?

Omvang bepaal die gereedskap. Wanneer net korporatiewe name misluk, bind die naamruimte eerder as om die masjien te herorden: 'n NRPT-reël stuur daardie agtervoegsel na die tonnel-resolveerder en laat alles anders ongemoeid. Wanneer elke opsoek geraak word, is die probleem globale adaptervoorkeur, en die metriek is die plek om te begin, want dit verander geen bedienerinstelling nie.

Stel die metriek per adresfamilie, op albei koppelvlakke, en bevestig daarna die ordening:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Vervang 11 met die tonnel-adapter se ifIndex uit die reël hierbo; as 11 die LAN-adapter is, verlaag dieselfde opdrag die verkeerde pad. Om eerder die LAN-adapter te verhoog bereik dieselfde ordening van die ander kant: netsh int ip set interface interface="Ethernet" metric=15, en netsh int ipv6 set interface interface="Ethernet" metric=15 vir die tweede familie, want int ip raak net IPv4.

Die bindingsorde is die laaste uitweg eerder as die eerste stap. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage hou 'n Bind-lys van toestel-identifiseerders, en om die tonnel-identifiseerder na die voorkant te skuif verander wel watter adapter eerste gevra word, maar dit is 'n masjienwye registerwaarde sonder per-naamruimte-omvang. Voer dit uit voordat jy redigeer, en verbind die tonnel daarna weer sodat die orde geld in die toestand wat die kliënt verwag.

Vir 'n enkele naamruimte, verkies die smaller instrument:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Besluit drie: oorleef die regstelling 'n herverbinding?

'n Metriek wat werk tot die volgende inbelverbinding weer koppel, is nooit bewaar nie. L2TP/IPsec en ander verbindingsprofiele word herskep wanneer die verbinding begin, so die gestoorde waarde leef in die telefoonboek-inskrywing as IpInterfaceMetric, nie net op die lewendige koppelvlak nie. Sommige omgewings skrip daardie veld juis om hierdie rede; ander stoot die voorkeur van bestuursbeleid af en laat die eindpunt alleen.

Kas en registrasie is 'n aparte laag. Om hierdie te laat loop nadat die tonnel opgekom het, maak verouderde inskrywings reg en registreer die kliënt weer, maar nie een van die twee herorden 'n adapter nie:

ipconfig /registerdns
ipconfig /flushdns

Daar is 'n afskakelaar in dieselfde laag. Om dinamiese registrasie op die fisiese adapter af te skakel, keer dat die kliënt sy VPN-kant-adres onder die verkeerde naam adverteer, wat 'n ander herstelling is as die verversing hierbo.

IPv6 verdien sy eie reël in die besluit. As die fisiese adapter 'n globale IPv6-adres het terwyl die tonnel net IPv4 dra, kan Windows die ongetonnelde pad vir naamresolusie verkies. Kontroleer daardie familie apart, want 'n metriek wat vir IPv4 gestel is, sê niks daaroor nie:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Om IPv6 op die LAN-adapter af te skakel, verwyder daardie pad en die protokol saam daarmee; 'n metrieverandering op die IPv6-koppelvlak, of 'n NRPT-reël vir die korporatiewe naamruimte, behou die familie en maak die voorkeur reg. Kies die smal een, tensy jy besluit het daardie skakel moenie IPv6 hê nie.

Verifieer met die bron genoem, en hou een eienaar

Verifieer met gereedskap wat rapporteer watter bron in werking is, nie bloot of 'n bladsy laai nie:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Skei dan filtering van seleksie, want hulle lyk identies vanuit 'n toepassing. OpenVPN se block-outside-dns blokkeer poort 53 op ander adapters; dit kies nie 'n resolveerder nie. As elke navraag nou misluk, blokkeer 'n filter dalk die enigste bereikbare bediener; as die gekonfigureerde resolveerder geïgnoreer word, is die orde of die naamruimte-reël verkeerd. Om albei gelyk te verander maak 'n geblokkeerde navraag en 'n geïgnoreerde navraag ononderskeibaar.

Hou een eienaar vir DNS-beleid: die VPN-profiel, 'n bestuursbeleid of 'n NRPT-reël, nie twee daarvan nie. Voordat jy dit afsluit:

• Die gestote resolveerder antwoord wanneer dit uitdruklik genoem word, en 'n gewone opsoek gebruik dit.
• Die reël of metriek wat jy verander het, dek die adresfamilie wat die navrae werklik dra.
• Die instelling oorleef 'n ontkoppeling en herverbinding, of jy het dit in die gestoorde profiel geskuif.
• Presies een meganisme is gesaghebbend, en die ander is gelaat soos hulle was.

Behandel die orde as omgewingstoestand eerder as iets wat jy afhandel. Hersien dit ná 'n herverbinding en ná 'n Windows-opdatering wat die netwerkstapel raak, want enige van die twee kan die fisiese adapter weer voor in die ry sit.