O que um ecrã do iftop pode e não pode provar sobre uma VPN

Um ecrã do iftop responde a uma pergunta de cada vez: que pares de hosts trocam bytes pela interface para a qual o apontou. Não responde se cada aplicação segue uma política de VPN, e um ecrã vazio não prova que nada escapou. É justamente na diferença entre estas duas afirmações que a maioria das discussões sobre testes de fuga se engana. Três condições decidem o que a visualização realmente significa, e as três são visíveis na linha de comandos que usou.

Três condições decidem o que o ecrã significa

As condições são qual interface está a ser mostrada, o que o filtro e a própria ferramenta escondem, e o que o teste realmente exercitou. Responda por essa ordem, porque um erro na primeira torna as outras duas sem sentido.

A condição da interface importa porque a vista do túnel e a vista física mostram camadas diferentes do mesmo tráfego. Olhar para a interface do túnel mostra os fluxos dentro do túnel; olhar para a interface física mostra o portador do túnel, mais qualquer tráfego legítimo de configuração, controlo ou local que partilhe essa ligação. Nenhuma das vistas está errada, e nenhuma é a imagem completa. Nomear qual está a ver é a diferença entre prova e impressão.

Condição um: qual interface está a ser mostrada

O iftop recebe a interface explicitamente com -i, e o manual descreve o comportamento quando não o faz: escolhe uma, que pode ser o dispositivo que parece externo em vez do túnel. Esse valor predefinido é uma escolha razoável para uma ferramenta de largura de banda e má para um teste de fuga.

Passe sempre a interface, e anote-a ao lado do resultado. Uma captura de ecrã sem o nome da interface não é reproduzível.

Condição dois: o que o filtro e a ferramenta escondem

O iftop aceita uma expressão de filtro, e um fluxo que o filtro exclui é invisível por construção e não por ausência. A ferramenta também faz, por predefinição, pesquisas de nomes de hosts para etiquetar endereços, e essas pesquisas geram o seu próprio tráfego DNS, ou seja, tráfego que não pretendia observar. -n desativa as pesquisas e torna a visualização numérica; esconder depois as linhas de DNS não é o mesmo que não gerar as consultas.

Vale a pena dizer essa distinção sem rodeios, porque também aparece noutras ferramentas: suprimir a visualização de uma atividade não é o mesmo que impedi-la. Se as pesquisas de DNS fazem parte do que está a testar, execute o teste com as pesquisas desativadas, para que a observação não seja contaminada pelo observador.

Condição três: o que o teste realmente exercitou

Um único pedido de uma aplicação, para um destino, numa família de endereços prova algo sobre esse pedido. Não prova nada sobre outra aplicação, outro destino ou a outra família de endereços, e o IPv6 é a família que mais se esquece precisamente neste tipo de verificação.

Por isso, defina o pedido antes de começar: um destino inofensivo, a partir da aplicação que lhe interessa, na família que lhe interessa, com o túnel no seu estado aprovado. Depois verifique o lado recetor ou os próprios diagnósticos do cliente, porque o extremo remoto sabe o que chegou de uma forma que o ecrã local não consegue. Depois exercite o caso aprovado de túnel indisponível e veja se o tráfego para, porque é esse o comportamento a que o requisito normalmente se refere.

O DNS merece a sua própria observação. O destinatário da consulta e a rota que a consulta tomou são dois factos, e um ecrã de largura de banda não mostra nenhum deles.

Usar o iftop como prova de apoio

Só então o iftop acrescenta valor, e acrescenta-o como corroboração. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" mostra se o fluxo esperado aparece na interface esperada, com contagens de bytes que tornam verificável uma afirmação de inatividade.

Compare isso com ss -tnp para a vista ao nível do socket e ip route get para a rota que o núcleo escolheria, e tem três observações de um pedido em vez de uma impressão de uma máquina. O manual do iftop documenta a seleção da interface, a sintaxe do filtro e o comportamento das pesquisas, que são as três coisas de que depende um teste de fuga. Um ecrã de largura de banda localiza a atividade; a rota, as exceções e o comportamento em caso de falha decidem se essa atividade cumpre o requisito.