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 браўзера не даказвае, што ўсе часткі іншай праграмы выкарыстоўваюць той самы выхад проксі.