UDP через SOCKS-порт Tor: что не передаётся
SOCKS-интерфейс Tor принимает потоковые соединения, а не произвольные датаграммы. Выполните проверку по порядку, а затем выберите транспорт, который приложение действительно поддерживает.
Направить приложение на SOCKS-порт работает для браузера и не работает для игры, и причина не в конфигурации. SOCKS5 определяет несколько команд, и реализация вправе поддерживать лишь некоторые из них; интерфейс Tor принимает потоковые соединения и разрешение имён, а не произвольную передачу датаграмм. Клиент, который отправляет UDP и ждёт, что прокси его перешлёт, требует команды, которую сервер не реализует. Инструкция ниже проверяет это за несколько минут и затем выбирает транспорт, который действительно может работать.
Проверьте, что приложение действительно отправляет
Начните с определения транспорта, а не названия протокола. Голосовой клиент может войти через HTTPS и затем передавать медиа через UDP; игра может аутентифицироваться через TCP и играть через UDP; передача файлов может использовать TCP для управления и UDP для обнаружения. Первые два поведения выглядят одинаково, пока вход не удастся, а звонок всё ещё не работает, поэтому «подключилось» не доказывает, что работает всё приложение. Некоторые клиенты сами возвращаются с UDP на TCP, из-за чего частично работающая сессия выглядит как нестабильная сеть, а не как заблокированный транспорт.
Запишите порт назначения и транспорт для той части, которая не работает. Именно эта одна строка решает, может ли прокси вообще помочь.
Что примет SOCKS-интерфейс Tor
Tor реализует команду SOCKS5 CONNECT для потоковых соединений и команды расширения для разрешения имён, поэтому браузер работает через него без изменений. UDP ASSOCIATE, команда, которая позволила бы клиенту передать датаграммы прокси для пересылки, не входит в то, что предлагает Tor. Документация расширений находится в спецификации расширений SOCKS проекта, и она короткая. Отсутствие команды для датаграмм намеренно: пересылка произвольного UDP дала бы сети роль пересыльщика, для которой она никогда не проектировалась.
Это же ответ для WireGuard, который по замыслу является UDP и не имеет резервного пути через TCP. Не существует поддерживаемого пути, направляющего WireGuard на SOCKS-порт, и всё, что утверждает обратное, — это обёртка с собственной историей доверия и сопровождения, а не функция одного из двух инструментов.
OpenVPN — частичное исключение, потому что его можно настроить на туннелирование через TCP, и он понимает опцию прокси SOCKS. Это всё равно требует сервера, настроенного для TCP, и осознанного решения о последствиях для производительности и отпечатка, поэтому это проектный выбор, а не исправление совместимости.
Выполните проверку по порядку
Сначала убедитесь, что прокси работает для потоков, чтобы более поздняя неудача не была списана на недоступный порт. Затем проверьте собственный трафик приложения и посмотрите, какие сокеты оно действительно открывает.
curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'
Успешная первая команда и установленный поток во второй строке показывают, что путь через прокси работает как задумано. Третья команда ищет локальные сокеты датаграмм, принадлежащие приложению; если клиент открывает один и отправляет напрямую на удалённый адрес, он никогда не обращался к прокси, и никакая настройка прокси этого не изменит. Если сбой происходит уже на первом шаге, остановитесь и исправьте путь через прокси, прежде чем исследовать приложение, потому что две неисправности сразу дают отчёт, с которым никто не может ничего сделать.
Откатите изменения и выберите правильный инструмент
Удалите все переменные окружения прокси или настройки прокси для отдельных приложений, которые направляли клиент UDP на SOCKS-порт; если их оставить, последующие тесты станут неоднозначными. Восстановите прежнюю конфигурацию из копии, перезапустите приложение и убедитесь, что исходное поведение вернулось, чтобы сравнение было чистым. Откат без проверки — это лишь надежда на то, что состояние изменилось.
Для транспорта, который должен остаться UDP, VPN обычно подходит лучше: он несёт пакеты приложения, не требуя, чтобы приложение говорило на языке прокси-протокола, ценой совершенно иных свойств анонимности. Используйте каждый инструмент для того, что он документирует, и относитесь к любому мосту между ними как к отдельной системе, которой нужен собственный обзор. Запишите в итоговом отчёте, какой уровень несёт какой транспорт, чтобы следующий человек не открыл ту же границу заново с другим приложением.