Tor через VPN: кто видит ваш IP и кто видит, что вы используете Tor?

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

Начните с порядка, а не с продукта

Две схемы называют «VPN с Tor», и распространена только первая. При Tor через VPN туннель уже поднят к моменту запуска Tor, поэтому процесс tor отправляет своё соединение со сторожевым реле в туннель, как любой другой исходящий трафик. При VPN через Tor сначала поднимается Tor, и сама сессия VPN идёт через цепь, приходя к провайдеру с выхода Tor.

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

В обоих порядках сайт назначения по-прежнему видит выход Tor, и ни один порядок не меняет того, что этот сайт узнаёт из вашего входа. Разница ограничена двумя краями.

Что видит входной релей Tor

Вход, или сторожевой релей, принимает обычное TCP-соединение на релейном порту и начинает рукопожатие TLS с клиентом. В схеме Tor-через-VPN источником этого соединения является ваш выход VPN. В схеме Tor-первым это адрес, который ваша машина использовала для выхода в сеть Tor, обычно ваше домашнее подключение.

Это отвечает на IP-половину вопроса, но только если туннель действительно пронёс соединение. Процесс Tor достигает сторожевого релея своим собственным сокетом, и этот сокет не подчиняется настройкам прокси Tor Browser. Браузер говорит с встроенным процессом tor через SOCKS на 9150, и затем tor открывает собственное соединение, используя таблицу маршрутизации ядра. Строка Socks5Proxy в torrc или клиентский транспорт меняют этот путь. Ничто другое.

В Linux ответ можно прочитать с машины. Спросите ядро, какой интерфейс оно использовало бы для произвольного публичного адреса, затем посмотрите на локальный адрес установленного соединения:

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

Если маршрут говорит dev wg0 или dev tun0, а локальный адрес установленного соединения является адресом туннеля, Tor находится внутри VPN. Если маршрут называет ваш физический интерфейс, он снаружи, что бы ни утверждал собственный индикатор клиента.

Что может видеть ваш VPN-провайдер

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

Чего он не видит, так это остатка цепи. Средний релей и выход выбираются внутри Tor, а провайдер обрабатывает только звено до сторожевого релея. Содержимое страницы остаётся внутри TLS, который заканчивается на выходе, и разрешение имён для трафика Tor тоже происходит на выходе, поэтому у провайдера нет ни одного DNS-запроса, который можно было бы сопоставить с назначением.

Мосты с obfs4 меняют поиск, а не топологию. Адреса моста нет в публичном списке релеев, а трафик формируется так, чтобы не выглядеть как Tor, поэтому оператор, который только сравнивает адреса, его не отметит. Сессия по-прежнему идёт от вашего VPN-клиента, и провайдер по-прежнему видит одну конечную точку, один объём и одно расписание.

Возможность — не политика хранения

Оператор, который может наблюдать соединение, не обещал его хранить. Логирование — отдельное решение, записанное в политике, ограниченное юрисдикцией и проверяемое только теми доказательствами, которым вы уже доверяете. Метка «без логов» не меняет описанную выше сетевую роль.

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

Проверьте покрытие, прежде чем доверять любому из двух ответов

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

Чтение экрана состояния клиента не проверяет ни одного из них. Проверка, которая это делает: оставьте Tor Browser работать, опустите туннель и посмотрите, выживает ли соединение со сторожевым релеем на физическом интерфейсе.

Порядок, в котором я проверяю, останавливаясь на первой неудаче:

• ip route get 203.0.113.10 возвращает устройство туннеля.
• ss -tnp | grep -i tor показывает соединение со сторожевым релеем с локальным адресом туннеля.
• ip -6 route не имеет маршрута по умолчанию вне туннеля, или в клиенте выключен IPv6.
• Опускание VPN завершает или перенаправляет соединение tor вместо того, чтобы оставить его на физическом звене.

Какой порядок подходит тому, что вы защищаете

Оба порядка что-то скрывают и что-то раскрывают, поэтому ответ — это выбор наблюдателя, который вам важен.

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

Ни одна схема не оставляет оба края слепыми. Добавление наблюдателя не убирает другого. Заметка Tor Project о запуске VPN вместе с Tor говорит то же самое с другой стороны: туннель меняет, кому доверяют и какие пути отказа существуют, поэтому это не улучшение, которое добавляют, не решив, что вы хотели скрыть.

Сначала решите про наблюдателя, затем выберите порядок и проверяйте с помощью ip route get и ss, а не индикатора клиента. Если наблюдатель — тот, кто может принудить самого VPN-провайдера, никакой выбор порядка этого не исправит.