Windows VPN DNS curenje: zašto metrika pobeđ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 prema metrici interfejsa odabrati čiji će se rezolver pitati, a tunelski adapter često gubi tu usporedbu sa bežičnim.

Dva objašnjenja za jedno curenje

Objašnjenje preko ruta kaže da deo saobraćaja izmiče tunelu, pa su podrazumevana ruta ili lista podeljenog tunela pogrešne. To objašnjenje se proverava jednom komandom, a kada podrazumevana ruta pokazuje u tunel, pitanje je rešeno. Proverite je prvo jer je jeftino, a zatim je odložite kada 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 sa redosledom, pa fizički adapter sa boljom metrikom može dati DNS za ime iako paketi za razreš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

Zabeležite interfejse, njihove metrike i konfigurisane servere dok je tunel aktivan. Čitajte ih kao tabelu, a ne kao dve 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, proslediti upit dalje ili ga odbiti, i nijedan od tih ishoda nije dizajn koji ste nameravali. Poredak je preferencija, pa tiho gubi umesto da podigne grešku.

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

Podignite tunel na lestvici i proverite ponovo

Dajte tunelskom interfejsu najnižu metriku, ili podignite vrednost fizičkog adaptera, u povišenoj ljusci. Obe su postavke po interfejsu i obe su povratne, što je važno kada menjate računar pred kojim možda ne sedite.

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

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

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

Neka preživi ponovno povezivanje

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

Statički konfigurisani serveri na fizičkom adapteru imaju isti problem trajnosti u obrnutom smeru. Nastavljaju da odgovaraju za taj interfejs dok se ne uklone, a DHCP će ih ponovo popuniti iz sledećeg najma, pa je njihovo uklanjanje merenje, a ne dizajn. Trajno rešenje je politika razrešavanja imena za interni imenski prostor, ili klijent koji preuzme DNS za vreme trajanja veze. U svakom slučaju, zabeležite listu rezolvera pre i posle ponovnog povezivanja, vratite izvornu metriku kada završite s testiranjem i potvrdite da se prethodno ponašanje vratilo.