Monitorar uma VPN do roteador sem confiar em uma única luz de status

A página de status diz conectado, a luz está verde e o escritório não alcança o servidor de arquivos. Um desses fatos é sobre o túnel e o outro sobre o caminho através dele. Monitorar ambos é a diferença entre um alerta sobre o qual você pode agir e um que aprende a ignorar.

Cinco verificações, em ordem, do par para fora.

Verificação 1: estado do par ou da associação

Cada protocolo expõe o próprio estado. O WireGuard mostra o último handshake e os contadores de transferência por par por meio de wg show. O OpenVPN grava o estado da sessão no arquivo de status ou na interface de gestão, e o IPsec expõe as associações de segurança por ferramentas como ipsec statusall. A armadilha é ler um carimbo de tempo como veredito: um par WireGuard inativo sem nada a enviar não fará um handshake recente, e isso não é uma queda.

Compare o carimbo de tempo com o tráfego esperado e as configurações de keepalive antes de acionar alguém.

Verificação 2: a rota selecionada

Uma interface de túnel pode existir enquanto nada é roteado para ela. Verifique a tabela de encaminhamento para o destino que lhe importa, não para a sub-rede do próprio túnel. Se o prefixo falta ou aponta para outro lugar, o estado do par é irrelevante.

Essa verificação captura a falha que uma luz de status nunca mostra.

Uma segunda verificação útil também compara o endereço de origem. ip route get 10.20.5.10 retorna o próximo salto, a interface e a origem preferida, e uma origem errada basta para quebrar o tráfego de retorno na extremidade remota. Anote a tripla esperada uma vez e alerte quando qualquer elemento mudar. Essa única linha captura mudanças de NAT, instabilidade da interface e erros de roteamento por política.

Verificação 3: um caminho de aplicação permitido

Teste algo representativo do requisito real. Um ping originado no roteador sai do endereço e da política do próprio roteador, que podem diferir do tráfego LAN encaminhado, e muitos hosts limitam ICMP. Se o requisito é um serviço privado, teste esse serviço na porta real.

Mantenha o volume da sonda modesto. Um laço de monitoramento não deve se tornar o tráfego que mede.

Verificação 4: o que mudou e quando

Correlacione mudanças de WAN, renovações de chaves, retiradas de rotas e falhas de aplicações em uma única linha do tempo. Distinga uma falha do túnel de uma rota de reserva que restaura silenciosamente o acesso normal à internet, porque ambas produzem relatos de usuário idênticos e diagnósticos opostos. Erros de fuso horário inverterão a ordem, então normalize antes de comparar. A linha do tempo é o que transforma quatro verificações em uma causa.

Preserve os registros para as transições, não para a carga útil.

Verificação 5: o alarme deve nomear o limite

Um alarme que diz VPN caída manda alguém ao lugar errado metade das vezes. Um que diz handshake do par obsoleto há doze minutos, rota para 10.20.0.0/16 ausente ou sonda para a porta 445 falhando aponta para uma verificação específica.

Mantenha contadores operacionais em vez de navegar por cargas úteis. Os contadores respondem à pergunta de monitoramento sem coletar conteúdo de que você não precisa.

E deixe a política de comutação decidir o que acontece depois. O monitoramento deve identificar qual limite falhou, não autorizar um desvio amplo sempre que uma sonda falhar. O manual do OpenVPN 2.6 documenta o arquivo de status e a interface de gestão que tornam a primeira verificação programável.