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

Відкритий порт на ретрансляторі Tor — не кінцева точка VPN. Спочатку перевірте, що обслуговує порт, роль ретранслятора, область прослуховування SOCKS і профіль.

У вас є адреса, порт відповідає, і клієнт приймає його без жодних скарг. Ніщо з цього не робить ретранслятор 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 і ваш власний, а не публічний порт на чужому ретрансляторі.
  • Ключі або сертифікати профілю належать кінцевій точці, до якої ви підключаєтеся.

Схожі статті