35

ソフトウェアに穴あけ機能を実装しようとしています。重要なのは、ユーザーと通信するために、すでに作成されたTCPサーバーを使用してこれを実装しているということです。

これが私がこれまでに持っているものです:

  • 「A」はUDPサーバー「US」(ポート9333)にメッセージを送信します
  • 「US」は、接続したポートを「A」に送り返します(ポート31000-ローカルポート31005)
  • 「A」はTCPサーバー「TS」にメッセージを送信し、Bに接続したい(そしてポート31000を指定したい)ことを伝えます。
  • 「TS」は「B」にメッセージを送信し、「A」のポート(31000)とIPを通知します。
  • 「B」は「US」にメッセージを送信します(ポート9333)
  • 「US」は「B」にメッセージを送信して、ポート45000(ローカルポート45005)を通知します。
  • 「B」は「TS」にメッセージを送信し、udpポート(45000)を提供します。
  • 「TS」は「A」にメッセージを送信し、Bのudpポート(45000)とIPを通知します
  • 「A」は、ポート45000でBのIPにudpメッセージの送信を開始し、ローカルポート31005でリッスンします。
  • 「B」は、ポート31000でAのIPにudpメッセージの送信を開始し、ローカルポート45005でリッスンします。

もちろん、ポート31000、31005、45000、45005はここにあります。たとえば、新しい接続ごとにポートが変更され、9333のみが静的になります。

本来あるべき以上に、何度も行き来していることを私は知っています。事実、私はTCPサーバーを使用して両方のユーザーと通信する必要があります。udpサーバーは、ユーザーのポートを自分自身に返し、TCPサーバーに送り返すことができるようにするためにここにあります。

ただし、ユーザー間のメッセージは誰にも受信されません...誰もが理由を知っているでしょうか?


編集 :

http://nattest.net.in.tum.de/test.phpを使用してルーターをテストしましたが、UDPホールパンチングは正常に機能するため、問題はルーターからではなく、プロトコルから発生しています...

ユーザーが同じNATの背後にいる場合、すべてが正常に機能します。もちろん、privates ipを使用しますが、コードも機能していることを意味するため、プロトコルの問題が発生します...


編集2:

実際、私はそれを半分機能させました(そして、問題はプロトコルではなく、実際に私のコードから来ていました...私は2人のユーザーを接続しました。

面白いことに(それほど多くはありませんが)、両方のユーザー間でデータを送受信できたのは1つのソケットだけでした。(iphoneによって開始されたソケット)プロトコルによれば、2つの適切に接続されたソケットが必要ですが、間違っていますか?

そのため、NATに穴を開けることができましたが、実際にはセルラーNATには穴を開けませんでした。

もちろん、私は3Gで接続された2台のiPhoneをすぐにテストしました。そして、誰も他からのメッセージを受け取りません。

セルラーNATについて何か見逃しましたか?

PS:質問を更新して申し訳ありませんが、答えが得られないので、自分で見つけようとしています...

PS 2:NATに穴を開けることができたので、「on3G」を追加してタイトルを変更しました


編集3:iphoneの3G接続を介してインターネットに接続されたコンピューターでhttp://nattest.net.in.tum.de/test.phpテストを再度実行しました。

結果は次のとおりです。 UDPホールパンチングの結果

どうやらすべてのUDPホールパンチングテストは9番目のテストで成功しました。

さらにそれはそうです:

UDPバインディングテスト(?):エンドポイントに依存しないバインディング、ポート予測は簡単

したがって、3G接続を介して2つのピアを接続するのに問題はないはずです(「ホーム」NATの背後にあるほどではありません)...私は正しいですか?


編集4:

念のため、2つの異なるUDPサーバーにメッセージを送信して、ポートとローカルポートが3Gで同じかどうかを確認します。

簡単に言うと、両方のサーバーで接続する場合、ポート(ローカルとパブリック)は同じです。したがって、EDIT 2で行われたテストは正しく、udpはエンドポイントに依存しないため、ホールパンチングを実行しても問題はないはずです...(少なくとも私のISPでは)

4

2 に答える 2

18

残念ながら、UDPでNATホールパンチングを実行する100%信頼できる方法はありません。せいぜい、NATとファイアウォールがほとんどの場合どのように動作するかについて推測することができます。ただし、例外は常にあり、まれではない場合があります。

この場合、中央サーバーを使用して2つのピアがお互いの外部ポートを把握し、お互いにデータの送信を開始しているように見えます。これはかなり良いアルゴリズムです。問題は、宛先によって外部ポートのルーティングが異なる場合があることです。つまり、AからBの外部ポートが5000の場合、AからCも5000から来るという保証はありません。したがって、中央サーバーにポートを記録させると、他の人との接続に役立たない場合があります。

ここにいくつかの関連する質問といくつかの詳細があります。

于 2012-09-12T16:50:25.377 に答える
8

背後にあるNATは対称的であるか、宛先に応じて送信ポート番号を変更します。対称NATを介したホールパンチングには、別の方法(TURNまたはUDPマルチホールパンチング)が必要です。次のようにしてみてください:https ://drive.google.com/file/d/0B1IimJ20gG0SY2NvaE4wRVVMbG8/view?usp = Sharing

于 2015-08-14T17:11:52.333 に答える