Windows VPN DNS sızması: metrika marşrutu niyə üstələyir

Sorğu maşından çıxıb ev routerinə çatır, halbuki hər paket tuneldən keçirilir. Təbii nəticə çatışmayan marşrutdur, halbuki marşrut adətən qaydasındadır. Windows hansı interfeysin həlledicisinin sorğulanacağını interfeys metrikasına görə seçə bilər və tunel adapteri bu müqayisədə simsiz interfeysə tez-tez uduzur.

Bir sızma üçün iki izah

Marşrut izahı deyir ki, trafikin bir hissəsi tuneldən qaçır, deməli defolt marşrut və ya bölünmüş tunel siyahısı səhv olmalıdır. Bu izah bir əmrlə yoxlanıla bilər və defolt marşrut tunelin içinə baxanda məsələ bitir. Onu ilk yoxlayın, çünki ucuzdur, sonra təmiz qayıdanda kənara qoyun.

Sıralama izahı deyir ki, trafik tam tuneldən keçir və sorğu hələ də başqa həllediciyə göndərilir. Windows həlledici seçimini sırası olan interfeys xassəsi kimi qəbul edir, ona görə daha yaxşı metrikaya malik fiziki adapter həll olunmuş ünvanın paketləri tuneldən getsə də bir ad üçün DNS verə bilər. Hər iki izah sızma testi səhifəsində eyni simptomu yaradır, buna görə test diaqnoz deyil. Onlardan yalnız biri marşrutları redaktə etməklə düzəlir.

Metrikaları və həllediciləri birlikdə müqayisə edin

Tunel işləyərkən interfeysləri, onların metrikalarını və konfiqurasiya olunmuş serverlərini qeyd edin. Onları iki ayrı siyahı kimi deyil, cədvəl kimi oxuyun, çünki sual hansı həlledicinin birinci gəlməsidir, hansı həlledicilərin mövcud olması deyil.

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

Tunel adapteri fiziki adapterdən daha yüksək rəqəm daşıyırsa, onun həlledicisi üstün tutulmur və daxili ad fiziki tərəfin təklif etdiyi yerə gedir. Həmin router keşdən cavab verə, sorğunu ötürə və ya ondan imtina edə bilər və bu nəticələrin heç biri nəzərdə tutduğunuz dizayn deyil. Sıralama üstünlükdür, ona görə xəta qaldırmaq əvəzinə səssizcə uduzur.

Ümumiyyətlə heç bir həlledici konfiqurasiya olunmayan tunel adapteri eyni dərəcədə geniş yayılmış variantdır. Müştəri interfeysi DNS təklif etmədən qaldırır, ona görə sıralama sualı heç ortaya çıxmır.

Tuneli yuxarı sıralayın və yenidən yoxlayın

Yüksəldilmiş qabıqda tunel interfeysinə ən aşağı metrikanı verin və ya fiziki adapterin dəyərini qaldırın. Hər ikisi interfeys üzrə parametrdir və hər ikisi geri qaytarıla bilər, bu da qarşısında oturmadığınız bir maşını dəyişəndə vacibdir.

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

Dəyişiklik dərhal görünür və DNS müştərisi ilə digər istehlakçılar artıq etdikləri seçimi keşləyir. Sorğu nəticəsindən nəsə çıxarmazdan əvvəl tuneli yenidən qoşun və ya yenidən başladın. Çox erkən aparılan test köhnə davranışı təkrarlayacaq və uğursuz düzəliş kimi görünəcək.

Sonra bir daxili və bir ictimai ad sorğulayın və hansı serverin cavab verdiyini yoxlayın. Microsoft-un avtomatik metrikalar haqqında arayışı ən aşağı dəyərin niyə üstün tutulduğunu və avtomatik təyinatın necə çıxarıldığını izah edir.

Yenidən qoşulmadan sonra da saxlayın

Hər qoşulmada yenidən yaradılan adapterdə əl ilə verilmiş metrika yoxa çıxan parametrdir. Müştəri interfeysi yenidən qurursa, bu üstələmə qoşulmadan sonra işləyən skript, siyasət və ya qoşulma müddətində DNS-ə sahib olan müştəri konfiqurasiyası tələb edir.

Fiziki adapterdə statik konfiqurasiya olunmuş serverlər eyni davamlılıq problemini tərsinə yaşayır. Onlar silinənə qədər həmin interfeys üçün cavab verməyə davam edir və DHCP onları növbəti icarədən yenidən doldurur, ona görə onları silmək dizayn deyil, ölçmədir. Davamlı dizayn daxili ad məkanı üçün ad həlli siyasəti və ya qoşulma müddətində DNS-ə sahiblik edən müştəridir. Hər halda, yenidən qoşulmadan əvvəl və sonra həlledici siyahısını qeyd edin, testi bitirəndə ilkin metrikanı bərpa edin və əvvəlki davranışın qayıtdığını təsdiqləyin.