特定のネットワーク インターフェイスが背後にある NAT のタイプ (フルコーン、制限付きコーン、ポート制限付きコーン、対称) を発見したいと考えています。
さまざまなツール ( http://freshmeat.net/projects/jstun/、http://code.google.com/p/boogu/ ) をテストしましたが、同じインターフェイスに対して異なる結果が報告されています。
Python（または他の言語、他に何も利用できない場合はJavaが2番目の選択肢）で決定的な答えを探しています。
@S.Lott からの回答を支持します。STUN (またはその他のプロトコル) を使用して、背後にある NAT のタイプを 100% 確実に判断することはできません。
問題は (私が最近目撃したように)、NAT がアドレス依存(対称)として機能することもあれば、エンドポイント非依存(フル、制限、またはポート制限コーン) として機能することもあります。
考えてみると、アドレス依存であることは、NAT の背後にあるクライアントの 1 つのソケットから 2 つの異なるサーバーにパケットを送信すると、NAT が各サーバーに対して 2 つのカスタム public address:port タプルを作成することを意味します。私の場合、これらのバインディングは完全にランダムに見えましたが、範囲が小さい場合、これらのタプルが実際に等しいことが時々ありました! これはテストを混乱させました。
私は当時このライブラリを使用していましたが、NAT の動作はアドレス依存であり、エンドポイントに依存しない場合もありました (2 つの間の切り替えも完全にランダムに見え、デバイスの再起動後に発生することもあれば、再起動後に発生することもあります)。期間、...）。
これは、主にDeutsche Telekomが所有するSlovak Telekomのモバイル デバイスで発生したため、問題は少なくともヨーロッパ全体に及ぶと思います。
ここでのルールは次のとおりです。STUN テストで対称 NAT の背後にいることがわかった場合はそうではありませんが、そうでないことがわかった場合は 100% 確実ではありません。
最後に、TCP に関する NAT の動作を確認する簡単な方法は、Google に「私の IP アドレスは何ですか」と入力してから、最初の (たとえば) 5 ページを開くことです。ページがIP アドレスに関して一貫していない場合、 NAT の動作はアドレス依存またはアドレスとポート依存 (対称) になります。しかし、繰り返しになりますが、それらが対応している場合は、確信が持てません。
http://en.wikipedia.org/wiki/STUN
NAT デバイスは、多数の異なるタイプのアドレスおよびポート マッピング スキームで実装されます。STUN はそれらすべてで正しく動作しません。
それは十分に決定的ですか？これはウィキペディアの引用にすぎませんが、これを見ると、あなたの要求は物理的に不可能のようです。
@S.Lott が言うように、STUN は最初に選択するプロトコルです。
そして、STUN は単なるプロトコルです。私のアドバイスは次のとおりです。
1 STUNには現在 2 つのバージョンがあります。古いバージョンはRFC3489 です。 これは、アプリケーションがそれらとパブリック インターネットの間の NAT とファイアウォールの存在とタイプを検出できるようにする軽量プロトコルです (したがって、主に NAT タイプの検出のみを目的としています)。新しいバージョンはRFC5389です。これは、NAT トラバーサルを扱う他のプロトコル用のツールです。
2 また、 TURN RFC5766という名前の STUN へのリレー拡張もあります。TURN により、ホストはリレーの動作を制御し、リレーを使用してピアとパケットを交換できます。TURN は、クライアントが単一のリレー アドレスを使用して複数のピアと通信できるようにするという点で、他のいくつかのリレー制御プロトコルとは異なります。
道具：
STUN クライアント (RFC3489) : pystun By python
TURN サーバー (RFC5766) : turnserver c によって
注: TURN は新しいバージョンの STUN の拡張であるため、TURN サーバーは RFC5389 による新しい STUN 要求もサポートします。