Windows VPN-də səhv DNS serveri: metrik, bağlama sırası və ya şəkilçi

Windows klienti işləyən tunelə malik ola, korporativ həlledicini daşıya və yenə də daxili adları ev marşrutlaşdırıcısına göndərə bilər. Hansı serverin cavab verəcəyini üç fərqli mexanizm müəyyən edir və onlar fərqli şəkildə sıradan çıxır. Hər üçünü düzəltmək lazım deyil: simptom hansının işdə olduğunu deyir. Aşağıdakı qərar ağacı bir neçə dəqiqə çəkir və adi nəticənin qarşısını alır: metrik dəyişikliyi, reyestr sıralaması və NRPT qaydası birlikdə düşür və heç kim hansının nə etdiyini bilmir.

Üç mexanizm qərar verir və adətən biri səhvdir

Interfeys metriki müəyyən ünvan ailəsi üçün adapterləri sıralayır. Tcpip\Linkage altındakı bağlama sırası köhnə kod yollarının hələ də müraciət etdiyi, maşın miqyaslı interfeys identifikatorları siyahısıdır. Ad Həlli Siyasəti Cədvəli (NRPT) bir ad məkanını konkret serverlərə bağlayır, şəkilçi siyahısı isə qısa adın ümumiyyətlə genişləndirilib-genişləndirilmədiyini müəyyən edir. Onlar bir-birindən asılı deyil, buna görə VPN adapterindəki düzgün həlledici başqa yerdəki köhnəlmiş üstünlüyə uduzur.

Bu mexanizmlərin heç biri tunelin o biri tərəfi deyil. VPN-in təqdim etdiyi server adı həll edə bilmirsə, müştəri tərəfindəki hər tənzimləmə sadəcə bəzəkdir, ona görə ilk qərar həlledicinin özünün birbaşa soruşulduqda cavab verə bilməsidir.

Qərar bir: təqdim edilən həlledici ümumiyyətlə cavab verə bilirmi?

Serverdən açıq şəkildə soruşun və bunu adi axtarışla müqayisə edin. Cavablar arasındakı fərq seçim problemini əlçatanlıq problemindən ayırır və burada ən sürətli çəngəldir:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Birinci uğurlu, ikinci uğursuz olarsa, həlledici əlçatandır və Windows pis seçim edir; aşağıdakı ad məkanı və sıra qərarlarına keçin. Birinci də uğursuz olarsa, müştəridə heç nə kömək etməyəcək: UDP və TCP 53-ün tunel vasitəsilə serverə çatdığını, serverdəki host firewall-un hovuzu atmadığını və serverin öz yönləndiricilərinin sağlam olduğunu yoxlayın.

Bu çəngəldə dayanın. Əlçatmayan həllediciyə NRPT qaydası tətbiq etmək eyni uğursuzluğu daha çox geri alınacaq konfiqurasiya ilə verir və əsl nasazlığı nüfuzlu görünən qaydanın arxasında gizlədir.

Qərar iki: bir ad məkanı, yoxsa hər sorğu?

Alət seçimi əhatə dairəsi ilə müəyyən olunur. Yalnız korporativ adlar uğursuz olursa, maşını yenidən sıralamaq əvəzinə ad məkanını bağlayın: NRPT qaydası həmin şəkilçini tunel həlledicisinə göndərir və qalan hər şeyi toxunulmaz qoyur. Hər axtarış təsirlənirsə, problem qlobal adapter üstünlüyüdür və metrik başlamaq üçün doğru yerdir, çünki heç bir server tənzimləməsini dəyişmir.

Metriki hər ünvan ailəsi üzrə, iki interfeysdə də təyin edin və sonra sıranı təsdiqləyin:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

11-i yuxarıdakı sətirdən tunel adapterinin ifIndex dəyəri ilə əvəz edin; 11 LAN adapteridirsə, eyni əmr səhv yolu aşağı salır. Əvəzində LAN adapterini qaldırmaq eyni sıraya digər tərəfdən çatır: netsh int ip set interface interface="Ethernet" metric=15 və ikinci ailə üçün netsh int ipv6 set interface interface="Ethernet" metric=15, çünki int ip yalnız IPv4-ə toxunur.

Bağlama sırası ilk addım deyil, son çarədir. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage cihaz identifikatorlarından ibarət Bind siyahısı saxlayır və tunel identifikatorunu önə çəkmək həqiqətən hansı adapterin birinci soruşulacağını dəyişir, lakin bu, hər ad məkanı üzrə əhatəsi olmayan, maşın miqyaslı reyestr dəyəridir. Redaktədən əvvəl onu ixrac edin və sonra tuneli yenidən qoşun ki, sıra müştərinin gözlədiyi vəziyyətdə tətbiq olunsun.

Tək bir ad məkanı üçün daha dar alətə üstünlük verin:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Qərar üç: düzəliş yenidən qoşulmadan sonra da qalırmı?

Növbəti yığım bağlantısı yenidən qoşulana qədər işləyən metrik heç vaxt yadda saxlanmayıb. L2TP/IPsec və digər bağlantı profilləri bağlantı başlayanda yenidən yaradılır, ona görə saxlanan dəyər telefon kitabçası qeydində IpInterfaceMetric kimi yaşayır, yalnız canlı interfeysdə deyil. Bəzi mühitlər o sahəni məhz bu səbəbdən skriptləyir; digərləri üstünlüyü idarəetmə siyasətindən təqdim edib son nöqtəni olduğu kimi qoyur.

Keş və qeydiyyat ayrı bir qatdır. Bunları tunel qalxdıqdan sonra işə salmaq köhnəlmiş qeydləri düzəldir və müştərini yenidən qeydiyyatdan keçirir, lakin heç biri adapteri yenidən sıralamır:

ipconfig /registerdns
ipconfig /flushdns

Eyni qatda bir söndürmə açarı var. Fiziki adapterdə dinamik qeydiyyatı söndürmək müştərinin VPN tərəfindəki ünvanını səhv ad altında elan etməsinin qarşısını alır və bu, yuxarıdakı yeniləmədən fərqli bir təmirdir.

IPv6 qərarda öz sətrinə layiqdir. Fiziki adapterdə qlobal IPv6 ünvanı varsa və tunel yalnız IPv4 daşıyırsa, Windows ad həlli üçün tunelsiz yola üstünlük verə bilər. O ailəni ayrıca yoxlayın, çünki IPv4 üçün təyin edilmiş metrik onun haqqında heç nə demir:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

LAN adapterində IPv6-nı söndürmək o yolu və onunla birlikdə protokolu çıxarır; IPv6 interfeysində metrik dəyişikliyi və ya korporativ ad məkanı üçün NRPT qaydası ailəni saxlayır və üstünlüyü düzəldir. Dar olanı seçin, məgər o bağlantının IPv6 olmamalı olduğuna qərar verməmisinizsə.

Mənbəni adlandıraraq yoxlayın və bir sahib saxlayın

Yalnız səhifənin yüklənməsini deyil, hansı mənbənin qüvvədə olduğunu bildirən alətlərlə yoxlayın:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Sonra filtrləməni seçimdən ayırın, çünki tətbiqin içindən onlar eyni görünür. OpenVPN-in block-outside-dns seçimi digər adapterlərdə 53 portunu bloklayır; həlledici seçmir. İndi hər sorğu uğursuz olursa, filtr yeganə əlçatan serveri bloklaya bilər; konfiqurasiya edilmiş həlledici nəzərə alınmırsa, sıra və ya ad məkanı qaydası səhvdir. İkisini eyni anda dəyişmək bloklanmış sorğunu nəzərə alınmayan sorğudan ayırd etməz.

DNS siyasəti üçün bir sahib saxlayın: VPN profili, idarəetmə siyasəti və ya NRPT qaydası, onlardan ikisi deyil. Bağlamazdan əvvəl:

• Təqdim edilən həlledici açıq şəkildə göstərildikdə cavab verir və adi axtarış ondan istifadə edir.
• Dəyişdiyiniz qayda və ya metrik sorğuları həqiqətən daşıyan ünvan ailəsini əhatə edir.
• Tənzimləmə bağlantının kəsilməsindən və yenidən qoşulmasından sonra da qalır və ya siz onu saxlanan profilə köçürmüsünüz.
• Yalnız bir mexanizm səlahiyyətlidir, digərləri olduğu kimi buraxılıb.

Sıraya bitirdiyiniz bir şey kimi deyil, mühit vəziyyəti kimi yanaşın. Yenidən qoşulmadan və şəbəkə yığınına toxunan Windows yeniləməsindən sonra onu yenidən yoxlayın, çünki hər ikisi fiziki adapteri yenidən önə çıxara bilər.