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 предупреждает против комбинаций, которые пользователи не могут правильно настроить, и эта относится к большинству людей. Это намеренный дизайн для узкой модели угроз, а не короткий путь к анонимному трафику всего устройства.

Похожие статьи