O túnel dividido ainda exclui um aplicativo que você desinstalou

O aplicativo antigo sumiu, e a lista do túnel dividido ainda tem uma entrada para ele. Nada quebra de forma visível, e é por isso que ela fica ali por meses. Então alguém instala outro programa na mesma pasta, ou um perfil gerenciado restaura a regra a cada reconexão, e o tráfego começa a seguir um caminho que ninguém planejou. A exclusão sobreviveu ao motivo pelo qual existia.

Limpar isso tem a ver sobretudo com identidade: para onde a regra aponta agora e quem é o dono da lista.

O sintoma: uma exclusão que não corresponde a nada

Uma entrada obsoleta é invisível no uso normal. Ela fica visível de três maneiras: um aplicativo que você esperava que passasse pelo túnel vai direto, um novo programa herda uma exceção antiga, ou o cliente se recusa a salvar uma edição porque o perfil gerenciado a sobrescreve. As três parecem bugs separados, e as três são o mesmo problema de escrituração. Cada uma é barata de verificar e cara de diagnosticar mal.

Comece lendo a regra, não apagando-a.

Descubra o que a regra identifica

As implementações de túnel dividido baseiam as exclusões em coisas diferentes: um caminho de executável, um nome de pacote, um identificador de pacote ou uma rota. Uma regra baseada em caminho aponta para um arquivo que pode não existir mais, ou que agora pode ser outro arquivo. Uma regra baseada em pacote aponta para uma identidade que uma nova instalação pode reutilizar. Leia a documentação do cliente para o campo que você está observando, porque a mesma caixa de texto significa coisas diferentes em produtos diferentes. O guia do VpnService do Android é a referência para o caso baseado em pacote.

O nome exibido é a parte menos confiável da entrada, e é justamente a parte que as pessoas leem.

Regras de caminho e regras de pacote se comportam de forma diferente

Uma regra de caminho que sobrevive a uma desinstalação costuma ficar inerte, e inerte é o bom resultado. O resultado ruim é um caminho que é reutilizado, porque o novo executável herda a exceção em silêncio. As regras de pacote se comportam de outro jeito: um produto pode ignorar um pacote indisponível, rejeitá-lo ou continuar correspondendo por nome quando algo novo reivindica esse nome.

Não transfira uma suposição de um cliente para outro. Verifique o que o seu realmente faz com um alvo ausente, de preferência criando a condição de propósito em uma máquina de teste e observando qual processo herda a exceção.

Remova-a pelo proprietário

Se a lista vem de um perfil gerenciado, editá-la localmente é uma mudança temporária que será restaurada na próxima reconexão. Altere o perfil, ou pergunte a quem o possui, e confirme que a edição sobrevive a uma reconexão. Se a lista é local, remova a entrada e verifique se o cliente reescreveu sua configuração em vez de manter a antiga na memória.

Uma lista vazia não é o objetivo. O objetivo é uma lista cujas entradas ainda atendem a requisitos reais.

Depois teste as duas direções

Depois da limpeza, teste um aplicativo que ainda deveria estar excluído e um aplicativo que agora deveria passar pelo túnel. Confirme o comportamento do DNS separadamente, porque a política do resolvedor é um controle diferente da lista de exclusões. Depois reconecte uma vez e teste de novo, já que um perfil restaurado é a forma mais comum de uma limpeza se desfazer em silêncio.

Mantenha um propósito de uma linha ao lado de cada exceção restante. É essa linha que impede a lista de virar um museu, e ela faz a próxima limpeza ser um trabalho de cinco minutos.