TURN

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
TCP/IP群
アプリケーション層

BGP / DHCP / DNS / FTP / HTTP / IMAP / IRC / LDAP / MGCP / NNTP / NTP / POP / RIP / RPC / RTP / SIP / SMTP / SNMP / SSH / Telnet / TFTP / TLS/SSL / XMPP

カテゴリ
トランスポート層

TCP / UDP / DCCP / SCTP / RSVP

カテゴリ
ネットワーク層

IP (IPv4IPv6) / ICMP / ICMPv6 / NDP / IGMP / IPsec

カテゴリ
リンク層

ARP / OSPF / SPB / トンネリング (L2TP) / PPP / MAC (イーサネットIEEE 802.11DSLISDN

カテゴリ

TURN(Traversal Using Relay aroud NAT)とは、マルチメディアアプリケーションがNATファイアーウォールを超えて通信することを補助するためのインターネットプロトコルである。TURNは、TCP,UDPを使って対象型NAT(Symmetric NAT)装置により隠蔽(マスカレード)されたプライベートネットワークに接続されたクライアントを利用する場合に最も役立つ手段である。一方、NATの背後におかれたwell-knownポートを使って動作するサーバに接続する目的には役立たない。TURNはNATの背後にあるシングルピアのユーザ、例えばIP電話、に接続する際に役立つものである。

TURNはRFC 5766で標準化されており、IPv6用のアップデートはRFC 6156である。TURNが使うURIスキームはRFC 7065に記述されている。

概略[編集]

NAT(Network Address Translators)には多くのメリットがある一方で、多くの欠点も持っている。 それらの欠点の中で最も厄介なものは、NATが多くの現存するIPアプリケーションに弊害をもたらし、また新規にIPアプリケーションを展開することを難しくしていることである。 どのようにしてNATと親和的な通信規約を作るかを記述したガイドラインが開発されてきた。 しかし、多くの通信規約はそれらのガイドラインにしたがってはどうしても構築することができなかった。そういった構築できなかった通信規約の例としてはマルチメディアアプリケーションやファイル共有関連の通信規約がある。

STUN(Session Traversal Utilities for NAT)は、アプリケーションがNATを越えるための1つの方法を提供する。 STUNはクライアントがピアからのパケットを受信するために利用するトランスポートアドレス(IPアドレスとポート)を入手することを可能にする。 しかしながら、STUNによって入手されたアドレスはすべてのピアに対して利用可能ではないかもしれない。それらのアドレスは、ネットワークのトポロジー的状況に依存して機能する。そのため、STUNはそれ自身ではNAT超えについて完全な解決を提供することはできない。

完全な解決には、インターネットへパケットを送信することができるあらゆるピアから、クライアントがメディアを受けることができるトランスポートアドレスを入手できることが必要である。 これは、インターネット上に存在するサーバを通過したデータに頼ることによってのみ達成することができる。 この仕様はTURN、つまり上記のようなサーバを通過したデータからのIPアドレスやポートをクライアントが獲得することを可能にする通信規格を記述している。

TURNはほとんどの場合にクライアントに接続性を提供するが、それはTURNサーバの提供者にとって高いコストがかかる。 それゆえ、STUNなどの他の手段が利用可能な場合はそちらを利用し、TURNを最終手段として利用することが望ましい。 この方法を達成するために、ICE(Interactive Connectivity Establishment)という方法は、接続性の最適な方法を発見するために使うことができる。

プロトコル[編集]

データ転送のためにクライアントコンピュータが宛先のコンピュータに通信するとき、クライアントと宛先の双方がそれぞれNATの背後にいて、通信ができないという状況が始まりである。対称型NAT(STUNと互換性のないNATタイプ)の場合、TURNを用いなければならない。

最初、クライアントはTURNサーバに「割り当て(Allocate)」要求を出す。割り当て要求とは、クライアントが宛先に通信するためにTURNサー バにリソースを割り当てることを依頼するものである。もし割り当てが可能ならば、TURNサーバはリレー用のアドレスを割り当てたうえで、クライアントに対し「Allocation Successful」レスポンスを返す。このレスポンスの中にはリレー用にTURNサーバに割り当てたトランスポートアドレスが入っている。

次に、クライアントはTURNサーバに対し、CreatePermission要求を出し、宛先とTURNサーバ間の通信のための認証システムを作ることを要求する。このチェックシステムは、サーバが宛先に通信使、宛先からリレーのためにTURNサーバに送り返してきた情報が、正当な通信であることを確認するために用いる。

通信が許可された後、クライアントには実際のデータを送るにあたって、2つの選択肢がある。

(1)Send機構を使う。

(2)ChannelBind要求を出し、チャネルを確保する。

Send機構は直接的な方法であるが、36バイトと大きなヘッダを必要とし、TURNによるリレー通信のためのバンド幅を無視できない程度に増加させてしまう。これに対し、ChannelBindによる手法は軽量であり、ヘッダは4バイトのみであるしかし、チャネルを確保しておく必要があり、そのために定期的にリフレッシュが必要である。

SendまたはChannelBindのどちらの手法を使うにせよ、TURNサーバはクライアントからデータを受け取り、UDPデータグラムを使って宛先に転送する。データの中にはソースアドレスとして、割り当てられた転送用トランスポートアドレスが含まれている。 宛先はデータを受け取り、再びUDPデータグラムを転送プロトコルとして用いてTURNサーバのリレー用アドレスに送る。

TURNサーバは宛先からUDPデータグラムを受け取り、認証をチェックしもし正当であれば、これをクライアントに送る。

この方法により、対称型NATの問題を回避することができる。クライアントと宛先の双方とも転送用に割り当てたIPアドレスを持つTURNサーバに対してだけ通信を行えばよいためである。

様々なNATを超えた通信ができるという意味で、TURNはSTUNよりも堅牢であるがTURN では全通信がTURNサーバを経由するため、STUNプロトコルよりもサーバに必要なバンド幅が大きい。そのため、ICEプロトコルにおいては、まず最初 にSTUNを採用することが必須条件であり、TURNは対称型NATやその他のSTUNでは解決できない状況を解決するために用いられる。

参照[編集]

外部リンク[編集]

(すべて英文)

実装[編集]

  • Numb is a free STUN/TURN server.
  • TurnServer - OpenSource TURN server.