Eyni vaxtda iki VPN tətbiqi: hansı kill switch həqiqətən tətbiq olunur?
İkinci VPN müştərisi heç vaxt birincinin kill switch-ini miras almır. Hansı siyasətin tətbiq olunduğunu üç şərt həll edir və sizinkini necə yoxlamaq olar.
İki VPN müştərisi yan-yana işləyə bilər, lakin onların kill switch-ləri vahid siyasətdə birləşmir. Hər müştəri öz tuneli üçün qaydalar qurur və heç biri digərinin mövcud olduğunu bilmir. Mən bunu əvvəlcə iş müştərisi qoşulmuş halda yaşadım: ikinci tətbiq əl sıxışmasını tamamlaya bilmədi, on dəqiqə „Connecting“ vəziyyətində qaldı və birinci tunel hər şeyi səssizcə daşıdı. İkinci tətbiqin qorunub-qorunmayacağı üç şərtdən asılıdır, hər iki ikonanın Qoşulub deməsindən deyil.
Kill switch həqiqətdə nə ilə məhdudlaşır
Əməliyyat sistemində tək bir kill switch bayrağı yoxdur. Belə bir şey reklam edən müştəri qaydalar toplusu qurur: tunelimdən çıxmayan hər şeyi at və tunel itdikdə çox vaxt fail closed davran. Linux-da bu adətən nftables və ya iptables zənciridir, Windows-da Windows Filtering Platform filtrləri toplusu, Android və iOS-da tunel xidmətinin öz marşrutlaşdırması üstəgəl VPN olmadan bağlantıları bloklayan sistem ayarıdır. Android VPN təlimatı platforma baxışını istəyirsinizsə bu xidmət modelini təsvir edir.
Əhatə dairəsi ən vacib hissədir. „Yalnız wg0 çıxış interfeysindəki paketlərə icazə ver“ kimi qayda ikinci tunelin olub-olmadığını vecinə almır. Başqa müştəri wg1-i qaldırarsa, birinci müştərinin qaydaları bu paketləri adi trafik kimi qəbul edir: adətən atılır, bəzən icazə verilir. Hər halda qərarı birinci müştəri verir və ikinci tətbiqin gözlədiyindən xəbəri yoxdur.
Kimin əhatə olunduğunu həll edən üç şərt
Hər kombinasiyanı sadalamaq lazım deyil. Üç sual bunu bir neçə dəqiqədə həll edir.
- Platforma ümumiyyətlə ikinci tunelə icazə verirmi? Əksər Android telefonlar və iPhone-lar istifadəçi profili üzrə yalnız bir aktiv VPN xidmətinə icazə verir, buna görə ikinci tətbiq heç vaxt tunel saxlamır və heç nə tətbiq etmir. Bir siyasət alırsınız: yeri qazanan tətbiqdən.
- Default marşrutu hansı prosesə məxsusdur? Windows, macOS və Linux iki tuneli rahat daşıyır. Default marşrut onu ən son və ya daha yaxşı metrika ilə konfiqurasiya edən müştəriyə aiddir, digər müştəri isə qoşulub, lakin boşdur. Linux-da wg-quick-in default marşrut rejimi xüsusi cədvəl və fwmark qaydası ilə siyasət əsaslı marşrutlaşdırmadan istifadə edir, buna görə ikinci wg-quick tuneli birincini əvəz etmək əvəzinə rəqib qayda əlavə edir.
- İkinci müştəri öz serverinə çata bilirmi? Birinci kill switch default-rəddirsə, ikinci tətbiqin xarici son nöqtəsi yalnız daha bir atılmış hədəfdir. Səssizcə yenidən cəhd edir və heç vaxt xəta bildirmir.
Qısa versiya, dəstək mövzuları üçün:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Bu sətirlərdən ikisi sistem qabındakı ikonadan eyni görünür, buna görə ikona burada mövcud olan ən pis sübutdur.
İlk nə sıradan çıxır və necə görünür
Digəri sağlam ikən „Connecting“-də ilişib qalan müştəri demək olar ki, həmişə son nöqtə aclığıdır: işləyən kill switch ikinci müştərinin öz serverinə əl sıxışmasını atır. Bunu ucuz yolla təsdiqləmək üçün birinci müştərinin bloklama qaydalarını bir cəhd üçün dayandırın. İkinci dərhal qoşulursa, sual cavablanıb.
DNS ikinci nasazlıqdır. Müştərilər həlledici konfiqurasiyasını öz interfeysləri üçün qurur və bəziləri qlobal siyahının üzərinə düz yazır. Hər iki tunel açıq olduqda sorğular bir tərəfdən çıxa bilər, həlledici isə digər tərəfə aiddir. Tətbiqlərdən birini ayırın və sağ qalan əlçatmaz ad serveri saxlayır: səhifələr bir dəqiqə dayanır və sonra yenidən həll olunur, VPN isə hələ də qoşulmuş görünür.
Üçüncüsü marşrut dalğalanmasıdır. Yenidən qoşulmalar default marşrutu yenidən sıralayır və interfeysə bağlı kill switch buna əməl etmir. Bir an əvvəl tunelin içində olan trafik indi atma qaydasına uyğun gəlir, bu da istifadəçi tərəfində təsadüfən işləməyi dayandıran VPN kimi oxunur.
Hansı siyasətin həqiqətən qüvvədə olduğunu yoxlayın
Bunu zərərsiz trafiklə edin, darıxacağınız bir şeylə deyil.
Linux-da nüvədən kimin qalib gəldiyini və firewall-un nəyə bağlandığını soruşun. ip -4 route show default çıxışa sahib tuneli adlandırır. ip rule show siyasət əsaslı marşrutlaşdırmanın oyunda olub-olmadığını göstərir. sudo nft list ruleset | grep -n oifname atmaların interfeys adına, işarəyə yoxsa bütün çıxış zəncirinə bağlı olduğunu göstərir.
Windows-da eyni hekayə marşrut metriğində və filtr siyahısında yaşayır: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric və Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS-da netstat -rn -f inet | head -5 və scutil --dns | head -20.
Sonra insanların atladığı addımı edin: tuneli qəsdən dayandırın və uğursuz olmasını gözlədiyiniz trafikin həqiqətən uğursuz olduğunu təsdiqləyin. Qoşulmuş ikona interfeys vəziyyətidir, tətbiq deyil.
İki müştəri nə vaxt yanlış dizayndır
İkinci tətbiqin arxasındakı yeganə tələb daha çox müdafiədirsə, onu çıxarın. Qarşılıqlı təsir edən iki bloklama siyasəti birdən az proqnozlaşdırıla biləndir və hər yenidən qoşulma heç bir satıcının sınaqdan keçirmədiyi vəziyyətə düşmək şansıdır.
Həqiqətən zəncirləmə lazımdırsa, məsələn kommersiya atlaması ilə əldə edilən korporativ şlüz, tək tətbiq nöqtəsi olan dizayn seçin. Bu, adətən eyni default marşrut uğrunda yarışan iki masaüstü tətbiqi deyil, zənciri dəstəkləyən bir marşrutlaşdırıcı və ya tək müştəri deməkdir. İdarə olunan cihazda icazə verilmiş müştərini saxlayın və qalan hər şeyi əhatə xaricində sayın, qabıqda nə göstərsə də.
Hər ikisini saxlamaqdan əvvəl yoxlama siyahısı
Siyahını sıra ilə işləyin; uğursuz olan ilk bənd düzəldilməli olandır.
- Default marşrutun və həlledicinin dəqiq bir müştəriyə aid olduğunu təsdiqləyin.
- İkinci müştəri açıq olsun istəyirsinizsə, onun serverinin son nöqtəsinə açıq şəkildə icazə verin və hər müştəri yeniləməsindən sonra yenidən yoxlayın.
- Tünellərdən biri düşdükdə gözlənilən nəticəni yazın və məhz o halı sınaqdan keçirin.
- Yenidən başlatmadan sonra, başlama sırası fərqli olduqda nasazlıq yolunu yoxlayın.
- İdarə olunan profildə dayanın və nə isə əlavə etməzdən əvvəl sahibindən soruşun.
Üçüncü addım uğursuz olarsa, dürüst cavab budur ki, sizə yalnız bir müştəri siyasət verir. Hansına güvəndiyinizə qərar verin və digərini buraxın.