Always-on VPN yoxsa kill switch: hansini həqiqətən aktivləşdirdiniz?

Always-on və kill switch eyni parametrlər ekranında iki sətir aralığında durur, ona görə insanlar onları bir funksiyanın iki adı kimi oxuyur. Elə deyil. Always-on yenidən qoşulma siyasətidir: tuneli yükləmədə açır, qəza və ya şəbəkə dəyişikliyindən sonra qaytarır və uğursuz olduqca yenidən cəhd edir. Kill switch trafik siyasətidir: tunel söndüyü halda maşını tərk edə biləcək paketləri adlandırır. Birincini ikincisiz aktivləşdirə bilərsiniz və əksər platformalarda standart nəticə boşluq zamanı trafiki yenə də buraxır.

Yoxlama 1: blok öz çeviricisidirmi?

Android 10 və sonrasında saxlanmış VPN profili dişli çarx ikonunun arxasında iki müstəqil keçid açır: Always-on VPN və VPN olmadan bağlantıları blokla. Yalnız ikincisi kill switch-dir. Tək always-on ilə tunel düşmədən sonra qayıdır, lakin sorğunun ortasındakı hər hansı tətbiq o vaxta qədər Wi-Fi və ya mobil data ilə şəbəkəyə çatır.

İdarə olunan cihazlar siyasət API-də eyni bölgünü saxlayır. setAlwaysOnVpnPackage() paket adını və lockdownEnabled bayrağını alır; paketi qoyub bayrağı yalançı saxlayan administrator davamlı tunel qurur, bağlı cihaz yox. Konsolun ifadəsi bu fərqi nadir hallarda göstərir.

Vəziyyəti konsoldan deyil, cihazdan oxuyun: adb shell settings get global always_on_vpn_app və adb shell settings get global always_on_vpn_lockdown. Birincisi null qaytarırsa, platform səviyyəsində heç bir paket tətbiq edilmir; ikincisi 0 qaytarırsa, platform heç nəyi bloklamır. Android VPN təlimatı bunları bir rejim deyil, ayrı imkanlar kimi təsvir edir.

Yoxlama 2: blok hansı qatındır?

Etiketlər klientdə, bloklar adətən firewall-da yaşayır, ona görə eyni söz hər platformada başqa şey bildirir. Aşağıdakı sətirlər hər hansı birinə güvənməzdən əvvəl təsdiqlənməyə dəyər.

Windows bloklamayan etiketin ən aydın nümunəsidir. Always On orada tunelin davamlılığını təsvir edir: maşın autentifikasiyası üçün cihaz tuneli, daxil olmuş hesab üçün istifadəçi tuneli, profil XML-i və ya Add-VpnConnection ilə qurulur. Həmin profildə tunel olmadıqda heç nə çıxan paketi dayandırmır və çıxan filtrasiya standart olaraq aktiv deyil, ona görə Wi-Fi-dakı noutbuk VPN söndüyü halda işləməyə davam edir.

WireGuard da eyni şəkildə bölünür, amma klient üzrə. Windows üçün WireGuard-da hər tunel üçün Tunelsiz trafiki blokla seçimi var və filtr qaydaları quraşdırır; Linux alətlərində belə keçid yoxdur. wg-quick hər AllowedIPs girişi üçün marşrut və fwmark qaydası əlavə edir, wg-quick down hər ikisini silir, beləliklə fiziki standart marşrut arada paket itirmədən yenidən işə düşür.

Apple platformalarında always-on nəzarət olunan cihazlar üçün idarəetmə profili funksiyası kimi gəlir və qeyd qutusu deyil, tələb üzrə qaydalar kimi ifadə olunur. Yükləmədən cavablandırılmalı sual budur: uğursuz tunel trafiki rədd edir, yoxsa sadəcə başqa bağlantı istəyir. Menyu başlığı bunu deməyəcək.

Yoxlama 3: boşluğu ölçün, ikonu yox

Dörd keçid vacibdir və fərqli şəkildə uğursuz olur: heç kim daxil olmadan yükləmə, yuxu və oyanma, Wi-Fi-dan mobil dataya keçid və tunel interfeysini yarımkonfiqurasiyalı qoyan klient qəzası. Birində təmiz yenidən qoşulma digər üçü haqqında heç nə sübut etmir.

Ən ucuz test tuneli qəsdən dayandırır və sonra çıxmağa çalışır. Tunel söndüyü halda curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com əmr ini 200 qaytarırsa, siyasət fail-open-dur; fasilə və ya rədd edilmiş bağlantı hələ nəyinsə blokladığını göstərir. ip route get 1.1.1.1 paketi daşıyacaq interfeysi adlandırır, bu adətən tepsi ikonundan daha çox deyir və systemctl status wg-quick@wg0 interfeysin təmiz silinib-silinmədiyini göstərir.

Şəbəkə dəyişərkən eyni yoxlamanı ikinci pəncərədə işə salın, yalnız sabitləşdikdən sonra deyil. Düşmə ilə təkrar cəhd arasındakı fasilə vacib hissədir və ad həllinin yoxlanması trafikin qaçdığını görməyin ən sürətli yoludur: tunel söndüyü halda yerli həlledici cavab verirsə, blok tamamlanmayıb.

Yoxlama 4: kilidləməzdən əvvəl istisnaları qərar verin

İki istisna strukturludur. Klient VPN serverinə özü çatmalıdır, ona görə hər şeyi atan qayda dəsti müdafiəni bərpa edəcək yenidən qoşulmanı da maneə törədir. Kaptiv portal da qalxmamış tuneldən əlçatmazdır, ona görə otel Wi-Fi-da kilidli cihaz portalı açmaq üçün sənədləşdirilmiş yol istəyir, improvizə olunmuş yox.

Minimal forma, son nöqtə icazəli və qalan hər şey atılıb:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Bu son nöqtə sətrini sabit deyil, dəyişən kimi qəbul edin. Provayderlər ünvanları dəyişir və köhnəlmiş istisna işləyən kill switch-in yenidən qoşula bilməyən cihaza çevrilməsinin adi səbəbidir. Yerli printerlər, NAS paylaşımları və inkişaf xidmətləri də eyni yazılı siyahıya aiddir, əks halda bir-bir dəstək biletləri ilə aşkar olunurlar.

Yoxlama 5: həqiqətən nə sübut etdiyinizi qeyd edin

Dörd sütunlu cədvəl saxlayın və test edərək doldurun: vəziyyət, gözlənilən davranış, müşahidə olunan davranış, sübut. Sətirlər yoxlama 3-dəki keçidlər və bir qəsdən edilmiş uğursuzluqdur. Əmr çıxışı ilə doldura bilmədiyiniz sətir yoxlamadığınız sətirdir və yenidən qoşulma sətrini keçib yükləmə sətrində uğursuz olan cihaz əlavə on dəqiqəyə dəyəcək qədər adidir.

Bitmiş adlandırmazdan əvvəl:

• Bloklama parametrinin yenidən qoşulma parametrindən ayrı olduğunu təsdiqləyin və dəyərini cihazda oxuyun.
• Bloku hansı qatın tətbiq etdiyini bilin - klient seçimi, cihaz siyasəti və ya firewall - və o qatın harada qurulduğunu.
• Bloku sübut edən bir yoxlama əmri saxlayın və onu keçid zamanı işə salın, sonra yox.
• İstisna siyahısını yazın, son nöqtə daxil olmaqla, və kimin yenilədiyini qeyd edin.
• İdarə olunan avadanlıqda tətbiq edilmiş siyasəti tək buraxın; bloku silmək tuneli düzəltmək əvəzinə tələbi dəyişir.