Tor-relä kontra VPN-server: varför de inte är utbytbara

En öppen port på ett Tor-relä är inte en VPN-slutpunkt. Kontrollera först vad porten betjänar, reläets roll, omfattningen för SOCKS-lyssnaren och profilen.

Du har en adress, porten svarar och en klient accepterar den utan klagomål. Inget av detta gör ett Tor-relä till en VPN-slutpunkt, och misstaget är dyrt eftersom profilen importeras rent och misslyckas senare vid handskakningen. Jag använder de fyra kontrollerna nedan i ordning; var och en har ett stoppvillkor, och det är just poängen att stanna tidigt. Om den första kontrollen misslyckas kan de andra inte hjälpa dig.

Kontrollera vad porten faktiskt betjänar

En öppen port bevisar en lyssnare, inget mer. Ett reläs ORPort talar Tor:s egna celler efter en TLS-handskakning, så en lyckad TLS-kontroll säger nästan ingenting om huruvida ett VPN-protokoll accepteras där:

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

Läs certifikatet i stället för det faktum att det finns ett. Relän presenterar ett självsignerat certifikat med ett medvetet oansenligt namn, eftersom relätrafik ska likna vanlig HTTPS; en VPN-servers certifikat bär det namn som din profil förväntar sig. Om motparten aldrig svarar på det första paketet i VPN-protokollet kommer ingen mängd profilredigering att ändra resultatet.

Stanna här om adressen inte slutför den handskakning som din klient skickar. Det är ett protokollsvar, inte ett konfigurationsproblem, och det är den vanligaste orsaken till att en importerad profil blir kvar på 'connecting' för alltid.

Kontrollera reläets roll, inte nätets storlek

Reläroller gör olika jobb. En guard är första hoppet för klienter, ett mellanrelä vidarebefordrar kretsar mellan andra relän, en exit är den som rör vid destinationer, och en bro är en icke-offentlig ingångspunkt som delas ut via BridgeDB. Tor:s ordlista håller dessa definitioner åtskilda, och det att vara nåbar är en del av varje roll, medan tillstånd att betjäna godtyckliga klienter inte är en del av någon av dem.

Exit-policyn är värd att läsa eftersom den är den enda delen som liknar en vidarebefordringsregel, och den styr de destinationer som exiten tillåter ut, inte de klienter som tillåts in. En restriktiv exit-policy som blockerar port 25 säger något om kontrollen av utgående missbruk, inte om huruvida du får peka en OpenVPN-klient mot maskinen.

Stanna om du resonerar utifrån rykte: eftersom relän vidarebefordrar trafik måste adressen acceptera din. Tor väljer vägar genom konsensus och sitt eget protokoll; en VPN-klient är inte deltagare och har ingen krets att ansluta till.

Kontrollera om SOCKS-lyssnaren är lokal eller offentlig

Tors klient exponerar ett SOCKS-gränssnitt för program på samma maskin, som standard på loopback. Den lyssnaren är en lokal bekvämlighet, inte en tjänst som ett relä erbjuder internet, och att behandla den som en offentlig proxy är hur folk till slut kör ett öppet relä som de inte avsåg:

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

Bind-adressen är ledtråden. En SocksPort på 127.0.0.1:9050 gör sitt jobb; en som lyssnar på 0.0.0.0 och är nåbar utifrån är en öppen proxy, och Tors egna åtkomstpolicykontroller finns just för att den exponeringen är ett problem och inte en funktion.

För ett program som behöver Tor, peka det mot loopback-porten och låt Tor slå upp namn, vilket formen socks5h ovan gör. Byt inte ut reläadressen mot den porten; reläet erbjuder inte det gränssnitt som ditt program ber om.

Kontrollera att VPN-profilen passar en riktig slutpunkt

En VPN-profil är ett knippe förväntningar: OpenVPN behöver serverns certifikat eller CA, ett klientcertifikat och en nyckel, och vanligtvis en TLS-nyckel, medan WireGuard behöver motpartens publika nyckel, en slutpunkt och tillåtna IP-adresser. Inget av detta kan härledas från en adress och en öppen port, vilket är varför en profil byggd så misslyckas vid det första utbytet och inte vid anslutningen.

När du får en profil överlämnad, verifiera den mot en slutpunkt du kontrollerar eller en leverantör du kan identifiera:

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

I OpenVPN-loggen namnger ett TLS-förhandlingsfel avvikelsen direkt; i wg show har en motpart utan handskakningsrad aldrig slutfört en. Båda är mer informativa än klientens snurrande indikator, och båda pekar på nyckelmaterial eller protokoll snarare än på Tor.

Kontrollera vilket skydd du egentligen behöver

Detta är kontrollen som avgör arkitekturen. Tor Browser ger dig kretsisolering och fingeravtrycksförsvar som en VPN inte ger; en VPN ändrar adressen som en destination ser och autentiserar dig hos en leverantör. Att välja mellan dem är en fråga om hotmodell, inte om kompatibilitet, och att blanda dem ger en uppsättning som ser privat ut och inte är det.

Kedjning har en ordning. En VPN som bär Tor-trafik är en stödd ordning, eftersom Tors klient bara behöver utgående TCP. En VPN-klient som tunnlas inne i Tor är inte samma sak och är inte det som Tor-klienten implementerar, så planera inte utifrån det.

Innan du importerar något, bekräfta alla fyra:

  • Porten slutför din protokolls handskakning, inte bara en TCP-anslutning.
  • Du känner värdens roll och behandlar inte vidarebefordran som tillstånd.
  • SOCKS-lyssnaren du använder är loopback och din egen, inte en offentlig port på någon annans relä.
  • Profilens nycklar eller certifikat tillhör slutpunkten du ansluter till.

Relaterade artiklar