VPN mənim DNS-imı dəyişdirdi? Əvvəl və sonra müqayisə edin
Profil sorğularınızı qəsdən başqa yerə yönəldə bilər. VPN qoşulmadan əvvəl və sonra həlledici siyasətini və faktiki cavabı müqayisə edin, bir dəyişəni sabit saxlayın.
Nəqli bağlantını açır, şəxsi paneli açırsınız və ad heç vaxt görmədiyiniz bir ünvana həll olunur. Ya da əksi olur: brauzer işləməyə davam edir, amma əmr sətri aləti qəflətən heç nə həll etmir. Hər iki nəticə eyni dəyişiklikdən irəli gəlir və insanlar bunu adətən VPN-in "öz DNS-ini istifadə etdiyi" barədə bir cümlə ilə izah edirlər, bu isə sazlaşdırmaq və ya yoxlamaq üçün kifayət qədər dəqiq deyil. Həmin cümlədə iki sual gizlidir: bu profil hansı sorğuları öz üzərinə götürməlidir və maşınınız onları həqiqətən ona verilən həllediciyə göndərdimi? Onları ayrı saxlamaq bütün metoddur, çünki onları qarışdıran test hər iki istiqamətdə əmin bir yanlış cavab verir.
Profil niyə ümumiyyətlə həlledici təqdim edir
Tunelin içində, uzaq tərəfin arxasındakı adlar adətən yalnız o şəbəkədə mövcud olan ünvanlara həll olunur. corp.internal kimi şəxsi zona açıq delegasiyaya malik deyil, ona görə də onu cavablandıran həlledici tunelin içindən əlçatan olmalıdır. Eyni mexanizm ikinci məqsədə də xidmət edir: sorğular əks halda provayderiniz vasitəsilə çıxacaqsa, uzaq tərəfdəki həlledici sorğunu şifrələnmiş yolun içində saxlayır. Buna görə DNS server ünvanı maşın üçün bir dəfə seçdiyiniz qlobal parametr kimi deyil, bağlantı siyasətinin bir hissəsi kimi gəlir.
Ünvanın özü heç nəyi həll etmir. Həlledici yalnız ona marşrut olduqda cavab verə bilər və ən çox rast gəlinən nasazlıq tunel açıq olduqda əlçatan olan həlledicidir. Tunel düşəndə və siyasət qalanda sorğular yolu olmayan ünvana gedir və simptom təmiz xəta deyil, gözləmə müddətinin bitməsidir. Bu fərq növbəti test nəticəsini oxuyarkən vacibdir, çünki gözləmə müddəti insanları heç vaxt iştirak etməmiş nəqliyyat parametrlərinə yönəldir.
Cavabları müqayisə etməzdən əvvəl iki dizaynı müqayisə edin
Tam tunel və bölünmüş DNS bir-birinə zidd gözləntilər yaradır və heç biri nasazlıq deyil. Tam tunel altında hər sorğu provayderə və ya korporativ həllediciyə keçə bilər, buna görə də qoşulmadan sonra ümumi adların fərqli cavab verməsi gözləniləndir. Bölünmüş DNS altında yalnız siyahıda olan domenlər şəxsi həllediciyə gedir, qalan hər şey isə lokal qalır; Windows-da domen siyahısı Ad Həll Siyasəti Cədvəlində, macOS-da DNS parametrlərinin uyğun domenlərində, systemd-resolved hostunda isə hər keçid üzrə marşrut domenlərində yaşayır.
Əvvəlcə bu müqayisəni aparmaq lazımdır, çünki nəyin nasazlıq sayıldığını o müəyyən edir. Bölünmüş DNS-də yeni həlledicidən cavab verən ümumi ad araşdırılmağa dəyər olan şeydir, daxili adın düzgün cavab verməsi isə sistemin öz işini görməsidir. Tam tuneldə isə hələ də provayderinizin həlledicisindən cavab verən ümumi ad anomaliyadır. Microsoft-un VPN ad həlli barədə sənədləşməsi bu qaydaların Windows-dakı sırasını, o cümlədən uyğun siyasət qeydinin adapterin öz serverlərindən əvvəl necə nəzərə alındığını təsvir edir.
Otaqda asanlıqla unudulan üçüncü bir həlledici var. Brauzerin təhlükəsiz DNS-i adları özü həll edir və tunel əməliyyat sisteminin siyasətini dəyişdikdən sonra da cavab verməyə davam edə bilər, buna görə yüklənən səhifə brauzerin həlledicisinin işlədiyini sübut edir, profilin tətbiq olunduğunu yox. Yalnız brauzerin göstərdiyini müqayisə etsəniz, vaxtın yarısında yanlış qatı sınaqdan keçirirsiniz.
Yalnız bir dəyişənlə başlanğıc vəziyyəti qeyd edin
Tuneli dəyişin. Eyni addımda adı, aləti və ya axtarış şəkilçisini də dəyişməyin. Sorğu verməyə icazəli olduğunuz bir ad seçin, hansı tətbiqdən istifadə etdiyinizi qeyd edin və ya qaytarılan ünvanı, ya da dəqiq xətanı yazın. Windows-da Get-DnsClientServerAddress -AddressFamily IPv4 hər adapter üzrə serverləri, Get-DnsClientNrptPolicy isə siyasət qeydlərini çap edir; systemd-resolved ilə Linux-da resolvectl status hər keçid üzrə DNS serverlərini və marşrut domenlərini göstərir; macOS-da scutil --dns sistemin həqiqətən izləyəcəyi həlledici sırasını çap edir.
Sonra müştərinin adi idarəetmə vasitələri ilə qoşulun və tam eyni əmrləri təkrarlayın. İlk çıxışı yaddaşınızda deyil, olduğu kimi saxlayın, çünki bütün məqsəd müqayisədir və keş təmizləndikdən sonra alınan ikinci oxunuş artıq fərqli bir ölçmədir. Başlanğıc vəziyyət brauzer öndə ikən götürülübsə və qoşulmadan sonrakı iş terminalda aparılırsa, siz bir həlledicinin iki vəziyyətini deyil, iki həlledicini müqayisə edirsiniz.
Açıq sorğu və tətbiq axtarışı fərqli testlərdir
nslookup name 10.20.0.1 və ya dig @10.20.0.1 name ilə müəyyən bir serverə sorğu vermək bir şeyi sübut edir: adını çəkdiyiniz server sizin üçün əlçatan olduqda cavab verir. Bu, seçim məntiqini tamamilə keçir, buna görə sistemin bu ad üçün həmin serveri seçib-seçməyəcəyini deyə bilməz. Onu təyin edilmiş həlledicinin əlçatan olub-olmadığını yoxlamaq üçün istifadə edin və siyasəti yoxlamaq üçün istifadə etməyin.
Yerli həlledici vasitəsilə axtarış seçimi həqiqətən işə salır. resolvectl query name eyni marşrut domeni qaydalarını keçir və cavab verən protokolu bildirir, Windows-da Resolve-DnsName siyasət cədvəlindən və müştəri keşindən keçir, scutil --dns isə axtarışın izləyəcəyi sıranı göstərir. Hər iki növü işə salın və onları qeydlərinizdə ayrı sütunlarda saxlayın. Uğurlu açıq sorğunun yanında uğursuz tətbiq axtarışı marşrut və ya seçim problemidir, işləməkdən imtina edən həlledici deyil.
Keşləmə sizinlə cavab arasında dayanır. Əməliyyat sistemi, yerli stub həlledici, brauzer və mənfi keşləmə hamısı nəticələri saxlayır, buna görə bir axtarış maşından bir dənə də paket çıxmadan uğurla nəticələnə bilər. Hər hansı təmizləmədən əvvəl nəticəni qeyd edin: ipconfig /flushdns, resolvectl flush-caches və ya macOS-da sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Bu mərhələdə geniş şəbəkə sıfırlamasını keçin, çünki o, hələ topladığınız sübutları məhv edir.
Bu fərq nə deməkdir
Qeyd etdiyiniz iki sətri müqayisə edin və hər hansı parametrə toxunmazdan əvvəl dəyişikliyi təsnif edin.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Bir sətir xüsusi vurğuya layiqdir. Həll olunan ad işləyən xidmət deyil və DNS uğuru yalnız ünvanın tapıldığını bildirir. O, yönləndirmə, firewall qaydaları və ya hesabınızın xidmətdən ümumiyyətlə istifadə edə bilib-bilmədiyi barədə heç nə demir, buna görə nasazlığın öz-özünə getdiyini güman etmək əvəzinə faktiki tətbiqi sınaqdan keçirərək bitirin.
Başlanğıc vəziyyəti bərpa edin və yoxlayın
Prosesi öldürmək əvəzinə müştərinin öz idarəetmə vasitələri ilə bağlantını kəsin, sonra eyni üç əmri yenidən oxuyun. Hər keçid üzrə serverlər, siyasət qeydləri və test adınızın cavabı əvvəl yazdığınız başlanğıc vəziyyətə qayıtmalıdır. Təmiz ayrılmadan sonra qalan siyasət qeydi qeydə alınmağa dəyər real qüsurdur və buna görə yaradılmış həlledici faylına əl ilə düzəliş etmək pis vərdişdir: fayl yenidən yazılır və düzəliş yox olur, ya da düzəliş qalır və artıq marşrutu olmayan həlledicini bərkidir.
Bu siyahını bir dəfə, sıra ilə işləyin. Hər hansı nəticəni mühakimə etməzdən əvvəl profilin hansı dizaynı tətbiq etdiyini müəyyənləşdirin. İki işə salma boyunca adı, aləti və şəkilçini sabit saxlayın. Açıq sorğunu tətbiq axtarışından ayırın. Yalnız cavabı deyil, effektiv siyasəti oxuyun. Keşləri ən sonda təmizləyin, müqayisə yazıldıqdan sonra. Faktiki tətbiqlə yoxlayın, sonra bir dəfə yenidən başladın və ayrılma vəziyyətinin hələ də təmiz olduğunu təsdiqləyin.