Elireja relajso de Tor kontraŭ elireja servilo de VPN: kion ĉiu scias
Elireja relajso de Tor kaj elireja servilo de VPN ambaŭ montras unu publikan adreson, sed ili dividas scion malsame. Komparu videblecon, kovradon kaj havenan politikon.
Ambaŭ dezajnoj kaŝas vian adreson malantaŭ unu publika IP, kaj retejo, kiu presas la adreson, kiun ĝi vidas, ne povas distingi ilin. La diferenco estas, kiu lernas kion survoje, kiom da trafiko estas kovrita, kaj kiuj havenoj rajtas funkcii. Elireja relajso de Tor estas la lasta salto de cirkvito el tri relajsoj; elireja servilo de VPN finas vian tunelon kaj mem faras la elirantan konekton. Jen kiel mi decidas, kiun bezonas tasko, kaj kion mi kontrolas antaŭ ol supozi, ke unu kondutas kiel la alia.
Du vojoj, kiuj finiĝas ĉe unu adreso
Tor konstruas cirkviton tra gardanto, meza relajso kaj elirejo, kaj ĉifras la ŝarĝon en tavoloj, tiel ke ĉiu relajso senŝeligas nur sian propran. La elirejo faras la ordinarajn TCP-konekton al la celo, kaj tial la celo vidas la elirejan adreson. Via kliento neniam parolas rekte kun la celo, kaj ankaŭ la gardanto ne vidas ĝin.
VPN estas unu tunelo al unu finpunkto. La servilo de la operatoro forigas la tunelon kaj malfermas la elirantan konekton, do la celo ankaŭ vidas unu adreson, ĉi-foje tiun de la operatoro. La observebla rezulto estas la sama; la scio ne. Testo, kiu presas IP, respondas, en kiu sistemo vi estas, kaj nenion pri la divido de fido, kiu efektive malsamas.
Kiu finfine scias kion
La finpunkto de VPN vidas la fontan adreson, la celon, la tempon kaj la volumenon en unu loko. Tiu koncentriĝo estas la dezajno: unu operatoro, unu logsurfaco, unu loko por subpreno aŭ por misagordo. Ĉio, kion vi gajnas, venas de fido al tiu partio kaj de la elira politiko de la finpunkto.
Tor dividas tiun scion. La gardanto scias vian adreson sed ne la celon; la elirejo scias la celon sed ne vian adreson. Relajso ne devus lerni ambaŭ. Tio estas struktura propraĵo, ne promeso kontraŭ tutmonda observanto, relajso, kiu korelacias tempojn, aŭ kompromitita finpunkto, do traktu ĝin kiel alian distribuon de la sama risko, ne kiel anonimecon, kiu ne povas malsukcesi.
| What is known | Tor exit relay | VPN exit server |
|---|---|---|
| Your public address | Seen by the guard relay, not the exit | Seen at the endpoint |
| Final destination | Seen at the exit | Seen at the endpoint |
| Coverage | Applications configured for Tor, chiefly Tor Browser | Whatever the route policy includes |
| Plain HTTP payload | Readable at the exit | Readable at the endpoint |
Kovrado estas decido de retumilo aŭ decido de itinero
Tor Browser itinigas sian propran trafikon kaj aldonas protektojn, kiujn ordinara VPN-kliento ne reproduktas: reziston al fingrospuroj, izoladon de unua partio, fiksan fenestran grandecon kaj agon Nova identeco, kiu forĵetas la seanstan staton. Aliaj aplikaĵoj ne uzas tiun cirkviton, krom se ili estas agorditaj por tio, kaj sistemvasta Tor-agordo estas aparta projekto de la instalado de la retumilo.
VPN havas la kontraŭan formon. Kovrado sekvas la itinertabelon, do WireGuard-profilo kun AllowedIPs = 0.0.0.0/0 kaptas ĉion kaj split-tunnel-listo kaptas nur la prefiksojn, kiujn ĝi nomas. Ĝuste en tiu mekanismo loĝas ankaŭ la likoj: DNS-demandoj, IPv6 kaj WebRTC povas ĉiu preni vojon, kiun la itinera politiko ne inkludis. Kontrolu de interne de la aplikaĵo, kiu malsukcesis, ne de retumila langeto, kiu eble uzas alian interfacon.
Havena politiko, blokitaj celoj kaj HTTPS
Elireja relajso rajtas rifuzi elirajn havenojn, kaj la defaŭlta politiko malakceptas liston de misuzemaj havenoj, inter ili SMTP-haveno 25. Tial retpoŝta kliento agordita tra Tor malsukcesas ĉe la elirejo, kio aspektas kiel reta paneo kaj ne estas. Operatoroj, kiuj funkciigas relajson, starigas tion eksplicite:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Ankaŭ celoj blokas, kaj ili blokas la du sistemojn malsame. Elirejaj adresoj de Tor estas publikigitaj, do retejo povas rifuzi la tutan liston; finpunktoj de VPN sidas en datencentraj gamoj, kiuj estas rifuzataj same senzorge. Kiam paĝo malsukcesas, apartigu la tri kandidatojn antaŭ ol ŝanĝi ion: elira aŭ eliranta politiko, celo rifuzanta la fonton, aŭ kaptiva portalo, kiu kaperas la unuan peton.
Neniu el la sistemoj anstataŭas transportan ĉifradon. Ordinara HTTP estas legebla ĉe la elireja relajso kaj ĉe la finpunkto de VPN egale, do tenu HTTPS ŝaltita kaj legu la atestilan averton anstataŭ forigi ĝin. Du kontroloj rapide solvas la itinera demando: curl -s https://check.torproject.org/api/ip redonas IsTor kiam la peto iris tra cirkvito, kaj curl -s https://ifconfig.me montras la eliran adreson, kiun VPN prezentus. Ruli ambaŭ diras al vi, kiun vojon la ŝelo efektive uzas.
Ne uzu unu kiel la alia
La adreso de elireja relajso ne estas VPN-profilo. Direkti klienton OpenVPN aŭ WireGuard al relajso sur haveno 443 ne kreas tunelon, ĉar neniu VPN-servo aŭskultas tie; la relajso estas salto en la cirkvito de iu alia. En la alia direkto, finpunkto de VPN ne estas enirpunkto por Tor, kaj la pontaj agordoj de Tor Browser ne estas loko por alglui gastigantnomon de komerca VPN. Se vi rulas Tor super VPN, la gardanto vidas la adreson de VPN anstataŭ vian, kio ŝanĝas la dividon sen kunfandi la du rolojn.
Antaŭ ol elekti, respondu kvar demandojn laŭvice: kiu funkciigas la finpunkton kaj kion ĝi retenas, kion la ilo kovras sur ĉi tiu aparato, kiujn havenojn kaj celojn la elira politiko permesas, kaj kion la aplikaĵo aldonas preter la reta vojo. Tasko, kiu bezonas ordinaran retan aliron por multaj programoj, volas VPN. Tasko, kiu bezonas la protektojn je retumila nivelo kaj la cirkvitan modelon, volas Tor Browser, tenatan ĝisdata. Se la respondo estas «ambaŭ», rulu ilin laŭ intenca ordo kaj notu, kiun adreson ĉiu flanko vidas.