O tráfico en eth0 non significa que o túnel VPN teña fugas

Ver enderezos públicos en eth0 mentres o túnel está activo parece a proba de que algo escapou. Normalmente é o contrario: os paquetes do propio túnel teñen que cruzar ese adaptador para chegar ao servidor, e parecen fluxos UDP ou TCP correntes. O paquete interior só aparece no dispositivo do túnel. Distinguir os dous é cuestión de ler o envoltorio, non de confiar nun reconto de bytes.

Cada paquete do túnel segue cruzando o cable

Un túnel é unha interface, non un cable. O cliente toma un paquete interior, envólveo e envía o resultado ao enderezo e ao porto do servidor do perfil. No adaptador físico ve o envoltorio; no dispositivo do túnel ve o que se envolveu.

En modo UDP o fluxo exterior é un único par de enderezo e porto en cada dirección, e por iso un túnel san parece case aburrido en eth0. Ese único par é o primeiro que hai que buscar.

Capture unha interface á vez

Capture unha interface á vez cando pretenda comparar recontos. A pseudointerface any recolle todos os dispositivos á vez, así que un paquete reenviado aparece na entrada e na saída e un xerado localmente aparece dúas veces en dúas formas distintas. Recontos de paquetes iguais con recontos de bytes distintos son normais, porque o envoltorio é maior ca o que transporta. O ARP, o DHCP e os anuncios de router IPv6 pertencen á ligazón local e non din nada sobre a súa aplicación.

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

Substitúa o enderezo e o porto polos valores do propio perfil. Se ese fluxo é constante, o túnel transporta algo.

Pregunte ao núcleo que dispositivo escolle

Pregunte ao núcleo que dispositivo escollería e despois confírmeo no cable. A consulta de ruta é a decisión, e a captura é a proba de que se seguiu a decisión. Responden a preguntas distintas e vostede quere ambas.

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

Un resultado dividido é o achado habitual: IPv4 vai ao túnel e IPv6 vai ao adaptador físico porque o perfil só empurrou rutas IPv4. Iso é unha fuga real, e é invisible nunha captura só de IPv4. Filtre por IPv6 e vixíe os enderezos que non son o servidor nin son link-local.

Execute ambas as consultas antes e despois de conectar, para que poida ver que cambiou realmente o cliente. A diferenza entre as dúas execucións é o efecto real do cliente.

Cando a captura si é unha fuga

Ás veces a captura di a verdade. Unha ruta máis estreita que envía un prefixo por fóra do túnel, unha subrede que se lle dixo ao cliente que excluíse, ou unha aceptación da devasa que se executa antes da política do túnel poden poñer tráfico no cable en claro. Unha regra que coincide cun grupo de procesos tamén pode ser unha excepción deliberada. Lea a súa interface e o seu ámbito de destino antes de cualificalo de fallo.

Corrixa a ruta ou a exclusión, non a devasa. Despois capture de novo desde unha conexión nova e comprobe IPv4 e IPv6 por separado, xa que arranxar un non di nada do outro. O manual de tcpdump cobre os selectores de interface e de dirección usados arriba.