Root Android VPN tətbiqinə trafiki daşımaq, sızmaları bloklamaq və ya yenidən başladıqdan sonra işləməyə davam etmək imkanı verən şey deyil. İnsanlar bütün bunları «tətbiqin VPN icazəsi var» kimi ümumiləşdirir və bu, üç ayrı mexanizmi gizlədir: istifadəçi razılığı, sistemin yaratdığı paket interfeysi və tətbiqin müəyyən etmədiyi platforma bloklama siyasəti. Android VPN dizaynını nəzərdən keçirmək hansı iddianın bu üçündən hansına dayandığını soruşmaqdır, çünki hər birinin sahibi və uğursuzluq rejimi fərqlidir.

Razılıq sistem fəaliyyəti vasitəsilə gəlir

VpnService.prepare() heç nə vermir. Razılıq yoxdursa, o, sistem razılıq fəaliyyətinə intent qaytarır və tətbiq həmin dialoqu açır ki, istifadəçi xidməti təsdiqləsin. Tətbiqin öz prosesini başlatmaq, manifestə icazə əlavə etmək və ya fərdi «VPN-i aktivləşdir» ekranı göstərmək razılığı yaratmır.

Razılıq həm də məhdud əhatəlidir. O, istifadəçi profilindəki paketə aiddir, buna görə şəxsi nüsxə və iş nüsxəsi ayrı qərarlardır və cihaz sahibi idarə olunan profili şəxsi profildən fərqli hazırlaya bilər. Dialoq heç görünmürsə və prepare() null qaytarırsa, razılıq həmin profildə həmin paket üçün artıq mövcuddur; bu, tətbiqin etibarlı olmasına sübut deyil, yalnız razılığın yerində olduğunu göstərir.

Interfeys sistemin yerinə yetirdiyi sorğudur

Razılıqdan sonra tətbiq nə istədiyini VpnService.Builder ilə təsvir edir: ünvanlar, marşrutlar, DNS serverləri, MTU və dəstəkləndiyi yerdə daxil ediləcək və ya xaric ediləcək tətbiqlər. establish() sistemdən tunel interfeysini yaratmağı və uyğun trafiki ona yönəltməyi xahiş edir. Marşrut qərarı sistemə aiddir; tətbiq fayl deskriptorunu alır və sonra paketlərlə faydalı bir şey etməlidir.

What you observeWho actually owns it
VPN consent dialogThe system, triggered by prepare()
Routes, DNS and app listsThe app requests them; the system applies them
One active VPN per profileThe platform; a new service replaces the old one
Always-on and block-without-VPNDevice policy enforced by the platform

Bu cədvəl arxitekturanı bir yerdə göstərir. Tətbiq paket emalında iştirak edir; interfeys, marşrut cədvəli və ya işləyə biləcək xidmətlərin sayı ona aid deyil.

Tunel soketi öz tunelindən çıxmalıdır

Şifrələnmiş trafiki daşıyan bağlantı özü bir soketdir. Əgər o, tətbiqin yenicə yaratdığı interfeysə geri yönəldilirsə, tunel tuneldən asılı olur və dayanır. VpnService.protect() həmin soketi alt şəbəkəyə bağlayır ki, tutmadan yan keçsin; buna görə düzgün müştəri ilk əl sıxmaadan əvvəl öz xarici soketini qoruyur.

adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdown

Bu əmrlər quraşdırılmış VPN şəbəkəsini, daimi işləyən paketi və kilidin qurulub-qurulmadığını göstərir. Onlar yalnız oxuna bilən müşahidələrdir: dəyərlər dizaynın iddia etdiyi ilə uyğun gəlmirsə, iddia sistemin vəziyyətinə deyil, tətbiqin interfeysinə aiddir.

Bloklama platformaya aid ola bilər

Android VPN-dən istifadə etməyən bağlantıları bloklayan siyasəti sənədləşdirir. Bu tətbiqetmə platforma müqaviləsidir, tətbiqin bağlantıları dövri olaraq yenidən cəhd etməsi deyil. Açar cihazın VPN ayarlarında «VPN olmadan bağlantıları blokla» adı ilə yerləşir və idarə olunan cihazda cihaz sahibi onu bütün profil üçün yandıra bilər. Marketinq iddiasını qiymətləndirərkən bu fərq vacibdir: müştəri kilid ikonu göstərib aqressiv şəkildə yenidən qoşula bilər, halbuki birbaşa trafik hələ də mümkündür; ya da əhatə olunan tətbiqlər sistem kilidi tətbiq etdiyi üçün oflayn qala bilər.

Kilid ikonunu tətbiq çəkir, buna görə o yalnız tətbiqin qoşulduğuna inandığını sübut edir. Başqa tətbiqin şəbəkə girişini itirib-itirmədiyini platforma həll edir, buna görə faydalı yoxlama tunel işləyərkən həmin tətbiqin uğursuzluğunu izləməkdir.

Tətbiq mağazasının «daimi işləyən» etiketi də bu müqaviləni əvəz etmir. Daimi işləmə və kilid cihaz ayarlarıdır, çox vaxt cihaz sahibi tərəfindən tətbiq olunur və xaric edilmiş tətbiqlər üçün davranışı platforma müəyyən edir. Nişanı deyil, ayarı oxuyun.

Dizayn baxışı üçün dörd sual

Birincisi, kim razılıq verdi: hansı paket, hansı profil və bu istifadəçi, yoxsa idarə olunan cihaz siyasəti idi? İkincisi, tətbiq nə xahiş etdi: hansı marşrutlar, hansı ailələr, hansı daxil edilmiş və ya xaric edilmiş tətbiqlər? Üçüncüsü, tunel əlçatan olmadıqda nə olur: sistem bloklayır, yoxsa trafik alt şəbəkəyə qayıdır? Dördüncüsü, tətbiq aldığı paketlərlə nə edir?

Dördüncü sual icazə modelinin cavab verə bilmədiyi sualdır. Razılıq və TUN interfeysi tətbiqin trafik ala bildiyini sübut edir, onu şifrələdiyini, qarşı tərəfi doğruladığını və ya təmiz bərpa olunduğunu deyil. Bunlar tətbiqetmə xassələridir və vicdanlı baxış vaxtını burada keçirir.

Lazımsız root sorğusu nəticəni öldürmə açarı adlandırmaqla qanuni olmur, razılıq dialoqu isə təhlükəsizlik auditi deyil. Üç icazəni ayrı saxlayın və hər iddia yoxlanıla bilən olur.

Əlaqəli məqalələr