Server dəyişəndə kill switch niyə trafiki dayandırır

Daha yaxın görünən server seçir, qoşul düyməsini basırsan və yeni tunel qurulmadan brauzer yükləməni dayandırır. İkon qoşulur vəziyyətinə keçir və hər tabın vaxtı bitənə qədər orada qalır. Bu fasilə adətən kill switch-in dizaynla işləməsidir: müştərinin trafiki ötürəcək tuneli olmadığı üçün trafik bloklanır. Fasilənin məqbul olub-olmaması müştərinin o saniyələrdə nə etdiyindən və blokun dediyi vaxtda qaldırılıb-qaldırılmamasından asılıdır.

Müştəri iki server arasında nə edir

Son nöqtə dəyişməsi bir açar deyil, bir neçə addımdır. Müştəri cari tuneli sökür, bloklama qaydalarını yeniləyir, yeni son nöqtəni həll edib tuneldən kənarda ona çatır, sonra yeni marşrutları qurur və bloku qaldırır. Hiss etdiyin boşluq birinci addımla sonuncu addım arasındadır.

Burada sıra sürətdən vacibdir. Əgər blok qaydaları yeni son nöqtə üçün istisnadan əvvəl qoyulursa, müştəri əl sıxışmanı tamamlaya bilmir və vaxt bitənə qədər qoşulur vəziyyətində qalır. Əgər istisna köhnə serverin ünvanının surətidirsə, yeni əl sıxışma hər hansı digər çıxan paket kimi görünür və atılır. Hər iki hal brauzerdən eyni görünür; buna görə altı saniyədən sonra bərpa olunan dəyişmə ilə heç vaxt bərpa olunmayan dəyişmə eyni səbəbi paylaşa bilər.

Yeni son nöqtə üçün blokda deşik lazımdır

Tuneli qurmaq üçün müştəri fiziki interfeysdən yeni serverin ünvanına və portuna paketlər göndərməlidir: məsələn, tipik WireGuard profili üçün UDP 51820, OpenVPN üçün isə 1194 və 443, sənin profilin nə göstərirsə. Bu trafik qurulmaqda olan tunelin içində deyil, ona görə də uyğun icazə qaydası olmasa, bütün cihazı əhatə edən blok onu udur.

Host adına əsaslanan profillər ikinci tələb əlavə edir: axtarışın özü. Əgər müştəri son nöqtəni blok qalxmazdan əvvəl həll edirsə, keşlənmiş ünvandan istifadə edə bilər, amma profil ünvanları dəyişdirdikdə və ya keş qeydi köhnəldikdə, əl sıxışma icazə qaydasının əhatə etmədiyi ünvana yönəlir. IPv6 bunu görünən edir, çünki iki yığımlı son nöqtə həm A, həm də AAAA qeydi yaya bilər və yalnız v4 ünvanını əhatə edən icazə qaydası müştərini bloklanmış v6 ünvanına qarşı yenidən cəhd etməyə qoyur.

Seçim adları və susmaya görə dəyərlər müştəriyə və versiyaya görə dəyişir, ona görə ekran şəkillərindən təxmin etmək əvəzinə öz müştərin üçün sənədləşdirilmiş siyahını oxu. OpenVPN Connect parametrləri arayışı openvpn.net/connect-docs/app-settings-windows ünvanında müştərinin blok və split-tunnel seçimlərini necə təsvir etdiyinə bir nümunədir.

Fail-closed bir vəziyyət maşınıdır, açar deyil

Əksər müştərilər bloku firewall siyasəti kimi üç vəziyyətdə ifadə edir: tunel açıq, trafik tuneldən keçir və blok yoxdur; tunel bağlı, blok aktivdir; və keçid, blok aktivdir və son nöqtə üçün müvəqqəti istisnalar var. Səhvlər üçüncü vəziyyətdə yaşayır, çünki o, bir neçə saniyə ərzində iki dəfə dəyişməlidir və ondan çıxa bilməmək daimi blok kimi görünür.

Mexanizm platformaya görə dəyişir, uğursuzluq da. Windows Filtering Platform filtrləri çəki daşıyır, ona görə icazəni üstələyən blok filtri icazə mövcud olsa da paketləri atmağa davam edir və öldürülmüş müştəri prosesinin geridə qoyduğu filtrlər tətbiq getdikdən sonra da maşını oflayn saxlaya bilər. macOS müştəriləri adətən pf qaydalarını ankerə yazır; orada qayda sırası və sürətli qərarlar hansı qaydanın tətbiq olunduğunu müəyyən edir. Linux müştəriləri adətən nftables və ya iptables zəncirini drop siyasəti və son nöqtə, tunel interfeysi və loopback üçün açıq icazələrlə idarə edir. Android-in always-on VPN funksiyası VPN olmadan bağlantıları blokla seçimi ilə qrupun ən sərtidir, çünki OS bloku tətbiq üzrə deyil, bütün cihaz üzrə tətbiq edir.

WireGuard ayrıca qeyd tələb edir, çünki AllowedIPs marşrut seçicisidir, bloklayıcı deyil. Hansı təyinatların tunelə girdiyini müəyyən edir; hələ tuneli olmayan paketin Wi-Fi üzərindən çıxmasının qarşısını almır. Yalnız WireGuard qurulan və firewall qaydası olmayan halda kill switch əslində marşrutun olmamasıdır və atılan əl sıxışmadan sonra fiziki interfeysdən real paket çıxa bilər.

İkonu izləmək əvəzinə boşluğu ölç

Status işığını deyil, paketləri izlə. Linux-da bir terminalda ictimai ünvana yavaş ping başlat və digərində tunelin nəqliyyat portunu fiziki interfeysdə tut:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

Hər ikisi işləyərkən müştəridə serverləri dəyiş. Üç şey vacibdir: ping-lərin nə qədər dayandığı, tutmanın əl sıxışmanın yeni son nöqtəyə çatdığını göstərib-göstərmədiyi və trafikin müştərinin vəziyyəti qoşulduya dəyişməsindən əvvəl, yoxsa sonra bərpa olunduğu. Əgər ping boşluğu əvvəl bitirsə, ya blok erkən qaldırılıb, ya da tunel indikator bunu qəbul etməzdən əvvəl qurulub. Boşluq sonra bitirsə, indikator optimistdir.

Windows-da netsh wfp show state müştəri özünü əlaqəsiz elan edərkən hələ də mövcud olan blok filtrlərini axtara biləcəyin snapshot yazır. macOS-da sudo pfctl -sr yüklənmiş qaydaları və onların sırasını göstərir. İstənilən snapshot-ı müştərinin öz jurnalı ilə birləşdir; ping-dən alınan zaman xətti blokun gec bitdiyini və ya heç bitmədiyini söyləyir.

Normal qaralma ilişib qalmış bloka qarşı

Müəyyən fasilə funksiyanın məqsədidir, ona görə hər hansı parametri dəyişməzdən əvvəl çeşidlə:

İkinci və ya beşinci sətirə düşürsənsə, yoxlamaq üçün kill switch-i söndürmə, çünki bu, marşrut xətasını sızıntıya çevirir. Müştərinin xidmətini yenidən başlat və ya proses öldürməyə dözən filtrlərin olduğu yerdə cihazı yenidən yüklə, sonra blokun təmizlənib-təmizlənmədiyinə bax. Təmizlənirsə, qüsur blokun özündə deyil, dəyişmə zamanı təmizləmədədir.

Növbəti dəyişmədən əvvəl dörd şeyi təsdiqlə: son nöqtə icazəsi profilin həll etdiyi hər ünvan ailəsini əhatə edir, müştəri jurnalı keçidin tamamlandığını göstərir, ping testin ikonu deyil boşluğu ölçür və müştərini bağlamaq normal bağlantını bərpa edir. Dəyişmə zamanı saxlayıb sonra buraxan kill switch işini görür. Erkən və ya heç vaxt buraxmayan isə sazlamağa dəyər.