SOCKS-prokurilo povas ŝargi mesaĝojn sed malsukcesas ĉe alvokoj
Per la Dante-manlibro kaj la UDP-postuloj de SOCKS5 oni klarigas, kial funkcianta TCP-vojo ne pruvas subtenon por la alvoka trafiko de aplikaĵo.
Tekstaj mesaĝoj alvenas per SOCKS-prokurilo, sed voĉa alvoko neniam konektiĝas. La prokurilo ne nepre estas tute rompita. La aplikaĵo eble uzas alian transporton por alvokoj.
Sukcesa TCP-peto pruvas TCP-vojon por tiu operacio. SOCKS5 ankaŭ difinas UDP-asocion, sed la kliento, la SOCKS-servo, la retaj reguloj kaj la agordoj de la aplikaĵo ĉiuj devas subteni la celatan UDP-vojon.
Estas pli ol TCP-aŭskultanto
La Dante-manlibro apartigas protokolajn kaj komandajn regulojn, inkluzive de connect, udpassociate kaj udpreply. Regulo, kiu permesas nur la TCP-konekton, kiun vi jam testis, ne starigas la postulatajn UDP-permesojn.
UDP-asocio ankaŭ enhavas plusendan finpunkton kaj returnan trafikon. Fajroŝirmiloj kaj adresa tradukado devas permesi tiun realan vojon. Malfermi la TCP-aŭskultanton de SOCKS ne samas al igi ĝian UDP-plusendilon atingebla.
Kontrolu la aktualan prokurilan dokumentaron kaj agordojn de la aplikaĵo. Malsamaj versioj povas trakti mesaĝojn, aŭdvidaĵojn kaj alvokojn malsame. Forumrecepto por malnova kliento ne prezentu kiel pruvon, ke ĉiu nuna kliento direktas alvokojn tra SOCKS.
Evitu malfermi ĉiun UDP-pordon kiel unuan diagnozon. Determinu la plusendan konduton kaj la celatan klientaron, poste apliku la taŭgan limigitan retan politikon. Same, malŝalti agordon pri prokurilo por alvokoj povas igi alvokon funkcii sendante ĝin rekte, kio ŝanĝas la eksteran vojon anstataŭ ripari la prokurilan.
Dokumentu sukceson laŭ operacio: mesaĝoj, aŭdvida transigo kaj alvokoj. Unu funkcianta peto aŭ ŝanĝita retumila IP ne povas pruvi, ke ĉiu parto de alia aplikaĵo dividas la saman prokurilan eliron.