Rootsiz Android VPN: rozilik, marshrutlar va bloklash kimga tegishli
Rozilik, TUN interfeysi va tizimning bloklash siyosati uch xil ruxsatdir. Android VPN ilovasini ko'rib chiqishdan oldin har biri qaysi komponentga tegishli ekanini aniqlang.
Root Android VPN ilovasiga trafikni tashish, oqishlarni bloklash yoki qayta yuklashdan keyin ishlash imkonini beradigan narsa emas. Odamlar bularning barchasini „ilovada VPN ruxsati bor“ deb umumlashtiradi, bu esa uchta alohida mexanizmni yashiradi: foydalanuvchi bergan rozilik, tizim yaratadigan paket interfeysi va ilova belgilamaydigan platforma bloklash siyosati. Android VPN dizaynini ko'rib chiqish qaysi da'vo haqiqatan shu uchtadan qaysi biriga tayanishini so'rash demakdir, chunki har birining egasi va muvaffaqiyatsizlik usuli boshqacha.
Rozilik tizim faoliyati orqali keladi
VpnService.prepare() hech narsa bermaydi. Rozilik bo'lmaganda u tizimning rozilik faoliyatiga intent qaytaradi va ilova foydalanuvchi xizmatni tasdiqlashi uchun o'sha muloqot oynasini ochadi. Ilovaning o'z jarayonini ishga tushirish, manifestga ruxsat qo'shish yoki maxsus „VPN yoqish“ ekranini ko'rsatish rozilikni yaratmaydi.
Rozilikning qamrovi ham bor. U foydalanuvchi profilidagi paketga tegishli, shuning uchun shaxsiy nusxa va ish nusxasi alohida qarorlar, qurilma egasi esa boshqariladigan profilni shaxsiydan boshqacha tayyorlashi mumkin. Agar muloqot oynasi hech qachon chiqmasa va prepare() null qaytarsa, o'sha profildagi o'sha paket uchun rozilik allaqachon mavjud; bu ilovaning ishonchli ekaniga dalil emas, faqat ruxsat mavjudligini bildiradi.
Interfeys — tizim bajaradigan so'rov
Rozilikdan keyin ilova nima istashini VpnService.Builder orqali tavsiflaydi: manzillar, marshrutlar, DNS serverlari, MTU va qo'llab-quvvatlangan joylarda kiritiladigan yoki chiqariladigan ilovalar. establish() tizimdan tunnel interfeysini yaratishni va mos trafikni unga yo'naltirishni so'raydi. Marshrutlash qarori tizimga tegishli; ilova fayl deskriptorini oladi va keyin paketlar bilan foydali ish qilishi kerak.
| What you observe | Who actually owns it |
|---|---|
| VPN consent dialog | The system, triggered by prepare() |
| Routes, DNS and app lists | The app requests them; the system applies them |
| One active VPN per profile | The platform; a new service replaces the old one |
| Always-on and block-without-VPN | Device policy enforced by the platform |
Bu jadval arxitekturani bir joyda ko'rsatadi. Ilova paketlarni qayta ishlashda qatnashadi; interfeys, marshrutlash jadvali yoki ishlashi mumkin bo'lgan xizmatlar soni unga tegishli emas.
Tunnel soketi o'z tunnelidan qochishi kerak
Shifrlangan trafikni tashuvchi ulanishning o'zi soketdir. Agar u ilova hozir yaratgan interfeysga qaytarilsa, tunnel tunnelga bog'liq bo'lib to'xtaydi. VpnService.protect() o'sha soketni pastki tarmoqqa bog'laydi, shunda u ushlashdan o'tib ketadi, shuning uchun to'g'ri mijoz birinchi qo'l siqishdan oldin tashqi soketini himoya qiladi.
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_lockdownBu buyruqlar o'rnatilgan VPN tarmog'ini, doim yoniq paketni va qulflash o'rnatilganligini ko'rsatadi. Bular faqat o'qish uchun kuzatuvlar: agar qiymatlar dizayn da'vo qilgan narsaga mos kelmasa, da'vo tizim holati haqida emas, ilova interfeysi haqida.
Bloklash platformaga tegishli bo'lishi mumkin
Android VPN ishlatmaydigan ulanishlarni bloklaydigan siyosatni hujjatlashtiradi. Bu ijro platforma shartnomasi, ilovaning sikl ichida ulanishni qayta urinishi emas. Kalit qurilmaning VPN sozlamalarida „VPNsiz ulanishlarni bloklash“ sifatida joylashgan va boshqariladigan qurilmada egasi uni butun profil uchun yoqishi mumkin. Bu farq marketing da'vosini baholashda muhim: mijoz qulf belgisini ko'rsatib, tajovuzkor tarzda qayta ulanashi mumkin, ammo to'g'ridan-to'g'ri trafik hali ham mumkin; yoki qamrab olingan ilovalar tizim qulfni qo'llayotgani uchun oflayn qolishi mumkin.
Qulf belgisini ilova chizadi, shuning uchun u faqat ilova o'zini ulangan deb hisoblashini isbotlaydi. Boshqa ilova tarmoq ruxsatini yo'qotadimi — buni platforma hal qiladi, shuning uchun foydali tekshiruv tunnel yoniq turganda o'sha ilovaning ishlamay qolishini kuzatishdir.
Ilova do'konining „doim yoniq“ yorlig'i ham bu shartnomani almashtirmaydi. Doim yoniq va qulflash qurilma sozlamalari bo'lib, ularni ko'pincha qurilma egasi qo'llaydi, chiqarib tashlangan ilovalar uchun xatti-harakatni platforma belgilaydi. Sozlamani o'qing, belgini emas.
Dizayn ko'rigi uchun to'rtta savol
Birinchidan, kim rozilik berdi: qaysi paket, qaysi profil va bu foydalanuvchimi yoki boshqariladigan qurilma siyosatimi? Ikkinchidan, ilova nima so'radi: qanday marshrutlar, qanday manzil oilalari, qanday ilovalar kiritildi yoki chiqarildi? Uchinchidan, tunnel mavjud bo'lmaganda nima bo'ladi: tizim bloklaydimi yoki trafik pastki tarmoqqa qaytadimi? To'rtinchidan, ilova olgan paketlar bilan nima qiladi?
To'rtinchi savol — ruxsat modeli javob bera olmaydigan savol. Rozilik va TUN interfeysi ilovaning trafik olishini isbotlaydi, uni shifrlashini, tomonni autentifikatsiya qilishini yoki toza tiklanishini emas. Bular amalga oshirish xossalari va aynan shu yerda halol ko'rik vaqtini o'tkazadi.
Keraksiz root so'rovi natijani „kill switch“ deb atash bilan qonuniy bo'lmaydi, rozilik muloqoti esa xavfsizlik auditi emas. Uch ruxsatni alohida saqlang, har bir da'vo tekshiriladigan bo'ladi.