VPN en Android sen root: quen posúe o consentimento, as rutas e o bloqueo
O consentimento, a interface TUN e a política de bloqueo do sistema son tres permisos distintos. Rastrexa que compoñente posúe cada un antes de revisar unha aplicación VPN de Android.
O root non é o que permite que unha aplicación VPN de Android transporte tráfico, bloquee fugas ou sobreviva a un reinicio. A xente resume todo iso como «a aplicación ten permiso de VPN», o que oculta tres mecanismos separados: un consentimento outorgado polo usuario, unha interface de paquetes que establece o sistema e unha política de bloqueo da plataforma que non corresponde á aplicación definir. Revisar un deseño de VPN de Android significa preguntar en cal dos tres se apoia realmente unha afirmación, porque cada un ten un propietario e un modo de fallo distintos.
O consentimento chega mediante unha actividade do sistema
VpnService.prepare() non concede nada. Devolve un intent á actividade de consentimento do sistema cando falta o consentimento, e a aplicación lanza ese diálogo para que o usuario aprobe o servizo. Iniciar o propio proceso da aplicación, engadir un permiso ao manifesto ou mostrar unha pantalla personalizada de «activar VPN» non crea a concesión.
A concesión tamén ten alcance. Pertence a un paquete dentro dun perfil de usuario, así que a copia persoal e a copia de traballo son decisións separadas, e o propietario dun dispositivo pode preparar un perfil xestionado de forma distinta a un persoal. Se o diálogo nunca aparece e prepare() devolve null, o consentimento xa existe para ese paquete nese perfil; non é proba de que a aplicación sexa fiable, só de que a concesión está no seu sitio.
A interface é unha petición que o sistema cumpre
Tras o consentimento, a aplicación describe o que quere con VpnService.Builder: enderezos, rutas, servidores DNS, MTU e, onde se admite, as aplicacións que se inclúen ou exclúen. establish() pide ao sistema que cree a interface de túnel e encamiñe cara a ela o tráfico correspondente. O sistema posúe a decisión de encamiñamento; a aplicación recibe o descritor de ficheiro e entón debe facer algo útil cos paquetes.
| 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 |
Esa táboa é a arquitectura nun só lugar. A aplicación participa no manexo de paquetes; non posúe a interface, a táboa de encamiñamento nin o número de servizos que poden executarse.
O socket do túnel ten que escapar do seu propio túnel
A conexión que transporta o tráfico cifrado é ela mesma un socket. Se se encamiña de volta á interface que a aplicación acaba de crear, o túnel depende do túnel e detense. VpnService.protect() vincula ese socket á rede subxacente para que evite a captura, e por iso un cliente correcto protexe o seu socket exterior antes do primeiro aperto de mans.
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_lockdownEstes comandos mostran a rede VPN instalada, o paquete de activación permanente e se o bloqueo está configurado. Son observacións de só lectura: se os valores non coinciden co que afirma o deseño, a afirmación é sobre a interface da aplicación e non sobre o estado do sistema.
O bloqueo pode pertencer á plataforma
Android documenta unha política que bloquea as conexións que non usan a VPN. Esa aplicación é un contrato da plataforma, non unha aplicación que reintenta conexións en bucle. O interruptor está nos axustes de VPN do dispositivo como Bloquear conexións sen VPN, e nun dispositivo xestionado o propietario pode activalo para todo o perfil. A distinción importa cando avalías unha afirmación de márketing: un cliente pode mostrar unha icona de cadeado e reconectar con agresividade mentres o tráfico directo segue sendo posible, ou as aplicacións cubertas poden quedar sen conexión porque o sistema aplica o bloqueo.
A icona de cadeado debúxaa a aplicación, así que só demostra que a aplicación cre que está conectada. Se outra aplicación perde o acceso á rede decídeo a plataforma, así que a comprobación útil é ver esa aplicación fallar co túnel activo.
A etiqueta «sempre activo» da tenda de aplicacións tampouco substitúe ese contrato. A activación permanente e o bloqueo son axustes do dispositivo, a miúdo aplicados polo propietario, e o seu comportamento para as aplicacións excluídas defíneo a plataforma. Le o axuste, non a insignia.
Catro preguntas para unha revisión de deseño
Primeiro, quen consentiu: que paquete, que perfil e se foi o usuario ou unha política de dispositivo xestionado. Segundo, que pediu a aplicación: que rutas, que familias de enderezos, que aplicacións incluídas ou excluídas. Terceiro, que ocorre cando o túnel non está dispoñible: bloquea o sistema ou o tráfico recorre á rede subxacente? Cuarto, que fai a aplicación cos paquetes que recibe.
A cuarta pregunta é a que o modelo de permisos non pode responder. O consentimento e unha interface TUN demostran que a aplicación pode recibir tráfico, non que o cifre, autentique a un par ou se recupere limpiamente. Son propiedades de implementación, e aí é onde unha revisión honesta pasa o seu tempo.
Unha petición de root innecesaria non se volve lexítima por chamar ao resultado interruptor de emerxencia, e un diálogo de consentimento non é unha auditoría de seguridade. Mantén as tres concesións separadas e cada afirmación vólvese comprobable.