Windows VPN DNS nuotėkis: kodėl metrika nugali maršrutą

Užklausa palieka mašiną ir pasiekia namų maršrutizatorių, nors kiekvienas paketas tuneliuojamas. Natūrali išvada yra trūkstamas maršrutas, o maršrutas paprastai būna tvarkingas. Windows gali pagal sąsajos metriką pasirinkti, kurios sąsajos sprendėjo klausti, ir tunelio adapteris dažnai pralaimi šį palyginimą belaidžiai sąsajai.

Du vieno nuotėkio paaiškinimai

Maršrutų paaiškinimas sako, kad dalis srauto ištrūksta iš tunelio, tad numatytasis maršrutas arba padalyto tunelio sąrašas turi būti neteisingi. Tą paaiškinimą galima patikrinti viena komanda, o kai numatytasis maršrutas rodo į tunelį, klausimas baigtas. Patikrinkite jį pirmiausia, nes tai pigu, o paskui atidėkite, kai jis grįš švarus.

Rikiavimo paaiškinimas sako, kad srautas visas tunelyje, o užklausa vis tiek siunčiama kitam sprendėjui. Windows sprendėjo pasirinkimą traktuoja kaip kiekvienos sąsajos savybę su tvarka, todėl fizinis adapteris su geresne metrika gali tiekti DNS vardui, nors paketai į išspręstą adresą keliauja tuneliu. Abu paaiškinimai sukuria tą patį simptomą nuotėkio testo puslapyje, todėl testas nėra diagnozė. Tik vienas jų pataisomas redaguojant maršrutus.

Palyginkite metrikas ir sprendėjus kartu

Užrašykite sąsajas, jų metrikas ir sukonfigūruotus serverius, kol tunelis veikia. Skaitykite juos kaip lentelę, o ne kaip du atskirus sąrašus, nes klausimas yra kuris sprendėjas pirmas, o ne kurie sprendėjai egzistuoja.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Jei tunelio adapteris turi didesnį skaičių nei fizinis adapteris, jo sprendėjas nėra pageidaujamas, ir vidinis vardas eis ten, ką siūlo fizinė pusė. Tas maršrutizatorius gali atsakyti iš podėlio, persiųsti užklausą arba jos atsisakyti, ir nė viena iš šių baigčių nėra ta konstrukcija, kurios norėjote. Rikiavimas yra nuostata, todėl jis tyliai pralaimi, o ne iškelia klaidą.

Tunelio adapteris, kuriame visai nesukonfigūruotas sprendėjas, yra toks pat dažnas variantas. Klientas pakelia sąsają nepastūmęs DNS, todėl rikiavimo klausimas net nekyla.

Pakelkite tunelį ir patikrinkite dar kartą

Suteikite tunelio sąsajai mažiausią metriką arba padidinkite fizinio adapterio reikšmę padidintų teisių apvalkale. Abi yra kiekvienos sąsajos nuostatos ir abi yra grąžinamos, o tai svarbu, kai keičiate mašiną, prie kurios galbūt nesėdite.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

Pakeitimas matomas iš karto, o DNS klientas ir kiti vartotojai kaupia jau padarytą pasirinkimą. Prijunkite tunelį iš naujo arba paleiskite iš naujo, prieš ką nors darydami iš užklausos rezultato. Per anksti paleistas testas atkartos seną elgseną ir atrodys kaip nepavykęs taisymas.

Tada paklauskite vieno vidinio ir vieno viešo vardo ir patikrinkite, kuris serveris atsakė. Microsoft nuoroda apie automatines metrikas paaiškina, kodėl pirmenybė teikiama mažiausiai reikšmei ir kaip išvedamas automatinis priskyrimas.

Padarykite jį atsparų pakartotiniam prisijungimui

Rankiniu būdu nustatyta metrika adapteriui, kuris atkuriamas po kiekvieno prisijungimo, yra nuostata, kuri išnyksta. Jei klientas atkuria sąsają, šiam perrašymui reikia prisijungimo pabaigos scenarijaus, taisyklės arba kliento konfigūracijos, kuri prisijungimo metu valdo DNS.

Statiškai sukonfigūruoti serveriai fiziniame adapteryje turi tą pačią patvarumo problemą atvirkščiai. Jie toliau atsakinėja už tą sąsają, kol bus pašalinti, o DHCP juos vėl užpildys iš kitos nuomos, tad jų pašalinimas yra matavimas, o ne konstrukcija. Patvari konstrukcija yra vardų sprendimo taisyklė vidinei vardų erdvei, arba klientas, kuris perima DNS visam prisijungimo laikui. Bet kuriuo atveju užrašykite sprendėjų sąrašą prieš pakartotinį prisijungimą ir po jo, atkurkite pradinę metriką, kai baigsite testuoti, ir patvirtinkite, kad ankstesnė elgsena grįžo.