VPN d'Android sense root: qui posseeix el consentiment, les rutes i el bloqueig
El consentiment, la interfície TUN i la política de bloqueig del sistema són tres permisos diferents. Rastreja quin component posseeix cadascun abans de revisar una aplicació VPN d'Android.
El root no és el que permet que una aplicació VPN d'Android transporti trànsit, bloquegi fuites o sobrevisqui a un reinici. La gent ho resumeix tot plegat com «l'aplicació té permís de VPN», cosa que amaga tres mecanismes separats: un consentiment atorgat per l'usuari, una interfície de paquets que el sistema estableix i una política de bloqueig de la plataforma que no correspon a l'aplicació definir. Revisar un disseny de VPN d'Android vol dir preguntar-se en quin dels tres descansa realment una afirmació, perquè cadascun té un propietari i un mode de fallada diferents.
El consentiment arriba per una activitat del sistema
VpnService.prepare() no atorga res. Retorna un intent a l'activitat de consentiment del sistema quan falta el consentiment, i l'aplicació obre aquest diàleg perquè l'usuari aprovi el servei. Iniciar el procés propi de l'aplicació, afegir un permís al manifest o mostrar una pantalla personalitzada d'«activa la VPN» no crea l'atorgament.
L'atorgament també té abast. Pertany a un paquet dins un perfil d'usuari, així que la còpia personal i la còpia de feina són decisions separades, i el propietari del dispositiu pot preparar un perfil gestionat de manera diferent d'un de personal. Si el diàleg no apareix mai i prepare() retorna null, el consentiment ja existeix per a aquest paquet en aquest perfil; no és cap prova que l'aplicació sigui fiable, només que l'atorgament hi és.
La interfície és una petició que compleix el sistema
Després del consentiment, l'aplicació descriu què vol amb VpnService.Builder: adreces, rutes, servidors DNS, MTU i, quan és compatible, les aplicacions a incloure o excloure. establish() demana al sistema que creï la interfície de túnel i que hi encamini el trànsit corresponent. El sistema posseeix la decisió d'encaminament; l'aplicació rep el descriptor de fitxer i llavors ha de fer alguna cosa útil amb els paquets.
| 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 |
Aquesta taula és l'arquitectura en un sol lloc. L'aplicació participa en el maneig de paquets; no posseeix la interfície, la taula d'encaminament ni el nombre de serveis que poden funcionar.
El sòcol del túnel ha d'escapar del seu propi túnel
La connexió que transporta el trànsit xifrat és ella mateixa un sòcol. Si s'encamina cap a la interfície que l'aplicació acaba de crear, el túnel depèn del túnel i s'atura. VpnService.protect() lliga aquest sòcol a la xarxa subjacent perquè eviti la captura, i per això un client correcte protegeix el seu sòcol exterior abans de la primera negociació.
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_lockdownAquestes ordres mostren la xarxa VPN instal·lada, el paquet d'activació permanent i si hi ha el bloqueig configurat. Són observacions només de lectura: si els valors no coincideixen amb el que afirma el disseny, l'afirmació és sobre la interfície de l'aplicació i no sobre l'estat del sistema.
El bloqueig pot pertànyer a la plataforma
Android documenta una política que bloqueja les connexions que no utilitzen la VPN. Aquest compliment és un contracte de la plataforma, no una aplicació que reintenta connexions en bucle. L'interruptor és a la configuració de VPN del dispositiu com a Bloca les connexions sense VPN, i en un dispositiu gestionat el propietari el pot activar per a tot el perfil. La distinció importa quan avalues una afirmació de màrqueting: un client pot mostrar una icona de cadenat i reconnectar-se agressivament mentre el trànsit directe encara és possible, o les aplicacions cobertes poden quedar fora de línia perquè el sistema aplica el bloqueig.
La icona de cadenat la dibuixa l'aplicació, així que només demostra que l'aplicació creu que està connectada. Si una altra aplicació perd l'accés a la xarxa ho decideix la plataforma, així que la comprovació útil és veure aquesta aplicació fallar amb el túnel actiu.
L'etiqueta «activació permanent» de la botiga d'aplicacions tampoc no substitueix aquest contracte. L'activació permanent i el bloqueig són ajustos del dispositiu, sovint aplicats pel propietari, i el seu comportament per a les aplicacions excloses el defineix la plataforma. Llegeix l'ajust, no la insígnia.
Quatre preguntes per a una revisió de disseny
Primer, qui va consentir: quin paquet, quin perfil i va ser l'usuari o una política de dispositiu gestionat? Segon, què va demanar l'aplicació: quines rutes, quines famílies d'adreces, quines aplicacions incloses o excloses? Tercer, què passa quan el túnel no està disponible: bloqueja el sistema o el trànsit recau en la xarxa subjacent? Quart, què fa l'aplicació amb els paquets que rep?
La quarta pregunta és la que el model de permisos no pot respondre. El consentiment i una interfície TUN demostren que l'aplicació pot rebre trànsit, no que el xifri, autentiqui un parell o es recuperi netament. Són propietats d'implementació, i és aquí on una revisió honesta passa el temps.
Una petició de root innecessària no es fa legítima per anomenar el resultat interruptor de seguretat, i un diàleg de consentiment no és una auditoria de seguretat. Mantén els tres atorgaments separats i cada afirmació esdevé comprovable.