iPhone-da Always On VPN və VPN On Demand: nə tətbiq etməli
On Demand qaydaları uyğun gəldikdə tunel açır; idarə olunan Always On nəzarətli cihazlarda əhatəni məcburi saxlayır. Birini seçmək və işlədiyini sübut etmək üçün təlimat.
İki iPhone da VPN dediyini deyə bilər, amma tamamilə fərqli davranır. On Demand qayda uyğun gəldikdə tunel açır və istifadəçi onu Tənzimləmələrdən yenə söndürə bilər. İdarə olunan Always On isə nəzarətli cihazda tunel qalxa bilmədiyi anlarda belə əhatəni məcburi saxlayır. İstifadəçi heç nə etmədikdə nəyin doğru olmalı olduğunu soruşaraq seçin, sonra sabit vəziyyəti deyil, keçidləri sınaqdan keçirin. Aşağıdakı addımlar tətbiqin həqiqətən uğursuz olduğu sıradadır.
Addım 1: cihazın nəyi məcbur edə biləcəyini müəyyənləşdirin
Always On nəzarətli cihazlara aid funksiyadır. Park nəzarətli deyilsə, müzakirə başlamadan bitir və heç bir payload açarı nəzarətsiz telefonu məcburi telefona çevirmir. Nəzarəti idarəetmə tərəfindən və cihazın özündən təsdiqləyin, sonra profili kimin imzaladığını təsdiqləyin.
Telefonda Tənzimləmələr, sonra Ümumi, sonra VPN və Cihaz İdarəetməsi açın. Profil qeydi sahibini göstərir və əl ilə quraşdırılmış şəxsi profil idarəetmə xidmətindən gələndən fərqli görünür. Məcburiliyi profilin adından və ya provayderin marketinq etiketindən çıxarmayın; etiket platformanın siyasəti deyil.
Konfiqurasiyaya toxunmadan əvvəl üç faktı yazın: nəzarətli olub-olmaması, idarə olunan yoxsa şəxsi profil, və tuneli hansı müştəri tətbiqinin daşıdığı. Sonrakı hər addım bu üçündən asılıdır və davranışı şəxsi telefondan idarə olunan profilə köçürmək tətbiqi yanlış baza üzrə təsdiqləməyin yoludur.
Addım 2: funksiyanın adını deyil, on-demand qaydalarını oxuyun
On Demand sıra ilə qiymətləndirilən qaydalar siyahısıdır. Hər qayda bir əməliyyat və onu seçən şərtləri adlandırır, şərtlər isə ən maraqlı hissədir: interfeys tipi, Wi-Fi SSID, DNS domen şəkilçisi və ya yoxlama URL-i. Heç vaxt uyğun gəlməyən qayda dəsti heç vaxt qoşulmayan funksiyadır.
<key>OnDemandRules</key>
<array>
<dict>
<key>Action</key><string>EvaluateConnection</string>
<key>InterfaceTypeMatch</key><string>WiFi</string>
<key>SSIDMatch</key><array><string>Office-WiFi</string></array>
</dict>
</array>
Bütün massivi oxuyun və hər qayda üçün iki sual verin: bu şərt bu parkda heç vaxt doğru ola bilərmi və heç bir qayda uyğun gəlmədikdə nə olur? Müəssisə şəbəkələri giriş nöqtələrini adlandırır, SSID-ləri birləşdirir və DNS şəkilçilərini dəyişir; bu düzəlişlərin hər biri qaydanı reallıqdan səssizcə ayırır.
DNS şəkilçisi şərti sahədə ən çox səhv olan şərtdir, çünki telefonun qonaq şəbəkəsində bildirdiyi şəkilçi korporativ həlledicinin xidmət etdiyi şəkilçi deyil. Qaydaya güvənməzdən əvvəl cihazın həqiqətən həll etdiyi adı yoxlayın.
Addım 3: statik bağlantını deyil, keçidləri sınayın
Baxdığınız anda qalxan tunel çox az sübut edir. Hər keçidi qəsdən icra edin və cihazın nə etdiyini qeyd edin, nəticələr müqayisə olunsun deyə hər dəfə eyni şəxsi resursdan istifadə edin:
- Qaydanın uyğun gəlməli olduğu şəbəkəyə qoşulun, sonra şəxsi resursu tələb edin və yükləndiyini təsdiqləyin.
- Tətbiq arxa planda ikən mobil şəbəkəyə keçin, sonra onu ön plana gətirin və sorğunu təkrarlayın.
- Captive portal olan Wi-Fi-a qoşulun və portalın əldə oluna bildiyini, yoxsa məcburiliyin autentifikasiyadan əvvəl onu blokladığını görün.
- Nəzarətli cihazda tuneli əl ilə söndürün və özü geri qayıdıb-qayıtmadığını və nə qədər tez olduğunu yoxlayın.
Əgər varsa, eyni siyahını nəzarətsiz cihazda icra edin. İki nəticə arasındakı fərq tətbiqin əsl davranışıdır və qoşulmuş tunelin şəkli bunu heç vaxt göstərmir.
Addım 4: iki uğursuzluq formasını bilin
Məcburi əhatə bloklama ilə uğursuz olur. Tunel qurula bilmədikdə cihaz şəxsi resurslarla birlikdə adi internet çıxışını itirir və istifadəçi onlayn olan, amma baxa bilməyən telefonla üzləşir. Yenidən qoşulma və bloklama ayrı müşahidələrdir, ona görə ikisini də qeyd edin, internetin olmamasını bir simptom kimi qiymətləndirməyin.
On Demand işə düşməməklə uğursuz olur. Qayda uyğun gəlmir, tunel görünmür və şəxsi resurs sadəcə vaxt aşımına uğrayır. Bunu server problemi kimi səhv diaqnoz etmək asandır, çünki müştəri konfiqurasiya edildiyi kimi davranır.
Captive portal ikisinin arasında durur: tunel yaranmazdan əvvəl bağlantı tələb edir, ona görə tunel qalxana qədər hər şeyi bloklayan siyasət portal vasitəsilə sənədləşdirilmiş yol tələb edir. Bunu dizayn mərhələsində qərar verin, dəstək masasında deyil.
Addım 5: yoxlayın, sonra geri qaytarmanı məşq edin
Yoxlama real yol üzərində zərərsiz trafiklə aparılır: ictimai olmamalı olan şəxsi resursu tələb edin, cihazın xaricə hansı ünvanı təqdim etdiyini təsdiqləyin və yenidən başlatmadan sonra təkrarlayın ki, başlanğıc ardıcıllığını görəsiniz, yalnız isti vəziyyəti deyil.
Sonra istehsalda lazım olmadan əvvəl sınaq cihazında silinməni məşq edin. Profili silmək cihazı əvvəlki vəziyyətinə qaytarır və bunun nə qədər çəkdiyini və istifadəçinin nə gördüyünü bilmək runbook-un hissəsidir. Apple-ın VPN təhlükəsizlik bələdçisi platformanın bu siyasətlər barədə sənədləşdirdiyi üçün mənbədir və platformadan artıq iddia edən konfiqurasiya yazmazdan əvvəl oxumağa dəyər.
Birinci addımdakı üç faktı qayda dəstinin və sınaq nəticələrinin yanında saxlayın. Növbəti şəxs niyə bir telefonda bir şəbəkəyə qoşulduğunu, digərində qoşulmadığını soruşanda bu qeydlər yenidən qurmaq əvəzinə bir dəqiqədə cavab verir.