Windowsi VPN-i DNS-leke: miks mõõdik alistab marsruudi

Päring lahkub masinast ja jõuab koju ruuterini, samal ajal kui iga pakett käib läbi tunneli. Loomulik järeldus on puuduv marsruut, ja marsruut on tavaliselt korras. Windows saab liidese mõõdiku järgi valida, millise liidese resolverilt küsida, ja tunneladapter kaotab selle võrdluse tihti traadita liidesele.

Üks leke, kaks seletust

Marsruudiseletus ütleb, et osa liiklusest pääseb tunnelist välja, seega peavad vaikemarsruut või jaotatud tunneli loend olema valed. Seda seletust saab kontrollida ühe käsuga, ja kui vaikemarsruut osutab tunnelisse, on see lahendatud. Kontrollige seda kõigepealt, sest see on odav, ja pange see siis kõrvale, kui see puhtana tagasi tuleb.

Järjestusseletus ütleb, et liiklus on täielikult tunnelis ja päring saadetakse ikkagi teisele resolverile. Windows käsitleb resolveri valikut iga liidese omadusena, millel on järjekord, seega parema mõõdikuga füüsiline adapter saab anda nimele DNS-i, kuigi lahendatud aadressi paketid liiguvad läbi tunneli. Mõlemad seletused tekitavad lekke testilehel sama sümptomi, seetõttu ei ole test diagnoos. Ainult üks neist parandatakse marsruutide muutmisega.

Võrrelge mõõdikuid ja resolvereid koos

Kirjutage liidesed, nende mõõdikud ja seadistatud serverid üles, kui tunnel töötab. Lugege neid tabelina, mitte kahe eraldi loendina, sest küsimus on selles, milline resolver on esimene, mitte selles, millised resolverid olemas on.

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

Kui tunneladapteril on suurem number kui füüsilisel adapteril, ei ole selle resolver eelistatud ja sisemine nimi läheb sinna, mida füüsiline pool pakub. See ruuter võib vastata vahemälust, päringu edasi saata või selle tagasi lükata, ja ükski neist tulemustest ei ole see kavand, mida te kavatsesite. Järjestus on eelistus, seega kaotab see vaikselt, selle asemel et viga tekitada.

Tunneladapter, millel pole üldse resolverit seadistatud, on sama tavaline variant. Klient tõstab liidese üles ilma DNS-i surumata, seega järjestuse küsimus ei tekigi.

Tõstke tunnel ettepoole ja kontrollige uuesti

Andke tunneliliidesele madalaim mõõdik või tõstke füüsilise adapteri väärtust kõrgendatud kestas. Mõlemad on liidesepõhised seaded ja mõlemad on tagasipööratavad, mis loeb siis, kui muudate masinat, mille ees te ehk ei istu.

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

Muudatus on kohe näha ning DNS-klient ja teised tarbijad vahemällu salvestavad juba tehtud valiku. Ühendage tunnel uuesti või taaskäivitage, enne kui päringu tulemusest midagi järeldate. Liiga vara tehtud test kordab vana käitumist ja näeb välja nagu ebaõnnestunud parandus.

Seejärel küsige üht sisemist ja üht avalikku nime ning kontrollige, milline server vastas. Microsofti viide automaatsete mõõdikute kohta selgitab, miks madalaim väärtus on eelistatud ja kuidas automaatne määramine tuletatakse.

Tehke see ühenduse taastamisele vastupidavaks

Käsitsi seatud mõõdik adapteril, mis luuakse iga ühenduse korral uuesti, on seade, mis kaob. Kui klient liidese uuesti üles ehitab, vajab see ülekirjutus ühendusjärgset skripti, poliitikat või kliendi seadistust, mis omab DNS-i ühenduse ajal.

Füüsilisel adapteril staatiliselt seadistatud serveritel on sama vastupidavusprobleem vastupidises suunas. Need vastavad selle liidese eest seni, kuni need eemaldatakse, ja DHCP täidab need järgmisest rendist uuesti, seega on nende eemaldamine mõõtmine, mitte kavand. Vastupidav kavand on sisemise nimeruumi nimelahenduse poliitika või klient, mis võtab DNS-i üle ühenduse kestuse ajaks. Igal juhul kirjutage resolverite loend enne ja pärast ühenduse taastamist üles, taastage algne mõõdik, kui testimise lõpetate, ja kinnitage, et varasem käitumine naasis.