2

ファイアウォールの背後にあるサーバーで TURN サーバー (http://tools.ietf.org/html/rfc5766) を実行しています。マシンにはパブリック IP アドレスがあり、サーバーのプライベート IP アドレスとの間で送受信されるネットワーク パケットが送受信されます。基本的に、サーバーはソケットをパブリック IP アドレスにバインドできず、プライベート IP アドレスのみにバインドできます。Runningifconfigは、プライベート IP アドレスを持つネットワーク デバイスを示します。

TURN サーバーを実行するときは、プライベート IP アドレスにバインドする必要があります (サーバーはパブリック インターネットに接続されているとは見なさないため)。割り当ての作成に対するすべての応答は、プライベート IP アドレスを含む XOR-RELAYED-ADDRESS を返します。クライアントは XOR-RELAYED-ADDRESS を受信し、サーバーのプライベート IP アドレスにデータを送信しますが、明らかに失敗します。

これを克服するために私が検討している2つのオプションがあります。

  • クライアント コードで XOR-RELAYED-ADDRESS の IP アドレスを無視し、XOR-RELAYED-ADDRESS のポートのみを使用するようにします。クライアントは、中継されたすべてのメッセージを TURN サーバーのパブリック IP (クライアントはこの値を事前に知っているため) および XOR-RELAYED-ADDRESS ポートに送信します。
  • サーバーを変更してパブリック IP を認識し (ソケットをバインドできない場合でも)、XOR-RELAYED-ADDRESS 応答で常にパブリック IP を返信します。

最初の方法はTURN RFCを破っているように感じます... TURNサーバーがXOR-RELAYED-ADDRESSのIPをTURNサーバーのパブリックIP以外のものとして送り返す状況を想像することはできませんが、RFCは言いますXOR-RELAYED-ADDRESS は、クライアントがデータを送信する必要があるものです。

2番目の方法はRFCをあまり壊していないように感じます...それが理にかなっていれば。さらに、この方法ではクライアントに特別なことを強制することはありませんが、最初の方法ではすべてのクライアントが上記に従う必要があります。

これについてあなたはどう思いますか？誰かがこれを経験したことがありますか、および/またはどの方法がRFCをあまり壊さないか、またはRFCがいずれかの方法によって違反されているかどうかについて意見がありますか?

4

1 に答える 1

4

Amazon EC2 でSTUN サーバー コードを実行すると、ほぼ同じ問題が発生します。stun サーバーからクライアントに返される起点アドレスと代替アドレスは、NAT された IP アドレスです。

私が考えたいくつかの解決策：

  1. クライアントが実際に追加の NAT タイプ検出テストを実行したい場合は、代替 IP アドレスを知るようにクライアントが事前に構成されていると想定してください。これは、STUN について行うのに悪い仮定ではありません。結局のところ、スタン サービスのプライマリ IP アドレスを知っている必要があります。

  2. コマンド ラインまたは構成ファイルからマップされた IP アドレスが渡されるようにサーバー コードを変更します。これは、上記の 2 番目の方法と同等です。これを自動化するために、起動時にサーバーにWebリクエストを介して独自の外部IPアドレスを自己検出させる（または別のスタンサーバーをテストする）ことができます。

あなたの最初の提案 - クライアントは IP マッピングを認識しています - は、自分以外のクライアントと相互運用しようとしていないとすれば、まったく問題ありません。しかし、他の誰かのクライアント スタックを使用する必要があると思われる場合、このオプションはあまり望ましくありません。ハイブリッド アプローチを実行できます。クライアントが「リレー IP を無視し、ポートが正しいと仮定する」ことを意味する TURN 割り当て応答の新しいカスタム属性を発明します。これは問題ありませんが、あまり良くありません。

あなたの 2 番目の提案は、上記の私の #2 に沿ったものです。もう1つ考えるべきことがあります。クライアントも TURN サーバーと同じファイアウォールの背後にある場合はどうなりますか? 内部アドレスと外部アドレスのどちらが必要ですか? 繰り返しになりますが、両方のクライアントが同じファイアウォールの背後にある場合、通信に TURN は必要ない可能性があります。もう 1 つの問題は、正しい IP アドレスをサーバーに渡すための管理オーバーヘッドです。

私はあなたの 2 番目の提案が好きです。

BEHAVE IETF 電子メール ディスカッション グループに質問を投稿することを検討してください。彼らは、STUN と TURN の仕様を起草した公開委員会です。NAT の背後で実行されるクラウド内のサーバーがますます一般的になっていることを、彼らは認識する必要があると思います。アドバイスがあるかもしれません。このメールをあなたと共同で作成することに非常に興味があります。または、少なくとも彼らの反応を読んでください。

于 2012-07-22T07:30:15.630 に答える