Unha aplicación excluída segue en liña? As regras por aplicación e de ruta difiren

Excluír un paquete é unha instrución de encamiñamento, non un bloqueo, así que as páxinas que se cargan tras conectar a VPN son o esperado e non unha proba de fallo. A exclusión saca a aplicación do túnel en lugar de bloqueala, e a rede ordinaria transporta o seu tráfico. Dúas políticas separadas atópanse aquí: unha elixe procesos, a outra elixe destinos. Lelas nesa orde explica por que unha icona conectada e unha aplicación que funciona non son unha contradición.

Por que unha exclusión mantén a rede aberta

VpnService.Builder acepta ou ben unha lista de permitidos ou ben unha lista de denegados, nunca ambas. Os paquetes dunha lista de permitidos son os únicos encamiñados polo túnel. Unha lista de denegados invérteo: cada paquete agás os listados usa o túnel, e os listados conservan o camiño físico. Un paquete non listado baixo unha lista de permitidos tamén queda fóra do túnel, así que a exclusión é o estado normal para a maioría das aplicacións nese modo.

Iso converte unha entrada local de denegación nunha decisión de encamiñamento, non nunha regra de devasado. Se o requisito é impedir que unha aplicación chegue a un servidor, o túnel ten que cubrila e o servidor ou unha política local ten que rexeitar o tráfico. Sacar unha aplicación do túnel só cambia que interface transporta os seus paquetes.

O caso de Play Store é o exemplo deliberado habitual. Excluír o paquete da tenda permite que as descargas usen a conexión subxacente cando a saída da VPN interfire nas transferencias, e mostra que exclusión significa desvío, non bloqueo.

Un perfil, unha lista

O construtor lanza unha excepción se se usan ambas chamadas, así que o perfil que ten diante é ou ben de lista de permitidos ou ben de denegados. Ese único feito determina como ler cada observación posterior. Comprobe o código ou a configuración xestionada antes da táboa de encamiñamento, porque a lista decide que significa o resto da saída. Un perfil híbrido non é un estado que poida estar mirando.

A distinción tamén predí que fará unha aplicación recentemente instalada. Baixo unha lista de permitidos queda fóra ata que alguén a engade, mentres que baixo unha lista de denegados únese ao túnel por defecto.

As configuracións xestionadas expoñen a mesma elección baixo nomes de clave distintos, e algunhas consolas descríbeno como modo VPN por aplicación en lugar de como unha lista. O comportamento segue reducíndose a esas dúas chamadas, así que rastree o axuste ata a lista de paquetes en lugar de confiar na etiqueta. Se a etiqueta e a lista non coinciden, gaña a lista.

Siga a regra de UID ata a táboa do túnel

Android dá a cada aplicación o seu propio identificador de usuario de Linux, e o servizo de VPN instala regras de política que coinciden con rangos de UID. O tráfico coincidente envíase a unha táboa de encamiñamento cuxa ruta por defecto apunta ao dispositivo tun. O número de táboa asígnase por instancia de VPN, así que cambia tras unha reconexión ou tras crear un segundo perfil de VPN.

A saída das regras é o mapa. Cada liña nomea unha táboa de consulta, e esa táboa contén a ruta por defecto que decide se os paquetes coincidentes entran no túnel.

adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>

Executa primeiro o terceiro comando para obter o UID e despois busca a regra cuxo rango o contén. Esa regra apunta a un número de táboa, e ip route show table <n> con ese número mostra se existe unha ruta por defecto a través do dispositivo tun. Se a táboa non ten ruta por defecto, a aplicación está seleccionada pero non ten camiño, o que é un fallo distinto.

Estes comandos necesitan unha compilación depurable ou un dispositivo onde adb shell poida ler o estado da rede. Nun teléfono de produción o xestor de paquetes segue respondendo, pero a inspección de encamiñamento pode ser rexeitada, así que capture o que poida e trate o resto como non verificado.

Unha ruta reclama un prefixo, non unha aplicación

Builder.addRoute reclama prefixos de destino para o túnel. Un perfil que só engade 10.0.0.0/8 envía ese prefixo polo túnel e deixa cada outro destino no camiño físico. Iso é tunelización dividida ordinaria, e é independente de que aplicacións seleccionaron as regras.

A configuración empurrada polo servidor reflicte o mesmo modelo. Os empurróns de ruta individuais engaden prefixos, mentres que unha directiva redirect-gateway substitúe a ruta por defecto e captura todo para as aplicacións que cobre o túnel. Quitar esa directiva pode encoller un túnel funcional a unha soa subrede sen ningún cambio no dispositivo.

Unha ruta empurrada cunha pasarela ou un cualificador métrico inusual tamén pode non instalarse. Prefira a forma simple de prefixo e deixe que o servidor se encargue do reenvío e do NAT.

Lea a intersección antes de cambiar un axuste

O túnel transporta a intersección dos procesos cubertos e os destinos reclamados. Unha aplicación cuberta que pide un enderezo fóra dos prefixos publicados sae pola rede física. Un paquete denegado queda fóra mesmo cando pide un enderezo dentro deses prefixos. Ningún dos dous casos é un erro; ambos son as dúas políticas facendo o seu traballo.

Unha VPN por aplicación tamén pode deixar unha aplicación asociada sen conectividade. Cando on-demand está desactivado e o túnel está caído, a aplicación segue ligada á VPN por aplicación e non ten alternativa, o que parece unha aplicación rota máis ca un estado de política. Activar on-demand, ou quitar a asociación mediante a xestión, cambia iso.

Diagnostique un eixo á vez. Confirme permiso ou denegación primeiro, lea despois as regras de UID e as táboas instaladas, e probe por último unha segunda aplicación contra o mesmo destino. A segunda aplicación separa a selección de proceso da selección de destino nunha soa petición.

Anote o resultado como aplicación, destino e número de táboa. Esa tupla é o que o seguinte cambio ten que preservar.