Tor-utgangsrelé kontra VPN-utgangsserver: kva kvar av dei veit
Eit Tor-utgangsrelé og ein VPN-utgangsserver viser begge éi offentleg adresse, men dei deler kunnskap ulikt. Samanlikn synlegheit, dekning og portpolitikk.
Båe designa skjuler adressa di bak éin offentleg IP, og eit nettstad som skriv ut adressa det ser, kan ikkje skilje dei. Skilnaden er kven som lærer kva undervegs, kor mykje trafikk som er dekt, og kva portar som får verke. Eit Tor-utgangsrelé er siste hopp i ein krins med tre reléar; ein VPN-utgangsserver avsluttar tunnelen din og opnar den utgåande sambandet sjølv. Her er korleis eg avgjer kva ein oppgåve treng, og kva eg kontrollerer før eg reknar med at den eine oppfører seg som den andre.
To vegar som endar på éi adresse
Tor byggjer ein krins gjennom ein vakt, eit mellomrelé og ein utgang, og krypterer nyttelasta i lag slik at kvar relé berre skrel av sitt eige lag. Utgangen opprettar den vanlege TCP-sambandet til målet, og difor ser målet utgangsadressa. Klienten din snakkar aldri direkte med målet, og vakta ser det heller ikkje.
Ein VPN er éin tunnel til eitt endepunkt. Tenaren til operatøren fjernar tunnelen og opnar den utgåande sambandet, så målet ser òg éi adresse, denne gongen operatøren si. Det observerbare resultatet er det same; kunnskapen er det ikkje. Ein test som skriv ut ein IP, svarar på kva system du er på, og seier ingenting om tillitsfordelinga som faktisk skil seg.
Kven som til slutt veit kva
VPN-endepunktet ser kjeldeadressa, målet, tidspunktet og volumet på ein stad. Den konsentrasjonen er designet: éin operatør, éi loggflate, éin stad å stemne eller feilkonfigurere. Alt du vinn, kjem frå tillit til den parten og frå den utgåande politikken til endepunktet.
Tor deler den kunnskapen. Vakta kjenner adressa di, men ikkje målet; utgangen kjenner målet, men ikkje adressa di. Ein relé skal ikkje lære båe. Det er ein strukturell eigenskap, ikkje eit løfte mot ein global observatør, ein relé som korrelerer tider, eller eit kompromittert endepunkt, så handsam det som ei anna fordeling av same risiko og ikkje som anonymitet som ikkje kan svikte.
| 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 |
Dekning er ei nettlesaravgjerd eller ei ruteavgjerd
Tor-nettlesaren ruter sin eigen trafikk og legg til vern ein vanleg VPN-klient ikkje gjer etter: motstand mot fingeravtrykk, isolasjon av første part, ein fast vindus storleik og ei handling Ny identitet som kastar sesjonstilstanden. Andre program brukar ikkje den krinsen med mindre dei er sette opp for det, og eit systemdekkjande Tor-oppsett er eit eige prosjekt frå å installere nettlesaren.
Ein VPN har motsett form. Dekninga følgjer rutetabellen, så ein WireGuard-profil med AllowedIPs = 0.0.0.0/0 fangar alt, og ei split-tunnel-liste fangar berre prefiksa ho nemner. Det er nettopp i denne mekanismen lekkasjane bur: DNS-spørjingar, IPv6 og WebRTC kan kvar ta ein veg som rutepolitikken ikkje omfatta. Kontroller innanfrå programmet som feila, ikkje frå ei nettlesarfane som kanskje brukar eit anna grensesnitt.
Portpolitikk, blokkerte mål og HTTPS
Eit utgangsrelé kan nekte utgåande portar, og standardpolitikken avviser ei liste over misbruksutsette portar, med SMTP-port 25 blant dei. Ein e-postklient sett opp gjennom Tor feilar difor ved utgangen, noko som ser ut som ein nettverksfeil og ikkje er det. Operatørar som driv ein relé, set dette eksplisitt:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Mål blokkerer òg, og dei blokkerer dei to systema ulikt. Tor-utgangsadresser vert publiserte, så ein nettstad kan avvise heile lista; VPN-endepunkt ligg i datasenterområde som vert avviste like lett. Når ei side feilar, skil dei tre kandidatane før du endrar noko: utgangs- eller utgåande politikk, eit mål som avviser kjelda, eller ein captive portal som kaprar den første førespurnaden.
Ingen av systema erstattar transportkryptering. Vanleg HTTP er lesbart ved utgangsreléet og ved VPN-endepunktet, så hald HTTPS på og les sertifikatvarselet i staden for å avvise det. To kontrollar avgjer rutespørsmålet raskt: curl -s https://check.torproject.org/api/ip returnerer IsTor når førespurnaden gjekk gjennom ein krins, og curl -s https://ifconfig.me viser den utgåande adressa ein VPN ville presentere. Å køyre båe fortel deg kva veg skalet faktisk brukar.
Ikkje bruk den eine som den andre
Adressa til eit utgangsrelé er ikkje ein VPN-profil. Å peike ein OpenVPN- eller WireGuard-klient mot ein relé på port 443 lagar ingen tunnel, fordi det ikkje lyttar nokon VPN-teneste der; reléet er eit hopp i kretsen til nokon andre. Den andre vegen er eit VPN-endepunkt ikkje eit inngangspunkt for Tor, og bruinnstillingane til Tor-nettlesaren er ikkje ein stad å lime inn eit vertsnamn for ein kommersiell VPN. Viss du køyrer Tor over ein VPN, ser vakta VPN-adressa i staden for di, noko som endrar fordelinga utan å slå saman dei to rollene.
Før du vel, svar på fire spørsmål i rekkefølge: kven driv endepunktet og kva det held på, kva verktøyet dekkjer på denne eininga, kva portar og mål den utgåande politikken tillèt, og kva programmet legg til utover nettverksvegen. Ei oppgåve som treng vanleg nettverkstilgang for mange program, vil ha ein VPN. Ei oppgåve som treng vernet på nettlesarnivå og krinsmodellen, vil ha Tor-nettlesaren, halden oppdatert. Viss svaret er «båe», køyr dei i ein medviten rekkjefølgje og skriv ned kva adresse kvar side ser.