Tor-utgangsrelé kontra VPN-utgangsserver: hva hver av dem vet
Et Tor-utgangsrelé og en VPN-utgangsserver viser begge én offentlig adresse, men de deler kunnskap ulikt. Sammenlign synlighet, dekning og portpolitikk.
Begge designene skjuler adressen din bak én offentlig IP, og et nettsted som skriver ut adressen det ser, kan ikke skille dem. Forskjellen er hvem som lærer hva underveis, hvor mye trafikk som dekkes, og hvilke porter som får virke. Et Tor-utgangsrelé er siste hopp i en krets med tre reléer; en VPN-utgangsserver avslutter tunnelen din og oppretter den utgående forbindelsen selv. Her er hvordan jeg avgjør hvilken en oppgave trenger, og hva jeg kontrollerer før jeg antar at den ene oppfører seg som den andre.
To veier som ender på én adresse
Tor bygger en krets gjennom en vakt, et mellomrelé og en utgang, og krypterer nyttelasten i lag slik at hvert relé bare skreller sitt eget lag. Utgangen oppretter 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 til ett endepunkt. Operatørens server fjerner tunnelen og åpner den utgående forbindelsen, så målet ser også én adresse, denne gangen operatørens. Det observerbare resultatet er det samme; kunnskapen er det ikke. En test som skriver ut en IP, svarer på hvilket system du er på, og sier ingenting om tillitsfordelingen som faktisk er forskjellig.
Hvem som til slutt vet hva
VPN-endepunktet ser kildeadressen, målet, tidspunktet og volumet på ett sted. Den konsentrasjonen er designet: én operatør, én loggflate, ett sted å stevne eller feilkonfigurere. Alt du vinner, kommer fra tillit til den parten og fra endepunktets utgående politikk.
Tor deler den kunnskapen. Vakten kjenner adressen din, men ikke målet; utgangen kjenner målet, men ikke adressen din. Et relé skal ikke lære begge. Det er en strukturell egenskap, ikke et løfte mot en global observatør, et relé som korrelerer tider, eller et kompromittert endepunkt, så behandle det som en annen fordeling av samme risiko 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 en nettleserbeslutning eller en rutebeslutning
Tor-nettleseren ruter sin egen trafikk og legger til beskyttelser en vanlig VPN-klient ikke gjenskaper: fingeravtrykksmotstand, isolasjon av første part, en fast vindusstørrelse og en handling Ny identitet som kaster sesjonstilstanden. Andre programmer bruker ikke den kretsen med mindre de er konfigurert for det, og et systemdekkende Tor-oppsett er et eget prosjekt fra å installere nettleseren.
En VPN har motsatt form. Dekningen følger rutetabellen, så en WireGuard-profil med AllowedIPs = 0.0.0.0/0 fanger alt, og en split-tunnel-liste fanger bare prefiksene den nevner. Det er nettopp i denne mekanismen lekkasjene bor: DNS-spørringer, IPv6 og WebRTC kan hver ta en vei som rutepolitikken ikke omfattet. Kontroller inne fra programmet som feilet, ikke fra en nettleserfane som kanskje bruker et annet grensesnitt.
Portpolitikk, blokkerte mål og HTTPS
Et utgangsrelé kan nekte utgående porter, og standardpolitikken avviser en liste over misbruksutsatte porter, med SMTP-port 25 blant dem. En e-postklient konfigurert gjennom Tor feiler derfor ved utgangen, noe som ser ut som en nettverksfeil og ikke er det. Operatører som driver et relé angir dette eksplisitt:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Mål blokkerer også, og de blokkerer de to systemene ulikt. Tor-utgangsadresser publiseres, så et nettsted kan avvise hele listen; VPN-endepunkter ligger i datasenterområder som avvises like lett. Når en side feiler, skill de tre kandidatene før du endrer noe: utgangs- eller utgående politikk, et mål som avviser kilden, eller en captive portal som kaprer den første forespørselen.
Ingen av systemene erstatter transportkryptering. Vanlig HTTP er lesbart ved utgangsreléet og ved VPN-endepunktet, så hold HTTPS på og les sertifikatvarselet i stedet for å avvise 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 en VPN ville presentere. Å kjøre begge forteller deg hvilken vei skallet faktisk bruker.
Ikke bruk den ene som den andre
Adressen til et utgangsrelé er ikke en VPN-profil. Å peke en OpenVPN- eller WireGuard-klient mot et relé på port 443 lager ingen tunnel, fordi det ikke lytter noen VPN-tjeneste der; reléet er et hopp i noen andres krets. Den andre veien er et VPN-endepunkt ikke et inngangspunkt for Tor, og Tor-nettleserens broinnstillinger er ikke et sted å lime inn et vertsnavn for en kommersiell VPN. Hvis du kjører Tor over en VPN, ser vakten VPN-adressen i stedet for din, noe som endrer fordelingen uten å slå sammen de to rollene.
Før du velger, svar på fire spørsmål i rekkefølge: hvem drifter endepunktet og hva det beholder, hva verktøyet dekker på denne enheten, hvilke porter og mål den utgående politikken tillater, og hva programmet legger til utover nettverksveien. En oppgave som trenger vanlig nettverkstilgang for mange programmer, vil ha en VPN. En oppgave som trenger beskyttelsene på nettlesernivå og kretsmodellen, vil ha Tor-nettleseren, holdt oppdatert. Hvis svaret er «begge», kjør dem i en bevisst rekkefølge og skriv ned hvilken adresse hver side ser.