Tor oor VPN: wie sien jou IP, en wie sien dat jy Tor gebruik?

Jy verbind die VPN-kliënt, wag vir die tonnel en maak dan Tor Browser oop sodat dit ʼn stroombaan kan bou. Daardie alledaagse volgorde bepaal wie wat sien. In daardie volgorde groet die Tor-toegangsaflos jou VPN-uitgangadres, en jou VPN-verskaffer groet ʼn openbare bewaker-aflos. Doen dit omgekeerd en albei waarnemers verander. Albei volgordes is die moeite werd om deur te werk, want kliëntinstellings breek stilweg die volgorde wat mense geglo het in plek was, en die toets wat dit vang, is in albei gevalle dieselfde.

Begin met die volgorde, nie die produk nie

Twee rangskikkings word “VPN met Tor” genoem, en net die eerste is algemeen. By Tor oor VPN is die tonnel al op wanneer Tor begin, so die tor-proses stuur sy bewakerverbinding die tonnel in soos enige ander uitgaande verkeer. By VPN oor Tor kom Tor eerste op, en die VPN-sessie self reis deur die stroombaan en bereik die verskaffer vanaf ʼn Tor-uitgang.

Wat tussen hulle verander, is watter adres aan die verste punt van die buitenste skakel sit. Elke waarnemer sien net die vorige hop, nooit die hele pad nie: die bewaker sien wie aan hom gekoppel het, en die VPN-bediener sien wie aan hom gekoppel het. Tor dra nie jou plaaslike tonneladres na buite nie, en daar is geen veld in die protokol waar dit sou kon nie.

In albei volgordes sien die bestemmingwebwerf steeds ʼn Tor-uitgang, en geen van die volgordes verander wat daardie werf uit jou aanmelding leer nie. Die verskil bly beperk tot die twee rande.

Wat die Tor-toegangsaflos sien

Die ingang, of bewaker, aanvaar ʼn gewone TCP-verbinding op ʼn aflospoort en begin ʼn TLS-handdruk met die kliënt. In ʼn Tor-oor-VPN-opset is die bron van daardie verbinding jou VPN-uitgang. In ʼn Tor-eerste-opset is dit watter adres jou masjien ook al gebruik het om die Tor-netwerk te bereik, gewoonlik jou tuisverbinding.

Dit beantwoord die IP-helfte van die vraag, maar net as die tonnel die verbinding werklik gedra het. Die Tor-proses bereik die bewaker met sy eie sokkie, en daardie sokkie word nie deur Tor Browser se instaanbediener-instellings beheer nie. Die blaaier praat met die ingeboude tor-proses oor SOCKS op 9150, en tor open dan sy eie verbinding met behulp van die kern se roetetabel. ʼn Socks5Proxy-reël in torrc, of ʼn kliëntvervoer, verander daardie pad. Niks anders nie.

Op Linux kan jy die antwoord uit die masjien lees. Vra die kern watter koppelvlak dit vir ʼn willekeurige openbare adres sou gebruik, en kyk dan na die plaaslike adres van die gevestigde verbinding:

ip route get 203.0.113.10
sudo ss -tnp | grep -i tor

As die roete dev wg0 of dev tun0 sê, en die plaaslike adres op die gevestigde verbinding is die tonneladres, is Tor binne die VPN. As die roete jou fisiese koppelvlak noem, is dit buite, wat die kliënt se eie aanwyser ook al beweer.

Wat jou VPN-verskaffer kan sien

Die verskaffer beëindig jou VPN-sessie, so dit sien die adresse waarna jy verbind. Bewaker-aflosadresse word in die openbare konsensus gepubliseer en hul poorte is algemeen bekend, so om een te pas is ʼn lysopsoek eerder as diep pakketinspeksie. ʼn Verskaffer hoef nie Tor te breek om te weet dat ʼn sessie Tor is nie.

Wat dit nie sien nie, is die res van die stroombaan. Die middel-aflos en die uitgang word binne Tor gekies, en die verskaffer hanteer net die skakel na die bewaker. Bladsyinhoud bly binne TLS wat by die uitgang eindig, en naamoplossing vir Tor-verkeer gebeur ook by die uitgang, so daar is geen DNS-navraag by die verskaffer om met ʼn bestemming te korreleer nie.

Bruggies met obfs4 verander die opsoek, nie die topologie nie. ʼn Brugadres is afwesig uit die openbare afloslys en die verkeer word gevorm om nie soos Tor te lyk nie, so ʼn operateur wat net adresse vergelyk, sal dit nie merk nie. Die sessie kom steeds van jou VPN-kliënt, en die verskaffer sien steeds een eindpunt, een volume en een tydskaal.

Vermoë is nie ʼn bewaarbeleid nie

ʼn Operateur wat ʼn verbinding kan waarneem, het nie belowe om dit te hou nie. Teken hoort ʼn afsonderlike besluit te wees, neergeskryf in ʼn beleid, beperk deur jurisdiksie en net kontrolleerbaar deur bewyse wat jy reeds vertrou. ʼn Etiket soos “geen logs” verander nie die netwerkrol hierbo nie.

Rekeningidentiteit maak gewoonlik meer saak as die uitgangadres. As jy met ʼn e-posadres aangemeld het, of met ʼn kaart betaal het, kan die verskaffer die sessie aan jou verbind sonder om ʼn enkele bestemming te teken. Om uitgang-IP's te roteer, doen niks daaraan nie.

Kontroleer dekking voordat jy enige antwoord vertrou

Die meeste mense wat glo hulle hardloop Tor oor VPN, hardloop net ʼn deel daarvan. Gesplete tonnelering wat Tor Browser uitsluit, ʼn doodskakelaar wat die blaaier dek maar nie die tor-diens nie, ʼn opstarteenheid wat voor die tonnel op is, en ʼn IPv6-pad om die tonnel is die gewone vier.

Om die kliënt se statusskerm te lees, toets nie een van hulle nie. Die toets wat dit doen: laat Tor Browser loop, bring die tonnel af, en kyk of die bewakerverbinding op die fisiese koppelvlak oorleef.

Die volgorde waarin ek kontroleer, en stop by die eerste fout:

• ip route get 203.0.113.10 gee die tonneltoestel terug.
• ss -tnp | grep -i tor wys die bewakerverbinding met ʼn tonnel-plaaslike adres.
• ip -6 route het geen verstekroete buite die tonnel nie, of IPv6 is af in die kliënt.
• Om die VPN te laat val, beëindig of herlei die tor-verbinding eerder as om dit op die fisiese skakel te laat.

Watter volgorde pas by wat jy verdedig

Albei volgordes verberg iets en ontbloot iets, so die antwoord is ʼn keuse oor die waarnemer waaroor jy omgee.

Lees dit per kolom totdat ʼn ry pas by wat jy probeer voorkom. As die bekommernis ʼn plaaslike netwerk of ʼn ISP is wat Tor teken of blokkeer, hanteer Tor oor VPN dit. As die bekommernis is dat die VPN-operateur jou tuisadres leer, hanteer VPN oor Tor dit, en betaal daarvoor deur Tor-gebruik aan jou eie netwerk en jou tuisadres aan die bewaker bloot te stel.

Nie een van die rangskikkings laat albei rande blind nie. Om ʼn waarnemer by te voeg, verwyder nie een nie. Die Tor Project se nota oor ʼn VPN saam met Tor hardloop maak dieselfde punt uit die ander rigting: die tonnel verander wie vertrou word en watter foutpaaie bestaan, so dit is nie ʼn opgradering om by te voeg sonder om te besluit wat jy wou verberg nie.

Besluit eers oor die waarnemer, kies dan die volgorde, en verifieer met ip route get en ss eerder as met die kliënt se aanwyser. As die waarnemer iemand is wat die VPN-verskaffer self kan dwing, maak geen keuse van volgorde dit reg nie.