UDP über Tors SOCKS-Port: Was nicht übertragen wird

Eine Anwendung auf einen SOCKS-Port zu zeigen, funktioniert für einen Browser und scheitert für ein Spiel, und der Grund ist nicht die Konfiguration. SOCKS5 definiert mehrere Befehle, und eine Implementierung darf nur einige davon unterstützen; Tors Schnittstelle nimmt Stream-Verbindungen und Namensauflösung an, keine beliebige Weiterleitung von Datagrammen. Ein Client, der UDP sendet und erwartet, dass der Proxy es weiterleitet, verlangt einen Befehl, den der Server nicht implementiert. Die folgende Anleitung prüft das in wenigen Minuten und wählt dann einen Transport, der tatsächlich funktionieren kann.

Prüfen Sie, was die Anwendung tatsächlich sendet

Beginnen Sie mit der Bestimmung des Transports statt des Protokollnamens. Ein Sprachclient kann sich über HTTPS anmelden und die Medien dann über UDP übertragen; ein Spiel kann sich über TCP authentifizieren und über UDP spielen; eine Dateiübertragung kann TCP zur Steuerung und UDP zur Erkennung nutzen. Die beiden ersten Verhaltensweisen sehen identisch aus, bis die Anmeldung gelingt und der Anruf weiterhin scheitert, weshalb „es hat sich verbunden“ kein Beleg dafür ist, dass die ganze Anwendung funktioniert. Manche Clients fallen auch von selbst von UDP auf TCP zurück, was eine teilweise funktionierende Sitzung wie ein instabiles Netz statt wie einen blockierten Transport aussehen lässt.

Notieren Sie Zielport und Transport für den Teil, der scheitert. Diese eine Zeile entscheidet, ob ein Proxy überhaupt helfen kann.

Was Tors SOCKS-Schnittstelle annimmt

Tor implementiert den Befehl SOCKS5 CONNECT für Stream-Verbindungen und Erweiterungsbefehle zur Namensauflösung, weshalb ein Browser unverändert dadurch funktioniert. UDP ASSOCIATE, der Befehl, mit dem ein Client Datagramme zur Weiterleitung an den Proxy übergeben könnte, gehört nicht zu dem, was Tor anbietet. Die Dokumentation der Erweiterungen steht in der Spezifikation der SOCKS-Erweiterungen des Projekts und ist kurz. Das Fehlen eines Datagramm-Befehls ist beabsichtigt: Beliebiges UDP weiterzuleiten würde dem Netzwerk eine Weiterleitungsrolle geben, für die es nie entworfen wurde.

Das ist auch die Antwort für WireGuard, das konstruktionsbedingt UDP ist und keinen TCP-Rückfallweg hat. Es gibt keinen unterstützten Weg, WireGuard auf einen SOCKS-Port zu zeigen, und alles, was anderes behauptet, ist ein Wrapper mit eigener Vertrauens- und Wartungsgeschichte statt einer Funktion eines der beiden Werkzeuge.

OpenVPN ist die teilweise Ausnahme, weil es sich für einen Tunnel über TCP konfigurieren lässt und eine SOCKS-Proxy-Option versteht. Das erfordert dennoch einen für TCP konfigurierten Server und eine bewusste Entscheidung über die Folgen für Leistung und Fingerabdruck, ist also eine Designentscheidung statt einer Kompatibilitätskorrektur.

Führen Sie die Prüfung der Reihe nach aus

Bestätigen Sie zuerst, dass der Proxy für Streams funktioniert, damit ein späterer Fehler nicht einem unerreichbaren Port angelastet werden kann. Bestätigen Sie dann den eigenen Datenverkehr der Anwendung und beobachten Sie, welche Sockets sie tatsächlich öffnet.

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

Ein erfolgreicher erster Befehl und ein aufgebauter Stream in der zweiten Zeile zeigen, dass der Proxy-Pfad wie vorgesehen funktioniert. Der dritte Befehl sucht lokale Datagramm-Sockets der Anwendung; öffnet der Client einen und sendet direkt an eine entfernte Adresse, hat er den Proxy nie befragt, und keine Proxy-Einstellung wird das ändern. Scheitert es schon im ersten Schritt, halten Sie an und reparieren Sie den Proxy-Pfad, bevor Sie die Anwendung untersuchen, denn zwei Fehler gleichzeitig ergeben einen Bericht, mit dem niemand etwas anfangen kann.

Zurückrollen und das richtige Werkzeug wählen

Entfernen Sie alle Proxy-Umgebungsvariablen oder anwendungsspezifischen Proxy-Einstellungen, die den UDP-Client auf den SOCKS-Port gezeigt haben; bleiben sie stehen, werden spätere Tests mehrdeutig. Stellen Sie die vorherige Konfiguration aus einer Kopie wieder her, starten Sie die Anwendung neu und bestätigen Sie, dass das ursprüngliche Verhalten zurückkehrt, damit der Vergleich sauber ist. Ein nicht überprüfter Rückbau ist nur die Hoffnung, dass sich der Zustand geändert hat.

Für einen Transport, der UDP bleiben muss, ist ein VPN meist die bessere Wahl: Es trägt die Pakete der Anwendung, ohne von ihr ein Proxy-Protokoll zu verlangen, zum Preis von ganz anderen Anonymitätseigenschaften. Nutzen Sie jedes Werkzeug für das, was es dokumentiert, und behandeln Sie jede Brücke dazwischen als separates System, das eine eigene Prüfung braucht. Schreiben Sie im Abschlussbericht fest, welche Schicht welchen Transport trägt, damit die nächste Person dieselbe Grenze nicht mit einer anderen Anwendung neu entdeckt.