VPN преко Tor-а: прво провера транспорта

Tor прво значи да VPN клијент стоји иза SOCKS проксија, тако да се сам тунел гради кроз Tor, а саобраћај апликација излази са VPN одредишта. То је један конкретан редослед и није оно што већина људи гради. Отварање Tor Browser-а поред обичног VPN клијента не приморава ни један од два програма да користи пут оног другог.

Прођите провере по реду. Свака одлучује да ли следећу вреди започети.

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

Два редоследа се мешају у истом разговору. Tor прво значи да VPN клијент стиже до свог сервера кроз SOCKS прокси, тако да се тунел гради преко Tor-а. VPN прво значи да саобраћај Tor-а излази кроз тунел, што већина људи гради случајно и затим описује као онај други. Први концентрише границу прослеђивања код VPN оператера, други је концентрише на улазу и излазу Tor-а. Ниједан није оно што добијате држећи оба програма отворена истовремено.

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

Проверите транспорт пре свега осталог

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

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

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

Препишите мапу посматрача

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

Она такође не поново ствара дистрибуирани пут до сваког одредишта. Tor Browser гради свеж круг за сваку страницу; VPN ношен преко Tor-а гради један тунел и свака страница иза њега дели ту одредишну тачку. Третирајте разлику као чињеницу дизајна, а не као ограничење које треба уклонити.

Пребројте слојеве отказа када се поквари

Покварена поставка има најмање четири независна слоја: SOCKS везу, TLS руковање са VPN сервером, само VPN руковање и затим рутирање или разрешавање имена унутар тунела. Сваки пада са различитим симптомом и сваком треба другачија поправка. Олабављење провера сертификата зато што се тунел не диже класична је погрешна дијагноза и претвара транспортни проблем у безбедносни.

Забележите први слој који падне и зауставите се ту. Одбијање проксија и одбијени кључ нису варијанте истог догађаја.

Зауставите се ако модел претњи тражи одбране Tor Browser-а

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

Сам Tor Project упозорава на комбинације које корисници не могу исправно да конфигуришу, а ова се односи на већину људи. То је намерен дизајн за уску модел претње, а не пречица до анонимног саобраћаја целог уређаја.