VPN conectada mas um serviço falha: isole o estágio

«Conectado» é o fato menos informativo num ticket de VPN. Ele registra que dois pares concluíram um handshake e nada sobre o nome consultado, a interface por onde o pacote saiu, o tamanho dele ou se o extremo remoto o aceitou. É por isso que um serviço pode falhar enquanto todos os outros aplicativos no mesmo portátil funcionam. Percorra os estágios em ordem e o primeiro que falhar nomeará o defeito.

Comece pelo nome, não pelo túnel

Resolva antes de encaminhar, porque uma resposta ruim torna inútil todo teste posterior. Consulte o nome no resolvedor do sistema e compare essa resposta com o endereço que a aplicação realmente usou. Um nome privado que volta como endereço público significa que a consulta foi para um resolvedor que não tem nada a ver com isso. Um nome que não resolve é a mesma categoria, só mais alto.

resolvectl query host.internal
getent hosts host.internal

Navegadores com a própria configuração de DNS seguro falham aqui enquanto o resto do sistema funciona. Por isso uma reclamação só do navegador pertence primeiro a este estágio, antes de alguém tocar numa rota. Compare os dois comandos e não um, porque getent segue o caminho NSS e a consulta ao resolvedor não.

Pergunte ao kernel qual caminho ele escolheu

A tabela de roteamento é uma ordem de preferência, e o caminho que o kernel escolhe não é sempre o que o diagrama mostra. Pergunte a ele diretamente sobre o destino em questão. A resposta nomeia a interface, o próximo salto e o endereço de origem que será usado. Um pacote pode sair pelo túnel carregando um endereço de origem que o extremo remoto recusa, e uma entrada mais específica na tabela física pode enviá-lo pela interface Wi-Fi.

ip route get 10.20.30.40
ip -brief address show

Leia os campos dev, via e src nessa ordem, porque cada um elimina uma suspeita diferente. Este estágio também é dono do estado que o cliente instalou, já que regras de firewall e rotas podem persistir após uma saída anormal. Por isso «sem internet sem o túnel» e «sem internet a menos que o cliente rode» são uma mesma família de falhas, não duas.

Teste o tamanho do pacote

Uma resposta pequena que volta enquanto uma transferência grande trava aponta primeiro para o MTU do caminho. Uma única sonda com o bit do-not-fragment ativado, enviada de dentro do túnel, separa este estágio dos demais. Suba a carga útil até a sonda falhar e terá o número que importa.

ping -M do -s 1400 10.20.30.40

Sondas pequenas que passam enquanto uma listagem de diretório ou um envio trava é a assinatura deste estágio. A reclamação soa como credenciais ou uma regra de firewall, e não é nenhuma das duas.

O número é uma propriedade do caminho, não do cliente, então um valor que funciona numa conexão de escritório pode falhar num enlace móvel. Guarde o comando da sonda com o ticket, porque a próxima pessoa precisa da mesma medição. Se uma carga menor passa, a correção é um clamp ou um MTU de túnel mais baixo, não uma cifra nova.

Teste o extremo remoto

Teste o destino pelo endereço dele e depois veja o que escuta ali. Uma conexão recusada e uma conexão que nunca responde são achados diferentes. A primeira diz que algo está no ar e não serve aquela porta, e a segunda diz que nada voltou. Nenhuma das duas é um problema de cliente por padrão.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Nada alcançável por um túnel pode ser um serviço que escuta apenas em 127.0.0.1, porque o ouvinte nunca vê o pacote. Quando o firewall do host remoto permite a sub-rede do escritório e recusa o pool do túnel, o resultado parece uma falha do cliente e não é. Área de trabalho remota ou compartilhamento de arquivos que quebram enquanto o tráfego web sobrevive costumam parar aqui, diga o usuário o que disser.

Mapeie a reclamação para um estágio

A maioria dos relatos encaixa em uma de cinco formas, e cada forma nomeia um estágio. Um site que só funciona pelo túnel é uma resposta de nome ou uma política ligada ao endereço de origem. Atualizações que falham sem o túnel enquanto a navegação funciona é um problema de nome ou de rota para esse cliente.

Que tudo pare quando um cliente de provedor inicia é estado instalado, ou seja, uma questão de rota e firewall. Um serviço inalcançável enquanto o resto está bem é o extremo remoto. Transferências que travam após alguns segundos são o tamanho do pacote. Combine a forma antes de executar comandos, porque ela decide quais evidências coletar primeiro.

Registre o estágio que produziu a primeira falha junto com a saída do comando. Um ticket que diz que o endereço de origem estava errado, com a linha de rota anexada, merece ação, enquanto um que relata a VPN como quebrada não.