Tor-udgangsrelay kontra VPN-udgangsserver: hvad hver af dem ved
Et Tor-udgangsrelay og en VPN-udgangsserver viser begge én offentlig adresse, men de fordeler viden forskelligt. Sammenlign synlighed, dækning og portpolitik.
Begge designs skjuler din adresse bag én offentlig IP, og et websted, der udskriver den adresse, det ser, kan ikke skelne dem. Forskellen er, hvem der lærer hvad undervejs, hvor meget trafik der er dækket, og hvilke porte der må virke. Et Tor-udgangsrelay er det sidste hop i et kredsløb med tre relæer; en VPN-udgangsserver afslutter din tunnel og etablerer selv den udgående forbindelse. Her er, hvordan jeg afgør, hvilken en opgave kræver, og hvad jeg kontrollerer, før jeg antager, at den ene opfører sig som den anden.
To veje, der ender på én adresse
Tor bygger et kredsløb gennem en vagt, et mellemrelæ og en udgang og krypterer nyttelasten i lag, så hvert relæ kun skræller sit eget lag af. Udgangen etablerer den almindelige TCP-forbindelse til destinationen, og derfor ser destinationen udgangsadressen. Din klient taler aldrig direkte med destinationen, og vagten ser den heller ikke.
En VPN er én tunnel til ét endepunkt. Operatørens server fjerner tunnelen og åbner den udgående forbindelse, så destinationen ser også én adresse, denne gang operatørens. Det observerbare resultat er det samme; viden er det ikke. En test, der udskriver en IP, svarer på, hvilket system du er på, og intet om den tillidsfordeling, der faktisk adskiller sig.
Hvem ender med at vide hvad
VPN-endepunktet ser kildeadressen, destinationen, tidspunktet og mængden på ét sted. Den koncentration er designet: én operatør, én logflade, ét sted at indkalde eller at fejlkonfigurere. Alt, hvad du vinder, kommer fra tillid til den part og fra endepunktets udgående politik.
Tor deler den viden. Vagten kender din adresse, men ikke destinationen; udgangen kender destinationen, men ikke din adresse. Et relæ bør ikke lære begge. Det er en strukturel egenskab, ikke et løfte mod en global observatør, et relæ der korrelerer tidspunkter, eller et kompromitteret endepunkt, så behandl det som en anden fordeling af samme risiko og ikke som anonymitet, der ikke kan svigte.
| 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 |
Dækning er en browserbeslutning eller en routingbeslutning
Tor Browser ruter sin egen trafik og tilføjer beskyttelser, som en almindelig VPN-klient ikke gengiver: modstand mod fingeraftryk, isolering af første part, en fast vinduesstørrelse og en handling Ny identitet, der kasserer sessionstilstanden. Andre programmer bruger ikke det kredsløb, medmindre de er konfigureret til det, og en systemdækkende Tor-opsætning er et separat projekt fra at installere browseren.
En VPN er den modsatte form. Dækningen følger routingtabellen, så en WireGuard-profil med AllowedIPs = 0.0.0.0/0 fanger alt, og en split-tunnel-liste fanger kun de præfikser, den nævner. Det er også der, lækagerne bor: DNS-forespørgsler, IPv6 og WebRTC kan hver tage en vej, som routingpolitikken ikke omfattede. Kontroller inde fra det program, der fejlede, ikke fra en browserfane, der måske bruger en anden grænseflade.
Portpolitik, blokerede destinationer og HTTPS
Et udgangsrelay må afvise udgående porte, og standardpolitikken afviser en liste over misbrugstruede porte med SMTP-port 25 blandt dem. En mailklient, der er konfigureret gennem Tor, fejler derfor ved udgangen, hvilket ligner en netværksfejl og ikke er det. Operatører, der kører et relæ, angiver det udtrykkeligt:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Destinationer blokerer også, og de blokerer de to systemer forskelligt. Tor-udgangsadresser offentliggøres, så et websted kan afvise hele listen; VPN-endepunkter ligger i datacenterområder, der afvises lige så koldt. Når en side fejler, skal du skelne de tre kandidater, før du ændrer noget: udgangs- eller udgående politik, en destination der afviser kilden, eller en captive portal, der kaprer den første anmodning.
Ingen af systemerne erstatter transportkryptering. Almindelig HTTP er læsbar ved udgangsrelayet og ved VPN-endepunktet, så hold HTTPS slået til og læs certifikatadvarslen i stedet for at afvise den. To kontroller afgør routingspørgsmålet hurtigt: curl -s https://check.torproject.org/api/ip returnerer IsTor, når anmodningen gik gennem et kredsløb, og curl -s https://ifconfig.me viser den udgående adresse, som en VPN ville fremvise. Kører du begge, ved du, hvilken vej shellen faktisk bruger.
Brug ikke den ene som den anden
Et udgangsrelays adresse er ikke en VPN-profil. At pege en OpenVPN- eller WireGuard-klient mod et relæ på port 443 skaber ingen tunnel, fordi der ikke lytter nogen VPN-tjeneste; relæet er et hop i en andens kredsløb. Den anden vej er et VPN-endepunkt ikke et indgangspunkt for Tor, og Tor Browsers broindstillinger er ikke et sted at indsætte et kommercielt VPN-værtsnavn. Hvis du kører Tor over en VPN, ser vagten VPN-adressen i stedet for din, hvilket ændrer fordelingen uden at sammenlægge de to roller.
Før du vælger, skal du besvare fire spørgsmål i rækkefølge: hvem driver endepunktet, og hvad beholder det, hvad dækker værktøjet på denne enhed, hvilke porte og destinationer tillader den udgående politik, og hvad tilføjer programmet ud over netværksvejen. En opgave, der kræver almindelig netværksadgang til mange programmer, vil have en VPN. En opgave, der kræver beskyttelserne på browserviveau og kredsløbsmodellen, vil have Tor Browser, holdt opdateret. Hvis svaret er »begge«, så kør dem i en bevidst rækkefølge, og skriv ned, hvilken adresse hver side ser.