Windows VPN DNS curenje: zašto metrika pobjeđuje rutu

Upit napušta računar i stiže do kućnog rutera dok se svaki paket tunelira. Prirodan zaključak je ruta koja nedostaje, a ruta je obično u redu. Windows može odabrati čiji će se rezolver pitati prema metrici interfejsa, a tunelski adapter često gubi tu usporedbu s bežičnim.

Dva objašnjenja za jedno curenje

Objašnjenje preko ruta kaže da dio saobraćaja izmiče tunelu, pa su podrazumijevana ruta ili lista podijeljenog tunela pogrešne. To se objašnjenje provjerava jednom komandom, a kad podrazumijevana ruta pokazuje u tunel, pitanje je riješeno. Provjerite je prvo jer je jeftino, a zatim je odložite kad se vrati čista.

Objašnjenje preko poretka kaže da je saobraćaj potpuno u tunelu, a upit se ipak šalje drugom rezolveru. Windows tretira izbor rezolvera kao svojstvo svakog interfejsa s redoslijedom, pa fizički adapter s boljom metrikom može dati DNS za ime iako paketi za razriješenu adresu idu kroz tunel. Oba objašnjenja daju isti simptom na stranici za test curenja, zato test nije dijagnoza. Samo se jedno od njih popravlja uređivanjem ruta.

Uporedite metrike i rezolvere zajedno

Zabilježite interfejse, njihove metrike i konfigurisane servere dok je tunel aktivan. Čitajte ih kao tabelu, a ne kao dvije odvojene liste, jer pitanje je koji rezolver stoji prvi, a ne koji rezolveri postoje.

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

Ako tunelski adapter nosi veći broj od fizičkog, njegov rezolver nije preferiran, a interno ime ide onome što fizička strana nudi. Taj ruter može odgovoriti iz keša, proslijediti upit dalje ili ga odbiti, i nijedan od tih ishoda nije dizajn koji ste namjeravali. Poredak je preferencija, pa tiho gubi umjesto da podigne grešku.

Tunelski adapter bez ikakvog konfigurisanog rezolvera jednako je česta varijanta. Klijent podiže interfejs bez slanja DNS postavki, pa se pitanje poretka uopće ne pojavljuje.

Podignite tunel na ljestvici i provjerite ponovo

Dajte tunelskom interfejsu najnižu metriku, ili podignite vrijednost fizičkog adaptera, u povišenoj ljusci. Obje su postavke po interfejsu i obje su povratne, što je važno kad mijenjate računar pred kojim možda ne sjedite.

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

Promjena se vidi odmah, a DNS klijent i drugi potrošači keširaju izbor koji su već napravili. Ponovo povežite tunel ili restartujte prije nego što bilo šta zaključite iz rezultata upita. Test proveden prerano ponovit će staro ponašanje i izgledati kao neuspjela popravka.

Zatim pitajte jedno interno i jedno javno ime i provjerite koji je server odgovorio. Microsoftov pregled o automatskim metrikama objašnjava zašto se najniža vrijednost preferira i kako se izvodi automatsko dodjeljivanje.

Neka preživi ponovno povezivanje

Ručna metrika na adapteru koji se iznova stvara pri svakom povezivanju jest postavka koja nestaje. Ako klijent ponovo izgradi interfejs, nadjačavanje treba skriptu nakon povezivanja, politiku ili konfiguraciju klijenta koja posjeduje DNS dok je veza aktivna.

Statički konfigurisani serveri na fizičkom adapteru imaju isti problem trajnosti u obrnutom smjeru. Oni nastavljaju odgovarati za taj interfejs dok se ne uklone, a DHCP će ih ponovo popuniti iz sljedećeg najma, pa je uklanjanje mjerenje, a ne dizajn. Trajno rješenje je politika razrješavanja imena za interni imenski prostor, ili klijent koji preuzme DNS za vrijeme trajanja veze. U svakom slučaju, zabilježite listu rezolvera prije i poslije ponovnog povezivanja, vratite izvornu metriku kad završite s testiranjem i potvrdite da se prijašnje ponašanje vratilo.