Windows VPN DNS noplūde: kāpēc metrika pārspēj maršrutu

Vaicājums atstāj mašīnu un sasniedz mājas maršrutētāju, kamēr katrs pakets tiek tunelēts. Dabiskais secinājums ir trūkstošs maršruts, un maršruts parasti ir kārtībā. Windows var pēc saskarnes metrikas izvēlēties, kuras saskarnes risinātāju vaicāt, un tunelēšanas adapteris šajā salīdzinājumā bieži zaudē bezvadu saskarnei.

Divi skaidrojumi vienai noplūdei

Maršrutu skaidrojums saka, ka daļa trafika izbēg no tuneļa, tāpēc noklusējuma maršrutam vai sadalītā tuneļa sarakstam jābūt nepareizam. Šo skaidrojumu var pārbaudīt ar vienu komandu, un, kad noklusējuma maršruts rāda tunelī, jautājums ir noslēgts. Pārbaudiet to vispirms, jo tas ir lēti, un pēc tam nolieciet malā, kad tas atgriežas tīrs.

Sarindošanas skaidrojums saka, ka trafiks pilnībā ir tunelī un vaicājums tomēr tiek sūtīts citam risinātājam. Windows risinātāja izvēli uzskata par katras saskarnes īpašību ar secību, tāpēc fiziskais adapteris ar labāku metriku var nodrošināt DNS kādam vārdam, lai gan paketi uz atrisināto adresi iet pa tuneli. Abi skaidrojumi rada vienu un to pašu simptomu noplūdes testa lapā, tāpēc tests nav diagnoze. Tikai viens no tiem tiek salabots, rediģējot maršrutus.

Salīdziniet metrikas un risinātājus kopā

Pierakstiet saskarnes, to metrikas un konfigurētos serverus, kamēr tunelis ir aktīvs. Lasiet tos kā tabulu, nevis kā divus atsevišķus sarakstus, jo jautājums ir, kurš risinātājs ir pirmais, nevis kuri risinātāji pastāv.

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

Ja tunelēšanas adapterim ir lielāks skaitlis nekā fiziskajam adapterim, tā risinātājs nav prioritārs, un iekšējais vārds dosies uz to, ko piedāvā fiziskā puse. Tas maršrutētājs var atbildēt no kešatmiņas, pārsūtīt vaicājumu vai to noraidīt, un neviens no šiem iznākumiem nav tas dizains, ko jūs domājāt. Sarindošana ir priekšroka, tāpēc tā klusi zaudē, nevis izraisa kļūdu.

Tunelēšanas adapteris, kurā vispār nav konfigurēts risinātājs, ir tikpat izplatīts variants. Klients paceļ saskarni, neiespiežot DNS, tāpēc sarindošanas jautājums pat nevar rasties.

Paceliet tuneli augstāk un pārbaudiet vēlreiz

Piešķiriet tuneļa saskarnei zemāko metriku vai paaugstiniet fiziskā adaptera vērtību paaugstinātā čaulā. Abi ir iestatījumi katrai saskarnei, un abus var atgriezt, kas ir svarīgi, kad maināt mašīnu, pie kuras jūs, iespējams, nesēžat.

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

Izmaiņa ir redzama uzreiz, un DNS klients un citi patērētāji kešatmiņā saglabā jau izdarīto izvēli. Pieslēdziet tuneli no jauna vai restartējiet, pirms kaut ko nolasāt vaicājuma rezultātā. Pārāk agri palaists tests atkārtos veco uzvedību un izskatīsies kā neizdevies labojums.

Pēc tam pajautājiet vienu iekšēju un vienu publisku vārdu un pārbaudiet, kurš serveris atbildēja. Microsoft atsauce par automātiskajām metrikām skaidro, kāpēc priekšroka tiek dota zemākajai vērtībai un kā tiek iegūts automātiskais piešķīrums.

Padariet to noturīgu pret atkārtotu savienojumu

Manuāli iestatīta metrika adapterim, kas tiek izveidots no jauna katrā savienojumā, ir iestatījums, kas pazūd. Ja klients pārbūvē saskarni, šim pārrakstam vajadzīgs pēcsavienojuma skripts, politika vai klienta konfigurācija, kas savienojuma laikā pārvalda DNS.

Statiski konfigurēti serveri fiziskajā adapterī saskaras ar to pašu noturības problēmu otrādi. Tie turpina atbildēt par šo saskarni, līdz tos noņem, un DHCP tos atkal aizpildīs no nākamās nomas, tāpēc to noņemšana ir mērījums, nevis dizains. Noturīgais dizains ir vārdu atrisināšanas politika iekšējai vārdu telpai, vai klients, kas pārņem DNS visā savienojuma laikā. Jebkurā gadījumā pierakstiet risinātāju sarakstu pirms atkārtota savienojuma un pēc tā, atjaunojiet sākotnējo metriku, kad esat pabeidzis testēšanu, un apstipriniet, ka iepriekšējā uzvedība ir atgriezusies.