VPN перед Tor: что на самом деле меняет порядок

Если сначала подключить VPN, возникает определённая цепочка: устройство, конечная точка VPN, вход Tor, цепь Tor, назначение. Ваша локальная сеть видит одно зашифрованное соединение с VPN, а входной узел Tor видит выход VPN как непосредственный источник вместо адреса вашего провайдера. Оператор VPN, в свою очередь, видит соединения к входной инфраструктуре Tor и может вывести использование Tor по назначениям. Каждый наблюдатель что-то теряет и что-то получает, поэтому порядок — это обмен, а не улучшение.

Ничто в этой цепочке не меняет того, что сайт узнаёт из вашей учётной записи, файлов cookie или введённых данных.

Что меняет порядок

Локальная сеть и провайдер теряют прямой обзор вашего трафика Tor, потому что первый шаг теперь — зашифрованный туннель к провайдеру. Входной страж Tor теряет ваш домашний адрес и видит выход VPN. Провайдер VPN получает метаданные, которые раньше были у вашего провайдера: к каким адресам вы обращаетесь, в какое время и сколько данных передаётся.

За входным стражем цепь ведёт себя как прежде. Реле по-прежнему разделяют роли входа, середины и выхода, и VPN видит итоговое содержимое не больше, чем ваш провайдер.

Подтвердите путь, который действительно используется

Раздельное туннелирование — обычная причина того, что задуманная цепочка не является реальной.Если Tor Browser исключён из туннеля, или второй профиль маршрутизируется иначе, входной страж снова видит адрес провайдера, хотя интерфейс всё ещё выглядит подключённым. Проверяйте маршрут и наблюдаемый выход, а не значок.

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

На запрос SOCKS через порт 9150 отвечает собственный клиент Tor Browser, поэтому ответ IsTor true подтверждает цепь браузера, а не то, что его использует каждая другая программа. Выход резолвера стоит записать, потому что DNS может уйти путём, который туннель не покрывает. Сохраняйте оба вывода с отметкой времени. Они — база для следующего сравнения.

Сравните с прямым запросом из обычного терминала: если он тоже сообщает о Tor, значит, что-то другое перенаправляет трафик, и цепочка не та, что предполагал проект.

Смотрите, что происходит при падении туннеля

Клиент, который тихо возвращается на локальный интерфейс, меняет источник, который видит входной страж, и пользователь обычно об этом не знает, потому что страница всё ещё загружается. Именно этот сбой стоит проверять, а не благополучный путь. Намеренно отключите туннель и посмотрите, останавливается ли трафик Tor или продолжается без защиты.

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

Правила брандмауэра, блокирующие исходящий трафик вне туннеля, — единственный надёжный резервный контроль, и они должны охватывать как SOCKS-клиент браузера, так и любую другую важную для вас программу. Расширение браузера не является VPN устройства и не влияет на другие программы или внешних наблюдателей.

Решите, заслуживает ли дополнительный слой доверия

Проект Tor не советует размещать VPN под Tor, если вы не можете сами оценить настройку. Названная причина — дополнительная зависимость: ещё одна сторона, ещё одна учётная запись и ещё один режим сбоя. Если цель в том, чтобы ваш провайдер не видел использования Tor, VPN адресуется именно этому наблюдателю. Если цель — более сильная анонимность против глобального наблюдателя, VPN её не даёт.

Существует и обратный порядок, и названия не взаимозаменяемы:Tor поверх VPN и VPN поверх Tor описывают разные отношения доверия и разное поведение при сбое. Прочитайте сравнение, прежде чем смешивать их.

Запишите, какого наблюдателя вы пытаетесь сдвинуть, затем проверьте, что реальный путь соответствует проекту, затем проверьте поведение при сбое. Если эти три ответа не оправдывают дополнительную учётную запись и настройку, в документированной настройке Tor Browser меньше частей, которые можно сделать неправильно.