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

Схожі статті