App excluído ainda online? As regras por app e de rota diferem

Excluir um pacote é uma instrução de encaminhamento, não um bloqueio, então as páginas que carregam após a conexão da VPN são esperadas e não prova de falha. A exclusão tira o app do túnel em vez de bloqueá-lo, e a rede comum transporta o seu tráfego. Duas políticas separadas encontram-se aqui: uma escolhe processos, a outra escolhe destinos. Lê-las nessa ordem explica por que um ícone conectado e um app a funcionar não são uma contradição.

Por que uma exclusão mantém a rede aberta

O VpnService.Builder aceita ou uma lista de permissão ou uma lista de proibição, nunca ambas. Apenas os pacotes de uma lista de permissão são encaminhados pelo túnel. Uma lista de proibição inverte isso: todos os pacotes exceto os listados usam o túnel, e os listados mantêm o caminho físico. Um pacote não listado numa lista de permissão também fica fora do túnel, portanto a exclusão é o estado normal para a maioria dos apps nesse modo.

Isso torna uma entrada local de proibição uma decisão de encaminhamento, não uma regra de firewall. Se o requisito é impedir que um app alcance um anfitrião, o túnel tem de o cobrir e o servidor ou uma política local tem de recusar o tráfego. Retirar um app do túnel muda apenas qual interface transporta os seus pacotes.

O caso da Play Store é o exemplo deliberado habitual. Excluir o pacote da loja permite que as transferências usem a ligação subjacente quando a saída da VPN interfere nas transferências, e mostra que exclusão significa contorno, não bloqueio.

Um perfil, uma lista

O construtor lança uma exceção se ambas as chamadas forem usadas, portanto o perfil à sua frente é ou uma lista de permissão ou uma lista de proibição. Esse único facto determina como ler cada observação posterior. Verifique o código ou a configuração gerida antes da tabela de encaminhamento, porque a lista decide o que significa o resto da saída. Um perfil híbrido não é um estado que possa estar a observar.

A distinção também prevê o que fará um app recentemente instalado. Numa lista de permissão fica fora até que alguém o adicione, enquanto numa lista de proibição se junta ao túnel por predefinição.

As configurações geridas expõem a mesma escolha sob nomes de chave diferentes, e algumas consolas descrevem-na como modo VPN por app em vez de como uma lista. O comportamento continua a reduzir-se àquelas duas chamadas, portanto siga a definição até à lista de pacotes em vez de confiar no rótulo. Se o rótulo e a lista discordarem, ganha a lista.

Siga a regra de UID até à tabela do túnel

O Android dá a cada app o seu próprio ID de utilizador Linux, e o serviço de VPN instala regras de política que correspondem a intervalos de UID. O tráfego correspondente é enviado para uma tabela de encaminhamento cuja rota predefinida aponta para o dispositivo tun. O número da tabela é atribuído por instância de VPN, por isso muda após uma reconexão ou após criar um segundo perfil de VPN.

A saída das regras é o mapa. Cada linha nomeia uma tabela de consulta, e essa tabela contém a rota predefinida que decide se os pacotes correspondentes entram no túnel.

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

Execute primeiro o terceiro comando para obter o UID e depois encontre a regra cujo intervalo o contém. Essa regra aponta para um número de tabela, e ip route show table <n> com esse número mostra se existe uma rota predefinida através do dispositivo tun. Se a tabela não tiver rota predefinida, o app está selecionado mas não tem caminho, o que é uma falha diferente.

Estes comandos exigem uma compilação depurável ou um dispositivo onde o adb shell possa ler o estado da rede. Num telemóvel de produção o gestor de pacotes ainda responde, mas a inspeção do encaminhamento pode ser recusada, por isso registe o que puder e trate o resto como não verificado.

Uma rota reivindica um prefixo, não um app

O Builder.addRoute reivindica prefixos de destino para o túnel. Um perfil que apenas acrescenta 10.0.0.0/8 envia esse prefixo pelo túnel e deixa todos os outros destinos no caminho físico. Isso é tunelização dividida comum, e é independente de quais apps as regras selecionaram.

A configuração enviada pelo servidor reflete o mesmo modelo. Os envios de rota individuais acrescentam prefixos, enquanto uma diretiva redirect-gateway substitui a rota predefinida e captura tudo para os apps que o túnel cobre. Remover essa diretiva pode reduzir um túnel funcional a uma única sub-rede sem qualquer alteração no dispositivo.

Uma rota enviada com um gateway ou um qualificador métrico invulgar também pode falhar a instalação. Prefira a forma simples de prefixo e deixe o servidor tratar do reencaminhamento e do NAT.

Leia a interseção antes de alterar uma definição

O túnel transporta a interseção dos processos cobertos e dos destinos reivindicados. Um app coberto que peça um endereço fora dos prefixos publicados sai pela rede física. Um pacote proibido fica fora mesmo quando pede um endereço dentro desses prefixos. Nenhum dos casos é um erro; ambos são as duas políticas a fazer o seu trabalho.

Uma VPN por app também pode deixar um app associado sem conetividade. Quando o on-demand está desligado e o túnel está em baixo, o app permanece ligado à VPN por app e não tem alternativa, o que parece um app avariado e não um estado de política. Ativar o on-demand, ou remover a associação através da gestão, muda isso.

Diagnostique um eixo de cada vez. Confirme permissão ou proibição primeiro, leia depois as regras de UID e as tabelas instaladas, e teste por último um segundo app contra o mesmo destino. O segundo app separa a seleção de processo da seleção de destino num único pedido.

Anote o resultado como app, destino e número de tabela. É esse triplo que a próxima alteração tem de preservar.