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 предупреждава срещу комбинации, които потребителите не могат да конфигурират правилно, и тази се отнася за повечето хора. Това е умишлен дизайн за тесен модел на заплаха, а не пряк път към анонимен трафик на цялото устройство.