Tor-utgangsrelé mot VPN-utgangsserver: hva vet hver av dem
Både et Tor-utgangsrelé og en VPN-utgangsserver viser én offentlig adresse, men de fordeler kunnskapen forskjellig. Sammenlign synlighet, dekning og portpolitikk.
Begge løsningene skjuler adressen din bak én offentlig IP, og et nettsted som skriver ut adressen det ser, klarer ikke å skille dem. Forskjellen ligger i hvem som får vite hva underveis, hvor stor del av trafikken som dekkes, og hvilke porter som tillates å virke. Et Tor-utgangsrelé er det siste hoppet i en krets med tre reléer; en VPN-utgangsserver avslutter tunnelen din og lager den utgående forbindelsen selv. Nedenfor forklarer jeg hvordan jeg velger hvilken en oppgave trenger, og hva jeg undersøker før jeg tror at den ene oppfører seg som den andre.
To veier som munner ut i én adresse
Tor setter sammen en krets gjennom en vakt, et mellomrelé og en utgang, og krypterer lasten lagvis slik at hvert relé bare fjerner sitt eget lag. Utgangen lager den vanlige TCP-forbindelsen til målet, og derfor ser målet utgangsadressen. Klienten din snakker aldri direkte med målet, og vakten ser det heller ikke.
En VPN er én tunnel mot ett endepunkt. Serveren til operatøren fjerner tunnelen og åpner den utgående forbindelsen, slik at målet også ser én adresse, denne gangen operatørens. Det vi kan observere, er det samme; kunnskapen er ikke. En test som skriver ut en IP, forteller hvilket system du er på, og ingenting om tillitsfordelingen som faktisk er ulik.
Hvem som til syvende og sist vet hva
VPN-endepunktet ser kildeadressen, målet, tidspunktet og volumet på ett sted. Denne konsentrasjonen er selve designet: én operatør, én loggflate, ett sted å rette en stevning eller gjøre en feilkonfigurasjon. Alt du oppnår, kommer fra tilliten til den parten og fra endepunktets utgående policy.
Tor deler denne kunnskapen. Vakten kjenner adressen din, men ikke målet; utgangen kjenner målet, men ikke adressen din. Et relé skal ikke lære begge. Dette er en strukturell egenskap, ikke et løfte mot en global observatør, et relé som korrelerer tidspunkter, eller et endepunkt som er kompromittert, så behandle det som en annen fordeling av den samme risikoen og ikke som anonymitet som ikke 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 et valg i nettleseren eller i rutingen
Tor-nettleseren ruter sin egen trafikk og legger på beskyttelser som en vanlig VPN-klient ikke gjenskaper: motstand mot fingeravtrykk, isolering av første part, en fast vindusbredde og en handling Ny identitet som forkaster sesjonstilstanden. Andre programmer bruker ikke den kretsen uten at de er satt opp for det, og et Tor-oppsett for hele systemet er et eget prosjekt fra å installere nettleseren.
En VPN er formet motsatt. Dekningen følger rutetabellen, så en WireGuard-profil med AllowedIPs = 0.0.0.0/0 fanger opp alt, mens en liste for delt tunnel bare fanger opp prefiksene den navngir. Det er i denne mekanismen lekkasjene også holder til: DNS-spørringer, IPv6 og WebRTC kan hver ta en vei som rutepolicyen ikke dekket. Undersøk fra innsiden av programmet som feilet, ikke fra en nettleserfane som kanskje bruker et annet grensesnitt.
Portpolitikk, blokkerte mål og HTTPS
Et utgangsrelé står fritt til å avvise utgående porter, og standardpolicyen avviser en liste over porter som er utsatt for misbruk, blant dem SMTP-port 25. En e-postklient som er satt opp via Tor, feiler derfor ved utgangen, noe som ser ut som en nettverksfeil og ikke er det. Operatører som driver et relé, angir dette uttrykkelig:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Mål blokkerer også, og de blokkerer de to systemene på ulike måter. Tor-utgangsadresser er publiserte, så et nettsted kan avvise hele listen; VPN-endepunkter befinner seg i datasenterområder som avvises like lett. Når en side feiler, skiller du de tre kandidatene før du endrer noe: utgangs- eller utgående policy, et mål som avviser kilden, eller en captive portal som kaprer den første forespørselen.
Ingen av løsningene erstatter transportkryptering. Vanlig HTTP er lesbart både ved utgangsreléet og ved VPN-endepunktet, så la HTTPS stå på og les sertifikatvarselet i stedet for å avfeie det. To kontroller avgjør rutespørsmålet raskt: curl -s https://check.torproject.org/api/ip returnerer IsTor når forespørselen gikk gjennom en krets, og curl -s https://ifconfig.me viser den utgående adressen som en VPN ville presentere. Kjører du begge, vet du hvilken vei skallet faktisk bruker.
Ikke bruk den ene som den andre
Adressen til et utgangsrelé er ikke en VPN-profil. Å rette en OpenVPN- eller WireGuard-klient mot et relé på port 443 lager ingen tunnel, fordi ingen VPN-tjeneste lytter der; reléet er et hopp i noen andres krets. Motsatt vei er et VPN-endepunkt ikke et inngangspunkt for Tor, og broinnstillingene i Tor-nettleseren er ikke stedet for å lime inn et vertsnavn til en kommersiell VPN. Kjører du Tor over en VPN, ser vakten VPN-adressen i stedet for din, noe som endrer fordelingen uten å slå de to rollene sammen.
Før du velger, svar på fire spørsmål i rekkefølge: hvem driver endepunktet og hva det beholder, hva verktøyet dekker på denne enheten, hvilke porter og mål den utgående policyen tillater, og hva programmet tilfører utover nettverksveien. En oppgave som trenger vanlig nettverkstilgang for mange programmer, ønsker seg en VPN. En oppgave som trenger beskyttelsen på nettlesernivå og kretsmodellen, ønsker seg Tor-nettleseren, holdt oppdatert. Er svaret «begge», kjør dem i en bevisst rekkefølge og skriv ned hvilken adresse hver side ser.