VPN у Tor, Tor у VPN: зашто се ланац кида

Слагање VPN-а, Tor-а и проксија апликације једно на друго изгледа као умножавање приватности, а заправо умножава број места на којима веза може да умре. Уобичајен резултат је прегледач који се врти док сва три алата себе пријављују здравима. Промена сва три подешавања одједном затим уклања једини траг о томе који од њих лаже.

Прво нацртајте предвиђену путању по реду, именујући који програм отвара сваку везу и које се име разрешава на сваком кораку.

Слојеви се не сабирају, они делују један на други

VPN пре Tor-а значи да улазна веза Tor клијента путује унутар тунела. VPN који се преноси кроз Tor значи да сопствена завршна тачка VPN клијента мора бити доступна преко Tor-а, што је сасвим други захтев. Прокси прегледача додаје још један скок о којем оперативни систем не зна ништа. Три распореда, три одвојене листе зависности.

Сваки распоред мења шта се може разрешити, шта се може пренети и ко види први пакет. Само један од њих може бити конфигурација коју сте мислили.

Додајте на дијаграм и директну путању. Резервна рута, изузетак за подељени тунел или обилажење проксија могу да учитају страницу док тихо прескачу ланац који сте хтели да тестирате, а такав успех обмањује више од неуспеха.

Редослед одређује шта се може пренети

Tor преноси TCP токове кроз своје SOCKS сучеље, а клијент који замоли прокси да разреши име хоста задржава претрагу унутар круга. UDP тако не путује у уобичајеним конфигурацијама, зато се WireGuard тунел не може уградити у Tor без додатног TCP релеја у средини.

OpenVPN може да се присили на TCP, па је тај распоред барем описив. Он је и спорији и крхкији, а начин квара када се поквари изгледа једнако као блокиран порт. Очекујте да ћете на разликовање тих двоје потрошити више времена него на поправку било којег.

Разрешавање је друга половина. Са --socks5-hostname прокси разрешава одредиште, док обични --socks5 прво пита локални разрешивач и исиса име изван круга. Управо тај један параметар одлучује да ли претрага имена припада ланцу или вашем провајдеру.

Проналажење прве прекинуте границе

Тестирајте етапе редом којим пакети путују, безопасним захтевима, и зауставите се на првој која не успе. Забележите која је наредба извршена прва, јер је редослед део доказа. Две наредбе раздвајају мртав круг од мртвог излаза:

curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip
curl -4 -s https://api.ipify.org; echo

Прва јавља да ли се захтев уопште завршава кроз SOCKS прокси, а друга показује адресу коју мрежа тренутно представља. Ако прва не успе а друга успе, проблем је код Tor клијента или пре њега. Ако обе успеју а прегледач и даље не ради, апликација користи други пут од љуске.

Страница јавне IP адресе такође описује само последњи видљиви излаз. Не може да каже колико је скокова претходило, зато је упарите са подржаним статусним излазом сваког алата уместо да један број третирате као дијаграм.

Када престати додавати слојеве

Ако не можете једном реченицом да кажете шта слој доприноси, уклоните га. Ланац чија сврха није јасна ланац је који нико не може да отклони у три ујутру, а добитак приватности од необјашњеног скока обично је мањи од доступности коју губите.

Ако слој заиста заслужује своје место, прво га тестирајте самог, затим додајте следећи и поново потврдите путању истим двема наредбама. Вратите цео ланац пре уобичајене употребе и оставите TLS проверу и аутентификацију укљученима; упозорење о сертификату прихваћено да би се страница учитала је заобилажење усмеравања, не поправка. Запишите редослед на којем сте се зауставили док је још свеж.

Запишите тај редослед, укључујући разрешивач који одговара на свакој етапи. Радни ланац који можете да опишете преживљава следећу надоградњу, док радни ланац састављен покушајима нестаје с њом. Додајте датум и верзије, да се каснији квар може упоредити са познатим добрим стањем уместо да се о њему расправља по сећању. Десет редова у текстуалној датотеци штеди вече нагађања.