Como detetar um túnel VPN ativo a partir do código em qualquer plataforma
O túnel existe, este destino passa por ele, ou o extremo remoto responde? São três verificações diferentes e três sinais diferentes.
«A VPN está ativa?» são, na verdade, três perguntas numa só frase. Qual delas o seu código precisa é a primeira decisão, e é a que a maioria das implementações salta. Existe um túnel neste dispositivo, o tráfego para este destino sai através dele, ou o extremo remoto responde com a identidade que espera. Escolha a propriedade, depois o sinal que a mede e, por fim, diga no registo qual mediu realmente.
Três propriedades, três sinais
Comprimidas numa linha cada, as três perguntas têm três respostas diferentes. A tabela abaixo é a própria decisão, não o seu resumo.
| Property | Signal that answers it | What it still leaves open |
|---|---|---|
| Existence | The platform's own connection state: RAS on Windows, NetworkManager on D-Bus on Linux, scutil on macOS | Tunnels of a type the platform does not manage, which includes most third-party clients |
| Path | A route lookup for the one destination, or a scoped proxy or interface key that names the tunnel | Whether the far end is the peer you trust |
| Identity | An authenticated response from the far end, or a source-address policy applied on the server | Which local interface carried the packets |
Leia a última linha devagar. Um anfitrião privado que responde prova que algo respondeu, não que a resposta veio pelo túnel, e não diz nada sobre quem está do outro lado. Se a propriedade de que precisa é o caminho, meça o caminho.
Existência: o estado da própria plataforma
O Windows responde a isto para perfis nativos através da API Remote Access Service. RasEnumConnections enumera o que está ligado, RasGetConnectStatus relata o estado de uma entrada e RasGetLinkStatistics acrescenta velocidade, contadores de bytes e idade da ligação. Os limites são o ponto: o OpenVPN, o WireGuard e os clientes de fabricantes nunca registam uma ligação RAS, por isso um túnel saudável desse tipo mostra uma lista vazia e o código ingénuo relata-o como desligado.
Os ambientes de trabalho Linux expõem a mesma propriedade através do NetworkManager no D-Bus, onde PropertiesChanged no objeto de ligação VPN transforma a verificação num evento e a propriedade State relata quando a ligação atinge o estado ligado. A partir de uma shell, nmcli connection show --active lê a mesma informação, e é isso que quer durante a depuração. O macOS guarda essa lista no framework System Configuration, com scutil como a sua vista de linha de comandos. As três descrevem uma ligação gerida pela plataforma, e as três calam-se perante um túnel que ela não gere.
Caminho: para onde o pacote vai realmente
A correspondência de nomes é o atalho a que todos recorrem primeiro: enumere as interfaces, teste a cadeia contra tun, tap, ppp ou ipsec e tome uma correspondência como prova. É uma heurística, e o conjunto de interfaces pode parecer o mesmo haja ou não algo a passar por ele. As versões antigas do iOS respondiam assim e as posteriores deixaram de o fazer, porque as interfaces visíveis já não distinguiam os dois estados.
O que o substituiu ali foi o dicionário de proxy do sistema. Enquanto há uma VPN ligada, a chamada das definições de proxy devolve chaves limitadas às interfaces relacionadas com o túnel, e sem nada ligado o dicionário volta vazio. É uma afirmação mais fraca do que parece, porque regista a crença do sistema de que existe um túnel, não qual destino o usa.
O Android tem a sua própria versão da armadilha: a difusão vpn.connectivity chega a recetores declarados no manifesto em algumas compilações e a recetores registados em tempo de execução noutras. Trate-a como melhor esforço e mantenha uma sonda direta por trás dela.
Quando o destino é o que importa, pergunte à tabela de encaminhamento em vez da lista de adaptadores. As heurísticas de gateway predefinido quebram-se em máquinas com várias redes e em túneis que instalam o seu próprio gateway.
Identidade: sondar o extremo remoto
Um ciclo que envia um eco ICMP ao extremo remoto a cada poucos segundos é a verificação mais barata deste tipo, e falha numa direção útil. Aponte-o a um endereço que só exista dentro da rede privada, porque um público responde por qualquer ligação ascendente que funcione e não prova nada. Onde o ICMP é filtrado, uma ligação TCP curta à porta do serviço faz o mesmo trabalho.
Uma verificação do lado do servidor tem exatamente um sinal disponível: o endereço de origem na ligação. Manter o inventário de intervalos é trabalho de manutenção, e não consegue separar um túnel de qualquer outra rede que use por acaso o mesmo bloco.
Uma política grosseira pode viver com isso. A identidade não, por isso autentique o cliente em vez de confiar em de onde os seus pacotes parecem vir.
Registe a categoria, não o veredicto
Mantenha as categorias de falha separadas no registo: nenhuma interface, interface presente mas destino inalcançável, destino alcançável mas autenticação recusada. São três proprietários diferentes, e cada um abre uma investigação diferente.
Colapsá-las num só «VPN em baixo» envia o relatório para uma equipa que não o consegue corrigir. A categoria é a saída útil; o veredicto é o que o torna errado.