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