奇妙な問題があります。ほとんどの NAT で動作する C++ (boost asio) P2P アプリケーションが正常に動作しています。問題は、最初の開始ポート番号を 1000 として指定すると、1000 が空いているかどうかがチェックされ、そうでない場合は 1 ずつインクリメントされ、ポートが選択されてハンドシェイクが開始されます。しかし、10000、20000、またはその他の巨大なポート番号がある場合、ポート制限されたコーン NAT ではホール パンチが機能しません。
そんなことがあるものか？コードとは何の関係もないと確信しています。最近では、私の友人のフル コーン NAT の 1 つでも機能しませんが、他の多くのフル コーン NAT では機能しています。その理由は何ですか？NAT がどのように動作するかについて、私が見逃しているものはありますか?
多くの NAT 実装では、ここで説明されているように、1 つのホストが WAN インターフェース上のポートの大部分を占有することを防止する保護ルールが用意されています。
ルーターによっては、NAT テーブル エントリの有効期間が異なり、1 つのクライアントに割り当てることができるポートの数には常に制限があります (128 から 4096 までの数字を見てきました)。
したがって、ハイポートを使用する必要があるポイントに到達すると、ソースIPアドレスのNATテーブルは、古い接続または他のアプリからの接続からのエントリですでにいっぱい（またはほぼいっぱい）になっていると思います。したがって、ルーターは次のいずれかを決定します拒否するか、ポートの新しい NAT エントリに適合しません。
ただし、確かに、NAT の両側で Wireshark ダンプを収集し、パケットを分析する制御された環境でそれを繰り返してみます。可能であれば、ルーターのログを有効にしてそれらをのぞき見することも役に立ちます。
これが「魔法の弾丸」ではないことは理解していますが、何らかの形で役立つことを願っています.
これが役立つかどうかはわかりませんが、クライアント アプリケーションの 1 つのインスタンスを 1001 から開始し、もう 1 つのインスタンスを 1000 から開始して、両方を 1 ずつ増やしてみました。
1000 はクライアント B で失敗しますが、クライアント A はすでに 1001 を試してその穴を開けたので、うまくいくと思いますよね? 理論的には、私の頭の中では問題ないように聞こえます。