O tráfego em eth0 não significa que o túnel VPN vaze

Ver endereços públicos em eth0 enquanto o túnel está ativo parece a prova de que algo escapou. Normalmente é o contrário: os pacotes do próprio túnel têm de atravessar esse adaptador para chegar ao servidor, e parecem fluxos UDP ou TCP comuns. O pacote interno só aparece no dispositivo do túnel. Distinguir os dois é uma questão de ler o envelope, não de confiar numa contagem de bytes.

Cada pacote do túnel ainda atravessa o fio

Um túnel é uma interface, não um fio. O cliente pega num pacote interno, envolve-o e envia o resultado para o endereço e a porta do servidor do perfil. No adaptador físico vê o invólucro; no dispositivo do túnel vê o que foi envolvido.

No modo UDP o fluxo externo é um único par de endereço e porta em cada direção, e é por isso que um túnel saudável parece quase aborrecido em eth0. É precisamente esse par único que deve ser procurado primeiro.

Capture uma interface de cada vez

Capture uma interface de cada vez quando pretende comparar contagens. A pseudointerface any recolhe todos os dispositivos de uma vez, por isso um pacote reencaminhado aparece à entrada e à saída e um gerado localmente aparece duas vezes em duas formas diferentes. Contagens de pacotes iguais com contagens de bytes diferentes são normais, porque o invólucro é maior do que aquilo que transporta. O ARP, o DHCP e os anúncios de router IPv6 pertencem à ligação local e não dizem nada sobre a sua aplicação.

sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194

Substitua o endereço e a porta pelos valores do próprio perfil. Se esse fluxo for constante, o túnel transporta algo.

Pergunte ao núcleo qual dispositivo ele escolhe

Pergunte ao núcleo qual dispositivo escolheria e depois confirme no fio. A consulta de rota é a decisão, e a captura é a prova de que a decisão foi seguida. Respondem a perguntas diferentes e você quer as duas.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Um resultado dividido é o achado habitual: o IPv4 vai para o túnel e o IPv6 vai para o adaptador físico porque o perfil só empurrou rotas IPv4. Isso é um vazamento real, e é invisível numa captura apenas de IPv4. Filtre IPv6 e vigie endereços que não são o servidor e não são link-local.

Execute as duas consultas antes e depois de ligar, para ver o que o cliente realmente mudou. A diferença entre as duas execuções é o efeito real do cliente.

Quando a captura é mesmo um vazamento

Às vezes a captura diz a verdade. Uma rota mais estreita que envia um prefixo ao lado do túnel, uma sub-rede que se disse ao cliente para excluir, ou uma aceitação da firewall que corre antes da política do túnel podem todas pôr tráfego no fio em claro. Uma regra que corresponde a um grupo de processos também pode ser uma exceção deliberada. Leia a interface e o âmbito de destino antes de a chamar defeito.

Corrija a rota ou a exclusão, não a firewall. Depois capture outra vez a partir de uma ligação nova e verifique IPv4 e IPv6 em separado, porque corrigir um não diz nada sobre o outro. O manual do tcpdump cobre os seletores de interface e de direção usados acima.