Neuer Tor-Kreis vs. VPN-Serverwechsel: Was sich wirklich ändert

Einen Tor-Kreis zu wechseln und einen VPN-Server zu wechseln fühlt sich beides wie eine neue Route an, doch sie brechen an verschiedenen Stellen, wenn man sie als denselben Knopf behandelt. Das eine lässt den Tor-Client einen anderen Pfad für eine Seite bauen, das andere den VPN-Client einen anderen Endpunkt verbinden. Keines ist ein Reset, und die Adresse, die eine Website am Ende sieht, hängt davon ab, welches von beiden näher am Ziel liegt. So entscheide ich, welches Steuerelement ich nehme, und was ich danach prüfe.

Zwei Vorgänge in zwei verschiedenen Schichten

Tor ist eine Überlagerung. Der Client wählt ein Guard-, ein Middle- und ein Exit-Relay und führt dann TCP-Ströme durch diesen Kreis; das Ziel sieht den Exit und sonst nichts. Ein Kreiswechsel ist eine Entscheidung innerhalb von Tor darüber, welche Relays einen Strom tragen.

Ein VPN ist ein Tunnel darunter. Der Client wählt einen Endpunkt, packt den Verkehr in eine äußere Schicht, und alles Folgende sieht die Adresse des Endpunkts. Ein Serverwechsel ist eine Entscheidung darüber, wo der äußere Pfad endet.

Weil die Schichten unabhängig sind, kann der eine Vorgang am fernen Ende der Verbindung unsichtbar sein. Diese Asymmetrie erklärt den größten Teil der Verwirrung um diese beiden Steuerelemente.

Was „Neuer Tor-Kreis für diese Seite“ tut

„Neuer Tor-Kreis für diese Seite“ im Seiteninformationsfeld schließt die Ströme, die Tor für diese Seite trägt, und baut für die nächste Anfrage einen neuen Kreis. Tabs, Cookies, Logins und der Rest der Sitzung bleiben genau, wo sie waren, und das ist der Punkt: Sitzung behalten, Pfad wechseln.

Damit ist es das richtige Werkzeug für einen engen Fehler: ein Exit-Relay, das das Ziel blockiert, eine Captcha-Schleife, die dem Exit folgt, oder eine Seite, die hängt, während alle anderen in Ordnung sind. Die Kreisanzeige im selben Feld listet die drei Relays, sodass man bestätigen kann, dass der Exit wirklich gewechselt hat, statt es anzunehmen.

Achte auf den Guard. Tor hält einen kleinen Satz von Einstiegs-Guards, und ein Kreiswechsel nutzt normalerweise denselben Guard, der erste Sprung im Netz bewegt sich also nicht. „Neue Identität“ ist der größere Reset: Sie schließt Tabs und löscht den Browsing-Zustand, bevor ein neuer Kreis gebaut wird, und die Identitätssteuerung ist aus gutem Grund separat dokumentiert: Es ist ein anderer Vorgang mit anderen Kosten.

Was ein VPN-Serverwechsel tut

Der Client reißt den Tunnel ab und verbindet sich mit einem anderen Endpunkt. Der nächste Sprung außerhalb des Tunnels, ob Tor-Guard oder das Ziel selbst, sieht eine andere Quelladresse. Verbindungen im Tunnel brechen und müssen neu aufgebaut werden, Seiten können also hängen, bis sie auslaufen, statt sauber neu zu laden.

Oberhalb des Tunnels wird nichts umgeschrieben, aber der Abbau ist nicht unsichtbar. In einem VPN-first-Aufbau wählt Tor weiterhin den Exit, doch das Fallen des Tunnels tötet die TCP-Verbindungen, die Tor zu seinem Guard hält, also reißt Tor diese Kreise ab, baut neue und wählt erneut einen Exit. Die Seite kann nach einem Wechsel daher eine andere Exit-Adresse sehen, obwohl der Wechsel selbst nie eine ausgewählt hat. Was der Wechsel entscheidet, ist die Adresse, die der Guard sieht; der neu gebaute Kreis wählt den Exit neu. Wer nur Server wechselt, um zu ändern, was eine Seite sieht, während Tor davorsteht, verschiebt eine Schicht, die die Seite nie direkt beobachtet, und jede bemerkte Änderung kam vom Neubau, nicht vom Wechsel.

Ein Wechsel betrifft außerdem nur die Route, die der Client besitzt. Ein Browser, der eine offene Verbindung wiederverwendet, kann auf dem alten Pfad festhängen, bis er sich neu verbindet, und eine gecachte DNS-Antwort ist der andere übliche Grund. Erst neu laden, dann urteilen.

Die Reihenfolge entscheidet, was das Ziel sieht

Die beiden Reihenfolgen beantworten verschiedene Fragen. Mit dem VPN vor Tor sehen Guard und Relays den VPN-Endpunkt, während das Ziel den Tor-Exit sieht. Mit Tor vor dem VPN sieht das Ziel den VPN-Endpunkt, weil der Tunnel das Letzte ist, was der Verkehr passiert.

Eine IP-Abfrage meldet also, was das Ziel gesehen hat, nicht den Pfad, der es trug. Ein Dienst, der im einen Aufbau den Exit und im anderen das VPN zeigt, verhält sich korrekt und leakt nicht.

Was keiner der beiden Vorgänge tut

Keiner löscht die Identität eines Kontos. Eine angemeldete Sitzung ist ein Cookie plus ein serverseitiger Datensatz, und ein Pfadwechsel berührt keins von beidem. Ein stabiles Browserprofil, derselbe Login und derselbe Fingerabdruck überleben beides.

Keiner ist auch ein Beweis. Eine Website meldet eine Adresse, die sie während einer Anfrage beobachtet hat; sie kann deinen Relay-Pfad nicht melden und nicht, ob dein VPN vor zehn Minuten ausgefallen ist. Brauchst du diese Zeitlinie, schreib sie sofort auf, denn vom fernen Ende lässt sie sich später nicht rekonstruieren.

Passe das Steuerelement zum Symptom

Beginne bei dem, was fehlgeschlagen ist, nicht bei dem Knopf, der gründlicher aussieht:

• Eine Seite blockiert dich, Captchas drehen sich im Kreis oder eine einzelne Seite ist langsam: neuer Kreis für diese Seite.
• Ein reiner VPN-Aufbau braucht eine andere sichtbare Adresse: Server wechseln.
• Du hast einen Exit erwartet, aber die Seite meldet dein VPN: Reihenfolge prüfen, Tor steht hinter dem Tunnel.
• Tabs geschlossen und alles zurückgesetzt: Du hast „Neue Identität“ benutzt, keinen Kreiswechsel.
• Der Exit sieht nach einem Kreiswechsel unverändert aus: Relays dürfen sich wiederholen, und der Guard bewegt sich überhaupt nicht.

Schreib die Aktion und das Symptom, das sie beheben sollte, auf, bevor du etwas anderes änderst. Zwei Wechsel hintereinander ergeben einen Vergleich, der sich nicht deuten lässt, und beide zu wiederholen, wenn nur eine Schicht spinnt, macht aus einer Fünf-Minuten-Prüfung einen ganzen Nachmittag.