Neteisingas DNS serveris „Windows“ VPN: metrika, susiejimo tvarka ar priesaga
Trys „Windows“ mechanizmai renkasi DNS sprendėją, ir jie sugenda skirtingai. Spręskite pagal vardų srities apimtį, pasaulinę tvarką arba ar pataisa išlieka po pakartotinio prisijungimo.
„Windows“ klientas gali turėti veikiančią tunelio jungtį, nešti įmonės sprendėją ir vis tiek siųsti vidinius vardus į namų maršrutizatorių. Kuris serveris atsakys, sprendžia trys skirtingi mechanizmai, ir jie sugenda skirtingai. Visų trijų taisyti nereikia: simptomas pasako, kuris dalyvauja. Toliau pateiktas sprendimų medis užima kelias minutes ir užkerta kelią įprastai baigčiai, kai metrikos pakeitimas, registro pertvarkymas ir NRPT taisyklė atsiranda kartu ir niekas nežino, kuri iš jų ką nors paveikė.
Sprendžia trys mechanizmai, ir dažniausiai vienas yra neteisingas
Sąsajos metrika tvarko adapterius tam tikrai adresų šeimai. Susiejimo tvarka po Tcpip\Linkage yra visos mašinos sąsajų identifikatorių sąrašas, į kurį senesni kodo keliai vis dar atsižvelgia. Vardų skyrimo strategijos lentelė (NRPT) susieja vardų sritį su konkrečiais serveriais, o priesagų sąrašas nusprendžia, ar trumpas vardas apskritai išplečiamas. Jie nepriklausomi, todėl teisingas sprendėjas VPN adapteryje pralaimi pasenusiai nuostatai kitur.
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
Nė vienas šių mechanizmų nėra kita tunelio pusė. Jei serveris, kurį stumia VPN, negali išspręsti vardo, kiekvienas kliento pusės nustatymas tėra puošmena, tad pirmasis sprendimas yra ar pats sprendėjas gali atsakyti, kai jo klausiama tiesiogiai.
Pirmasis sprendimas: ar stumiamas sprendėjas apskritai gali atsakyti?
Paklauskite serverio tiesiogiai ir palyginkite su įprasta paieška. Skirtumas tarp atsakymų atskiria pasirinkimo problemą nuo pasiekiamumo problemos, ir tai čia greičiausia šaka:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type AJei pirmasis pavyksta, o antrasis nepavyksta, sprendėjas pasiekiamas ir „Windows“ renkasi blogai; eikite prie toliau pateiktų vardų srities ir tvarkos sprendimų. Jei ir pirmasis nepavyksta, kliente niekas nepadės: patikrinkite, ar UDP ir TCP 53 pasiekia serverį per tunelį, ar serverio pagrindinė užkarda neismeta baseino, ir ar paties serverio persiuntėjai sveiki.
Sustokite šioje šakoje. NRPT taisyklės taikymas sprendėjui, kurio nepasiekiate, duoda tą patį gedimą su daugiau atšaukiamos konfigūracijos, ir paslepia tikrą defektą už taisyklės, kuri atrodo autoritetinga.
Antrasis sprendimas: viena vardų sritis ar kiekviena užklausa?
Apimtis nulemia įrankį. Kai nepavyksta tik įmonės vardai, susiekite vardų sritį, o ne pertvarkykite mašiną: NRPT taisyklė siunčia tą priesagą tunelio sprendėjui ir palieka visa kita ramybėje. Kai paveikta kiekviena paieška, problema yra pasaulinė adapterių nuostata, ir metrika yra vieta, nuo kurios pradėti, nes ji nekeičia jokio serverio nustatymo.
Nustatykite metriką kiekvienai adresų šeimai, abiejose sąsajose, ir tada patvirtinkite tvarką:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6Pakeiskite 11 tunelio adapterio ifIndex reikšme iš aukščiau esančios eilutės; jei 11 yra LAN adapteris, ta pati komanda nuleidžia neteisingą kelią. Jei pakelsite LAN adapterį, pasieksite tą pačią tvarką iš kitos pusės: netsh int ip set interface interface="Ethernet" metric=15, o antrajai šeimai netsh int ipv6 set interface interface="Ethernet" metric=15, nes int ip liečia tik IPv4.
Susiejimo tvarka yra paskutinė priemonė, o ne pirmas žingsnis. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage laiko įrenginių identifikatorių Bind sąrašą, ir tunelio identifikatoriaus perkėlimas į priekį tikrai pakeičia, kurio adapterio klausiama pirmiausia, bet tai visos mašinos registro reikšmė be apimties pagal vardų sritį. Eksportuokite ją prieš redaguodami ir po to iš naujo prijunkite tunelį, kad tvarka galiotų toje būsenoje, kurios tikisi klientas.
Vienai vardų sričiai teikite pirmenybę siauresniam įrankiui:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersTrečiasis sprendimas: ar pataisa išlieka po pakartotinio prisijungimo?
Metrika, kuri veikia iki kito sujungimo telefonu, niekada nebuvo išsaugota. L2TP/IPsec ir kiti ryšio profiliai sukuriami iš naujo, kai ryšys prasideda, todėl išsaugota reikšmė gyvena telefono knygos įraše kaip IpInterfaceMetric, ne tik aktyvioje sąsajoje. Kai kurios aplinkos tą lauką skriptuoja būtent todėl; kitos stumia nuostatą iš valdymo strategijos ir palieka galinį tašką ramybėje.
Podėlis ir registracija yra atskiras sluoksnis. Jų paleidimas po tunelio pakilimo pataiso pasenusius įrašus ir iš naujo registruoja klientą, bet nė vienas nepertvarko adapterio:
ipconfig /registerdns
ipconfig /flushdnsTame pačiame sluoksnyje yra išjungiklis. Dinaminės registracijos išjungimas fiziniame adapteryje neleidžia klientui skelbti savo VPN pusės adreso neteisingu vardu, ir tai kitokia pataisa nei aukščiau aprašytas atnaujinimas.
IPv6 sprendime nusipelno atskiros eilutės. Jei fizinis adapteris turi pasaulinį IPv6 adresą, o tunelis perduoda tik IPv4, „Windows“ gali teikti pirmenybę keliui be tunelio vardų skyrimui. Patikrinkite tą šeimą atskirai, nes IPv4 nustatyta metrika apie ją nieko nesako:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricIPv6 išjungimas LAN adapteryje pašalina tą kelią ir protokolą kartu su juo; metrikos pakeitimas IPv6 sąsajoje arba NRPT taisyklė įmonės vardų sričiai išsaugo šeimą ir ištaiso nuostatą. Rinkitės siauresnį, nebent nusprendėte, kad ta jungtis neturėtų turėti IPv6.
Tikrinkite su įvardytu šaltiniu ir laikykitės vieno savininko
Tikrinkite įrankiais, kurie praneša, kuris šaltinis galioja, o ne tik ar puslapis įkeliamas:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type ATada atskirkite filtravimą nuo pasirinkimo, nes programos viduje jie atrodo vienodai. „OpenVPN“ parinktis block-outside-dns blokuoja 53 prievadą kituose adapteriuose; ji nerenka sprendėjo. Jei dabar nepavyksta kiekviena užklausa, filtras gali blokuoti vienintelį pasiekiamą serverį; jei sukonfigūruotas sprendėjas ignoruojamas, tvarka arba vardų srities taisyklė neteisinga. Abiejų keitimas iš karto daro blokuotą užklausą ir ignoruotą užklausą neatskiriamas.
Laikykitės vieno DNS strategijos savininko: VPN profilis, valdymo strategija arba NRPT taisyklė, o ne du iš jų. Prieš užbaigdami:
- Stumiamas sprendėjas atsako, kai įvardijamas tiesiogiai, ir įprasta paieška juo naudojasi.
- Pakeista taisyklė ar metrika apima tą adresų šeimą, kuri iš tikrųjų perduoda užklausas.
- Nustatymas išlieka po atjungimo ir pakartotinio prisijungimo, arba perkėlėte jį į išsaugotą profilį.
- Autoritetingas yra tiksliai vienas mechanizmas, o kiti palikti tokie, kokie buvo.
Traktuokite tvarką kaip aplinkos būseną, o ne kaip dalyką, kurį pabaigsite. Patikrinkite ją dar kartą po pakartotinio prisijungimo ir po „Windows“ atnaujinimo, kuris liečia tinklo kamino dalį, nes bet kuris iš jų gali vėl iškelti fizinį adapterį į priekį.