El tráfico en eth0 no significa que el túnel VPN tenga fugas

Ver direcciones públicas en eth0 mientras el túnel está activo parece la prueba de que algo se ha escapado. Normalmente es lo contrario: los paquetes del propio túnel tienen que cruzar ese adaptador para llegar al servidor, y parecen flujos UDP o TCP corrientes. El paquete interior solo aparece en el dispositivo del túnel. Distinguir los dos es cuestión de leer el envoltorio, no de fiarse de un recuento de bytes.

Cada paquete del túnel sigue cruzando el cable

Un túnel es una interfaz, no un cable. El cliente toma un paquete interior, lo envuelve y envía el resultado a la dirección y el puerto del servidor del perfil. En el adaptador físico ve el envoltorio; en el dispositivo del túnel ve lo que se envolvió.

En modo UDP el flujo exterior es un único par de dirección y puerto en cada dirección, y por eso un túnel sano parece casi aburrido en eth0. Ese único par es lo primero que hay que buscar.

Capture una interfaz a la vez

Capture una interfaz a la vez cuando pretenda comparar recuentos. La pseudointerfaz any recoge todos los dispositivos a la vez, así que un paquete reenviado aparece en la entrada y en la salida y uno generado localmente aparece dos veces en dos formas distintas. Recuentos de paquetes iguales con recuentos de bytes distintos son normales, porque el envoltorio es mayor que lo que transporta. El ARP, el DHCP y los anuncios de router IPv6 pertenecen al enlace local y no dicen nada sobre su aplicación.

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

Sustituya la dirección y el puerto por los valores del propio perfil. Si ese flujo es constante, el túnel transporta algo.

Pregunte al núcleo qué dispositivo elige

Pregunte al núcleo qué dispositivo elegiría y luego confírmelo en el cable. La consulta de ruta es la decisión, y la captura es la prueba de que se siguió la decisión. Responden a preguntas distintas y usted quiere ambas.

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

Un resultado dividido es el hallazgo habitual: IPv4 va al túnel e IPv6 va al adaptador físico porque el perfil solo empujó rutas IPv4. Eso es una fuga real, y es invisible en una captura solo de IPv4. Filtre por IPv6 y vigile las direcciones que no son el servidor ni son link-local.

Ejecute ambas consultas antes y después de conectar, para que pueda ver qué cambió realmente el cliente. La diferencia entre las dos ejecuciones es el efecto real del cliente.

Cuando la captura sí es una fuga

A veces la captura dice la verdad. Una ruta más estrecha que envía un prefijo por fuera del túnel, una subred que se le dijo al cliente que excluyera, o una aceptación del cortafuegos que se ejecuta antes de la política del túnel pueden poner tráfico en el cable en claro. Una regla que coincide con un grupo de procesos también puede ser una excepción deliberada. Lea su interfaz y su ámbito de destino antes de calificarlo de fallo.

Corrija la ruta o la exclusión, no el cortafuegos. Luego capture de nuevo desde una conexión nueva y compruebe IPv4 e IPv6 por separado, ya que arreglar uno no dice nada del otro. El manual de tcpdump cubre los selectores de interfaz y de dirección usados arriba.