Un proxy SOCKS peut charger les messages mais échouer sur les appels

Les messages texte arrivent par un proxy SOCKS, mais un appel vocal ne s'établit jamais. Le proxy n'est pas forcément complètement hors service. L'application utilise peut-être un autre transport pour les appels.

Une requête TCP réussie prouve un chemin TCP pour cette opération. SOCKS5 définit aussi l'association UDP, mais le client, le service SOCKS, les règles réseau et les réglages de l'application doivent tous prendre en charge la route UDP prévue.

Il y a plus qu'un écouteur TCP

Le manuel Dante sépare les règles de protocole et de commandes, dont connect, udpassociate et udpreply. Une règle qui n'autorise que la connexion TCP déjà testée n'établit pas les autorisations UDP nécessaires.

L'association UDP implique aussi un point de terminaison de relais et du trafic de retour. Les pare-feu et la traduction d'adresses doivent autoriser ce chemin réel. Ouvrir l'écouteur TCP de SOCKS n'équivaut pas à rendre son relais UDP joignable.

Vérifiez la documentation et les réglages proxy actuels de l'application. Des versions différentes peuvent traiter différemment les messages, les médias et les appels. Une recette de forum pour un ancien client ne doit pas être présentée comme la preuve que chaque client actuel achemine les appels via SOCKS.

Évitez d'ouvrir tous les ports UDP comme premier diagnostic. Déterminez le comportement du relais et le périmètre de clients visé, puis appliquez la politique réseau restreinte appropriée. De même, désactiver un réglage de proxy pour les appels peut faire fonctionner un appel en l'envoyant directement, ce qui change la route sortante au lieu de réparer celle qui passe par le proxy.

Documentez le succès par opération : messages, transfert de médias et appels. Une seule requête qui fonctionne ou une IP de navigateur modifiée ne peuvent pas prouver que chaque partie d'une autre application partage la même sortie proxy.