Zwei VPNs hintereinanderschalten: Was es verbirgt und was es kostet

Zwei verschachtelte Tunnel machen Sie nicht anonym. Sie verteilen die Beobachtungen auf zwei Anbieter, sodass keiner von beiden Ihre Heimatadresse und Ihr Ziel zugleich sieht. Das ist ein echter, aber schmaler Vorteil, und er geht mit Routing-, DNS- und MTU-Problemen einher, die beim ersten Mal auftreten, wenn Sie sich darauf verlassen.

1. Entscheiden Sie, wozu der zweite Hop dient

Schreiben Sie das Ziel in einem Satz auf, bevor Sie irgendetwas konfigurieren. Wenn es darum geht, dass Ihr Provider nicht sieht, welche Seiten Sie besuchen, erreicht das ein Tunnel. Wenn es darum geht, dass kein einzelner Anbieter Ihre Adresse mit Ihrem Verkehr verknüpfen kann, erreichen das zwei. Wenn es darum geht, dass niemand Sie identifizieren kann, führt keine Anzahl von Hops dorthin.

Die Kette ist nur so stark wie die Protokolle des schwächeren Anbieters und die Kontounterlagen, die beide führen. Zahlungen, Anmelde-E-Mail und App-Telemetrie liegen völlig außerhalb des Tunnels.

2. Machen Sie den inneren Endpunkt durch den äußeren Tunnel erreichbar

Der übliche Fehler ist, dass der innere Tunnel nie zustande kommt. Eine äußere Verbindung mit vollem Tunnel besitzt die Standardroute, also wird der Versuch des inneren Clients, seinen eigenen Endpunkt zu erreichen, vom äußeren Tunnel verschluckt und verworfen oder in eine Schleife geschickt. Der innere Endpunkt braucht eine explizite Route über die äußere Schnittstelle, eingerichtet bevor der innere Client startet. Sonst läuft der Handshake der Route davon und verliert.

WireGuard zeigt denselben Konflikt aus der anderen Richtung. Die AllowedIPs jedes Peers entscheiden, welche Ziele in diesen Tunnel gelangen, also beansprucht eine innere Schnittstelle, die jede Adresse reklamiert, auch den äußeren Endpunkt, sofern keine spezifischere Route gewinnt. Überlappende AllowedIPs über zwei Schnittstellen hinweg sind eine Konfiguration, bei der eine Seite still verliert.

Containerketten machen die Trennung ausdrücklich und die Falle offensichtlich. Ein Container mit eigenem Namespace, eigener Standardroute und einem Client darin leitet weiter, was der Host ihm schickt; der Host beginnt nicht von selbst, diesen Weg zu nutzen. Aktivieren Sie die Weiterleitung, fügen Sie eine Route für den Tunnel des Containers hinzu und richten Sie den Dienst auf die Containeradresse.

3. Halten Sie DNS auf demselben Weg

DNS muss dorthin reisen, wohin der Verkehr reist. Wenn der innere Anbieter Resolver vorgibt und der Host weiterhin die lokalen fragt, verraten diese Abfragen genau die Seiten, die der Tunnel verbergen sollte. Prüfen Sie mit einem Mitschnitt an jeder Tunnelschnittstelle, statt dem Statusfenster des Clients zu vertrauen. Ein Leck ist hier beim normalen Surfen unsichtbar und im Mitschnitt offensichtlich.

Split-DNS-Entwürfe machen das schwieriger, weil eine Abfrage für einen lokalen Namen legitim außerhalb des Tunnels gehören kann. Schreiben Sie die Ausnahmeliste bewusst auf, statt sie danach zu entdecken, welcher Resolver zufällig geantwortet hat.

4. Setzen Sie die MTU, bevor Nutzer es für Sie herausfinden

Die MTU ist das andere vorhersehbare Opfer. Zwei Kapselungen ziehen zwei Header ab, und ein äußerer Tunnel, der die Pfad-MTU schon gesenkt hat, lässt innen weniger Platz. Die Symptome sind vertraut: kleine Anfragen gelingen, große Übertragungen und TLS-Handshakes stocken.

ip link set dev wg1 mtu 1280 ist der grobe Fix, und MSS am Weiterleiter zu begrenzen der sauberere. Die Verbindung erneut zu versuchen ist überhaupt kein Fix.

5. Testen Sie den Ausfall, den Sie tatsächlich bekommen

Unterbrechen Sie den äußeren Tunnel absichtlich und beobachten Sie, was passiert. Eine Kette, die still auf einen direkten Weg zurückfällt, wenn der äußere Hop stirbt, ist schlimmer als keine Kette, weil sie genau in dem Moment leckt, in dem Sie sich abgesichert glaubten. Ein Kill Switch, der den gesamten Verkehr stoppt, ist das anzustrebende Verhalten. Halten Sie das Ergebnis fest, denn Sie wollen es nicht mitten in einem Vorfall neu entdecken.

Latenz und ein zweiter Ausfallpunkt sind die laufenden Kosten. Zwei Hops bedeuten auch zwei Support-Schlangen, wenn etwas zu einer ungünstigen Stunde kaputtgeht.