Tor super VPN: kiu vidas vian IP, kaj kiu vidas, ke vi uzas Tor?

Vi konektas la VPN-klienton, atendas la tunelon, poste malfermas Tor Browser kaj lasas ĝin konstrui cirkviton. Ĝuste tiu ordinara sinsekvo decidas, kiu vidas kion. En tiu ordo la enira relajso de Tor salutas la adreson de via VPN-eliro, kaj via VPN-provizanto salutas publikan gvardan relajson. Faru ĝin male kaj ambaŭ observantoj ŝanĝiĝas. Ambaŭ ordoj indas esti trairitaj, ĉar agordoj de la kliento silente rompas la sinsekvon, kiun homoj kredis esti en loko, kaj la kontrolo, kiu kaptas tion, estas la sama en ambaŭ kazoj.

Komencu per la ordo, ne per la produkto

Du aranĝoj nomiĝas „VPN kun Tor“, kaj nur la unua estas ordinara. En Tor super VPN la tunelo jam staras kiam Tor ekfunkcias, do la procezo tor sendas sian gvardan konekton en la tunelon kiel ĉiu alia eliranta trafiko. En VPN super Tor unue ekfunkcias Tor, kaj la VPN-kunsido mem vojaĝas tra la cirkvito, alvenante al la provizanto el Tor-eliro.

Kio ŝanĝiĝas inter ili estas, kiu adreso staras ĉe la malproksima fino de la plej ekstera ligilo. Ĉiu observanto vidas nur la antaŭan salteton, neniam la tutan vojon: la gvardio vidas, kiu konektiĝis al ĝi, kaj la VPN-servilo vidas, kiu konektiĝis al ĝi. Tor ne portas vian lokan tuneladreson eksteren, kaj ne ekzistas kampo en la protokolo, kie ĝi povus tion fari.

En ambaŭ ordoj la celretejo ankoraŭ vidas Tor-eliron, kaj neniu ordo ŝanĝas, kion tiu retejo lernas el via ensaluto. La diferenco limiĝas al la du randoj.

Kion vidas la enira relajso de Tor

La eniro, aŭ gvardio, akceptas ordinaran TCP-konekton sur relajsa pordo kaj komencas TLS-intermanon kun la kliento. En aranĝo Tor-super-VPN la fonto de tiu konekto estas via VPN-eliro. En aranĝo Tor-unue temas pri la adreso, kiun via maŝino uzis por atingi la Tor-reton, kutime via hejma konekto.

Tio respondas la IP-duonon de la demando, sed nur se la tunelo efektive portis la konekton. La procezo Tor atingas la gvardion per sia propra ingo, kaj tiu ingo ne estas regata de la prokseaj agordoj de Tor Browser. La retumilo parolas kun la enbindigita procezo tor per SOCKS sur 9150, kaj poste tor malfermas sian propran konekton uzante la enkursigan tabelon de la kerno. Linio Socks5Proxy en torrc, aŭ klienta transporto, ŝanĝas tiun vojon. Nenio alia.

En Linux vi povas legi la respondon de la maŝino. Demandu la kernon, kiun interfacon ĝi uzus por arbitra publika adreso, poste rigardu la lokan adreson de la establita konekto:

ip route get 203.0.113.10
sudo ss -tnp | grep -i tor

Se la vojo diras dev wg0 aŭ dev tun0, kaj la loka adreso de la establita konekto estas la tuneladreso, Tor estas ene de la VPN. Se la vojo nomas vian fizikan interfacon, ĝi estas ekstere, kion ajn pretendas la propra indikilo de la kliento.

Kion povas vidi via VPN-provizanto

La provizanto finas vian VPN-kunsidon, do ĝi vidas la adresojn, al kiuj vi konektiĝas. La adresoj de gvardaj relajsoj estas publikigataj en la publika konsento kaj iliaj pordoj estas bone konataj, do kongruigo estas serĉo en listo, ne profunda paketa inspektado. Provizanto ne bezonas rompi Tor por scii, ke kunsido estas Tor.

Kion ĝi ne vidas, estas la resto de la cirkvito. La meza relajso kaj la eliro estas elektataj ene de Tor, kaj la provizanto traktas nur la ligilon al la gvardio. Paĝa enhavo restas ene de TLS, kiu finiĝas ĉe la eliro, kaj nomrezolucio por Tor-trafiko ankaŭ okazas ĉe la eliro, do ekzistas neniu DNS-demando ĉe la provizanto por korelacii kun celo.

Pontoj kun obfs4 ŝanĝas la serĉon, ne la topologion. Ponto-adreso forestas el la publika listo de relajsoj kaj la trafiko estas formata por ne aspekti kiel Tor, do operatoro, kiu nur komparas adresojn, ne markos ĝin. La kunsido ankoraŭ venas de via VPN-kliento, kaj la provizanto ankoraŭ vidas unu finpunkton, unu volumon kaj unu horaron.

Kapablo ne estas retenpolitiko

Operatoro, kiu povas observi konekton, ne promesis konservi ĝin. Protokolado estas aparta decido, skribita en politiko, limigita de jurisdikcio, kaj kontrolebla nur per pruvoj, kiujn vi jam fidas. Etikedo sen protokoloj ne ŝanĝas la retan rolon priskribitan supre.

Konta identeco kutime gravas pli ol la elira adreso. Se vi ensalutis per retpoŝta adreso, aŭ pagis per karto, la provizanto povas ligi la kunsidon al vi sen protokoli eĉ unu celon. Rotacio de eliraj IP-oj faras nenion pri tio.

Kontrolu kovradon antaŭ ol fidi iun el la du respondoj

Plej multaj, kiuj kredas, ke ili rulas Tor super VPN, rulas nur parton de ĝi. Dividita tunelado, kiu ekskludas Tor Browser, haltigilo, kiu kovras la retumilon sed ne la servon tor, starta unuo, kiu ruliĝas antaŭ ol la tunelo staras, kaj IPv6-vojo ĉirkaŭ la tunelo estas la kutimaj kvar.

Legi la ekranon de stato ĉe la kliento testas neniun el ili. La testo, kiu faras tion: lasu Tor Browser ruliĝi, mallevu la tunelon, kaj observu, ĉu la gvardia konekto postvivas sur la fizika interfaco.

La ordo, laŭ kiu mi kontrolas, haltante ĉe la unua malsukceso:

• ip route get 203.0.113.10 redonas la tunel-aparaton.
• ss -tnp | grep -i tor montras la gvardian konekton kun loka tuneladreso.
• ip -6 route havas neniun defaŭltan vojon ekster la tunelo, aŭ IPv6 estas malŝaltita en la kliento.
• Mallevi la VPN finas aŭ alidirektas la tor-konekton anstataŭ lasi ĝin sur la fizika ligilo.

Kiu ordo taŭgas por tio, kion vi defendas

Ambaŭ ordoj kaŝas ion kaj elmetas ion, do la respondo estas elekto pri la observanto, pri kiu vi zorgas.

Legu ĝin kolumne ĝis vico kongruos kun tio, kion vi provas malhelpi. Se la zorgo estas loka reto aŭ ISP, kiu registras aŭ blokas Tor, Tor super VPN traktas tion. Se la zorgo estas, ke la VPN-operatoro ekscias vian hejman adreson, VPN super Tor traktas tion, kaj pagas por ĝi elmetante Tor-uzadon al via propra reto kaj vian hejman adreson al la gvardio.

Neniu aranĝo lasas ambaŭ randojn blindaj. Aldoni observanton ne forigas alian. La noto de la Tor Project pri ruligado de VPN kun Tor diras la saman aferon el la alia flanko: la tunelo ŝanĝas, kiu estas fidata kaj kiuj malsukcesaj vojoj ekzistas, do ĝi ne estas plibonigo aldonenda sen decidi, kion vi volis kaŝi.

Unue decidi la observanton, due elektu la ordon, kaj kontrolu per ip route get kaj ss anstataŭ per la indikilo de la kliento. Se la observanto estas iu, kiu povas devigi la VPN-provizanton mem, neniu ordo-elekto riparas tion.