SOCKS プロキシはメッセージを読み込めても通話では失敗する

テキストメッセージは SOCKS プロキシ経由で届きますが、音声通話はまったく接続されません。プロキシが完全に壊れているとは限りません。アプリケーションが通話に別のトランスポートを使っている可能性があります。

TCP リクエストの成功は、その操作に対する TCP 経路を証明します。SOCKS5 は UDP アソシエーション も定義していますが、クライアント、SOCKS サービス、ネットワークルール、アプリケーション設定のすべてが想定する UDP 経路をサポートしている必要があります。

TCP リスナーだけではない

Dante のマニュアルはプロトコルルールとコマンドルールを分けており、connect、udpassociate、udpreply などがあります。すでにテストした TCP 接続だけを許可するルールでは、必要な UDP 権限は確立されません。

UDP アソシエーションにはリレーエンドポイントと戻りトラフィックも関わります。ファイアウォールとアドレス変換がその実際の経路を許可しなければなりません。SOCKS の TCP リスナーを開くことは、その UDP リレーを到達可能にすることと同じではありません。

アプリケーションの現在のプロキシのドキュメントと設定を確認してください。バージョンによってメッセージ、メディア、通話の扱いが異なる場合があります。古いクライアント向けのフォーラムのレシピを、現在のすべてのクライアントが通話を SOCKS 経由でルーティングする証拠として提示すべきではありません。

最初の診断としてすべての UDP ポートを開くことは避けてください。リレーの挙動と想定するクライアント範囲を特定し、適切な制限付きネットワークポリシーを適用します。同様に、通話用プロキシ設定を無効にすると通話を直接送信して動作させることがありますが、これはプロキシ経由の経路を修復するのではなく外向きの経路を変えることになります。

操作ごとに成功を記録してください。メッセージ、メディア転送、通話です。ひとつの成功したリクエストやブラウザ IP の変化だけでは、別のアプリケーションのあらゆる部分が同じプロキシ出口を共有していることを証明できません。