Por que o tunelamento dividido não cobre as atualizações do seu aplicativo

Você adiciona o aplicativo à lista de exclusões do tunelamento dividido, o aplicativo chega à internet diretamente, e as atualizações continuam falhando ou continuam se arrastando pelo túnel. A exclusão funcionou. Ela só cobriu um processo diferente do que faz o download, porque um atualizador moderno raramente é o mesmo executável da janela do aplicativo.

O mito: excluir o aplicativo exclui o tráfego dele

O tunelamento dividido por aplicativo casa um processo, um pacote ou um caminho de aplicativo, dependendo da plataforma. Ele não casa uma marca, um recurso ou uma intenção do usuário. Quando o aplicativo entrega o download a um auxiliar, a um serviço compartilhado da plataforma ou a um componente do navegador, esse auxiliar tem a própria identidade e o próprio caminho pelo túnel. A lista de exclusões não faz ideia de que os dois processos pertencem ao mesmo produto. Ela só sabe qual deles você nomeou.

Então a regra está fazendo exatamente o que lhe foi dito. A suposição sobre quem é dono da transferência estava errada, e a correção começa por identificar esse dono em vez de adicionar mais exclusões.

Encontre o dono da transferência

No Android, a atualização pode ser buscada por um pacote de serviço compartilhado em vez do pacote do aplicativo que você excluiu, e uma regra de VPN por aplicativo se aplica ao pacote que abre o socket. No Windows, um serviço de atualização pode rodar sob um caminho executável diferente do aplicativo, então uma regra que casa com o caminho do aplicativo não o alcança. No macOS, um auxiliar privilegiado ou um daemon de atualização do sistema pode realizar a transferência enquanto o aplicativo apenas a solicita.

Identifique o dono a partir de evidências: a visão de atividade de rede da plataforma, uma captura de pacotes filtrada por processo ou a documentação do fornecedor que nomeia o componente de atualização. Adivinhar pelo nome do processo é como dois binários parecidos se confundem e o errado é excluído.

Os sistemas de atualização também costumam dividir o trabalho. Uma pequena requisição de metadados verifica uma versão, e um download de pacote muito maior vai para um host de entrega de conteúdo ou outro domínio. A verificação de metadados pode dar certo pelo túnel enquanto a transferência do pacote trava em um host que o túnel roteia de outra forma. Essa divisão explica o relatório confuso em que atualizações são detectadas mas nunca instaladas. Teste o download do pacote em si, do mesmo dispositivo e da mesma rede, em vez de testar se o aplicativo abre.

A verificação sobrevive a uma mudança de rota

Mudar uma rota não substitui TLS, a identidade do editor nem a verificação da assinatura do pacote. Não desligue essas checagens porque um download só funciona depois que você passa por um aviso de certificado sem explicação. Um aviso que aparece só no caminho excluído é um achado, não um obstáculo. Investigue antes de ampliar o desvio.

Em um dispositivo gerenciado, peça uma exceção suportada em vez de adicionar uma regra ampla para cada serviço do sistema. Uma regra que exclui todos os serviços compartilhados para consertar um único atualizador amplia o desvio muito além da solicitação original.

Teste a atualização e depois documente o dono

Reconecte após a mudança e verifique de novo a regra aplicada, porque alguns clientes reconstroem o roteamento quando o túnel se reconecta. Execute um ciclo completo de atualização: verificar, baixar, confirmar e instalar. Uma verificação bem-sucedida prova apenas a menor parte do caminho.

Registre o dono da transferência, os hosts de destino e a rota pretendida no mesmo lugar da regra de tunelamento dividido. Caso contrário, a próxima mudança no mecanismo de atualização invalidará a exceção em silêncio, e quem a herdar não terá como saber para qual processo a regra foi escrita.