Tor-utgångsrelä kontra VPN-utgångsserver: vad var och en vet
Ett Tor-utgångsrelä och en VPN-utgångsserver visar båda en offentlig adress, men de delar kunskapen olika. Jämför synlighet, täckning och portpolicy.
Båda designerna döljer din adress bakom en enda offentlig IP, och en webbplats som skriver ut den adress den ser kan inte skilja dem åt. Skillnaden är vem som lär sig vad på vägen, hur mycket trafik som täcks och vilka portar som får fungera. Ett Tor-utgångsrelä är sista hoppet i en krets med tre reläer; en VPN-utgångsserver avslutar din tunnel och öppnar själv den utgående anslutningen. Här är hur jag avgör vilken en uppgift behöver, och vad jag kontrollerar innan jag antar att den ena beter sig som den andra.
Två vägar som slutar på en adress
Tor bygger en krets genom en vakt, ett mellanrelä och en utgång, och krypterar nyttolasten i lager så att varje relä bara skalar av sitt eget lager. Utgången upprättar den vanliga TCP-anslutningen till målet, och därför ser målet utgångsadressen. Din klient talar aldrig direkt med målet, och vakten ser det inte heller.
En VPN är en tunnel till en enda slutpunkt. Operatörens server tar bort tunneln och öppnar den utgående anslutningen, så målet ser också en enda adress, den här gången operatörens. Det observerbara resultatet är detsamma; kunskapen inte. Ett test som skriver ut en IP svarar på vilket system du är på och säger ingenting om den förtroendefördelning som faktiskt skiljer sig.
Vem som till slut vet vad
VPN-slutpunkten ser källadressen, målet, tidpunkten och volymen på ett ställe. Den koncentrationen är designen: en operatör, en loggyta, en plats att stämma eller felkonfigurera. Allt du vinner kommer från förtroende för den parten och från slutpunktens utgående policy.
Tor delar den kunskapen. Vakten känner din adress men inte målet; utgången känner målet men inte din adress. Ett relä ska inte lära sig båda. Det är en strukturell egenskap, inte ett löfte mot en global observatör, ett relä som korrelerar tider eller en komprometterad slutpunkt, så behandla det som en annan fördelning av samma risk och inte som anonymitet som inte kan misslyckas.
| 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 |
Täckningen är ett webbläsarbeslut eller ett rutbeslut
Tor-webbläsaren dirigerar sin egen trafik och lägger till skydd som en vanlig VPN-klient inte återskapar: motstånd mot fingeravtryck, isolering av första parten, en fast fönsterstorlek och en åtgärd Ny identitet som kastar sessionens tillstånd. Andra program använder inte den kretsen om de inte är konfigurerade för det, och en systemomfattande Tor-inställning är ett eget projekt från att installera webbläsaren.
En VPN har motsatt form. Täckningen följer routningstabellen, så en WireGuard-profil med AllowedIPs = 0.0.0.0/0 fångar allt och en split-tunnel-lista fångar bara de prefix den namnger. Det är just i den mekanismen läckorna bor: DNS-frågor, IPv6 och WebRTC kan var och en ta en väg som routningspolicyn inte omfattade. Kontrollera inifrån programmet som misslyckades, inte från en webbläsarflik som kanske använder ett annat gränssnitt.
Portpolicy, blockerade mål och HTTPS
Ett utgångsrelä får neka utgående portar, och standardpolicyn avvisar en lista över portar som är benägna att missbrukas, bland dem SMTP-port 25. En e-postklient som konfigurerats via Tor misslyckas därför vid utgången, vilket ser ut som ett nätverksfel och inte är det. Operatörer som driver ett relä anger detta uttryckligen:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Mål blockerar också, och de blockerar de två systemen olika. Tor-utgångsadresser publiceras, så en webbplats kan avvisa hela listan; VPN-slutpunkter ligger i datacenterintervall som avvisas lika lättvindigt. När en sida misslyckas, skilj de tre kandidaterna innan du ändrar något: utgångs- eller utgående policy, ett mål som avvisar källan eller en captive portal som kapar den första begäran.
Inget av systemen ersätter transportkryptering. Vanlig HTTP är läsbar både vid utgångsreläet och vid VPN-slutpunkten, så håll HTTPS på och läs certifikatvarningen i stället för att avfärda den. Två kontroller avgör rutfrågan snabbt: curl -s https://check.torproject.org/api/ip returnerar IsTor när begäran gick genom en krets, och curl -s https://ifconfig.me visar den utgående adress som en VPN skulle presentera. Att köra båda säger vilken väg skalet faktiskt använder.
Använd inte den ena som den andra
Adressen till ett utgångsrelä är inte en VPN-profil. Att rikta en OpenVPN- eller WireGuard-klient mot ett relä på port 443 skapar ingen tunnel, eftersom ingen VPN-tjänst lyssnar där; reläet är ett hopp i någon annans krets. Åt andra hållet är en VPN-slutpunkt inte en ingångspunkt för Tor, och broinställningarna i Tor-webbläsaren är inte en plats att klistra in ett värdnamn för en kommersiell VPN. Om du kör Tor över en VPN ser vakten VPN-adressen i stället för din, vilket ändrar fördelningen utan att slå ihop de två rollerna.
Innan du väljer, svara på fyra frågor i ordning: vem driver slutpunkten och vad den behåller, vad verktyget täcker på den här enheten, vilka portar och mål den utgående policyn tillåter, och vad programmet lägger till utöver nätverksvägen. En uppgift som behöver vanlig nätverksåtkomst för många program vill ha en VPN. En uppgift som behöver skydden på webbläsarnivå och kretsmodellen vill ha Tor-webbläsaren, hållen uppdaterad. Om svaret är »båda«, kör dem i en medveten ordning och skriv ned vilken adress varje sida ser.