A と B の 2 つのピアがあり、Symmetric NAT を介して WebRTC ピア接続を確立しようとしているとします。彼らはシグナリングを介してICE候補を交換しました。
A のパブリック アドレス: IP_A : Port_A
B のパブリック アドレス: IP_B : Port_B
まず、A は B IP_A : Port_A ---> IP_B : Port_Bに接続しようとします。
ただし、要求は B の NAT によって拒否されます。B の STUN サーバーだけがそのアドレスで B に接続できます。
次はBさんの番です。
IP_B : Port_B ---> IP_A : Port_A
しかし、ここで、接続を確立する必要がありますか? ピア A の NAT テーブルは、A が最初に B に要求を送信したときにピア B のアドレスを登録している必要があるためです。したがって、B からの応答はすべて受け入れられる必要があります。しかし、もちろん、それはうまくいかないようです。それで、どこが間違っているのですか？
マッピング/フィルタリングの観点から考えると、より理にかなっています。他の NAT 用語では、物事が実際にどのように機能するかをうまく説明できません。私の答えはRFC 4787とWebRTC for the Curious から来ています: 接続中
マッピングは、NAT がアウトバウンド パケットに IP/ポートを割り当てるときです。リモート ピアは、このマッピングにトラフィックを送信できます。フィルタリングは、誰がこれらのマッピングを使用できるかに関するルールです。
フィルタリングとマッピングは、アドレスに依存することも、独立することもできます。マッピングがアドレスに依存している場合、新しい IP/ポートに接続するたびに新しいマッピングが作成されることを意味します。マッピングがアドレスに依存しない場合、トラフィックの送信先に関係なく再利用されることを意味します。これらと同じルールがフィルタリングに適用されます。
元の質問には、アドレス依存のマッピング + フィルタリングが問題を引き起こしているようです!
あなたが説明したセットアップで物事がうまくいくことを期待しています。WebRTCにはPeer Reflexive Candidates. WebRTC は、ICE 接続チェック中に新しい候補を発見できます。ICE は認証されているため、交換されていない IP/ポートからのトラフィックを受け入れることができます。必要なのは、ICE ユーザーフラグメントとパスワードが期待どおりであることをアサートすることだけです。