Ретранслятор Tor против VPN-сервера: почему они не заменяют друг друга

У вас есть адрес, порт отвечает, и клиент принимает его без жалоб. Ничто из этого не делает ретранслятор Tor конечной точкой VPN, и ошибка дорога, потому что профиль импортируется чисто и позже срывается на рукопожатии. Я использую четыре проверки ниже по порядку; у каждой есть условие остановки, и остановиться рано — в этом и смысл. Если первая проверка провалилась, остальные не помогут.

Проверьте, что на самом деле обслуживает порт

Открытый порт доказывает наличие слушателя, не больше. ORPort ретранслятора после рукопожатия TLS говорит собственными ячейками Tor, поэтому успешная проверка TLS почти ничего не говорит о том, принимается ли там протокол VPN:

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

Читайте сертификат, а не факт его наличия. Ретрансляторы предъявляют самоподписанный сертификат с намеренно неприметным именем, потому что трафик ретранслятора должен напоминать обычный HTTPS; сертификат VPN-сервера несёт имя, которого ждёт ваш профиль. Если другая сторона никогда не отвечает на первый пакет протокола VPN, никакая правка профиля не изменит результат.

Остановитесь здесь, если адрес не завершает рукопожатие, которое отправляет ваш клиент. Это ответ протокола, а не проблема конфигурации, и это самая частая причина, почему импортированный профиль навсегда остаётся на 'connecting'.

Проверьте роль ретранслятора, а не размер сети

Роли ретранслятора выполняют разную работу. Guard — первый шаг для клиентов, средний ретранслятор передаёт цепи между другими ретрансляторами, exit — тот, что касается пунктов назначения, а мост — это непубличная точка входа, распространяемая через BridgeDB. Глоссарий Tor держит эти определения отдельно, и доступность является частью каждой роли, тогда как разрешение обслуживать произвольных клиентов не входит ни в одну из них.

Политика exit стоит прочтения, потому что это единственная часть, похожая на правило пересылки, и она регулирует пункты назначения, которые exit позволит выпустить, а не клиентов, которых пускают внутрь. Строгая политика exit, блокирующая порт 25, говорит кое-что о контроле исходящих злоупотреблений, а не о том, можно ли направить клиент OpenVPN на эту машину.

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

Проверьте, локальный ли слушатель SOCKS или публичный

Клиент Tor предоставляет интерфейс SOCKS приложениям на той же машине, по умолчанию на loopback. Этот слушатель — локальное удобство, а не сервис, который ретранслятор предлагает интернету, и относиться к нему как к публичному прокси — это путь, которым люди в итоге запускают открытый ретранслятор, которого не собирались:

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

Адрес привязки — это подсказка. SocksPort на 127.0.0.1:9050 делает свою работу; тот, что слушает на 0.0.0.0 и доступен снаружи, — открытый прокси, и собственные средства контроля политики доступа Tor существуют именно потому, что такая открытость является проблемой, а не функцией.

Для приложения, которому нужен Tor, направьте его на порт loopback и дайте Tor разрешать имена, что и делает форма socks5h выше. Не подменяйте адрес ретранслятора этим портом; ретранслятор не предоставляет интерфейс, который просит ваше приложение.

Проверьте, что профиль VPN соответствует реальной конечной точке

Профиль VPN — это набор ожиданий: OpenVPN нужны сертификат сервера или CA, клиентский сертификат и ключ, а обычно и ключ TLS, тогда как WireGuard нужны открытый ключ другой стороны, конечная точка и разрешённые IP. Ничего из этого нельзя вывести из адреса и открытого порта, поэтому профиль, собранный так, срывается на первом обмене, а не при подключении.

Когда вам передают профиль, проверьте его по конечной точке, которую вы контролируете, или по провайдеру, которого можно опознать:

wg show
openvpn --config client.ovpn --verb 4

В журнале OpenVPN ошибка согласования TLS прямо называет несоответствие; в wg show сторона без строки рукопожатия ни разу его не завершила. И то и другое информативнее вращающегося индикатора клиента, и оба указывают на ключевой материал или протокол, а не на Tor.

Проверьте, какая защита вам действительно нужна

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

У связывания есть порядок. VPN, несущий трафик Tor, — поддерживаемая схема, потому что клиенту Tor нужен только исходящий TCP. Клиент VPN, завёрнутый в туннель внутри Tor, — это не то же самое и не то, что реализует клиент Tor, поэтому не планируйте на этом.

Прежде чем что-либо импортировать, подтвердите все четыре:

• Порт завершает рукопожатие вашего протокола, а не просто TCP-соединение.
• Вы знаете роль хоста и не считаете пересылку разрешением.
• Используемый слушатель SOCKS — это loopback и ваш собственный, а не публичный порт на чужом ретрансляторе.
• Ключи или сертификаты профиля принадлежат конечной точке, к которой вы подключаетесь.