Zwei VPN-Hops hintereinander: Wer sieht Ihren Datenverkehr wirklich?

Jedes Client-Profil nennt einen Server, also gibt es aus Sicht des Nutzers einen Tunnel und eine Stelle, an der der Schutz endet. Was nach diesem ersten Gateway geschieht, ist eine Designentscheidung, die der Client nie sieht, und die beiden gängigen Designs verhalten sich bei genauer Prüfung sehr unterschiedlich. In einer seriellen Kette entschlüsselt das erste Gateway und verschlüsselt erneut. In einer verschachtelten Kette entfernt es eine äußere Schicht und leitet einen inneren Tunnel weiter, den es nicht öffnen kann. Die Hop-Anzahl ist in beiden Fällen gleich, deshalb muss der Unterschied gezeichnet statt gezählt werden.

Beim Client beginnen und beide Endpunkte benennen

Beginnen Sie dort, wo der Nutzer beginnt, im Verbindungsprofil. Es enthält eine entfernte Adresse, eine Authentifizierungsmethode und, wenn das Design es unterstützt, eine Routenliste. Bezeichnen Sie diesen äußeren Tunnel vom Client zu Gateway A und geben Sie ihm Beispieladressen: die Tunneladresse des Clients 10.77.0.2, die von A 10.77.0.1 und den öffentlichen Endpunkt von A 198.51.100.10, entnommen aus dem Dokumentationsbereich TEST-NET-2, damit nichts im Beispiel mit einem echten Host kollidieren kann.

Nichts in diesem Profil erwähnt Gateway B, und das ist kein Fehler. Der zweite Hop gehört zu A, und die einzige Pflicht des Clients ist, Datenverkehr an A zu liefern und anzunehmen, was zurückkommt. Ob A den Tunnel beendet, weiterleitet oder einen neuen öffnet, ist die Frage, die der Rest dieses Durchgangs beantwortet, und sie entscheidet, was A lesen kann.

Seriell: A entschlüsselt und verschlüsselt dann erneut

Im seriellen Design beendet A den Datenverkehr zweimal. Es entfernt den Schutz vom Client, erhält das IP-Paket der Anwendung und sendet dieses Paket dann durch einen zweiten Tunnel, den A in Richtung B aufbaut. Zwischen diesen beiden Vorgängen liegt das Paket im Weiterleitungspfad von A als gewöhnliches IP-Paket, das an ein privates Ziel adressiert ist.

Das hat zwei Konsequenzen, die man klar benennen sollte. A kann Richtlinien auf das innere Paket anwenden, in Form von Routen, Filterregeln und Protokollierung von Quelle und Ziel, und A muss zwei Sätze von Anmeldedaten halten: einen als Server für den Client und einen als Client von B. Schutz besteht zu jedem Zeitpunkt, doch das geschützte Objekt wechselt bei A die Identität.

Daraus folgt nicht, dass A den Klartext der Anwendung liest. Wenn Client und Dienst TLS verwenden und gegenseitig ihre Zertifikate prüfen, sieht A einen TLS-Datensatzstrom statt einer lesbaren Anfrage. Wo dieser Schutz endet, zeigt ein Blick auf die Zertifikatskette des Dienstes, nicht auf das Tunnelbild.

Verschachtelt: A entfernt nur die äußere Schicht

Im verschachtelten Design baut der Client zuerst einen inneren Tunnel zu B und trägt diesen Tunnel dann im äußeren zu A. A entfernt den äußeren Header, findet einen inneren Tunnel und leitet ihn weiter, ohne dessen Schlüssel zu halten, sodass der innere Schutz weiterhin bei B endet.

Der Uplink des Clients trägt dann zwei Schichten, während der Pfad zwischen A und B eine trägt. A sieht die äußeren Adressen des inneren Tunnels, was genügt, um zu wissen, dass Datenverkehr existiert und ungefähr wohin er geht, und nicht genügt, um die Nutzlast zu lesen. Das ist der ganze Unterschied zum seriellen Fall, und kein Hop-Zähler zeigt ihn. Was A noch tun kann, ist die Weiterleitung dessen zu verweigern, was es nicht lesen kann, und das steht dem Betreiber dieses Gateways immer offen.

Die Verschachtelung lässt sich das bezahlen. Jede Schicht fügt Header-Overhead hinzu, sodass MTU- und MSS-Planung verpflichtend statt ordentlich wird, und ein Pfad, der mit einer Schicht funktioniert, kann mit zwei große Pakete stillschweigend verwerfen. Jede Schicht braucht zudem eigenes Verhalten für Wiederverbindung und Keepalive, und ein Ausfall in einer Schicht wirkt durch die andere wie eine Teilunterbrechung.

Zeichnen Sie die Beobachter, nicht nur die Tunnel

Die Tunnel sind der leichte Teil der Zeichnung. Die Beobachter sind das, worum es im Design geht, also schreiben Sie eine Zeile pro Sichtpunkt und tragen Sie ein, was jeder tatsächlich lesen kann.

Zwei Zeilen werden ständig verwechselt: der Betreiber von A und der Anbieter des Client-Tunnels. Sie können eine Einheit sein, und getrennte Gateway-Namen machen sie nicht unabhängig. Unabhängige Eigentümerschaft braucht getrennte administrative Kontrolle, getrennte Anmeldedaten und getrennte Protokollierung.

Metadaten überleben beide Designs. Timing, Paketgrößen und Verbindungszahlen bleiben an jedem Hop beobachtbar, zwei Hops erhöhen also die Kosten der Korrelation, statt das Signal zu entfernen. Ein Design, das Unsichtbarkeit verspricht, sollte an dieser Liste geprüft werden, bevor jemand sich darauf verlässt.

Gehen Sie die Fehlerpfade durch, bevor Sie wählen

Zerstören Sie absichtlich Dinge vom Client aus, in der Reihenfolge, in der ein Nutzer sie erleben würde. Beginnen Sie mit der Schnittstelle und ihrer MTU, denn die Verschachtelung scheitert an der Paketgröße lange bevor sie an der Authentifizierung scheitert.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Bestätigen Sie dann die Schutzendpunkte, statt sie anzunehmen. Fragen Sie den Dienst nach seinem Zertifikat von innerhalb des gerade aktiven Tunnels und vergleichen Sie die Kette, die der Client sieht, mit der Kette, die der Dienst tatsächlich vorlegt. Ein Gateway, das neu signiert oder abfängt, ändert dieses Zertifikat, und die Prüfung wird in einem einzigen Befehl sichtbar.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Schließen Sie mit der Wiederverbindungsmatrix ab: Der Tunnel des Clients fällt aus, der Tunnel von B fällt aus, der Pfad zwischen A und B ändert sich. Notieren Sie, was zurückkommt und was nicht, und ob eine innere Verbindung je auf eine Route außerhalb ihres vorgesehenen Trägers zurückfällt. Halten Sie die Adressen fest, die jeder Test verwendet hat, denn die Wiederholung in einem anderen Zugangsnetz beantwortet eine andere Frage. Wiederholen Sie auch die MTU-Prüfung nach jeder Wiederverbindung, denn ein geänderter Pfad kann die nutzbare Größe senken, ohne dass eine einzige Konfigurationszeile sich bewegt.

Wählen Sie seriell, wenn A Richtlinien auf das innere Paket anwenden muss oder wenn der Client keine zwei gestapelten Tunnel betreiben kann. Wählen Sie die Verschachtelung, wenn die innere Nutzlast bei A unlesbar bleiben muss. Schreiben Sie die Wahl mit ihren Beobachtern und ihren MTU-Zahlen auf, und die nächste Person muss nicht das ganze Bild neu zeichnen, um eine Frage zu beantworten.