Tor-relé mot VPN-tenar: kvifor dei ikkje kan bytast om

Du har ei adresse, porten svarar, og ein klient godtek han utan klage. Ingenting av dette gjer eit Tor-relé til eit VPN-endepunkt, og feilen er dyr fordi profilen blir importert reint og seinare feilar ved handtrykket. Eg brukar dei fire kontrollane nedanfor i rekkjefølgje; kvar har ein stoppbetingelse, og det er nettopp poenget å stoppe tidleg. Viss den første kontrollen feilar, kan resten ikkje hjelpe deg.

Sjekk kva porten faktisk tener

Ein open port provar ein lyttar, ikkje meir. ORPorten til eit relé snakkar Tor sine eigne celler etter eit TLS-handtrykk, så ein vellukka TLS-probe fortel deg nesten ingenting om ein VPN-protokoll blir godteken der:

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

Les sertifikatet i staden for det faktumet at det finst eit. Relé presenterer eit sjølvsignert sertifikat med eit medvite uansvarleg namn, fordi relétrafikk skal likne vanleg HTTPS; sertifikatet til ein VPN-tenar ber namnet profilen din ventar. Viss motparten aldri svarar på den første pakken i VPN-protokollen, vil inga mengd profilredigering endre resultatet.

Stopp her viss adressa ikkje fullfører handtrykket klienten din sender. Det er eit protokollsvar, ikkje eit konfigurasjonsproblem, og det er den vanlegaste grunnen til at ein importert profil blir ståande på 'connecting' for alltid.

Sjekk rolla til reléet, ikkje storleiken på nettet

Relérollar gjer ulikt arbeid. Ein guard er det første hoppet for klientar, eit mellomrelé sender krinsar vidare mellom andre relé, ein exit er den som rører ved mål, og ei bru er eit ikkje-offentleg inngangspunkt som blir delt ut gjennom BridgeDB. Ordlista til Tor held desse definisjonane fråskilde, og det å vere tilgjengeleg er ein del av kvar rolle, medan løyve til å tene vilkårlege klientar ikkje er ein del av noka av dei.

Exit-policyen er verd å lese fordi han er den einaste delen som liknar ei vidaresendingsregel, og han styrer måla som exiten lèt gå ut, ikkje klientane som blir sleppte inn. Ein restriktiv exit-policy som blokkerer port 25 seier noko om kontroll av utgåande misbruk, ikkje om du kan peike ein OpenVPN-klient mot maskina.

Stopp viss du resonnerer ut frå omdøme: fordi relé sender trafikk vidare, må adressa godta di. Tor vel ruter gjennom konsensus og sin eigen protokoll; ein VPN-klient er ikkje deltakar og har ingen krins å slutte seg til.

Sjekk om SOCKS-lyttaren er lokal eller offentleg

Klienten til Tor eksponerer eit SOCKS-grensesnitt for program på same maskin, som standard på loopback. Den lyttaren er ei lokal lettvintheit, ikkje ei teneste eit relé tilbyr internett, og å handsame han som ein offentleg proxy er måten folk endar opp med å køyre eit ope relé dei ikkje hadde til hensikt:

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

Bind-adressa er teiknet. Ein SocksPort på 127.0.0.1:9050 gjer jobben sin; ein som lyttar på 0.0.0.0 og er tilgjengeleg utanfrå, er ein open proxy, og Tor sine eigne tilgangspolitikk-kontrollar finst nettopp fordi den eksponeringa er eit problem og ikkje ein funksjon.

For eit program som treng Tor, peik det mot loopback-porten og lat Tor slå opp namn, noko socks5h-forma ovanfor gjer. Ikkje byt ut ei reléadresse med den porten; reléet tilbyr ikkje grensesnittet programmet ditt ber om.

Sjekk at VPN-profilen passar til eit ekte endepunkt

Ein VPN-profil er ein bunt av forventningar: OpenVPN treng sertifikatet til tenaren eller CA-en, eit klientcertifikat og ein nøkkel, og vanlegvis ein TLS-nøkkel, medan WireGuard treng den offentlege nøkkelen til motparten, eit endepunkt og tillatne IP-ar. Ingenting av dette kan leiast ut frå ei adresse og ein open port, og difor feilar ein profil bygd slik ved den første utvekslinga i staden for ved tilkoplinga.

Når du får utlevert ein profil, verifiser han mot eit endepunkt du kontrollerer eller ein leverandør du kan identifisere:

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

I OpenVPN-loggen namngir ein TLS-forhandlingsfeil uoverensstemminga direkte; i wg show har ein motpart utan handtrykkslinje aldri fullført ein. Begge er meir informative enn den snurrande indikatoren til klienten, og begge peikar på nøkkelmateriale eller protokoll framfor på Tor.

Sjekk kva vern du eigentleg treng

Dette er kontrollen som avgjer arkitekturen. Tor-nettlesaren gir deg krinsisolering og fingeravtrykkvern som ein VPN ikkje gir; ein VPN endrar adressa ein destinasjon ser, og autentiserer deg overfor ein leverandør. Å velje mellom dei er eit trusselmodellspørsmål, ikkje eit kompatibilitetsspørsmål, og å blande dei gir eit oppsett som ser privat ut og ikkje er det.

Kjeding har ei rekkjefølgje. Ein VPN som ber Tor-trafikk er ei støtta ordning, fordi Tor-klienten berre treng utgåande TCP. Ein VPN-klient som er tunnellert inne i Tor er ikkje det same og er ikkje det Tor-klienten implementerer, så ikkje planlegg etter det.

Før du importerer noko, stadfest alle fire:

• Porten fullfører handtrykket til protokollen din, ikkje berre ei TCP-tilkopling.
• Du kjenner rolla til verten og handsamar ikkje vidaresending som løyve.
• SOCKS-lyttaren du brukar er loopback og din eigen, ikkje ein offentleg port på reléet til nokon annan.
• Nøklane eller sertifikata til profilen høyrer til endepunktet du koplar til.