O tráfego passa mesmo pela VPN? Como verificar

Duas falhas parecem iguais a partir do ícone da bandeja: o tráfego que entra no túnel e o tráfego que o contorna silenciosamente. O cliente mostra Connected nos dois casos, porque Connected significa apenas que a interface do túnel existe e que o cliente instalou as rotas que queria. Se um pacote de uma aplicação usou essas rotas é uma pergunta à parte, respondida noutro ponto da pilha. Quatro medições resolvem a maior parte — a consulta de rota, o primeiro salto, uma captura no adaptador físico e uma observação do exterior — e a vista de sessão no servidor cobre o resto.

Comece pela rota que o pacote vai seguir

A tabela de encaminhamento é a decisão, por isso pergunte-lhe por um destino em vez de a ler toda e adivinhar. No Linux, ip route get indica a interface e o endereço de origem que o núcleo escolheu:

ip route get 203.0.113.10
ip route get 10.20.5.7

No Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 é mais útil do que route print -4 pelo mesmo motivo: relata a rota que ganhou, não todas as rotas que existem. Ainda assim, leia a tabela uma vez pela sua linha 0.0.0.0. Um par /1 ali significa que um cliente de túnel completo reescreveu a rota predefinida: a opção redirect-gateway def1 do OpenVPN instala 0.0.0.0/1 e 128.0.0.0/1 pelo túnel, o que vence a 0.0.0.0/0 existente na correspondência de prefixo mais longa sem apagar a rota predefinida física. É por isso que duas rotas predefinidas podem coexistir enquanto tudo continua a entrar no túnel.

Dois detalhes tornam a tabela mentirosa. Primeiro, olhe para o prefixo que coincidiu e não para o número de rotas predefinidas, porque a métrica da interface ou um par /1 decidem o vencedor. Segundo, uma ligação que já existe mantém o caminho com que foi estabelecida; depois de o túnel subir, uma sessão aberta pode continuar a usar a rota antiga até ser reiniciada, e é por isso que reconectar parece corrigir um problema de encaminhamento. Um cliente em execução — ps ax | grep openvpn — prova apenas que o processo arrancou.

Siga um nome interno e um nome público

A consulta de rota mostra a intenção; o caminho mostra a entrega. Siga um nome que tem de ser interno e um que não deve ser, enquanto está ligado, e compare o primeiro salto:

traceroute intranet.corp.example
traceroute 1.1.1.1

O mesmo primeiro salto para ambos significa que o nome interno nunca entrou no túnel e que a falha está acima, normalmente um nome que resolve para um endereço público ou uma rota que nunca foi instalada. Se o tráfego interno sai por 10.8.0.1 enquanto o público sai por 192.168.1.1, o túnel dividido faz exatamente aquilo para que foi configurado. Uma traça que chega à porta de ligação da VPN e depois só devolve tempos esgotados é normalmente um problema de caminho de retorno ou da firewall do servidor, não uma rota de encaminhamento ausente.

O ICMP filtrado torna esta verificação mentirosa: estrelas nas duas traças parecem um túnel morto e normalmente são uma firewall. Teste uma porta TCP onde puder — traceroute -T -p 443 no Linux — e lembre-se de que a traça não diz que resolução respondeu: um nome pode resolver localmente e continuar acessível pelo túnel.

Capture no adaptador físico, não no túnel

A ligação física é o único lugar que mostra o que a rede vê realmente. Com o túnel levantado, uma sessão para o escritório deve aparecer como carga cifrada endereçada ao servidor VPN, não como uma ligação a 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

O primeiro filtro apanha a resolução de nomes que sai localmente, que é a fuga mais comum e a mais silenciosa — a página carrega na mesma, o resolvedor só viu o pedido. O segundo apanha tráfego simples para um endereço interno que só deveria existir dentro do túnel. No Windows, pktmon faz o mesmo trabalho sem controlador: pktmon filter add -p 53, depois pktmon start --capture --pkt-size 128, depois pktmon stop e pktmon format pktmon.etl -o capture.txt. Estes indicadores variam um pouco entre versões do Windows, por isso verifique pktmon filter add /? antes de confiar na sintaxe.

Capture a interface física para encontrar fugas; uma captura no túnel contém os pacotes que já acredita estarem lá, e num servidor contém pacotes externos ilegíveis cuja origem é a porta de ligação. Os contadores de bytes de qualquer interface descrevem pacotes, não programas; atribuir tráfego a um processo exige um monitor que associe sockets a processos.

Pergunte a um serviço externo e volte a perguntar por aplicação

A única verificação que prova a saída é uma resposta do exterior: um serviço que devolve o endereço de origem que viu. Execute-o a partir de uma shell, onde pode escolher a interface, e execute-o duas vezes:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Respostas diferentes dão-lhe prova dos dois caminhos e uma forma de testar uma aplicação concreta: ligue-a, ou execute-a num espaço de nomes de rede com uma só rota, e veja que endereço regista o extremo remoto. Respostas idênticas são a falha interessante: ou a ligação não teve efeito, ou algo entre o anfitrião e o extremo remoto reescreve o endereço de origem antes de chegar. No Windows, curl --interface quer o endereço do adaptador e não o seu nome.

Um navegador que relata o endereço da VPN prova o navegador. Um cliente de correio, um gestor de pacotes, um agente de cópias de segurança ou um segundo perfil de navegador podem cada um tomar um caminho diferente, sobretudo quando uma definição de proxy ou uma rota de túnel dividido cobre um deles. Uma mudança de endereço não é prova de fuga por si só: um balanceador pode responder de forma diferente conforme a saída que viu, por isso compare o endereço de origem registado, não a página.

Use a vista do servidor para confirmar o par

O servidor responde a outra pergunta: se um par está ligado, quanto transportou e se a sessão foi reiniciada. Um par ativo no servidor enquanto os contadores do cliente quase não se movem significa que o tráfego da aplicação não entra no túnel, diga o que disser a tabela do cliente. Um par que move muitos dados para um utilizador que refere que nada funciona é outra investigação.

Aqui há duas armadilhas. Um túnel mascarado faz cada fluxo parecer vir da porta de ligação, pelo que os registos e a contabilidade por cliente colapsam num só endereço. E um cliente é tratado como anfitrião local, pelo que a pergunta sobre se alguém copia ficheiros pela VPN é respondida pelo tráfego de partilha de ficheiros no servidor ou pela auditoria do anfitrião no servidor — observar o túnel dá extremos e volume, não nomes de ficheiros.

Distinga uma decisão de projeto de uma fuga

Nem tudo o que está fora do túnel é uma fuga. O tráfego de ligação local e de difusão fica local por projeto, uma impressora encontrada por multicast continua a anunciar-se na LAN, e o DHCP tem de sair localmente. Uma aplicação ligada a uma interface concreta contorna a tabela de encaminhamento de propósito, e só uma regra de firewall, um espaço de nomes ou uma rota de política o mudam.

O IPv6 merece a sua própria linha na lista de verificação. Um túnel que só transporta IPv4 deixa um anfitrião de pilha dupla com um segundo caminho utilizável, e um destino de pilha dupla irá preferi-lo — incluindo DNS, se o resolvedor for alcançável por IPv6. Desative o IPv6 no adaptador ou confirme que o túnel o transporta antes de considerar um resultado IPv4 completo.

Quando as verificações não coincidem, a discrepância costuma nomear a falha:

Uma ordem que funciona: guarde a tabela de encaminhamento antes e depois de ligar, siga um nome interno e um público, capture DNS no adaptador físico, devolva o endereço de saída a partir da shell para a aplicação concreta e depois leia o servidor para o volume. Se as quatro primeiras coincidirem, o túnel transporta o que pensa e o problema restante está acima. Se duas delas não coincidirem, o par que discrepa é a falha, não o ícone.