Por que uma VPN pode parecer conectada quando nada funciona

Seu cliente informa conectado enquanto a interface está no ar e o navegador atinge o tempo limite, e nenhuma dessas três afirmações é falsa. Conectado descreve uma camada que não tem nada a ver com a página que você solicitou. Decidir qual camada está informando exige uma solicitação nova e uma olhada no contador que provaria que o tráfego se moveu. Uma reinicialização joga fora essa evidência e reconstrói as condições que você tentava observar.

Três coisas diferentes chamadas conectado

Na base, conectado pode significar que um processo de cliente está rodando e mantendo um socket para um par. Acima disso, pode significar que existe uma interface com um endereço, que um dispositivo persistente ou uma rotina de recuperação pode criar sem sessão viva por trás. No nível de controle, pode significar que uma associação foi negociada, o que não diz nada sobre se um único pacote passou por baixo dela. Cada uma delas sobrevive a falhas a que as outras não sobrevivem, e um cliente costuma exibir a mais forte que pode alegar.

Um ícone verde e um túnel morto são, portanto, compatíveis e não contraditórios; eles informam sobre objetos diferentes. É toda a razão pela qual essa falha continua sendo mal diagnosticada como bug do cliente.

Envie uma solicitação inofensiva a um destino de que você realmente precisa antes de tocar no daemon, e mantenha o bloco de tráfego direto exigido no lugar enquanto trabalha. Uma reinicialização apaga a ordem dos eventos e depois os recria perto o suficiente para esconder a causa, e é por isso que o mesmo ticket volta uma semana depois sem nada de novo. Uma solicitação, uma leitura do contador e o gatilho que produziu a falha são a evidência mínima.

Qual contador prova que os pacotes se moveram

No IPsec, a associação IKE e a associação CHILD são objetos separados, e só o child carrega os contadores que respondem a esta pergunta. Liste o child, observe se os pacotes aumentam nas duas direções e compare com o que a aplicação tenta fazer. Uma associação instalada em zero é um achado diferente de uma que aumenta enquanto a aplicação ainda falha; a primeira significa que o tráfego não está sendo selecionado, a segunda que ele está se movendo e que a falha está mais adiante. Leia os contadores duas vezes, com alguns segundos de intervalo, porque uma amostra não pode mostrar tendência.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Contadores zerados apontam para a seleção: o roteamento, a política, um namespace de onde o pacote saiu ou uma interface à qual o cliente nunca se vinculou. Contadores crescentes apontam para longe do túnel, então continue com o encaminhamento na ponta distante, a resolução de nomes, o caminho de volta e o serviço de destino, nessa ordem. Um protocolo sem objeto child separado expõe a mesma evidência nos próprios termos, então use o que ele informa sobre o estado do par e a contagem de pacotes em vez de tomar emprestado o vocabulário do IPsec. A forma da leitura importa mais do que a ferramenta que a produziu.

Onde está a falha depois que os contadores se movem

Um gateway que responde no próprio endereço de gerenciamento prova que o gateway está rodando, não que algo atrás dele atenda à sua solicitação, então teste o lado distante e não a caixa do meio. A resolução de nomes esconde falhas melhor que tudo, porque um resolvedor inalcançável pelo túnel expira exatamente como uma conexão morta. Duas consultas separam esses casos, e ambas são baratas. Pergunte primeiro ao resolvedor que o túnel impõe e depois pergunte a um resolvedor público pelo mesmo nome.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Um nome que resolve pelo resolvedor público mas não pelo resolvedor do túnel significa que o caminho DNS está quebrado, enquanto um nome que resolve pelos dois e ainda expira no navegador aponta para o caminho de volta ou para o serviço. Se o ping por endereço funcionar e a aplicação ainda recusar, a rede entregou a solicitação e o serviço a rejeitou, o que é um estágio muito posterior.

Registre o gatilho e depois mude uma coisa

Registre o que antecedeu a falha: um período de inatividade, uma mudança de rede, uma renovação de chave, um laptop retomado ou um sistema restaurado. Isso produz mecanismos diferentes, e normalmente só o sistema restaurado se conserta sozinho, que é exatamente o caso que não ensina nada. Uma reinicialização remove a ordem dos eventos e depois recria condições próximas o bastante para esconder a causa. Anote o gatilho enquanto ele ainda é reproduzível.

Depois faça uma correção embasada e repita a solicitação original junto com o gatilho que produziu a falha. A inatividade é o gatilho mais fácil de reproduzir, então é a confirmação mais rápida de que a correção tratou do mecanismo e não do sintoma.

O que você quer relatar é a prova de que o tráfego que pretendia enviar alcançou o serviço que pretendia alcançar. Um ícone que fica verde, uma página em cache que carrega e um contador que se move provam todos menos do que uma solicitação concluída contra o destino pretendido. Mantenha a solicitação, a leitura do contador e o gatilho juntos, para que a próxima pessoa possa distinguir uma correção de uma coincidência.