Tətbiqdə kill switch ilə firewall kill switch: hər biri nəyi bloklayır
Bir kill switch tətbiqləri bağlayır, digəri paket filtrləri qurur. Bu yoxlamaları sıra ilə aparın və ədalətli cavab verə bilmədiyiniz birincisində dayanın.
Xüsusiyyətlər siyahısındakı kill switch tunel düşəndə nə baş verdiyi barədə demək olar ki, heç nə demir. Bir tətbiq seçilmiş prosesləri bağlayır, digəri əməliyyat sistemi sərhədində paket filtrləri qurur, üçüncüsü isə sadəcə yenidən qoşulmağa çalışır. Fərq nasazlıqdan sonrakı saniyələrdə görünür, parametrlər ekranında deyil. Bu yoxlamaları sıra ilə keçin və ədalətli cavab verə bilmədiyiniz birincisində dayanın, çünki real əhatəniz orada bitir.
Əvvəlcə icra mexanizmini adlandırın
Prosesin dayandırılması tətbiqin həyat dövrü xüsusiyyətidir. Aşkar edilmiş tunel nasazlığından sonra seçilmiş proqramları tapır və bağlayır. Əsas proses olmayan hər şey qalır: köməkçi xidmətlər, fon sinxronizasiyası və bir saniyə sonra başlayan hər hansı tətbiqin öz həyat dövrü və öz vaxtı var.
Paket filtrləmə əməliyyat sistemi xüsusiyyətidir. İcazə verilən yolu izləməyən trafiki rədd edir, bu daha güclü vəddir, amma yalnız qaydanın həqiqətən uyğun gəldiyi çərçivədə. Bunu ünvan ailəsi, interfeys, xaric edilmiş tətbiqlər və istisnalar həll edir, müştəridəki etiket deyil.
Blok müştəridən uzun yaşayırmı?
Dörd sualı bu sıra ilə verin: qəza zamanı, əl ilə çıxışda, logoutda və yenidən başlatmada nə olur. Müştərinin özünün saxladığı qayda adətən səliqəli bağlanma zamanı silinir və çox vaxt qəzadan sonra qalır. Platforma anbarına quraşdırılmış qayda isə əksinə davrana bilər: həm müştərini, həm də bəzən deinstalyasiyanı keçib yaşayır.
Uzun yükləmənin ortasında müştərini bağlayın və ötürmənin dayandığını yoxsa davam etdiyini izləyin.
Standart deşikləri axtarın
IPv6 birincidir. IPv4 ünvanları üçün yazılmış qayda IPv6 trafikini toxunulmaz qoyur və bir çox müştəri yalnız v4 yarısını yazır. İkincisi interfeysdir: USB tethering, ikinci Wi-Fi adapteri və mobil modem əsas bağlantıya yönəlmiş qaydaya daxil olmaya bilər. Xaric edilmiş tətbiqlər və yerli şəbəkə istisnaları üçüncüdür.
Windows-da açar əvəzinə quraşdırılmış qaydaları oxuya bilərsiniz: Get-NetFirewallRule -DisplayName '*VPN*' və netsh wfp show filters nəyin mövcud olduğunu göstərir. Linux-da iptables -S, ip6tables -S və nft list ruleset ümumi halları əhatə edir və üçünü müqayisə etmək əsas məqsəddir.
DNS adi sızma yeridir
TCP-ni bloklayıb UDP 53-ü açıq qoymaq sizə hər hostname sorğusuna cavab verən çox inandırıcı bir kill switch verir. Eyni şey DNS başqa interfeysdəki resolver-ə verildikdə və ya müştəri yalnız v4-ü bloklayanda və resolver v6 üzərindən əlçatan olduqda da tətbiq olunur.
Tunel düşmüş halda bir tanınmış adı həll edin və cavabın qayıdıb-qayıtmadığına baxın. Qayıdırsa, status nişanı nə deyirsə desin, trafik tam bloklanmayıb.
Keçidi yoxlayın, açarı deyil
VPN-i öz menyusundan söndürmək səliqəli bağlanmadır və səliqəli hal hər tətbiqin yaxşı idarə etdiyi haldır. Əhəmiyyətli keçid kobud olandır: tunel prosesini öldürün, şəbəkəni çıxarın, serverin cavab verməsini dayandırın. Sonra sorğu başladın və onun uğursuz olduğunu yoxsa səssizcə fiziki kanaldan istifadə etdiyini izləyin.
Bir noutbukdan alınan nəticə telefona və ya marşrutlaşdırıcıya keçmir. Fərqli platforma API-ləri, fərqli standartlar və Android-də fərq kəskindir: bloklama ilə always-on rejimi müştəri deyil, sistem tətbiq edir, ona görə müştəri işləməyəndə də işləyir. Android VPN təlimatı bu ayrımı təsvir edir.
Geri dönüş yolu saxlayın
Sistem səviyyəsində bloklamanın əks nasazlıq rejimi var. Müştəridən uzun yaşayan filtrlər deinstalyasiyadan sonra kompüteri tamamilə şəbəkəsiz qoya bilər, bu da səbəbi aydın olmayan bir dəstək zəngidir. Platforma qaydaları yazan hər hansı kill switch-i aktivləşdirməzdən əvvəl onun necə silindiyini qeyd edin və təchizatçının təmir yolunu tapa biləcəyiniz yerdə saxlayın.
Müştəriniz üçün qəza, IPv6, DNS və keçid yoxlamalarına cavab verə bilmirsinizsə, onu məlum boşluqları olan tətbiq səviyyəli açar kimi qəbul edin və ona uyğun planlaşdırın.