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 не станува легитимно со нарекување на резултатот прекинувач за убивање, а дијалогот за одобрување не е безбедносен аудит. Држете ги трите дозволи одделно и секое тврдење станува проверливо.