Der Client meldet verbunden, das Schloss ist zu, und eine Website protokolliert trotzdem die Adresse Ihrer Wohnung. Nichts ist ausgefallen. Ein Tunnel ersetzt weder Ihr WLAN noch Ihre Mobilfunkverbindung; er legt einen zweiten Umschlag um ausgewählte Pakete und schickt diesen Umschlag über das Netz, das Sie ohnehin hatten. Den Trick zu verstehen heißt vor allem, einer Anfrage zu folgen und zu bemerken, wo der Umschlag geöffnet wird, denn fast jedes verwirrende Symptom, von der durchsickernden Heimatadresse bis zum hängenden großen Download, stammt von dieser Grenze.

Zwei Umschläge, eine physische Strecke

Ihr Laptop behält seine normale Verbindung zum Router, und der Router behält seine normale Verbindung zum Anbieter. An diesem Weg ändert sich nichts, wenn ein Tunnel hochkommt. Was sich ändert, ist, dass ausgewählte Pakete an eine virtuelle Schnittstelle übergeben, in ein neues, an den VPN-Peer adressiertes Paket gewickelt und als gewöhnlicher Verkehr über die physische Strecke gesendet werden.

Die Gegenseite ist ein Gerät, das den Umschlag öffnet und das ursprüngliche Paket zu seinem Ziel weiterleitet. Zwischen den beiden Enden sieht ein Beobachter den äußeren Kopf und nichts über den inneren, sofern das Protokoll ihn nicht verschlüsselt, was die meisten Verbraucherprotokolle tun und die allgemeine Technik nicht verlangt.

Darum ist die virtuelle Schnittstelle zugleich real und irreführend. Sie existiert als Kernelobjekt mit einer Adresse und einer maximalen Übertragungseinheit, und das Betriebssystem leitet Verkehr hinein wie in jede andere Schnittstelle. Sie ist kein Kabel, und ihre Existenz beweist nur, dass eine Komponente installiert ist. Ob Ihr Browser sie nutzt, entscheiden Routen, nicht die Tatsache, dass die Schnittstelle aktiv ist.

Verfolgen Sie eine Anfrage auf ihrer Reise

Wählen Sie ein Ziel und fragen Sie den Kernel, welche Schnittstelle er verwenden wird. Dieser eine Befehl entscheidet die meisten Diskussionen darüber, ob der Tunnel überhaupt etwas tut:

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

Nennt die Routenausgabe die Tunnelschnittstelle, wird das Paket eingewickelt. Nennt sie die physische Schnittstelle, wird es das nicht, und kein Neustart des Clients ändert daran etwas. Der zweite Befehl zeigt beide Schnittstellen nebeneinander, und genau so entdecken Sie einen Tunnel, der ohne Adresse oder mit einer Adresse aus der falschen Familie hochkam.

Schauen Sie dann auf den ersten Sprung von innerhalb des Umschlags und vergleichen Sie ihn mit dem ersten Sprung außerhalb:

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

Innerhalb des Tunnels ist der erste Sprung die innere Adresse des Peers, nicht Ihr Router. Die Aufzeichnung an der Tunnelschnittstelle zeigt die inneren Pakete, also den Verkehr, den die Anwendung zu senden glaubt. Die gleichzeitige Aufzeichnung an der physischen Schnittstelle zeigt die äußeren Pakete, und beides zusammen ist der klarste Beweis dafür, was ein Tunnel tatsächlich tut.

Drei Adressen, und nur eine sieht die Website

Menschen verwechseln das ständig, und die Verwechslung erzeugt falsche Leckberichte. Es sind verschiedene Felder in verschiedenen Köpfen mit verschiedenen Lebensdauern.

AddressWhere it appearsWho can see it
Endpoint addressOuter header, the peer you connect toYour access network and the path to it
Inner tunnel addressInside the envelope, on the virtual interfaceThe peer, and anything the peer routes to
Exit addressSource of the packet that reaches the websiteThe website and its upstream

Die Nummer neben dem virtuellen Adapter ist die zweite Zeile. Sie ist nicht die Adresse, die eine Website protokolliert, und sie als Ihre öffentliche IP zu zitieren ist schlicht falsch. Die Adresse, die eine Website sieht, wird vom Ausgang vergeben, und bei einem Tunnel in ein privates Netz gibt es womöglich gar keinen öffentlichen Ausgang, weil das Ziel innerhalb der Organisation liegt und nicht im Internet.

Ein Tunnel zwischen zwei Standorten ist derselbe Mechanismus mit anderen Endpunkten. Zwei Router wickeln Verkehr zwischen Netzen ein, und kein einzelnes Gerät hat einen Client installiert. Der Umschlag ist im Prinzip identisch, die administrative Grenze nicht.

Wo der Umschlag geöffnet wird und was ihn überlebt

Der Tunnel endet an seinem Peer. Reicht die eigene Verschlüsselung der Anwendung weiter, überlebt sie diese Grenze, was der Normalfall bei HTTPS ist: Die Sitzung des Browsers endet an der Website, also leitet der Ausgang Chiffretext weiter, den er nicht lesen kann.

Sonst überlebt nichts standardmäßig. Eine unverschlüsselte Anfrage ist am Ausgang genauso lesbar, wie sie im WLAN des Cafés lesbar war, und der Tunnel fügt keinen Schutz hinzu, den die Anwendung nie hatte. Ebenso entscheiden die Firewallregeln und die Weiterleitungsrichtlinie des Ausgangs, was als Nächstes geschieht; ein erfolgreicher Handshake ist eine Tatsache über die Peer-Verbindung, nicht über den Rest der Reise.

Der Overhead ist die andere sichtbare Folge. Jedes Paket trägt einen zusätzlichen Kopf, und der äußere Transport kann seinen eigenen hinzufügen, sodass die nutzbare Nutzlast pro Paket schrumpft. Auf einem Weg mit fester maximaler Übertragungseinheit ist genau das der Grund, warum ein Tunnel einen Ping durchlässt und einen großen Upload blockiert.

Prüfen Sie den Weg, den die Anwendung tatsächlich genommen hat

Der letzte Schritt ist, die konkrete Anwendung zu bestätigen statt der Maschine im Allgemeinen. Lösen Sie das Ziel auf, sehen Sie sich die Route für diese Adresse an und beobachten Sie dann die Verbindung, solange sie offen ist:

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

Nennt die Route den Tunnel, zeigt die Socket-Liste aber eine Verbindung mit einer Quelladresse von der physischen Schnittstelle, ist die Anwendung an etwas Bestimmtes gebunden, oder ein zweiter Tunnel konkurriert um die Standardroute. Das ist eine Routingfrage, und sie lässt sich aus diesen drei Ausgaben beantworten statt aus dem Statusbildschirm des Clients.

Die Sicherheitsarchitektur RFC 4301 beschreibt die IP-Schicht-Version dieses Einwickelns für IPsec, und dieselbe Schichtenlogik gilt für WireGuard und OpenVPN. Sobald Sie das innere Paket und das äußere Paket als getrennte Objekte benennen können, verliert das meiste Tunnelverhalten das Rätselhafte und wird zu einer Routing-Tabelle, die Sie lesen können.

Ähnliche Artikel