VPN kill switch 53-cü portu bloklayanda DNS həll olunmur
Kill switch DNS-i qəsdən bloklaya bilər. Yalnız tunel daxilində həlli yerli həlledici istisnası ilə müqayisə edin, sonra hansı qatın həqiqətən sıradan çıxdığını müəyyənləşdirin.
Kill switch tuneli aşıranda DNS yolunu da özü ilə aparır və arxada qalan həlledici nadir hallarda gözlədiyiniz biri olur. İki dizayn bu ana tamamilə fərqli yanaşır: tunelin içində olmayan hər DNS paketini bloklamaq və yabir həlledicini istisna kimi yerində saxlamaq. Hər ikisi müdafiə oluna bilər. Brauzer vərəqindən simptomlar demək olar ki, eyni görünür, ona görə də ilk iş həqiqətən hansı dizaynı tətbiq etdiyinizi müəyyən etməkdir.
Bu fərqi göz önündə saxlayıram, çünki düzəliş hər halda əks istiqamətdədir. Bir dizayn daha geniş istisna tələb edir; digəri daha dar bir istisna. Təxmin etmək sizə ya məxfilik, ya da bir günorta vaxtı baha başa gəlir.
Eyni nasazlıq üçün iki DNS dizaynı
A dizaynı həllediciyə tunelin arxasındakı adi bir xidmət kimi baxır. Firewall qaydaları UDP və TCP 53-ə yalnız tunel interfeysində icazə verir və müştəriyə verilən ünvan tunel daxilindəki həlledicidir. Tunel düşəndə axtarışlar dayanır və bu, nasazlıq deyil, nəzərdə tutulan nəticədir.
B dizaynı yerli şəbəkədə əlçatan bir həlledici saxlayır — adətən 192.168.1.1 ünvanındakı marşrutlaşdırıcı və ya 127.0.0.53 ünvanındakı əməliyyat sistemi stubu — ad həllinin tunellə birlikdə ölməməsi məntiqi ilə. Bütün ev üçün marşrutlaşdırıcının həll etdiyi ev LAN-ında bu rahatdır. Otel və ya hava limanı Wi-Fi şəbəkəsində eyni istisna başqasının serverinə işarə edir və yazdığınız hər ad açıqlanır, hətta veb trafikiniz bloklanmış qalsa da.
Sərhəd həlledicinin kimə aid olmasıdır. Yerli həllediciyə güvənirsinizsə, istisna kiçik və dürüst bir deşikdir. Güvənmirsinizsə, yalnız tunel dizaynı davam gətirir və qiyməti düşmüş tunelin bütün adları özü ilə aparmasıdır.
Niyə VPN müştərisinin öz axtarışı hələ də işləyir
Müştəri tunel yaranmazdan əvvəl şlüz host adını həll etməlidir, ona görə ciddi blok müştərinin ilkin yükləmə yolunu əhatə etməməlidir. Müştərilərin əksəriyyəti ya son nöqtə ünvanını keşləyir, ya da həmin tək host üçün sənədləşdirilmiş ilkin yükləmə istisnası təqdim edir. Qayda dəstiniz bu axtarışı bloklayırsa, tunel heç vaxt geri qayıtmır və jurnallar öz serverinə çata bilməyən müştəri göstərir; bu, DNS deyil, siyasət qüsurudur.
Split DNS bunun göründüyü digər yerdir. Müştəri daxili zonanı özəl həllediciyə ötürür və qalan hər şeyi sistem həlledicisinə buraxır. Düşmədən sonra ictimai adlar hələ də həll oluna bilər, daxili adlar isə vaxt aşımına uğrayır, çünki özəl zonanın qalan marşrutu yoxdur. İstifadəçi üçün bu "VPN interneti sındırdı" deməkdir; həlledici jurnalı üçün isə heç vaxt çatmayan sorğudur.
systemd-resolved altında bölünməni birbaşa görə bilərsiniz.resolvectl statushər keçid üzrə DNS serverlərini və marşrutlaşdırma domenlərini göstərir və tunel düşdükdən sonra daxili domen artıq mövcud olmayan keçiddəki serverə işarə etməyə davam edir. 127.0.0.53 ünvanındakı stub sorğunu hələ də qəbul edir, sonra cavab verməyəcək yuxarı axını gözləyir; nasazlığın dərhal qayıtmaq əvəzinə saniyələr çəkməsinin səbəbi budur.
Şifrələnmiş DNS paket filtrini keçmir
DNS over HTTPS və DNS over TLS 443 və 853 portlarında hərəkət edir, ona görə 53-cü portu bloklayan qayda onlar haqqında heç nə deməmişdir. "DNS"i porta görə bloklamaq ad həlli ilə deyil, portla bağlı siyasətdir. Kill switch tuneldən kənar bütün trafiki bloklayırsa, DoH təsadüfən əhatə olunur. Captive portal və ya ictimai həlledici üçün icazə ayırmısınızsa, əhatə olunmur.
Müştəri tərəfindəki nəzarətlər daha ucuz qoldur. Firefox kanareyka adıuse-application-dns.nethəll olunmayanda DoH həlledicisindən imtina edir; buna görə idarə olunan şəbəkələr həmin domeni NXDOMAIN kimi yayımlayır və korporativ siyasət də onu söndürülmüş şəkildə bərkidə bilər. Android Private DNS və Chrome-un təhlükəsiz DNS-inin öz açarları və öz standartları var. Onları söndürmək həlledici ünvanlarının arxasınca qaçmaqdan daha etibarlıdır, çünki ünvan siyahısı dəyişir, qayda dəstiniz isə dəyişmir.
Bunun sızmalarla heç bir əlaqəsi olmayan bir variantı da var. Sabitlənmiş həlledicisi olan tətbiq ona çatmaq üçün hələ də şəbəkə yolu tələb edir. Şifrələmə sorğunu kimin oxuya biləcəyini dəyişir, paketin maşından çıxa bilib-bilmədiyini yox, ona görə bütün cihaz üzrə blok parametri ona toxunmadan məğlub edir.
Simptomu qatla uyğunlaşdırın
Əksər hesabat sizə bir cümlə kimi çatır və o cümlə adətən qatı artıq adlandırır. Aşağıdakı cədvəl hər hansı qaydaya toxunmazdan əvvəl nəzərdən keçirdiyim şeydir; məqsəd sorğunun bloklandığını, yanlış yönləndirildiyini yoxsa heç göndərilmədiyini müəyyən etməkdir.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
İlk iki sətir insanların səhv diaqnoz qoyduğu sətirlərdir. Səssiz düşmə və rədd cavabı brauzerdə eyni dərəcədə "DNS sındı" kimi görünür, amma yalnız biri kill switch-in öz işini gördüyünü bildirir. Rədd cavabı nəyinsə cavab verdiyini göstərir, deməli blok düşündüyünüz yerdə deyil.
Həlledici siyasətini bərpa edin, sonra sübut edin
Simptomu deyil, dizaynı düzəldin. Yalnız tunel daxilində həll üçün tunel interfeysində 53-ə icazə verin, daxili həlledicini tunel konfiqurasiyası ilə birlikdə ötürün və fiziki keçidi heç bir DNS icazəsi olmadan buraxın. wg-quick-də həlledicini interfeys konfiqurasiyasına yazan sətirDNS =sətiridir, ona görə onu buraxan tunel köhnə həlledicini yerində qoyur və hər sorğu yanlış yolda olur.wg-quick təlimatıbu davranışı hər platforma üzrə sənədləşdirir.
Sonra bu ardıcıllıqla yoxlayın. Linux-daresolvectl statusaktiv keçidi göstərir,dig +short example.comictimai adı yoxlayır,dig @10.8.0.1 internal.example.comözəl adı yoxlayır vəsudo tcpdump -ni any port 53hər ikisini işlədərkən paketlərin hansı interfeysdən getdiyini göstərir. Windows-daGet-DnsClientServerAddress -AddressFamily IPv4vəResolve-DnsName example.comeyni iki faktı verir: kimin konfiqurasiya olunduğunu və kimin cavab verdiyini.
Mənfi testlə bitirin. Tuneli ayırın, təzə ictimai adın uğursuz olduğunu, özəl adın uğursuz olduğunu və53-cü portdan heç bir paketin fiziki adapterdən çıxmadığını təsdiqləyin. Yalnız keşlənmiş cavablar üçün davam edən blok heç davam etmir.
Bileti bağlamazdan əvvəl yoxlama siyahısı:
- Nasazlıq zamanı istifadə olunan həlledici siyasətin nəzərdə tutduğu həlledicidir.
- Müştərinin öz son nöqtə axtarışına hələ də icazə verilir — keş və ya istisna ilə.
- DoH və DoT ya blokla əhatə olunur, ya da siyasətlə söndürülür.
- Özəl zonalar tunel getdikdən sonra açıq deyil, bağlı rejimdə uğursuz olur.