SOCKS posrednik lahko naloži sporočila, a pri klicih spodleti
S priročnikom Dante in zahtevami UDP v SOCKS5 je razloženo, zakaj delujoča pot TCP ne dokazuje podpore za promet klicev aplikacije.
Besedilna sporočila pridejo prek posrednika SOCKS, a glasovni klic se nikoli ne poveže. Posrednik ni nujno popolnoma pokvarjen. Aplikacija lahko za klice uporablja drug prenos.
Uspešna zahteva TCP dokazuje pot TCP za to operacijo. SOCKS5 določa tudi povezavo UDP, a odjemalec, storitev SOCKS, omrežna pravila in nastavitve aplikacije morajo vsi podpirati predvideno pot UDP.
Obstaja več kot le poslušalec TCP
Priročnik Dante ločuje pravila protokola in ukazov, vključno z connect, udpassociate in udpreply. Pravilo, ki dovoljuje le že preizkušeno povezavo TCP, ne vzpostavi potrebnih dovoljenj UDP.
Povezava UDP vključuje tudi končno točko posredovanja in povratni promet. Požarni zidovi in prevajanje naslovov morajo dovoliti prav to pot. Odpreti poslušalec TCP v SOCKS ni enako temu, da postane njegov posrednik UDP dosegljiv.
Preverite trenutno dokumentacijo in nastavitve posrednika v aplikaciji. Različne različice lahko sporočila, medije in klice obravnavajo različno. Recepta s foruma za starega odjemalca ne bi smeli predstavljati kot dokaz, da vsak sedanji odjemalec usmerja klice prek SOCKS.
Izogibajte se odpiranju vseh vrat UDP kot prvi diagnozi. Ugotovite vedenje posredovanja in predviden obseg odjemalcev, nato uporabite ustrezno omejeno omrežno politiko. Prav tako lahko izklop nastavitve posrednika za klice klic uspe, ker se pošlje neposredno, kar spremeni zunanjo pot, namesto da bi popravilo posredovano.
Dokumentirajte uspeh po operaciji: sporočila, prenos medijev in klici. Ena delujoča zahteva ali spremenjen IP brskalnika ne moreta dokazati, da si vsak del druge aplikacije deli isti izhod posrednika.