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

Upit napušta računalo i stiže do kućnog usmjerivača 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 sučelja, a tunelski adapter često gubi tu usporedbu sa bežičnim.

Dva objašnjenja za jedno curenje

Objašnjenje preko ruta kaže da dio prometa izmiče tunelu, pa su zadana ruta ili popis podijeljenog tunela pogrešni. To se objašnjenje provjerava jednom naredbom, a kad zadana 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 promet potpuno u tunelu, a upit se ipak šalje drugom rezolveru. Windows tretira izbor rezolvera kao svojstvo svakog sučelja s redoslijedom, pa fizički adapter s boljom metrikom može dati DNS za ime iako paketi za razriješenu adresu idu kroz tunel. Objašnjenja daju isti simptom na stranici za test curenja, zato test nije dijagnoza. Samo se jedno od njih popravlja uređivanjem ruta.

Usporedite metrike i rezolvere zajedno

Zabilježite sučelja, njihove metrike i konfigurirane poslužitelje dok je tunel aktivan. Čitajte ih kao tablicu, a ne kao dva odvojena popisa, 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 usmjerivač može odgovoriti iz predmemorije, 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 konfiguriranog rezolvera jednako je česta varijanta. Klijent podiže sučelje bez guranja DNS postavki, pa se pitanje poretka uopće ne pojavljuje.

Podignite tunel na ljestvici i provjerite ponovno

Dajte tunelskom sučelju najnižu metriku, ili podignite vrijednost fizičkog adaptera, u povišenoj ljusci. Obje su postavke po sučelju i obje su povratne, što je važno kad mijenjate računalo 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 predmemoriraju izbor koji su već napravili. Ponovno povežite tunel ili restartajte prije nego što bilo što 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 poslužitelj 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 ponovno izgradi sučelje, nadjačavanje treba skriptu nakon povezivanja, politiku ili konfiguraciju klijenta koja posjeduje DNS dok je veza aktivna.

Statički konfigurirani poslužitelji na fizičkom adapteru imaju isti problem trajnosti u obrnutom smjeru. Nastavljaju odgovarati za to sučelje dok se ne uklone, a DHCP će ih ponovno popuniti iz sljedećeg najma, pa je njihovo 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 popis rezolvera prije i poslije ponovnog povezivanja, vratite izvornu metriku kad završite s testiranjem i potvrdite da se prijašnje ponašanje vratilo.