Verkehr auf eth0 bedeutet nicht, dass der VPN-Tunnel leckt

Öffentliche Adressen auf eth0 zu sehen, während der Tunnel läuft, wirkt wie ein Beweis, dass etwas entwischt ist. Meist ist es umgekehrt: Die eigenen Pakete des Tunnels müssen diesen Adapter überqueren, um den Server zu erreichen, und sie sehen wie gewöhnliche UDP- oder TCP-Ströme aus. Das innere Paket erscheint nur auf dem Tunnelgerät. Beides zu unterscheiden heißt, den Umschlag zu lesen, nicht einer Byte-Zahl zu vertrauen.

Jedes Tunnelpaket überquert trotzdem die Leitung

Ein Tunnel ist eine Schnittstelle, keine Leitung. Der Client nimmt ein inneres Paket, verpackt es und schickt das Ergebnis an Adresse und Port des Servers aus dem Profil. Am physischen Adapter sehen Sie die Verpackung, am Tunnelgerät sehen Sie das Verpackte.

Im UDP-Modus ist der äußere Strom ein einziges Adress-Port-Paar je Richtung, weshalb ein gesunder Tunnel auf eth0 fast langweilig wirkt. Genau dieses eine Paar ist zuerst zu suchen.

Nehmen Sie jeweils eine Schnittstelle auf

Nehmen Sie jeweils nur eine Schnittstelle auf, wenn Sie Zählungen vergleichen wollen. Die Pseudo-Schnittstelle any sammelt alle Geräte auf einmal, daher erscheint ein weitergeleitetes Paket beim Eintritt und beim Austritt und ein lokal erzeugtes zweimal in zwei verschiedenen Formen. Gleiche Paketzahlen bei ungleichen Byte-Zahlen sind normal, weil die Verpackung größer ist als das, was sie trägt. ARP, DHCP und Router-Ankündigungen für IPv6 gehören zum lokalen Link und sagen nichts über Ihre Anwendung.

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

Ersetzen Sie Adresse und Port durch die Werte des Profils. Ist dieser Strom stetig, trägt der Tunnel etwas.

Fragen Sie den Kernel, welches Gerät er wählt

Fragen Sie den Kernel, welches Gerät er wählen würde, und bestätigen Sie es dann auf der Leitung. Die Routensuche ist die Entscheidung, und die Aufnahme ist der Beleg, dass der Entscheidung gefolgt wurde. Sie beantworten verschiedene Fragen, und Sie wollen beides.

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

Ein geteiltes Ergebnis ist der übliche Befund: IPv4 geht in den Tunnel, und IPv6 geht an den physischen Adapter, weil das Profil nur IPv4-Routen geschoben hat. Das ist ein echtes Leck, und es bleibt in einer reinen IPv4-Aufnahme unsichtbar. Filtern Sie auf IPv6 und achten Sie auf Adressen, die weder der Server noch link-local sind.

Führen Sie beide Abfragen vor und nach dem Verbinden aus, damit Sie sehen, was der Client tatsächlich geändert hat. Der Unterschied zwischen den beiden Läufen ist die reale Wirkung des Clients.

Wenn die Aufnahme wirklich ein Leck ist

Manchmal sagt die Aufnahme die Wahrheit. Eine engere Route, die ein Präfix am Tunnel vorbeischickt, ein Subnetz, das der Client ausschließen sollte, oder eine Firewall-Freigabe, die vor der Tunnelrichtlinie greift, können Verkehr im Klartext auf die Leitung bringen. Auch eine Regel für eine Prozessgruppe kann eine bewusste Ausnahme sein. Lesen Sie deren Schnittstelle und Zielbereich, bevor Sie es einen Fehler nennen.

Korrigieren Sie die Route oder die Ausnahme, nicht die Firewall. Nehmen Sie dann erneut über eine frische Verbindung auf und prüfen Sie IPv4 und IPv6 getrennt, denn die eine Korrektur sagt nichts über die andere. Das tcpdump-Handbuch beschreibt die oben verwendeten Schnittstellen- und Richtungsselektoren.