A internet só funciona com o aplicativo de VPN ligado? Verifique quatro camadas

Você experimenta um cliente de VPN gratuito ou uma extensão de navegador por uma semana, desliga e a internet para. O ícone de Wi-Fi continua mostrando uma conexão, outros aparelhos no mesmo roteador funcionam bem, e as únicas coisas que trazem a navegação de volta são religar o aplicativo ou desinstalá-lo. Esse padrão não é criptografia criando uma dependência. É configuração que o aplicativo gravou em algum lugar que o túnel não controla.

O cliente altera ajustes que o túnel não controla

Um cliente de privacidade no Windows ou no macOS costuma mexer em três lugares ao mesmo tempo. Ele define o proxy HTTP do sistema, o mesmo campo que as Opções da Internet mostram. Instala um adaptador virtual, muitas vezes um driver TAP, para conseguir capturar pacotes. E reescreve a lista de resolvedores, embora só o túnel desapareça quando você clica em desconectar.

Uma extensão de navegador é uma coisa mais estreita. Normalmente altera o próprio perfil ou o proxy que um navegador segue. É por isso que um único navegador pode falhar enquanto as ferramentas de linha de comando continuam funcionando, ou o contrário: a extensão nunca teve autoridade para tocar nas outras camadas. A camada que ela editou decide quais ferramentas quebram.

De qualquer forma, a decisão obsoleta foi tomada por um software que não tinha motivo para desfazê-la. O túnel era a parte visível, e também era a única parte com um caminho de encerramento limpo. Todo o resto é um ajuste num armazenamento que sobrevive ao processo, então remover o aplicativo é o único passo que reverte os três de uma vez. Ler esses armazenamentos antes de reinstalar qualquer coisa é o que transforma o sintoma em diagnóstico.

Três sobras, três falhas diferentes

A primeira sobra é um proxy que aponta para nada: a caixa de proxy da LAN ainda marcada, ou uma URL de script de configuração mirando uma porta localhost onde nenhum processo escuta mais. O navegador encaminha cada requisição para essa porta morta e trava até o tempo limite parecer uma rede morta. A segunda é um adaptador que ainda detém uma rota padrão, porque um dispositivo TAP-Windows ou um driver de roteamento do fornecedor continua sendo uma interface real depois de uma desinstalação. Ele mantém a rota que recebeu, e o tráfego desaparece num túnel que não existe. Nenhuma das sobras se anuncia; ambas parecem exatamente uma queda.

A terceira é o DNS, e ele falha antes das outras duas. Se a lista de resolvedores contém apenas servidores alcançáveis pelo túnel, toda consulta expira antes de uma única página ser pedida, então o navegador relata um site inacessível em vez de um proxy morto. Qualquer que seja a sua, nenhuma delas é uma queda no sentido de rede. Cada uma é uma sobra que ninguém revogou, e cada uma se conserta num lugar diferente.

Percorra as quatro camadas

Comece pelo mais próximo da aplicação e desça, porque as camadas falham nessa ordem de visibilidade. Mude uma camada por teste, e teste de novo depois de cada uma. Redefinir tudo de uma vez costuma restaurar a navegação, e deixa você sem saber qual sobra causou o problema, então a próxima instalação recria o mesmo quebra-cabeça. A ordem é proxy, adaptadores, rotas, resolvedores.

No Windows cada verificação é um único comando que vem com o sistema operacional, então nada precisa ser instalado. Execute-os em ordem e mantenha a saída junta, porque as quatro respostas só fazem sentido lado a lado. Eles relatam o proxy, os adaptadores, as rotas IPv4 e a lista de resolvedores, nessa ordem:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux e macOS precisam de comandos próprios, e eles não são intercambiáveis. No Linux as rotas vêm de ip route e o resolvedor de resolvectl status onde o systemd-resolved é o dono, com recurso a cat /etc/resolv.conf. No macOS as rotas vêm de netstat -rn, os resolvedores de scutil --dns e o proxy do sistema de scutil --proxy. Um leitor de macOS que executa ip route recebe command not found, e /etc/resolv.conf ali é um stub gerado em vez da configuração autoritativa. Verifique a plataforma antes de verificar a camada, ou o primeiro comando vira a própria descoberta.

Faça uma pergunta para cada camada: esse valor ainda aponta para algo que existe enquanto o aplicativo está fechado? Um proxy numa porta morta, um adaptador sem túnel, uma rota padrão por uma interface desligada e um resolvedor dentro do túnel respondem todos que não. Um único não basta para explicar o sintoma, e é por isso que uma mudança por teste importa.

Um proxy não é um túnel

Um proxy aceita uma requisição, busca-a em outro lugar e devolve a resposta, o que significa que ele conhece o destino e vê tudo o que o site não cifrou por conta própria. Ele não carrega outros protocolos. Não protege o caminho a menos que o destino já use TLS. E pode ser alterado por qualquer coisa que o tenha instalado, sem o seu envolvimento.

Essa distinção muda a pergunta que vale a pena fazer. Quando um proxy fica para trás, descubra qual programa ainda dirige o seu navegador em vez de se o túnel está de pé. O túnel pode estar perfeitamente saudável e totalmente irrelevante para a falha.

Se você quer saber o que tal cliente realmente fez, observe em vez de ler o painel dele. O Process Monitor registra quais chaves de registro e arquivos ele toca, enquanto uma captura de pacotes revela para onde o tráfego foi. Ambos são ferramentas comuns, e ambos respondem à pergunta da sobra melhor do que qualquer luz de status. Nenhum dos dois exige que o aplicativo ainda esteja rodando.

Remova o componente, não a evidência

A correção durável é remover o que gravou o ajuste. Desinstale o aplicativo, exclua o adaptador virtual que ele adicionou, limpe o proxy e a lista de resolvedores, reinicie e teste com o aplicativo ainda desinstalado. Se a navegação funcionar nesse ponto, você encontrou a causa em vez de um paliativo. Anote qual camada estava obsoleta, porque o mesmo fornecedor costuma entregar o mesmo erro duas vezes.

Se o sintoma voltar depois de instalar o próximo cliente, percorra as quatro camadas de novo antes de decidir que o serviço quebrou algo. A evidência normalmente ainda está lá, em um dos quatro lugares. Um segundo aplicativo não cria uma quinta camada; ele edita uma das quatro.

Reinstalar redefine o proxy mas não um adaptador obsoleto, e pode deixar dois resolvedores na lista. Essa assimetria é por que desinstalar-e-testar vence um botão de redefinir tudo. Também dá a você uma linha de base para comparar na próxima vez que a conexão cair.