2016-12-03 12 views
0

私はWebRTCについて読んでおり、どのようにしてpeer to peerの通信を可能にしています。だから、私はNAT横断の実験をしました。NATトラバーサル実験?

NATで穴あけをテストすることでした。私は2つのシステムが両方とも実行していたUbuntu 16.04でした。私はこれらのシステムをsystem Asystem Bと呼んでいます。

両方のシステムは、Amazon Web Servicesでホストされているサーバーに接続します。システムAはコマンドnc -p 1234 -u IP_ADDRESS_OF_SERVER PORT_NUMBER_OF_SERVERを使用し、システムBはコマンドnc -p 1235 -u IP_ADDRESS_OF_SERVER PORT_NUMBER_OF_SERVERを使用しました。システムAとシステムBの両方が同じWiFiルーターに接続されていました。

サーバーに接続したら、両方のシステムの約public socketを知る必要があります。その後、私は数秒以内にサーバーから取得したパブリックソケットの情報を使ってお互いを接続しようとしました。

システムAはサーバから切断し、コマンドnc -u -p 1234 PUBLIC_IP_OF_SYS_B PUBLIC_PORT_OF_SYS_Bを使用してシステムBに接続し、システムBもサーバから切断し、コマンドnc -u -p 1235 PUBLIC_IP_OF_SYS_A PUBLIC_PORT_OF_SYS_Aを使用してシステムAに接続します。

NATで穴を開けるためにこれを行いました。その後、システムAは上記のncコマンドをキャンセルし、nc -l -u -p 1234を使用してポートをリッスンします。しかし残念ながら、システムAのシステムBでタイプされたメッセージを受け取ることができませんでした。

誰でもこの仕事を手伝ってもらえますか?

+0

WebRTCサービスを実行して何が起こるかを知ることができれば、なぜこのような問題が発生するのか不明です。 https://appear.inまたはhttps://talky.ioをお試しください。彼らがうまくいけば、NATトラバーサルが動作します(またはNATがあなたを妨害することはありません)。 –

+1

@abhiarora - すばらしいことに、もっと頑張ってください。 –

+0

@Am_I_Helpful - 以前に試しましたか? 何か提案できますか? – abhiarora

答えて

1

私はそれを自分で見つけます。私がやろうとしていたことはHairpin Translationと呼ばれ、ヘアピンの翻訳は(穿孔パンチ翻訳と比較して)既存のNAT間ではあまり一般的ではありません。

2つのシステムは同じNATの背後に存在するため、同じプライベートIPアドレス領域に配置されます。 System Aは、サーバSとのUDPセッションを確立しています。このセッションには、共通NATが独自のパブリックポート番号(たとえば、x)を割り当てています。 System Bは、同様に、Sとのセッションを確立しました。このセッションには、NATがパブリックポート番号(yなど)を割り当てています。

system Aが、サーバーSをイントロデューサとして使用して、BでUDPセッションを確立するためにホールパンチング技術を使用するとします。 System Aは、Bに接続を要求するメッセージをSに送信します.Sは、BのパブリックエンドポイントとプライベートエンドポイントでAに応答し、AのパブリックエンドポイントとプライベートエンドポイントをBに転送します。両方のクライアントは、 。 NATがヘアピン変換をサポートしていないため、パブリックエンドポイントに向けられたメッセージは宛先に届きません。

誰でもヘアピンについてhereを読むことができます。