VPN por aplicacion en Android: excluir una app no la bloquea
La lista por aplicacion que ves pertenece a un unico dueno de tunel, y excluir una app la desvia alrededor de ese tunel en vez de sacarla de la red. Empieza por ahi.
Dos personas hacen la misma pregunta y reciben respuestas incompatibles, porque estan de pie en lugares distintos. Una tiene abierta la pantalla de ajustes de VPN del sistema y edita una lista de aplicaciones. La otra escribe VpnService.Builder.addDisallowedApplication() en un editor. Ambas lo llaman filtro de VPN por aplicacion. Solo una de ellas es duena del control que describe, y ninguna de las dos esta bloqueando nada.
Empieza por la pantalla que ve el usuario
Abre Ajustes, busca la entrada de VPN y mira la conexion que esta realmente activa. Si el cliente ofrece una lista por aplicacion, esa lista pertenece al tunel propio del cliente. La plataforma no publica una API general mediante la cual una aplicacion ajena pueda leer o editar la seleccion de aplicaciones de otra VPN, asi que una segunda app no puede arreglar esa lista por el usuario.
Esta es la primera bifurcacion del recorrido. Si la VPN instalada no tiene ese ajuste, no hay nada que programar alrededor: la funcion no existe en el producto dueno del tunel. Si lo tiene, la correccion correcta esta en esa pantalla y la hace la persona que puede abrirla.
Sigue el paquete hacia un tunel
Cuando tu propia app construye un tunel, crea una interfaz TUN y declara que trafico de aplicaciones entra en ella. Las llamadas de pertenencia ocurren antes de establecer la interfaz, y despues el conjunto de reglas queda fijo para esa sesion:
val builder = VpnService.Builder()
builder.addAddress("10.8.0.2", 32)
builder.addRoute("0.0.0.0", 0)
builder.addDisallowedApplication("com.example.bypass")
val tun = builder.establish() // membership decided hereEsas llamadas se aplican al tunel que tu app acaba de crear y a nada mas. No son una politica de todo el dispositivo, no persisten para otros clientes y no pueden entrar en la VPN de otra persona. Cuando una llamada al constructor falla porque el paquete no se puede resolver, la interfaz nunca se establece, lo que es un fallo limpio en lugar de uno silencioso.
Por que la exclusion parecia un bloqueo
Una aplicacion excluida se enruta alrededor de tu tunel hacia la red subyacente. Eso es lo contrario de bloquearla: el trafico sigue saliendo del dispositivo, solo que fuera de la interfaz que controlas. Una app estilo cortafuegos hace lo inverso. Admite el trafico de la aplicacion en su tunel y luego descarta los paquetes, o se niega a reenviarlos, de modo que la interfaz es la misma y la direccion de la politica esta invertida.
El trabajo detras de esa inversion no es una bandera de configuracion. Lees paquetes IP del descriptor del tunel, decides por flujo y luego los reenvias por un socket protegido o los descartas. Todo lo que no manejas simplemente se detiene, y por eso un tunel a medio terminar parece una red rota en lugar de un filtro que funciona. Si tu objetivo es bloquear, presupuesta manejo de paquetes, un servicio en primer plano y una politica escrita para el trafico que no puedas clasificar.
Que se rompe cuando lo construyes tu mismo
Android suele permitir solo una VPN activa a la vez, asi que tu tunel de filtrado y uno de privacidad compiten por la misma ranura salvo que los productos admitan encadenamiento. La VPN siempre activa con bloqueo de conexiones cambia el modo de fallo de una forma que aqui importa: el trafico que no puede entrar en el tunel se descarta en vez de enviarse directo, que es lo que quiere un diseno de prevencion de fugas y lo que una sesion de depuracion rara vez espera.
La visibilidad de paquetes es la segunda trampa. Resolver el nombre de paquete de una aplicacion puede fallar con NameNotFoundException, y en versiones mas nuevas de Android el conjunto de paquetes que puedes ver depende de las consultas que hayas declarado. Maneja la excepcion en vez de suponer que todo nombre se resuelve, y vuelve a leer la lista cuando se instalan o quitan aplicaciones en lugar de guardarla en cache para siempre.
Los dispositivos gestionados anaden un tercer dueno. Una politica de movilidad empresarial puede fijar una VPN por aplicacion o un perfil siempre activo, y una aplicacion comun no puede anularlo. Comprueba si el dispositivo esta gestionado antes de depurar tu propio codigo, porque en ese caso la lista que intentas cambiar puede que nadie que sostenga el telefono pueda editarla.
Pruébalo con una app que controles
No pruebes con la app que intentas filtrar. Usa una segunda aplicacion cuyo comportamiento de red puedas observar y comprueba si su trafico sale por tu tunel mientras el del objetivo no lo hace. Si ambas se quedan dentro, la politica funciona y el objetivo esta excluido; si ninguna sale, el tunel mismo esta mal y la lista de apps no es el problema.
Despues decide cual de tres cosas estas construyendo en realidad. Un tunel por aplicacion es la API del constructor, con la lista como parte de tu perfil. Un cortafuegos de dispositivo es manejo de paquetes mas un ciclo de vida que puedas defender. Cambiar la VPN de otra persona no es una ruta admitida en absoluto, y la respuesta honesta ahi es que el ajuste pertenece a ese producto.