Tor-relay kontra VPN-server: hvorfor de ikke kan udskiftes

Du har en adresse, porten svarer, og en klient accepterer den uden klager. Intet af det gør en Tor-relay til et VPN-endepunkt, og fejlen er dyr, fordi profilen importeres rent og senere fejler ved håndtrykket. Jeg bruger de fire kontroltrin nedenfor i rækkefølge; hvert har en stopbetingelse, og det er netop pointen at stoppe tidligt. Hvis den første kontrol fejler, kan resten ikke hjælpe dig.

Kontrollér, hvad porten egentlig betjener

En åben port beviser en lytter, ikke mere. En relays ORPort taler Tor's egne celler efter et TLS-håndtryk, så en vellykket TLS-probe fortæller dig næsten intet om, hvorvidt en VPN-protokol accepteres der:

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

Læs certifikatet i stedet for det faktum, at der findes et. Relays præsenterer et selvsigneret certifikat med et bevidst uanseligt navn, fordi relaytrafik skal ligne almindelig HTTPS; et VPN-servers certifikat bærer det navn, din profil forventer. Hvis modparten aldrig svarer på VPN-protokollens første pakke, vil ingen mængde profilredigering ændre resultatet.

Stop her, hvis adressen ikke fuldfører det håndtryk, din klient sender. Det er et protokolsvar, ikke et konfigurationsproblem, og det er den enkeltstående hyppigste grund til, at en importeret profil bliver stående på 'connecting' for evigt.

Kontrollér relayens rolle, ikke nettets størrelse

Relayroller udfører forskellige opgaver. En guard er det første hop for klienter, en mellemrelay videresender kredsløb mellem andre relays, en exit er den, der rører ved destinationer, og en bro er et ikke-offentligt indgangspunkt, der uddeles gennem BridgeDB. Tor's ordliste holder disse definitioner adskilt, og det at være tilgængelig er en del af enhver rolle, mens tilladelse til at betjene vilkårlige klienter ikke er en del af nogen af dem.

Exitpolitikken er værd at læse, fordi den er den eneste del, der ligner en videresendelsesregel, og den styrer de destinationer, som exiten tillader ud, ikke de klienter, der tillades ind. En restriktiv exitpolitik, der blokerer port 25, siger noget om kontrol med udgående misbrug, ikke om du må pege en OpenVPN-klient mod maskinen.

Stop, hvis du ræsonnerer ud fra omdømme: fordi relays videresender trafik, må adressen acceptere din. Tor vælger ruter gennem konsensus og sin egen protokol; en VPN-klient er ikke deltager og har ikke et kredsløb at slutte sig til.

Kontrollér, om SOCKS-lytteren er lokal eller offentlig

Tor's klient eksponerer en SOCKS-grænseflade til programmer på samme maskine, som standard på loopback. Den lytter er en lokal bekvemmelighed, ikke en tjeneste, en relay tilbyder internettet, og at behandle den som en offentlig proxy er måden, hvorpå folk ender med at køre en åben relay, de ikke havde til hensigt:

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

Bind-adressen er tegnet. En SocksPort på 127.0.0.1:9050 gør sit arbejde; en, der lytter på 0.0.0.0 og kan nås udefra, er en åben proxy, og Tor's egne adgangspolitikkontroller findes netop, fordi den eksponering er et problem frem for en funktion.

For et program, der har brug for Tor, peg det mod loopback-porten, og lad Tor slå navne op, hvilket socks5h-formen ovenfor gør. Erstat ikke en relayadresse med den port; relayen tilbyder ikke den grænseflade, dit program beder om.

Kontrollér, at VPN-profilen passer til et rigtigt endepunkt

En VPN-profil er en bunke forventninger: OpenVPN kræver serverens certifikat eller CA, et klientcertifikat og en nøgle, og som regel en TLS-nøgle, mens WireGuard kræver modpartens offentlige nøgle, et endepunkt og tilladte IP'er. Intet af dette kan udledes af en adresse og en åben port, og derfor fejler en profil bygget sådan ved den første udveksling i stedet for ved forbindelsen.

Når du får udleveret en profil, verificér den mod et endepunkt, du kontrollerer, eller en udbyder, du kan identificere:

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

I OpenVPN-loggen angiver en TLS-forhandlingsfejl uoverensstemmelsen direkte; i wg show har en modpart uden håndtrykslinje aldrig fuldført et. Begge er mere informative end klientens snurrende indikator, og begge peger på nøglmateriale eller protokol frem for på Tor.

Kontrollér, hvilken beskyttelse du egentlig har brug for

Dette er den kontrol, der bestemmer arkitekturen. Tor Browser giver dig kredsløbsisolering og fingeradaftryksforsvar, som en VPN ikke giver; en VPN ændrer den adresse, en destination ser, og autentificerer dig over for en udbyder. At vælge mellem dem er et trusselsmodelspørgsmål, ikke et kompatibilitetsspørgsmål, og at blande dem sammen giver et opsætning, der ser privat ud og ikke er det.

Kædning har en rækkefølge. En VPN, der bærer Tor-trafik, er en understøttet ordning, fordi Tor's klient kun har brug for udgående TCP. En VPN-klient tunneleret inde i Tor er ikke det samme og er ikke det, Tor-klienten implementerer, så planlæg ikke efter det.

Før du importerer noget, skal du bekræfte alle fire:

• Porten fuldfører din protokols håndtryk, ikke blot en TCP-forbindelse.
• Du kender værtens rolle og behandler ikke videresendelse som tilladelse.
• Den SOCKS-lytter, du bruger, er loopback og din egen, ikke en offentlig port på en andens relay.
• Profilens nøgler eller certifikater tilhører det endepunkt, du opretter forbindelse til.