VPN in Tor, Tor in VPN: Warum die Kette bricht
Wenn VPN, Tor und ein Proxy gestapelt werden, entscheidet die Reihenfolge, was aufgelöst und was übertragen wird. Finde die erste gebrochene Grenze, bevor du alle drei änderst.
Ein VPN, Tor und einen Anwendungsproxy zu stapeln wirkt wie eine Vervielfachung der Privatsphäre, und es vervielfacht die Zahl der Stellen, an denen eine Verbindung sterben kann. Das übliche Ergebnis ist ein Browser, der dreht, während drei Werkzeuge sich jeweils gesund melden. Ändert man dann alle drei Einstellungen auf einmal, beseitigt man den einzigen Hinweis darauf, welches von ihnen lügt.
Zeichne zuerst den beabsichtigten Weg in der richtigen Reihenfolge auf und benenne, welches Programm jede Verbindung öffnet und welcher Name bei jedem Schritt aufgelöst wird.
Schichten addieren sich nicht, sie wirken aufeinander
Ein VPN vor Tor bedeutet, dass die Eintrittsverbindung des Tor-Clients innerhalb des Tunnels verläuft. Ein durch Tor geführtes VPN bedeutet, dass der eigene Endpunkt des VPN-Clients über Tor erreichbar sein muss, was eine ganz andere Anforderung ist. Der Browser-Proxy fügt einen weiteren Sprung hinzu, von dem das Betriebssystem nichts weiß. Drei Anordnungen, drei getrennte Abhängigkeitslisten.
Jede Anordnung ändert, was aufgelöst, was übertragen werden kann und wer das erste Paket sieht. Nur eine davon kann die Konfiguration sein, die du gemeint hast.
Nimm auch den direkten Weg ins Diagramm auf. Eine Ausweichroute, eine Ausnahme für geteiltes Tunneling oder eine Proxy-Umgehung können eine Seite laden lassen, während sie die Kette, die du testen wolltest, stillschweigend überspringen, und dieser Erfolg ist irreführender als der Fehler.
Die Reihenfolge entscheidet, was übertragen werden kann
Tor überträgt TCP-Ströme über seine SOCKS-Schnittstelle, und ein Client, der den Proxy bittet, den Hostnamen aufzulösen, hält die Abfrage im Circuit. UDP reist in gewöhnlichen Konfigurationen nicht so, weshalb ein WireGuard-Tunnel nicht in Tor verschachtelt werden kann, ohne ein zusätzliches TCP-Relais dazwischen.
OpenVPN lässt sich auf TCP zwingen, also ist diese Anordnung zumindest beschreibbar. Sie ist auch langsamer und fragiler, und das Fehlerbild beim Abbruch sieht aus wie ein blockierter Port. Erwarte, länger mit dem Unterscheiden der beiden zu verbringen als mit der Reparatur einer von ihnen.
Die Auflösung ist die andere Hälfte. Mit --socks5-hostname löst der Proxy das Ziel auf, während einfaches --socks5 zuerst den lokalen Resolver fragt und den Namen außerhalb des Circuits preisgibt. Genau dieses eine Flag entscheidet, ob die Namensabfrage zur Kette oder zu deinem Anbieter gehört.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
Die erste gebrochene Grenze finden
Teste die Stufen in der Reihenfolge, in der die Pakete reisen, mit harmlosen Anfragen und halte bei der ersten an, die scheitert. Notiere, welcher Befehl zuerst lief, denn die Reihenfolge ist Teil des Beweises. Zwei Befehle trennen einen toten Circuit von einem toten Ausgang:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Der erste meldet, ob eine Anfrage überhaupt durch den SOCKS-Proxy abgeschlossen wird, und der zweite zeigt die Adresse, die das Netzwerk gerade präsentiert. Scheitert der erste und gelingt der zweite, liegt das Problem beim Tor-Client oder davor. Gelingen beide und der Browser scheitert weiterhin, nutzt die Anwendung einen anderen Weg als die Shell.
Eine Seite mit der öffentlichen IP beschreibt außerdem nur den letzten sichtbaren Ausgang. Sie kann nicht sagen, wie viele Sprünge davor lagen, also kombiniere sie mit der unterstützten Statusausgabe jedes Werkzeugs, statt eine einzelne Zahl als Diagramm zu behandeln.
Wann man aufhören sollte, Schichten hinzuzufügen
Wenn du nicht in einem Satz sagen kannst, was eine Schicht beiträgt, entferne sie. Eine Kette, deren Zweck unklar ist, ist eine Kette, die niemand um drei Uhr nachts debuggen kann, und der Privatsphäregewinn eines unerklärten Sprungs ist meist kleiner als die Verfügbarkeit, die du verlierst.
Wenn eine Schicht ihren Platz wirklich verdient, teste sie zuerst allein, füge dann die nächste hinzu und bestätige den Weg erneut mit denselben zwei Befehlen. Stelle vor dem gewöhnlichen Gebrauch die vollständige Kette wieder her und lass TLS-Validierung und Authentifizierung eingeschaltet; eine Zertifikatswarnung, die akzeptiert wird, damit eine Seite lädt, ist ein Routing-Behelf, keine Reparatur. Notiere die Reihenfolge, auf die du dich festgelegt hast, solange sie frisch ist.
Schreib diese Reihenfolge auf, einschließlich des Resolvers, der auf jeder Stufe antwortet. Eine funktionierende Kette, die du beschreiben kannst, übersteht das nächste Update, während eine funktionierende Kette, die du durch Ausprobieren zusammengesetzt hast, mit ihm verschwindet. Ergänze Datum und Versionen, damit ein späterer Fehler mit einem bekannt guten Zustand verglichen werden kann, statt aus dem Gedächtnis diskutiert zu werden. Zehn Zeilen in einer Textdatei sparen einen Abend Rätselraten.