Tor-relajso kontraŭ VPN-servilo: kial ili ne estas interŝanĝeblaj

Malfermita pordo sur Tor-relajso ne estas VPN-fina punkto. Unue kontrolu, kion servas la pordo, la rolon de la relajso, la amplekson de la SOCKS-aŭskultanto kaj la profilon.

Vi havas adreson, la pordo respondas, kaj kliento akceptas ĝin sen plendo. Nenio el tio faras Tor-relajson VPN-fina punkto, kaj la eraro multekostas ĉar la profilo enportiĝas pure kaj malsukcesas poste ĉe la manpremo. Mi uzas la kvar kontrolojn sube laŭ ordo; ĉiu havas haltkondiĉon, kaj frue halti estas la tuta celo. Se la unua kontrolo malsukcesas, la ceteraj ne povas helpi vin.

Kontrolu, kion la pordo efektive servas

Malfermita pordo pruvas aŭskultanton, nenion pli. La ORPort de relajso parolas la proprajn ĉelojn de Tor post TLS-manpremo, do sukcesa TLS-provo diras al vi preskaŭ nenion pri tio, ĉu VPN-protokolo estas akceptata tie:

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

Legu la atestilon anstataŭ la fakton, ke ĝi ekzistas. Relajsoj prezentas memsubskribitan atestilon kun intence nerimarkinda nomo, ĉar relajsa trafiko devas simili ordinaran HTTPS; la atestilo de VPN-servilo portas la nomon, kiun via profilo atendas. Se la alia flanko neniam respondas al la unua paketo de la VPN-protokolo, nenia kvanto da redaktado de la profilo ŝanĝos la rezulton.

Haltu ĉi tie, se la adreso ne kompletigas la manpremon, kiun sendas via kliento. Tio estas protokola respondo, ne agorda problemo, kaj ĝi estas la plej ofta kialo, ke enportita profilo restas ĉe 'connecting' por ĉiam.

Kontrolu la rolon de la relajso, ne la grandecon de la reto

Relajsaj roloj faras malsamajn taskojn. Guard estas la unua salto por klientoj, meza relajso plusendas cirkvitojn inter aliaj relajsoj, exit estas tiu, kiu tuŝas celojn, kaj ponto estas ne-publika enirpunkto disdonata per BridgeDB. La glosaro de Tor tenas tiujn difinojn apartaj, kaj atingeblo estas parto de ĉiu rolo, dum permeso servi arbitrajn klientojn estas parto de neniu el ili.

La exit-politiko indas legi, ĉar ĝi estas la sola parto, kiu similas plusenda regulo, kaj ĝi regas la celojn, kiujn la exit permesos eliri, ne la klientojn permesatajn eniri. Restrikta exit-politiko, kiu blokas pordon 25, diras ion pri kontrolo de elira misuzo, ne pri tio, ĉu vi rajtas direkti OpenVPN-klienton al la maŝino.

Haltu, se vi rezonas el reputacio: ĉar relajsoj plusendas trafikon, la adreso devas akcepti vian. Tor elektas vojojn per konsento kaj propra protokolo; VPN-kliento ne estas partoprenanto kaj havas neniun cirkviton, al kiu aliĝi.

Kontrolu, ĉu la SOCKS-aŭskultanto estas loka aŭ publika

La kliento de Tor elmontras SOCKS-kradon por aplikaĵoj sur la sama maŝino, defaŭlte sur loopback. Tiu aŭskultanto estas loka komforto, ne servo, kiun relajso ofertas al la interreto, kaj trakti ĝin kiel publika prokuro estas kiel homoj finas kun malfermita relajso, kiun ili ne intencis:

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

La bind-adreso estas la indiko. SocksPort sur 127.0.0.1:9050 faras sian laboron; unu aŭskultanta sur 0.0.0.0 kaj atingebla de ekstere estas malfermita prokuro, kaj la propraj alirpolitikaj kontroloj de Tor ekzistas ĝuste ĉar tiu elmeto estas problemo, ne trajto.

Por aplikaĵo, kiu bezonas Tor, direktu ĝin al la loopback-pordo kaj lasu Tor solvi nomojn, kion faras la formo socks5h supre. Ne anstataŭigu la adreson de relajso per tiu pordo; la relajso ne ofertas la kradon, kiun via aplikaĵo petas.

Kontrolu, ke la VPN-profilo kongruas al reala fina punkto

VPN-profilo estas fasko da atendoj: OpenVPN bezonas la atestilon de la servilo aŭ la CA, klientan atestilon kaj ŝlosilon, kaj kutime TLS-ŝlosilon, dum WireGuard bezonas la publikan ŝlosilon de la alia flanko, finan punkton kaj permesatajn IP. Nenion el tio eblas derivi el adreso kaj malfermita pordo, tial profilo tiel konstruita malsukcesas ĉe la unua interŝanĝo, ne ĉe la konekto.

Kiam oni transdonas al vi profilon, kontrolu ĝin kontraŭ fina punkto, kiun vi regas, aŭ provizanto, kiun vi povas identigi:

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

En la OpenVPN-protokolo, TLS-traktada eraro rekte nomas la malkongruon; en wg show, alia flanko sen manprema linio neniam kompletigis unu. Ambaŭ estas pli informaj ol la turniĝanta indikilo de la kliento, kaj ambaŭ montras al ŝlosila materialo aŭ protokolo, ne al Tor.

Kontrolu, kiun protekton vi vere bezonas

Tiu ĉi kontrolo decidas la arkitekturon. Tor Browser donas al vi cirkvitan izolon kaj fingrospurajn defendojn, kiujn VPN ne donas; VPN ŝanĝas la adreson, kiun celo vidas, kaj aŭtentikigas vin ĉe provizanto. Elekti inter ili estas demando pri minacmodelo, ne pri kongrueco, kaj miksado de ili produktas agordon, kiu aspektas privata kaj ne estas.

Ĉenado havas ordon. VPN portanta Tor-trafikon estas subtenata aranĝo, ĉar la kliento de Tor bezonas nur eliran TCP. VPN-kliento tunelita ene de Tor ne estas la sama afero kaj ne estas tio, kion la Tor-kliento efektivigas, do ne planu sur tio.

Antaŭ ol enporti ion ajn, konfirmu ĉiujn kvar:

  • La pordo kompletigas la manpremon de via protokolo, ne nur TCP-konekton.
  • Vi konas la rolon de la gastiganto kaj ne traktas plusendadon kiel permeson.
  • La SOCKS-aŭskultanto, kiun vi uzas, estas loopback kaj via, ne publika pordo sur la relajso de aliulo.
  • La ŝlosiloj aŭ atestiloj de la profilo apartenas al la fina punkto, al kiu vi konektiĝas.

Rilataj artikoloj