Een SOCKS-proxy kan berichten laden maar faalt bij gesprekken
Met de Dante-handleiding en de UDP-eisen van SOCKS5 wordt uitgelegd waarom een werkend TCP-pad geen ondersteuning aantoont voor het gespreksverkeer van een toepassing.
Tekstberichten komen binnen via een SOCKS-proxy, maar een spraakgesprek komt nooit tot stand. De proxy is daarom niet per se volledig stuk. De toepassing gebruikt voor gesprekken mogelijk een ander transport.
Een geslaagd TCP-verzoek bewijst een TCP-pad voor die bewerking. SOCKS5 definieert ook UDP-associatie, maar de client, de SOCKS-dienst, netwerkregels en toepassingsinstellingen moeten allemaal het beoogde UDP-pad ondersteunen.
Er is meer dan een TCP-listener
De Dante-handleiding scheidt protocol- en commandoregels, waaronder connect, udpassociate en udpreply. Een regel die alleen de al geteste TCP-verbinding toestaat, legt niet de vereiste UDP-rechten vast.
UDP-associatie omvat ook een relay-eindpunt en retourverkeer. Firewalls en adresvertaling moeten precies dat pad toestaan. De TCP-listener van SOCKS openen is niet hetzelfde als zijn UDP-relay bereikbaar maken.
Controleer de huidige proxydocumentatie en instellingen van de toepassing. Verschillende versies kunnen berichten, media en gesprekken anders behandelen. Een forumrecept voor een oude client mag niet worden gepresenteerd als bewijs dat elke huidige client gesprekken via SOCKS leidt.
Vermijd het openen van elke UDP-poort als eerste diagnose. Bepaal het relaygedrag en de beoogde clientomvang en pas daarna het passende beperkte netwerkbeleid toe. Evenzo kan het uitschakelen van een proxy-voor-gesprekken-instelling een gesprek laten werken door het direct te versturen, wat de uitgaande route wijzigt in plaats van de via de proxy te repareren.
Documenteer succes per bewerking: berichten, mediaoverdracht en gesprekken. Een enkel werkend verzoek of een gewijzigd browser-IP toont niet aan dat elk onderdeel van een andere toepassing dezelfde proxy-uitgang deelt.