Java DatagramSocket і ретрансляція UDP через SOCKS5
Зрозумійте, чому Java UDP-сокету потрібна реалізація SOCKS5 UDP, навіть коли TCP-з’єднання вже використовують SOCKS.
Ваш HTTP-запит на Java працює через SOCKS, але функція UDP досі надсилає трафік напряму або завершується помилкою. Встановлення властивостей SOCKS JVM не дає DatagramSocket реалізації SOCKS5 UDP.
API DatagramSocket надсилає й приймає дейтаграми, адресовані мережевим кінцевим точкам. Його метод connect() вибирає партнера для цього сокета. Він не виконує узгодження SOCKS з партнером.
Маршрут UDP через SOCKS5 потребує додаткової роботи
SOCKS5 визначає UDP-асоціацію, що встановлюється поверх керуючого з’єднання TCP. Далі клієнт обмінюється інкапсульованими дейтаграмами з адресою ретрансляції, яку надає проксі. Кожне інкапсульоване повідомлення визначає своє призначення. Реалізація клієнта має обробляти це пакування та час життя керуючого з’єднання.
Спрямування звичайного UDP-сокета на TCP-порт прослуховування проксі пропускає ці кроки. Надсилання сирих дейтаграм вашого застосунку на цю адресу не замінює асоціацію.
Виберіть бібліотеку або функцію застосунку, яка явно підтримує ретрансляцію UDP через SOCKS5, і переконайтеся, що сервер також її підтримує. Бібліотека, яка заявляє підтримку SOCKS, може реалізувати лише TCP CONNECT. Специфікація протоколу розрізняє ці команди.
Ретрансляції UDP також потрібен придатний шлях
Успішне TCP-з’єднання з проксі встановлює лише керуючий шлях. Міжмережеві екрани або поведінка NAT усе ще можуть заважати дейтаграмам, надісланим на ретрансляцію. Зберіть повернену кінцеву точку ретрансляції та будь-яку помилку ретрансляції, перш ніж робити висновок, що призначення застосунку недоступне.
Нарешті, підтримка транспорту SOCKS не додає UDP гарантій доставки. Власні тайм-аути вашого застосунку, обробка втрат і обмеження розміру повідомлень діють і після зміни маршруту.