UDP кроз Tor-ов SOCKS порт: шта не пролази

Усмеравање апликације на SOCKS порт ради за прегледач, а не ради за игру, и разлог није конфигурација. SOCKS5 дефинише неколико наредби, а имплементација је слободна да подржи само неке од њих; интерфејс Tor-а прихвата струјне везе и разрешавање имена, а не произвољно прослеђивање датаграма. Клијент који шаље UDP и очекује да их прокси пренесе тражи наредбу коју сервер не имплементира. Упутство испод то проверава за неколико минута и затим бира транспорт који заиста може да ради.

Проверите шта апликација заиста шаље

Почните препознавањем транспорта, а не назива протокола. Гласовни клијент може да се пријави преко HTTPS-а и затим преноси медије преко UDP-а; игра може да се аутентификује преко TCP-а и игра преко UDP-а; пренос датотека може користити TCP за контролу и UDP за откривање. Прва два понашања изгледају исто док пријава не успе, а позив и даље не ради, зато „повезао се“ није доказ да цела апликација ради. Неки клијенти се сами враћају са UDP-а на TCP, што чини делимично радну сесију сличном нестабилној мрежи, а не блокираном транспорту.

Запишите одредишни порт и транспорт за део који не ради. Тај један ред одлучује може ли прокси уопште да помогне.

Шта ће Tor-ов SOCKS интерфејс прихватити

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 је обично бољи избор: преноси пакете апликације не тражећи од ње да говори прокси протокол, по цени сасвим другачијих својстава анонимности. Користите сваки алат за оно што документује и третирајте сваки мост између њих као засебан систем који треба сопствени преглед. Запишите у завршном извештају који слој преноси који транспорт, да следећа особа не открије исту границу са другом апликацијом.