Java DatagramSocket і рэтрансляцыя UDP праз SOCKS5
Зразумейце, чаму Java UDP-сокету патрэбна рэалізацыя SOCKS5 UDP, нават калі TCP-злучэнні ўжо выкарыстоўваюць SOCKS.
Ваш HTTP-запыт на Java працуе праз SOCKS, але функцыя UDP усё яшчэ адпраўляе трафік напрамую або не працуе. Усталяванне ўласцівасцей SOCKS у JVM не дае DatagramSocket рэалізацыі SOCKS5 UDP.
API DatagramSocket адпраўляе і прымае датаграмы, адрасаваныя сеткавым канчатковым пунктам. Яго метад connect() выбірае партнёра для гэтага сокета. Ён не выконвае SOCKS-перамовы з партнёрам.
Маршрут SOCKS5 UDP патрабуе дадатковай працы
SOCKS5 вызначае UDP-асацыяцыю, якая ўсталёўваецца праз TCP-злучэнне кіравання. Затым кліент абменьваецца інкапсуляванымі датаграмамі з адрасам рэтрансляцыі, які падае проксі. Кожнае інкапсуляванае паведамленне вызначае сваё прызначэнне. Рэалізацыя кліента павінна апрацоўваць гэтую структуру і час жыцця злучэння кіравання.
Напрамкі звычайнага UDP-сокета на TCP-порт праслухоўвання проксі прапускае гэтыя крокі. Адпраўка сырых датаграм вашай праграмы на гэты адрас не замяняе асацыяцыю.
Выберыце бібліятэку або функцыю праграмы, якая відавочна падтрымлівае рэтрансляцыю SOCKS5 UDP, і пераканайцеся, што сервер таксама яе падтрымлівае. Бібліятэка, якая заяўляе падтрымку SOCKS, можа рэалізоўваць толькі TCP CONNECT. Спецыфікацыя пратакола адрознівае гэтыя каманды.
Рэтрансляцыі UDP таксама патрэбны прыдатны шлях
Паспяховае TCP-злучэнне з проксі ўсталёўвае толькі шлях кіравання. Брандмаўэры або паводзіны NAT усё яшчэ могуць перашкаджаць датаграмам, адпраўленым рэтранслятару. Сабярыце вернуты канчатковы пункт рэтрансляцыі і любую памылку рэтрансляцыі, перш чым рабіць выснову, што мэта праграмы недаступная.
Нарэшце, падтрымка транспарту SOCKS не дадае UDP гарантый дастаўкі. Уласныя тайм-аўты вашай праграмы, апрацоўка страт і абмежаванні памеру паведамленняў па-ранейшаму дзейнічаюць пасля змены маршруту.