Windows-da OpenVPN qoşulduqdan sonra DNS niyə işləmir

Resolver ping-ə hələ də cavab verir, amma 53 portuna heç nə çatmır. block-outside-dns-in filtrlədiyini yoxlayın, sonra tunelin çata bildiyi bir resolver təyin edin.

Ofis resolver-inə ping "OpenVPN" qoşulduqdan sonra da cavab verir, lakin hər ad sorğusu uğursuz olur. Ünvan əlçatandır, port isə deyil, və Windows-un DNS-i adapter üzrə filtrləyə bildiyini biləndə bu birləşmə məntiqli olur. Profildə block-outside-dns varsa, bu filtr ilk şübhəlidir və marşrut cədvəli axtarış üçün yanlış yerdir. Aşağıdakı iki test qatları saniyələr içində ayırır.

Əlçatan ünvan, ölü port

Uğurlu ping hostun işlədiyini və yolun mövcud olduğunu sübut edir. Lakin 53 portuna icazə barədə heç nə demir, çünki sözügedən filtr başqa qatda işləyir və adapterə bağlanır. Buna görə eyni maşın ICMP-yə cavab verə və eyni ünvana göndərilən hər sorğunu rədd edə bilər. Hər hansı konfiqurasiyanı dəyişməzdən əvvəl hər iki testi eyni sessiyada işlədin.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Bu cüt diaqnozdur. Yeraltı şəbəkəyə adi trafik işləməyə davam edir, ad həlli isə ölür, və insanlar serverin xarab olduğu və ya DNS-in heç vaxt ötürülmədiyi qənaətinə gəlir. Hər iki izahatın arxasınca getmək baha başa gəlir, dəlillər isə daha dar bir yerə işarə edir. Hər hansı parametrə toxunmazdan əvvəl cütü təsdiqləyin.

Bu seçim filtrləmə platformasının qaydasıdır

OpenVPN sənədi block-outside-dns-i tuneldən kənar adapterlərdə tətbiqlərin DNS-ə çatmasını dayandıran Windows Filtering Platform məhdudiyyəti kimi təsvir edir. O, TCP və UDP üzrə 53 portunu əhatə edir. Filtr adi firewall qaydaları siyahısında deyil, WFP-də yaşadığı üçün başqa yerdə icazə qaydası əlavə etmək nəticəni mütləq dəyişmir. Buna görə DNS-ə icazə vermək barədə geniş yayılmış məsləhət uğursuz olmağa davam edir.

Parametr idxal edilmiş profildən və ya serverdən gələ bilər, və sonuncu dəfə redaktə etdiyiniz fayl "müştərinin nə yüklədiyinin sübutu deyil". Effektiv konfiqurasiyanı və qoşulma jurnalını birlikdə oxuyun. Bu seçim həm də Windows-a xasdır, və onu portativ hesab etmək tətbiq olunmayan məsləhət yaradır.

Daha çox qayda əlavə etmək əvəzinə məhdudiyyəti idarə edən müştəri komponentini axtarın. Sahib onu həqiqətən silə bilən şeydir.

Filtr resolver deyil

Tuneldən kənar trafiki bloklamaq onun içində işlək resolver quraşdırmır. Seçim bir yolu silir və tunelin DNS konfiqurasiyasını profili quran şəxsə buraxır. Heç vaxt resolver ötürməyən profildə indi heç biri yoxdur.

Üç yoxlamanı sıra ilə keçin. Birincisi, uğursuz tətbiqin faktiki olaraq hansı resolver-dən istifadə etdiyi. İkincisi, müştərinin VPN DNS parametrlərini tətbiq edib-etmədiyi. Üçüncüsü, hansı interfeysin o resolver-ə trafik daşıdığı.

  1. İstifadədə olan resolver: Resolve-DnsName -Server <resolver-ip> <name> əmrini ipconfig /all çıxışında sadalanan DNS serverləri ilə müqayisə edin.
  2. VPN DNS tətbiq olunub: ipconfig /all çıxışında tunel adapterinin DNS qeydlərini yoxlayın.
  3. İstifadə olunan interfeys: Find-NetRoute -RemoteIPAddress <resolver-ip> həmin təyinat üçün gedən interfeysi göstərir.

LAN resolver-i bu siyasət altında dizayn olaraq əlçatmaz olur, hətta digər LAN trafiki işləyərkən. Bu, seçimin öz işini görməsidir. Dizayn VPN DNS tələb edirsə, resolver qeydiyyatını və tunel yolunu düzəldin; yerli istisnalarla split DNS tələb olunursa, konfiqurasiya sahibi həmin istisnaları dəstəklənən şəkildə ifadə etməlidir.

Seçimin əhatə etmədiyi şeylər

53 portu ad həllinin hamısı deyil. DNS over HTTPS və DNS over TLS fərqli nəqliyyat istifadə edir, və bəzi tətbiqlər sistem parametrlərindən asılı olmayaraq öz resolver məntiqini işlədir. Buna görə brauzer adları həll edə bilər, əmr sətri isə edə bilməz.

Bu fərqi ziddiyyət kimi deyil, diaqnostik kimi qəbul edin. Sistem resolver-inin xarab olduğuna qərar verməzdən əvvəl ikisini müqayisə edin.

Yazarkən nəticəni dar saxlayın. Bu seçim bir platformada bir nəqliyyatı məhdudlaşdırır, həll yolunun qalan hissəsi isə öz sahibi olan ayrı dizayn sualıdır.

Əlaqəni kəsməzdən əvvəl və sonra vəziyyəti yoxlayın

Eyni axtarışı qoşulma zamanı və sahib müştəri ayrıldıqdan sonra yenidən işlədin. Birincisi tunel açıqkən xarici resolver üçün uğursuz olmalı, ikincisi filtr silindikdən sonra uğurlu olmalıdır. Əgər ayrıldıqdan sonra da uğursuz olursa, filtr təmizlənməyib.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Müştəri xidmətini və ya maşını yenidən başlatmaq adətən köhnə filtri təmizləyir. Bu, diaqnozu təsdiqləyir, lakin qalıcı həlli sübut etmir. Gördüyünüzü qeyd edin, çünki ayrılmadan sonra da qalan filtr bunu yenidən edəcək, və qeyd səhv hesabatını əsaslandıran şeydir.

Yalnız bu yoxlamalardan sonra resolver-i dəyişmək və ya firewall siyasətini yenidən qurmaq məntiqli olur. Hər ikisi dəlillərin dəstəklədiyindən daha böyük dəyişikliklərdir.

Əlaqəli məqalələr