’n SOCKS-volmag kan boodskappe laai maar faal op oproepe
Verduidelik met Dante en SOCKS5 se UDP-vereistes waarom ’n werkende TCP-pad nie ondersteuning vir ’n toepassing se oproepverkeer bewys nie.
Teksboodskappe kom deur ’n SOCKS-volmag binne, maar ’n stemoproep verbind nooit nie. Die volmag is nie noodwendig heeltemal stukkend nie. Die toepassing gebruik moontlik ’n ander vervoer vir oproepe.
’n Suksesvolle TCP-versoek bewys ’n TCP-pad vir daardie bewerking. SOCKS5 definieer ook UDP-assosiasie, maar die kliënt, SOCKS-diens, netwerkstreëls en toepassinginstellings moet almal die beoogde UDP-roete ondersteun.
Daar is meer as ’n TCP-luisteraar
Die Dante-handleiding skei protokol- en opdragreëls, insluitend connect, udpassociate en udpreply. ’n Reël wat net die TCP-verbinding toelaat wat jy reeds getoets het, vestig nie die vereiste UDP-toestemmings nie.
UDP-assosiasie behels ook ’n aflos-eindpunt en terugkeerverkeer. Vuurmure en adresvertaling moet daardie werklike pad toelaat. Om die SOCKS TCP-luisteraar oop te maak is nie dieselfde as om sy UDP-aflos bereikbaar te maak nie.
Kontroleer die toepassing se huidige volmagdokumentasie en -instellings. Verskillende weergawes kan boodskappe, media en oproepe anders hanteer. ’n Forumresep vir ’n ou kliënt moet nie as bewys aangebied word dat elke huidige kliënt oproepe deur SOCKS stuur nie.
Vermy om elke UDP-poort as eerste diagnose oop te maak. Bepaal die aflosgedrag en beoogde kliëntomvang, en pas dan die toepaslike beperkte netwerkbeleid toe. Net so kan die deaktivering van ’n volmag-vir-oproepe-instelling ’n oproep laat werk deur dit direk te stuur, wat die uitwaartse roete verander eerder as om die gevolmagtigde een te herstel.
Dokumenteer sukses per bewerking: boodskappe, media-oordrag en oproepe. ’n Enkele werkende versoek of ’n veranderde blaaier-IP kan nie bewys dat elke deel van ’n ander toepassing dieselfde volmag-uitgang deel nie.