¿Una aplicación excluida sigue en línea? Las reglas por aplicación y de ruta difieren
Excluir una aplicación de Android de una VPN no la bloquea. Las listas de permitidos, las reglas de UID y las rutas empujadas deciden cada una una parte distinta del camino.
Excluir un paquete es una instrucción de enrutamiento, no un bloqueo, así que las páginas que se cargan tras conectar la VPN son lo esperado y no una prueba de fallo. La exclusión saca la aplicación del túnel en lugar de bloquearla, y la red ordinaria transporta su tráfico. Dos políticas separadas se encuentran aquí: una elige procesos, la otra elige destinos. Leerlas en ese orden explica por qué un icono conectado y una aplicación que funciona no son una contradicción.
Por qué una exclusión mantiene la red abierta
VpnService.Builder acepta o bien una lista de permitidos o bien una lista de denegados, nunca ambas. Los paquetes de una lista de permitidos son los únicos enrutados por el túnel. Una lista de denegados lo invierte: cada paquete excepto los listados usa el túnel, y los listados conservan el camino físico. Un paquete no listado bajo una lista de permitidos también queda fuera del túnel, así que la exclusión es el estado normal para la mayoría de aplicaciones en ese modo.
Eso convierte una entrada local de denegación en una decisión de enrutamiento, no en una regla de cortafuegos. Si el requisito es impedir que una aplicación llegue a un host, el túnel tiene que cubrirla y el servidor o una política local tiene que rechazar el tráfico. Sacar una aplicación del túnel solo cambia qué interfaz transporta sus paquetes.
El caso de Play Store es el ejemplo deliberado habitual. Excluir el paquete de la tienda permite que las descargas usen la conexión subyacente cuando la salida de la VPN interfiere con las transferencias, y muestra que exclusión significa rodeo, no bloqueo.
Un perfil, una lista
El constructor lanza una excepción si se usan ambas llamadas, así que el perfil que tiene delante es o bien de lista de permitidos o bien de denegados. Ese único hecho determina cómo leer cada observación posterior. Compruebe el código o la configuración gestionada antes de la tabla de enrutamiento, porque la lista decide qué significa el resto de la salida. Un perfil híbrido no es un estado que pueda estar mirando.
La distinción también predice qué hará una aplicación recién instalada. Bajo una lista de permitidos se queda fuera hasta que alguien la añade, mientras que bajo una lista de denegados se une al túnel por defecto.
Las configuraciones gestionadas exponen la misma elección bajo nombres de clave distintos, y algunas consolas lo describen como modo VPN por aplicación en lugar de como una lista. El comportamiento sigue reduciéndose a esas dos llamadas, así que rastree el ajuste hasta la lista de paquetes en lugar de confiar en la etiqueta. Si la etiqueta y la lista no coinciden, gana la lista.
Siga la regla de UID hasta la tabla del túnel
Android da a cada aplicación su propio identificador de usuario de Linux, y el servicio de VPN instala reglas de política que coinciden con rangos de UID. El tráfico coincidente se envía a una tabla de enrutamiento cuya ruta por defecto apunta al dispositivo tun. El número de tabla se asigna por instancia de VPN, así que cambia tras una reconexión o tras crear un segundo perfil de VPN.
La salida de las reglas es el mapa. Cada línea nombra una tabla de consulta, y esa tabla contiene la ruta por defecto que decide si los paquetes coincidentes entran en el túnel.
adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>
Ejecute primero el tercer comando para obtener el UID y luego busque la regla cuyo rango lo contiene. Esa regla apunta a un número de tabla, y ip route show table <n> con ese número muestra si existe una ruta por defecto a través del dispositivo tun. Si la tabla no tiene ruta por defecto, la aplicación está seleccionada pero no tiene camino, lo que es un fallo distinto.
Estos comandos necesitan una compilación depurable o un dispositivo donde adb shell pueda leer el estado de la red. En un teléfono de producción el gestor de paquetes sigue respondiendo, pero la inspección de enrutamiento puede ser rechazada, así que capture lo que pueda y trate el resto como no verificado.
Una ruta reclama un prefijo, no una aplicación
Builder.addRoute reclama prefijos de destino para el túnel. Un perfil que solo añade 10.0.0.0/8 envía ese prefijo por el túnel y deja cada otro destino en el camino físico. Eso es tunelización dividida ordinaria, y es independiente de qué aplicaciones seleccionaron las reglas.
La configuración empujada por el servidor refleja el mismo modelo. Los empujes de ruta individuales añaden prefijos, mientras que una directiva redirect-gateway sustituye la ruta por defecto y captura todo para las aplicaciones que cubre el túnel. Quitar esa directiva puede encoger un túnel funcional a una sola subred sin ningún cambio en el dispositivo.
Una ruta empujada con una puerta de enlace o un calificador métrico inusual también puede no instalarse. Prefiera la forma simple de prefijo y deje que el servidor se encargue del reenvío y del NAT.
Lea la intersección antes de cambiar un ajuste
El túnel transporta la intersección de los procesos cubiertos y los destinos reclamados. Una aplicación cubierta que pide una dirección fuera de los prefijos publicados sale por la red física. Un paquete denegado se queda fuera incluso cuando pide una dirección dentro de esos prefijos. Ninguno de los dos casos es un error; ambos son las dos políticas haciendo su trabajo.
Una VPN por aplicación también puede dejar una aplicación asociada sin conectividad. Cuando on-demand está desactivado y el túnel está caído, la aplicación sigue ligada a la VPN por aplicación y no tiene alternativa, lo que parece una aplicación rota más que un estado de política. Activar on-demand, o quitar la asociación mediante la gestión, cambia eso.
| Layer | What it selects | Where to look | Typical mismatch |
|---|---|---|---|
| Package list | Processes | Builder calls or managed configuration | App excluded but expected to be blocked |
| UID policy rule | Which table a UID uses | ip rule show | Tunnel icon on, app still on Wi-Fi |
| Routing table | Destinations for matched traffic | ip route show table <n> | Covered app reaches only one subnet |
| Server push | Prefixes offered to the client | Server route configuration | Tunnel shrinks after a server edit |
Diagnostique un eje cada vez. Confirme permiso o denegación primero, lea después las reglas de UID y las tablas instaladas, y pruebe por último una segunda aplicación contra el mismo destino. La segunda aplicación separa la selección de proceso de la selección de destino en una sola petición.
Anote el resultado como aplicación, destino y número de tabla. Esa tupla es lo que el siguiente cambio tiene que preservar.