UDP през 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 обикновено е по-подходящ: той пренася пакетите на приложението, без да изисква от него да говори протокол за прокси, с цената на напълно различни свойства на анонимност. Използвайте всеки инструмент за това, което документира, и третирайте всеки мост между тях като отделна система, която се нуждае от собствен преглед. Запишете в окончателния доклад кой слой пренася кой транспорт, за да не преоткрива следващият човек същата граница с друго приложение.