Android VPN без root: кой притежава съгласието, маршрутите и блокирането
Съгласието, 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 не става законна, ако резултатът се нарече прекъсвач, а диалогът за съгласие не е одит на сигурността. Дръжте трите разрешения отделно и всяко твърдение става проверимо.