Tor VPN felett: ki látja az IP-címedet, és ki látja, hogy Tor-t használsz?

Csatlakoztatod a VPN klienst, megvárod az alagutat, majd megnyitod a Tor Browsert, hogy áramkört építsen. Ez a hétköznapi sorrend dönti el, ki mit lát. Ebben a sorrendben a Tor belépő relaye a VPN kilépési címedet köszönti, a VPN szolgáltatód pedig egy nyilvános guard relayt köszönt. Fordítsd meg, és mindkét megfigyelő változik. Mindkét sorrendet érdemes végigjárni, mert a kliens beállításai csendben megtörik a sorrendet, amelyről az emberek azt hitték, hogy fennáll, és az ezt elkapó ellenőrzés mindkét esetben ugyanaz.

Kezdd a sorrenddel, ne a termékkel

Két elrendezést neveznek „VPN Torral”-nak, és csak az első gyakori. Tor VPN felett esetén az alagút már áll, amikor a Tor elindul, így a tor folyamat a guard kapcsolatát minden más kimenő forgalomhoz hasonlóan az alagútba küldi. VPN Tor felett esetén először a Tor indul el, és maga a VPN munkamenet halad át az áramkörön, a szolgáltatóhoz egy Tor kilépésből érkezve.

Ami köztük változik, az az, melyik cím áll a legkülső láncszem túlsó végén. Minden megfigyelő csak az előző ugrást látja, soha nem a teljes útvonalat: a guard látja, ki kapcsolódott hozzá, a VPN szerver pedig látja, ki kapcsolódott hozzá. A Tor nem viszi kifelé a helyi alagútcímedet, és nincs olyan mező a protokollban, ahol megtehetné.

Mindkét sorrendben a célwebhely továbbra is Tor kilépést lát, és egyik sorrend sem változtatja meg, mit tanul az a webhely a bejelentkezésedből. A különbség a két peremre korlátozódik.

Mit lát a Tor belépő relaye

A belépő, azaz a guard, egy közönséges TCP kapcsolatot fogad egy relay porton, és TLS kézfogást kezd a klienssel. Tor-VPN felett elrendezésben ennek a kapcsolatnak a forrása a VPN kilépésed. Tor-először elrendezésben az a cím, amelyet a géped a Tor hálózat eléréséhez használt, általában az otthoni kapcsolatod.

Ez megválaszolja a kérdés IP-felét, de csak akkor, ha az alagút valóban vitte a kapcsolatot. A Tor folyamat a saját socketjével éri el a guardot, és ezt a socketet nem a Tor Browser proxybeállításai irányítják. A böngésző a beépített tor folyamattal SOCKS-on keresztül beszél a 9150-es porton, majd a tor a saját kapcsolatát a kernel útválasztási táblázata segítségével nyitja meg. A torrc-ben lévő Socks5Proxy sor, vagy egy kliens-transzport, megváltoztatja ezt az utat. Semmi más.

Linuxon leolvashatod a választ a gépről. Kérdezd meg a kernelt, melyik interfészt használná egy tetszőleges nyilvános címhez, majd nézd meg a létrejött kapcsolat helyi címét:

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

Ha az útvonal dev wg0 vagy dev tun0, és a létrejött kapcsolat helyi címe az alagút címe, a Tor a VPN-en belül van. Ha az útvonal a fizikai interfészedet nevezi meg, kívül van, bármit állít a kliens saját jelzője.

Mit láthat a VPN szolgáltatód

A szolgáltató lezárja a VPN munkamenetedet, így látja azokat a címeket, amelyekhez csatlakozol. A guard relayek címei megjelennek a nyilvános konszenzusban, portjaik jól ismertek, így az egyezés listakeresés, nem mély csomagvizsgálat. A szolgáltatónak nem kell feltörnie a Tort ahhoz, hogy tudja: egy munkamenet Tor.

Amit nem lát, az az áramkör többi része. A középső relayt és a kilépést a Toron belül választják ki, a szolgáltató csak a guardhoz vezető láncszemet kezeli. Az oldal tartalma a kilépésnél végződő TLS-en belül marad, és a Tor forgalom névfeloldása is a kilépésnél történik, így nincs olyan DNS-kérés a szolgáltatónál, amelyet célhoz lehetne kapcsolni.

Az obfs4-es hidak a keresést változtatják meg, nem a topológiát. A híd címe hiányzik a nyilvános relaylistáról, és a forgalmat úgy formálják, hogy ne hasonlítson a Torra, így a csak címeket összehasonlító üzemeltető nem jelöli meg. A munkamenet továbbra is a VPN kliense felől jön, és a szolgáltató továbbra is egy végpontot, egy volumenet és egy ütemtervet lát.

A képesség nem adatmegőrzési szabályzat

Az az üzemeltető, aki megfigyelhet egy kapcsolatot, nem ígérte meg, hogy megtartja. A naplózás külön döntés, szabályzatban rögzített, joghatóság által korlátozott, és csak olyan bizonyítékokkal ellenőrizhető, amelyekben már megbízol. A naplók nélküli címke nem változtatja meg a fent leírt hálózati szerepet.

A fiók identitása általában fontosabb a kilépési címnél. Ha e-mail-címmel jelentkeztél be, vagy kártyával fizettél, a szolgáltató egyetlen cél naplózása nélkül is hozzád kötheti a munkamenetet. A kilépési IP-k forgatása ezen nem változtat.

Ellenőrizd a lefedettséget, mielőtt bármelyik válaszban megbízol

A legtöbb ember, aki azt hiszi, hogy Tor-t futtat VPN felett, csak egy részét futtatja. A Tor Browsert kizáró osztott alagutazás, a böngészőt, de nem a tor szolgáltatást lefedő kill switch, az alagút felállása előtt futó indítási egység és az alagutat megkerülő IPv6-útvonal a szokásos négy.

A kliens állapotképernyőjének olvasása egyiket sem teszteli. A teszt, amely igen: hagyd futni a Tor Browsert, húzd le az alagutat, és figyeld, túléli-e a guard kapcsolat a fizikai interfészen.

Az a sorrend, ahogyan ellenőrzöm, az első hibánál megállva:

• ip route get 203.0.113.10 visszaadja az alagút eszközét.
• ss -tnp | grep -i tor megmutatja a guard kapcsolatot egy helyi alagútcímmel.
• ip -6 route nincs alapértelmezett útvonala az alagúton kívül, vagy az IPv6 ki van kapcsolva a kliensben.
• A VPN lecsatolása befejezi vagy átirányítja a tor kapcsolatot ahelyett, hogy a fizikai láncon hagyná.

Melyik sorrend illik ahhoz, amit védesz

Mindkét sorrend elrejt valamit és feltár valamit, így a válasz arról szóló döntés, melyik megfigyelő érdekel.

Oszloponként olvasd, amíg egy sor megfelel annak, amit meg akarsz akadályozni. Ha az aggodalom egy helyi hálózat vagy egy Tor-t rögzítő vagy blokkoló internetszolgáltató, a Tor VPN felett kezeli. Ha az aggodalom az, hogy a VPN üzemeltetője megtudja az otthoni címedet, a VPN Tor felett kezeli, és ennek árát azzal fizeti, hogy a Tor használatot a saját hálózatodnak, az otthoni címedet pedig a guardnak tárja fel.

Egyik elrendezés sem hagyja mindkét peremet vakon. Egy megfigyelő hozzáadása nem szüntet meg egy másikat. A Tor Project megjegyzése a VPN Torral való futtatásáról ugyanezt mondja a másik oldalról: az alagút megváltoztatja, kiben bíznak és milyen hibaútvonalak léteznek, így nem olyan fejlesztés, amelyet anélkül adnak hozzá, hogy eldöntenék, mit akartak elrejteni.

Először döntsd el a megfigyelőt, másodszor válaszd ki a sorrendet, és ellenőrizz ip route get és ss segítségével, ne a kliens jelzőjével. Ha a megfigyelő olyasvalaki, aki magát a VPN szolgáltatót is kényszerítheti, semmilyen sorrendválasztás nem javítja meg.