SOCKS proxy může načíst zprávy, ale u hovorů selhává
Na základě příručky Dante a požadavků UDP v SOCKS5 vysvětluje, proč funkční cesta TCP neprokazuje podporu pro hovorový provoz aplikace.
Textové zprávy přicházejí přes SOCKS proxy, ale hlasový hovor se nikdy nespojí. Proxy nemusí být úplně rozbitá. Aplikace může pro hovory používat jiný transport.
Úspěšný požadavek TCP prokazuje cestu TCP pro danou operaci. SOCKS5 také definuje UDP asociaci, ale klient, služba SOCKS, síťová pravidla i nastavení aplikace musí podporovat zamýšlenou trasu UDP.
Nejde jen o posluchač TCP
Příručka Dante odděluje pravidla protokolu a příkazů, včetně connect, udpassociate a udpreply. Pravidlo, které povoluje pouze vámi už otestované spojení TCP, nevytváří potřebná oprávnění UDP.
UDP asociace zahrnuje také koncový bod přenosu a zpětný provoz. Firewally a překlad adres musí povolit právě tuto cestu. Otevření posluchače TCP v SOCKS není totéž jako zpřístupnění jeho přenosu UDP.
Zkontrolujte aktuální dokumentaci a nastavení proxy v aplikaci. Různé verze mohou zprávy, média a hovory zpracovávat odlišně. Návod z fóra pro starého klienta by se neměl vydávat za důkaz, že každý současný klient směruje hovory přes SOCKS.
Jako první diagnostiku neotvírejte všechny porty UDP. Zjistěte chování přenosu a zamýšlený rozsah klientů, potom použijte odpovídající omezenou síťovou politiku. Stejně tak vypnutí nastavení proxy pro hovory může hovor zprovoznit tím, že se odešle přímo, což mění vnější trasu, místo aby opravilo tu proxyovanou.
Dokumentujte úspěch podle operací: zprávy, přenos médií a hovory. Jediný funkční požadavek nebo změněná IP prohlížeče nemůže prokázat, že všechny části jiné aplikace sdílejí stejný výstup proxy.