Tor-uitgangsrelay teenoor VPN-uitgangsbediener: wat elkeen weet
'n Tor-uitgangsrelay en 'n VPN-uitgangsbediener wys albei een openbare adres, maar hulle verdeel kennis anders. Vergelyk sigbaarheid, dekking en poortbeleid.
Albei ontwerpe versteek jou adres agter een openbare IP, en 'n webwerf wat die adres druk wat hy sien, kan hulle nie onderskei nie. Die verskil is wie onderweg wat leer, hoeveel verkeer gedek word en watter poorte toegelaat word om te werk. 'n Tor-uitgangsrelay is die laaste sprong van 'n kring van drie relays; 'n VPN-uitgangsbediener beëindig jou tonnel en maak self die uitgaande verbinding. Hier is hoe ek besluit watter een 'n taak nodig het, en wat om na te gaan voordat ek aanneem dat die een soos die ander werk.
Twee paaie wat by een adres eindig
Tor bou 'n kring deur 'n wag, 'n middelrelay en 'n uitgang, en versleutel die data in lae sodat elke relay net sy eie laag afskil. Die uitgang maak die gewone TCP-verbinding na die bestemming, en daarom sien die bestemming die uitgangadres. Jou kliënt praat nooit direk met die bestemming nie, en die wag sien dit ook nooit nie.
'n VPN is een tonnel na een eindpunt. Die operateur se bediener verwyder die tonnel en open die uitgaande verbinding, so die bestemming sien ook 'n enkele adres, hierdie keer dié van die operateur. Die waarneembare resultaat is dieselfde; die kennis nie. 'n Toets wat 'n IP druk, antwoord in watter stelsel jy is en niks oor die verdeling van vertroue wat werklik verskil nie.
Wie uiteindelik wat weet
Die VPN-eindpunt sien die bronadres, die bestemming, die tydsberekening en die volume op een plek. Daardie konsentrasie is die ontwerp: een operateur, een logoppervlak, een plek om te dagvaar of verkeerd te konfigureer. Alles wat jy wen, kom uit vertroue in daardie party en uit die eindpunt se uitgangsbeleid.
Tor verdeel daardie kennis. Die wag ken jou adres maar nie die bestemming nie; die uitgang ken die bestemming maar nie jou adres nie. 'n Relay is nie veronderstel om albei te leer nie. Dit is 'n strukturele eienskap, nie 'n belofte teen 'n globale waarnemer, 'n relay wat tydsberekening korreleer of 'n gekompromitteerde eindpunt nie; behandel dit dus as 'n ander verdeling van dieselfde risiko, nie as anonimiteit wat nie kan faal nie.
| 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 |
Dekking is 'n blaaierbesluit of 'n roetebesluit
Tor Browser stuur sy eie verkeer en voeg beskermings by wat 'n gewone VPN-kliënt nie reproduseer nie: weerstand teen vingerafdrukke, eerste-party-isolasie, 'n vaste venstergrootte en 'n aksie Nuwe Identiteit wat die sessietoestand weggooi. Ander toepassings gebruik nie daardie kring nie, tensy hulle daarvoor opgestel is, en 'n stelselwye Tor-opstelling is 'n aparte projek van die installering van die blaaier.
'n VPN is die teenoorgestelde vorm. Dekking volg die roetetabel, so 'n WireGuard-profiel met AllowedIPs = 0.0.0.0/0 vang alles en 'n split-tonnel-lys vang net die voorvoegsels wat dit noem. Daardie meganisme is ook waar lekkasies woon: DNS-navrae, IPv6 en WebRTC kan elk 'n pad neem wat die roetebeleid nie ingesluit het nie. Gaan na binne die toepassing wat gefaal het, nie vanaf 'n blaaier-oortjie wat dalk 'n ander koppelvlak gebruik nie.
Poortbeleid, geblokkeerde bestemmings en HTTPS
'n Uitgangsrelay is vry om uitgaande poorte te weier, en die verstekbeleid verwerp 'n lys misbruikgevoelige poorte met SMTP-poort 25 onder hulle. 'n Poskliënt wat deur Tor opgestel is, faal dus by die uitgang, wat soos 'n netwerkfout lyk en nie een is nie. Operateurs wat 'n relay bedryf, stel dit uitdruklik:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Bestemmings blokkeer ook, en hulle blokkeer die twee stelsels verskillend. Tor-uitgangadresse word gepubliseer, so 'n webwerf kan die hele lys weier; VPN-eindpunte sit in datasentrumreekse wat net so gemaklik geweier word. Wanneer 'n bladsy faal, skei die drie kandidate voordat jy enigiets verander: uitgang- of uitgangsbeleid, 'n bestemming wat die bron weier, of 'n captive portal wat die eerste versoek kaap.
Nie een van die stelsels vervang vervoerversleuteling nie. Gewone HTTP is by die uitgangsrelay en by die VPN-eindpunt ewe leesbaar, so hou HTTPS aan en lees die sertifikaatwaarskuwing in plaas daarvan om dit weg te klik. Twee kontroles beslis die roetevraag vinnig: curl -s https://check.torproject.org/api/ip gee IsTor terug wanneer die versoek deur 'n kring gegaan het, en curl -s https://ifconfig.me wys die uitgangadres wat 'n VPN sou voorlê. Om albei te hardloop, sê vir jou watter pad die shell werklik gebruik.
Moenie die een as die ander gebruik nie
'n Uitgangsrelay se adres is nie 'n VPN-profiel nie. Om 'n OpenVPN- of WireGuard-kliënt op 'n relay op poort 443 te rig, skep nie 'n tonnel nie, want daar luister geen VPN-diens nie; die relay is 'n sprong in iemand anders se kring. In die ander rigting is 'n VPN-eindpunt nie 'n ingangspunt vir Tor nie, en Tor Browser se bruginstellings is nie 'n plek om 'n kommersiële VPN-gasheernaam in te plak nie. As jy Tor oor 'n VPN hardloop, sien die wag die VPN-adres in plaas van joune, wat die verdeling verander sonder om die twee rolle saam te smelt.
Voordat jy kies, beantwoord vier vrae in volgorde: wie bedryf die eindpunt en wat behou dit, wat dek die gereedskap op hierdie toestel, watter poorte en bestemmings laat die uitgangsbeleid toe, en wat voeg die toepassing by anderkant die netwerkpad. 'n Taak wat gewone netwerktoegang vir baie programme nodig het, wil 'n VPN hê. 'n Taak wat die beskermings op blaaier vlak en die kringmodel nodig het, wil Tor Browser hê, bygehou. As die antwoord "albei" is, hardloop hulle in 'n doelbewuste volgorde en skryf neer watter adres elke kant sien.