Tor-Relay versus VPN-Server: Warum sie nicht austauschbar sind

Sie haben eine Adresse, der Port antwortet, und ein Client akzeptiert sie ohne Beschwerde. Nichts davon macht ein Tor-Relay zu einem VPN-Endpunkt, und der Fehler ist teuer, weil das Profil sauber importiert wird und später beim Handshake scheitert. Ich nutze die vier Prüfungen unten in dieser Reihenfolge; jede hat eine Abbruchbedingung, und früh abzubrechen ist der Punkt. Wenn die erste Prüfung scheitert, können die übrigen Ihnen nicht helfen.

Prüfen Sie, was der Port tatsächlich bedient

Ein offener Port beweist einen Listener, mehr nicht. Der ORPort eines Relays spricht nach einem TLS-Handshake die eigenen Zellen von Tor, daher sagt eine erfolgreiche TLS-Prüfung fast nichts darüber aus, ob dort ein VPN-Protokoll akzeptiert wird:

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

Lesen Sie das Zertifikat statt der Tatsache, dass eines existiert. Relays präsentieren ein selbstsigniertes Zertifikat mit bewusst unauffälligem Namen, weil Relay-Verkehr gewöhnlichem HTTPS ähneln soll; das Zertifikat eines VPN-Servers trägt den Namen, den Ihr Profil erwartet. Wenn die Gegenstelle nie auf das erste Paket des VPN-Protokolls antwortet, ändert kein noch so großer Aufwand beim Bearbeiten des Profils das Ergebnis.

Stoppen Sie hier, wenn die Adresse den Handshake Ihres Clients nicht abschließt. Das ist eine Protokollantwort, kein Konfigurationsproblem, und es ist der bei weitem häufigste Grund, warum ein importiertes Profil dauerhaft auf 'connecting' steht.

Prüfen Sie die Rolle des Relays, nicht die Größe des Netzes

Relay-Rollen erfüllen verschiedene Aufgaben. Ein Guard ist der erste Sprung für Clients, ein mittleres Relay leitet Circuits zwischen anderen Relays weiter, ein Exit ist derjenige, der Ziele berührt, und eine Brücke ist ein nicht öffentlicher Einstiegspunkt, der über BridgeDB verteilt wird. Das Glossar von Tor hält diese Definitionen getrennt, und Erreichbarkeit ist Teil jeder Rolle, während die Berechtigung, beliebige Clients zu bedienen, zu keiner von ihnen gehört.

Die Exit-Policy ist lesenswert, weil sie der einzige Teil ist, der einer Weiterleitungsregel ähnelt, und sie regelt die Ziele, die der Exit nach außen zulässt, nicht die Clients, die hereingelassen werden. Eine restriktive Exit-Policy, die Port 25 blockiert, sagt etwas über die Kontrolle ausgehenden Missbrauchs aus, nicht darüber, ob Sie einen OpenVPN-Client auf die Maschine richten dürfen.

Stoppen Sie, wenn Sie aus dem Ruf argumentieren: weil Relays Verkehr weiterleiten, müsse die Adresse Ihren annehmen. Tor wählt Pfade über Konsens und sein eigenes Protokoll; ein VPN-Client ist kein Teilnehmer und hat keinen Circuit, dem er beitreten könnte.

Prüfen Sie, ob der SOCKS-Listener lokal oder öffentlich ist

Der Tor-Client stellt eine SOCKS-Schnittstelle für Anwendungen auf derselben Maschine bereit, standardmäßig auf Loopback. Dieser Listener ist eine lokale Bequemlichkeit, kein Dienst, den ein Relay dem Internet anbietet, und ihn als öffentlichen Proxy zu behandeln, ist der Weg, auf dem Leute am Ende ein offenes Relay betreiben, das sie nicht beabsichtigt hatten:

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

Die Bind-Adresse ist der Hinweis. Ein SocksPort auf 127.0.0.1:9050 tut seine Arbeit; einer, der auf 0.0.0.0 lauscht und von außen erreichbar ist, ist ein offener Proxy, und die Zugriffsrichtlinien von Tor existieren gerade deshalb, weil diese Exposition ein Problem und keine Funktion ist.

Für eine Anwendung, die Tor braucht, richten Sie sie auf den Loopback-Port und lassen Tor Namen auflösen, was die Form socks5h oben tut. Ersetzen Sie diesen Port nicht durch eine Relay-Adresse; das Relay bietet nicht die Schnittstelle, die Ihre Anwendung verlangt.

Prüfen Sie, ob das VPN-Profil zu einem echten Endpunkt passt

Ein VPN-Profil ist ein Bündel von Erwartungen: OpenVPN braucht das Serverzertifikat oder die CA, ein Clientzertifikat und einen Schlüssel und meist einen TLS-Schlüssel, während WireGuard den öffentlichen Schlüssel der Gegenstelle, einen Endpunkt und erlaubte IPs braucht. Nichts davon lässt sich aus einer Adresse und einem offenen Port ableiten, weshalb ein so gebautes Profil beim ersten Austausch scheitert und nicht beim Verbinden.

Wenn Ihnen ein Profil übergeben wird, prüfen Sie es gegen einen Endpunkt, den Sie kontrollieren, oder einen Anbieter, den Sie identifizieren können:

wg show
openvpn --config client.ovpn --verb 4

Im OpenVPN-Protokoll benennt ein TLS-Aushandlungsfehler die Abweichung direkt; in wg show hat eine Gegenstelle ohne Handshake-Zeile nie eine abgeschlossen. Beides ist aussagekräftiger als der drehende Indikator des Clients, und beides deutet auf Schlüsselmaterial oder Protokoll hin und nicht auf Tor.

Prüfen Sie, welchen Schutz Sie tatsächlich brauchen

Diese Prüfung entscheidet die Architektur. Der Tor Browser gibt Ihnen Circuit-Isolation und Fingerprinting-Schutz, den eine VPN nicht bietet; eine VPN ändert die Adresse, die ein Ziel sieht, und authentifiziert Sie gegenüber einem Anbieter. Die Wahl zwischen beiden ist eine Frage des Bedrohungsmodells, keine der Kompatibilität, und ihre Vermischung ergibt ein Setup, das privat aussieht und es nicht ist.

Verkettung hat eine Reihenfolge. Eine VPN, die Tor-Verkehr trägt, ist eine unterstützte Anordnung, weil der Tor-Client nur ausgehendes TCP braucht. Ein VPN-Client, der innerhalb von Tor getunnelt wird, ist nicht dasselbe und nicht das, was der Tor-Client umsetzt, planen Sie also nicht damit.

Bevor Sie etwas importieren, bestätigen Sie alle vier:

• Der Port schließt den Handshake Ihres Protokolls ab, nicht nur eine TCP-Verbindung.
• Sie kennen die Rolle des Hosts und behandeln Weiterleitung nicht als Berechtigung.
• Der SOCKS-Listener, den Sie nutzen, ist Loopback und Ihrer, kein öffentlicher Port auf dem Relay eines anderen.
• Die Schlüssel oder Zertifikate des Profils gehören zu dem Endpunkt, mit dem Sie sich verbinden.