Tor-relay teenoor VPN-bediener: waarom hulle nie uitruilbaar is nie

’n Oop poort op ’n Tor-relay is nie ’n VPN-eindpunt nie. Kyk eers wat die poort bedien, wat die rol van die relay is, hoe wyd die SOCKS-luisteraar strek en wat die profiel sê.

Jy het 'n adres, die poort antwoord, en 'n kliënt aanvaar dit sonder enige klagte. Niks daarvan maak 'n Tor-relay 'n VPN-eindpunt nie, en die fout is duur omdat die profiel skoon invoer en eers later by die handshake misluk. Ek gebruik die vier kontroles hier onder in volgorde; elkeen het 'n stoptoestand, en vroeg stop is juis die punt. As die eerste kontrole misluk, kan die res jou nie help nie.

Kyk wat die poort werklik bedien

'n Oop poort bewys 'n luisteraar, niks meer nie. 'n Relay se ORPort praat Tor se eie selle ná 'n TLS-handshake, so 'n TLS-toets wat slaag sê byna niks oor of 'n VPN-protokol daar aanvaar word nie:

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

Lees die sertifikaat eerder as die feit dat daar een is. Relays bied 'n selfondertekende sertifikaat aan met 'n doelbewus onopvallende naam, want relay-verkeer moet soos gewone HTTPS lyk; 'n VPN-bediener se sertifikaat dra die naam wat jou profiel verwag. As die eweknie nooit die VPN-protokol se eerste pakkie beantwoord nie, sal geen mate van profielredigering die uitkoms verander nie.

Stop hier as die adres nie die handshake voltooi wat jou kliënt stuur nie. Dit is 'n protokolantwoord, nie 'n konfigurasieprobleem nie, en dit is die enkele mees algemene rede waarom 'n ingevoerde profiel vir ewig by 'connecting' bly hang.

Kyk na die rol van die relay, nie die grootte van die netwerk nie

Relay-rolle doen verskillende take. 'n Guard is die eerste hop vir kliënte, 'n middel-relay stuur stroombane tussen ander relays aan, 'n exit is die een wat bestemmings aanraak, en 'n brug is 'n nie-openbare toegangspunt wat deur BridgeDB uitgedeel word. Tor se woordelys hou daardie definisies apart, en bereikbaarheid is deel van elke rol terwyl toestemming om willekeurige kliënte te bedien deel van geen een daarvan is nie.

Die exit-beleid is die moeite werd om te lees, want dit is die enigste deel wat aan 'n aanstuurreël herinner, en dit bepaal na watter bestemmings die exit mag uitstuur, nie watter kliënte ingelaat word nie. 'n Beperkende exit-beleid wat poort 25 blokkeer, sê iets oor beheer van uitgaande misbruik, nie oor of jy 'n OpenVPN-kliënt na die masjien mag wys nie.

Stop as jy van reputasie af redeneer: omdat relays verkeer aanstuur, moet die adres joune aanvaar. Tor kies paaie deur konsensus en sy eie protokol; 'n VPN-kliënt is nie 'n deelnemer nie en het geen stroombaan om by aan te sluit nie.

Kyk of die SOCKS-luisteraar plaaslik of openbaar is

Tor se kliënt stel 'n SOCKS-koppelvlak beskikbaar vir toepassings op dieselfde masjien, by verstek op loopback. Daardie luisteraar is 'n plaaslike gerief, nie 'n diens wat 'n relay aan die internet bied nie, en om dit as 'n openbare proxy te behandel, is hoe mense uiteindelik 'n oop relay bedryf wat hulle nie bedoel het nie:

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

Die bind-adres is die aanduiding. 'n SocksPort op 127.0.0.1:9050 doen sy werk; een wat op 0.0.0.0 luister en van buite bereikbaar is, is 'n oop proxy, en Tor se eie toegangsbeleidkontroles bestaan juis omdat daardie blootstelling 'n probleem is eerder as 'n kenmerk.

Vir 'n toepassing wat Tor nodig het, wys dit na die loopback-poort en laat Tor name oplos, wat die socks5h-vorm hier bo doen. Moenie 'n relay-adres vir daardie poort inruil nie; die relay bied nie die koppelvlak wat jou toepassing vra nie.

Kyk dat die VPN-profiel by 'n werklike eindpunt pas

'n VPN-profiel is 'n bondel verwagtinge: OpenVPN het die bediener-sertifikaat of CA nodig, 'n kliënt-sertifikaat en -sleutel, en gewoonlik 'n TLS-sleutel, terwyl WireGuard die peer se openbare sleutel, 'n eindpunt en toegelate IP's nodig het. Nie een daarvan kan van 'n adres en 'n oop poort afgelei word nie, en daarom misluk 'n profiel wat so gebou is by die eerste uitruiling eerder as by die verbinding.

Wanneer jy 'n profiel ontvang, verifieer dit teen 'n eindpunt wat jy beheer of 'n verskaffer wat jy kan identifiseer:

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

In die OpenVPN-log noem 'n TLS-onderhandelingsfout die wanverhouding direk; in wg show het 'n peer sonder 'n handshake-lyn nog nooit een voltooi nie. Albei is meer insiggewend as die kliënt se draaiende wyser, en albei wys na sleutelmateriaal of protokol eerder as na Tor.

Kyk watter beskerming jy werklik nodig het

Dit is die kontrole wat die argitektuur bepaal. Tor Browser gee jou stroombaan-isolasie en vingerafdrukverdediging wat 'n VPN nie het nie; 'n VPN verander die adres wat 'n bestemming sien en authentiseer jou by 'n verskaffer. Om tussen hulle te kies is 'n bedreigingsmodel-vraag, nie 'n versoenbaarheidsvraag nie, en om hulle te verwar lewer 'n opset wat privaat lyk en dit nie is nie.

Ketting het 'n orde. 'n VPN wat Tor-verkeer dra, is 'n ondersteunde reëling, want Tor se kliënt het net uitgaande TCP nodig. 'n VPN-kliënt wat binne Tor tonnel is nie dieselfde ding nie en is nie wat die Tor-kliënt implementeer nie, so moenie daarom beplan nie.

Voordat jy iets invoer, bevestig al vier:

  • Die poort voltooi jou protokol se handshake, nie net 'n TCP-verbinding nie.
  • Jy ken die rol van die gasheer en behandel nie aanstuur as toestemming nie.
  • Die SOCKS-luisteraar wat jy gebruik is loopback en joune, nie 'n openbare poort op iemand anders se relay nie.
  • Die profiel se sleutels of sertifikate behoort aan die eindpunt waaraan jy verbind.

Verwante artikels