VPN de Android frente a los permisos de las aplicaciones: qué significa el aviso
El diálogo de consentimiento de VPN de Android concede una posición de paquetes, no acceso a tu correo, tus fotos ni tus contactos. Aquí está realmente esa frontera.
Dos diálogos de Android se confunden todo el tiempo: el aviso de consentimiento de VPN y las solicitudes de permisos que una aplicación hace sobre tus datos. El primero entrega una posición de red, el punto donde los paquetes se pueden leer y reescribir. El segundo entrega contenido almacenado que Android protege aplicación por aplicación. Tratarlos como una sola cosa o bien exagera lo que un túnel puede ver, o bien subestima gravemente lo que pedirá después una aplicación decidida.
Qué entrega realmente el diálogo de consentimiento
Una aplicación que implementa VpnService y declara BIND_VPN_SERVICE pide al sistema convertirse en la VPN del dispositivo. Tras la aprobación, el marco de trabajo crea una interfaz tun y entrega a la aplicación un descriptor de archivo para ella. Todo lo que la aplicación hace después fluye por ese descriptor: lee paquetes IP hacia fuera, decide qué hacer con ellos y vuelve a escribir paquetes hacia dentro.
El alcance de esa interfaz es explícito. Las rutas deciden qué destinos se capturan, y addAllowedApplication o addDisallowedApplication decide qué aplicaciones la alimentan. Una VPN por aplicación que enumera dos aplicaciones no ve el resto del dispositivo.
Eso es una concesión a nivel de paquete, no a nivel de datos. El servicio ve los bytes que una aplicación entrega a la pila de red, dirigidos a un destino. No obtiene ninguna vía de acceso al almacenamiento privado de la aplicación emisora, a sus archivos de base de datos ni a su memoria descifrada. Los archivos que una aplicación ha guardado dentro de su propio sandbox siguen siendo exactamente igual de difíciles de leer que antes.
Dónde se detiene la visión de paquetes
TLS sigue haciendo su trabajo dentro del túnel, porque el apretón de manos ocurre entre la aplicación y el servidor, no entre la aplicación y la VPN. La VPN reenvía texto cifrado que no puede descifrar sin las claves de sesión. Por eso un túnel por sí solo no revela el contenido de una página HTTPS ni de una sesión de correo protegida.
Los metadatos que rodean al texto cifrado son otra historia, y aquí es donde se desmoronan la mayoría de las afirmaciones seguras. La IP de destino, el puerto, los tamaños de paquete y la temporización son visibles, además del nombre del servidor en el TLS ClientHello, que normalmente se envía en claro incluso con TLS 1.3. Encrypted Client Hello cambia eso, pero no es universal. El DNS simple filtra nombres con la misma facilidad cuando las consultas salen sin cifrar.
Los protocolos más antiguos o mal configurados entregan más. HTTP simple, IMAP sin TLS y varios protocolos de juegos y de IoT exponen sus cargas útiles a cualquier cosa que tenga el descriptor tun.
Los permisos que nunca vienen con esto
Aprobar una VPN no aprueba contactos, SMS, fotos ni el almacén multimedia. Son concesiones de ejecución separadas, cada una con su propio diálogo y su propia ruta de revocación en la página de ajustes de la aplicación. Un cliente VPN que quiera tu registro de llamadas tiene que pedirlo como cualquier otra aplicación, y puedes negarte manteniendo el túnel.
La instalación de certificados es la que hay que vigilar, porque parece parte de la configuración de la VPN y no lo es. Instalar una CA de usuario en el almacén de credenciales cambia qué certificados aceptará Android, y desde Android 7.0 una aplicación destinada a API 24 o posterior ignora las CA añadidas por el usuario a menos que su configuración de seguridad de red lo habilite con un anclaje de confianza de usuario. Un cliente que insiste en una CA puede estar haciendo interceptación empresarial legítima, o puede estar pidiendo algo que el diálogo de la VPN nunca mencionó.
El acceso de accesibilidad está aún más fuera. Un servicio con la accesibilidad activada puede leer el contenido de pantalla de otras aplicaciones, algo que ninguna posición a nivel de paquete proporciona.
Filtro local o pasarela remota
La misma API cubre dos productos que merecen niveles de confianza diferentes. Un cortafuegos o bloqueador de anuncios en el dispositivo toma el descriptor tun y responde al tráfico localmente, sin enviarlo nunca a un servidor que él mismo opera. Un túnel real reenvía esos paquetes a una pasarela en otro lugar, y ese operador ve los mismos metadatos desde el otro extremo y además decide qué vuelve.
Una forma práctica de distinguirlos es comprobar tu dirección pública con la VPN activada y desactivada, y mirar si la notificación nombra un punto final remoto. Si la dirección nunca cambia, el tráfico probablemente está volviendo sobre el propio dispositivo.
Ambos casos siguen siendo una posición de paquetes. La diferencia es quién más está en la salida.
Audita lo que aprobaste
Abre Ajustes, luego Red e internet, luego VPN, y lee la entrada en lugar del icono de la barra de estado. La VPN siempre activa y Bloquear conexiones sin VPN son ajustes del dispositivo que mantienen viva la interfaz y cortan fugas; no amplían nada. Desde esa misma pantalla puedes olvidar el perfil y revocar la concesión.
Después recorre los demás permisos. La información de la aplicación muestra qué concesiones de ejecución tiene el cliente, y los ajustes de Seguridad muestran si se instaló al mismo tiempo un certificado de usuario. Cualquiera de los dos se puede eliminar de forma independiente.
La pregunta que merece respuesta es estrecha: qué paquetes entran en este servicio, adónde van y qué conserva la implementación. Todo lo demás en el diálogo es ruido. La referencia de VpnService es la lista autorizada de lo que expone la interfaz.