SOCKS proxy dokáže načítať správy, ale pri hovoroch zlyháva
Na základe príručky Dante a požiadaviek UDP v SOCKS5 sa vysvetľuje, prečo funkčná cesta TCP nepreukazuje podporu hovorovej prevádzky aplikácie.
Textové správy prichádzajú cez SOCKS proxy, ale hlasový hovor sa nikdy nespojí. Proxy nemusí byť úplne pokazená. Aplikácia môže na hovory používať iný transport.
Úspešná požiadavka TCP preukazuje cestu TCP pre danú operáciu. SOCKS5 tiež definuje UDP asociáciu, ale klient, služba SOCKS, sieťové pravidlá aj nastavenia aplikácie musia podporovať zamýšľanú trasu UDP.
Nejde len o poslucháč TCP
Príručka Dante oddeľuje pravidlá protokolu a príkazov, vrátane connect, udpassociate a udpreply. Pravidlo, ktoré povoľuje iba už otestované spojenie TCP, nevytvára potrebné oprávnenia UDP.
UDP asociácia zahŕňa aj koncový bod prenosu a spätnú prevádzku. Firewally a preklad adries musia povoliť práve túto cestu. Otvorenie poslucháča TCP v SOCKS nie je to isté ako sprístupnenie jeho prenosu UDP.
Skontrolujte aktuálnu dokumentáciu a nastavenia proxy v aplikácii. Rôzne verzie môžu správy, médiá a hovory spracúvať odlišne. Návod z fóra pre starého klienta by sa nemal vydávať za dôkaz, že každý súčasný klient smeruje hovory cez SOCKS.
Ako prvú diagnostiku neotvárajte všetky porty UDP. Zistite správanie prenosu a zamýšľaný rozsah klientov, potom použite zodpovedajúcu obmedzenú sieťovú politiku. Rovnako vypnutie nastavenia proxy pre hovory môže hovor sprevádzkovať tým, že sa odošle priamo, čo mení vonkajšiu trasu namiesto opravy tej proxyovanej.
Dokumentujte úspech podľa operácií: správy, prenos médií a hovory. Jediná funkčná požiadavka alebo zmenená IP prehliadača nemôže preukázať, že všetky časti inej aplikácie zdieľajú rovnaký výstup proxy.