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