Tor-relé mot VPN-server: hvorfor de ikke kan byttes om

En åpen port på et Tor-relé er ikke et VPN-endepunkt. Sjekk først hva porten betjener, reléets rolle, omfanget til SOCKS-lytteren og profilen.

Du har en adresse, porten svarer, og en klient godtar den uten klage. Ingenting av dette gjør et Tor-relé til et VPN-endepunkt, og feilen er dyr fordi profilen importeres rent og senere feiler ved håndtrykket. Jeg bruker de fire kontrollene nedenfor i rekkefølge; hver har en stoppbetingelse, og det er nettopp poenget å stoppe tidlig. Hvis den første kontrollen feiler, kan resten ikke hjelpe deg.

Sjekk hva porten faktisk betjener

En åpen port beviser en lytter, ikke mer. ORPorten til et relé snakker Tor sine egne celler etter et TLS-håndtrykk, så en vellykket TLS-probe forteller deg nesten ingenting om hvorvidt en VPN-protokoll godtas der:

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

Les sertifikatet i stedet for det faktum at det finnes et. Reléer presenterer et selvsignert sertifikat med et bevisst uanselig navn, fordi relétrafikk skal ligne vanlig HTTPS; sertifikatet til en VPN-server bærer navnet profilen din forventer. Hvis motparten aldri svarer på den første pakken i VPN-protokollen, vil ingen mengde profilredigering endre resultatet.

Stopp her hvis adressen ikke fullfører håndtrykket klienten din sender. Det er et protokollsvar, ikke et konfigurasjonsproblem, og det er den vanligste grunnen til at en importert profil blir stående på 'connecting' for alltid.

Sjekk reléets rolle, ikke nettets størrelse

Reléroller gjør forskjellige jobber. En guard er det første hoppet for klienter, et mellomrelé videresender kretser mellom andre reléer, en exit er den som berører destinasjoner, og en bro er et ikke-offentlig inngangspunkt som deles ut gjennom BridgeDB. Ordlisten til Tor holder disse definisjonene atskilt, og det å være tilgjengelig er en del av hver rolle, mens tillatelse til å betjene vilkårlige klienter ikke er en del av noen av dem.

Exit-policyen er verdt å lese fordi den er den eneste delen som ligner en videresendingsregel, og den styrer destinasjonene som exiten tillater ut, ikke klientene som tillates inn. En restriktiv exit-policy som blokkerer port 25 sier noe om kontroll av utgående misbruk, ikke om du kan peke en OpenVPN-klient mot maskinen.

Stopp hvis du resonnerer ut fra omdømme: fordi reléer videresender trafikk, må adressen godta din. Tor velger ruter gjennom konsensus og sin egen protokoll; en VPN-klient er ikke deltaker og har ingen krets å slutte seg til.

Sjekk om SOCKS-lytteren er lokal eller offentlig

Tor-klienten eksponerer et SOCKS-grensesnitt for programmer på samme maskin, som standard på loopback. Den lytteren er en lokal bekvemmelighet, ikke en tjeneste et relé tilbyr internett, og å behandle den som en offentlig proxy er måten folk ender opp med å kjøre et åpent relé de ikke hadde til hensikt:

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 gjør jobben sin; en som lytter på 0.0.0.0 og er tilgjengelig utenfra, er en åpen proxy, og Tor sine egne tilgangspolitikk-kontroller finnes nettopp fordi den eksponeringen er et problem og ikke en funksjon.

For et program som trenger Tor, pek det mot loopback-porten og la Tor slå opp navn, noe socks5h-formen ovenfor gjør. Ikke bytt ut en reléadresse med den porten; reléet tilbyr ikke grensesnittet programmet ditt ber om.

Sjekk at VPN-profilen passer til et ekte endepunkt

En VPN-profil er en bunt forventninger: OpenVPN trenger serverens sertifikat eller CA, et klientsertifikat og en nøkkel, og vanligvis en TLS-nøkkel, mens WireGuard trenger motpartens offentlige nøkkel, et endepunkt og tillatte IP-er. Ingenting av dette kan utledes fra en adresse og en åpen port, og derfor feiler en profil bygget slik ved den første utvekslingen i stedet for ved tilkoblingen.

Når du får utlevert en profil, verifiser den mot et endepunkt du kontrollerer eller en leverandør du kan identifisere:

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

I OpenVPN-loggen navngir en TLS-forhandlingsfeil uoverensstemmelsen direkte; i wg show har en motpart uten håndtrykkslinje aldri fullført en. Begge er mer informative enn klientens snurrende indikator, og begge peker på nøkkelmateriale eller protokoll fremfor på Tor.

Sjekk hvilken beskyttelse du egentlig trenger

Dette er kontrollen som avgjør arkitekturen. Tor Browser gir deg kretsisolering og fingeravtrykkforsvar som en VPN ikke gir; en VPN endrer adressen en destinasjon ser, og autentiserer deg overfor en leverandør. Å velge mellom dem er et trusselmodellspørsmål, ikke et kompatibilitetsspørsmål, og å blande dem gir et oppsett som ser privat ut og ikke er det.

Kjeding har en rekkefølge. En VPN som bærer Tor-trafikk er en støttet ordning, fordi Tor-klienten bare trenger utgående TCP. En VPN-klient tunnelert inne i Tor er ikke det samme og er ikke det Tor-klienten implementerer, så ikke planlegg etter det.

Før du importerer noe, bekreft alle fire:

  • Porten fullfører håndtrykket til protokollen din, ikke bare en TCP-tilkobling.
  • Du kjenner vertens rolle og behandler ikke videresending som tillatelse.
  • SOCKS-lytteren du bruker er loopback og din egen, ikke en offentlig port på noen andres relé.
  • Profilens nøkler eller sertifikater tilhører endepunktet du kobler til.

Relaterte artikler