Eine globale IPv6-Adresse heißt nicht, dass der Verkehr den Tunnel umgeht

Eine Testseite meldet eine globale IPv6-Adresse, und die Schlussfolgerung springt sofort zu Verkehr, der das VPN umgeht. Diese Schlussfolgerung braucht zwei Fakten, die die Seite nie zeigte: welche Anwendung die Anfrage gestellt hat und welche Route der Kernel dafür gewählt hat. Der Adressbereich beschreibt, wie weit eine Adresse geroutet werden darf. Er sagt nichts darüber, wohin genau dieses Paket ging.

Bereich und Rolle sind verschiedene Fragen mit verschiedenen Belegen.

Der Geltungsbereich beantwortet, wer sie routen darf, nicht wer es tut

Globale Unicast-Adressen sind im öffentlichen Internet grundsätzlich routingfähig, eindeutige lokale Adressen sind für interne Topologie gedacht, und link-lokale Adressen existieren nur auf einer Verbindung. Das sind Eigenschaften des Adressblocks. Ob ein Paket zu einem bestimmten Ziel den Tunnel verlässt, entscheiden die Routing-Tabelle und die an die Schnittstelle gebundene Richtlinie, und beide können in jede Richtung zeigen.

Eine Adresse kann globalen Geltungsbereich haben und trotzdem in einem Tunnel transportiert werden, weil der Tunnel ein Pfad ist und kein Adressplan.

Lies alle Adressen auf der Schnittstelle, nicht den Webtest

Die Ausgabe der Schnittstelle zeigt mehrere Adressen gleichzeitig: die äußere Adresse auf der physischen Verbindung, die Tunneladresse und eine link-lokale Adresse pro Schnittstelle. Der Webtest zeigt nur die Quelladresse einer einzigen Anfrage. Beginne mit ip -6 addr show und notiere, welche Schnittstelle welche Adresse besitzt und welche Präfixlänge sie trägt, und frage dann, welche Schnittstelle die Anfrage tatsächlich benutzt hat.

Vergleiche das mit ip -6 route get 2606:4700::1111, das die Schnittstelle und die Quelle ausgibt, die der Kernel für ein Ziel wählen würde.

Wie ein globales Präfix in einen Tunnel gelangt

Zwei Entwürfe erzeugen eine globale Adresse auf einer Tunnelschnittstelle. Der Anbieter kann ein Präfix delegieren, das über den Tunnel zum Client geroutet wird, was die Adresse global macht, während der Pfad weiter der Tunnel ist. Oder der Client behält seine native globale Adresse, und der Tunnel trägt sie als inneren Verkehr, während der äußere Header die Arbeit macht. Keiner der Entwürfe verlangt Übersetzung, und die Verwirrung beginnt dort, wo Gewohnheiten aus IPv4 NAT als Anforderung an IPv6 gelten.

Frage den Administrator, welcher der beiden gilt. Die Antwort bestimmt, was ein Server auf der Gegenseite als deine Quelle sieht.

Warum eine privat wirkende Adresse kein Vertrauenssignal ist

Eine eindeutige lokale Adresse sagt, dass der Betreiber sie für internes Routing vorgesehen hat, und mehr nicht. Sie beweist nicht, dass das Gerät verwaltet wird, die Software vertrauenswürdig ist oder der Verkehr verschlüsselt ist. Umgekehrt beweist eine globale Adresse nicht, dass der Verkehr dem Tunnel entkommen ist, und genau diese Annahme soll dieser ganze Artikel zerlegen.

Beurteile Vertrauen nach Richtlinie, Authentifizierung und Verschlüsselung. Das Aussehen einer Adresse ist eine schwache Heuristik, die in beide Richtungen versagt.

Prüfe Route und Richtlinie als zwei Fragen

Erstens die Route: führe curl -6 https://ifconfig.me über den Tunnel und noch einmal über die physische Schnittstelle aus, und vergleiche die Antworten. Zweitens die Richtlinie: bestätige, welches Präfix der Tunnel tatsächlich trägt und ob die Gegenseite eine Rückroute dafür hat. Eine erfolgreiche Anfrage an eine öffentliche Website beweist keines von beiden, weil dieses Ziel von überall erreichbar ist. Nutze ein internes Ziel für den Richtlinientest.

Notiere die Quelladresse, die jeder Pfad erzeugt hat. Das sind die Belege, die eine Behauptung über eine Umgehung wirklich braucht.