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 |
Та табела је архитектура на једном месту. Апликација учествује у обради пакета; не поседује интерфејс, табелу рутирања ни број услуга које смеју да раде.
Тунелски socket мора побећи из сопственог тунела
Веза која преноси шифровани саобраћај и сама је socket. Ако се усмери натраг у интерфејс који је апликација управо створила, тунел зависи од тунела и стаје. VpnService.protect() везује тај socket за доњу мрежу тако да заобиђе хватање, и зато исправан клијент штити свој спољни socket пре првог руковања.
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 не постаје легитиман ако се резултат назове прекидачем за убијање, а дијалог пристанка није безбедносни аудит. Држите три одобрења одвојено и свака тврдња постаје проверљива.