VPN antaŭ Tor: kion la ordo fakte ŝanĝas

Unue konekti la VPN-on produktas specifan ĉenon: aparato, VPN-finpunkto, Tor-eniro, Tor-cirkvito, celo. Via loka reto vidas unu ĉifritan konekton al la VPN, kaj la Tor-enira nodo vidas la VPN-eliron kiel la tujan fonton anstataŭ la adreson de via provizanto. La VPN-operaciisto siavice vidas konektojn al la Tor-enira infrastrukturo kaj povas konkludi pri uzo de Tor el la celoj. Ĉiu observanto perdas ion kaj gajnas ion, kaj tial la ordo estas interŝanĝo, ne plibonigo.

Nenio en tiu ĉeno ŝanĝas kion la retejo lernas el via konto, kuketoj aŭ tajpitaj detaloj.

Kion la ordo ŝanĝas

La loka reto kaj la ISP perdas rektan videblecon de via Tor-trafiko, ĉar la unua salto nun estas ĉifrita tunelo al provizanto. La Tor-enira gardisto perdas vian hejman adreson kaj vidas la VPN-eliron. La VPN-provizanto gajnas la metadatumojn, kiujn antaŭe tenis via ISP: kiujn adresojn vi kontaktas, je kiuj horoj, kaj kiom da datumoj moviĝas.

Post la enira gardisto la cirkvito kondutas kiel antaŭe. Relajoj ankoraŭ apartigas la rolojn de eniro, mezo kaj eliro, kaj la VPN ne vidas la finan enhavon pli ol via ISP vidis ĝin.

Konfirmu la padon, kiu fakte estas uzata

Disigita tunelado estas la kutima kialo, ke la celita ĉeno ne estas la reala.Se Tor Browser estas ekskludita de la tunelo, aŭ dua profilo vojigas alie, la enira gardisto denove vidas la adreson de la provizanto dum la fasado ankoraŭ aspektas konektita. Kontrolu la vojon kaj la observitan eliron anstataŭ la ikonon.

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

La SOCKS-peton tra pordo 9150 respondas la propra kliento de Tor Browser, do respondo IsTor true konfirmas la cirkviton de la retumilo, ne ke ĉiu alia aplikaĵo uzas ĝin. Indas registri la eligon de la solvilo, ĉar DNS povas eliri per vojo, kiun la tunelo ne kovras. Konservu ambaŭ eligojn kun tempmarko. Ili estas la bazlinio por la sekva komparo.

Komparu kun rekta peto el ordinara terminalo: se ankaŭ tiu raportas Tor, io alia alidirektas la trafikon kaj la ĉeno ne estas tio, kion la dezajno supozis.

Rigardu, kio okazas, kiam la tunelo falas

Kliento, kiu silente reiras al la loka fasado, ŝanĝas la fonton, kiun la enira gardisto vidas, kaj la uzanto kutime ne scias tion, ĉar la paĝo ankoraŭ ŝarĝiĝas. Ĝuste tiu fiasko indas testi, ne la feliĉa vojo. Intence malkonektu la tunelon kaj observu, ĉu Tor-trafiko haltas aŭ daŭras senprotekta.

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

Fajroŝirmilaj reguloj, kiuj blokas elirantan trafikon ekster la tunelo, estas la sola fidinda rezerva kontrolo, kaj ili devas kovri kaj la SOCKS-klienton de la retumilo kaj ĉiun alian aplikaĵon, pri kiu vi zorgas. Retumila etendaĵo ne estas aparata VPN kaj ne efikas al aliaj programoj aŭ eksteraj observantoj.

Decidu, ĉu la aldona tavolo meritas sian fidon

La Tor Project konsilas ne staki VPN-on sub Tor, se vi ne povas mem taksi la agordon. Ilia menciita kialo estas la aldona dependeco: plia partio, plia konto kaj plia fiaska reĝimo. Se la celo estas malhelpi vian ISP vidi, ke vi uzas Tor, la VPN traktas ĝuste tiun observanton. Se la celo estas pli forta anonimeco kontraŭ tutmonda observanto, la VPN ne provizas ĝin.

Ankaŭ ekzistas la inversa ordo, kaj la nomoj ne estas interŝanĝeblaj:Tor super VPN kaj VPN super Tor priskribas malsamajn fido-rilatojn kaj malsaman fiaskan konduton. Legu la komparon antaŭ ol miksi ilin.

Skribu, kiun observanton vi provas movi, poste konfirmu, ke la reala pado kongruas kun la dezajno, poste konfirmu la fiaskan konduton. Se tiuj tri respondoj ne pravigas la plian konton kaj agordon, la dokumentita agordo de Tor Browser havas malpli da partoj, kiuj povas erari.