Android VPN bez rootu: komu patří souhlas, trasy a blokování
Souhlas, rozhraní TUN a systémová politika blokování jsou tři různá oprávnění. Sledujte, která komponenta vlastní každé z nich, než začnete recenzovat aplikaci Android VPN.
Root není to, co umožňuje aplikaci Android VPN přenášet provoz, blokovat úniky nebo přežít restart. Lidé to všechno shrnují jako „aplikace má oprávnění VPN“, což skrývá tři oddělené mechanismy: souhlas udělený uživatelem, paketové rozhraní, které vytvoří systém, a politiku blokování platformy, kterou aplikace nedefinuje. Recenzovat návrh Android VPN znamená ptát se, o kterou z těch tří se tvrzení skutečně opírá, protože každá má jiného vlastníka a jiný způsob selhání.
Souhlas přichází skrze systémovou aktivitu
VpnService.prepare() nic neuděluje. Vrací intent systémové aktivitě pro souhlas, když souhlas chybí, a aplikace tento dialog spustí, aby uživatel službu schválil. Spuštění vlastního procesu aplikace, přidání oprávnění do manifestu nebo zobrazení vlastní obrazovky „zapnout VPN“ oprávnění nevytváří.
Oprávnění je také omezené rozsahem. Patří balíčku v uživatelském profilu, takže osobní kopie a pracovní kopie jsou samostatná rozhodnutí a vlastník zařízení může spravovaný profil připravit jinak než osobní. Pokud se dialog nikdy neobjeví a prepare() vrátí null, souhlas už pro tento balíček v tomto profilu existuje; není to důkaz, že je aplikace důvěryhodná, jen že oprávnění existuje.
Rozhraní je požadavek, který systém splní
Po souhlasu aplikace popíše, co chce, pomocí VpnService.Builder: adresy, trasy, servery DNS, MTU a tam, kde je to podporováno, aplikace k zahrnutí nebo vyloučení. establish() požádá systém o vytvoření tunelového rozhraní a směrování odpovídajícího provozu do něj. Rozhodnutí o směrování vlastní systém; aplikace dostane deskriptor souboru a pak musí s pakety udělat něco užitečného.
| 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 |
Tato tabulka je architektura na jednom místě. Aplikace se účastní zpracování paketů; nevlastní rozhraní, směrovací tabulku ani počet služeb, které smějí běžet.
Tunelový socket musí uniknout ze svého vlastního tunelu
Spojení, které přenáší šifrovaný provoz, je samo socket. Pokud je směrováno zpět do rozhraní, které aplikace právě vytvořila, tunel závisí na tunelu a zastaví se. VpnService.protect() připoutá tento socket k podkladové síti, aby obešel zachytávání, a proto správný klient chrání svůj vnější socket před prvním handshake.
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_lockdownTyto příkazy ukazují nainstalovanou síť VPN, balíček trvalého zapnutí a zda je nastaveno blokování. Jsou to pozorování jen pro čtení: pokud se hodnoty neshodují s tím, co tvrdí návrh, tvrzení se týká rozhraní aplikace, nikoli stavu systému.
Blokování může patřit platformě
Android dokumentuje politiku, která blokuje připojení, jež nepoužívají VPN. To vynucení je smlouvou platformy, ne aplikací, která v cyklu opakuje pokusy o připojení. Přepínač je v nastavení VPN zařízení jako Blokovat připojení bez VPN a na spravovaném zařízení jej vlastník může zapnout pro celý profil. Rozdíl je důležitý při hodnocení marketingového tvrzení: klient může zobrazit ikonu zámku a agresivně se znovu připojovat, zatímco přímý provoz je stále možný, nebo pokryté aplikace mohou zůstat offline, protože systém vynucuje blokování.
Ikonu zámku kreslí aplikace, takže dokazuje jen to, že aplikace věří, že je připojená. Zda jiná aplikace ztratí přístup k síti, rozhoduje platforma, takže užitečná kontrola je sledovat, jak tato aplikace selhává, dokud je tunel aktivní.
Ani štítek „trvale zapnuto“ z obchodu s aplikacemi tuto smlouvu nenahrazuje. Trvalé zapnutí a blokování jsou nastavení zařízení, často aplikovaná vlastníkem, a jejich chování pro vyloučené aplikace určuje platforma. Čtěte nastavení, ne odznak.
Čtyři otázky pro recenzi návrhu
Za prvé, kdo dal souhlas: který balíček, který profil a byl to uživatel, nebo politika spravovaného zařízení? Za druhé, co aplikace požadovala: které trasy, které rodiny adres, které zahrnuté nebo vyloučené aplikace? Za třetí, co se stane, když tunel není dostupný: blokuje systém, nebo provoz propadne do podkladové sítě? Za čtvrté, co aplikace dělá s pakety, které obdrží?
Čtvrtá otázka je ta, na kterou model oprávnění neumí odpovědět. Souhlas a rozhraní TUN dokazují, že aplikace může přijímat provoz, ne že jej šifruje, autentizuje protistranu nebo se čistě zotaví. To jsou vlastnosti implementace a právě tam poctivá recenze tráví čas.
Nepotřebný požadavek na root se nestane legitimním tím, že se výsledek nazve kill switch, a dialog souhlasu není bezpečnostní audit. Držte tři oprávnění oddělená a každé tvrzení se stane ověřitelným.