Windowsin VPN-DNS-vuoto: miksi metriikka voittaa reitin
Windows valitsee resolverin liitännän metriikan perusteella, ei vain reitin perusteella. Wi-Fiä alemmas sijoitettu tunnelisovitin voi vuotaa kyselyitä, vaikka jokainen paketti kulkee yhä tunnelin läpi.
Kysely lähtee koneesta ja saapuu kotireitittimelle, vaikka jokainen paketti tunneloidaan. Luonteva johtopäätös on puuttuva reitti, ja reitti on yleensä kunnossa. Windows voi valita liitännän metriikan perusteella, minkä liitännän resolvereilta kysytään, ja tunnelisovitin häviää tämän vertailun usein langattomalle.
Kaksi selitystä yhdelle vuodolle
Reittiselitys sanoo, että osa liikenteestä karkaa tunnelista, joten oletusreitin tai jaetun tunnelin luettelon täytyy olla väärä. Se selitys on testattavissa yhdellä komennolla, ja kun oletusreitti osoittaa tunneliin, se on selvitetty. Tarkista se ensin, koska se on halpaa, ja jätä se sitten sivuun, kun se palaa puhtaana.
Järjestysselitys sanoo, että liikenne on kokonaan tunnelissa ja kysely lähetetään silti toiselle resolverille. Windows kohtelee resolverin valintaa liitäntäkohtaisena ominaisuutena, jolla on järjestys, joten paremman metriikan fyysinen sovitin voi tarjota DNS:n nimelle, vaikka ratkaistun osoitteen paketit kulkevat tunnelin kautta. Molemmat selitykset tuottavat saman oireen vuototestisivulla, siksi testi ei ole diagnoosi. Vain toinen niistä korjataan reittejä muokkaamalla.
Vertaa metriikoita ja resolvereita yhdessä
Kirjaa liitännät, niiden metriikat ja määritetyt palvelimet, kun tunneli on päällä. Lue ne taulukkona, älä kahtena erillisenä luettelona, koska kysymys on siitä, mikä resolveri on ensimmäinen, ei siitä, mitä resolvereita on olemassa.
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses
Jos tunnelisovittimella on suurempi luku kuin fyysisellä sovittimella, sen resolveria ei suosita, ja sisäinen nimi menee sille, mitä fyysinen puoli tarjoaa. Se reititin voi vastata välimuistista, välittää kyselyn eteenpäin tai hylätä sen, eikä mikään noista tuloksista ole se suunnittelu, jonka tarkoitit. Järjestys on mieltymys, joten se häviää hiljaa sen sijaan että nostaisi virheen.
Tunnelisovitin, jolle ei ole määritetty lainkaan resolveria, on yhtä tavallinen muunnos. Asiakas nostaa liitännän työntämättä DNS:ää, joten järjestyskysymys ei edes nouse esiin.
Nosta tunneli järjestyksessä ja tarkista uudelleen
Anna tunneliliitännälle alhaisin metriikka tai nosta fyysisen sovittimen arvoa korotetussa komentotulkissa. Molemmat ovat liitäntäkohtaisia asetuksia ja molemmat ovat peruttavissa, millä on merkitystä, kun muutat konetta, jonka edessä et ehkä istu.
Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric
Muutos näkyy heti, ja DNS-asiakas sekä muut kuluttajat tallentavat jo tekemänsä valinnan välimuistiin. Yhdistä tunneli uudelleen tai käynnistä uudelleen ennen kuin luet mitään kyselyn tuloksesta. Liian aikaisin tehty testi toistaa vanhan käyttäytymisen ja näyttää epäonnistuneelta korjaukselta.
Kysy sitten yhtä sisäistä ja yhtä julkista nimeä ja tarkista, mikä palvelin vastasi. Microsoftin viite automaattisista metriikoista selittää, miksi alhaisinta arvoa suositaan ja miten automaattinen määritys johdetaan.
Tee siitä uudelleenyhdistämisen kestävä
Käsin asetettu metriikka sovittimelle, joka luodaan uudelleen joka yhteydellä, on asetus, joka katoaa. Jos asiakas rakentaa liitännän uudelleen, ohitus tarvitsee yhteyden jälkeisen skriptin, käytännön tai asiakasasetuksen, joka omistaa DNS:n yhteyden ajan.
Fyysiselle sovittimelle staattisesti määritetyillä palvelimilla on sama kestävyysongelma päinvastoin. Ne vastaavat kyseiselle liitännälle, kunnes ne poistetaan, ja DHCP täyttää ne uudelleen seuraavasta vuokrasta, joten niiden poistaminen on mittaus eikä suunnittelu. Kestävä suunnittelu on nimienratkaisukäytäntö sisäiselle nimiavaruudelle, tai asiakas, joka ottaa DNS:n haltuunsa yhteyden ajaksi. Joka tapauksessa kirjaa resolveriluettelo ennen uudelleenyhdistämistä ja sen jälkeen, palauta alkuperäinen metriikka, kun lopetat testaamisen, ja vahvista, että aiempi käyttäytyminen palasi.