Tor-relay versus VPN-server: waarom ze niet uitwisselbaar zijn

Je hebt een adres, de poort antwoordt, en een client accepteert het zonder klachten. Niets daarvan maakt van een Tor-relay een VPN-eindpunt, en de fout is duur omdat het profiel netjes importeert en later bij de handshake faalt. Ik gebruik de vier controles hieronder in volgorde; elk heeft een stopvoorwaarde, en vroeg stoppen is juist het punt. Als de eerste controle faalt, kunnen de andere je niet helpen.

Controleer wat de poort werkelijk bedient

Een open poort bewijst een luisteraar, niet meer. De ORPort van een relay spreekt na een TLS-handshake de eigen cellen van Tor, dus een geslaagde TLS-test zegt bijna niets over de vraag of daar een VPN-protocol wordt geaccepteerd:

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

Lees het certificaat in plaats van het feit dat er een bestaat. Relays presenteren een zelfondertekend certificaat met een bewust onopvallende naam, omdat relayverkeer op gewone HTTPS moet lijken; het certificaat van een VPN-server draagt de naam die je profiel verwacht. Als de tegenpartij nooit antwoordt op het eerste pakket van het VPN-protocol, verandert geen enkele profielbewerking de uitkomst.

Stop hier als het adres de handshake die je client stuurt niet voltooit. Dat is een protocolantwoord, geen configuratieprobleem, en het is de meest voorkomende reden waarom een geïmporteerd profiel voor altijd op 'connecting' blijft staan.

Controleer de rol van de relay, niet de grootte van het netwerk

Relayrollen doen verschillend werk. Een guard is de eerste sprong voor clients, een middenrelay stuurt circuits tussen andere relays door, een exit is degene die bestemmingen aanraakt, en een brug is een niet-openbaar toegangspunt dat via BridgeDB wordt uitgegeven. Het woordenboek van Tor houdt die definities gescheiden, en bereikbaarheid is deel van elke rol terwijl toestemming om willekeurige clients te bedienen van geen enkele deel is.

Het exitbeleid is de moeite van het lezen waard omdat het het enige deel is dat op een doorstuurregel lijkt, en het regelt de bestemmingen die de exit naar buiten toelaat, niet de clients die binnen worden toegelaten. Een restrictief exitbeleid dat poort 25 blokkeert, zegt iets over de beheersing van uitgaand misbruik, niet over de vraag of je een OpenVPN-client naar de machine mag richten.

Stop als je redeneert vanuit reputatie: omdat relays verkeer doorsturen, zou het adres het jouwe moeten accepteren. Tor kiest paden via consensus en zijn eigen protocol; een VPN-client is geen deelnemer en heeft geen circuit om bij aan te sluiten.

Controleer of de SOCKS-listener lokaal of openbaar is

De client van Tor stelt een SOCKS-interface beschikbaar aan toepassingen op dezelfde machine, standaard op loopback. Die listener is een lokaal gemak, geen dienst die een relay aan het internet aanbiedt, en hem als openbare proxy behandelen is de manier waarop mensen uiteindelijk een open relay draaien die ze niet bedoelden:

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

Het bindadres is de aanwijzing. Een SocksPort op 127.0.0.1:9050 doet zijn werk; een die op 0.0.0.0 luistert en van buitenaf bereikbaar is, is een open proxy, en de eigen toegangsbeleidscontroles van Tor bestaan juist omdat die blootstelling een probleem is en geen functie.

Voor een toepassing die Tor nodig heeft, wijs hem naar de loopback-poort en laat Tor namen oplossen, wat de vorm socks5h hierboven doet. Vervang het adres van een relay niet door die poort; de relay biedt niet de interface die je toepassing vraagt.

Controleer of het VPN-profiel bij een echt eindpunt past

Een VPN-profiel is een bundel verwachtingen: OpenVPN heeft het servercertificaat of de CA nodig, een clientcertificaat en -sleutel, en meestal een TLS-sleutel, terwijl WireGuard de openbare sleutel van de tegenpartij, een eindpunt en toegestane IP's nodig heeft. Niets daarvan valt af te leiden uit een adres en een open poort, en daarom faalt een zo gebouwd profiel bij de eerste uitwisseling en niet bij het verbinden.

Wanneer je een profiel krijgt, verifieer het dan tegen een eindpunt dat je beheert of een aanbieder die je kunt identificeren:

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

In het OpenVPN-logboek benoemt een TLS-onderhandelingsfout de mismatch direct; in wg show heeft een tegenpartij zonder handshake-regel er nooit een voltooid. Beide zijn informatiever dan de draaiende indicator van de client, en beide wijzen op sleutelmateriaal of protocol en niet op Tor.

Controleer welke bescherming je werkelijk nodig hebt

Dit is de controle die de architectuur bepaalt. De Tor Browser geeft je circuitisolatie en verdediging tegen vingerafdrukken die een VPN niet biedt; een VPN verandert het adres dat een bestemming ziet en authenticeert je bij een aanbieder. Kiezen tussen beide is een vraag van dreigingsmodel, niet van compatibiliteit, en ze door elkaar halen levert een opzet op die privé lijkt en het niet is.

Ketening heeft een volgorde. Een VPN die Tor-verkeer draagt is een ondersteunde opstelling, omdat de client van Tor alleen uitgaand TCP nodig heeft. Een VPN-client die binnen Tor wordt getunneld is niet hetzelfde en is niet wat de Tor-client implementeert, dus plan daar niet op.

Voordat je iets importeert, bevestig alle vier:

• De poort voltooit de handshake van je protocol, niet alleen een TCP-verbinding.
• Je kent de rol van de host en behandelt doorsturen niet als toestemming.
• De SOCKS-listener die je gebruikt is loopback en van jou, geen openbare poort op de relay van een ander.
• De sleutels of certificaten van het profiel horen bij het eindpunt waarmee je verbindt.