Textnachrichten kommen über einen SOCKS-Proxy an, doch ein Sprachanruf kommt nie zustande. Der Proxy ist deshalb nicht unbedingt völlig defekt. Die Anwendung nutzt für Anrufe möglicherweise einen anderen Transport.

Eine erfolgreiche TCP-Anfrage belegt einen TCP-Pfad für diesen Vorgang. SOCKS5 definiert außerdem UDP-Assoziation, doch Client, SOCKS-Dienst, Netzwerkregeln und Anwendungseinstellungen müssen den vorgesehenen UDP-Pfad alle unterstützen.

Es gibt mehr als einen TCP-Listener

Das Dante-Handbuch trennt Protokoll- und Kommandoregeln, darunter connect, udpassociate und udpreply. Eine Regel, die nur die bereits getestete TCP-Verbindung erlaubt, schafft nicht die erforderlichen UDP-Berechtigungen.

Eine UDP-Assoziation umfasst auch einen Relay-Endpunkt und Rückverkehr. Firewalls und Adressübersetzung müssen genau diesen Pfad zulassen. Den TCP-Listener von SOCKS zu öffnen ist nicht dasselbe, wie dessen UDP-Relay erreichbar zu machen.

Prüfen Sie die aktuelle Proxy-Dokumentation und die Einstellungen der Anwendung. Verschiedene Versionen können Nachrichten, Medien und Anrufe unterschiedlich behandeln. Ein Forenrezept für einen alten Client sollte nicht als Beleg dafür dienen, dass jeder heutige Client Anrufe über SOCKS leitet.

Vermeiden Sie es, als erste Diagnose alle UDP-Ports zu öffnen. Bestimmen Sie das Relay-Verhalten und den vorgesehenen Clientumfang und wenden Sie dann die passende eingeschränkte Netzwerkrichtlinie an. Ebenso kann das Abschalten einer Proxy-für-Anrufe-Einstellung einen Anruf zum Laufen bringen, indem er direkt gesendet wird, was die nach außen gehende Route ändert, statt die über den Proxy zu reparieren.

Dokumentieren Sie den Erfolg je Vorgang: Nachrichten, Medienübertragung und Anrufe. Eine einzelne funktionierende Anfrage oder eine geänderte Browser-IP belegt nicht, dass jeder Teil einer anderen Anwendung denselben Proxy-Ausgang nutzt.

Ähnliche Artikel