Como verificar se um túnel VPN no Linux está mesmo ativo

O cron reinicia a cada dez minutos uma VPN perfeitamente saudável, e a mesma tarefa deixa uma morta a funcionar durante uma semana. Ambas as falhas vêm de tratar «ativo» como um único facto, quando ele é pelo menos quatro. Um dispositivo pode estar ativado administrativamente, corretamente encaminhado, totalmente cifrado e mesmo assim não transportar nada de útil. Separe primeiro as observações, e a verificação quase se escreve sozinha.

Os sinalizadores da ligação descrevem o dispositivo, não o caminho

A verificação que todos copiam procura um endereço de hardware de zeros. Esse truque separa uma interface real de um marcador de posição em alguns controladores e não prova nada nos restantes, porque um dispositivo tun não tem qualquer MAC para declarar. ip -brief link show tun0 oferece, em vez disso, sinalizadores: UP significa que um administrador ativou o dispositivo, e LOWER_UP significa que o controlador considera a ligação utilizável. Lidos em conjunto, dizem que o dispositivo existe e não está administrativamente desligado. Nenhum deles diz que um pacote tem para onde ir.

OpenVPN cria o seu dispositivo tun antes de as rotas serem instaladas, pelo que os sinalizadores podem parecer perfeitos enquanto nada está encaminhado. Trate-os como uma precondição, nunca como a resposta.

Pergunte para onde iria um pacote

A consulta de rota responde à pergunta que os sinalizadores não conseguem. ip route get 10.8.0.1 from 10.8.0.2 nomeia a interface, o endereço de origem e a tabela que o kernel usaria, e é exatamente aquilo contra o que um túnel dividido tem de ser verificado. Sem o endereço de origem está a perguntar outra coisa, e com encaminhamento por políticas a resposta pode variar conforme a origem. Este é o teste honesto mais barato, porque consulta as mesmas regras que o seu tráfego usará.

Para o WireGuard, acrescente o handshake. wg show imprime um carimbo de tempo do último handshake por par, e um carimbo que deixou de avançar significa que o par desapareceu, digam o que disserem os sinalizadores da interface. Uma interface configurada sem handshake recente é um dos falsos positivos mais comuns na monitorização caseira.

A tabela 220 conta a história do IPsec

O strongSwan instala rotas para os seletores negociados na tabela 220 quando a instalação de rotas está ativada. ip route list table 220 portanto separa o negociado do encaminhado: uma tabela vazia ao lado de uma ligação carregada significa que as SA de IKE e CHILD subiram enquanto nenhum tráfego é dirigido para elas. Verifique ip xfrm state ao lado, pois lista as associações de segurança instaladas e os seus pontos finais.

Uma política de armadilha é o caso a que deve estar atento. Espera tráfego interessante em vez de o encaminhar, pelo que a tabela fica vazia até algo acionar o túnel.

O estado do gestor e o estado do daemon são listas diferentes

O NetworkManager lista apenas as ligações que possui. nmcli -t -f NAME,TYPE connection show --active não devolve nada para um túnel iniciado diretamente por wg-quick ou por um daemon OpenVPN.

Essa distinção é importante quando um script tem de decidir a qual dos dois gestores perguntar. Escolha o que possui realmente o túnel neste anfitrião e ignore o silêncio do outro. Se ambos existirem, decida qual é autoritativo e desative o segundo, porque dois gestores a reescrever rotas numa só interface produzem falhas que ninguém consegue reproduzir. Uma entrada em falta é informação sobre o gestor, não sobre o túnel.

Condicione o passo seguinte ao teste de que precisa

Sondar uma porta UDP não prova nada sobre a prontidão, porque o UDP não tem handshake e nc -u tem sucesso assim que o pacote sai. Sonde o que o passo seguinte consome de facto: uma ligação TCP à porta reencaminhada, um pedido a um anfitrião dentro do túnel, um nome que só se resolve ali. Limite a espera com um tempo limite e um número de tentativas, e falhe ruidosamente quando se esgotar.

Os ganchos superam a sondagem quando o cliente os oferece. --up e --down os scripts do OpenVPN correm depois de a interface mudar de estado, o que elimina a corrida por completo, mas correm com os privilégios que o daemon manteve. Se o OpenVPN desceu para uma conta sem privilégios através de user e group, o gancho corre como essa conta. Reiniciar um serviço do sistema exige então sudo para permitir exatamente esse comando. Entregue a nova tentativa ao gestor de serviços em vez de a um ciclo cron: uma política de reinício limitada com um limite de arranques revela um túnel quebrado, enquanto um ciclo ilimitado o esconde indefinidamente.