Tor relay kontra VPN szerver: miért nem cserélhetők fel

Van egy cím, a port válaszol, és egy kliens panasz nélkül elfogadja. Ezek egyike sem tesz egy Tor relayt VPN-végponttá, és a hiba drága, mert a profil tisztán importálódik, majd később a kézfogásnál elbukik. Az alábbi négy ellenőrzést sorrendben használom; mindegyiknek van leállási feltétele, és éppen a korai leállás a lényeg. Ha az első ellenőrzés elbukik, a többi nem tud segíteni.

Ellenőrizze, mit szolgál ki valójában a port

A nyitott port egy figyelőt bizonyít, nem többet. A relay ORPortja TLS-kézfogás után Tor saját celláival beszél, ezért egy sikeres TLS-próba szinte semmit nem mond arról, hogy ott elfogadnak-e VPN-protokollt:

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

Olvassa a tanúsítványt, ne azt a tényt, hogy van. A relayek szándékosan feltűnésmentes nevű, önaláírt tanúsítványt mutatnak, mert a relay-forgalomnak közönséges HTTPS-hez kell hasonlítania; a VPN-szerver tanúsítványa azt a nevet hordozza, amelyet a profilja vár. Ha a partner soha nem válaszol a VPN-protokoll első csomagjára, semmilyen profil szerkesztése nem változtat az eredményen.

Álljon meg itt, ha a cím nem fejezi be a kézfogást, amelyet a kliense küld. Ez protokollválasz, nem konfigurációs probléma, és ez a leggyakoribb oka annak, hogy egy importált profil örökre 'connecting' állapotban marad.

Ellenőrizze a relay szerepét, ne a hálózat méretét

A relay szerepek különböző feladatokat látnak el. A guard az első ugrás a kliensek számára, a középső relay áramköröket továbbít más relayek között, az exit az, amely megérinti a célokat, a híd pedig egy nem nyilvános belépési pont, amelyet a BridgeDB oszt ki. A Tor szójegyzéke külön tartja ezeket a meghatározásokat, és az elérhetőség minden szerep része, míg az önkényes kliensek kiszolgálásának engedélye egyikének sem része.

Az exit-szabályzatot érdemes elolvasni, mert ez az egyetlen rész, amely továbbítási szabályra emlékeztet, és azt szabályozza, hogy az exit mely célok felé enged kifelé, nem pedig azt, hogy mely klienseket enged be. A 25-ös portot blokkoló szigorú exit-szabályzat valamit mond a kimenő visszaélés elleni védelemről, nem arról, hogy irányíthat-e OpenVPN-klienst a gépre.

Álljon meg, ha hírnévből következtet: mivel a relayek továbbítják a forgalmat, a címnek el kell fogadnia az önét. A Tor konszenzus és saját protokollja révén választ útvonalakat; a VPN-kliens nem résztvevő, és nincs áramköre, amelyhez csatlakozhatna.

Ellenőrizze, hogy a SOCKS-figyelő helyi-e vagy nyilvános

A Tor kliense SOCKS-felületet tesz elérhetővé az ugyanazon a gépen futó alkalmazások számára, alapértelmezés szerint loopbacken. Ez a figyelő helyi kényelmi szolgáltatás, nem olyan szolgáltatás, amelyet egy relay nyújt az internetnek, és nyilvános proxyként kezelni éppen az az út, amelyen az emberek akaratlanul nyitott relayt futtatnak:

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

A kötési cím az árulkodó jel. A 127.0.0.1:9050 címen futó SocksPort végzi a dolgát; az, amelyik a 0.0.0.0 címen figyel és kívülről elérhető, nyitott proxy, és a Tor saját hozzáférési szabályzatának ellenőrzései éppen azért léteznek, mert ez a kitettség probléma, nem funkció.

Ha egy alkalmazásnak Torra van szüksége, irányítsa a loopback portra, és hagyja, hogy a Tor oldja fel a neveket, amit a fenti socks5h forma tesz. Ne cserélje ki a relay címére ezt a portot; a relay nem nyújtja azt a felületet, amelyet az alkalmazása kér.

Ellenőrizze, hogy a VPN-profil valódi végponthoz illik

A VPN-profil elvárások csomagja: az OpenVPN igényli a szerver tanúsítványát vagy a CA-t, egy kliens-tanúsítványt és kulcsot, és általában egy TLS-kulcsot, míg a WireGuard a partner nyilvános kulcsát, egy végpontot és engedélyezett IP-címeket igényel. Ezek egyike sem vezethető le egy címből és egy nyitott portból, ezért az így felépített profil az első cserénél bukik el, nem a csatlakozásnál.

Amikor átadnak önnek egy profilt, ellenőrizze egy ön által irányított végponttal vagy egy azonosítható szolgáltatóval szemben:

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

Az OpenVPN naplójában a TLS-tárgyalási hiba közvetlenül megnevezi az eltérést; a wg show kimenetében a kézfogási sor nélküli partner soha nem fejezett be egyet sem. Mindkettő többet mond a kliens pörgő jelzőjénél, és mindkettő kulcsanyagra vagy protokollra mutat, nem a Torra.

Ellenőrizze, milyen védelemre van valóban szüksége

Ez az ellenőrzés dönti el az architektúrát. A Tor Browser áramkör-izolációt és ujjlenyomat elleni védelmet ad, amelyet egy VPN nem; a VPN megváltoztatja a címet, amelyet egy cél lát, és azonosítja önt egy szolgáltatónál. A kettő közötti választás fenyegetésmodell kérdése, nem kompatibilitási kérdés, és összekeverésük olyan beállítást eredményez, amely privátnak látszik, és nem az.

A láncolásnak van sorrendje. A Tor-forgalmat vivő VPN támogatott elrendezés, mert a Tor kliensének csak kimenő TCP-re van szüksége. A Tor belsejébe alagutazott VPN-kliens nem ugyanaz, és nem az, amit a Tor kliens megvalósít, ezért ne tervezzen erre.

Mielőtt bármit importálna, erősítse meg mind a négyet:

• A port befejezi a protokollja kézfogását, nem csak egy TCP-kapcsolatot.
• Ismeri a gazdagép szerepét, és nem tekinti a továbbítást engedélynek.
• A használt SOCKS-figyelő loopback és az öné, nem nyilvános port valaki más relayén.
• A profil kulcsai vagy tanúsítványai ahhoz a végponthoz tartoznak, amelyhez csatlakozik.