Проксі SOCKS може завантажувати повідомлення, але не працює з викликами
За допомогою посібника Dante та вимог UDP у SOCKS5 пояснюється, чому робочий шлях TCP не доводить підтримку викликів застосунку.
Текстові повідомлення надходять через проксі SOCKS, але голосовий виклик так і не встановлюється. Проксі не обов'язково повністю несправний. Застосунок може використовувати для викликів інший транспорт.
Успішний запит TCP доводить наявність шляху TCP для цієї операції. SOCKS5 також визначає UDP-асоціацію, але клієнт, служба SOCKS, мережеві правила та налаштування застосунку мають підтримувати потрібний маршрут UDP.
Це більше, ніж слухач TCP
Посібник Dante розділяє правила протоколу й команд, зокрема connect, udpassociate і udpreply. Правило, яке дозволяє лише вже перевірене з'єднання TCP, не створює потрібних дозволів UDP.
UDP-асоціація включає також точку пересилання та зворотний трафік. Міжмережеві екрани й трансляція адрес мають дозволяти саме цей шлях. Відкрити слухач TCP у SOCKS не те саме, що зробити його пересилання UDP доступним.
Перевірте поточну документацію й налаштування проксі в застосунку. Різні версії можуть по-різному обробляти повідомлення, медіа та виклики. Рецепт із форуму для старого клієнта не слід подавати як доказ того, що кожен сучасний клієнт спрямовує виклики через SOCKS.
Не починайте діагностику з відкриття всіх портів UDP. Визначте поведінку пересилання й передбачуване коло клієнтів, потім застосуйте відповідну обмежувальну мережеву політику. Так само вимкнення налаштування проксі для викликів може змусити виклик працювати, надіславши його напряму, що змінює зовнішній маршрут, а не виправляє проксійований.
Фіксуйте успіх за кожною операцією: повідомлення, передавання медіа та виклики. Один успішний запит або змінений IP браузера не доводить, що всі частини іншого застосунку використовують той самий вихід проксі.