Цурење DNS кроз VPN у Windows-у: зашто метрика побеђује руту

Упит напушта рачунар и стиже до кућног рутера док се сваки пакет тунелује. Природан закључак је рута која недостаје, а рута је обично у реду. Windows може према метрици интерфејса да изабере чији ће се резолвер питати, а тунелски адаптер често губи то поређење са бежичним.

Два објашњења за једно цурење

Објашњење преко рута каже да део саобраћаја измиче тунелу, па су подразумевана рута или листа подељеног тунела погрешне. То објашњење се проверава једном командом, а када подразумевана рута показује у тунел, питање је решено. Проверите је прво јер је јефтино, а затим је одложите када се врати чиста.

Објашњење преко поретка каже да је саобраћај потпуно у тунелу, а упит се ипак шаље другом резолверу. Windows третира избор резолвера као својство сваког интерфејса са редоследом, па физички адаптер са бољом метриком може дати DNS за име иако пакети за разрешену адресу иду кроз тунел. Оба објашњења дају исти симптом на страници за тест цурења, зато тест није дијагноза. Само се једно од њих поправља уређивањем рута.

Упоредите метрике и резолвере заједно

Забележите интерфејсе, њихове метрике и конфигурисане сервере док је тунел активан. Читајте их као табелу, а не као две одвојене листе, јер питање је који резолвер стоји први, а не који резолвери постоје.

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

Ако тунелски адаптер носи већи број од физичког, његов резолвер није префериран, а интерно име иде ономе што физичка страна нуди. Тај рутер може да одговори из кеша, проследи упит даље или га одбије, и ниједан од тих исхода није дизајн који сте намеравали. Поредак је преференција, па тихо губи уместо да подигне грешку.

Тунелски адаптер без икаквог конфигурисаног резолвера једнако је честа варијанта. Клијент подиже интерфејс без гурања DNS поставки, па се питање поретка уопште не појављује.

Подигните тунел и проверите поново

Дајте тунелском интерфејсу најнижу метрику, или подигните вредност физичког адаптера, у подигнутој љусци. Обе су поставке по интерфејсу и обе су повратне, што је важно када мењате рачунар пред којим можда не седите.

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

Промена се види одмах, а DNS клијент и други потрошачи кеширају избор који су већ направили. Поново повежите тунел или рестартујте пре него што било шта закључите из резултата упита. Тест изведен прерано поновиће старо понашање и изгледати као неуспела поправка.

Затим питајте једно интерно и једно јавно име и проверите који је сервер одговорио. Microsoft-ов преглед о аутоматским метрикама објашњава зашто се најнижа вредност преферира и како се изводи аутоматска додела.

Учините га издржљивим на поновно повезивање

Ручна метрика на адаптеру који се изнова ствара при сваком повезивању јесте поставка која нестаје. Ако клијент поново изгради интерфејс, надјачавање тражи скрипту након повезивања, политику или конфигурацију клијента која поседује DNS док је веза активна.

Статички конфигурисани сервери на физичком адаптеру имају исти проблем трајности у обрнутом смеру. Настављају да одговарају за тај интерфејс док се не уклоне, а DHCP ће их поново попунити из следећег најма, па је њихово уклањање мерење, а не дизајн. Трајно решење је политика разрешавања имена за интерни именски простор, или клијент који преузме DNS за време трајања везе. У сваком случају, забележите листу резолвера пре и после поновног повезивања, вратите изворну метрику када завршите с тестирањем и потврдите да се претходно понашање вратило.