VPN ligada mas sem internet? Percorra as quatro camadas

O cliente diz ligado, o navegador roda e cada site termina em tempo esgotado. Essa combinação é comum e não é contradição: ligado significa que o túnel negociou, e nada mais. Resolução de nomes, encaminhamento e a própria saída do servidor falham cada um à sua maneira, e cada um tem dono diferente. Percorra as camadas em ordem e pare na primeira que falhar.

Comece pela rede de onde veio

Desligue o túnel com o próprio controle de desconexão do cliente e depois teste dois sites HTTPS não relacionados, se a política permitir. Deixe o trabalho sensível fechado durante esse teste. Se o acesso comum também falhar, a VPN não é o primeiro suspeito.

Olhe para o link Wi-Fi, o roteador e qualquer página de portal que exija login antes de tocar no túnel. Um kill switch pode bloquear o tráfego enquanto está desconectado por projeto, então siga o procedimento de teste documentado em vez de concluir que a rede está morta. Outra rede confiável é uma comparação útil, e uma saída VPN nova não concluirá um login de hotel expirado. Se a rede aberta funciona e o túnel não, a rede está ilibada e a próxima camada é sua.

Decida se a falha é de resolução de nomes

Anote o texto do erro, porque falha de resolução, tempo esgotado e aviso de certificado apontam cada um para outro lugar. O padrão a detectar cedo é um nome de host nunca visitado falhando enquanto uma aplicação com sessão aberta continua. Esse padrão é sobre novas consultas, não sobre o túnel transportar pacotes. Uma única consulta mostra o que o resolvedor devolve, e leva um segundo. Teste também um segundo nome, para que uma resposta em cache ou um registo quebrado não decidam o diagnóstico.

nslookup example.com

Um IP arbitrário na barra de endereços HTTPS não é um teste de DNS, porque o certificado e o host virtual costumam depender do nome. Nomes internos podem exigir o resolvedor da organização em vez de um substituto público, e um navegador com o seu próprio resolvedor seguro pode responder de forma diferente da consulta do sistema operativo. Onde os dois divergem, o resolvedor do navegador é o que o utilizador experiencia, e essa distinção pertence ao ticket.

Túnel completo ou apenas sub-redes da empresa

Alguns perfis existem apenas para chegar a um punhado de sub-redes da empresa; outros são feitos para transportar tudo e precisam de uma saída funcional atrás. Leia a finalidade documentada antes de presumir que o indicador cobre cada aplicação e cada família de endereços. Um perfil de rede privada pode funcionar exatamente como concebido enquanto o navegador, que nunca deveria usá-lo, continua a falhar. Leia a tabela de rotas sem a alterar, e inclua IPv6, porque um caminho IPv4 funcional não diz nada sobre a outra família.

Uma rota mais específica pode vencer enquanto a rota padrão ainda existe, por isso a tabela tem de ser lida e não presumida. Adaptadores virtuais concorrentes também podem deter tráfego que esperava noutro lugar, sobretudo depois de um segundo cliente VPN ser instalado e esquecido. Não apague a rota padrão como experiência; isso transforma um diagnóstico numa segunda falha.

Um único site a falhar entre os que funcionam é um problema desse site, e também prova que o túnel transporta tráfego. As paragens que só aparecem em transferências grandes apontam para o tamanho do pacote e não para a acessibilidade.

Quando o servidor nunca reencaminha nada

Se todos os destinos falham em dois dispositivos e duas redes de acesso, o túnel está no ar e a saída não reencaminha. É esse par que separa uma falha do lado do servidor de um dispositivo mal configurado num só ponto. Envie ao operador as perguntas de reencaminhamento, NAT e caminho de retorno, não uma captura do indicador.

Essas três cobrem a maioria das causas do lado do servidor, e responder é tarefa do operador. A página de resolução de problemas de conectividade do OpenVPN percorre as mesmas perguntas do lado do servidor, por isso entregue-a com o ticket. Uma captura de um indicador verde não responde a nenhuma.

Reveja o registo do cliente após o início de sessão à procura de falhas na aplicação de rotas, definições de DNS ou do adaptador virtual. Os erros nessa fase apontam para o dispositivo e não para o servidor. Um erro que nunca aparece no registo é igualmente informativo, porque desloca a suspeita para o outro lado.

Verifique uma camada de cada vez

Assim que alterar algo, volte a ligar e repita exatamente a aplicação que falhou. Uma só página que carrega prova menos do que um caminho repetível até aos recursos para os quais o perfil foi criado. Dois comandos separam a resolução da acessibilidade, e o segundo depende do host. Execute a linha curl em qualquer lugar e depois o comando de rotas que corresponde ao host à sua frente.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Se o pedido numérico funciona e o nome não, fique no DNS. Se nenhum funcionar, compare a tabela de rotas com o padrão esperado do túnel e verifique a família que está realmente a testar. Se a rota estiver correta e o pedido continuar a morrer na saída, a pergunta restante é do operador, e as provas que guardou são o ticket.