Rootгүй Android VPN: зөвшөөрөл, маршрут, блоклох эрх хэнд байна
Зөвшөөрөл, TUN интерфейс, системийн блоклох бодлого нь гурван өөр зөвшөөрөл юм. Android VPN аппыг хянахын өмнө аль бүрэлдэхүүн нь аль нэгийг эзэмшиж байгааг тогтооно уу.
Root нь Android VPN аппад трафик зөөх, алдагдал хаах, дахин ачаалсны дараа ажиллах боломж олгодог зүйл биш. Хүмүүс энийг бүгдийг „апп VPN зөвшөөрөлтэй“ гэж хураангуйлдаг бөгөөд энэ нь гурван тусдаа механизмыг нуудаг: хэрэглэгчийн зөвшөөрөл, системийн үүсгэдэг багц интерфейс, апп тодорхойлох ёсгүй платформын блоклох бодлого. Android VPN загварыг хянах гэдэг нь аль нэг мэдэгдэл энэ гурвын алийг нь үнэхээр тулгуурлаж байгааг асуухыг хэлнэ, учир нь тус бүр өөр эзэмшигч, өөр бүтэлгүйтлийн горимтой.
Зөвшөөрөл системийн үйл ажиллагаагаар ирдэг
VpnService.prepare() юу ч өгөхгүй. Зөвшөөрөл байхгүй үед энэ нь системийн зөвшөөрлийн үйл ажиллагаа руу intent буцааж, апп тэр харилцах цонхыг нээж хэрэглэгч үйлчилгээг зөвшөөрнө. Аппын өөрийн процесс эхлүүлэх, манифестэд зөвшөөрөл нэмэх, эсвэл өөрийн „VPN идэвхжүүлэх“ дэлгэц үзүүлэх нь зөвшөөрлийг үүсгэхгүй.
Зөвшөөрөл нь хүрээгээрээ ч хязгаарлагддаг. Энэ нь хэрэглэгчийн профайл дахь багцад хамаарах тул хувийн хуулбар, ажлын хуулбар нь тусдаа шийдвэр бөгөөд төхөөрөмжийн эзэмшигч удирдлагатай профайлыг хувийн профайлаас өөрөөр бэлтгэж болно. Хэрэв харилцах цонх хэзээ ч гарахгүй бөгөөд prepare() null буцаавал, тухайн профайл дахь тухайн багцад зөвшөөрөл аль хэдийн байна; энэ нь апп найдвартай гэдгийн баталгаа биш, зөвшөөрөл байгааг л харуулна.
Интерфейс бол системийн биелүүлдэг хүсэлт
Зөвшөөрлийн дараа апп VpnService.Builder ашиглан юу хүсэж байгаагаа тодорхойлно: хаягууд, маршрутууд, DNS серверүүд, MTU, дэмжигдсэн газарт оруулах эсвэл хасах аппууд. establish() системд туннелийн интерфейс үүсгэж, тохирох трафикийг тийш чиглүүлэхийг хүснэ. Чиглүүлэх шийдвэр системд хамаарна; апп файлын тодорхойлолтыг авч, дараа нь багцуудтай ямар нэг ашигтай зүйл хийх ёстой.
| 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 |
Тэр хүснэгт нь архитектурыг нэг дор харуулна. Апп багц боловсруулалтад оролцдог; интерфейс, чиглүүлэх хүснэгт, ажиллах боломжтой үйлчилгээний тоо түүний эзэмшилд байхгүй.
Туннелийн сокет өөрийн туннелээс зугтах ёстой
Шифрлэгдсэн трафик зөөдөг холболт өөрөө сокет юм. Хэрэв үүнийг апп саяхан үүсгэсэн интерфейс рүү буцааж чиглүүлбэл, туннель туннелээс хамаарч гацна. VpnService.protect() тэр сокетыг доод сүлжээнд холбож, барилтаас зайлсхийх боломж олгодог, тиймээс зөв клиент эхний гар барилтын өмнө гадаад сокетоо хамгаалдаг.
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Эдгээр команд нь суулгасан VPN сүлжээ, байнга асаалттай багц, түгжээ тохируулагдсан эсэхийг харуулна. Эдгээр нь зөвхөн уншихад зориулсан ажиглалт юм: утгууд загварын мэдэгдэлтэй тохирохгүй бол мэдэгдэл системийн төлөв биш, аппын интерфейсийн тухай юм.
Блоклолт платформд хамаарч болно
Android нь VPN ашигладаггүй холболтыг блоклодог бодлогыг баримтжуулдаг. Тэр хэрэгжилт нь платформын гэрээ бөгөөд апп давталтад холболтыг дахин оролддоггүй. Унтраалга нь төхөөрөмжийн VPN тохиргоонд „VPNгүйгээр холболтыг блоклох“ гэж байрлаж, удирдлагатай төхөөрөмж дээр эзэмшигч бүх профайлд асааж болно. Маркетингийн мэдэгдлийг үнэлэхэд энэ ялгаа чухал: клиент түгжээний дүрс харуулж, түрэмгий дахин холбогдож болох боловч шууд трафик боломжтой хэвээр байна, эсвэл хамрагдсан аппууд систем түгжээг хэрэгжүүлж байгаа тул офлайн үлдэж болно.
Түгжээний дүрсийг апп зурдаг тул зөвхөн апп холбогдсон гэж итгэж байгааг нотолно. Өөр апп сүлжээний хандалтаа алдах эсэхийг платформ шийддэг тул ашигтай шалгалт нь туннель асаалттай үед тэр апп бүтэлгүйтэхийг харах юм.
Апп дэлгүүрийн „байнга асаалттай“ шошго ч тэр гэрээг орлохгүй. Байнга асаалттай, түгжээ нь төхөөрөмжийн тохиргоо бөгөөд ихэвчлэн эзэмшигч хэрэглэдэг, хасагдсан аппуудад үзүүлэх зан төлөвийг платформ тодорхойлдог. Тохиргоог уншаарай, шошгыг биш.
Загвар хяналтад дөрвөн асуулт
Нэгд, хэн зөвшөөрсөн: аль багц, аль профайл, хэрэглэгч үү эсвэл удирдлагатай төхөөрөмжийн бодлого юу? Хоёрт, апп юу хүссэн: ямар маршрут, ямар хаягийн гэр бүл, ямар апп оруулсан эсвэл хассан? Гуравт, туннель боломжгүй үед юу болдог: систем блоклодог уу эсвэл трафик доод сүлжээ рүү буцдаг уу? Дөрөвт, апп хүлээн авсан багцуудаар юу хийдэг вэ?
Дөрөв дэх асуулт нь зөвшөөрлийн загвар хариулж чадахгүй асуулт юм. Зөвшөөрөл ба TUN интерфейс нь апп трафик хүлээн авч чадна гэдгийг нотолдог, түүнийг шифрлэдэг, талыг баталгаажуулдаг эсвэл цэвэрхэн сэргэдэг гэдгийг биш. Эдгээр нь хэрэгжүүлэлтийн шинж чанар бөгөөд шударга хяналт цагаа тэнд өнгөрүүлдэг.
Шаардлагагүй root хүсэлт үр дүнг „kill switch“ гэж нэрлэснээр хууль ёсны болохгүй, зөвшөөрлийн харилцах цонх нь аюулгүй байдлын аудит биш. Гурван зөвшөөрлийг тусад нь байлга, тэгвэл мэдэгдэл бүр шалгах боломжтой болно.