スタン

STUN ( Session Traversal Utilities for NAT、元々はSimple Traversal of User Datagram Protocol (UDP) through Network Address Translators ) は、リアルタイムの音声、ビデオ、メッセージング、およびその他のインタラクティブ通信のアプリケーションで ネットワーク アドレス変換 (NAT) ゲートウェイを通過するための、ネットワーク プロトコルを含む標準化された一連の方法です。

STUN は、 Interactive Connectivity Establishment (ICE)、Session Initiation Protocol (SIP)、WebRTCなどの他のプロトコルで使用されるツールです。ホストがネットワーク アドレス トランスレータの存在を検出し、 NAT がリモート ホストへのアプリケーションのユーザーデータグラム プロトコル(UDP) フローに割り当てた、マッピングされた (通常はパブリックの)インターネット プロトコル(IP) アドレスとポート番号を検出するためのツールを提供します。このプロトコルでは、NAT の反対側 (パブリック) 側 (通常はパブリックインターネット) にあるサードパーティ ネットワーク サーバー (STUN サーバー) のサポートが必要です。

STUNはRFC 3489で初めて発表されました。^[1] RFC 5389として公開された更新された一連のメソッドの仕様では、同じ頭字語を保持したままタイトルが変更されました。^[2]

STUN は、RFC 3489 で初めて発表されました。^[1]元の仕様では、アドレスとポートのマッピング動作に応じて NAT の動作を特徴付けるアルゴリズムが指定されていました。このアルゴリズムは確実に成功するわけではなく、展開されている NAT デバイスのサブセットにのみ適用できます。このアルゴリズムは、アプリケーションによって実行される一連のテストで構成されています。図のパスが赤いボックスで終わる場合、UDP 通信は不可能であり、パスが黄色または緑のボックスで終わる場合、通信は可能です。RFC 3489 の方法は、実稼働ネットワークで発生する多種多様な NAT 実装とアプリケーション シナリオに対処するには信頼性が低すぎることが判明しました。STUN プロトコルと方法は、RFC 5389 で更新され、元の仕様の多くを方法のサブセットとして保持しながら、他の仕様は削除されました。

RFC 5389として公開された更新された一連のメソッドの仕様では、同じ頭字語を保持したままタイトルが変更されました。^[2]

STUN は、通信プロトコルが 2 つの通信エンドポイント間のパスにあるネットワーク アドレス トランスレータを検出して通過するためのツールです。これは軽量のクライアント サーバープロトコルとして実装されており、一般的な簡単にアクセスできるネットワーク (通常はインターネット) にあるサード パーティ サーバーとの単純なクエリと応答コンポーネントのみを必要とします。クライアント側は、VoIP ( Voice over Internet Protocol ) 電話やインスタント メッセージング クライアントなどのユーザーの通信アプリケーションに実装されます。

基本プロトコルは、基本的に次のように動作します。通常、プライベート ネットワーク内で動作するクライアントは、パブリック インターネット上の STUN サーバーにバインディング要求を送信します。STUN サーバーは、サーバーの観点から観察されたクライアントのIP アドレスとポート番号を含む成功応答で応答します。結果は、排他的論理和(XOR) マッピングによって難読化され、代替の NAT トラバーサル メソッドを実行するためにディープパケット インスペクションを実行するアプリケーション層ゲートウェイ (ALG) によるパケット コンテンツの変換を回避します。

STUN メッセージは、ユーザー データグラム プロトコル(UDP) パケットで送信されます。UDP は信頼性の高い転送を提供しないため、信頼性は、アプリケーション制御による STUN 要求の再送信によって実現されます。STUN サーバーは、応答に対して信頼性メカニズムを実装していません。^{[2]信頼性が必須の場合、伝送制御プロトコル (TCP) を使用できますが、余分なネットワーク オーバーヘッドが発生します。セキュリティに敏感なアプリケーションでは、STUN は}トランスポート層セキュリティ(TLS)によって転送および暗号化される場合があります。

アプリケーションは、ドメイン ネーム システム(DNS) にstun (UDP の場合) またはstuns (TCP/TLS の場合) サーバー ( SRV ) リソース レコード (例: _stun._udp.example.com) を照会することで、特定のピアとの通信に適した STUN サーバーを自動的に決定できます。STUN サーバーの標準リスニング ポート番号は、UDP と TCP の場合は 3478、TLS の場合は 5349 です。または、サーバーの実装が TLS と STUN パケットをデマルチプレックスできる場合は、TLS を TCP ポートで実行することもできます。DNS ルックアップを使用して STUN サーバーが見つからない場合は、標準では、宛先ドメイン名でアドレス レコード (A または AAAA) を照会し、デフォルトのポート番号で使用することを推奨しています。^[2]

STUN には、TLS によるプロトコル暗号化の使用に加えて、特殊な STUN パケット タイプを介した認証およびメッセージ整合性メカニズムも組み込まれています。

クライアントが外部アドレスを評価すると、パブリック ネットワーク上のピアからは到達できないプライベート アドレスではなく、外部 NAT アドレスを共有することで、これをピアとの通信の候補として使用できます。

通信中の両方のピアがそれぞれ NAT の背後にある異なるプライベート ネットワークにある場合、ピアは調整してピア間の最適な通信パスを決定する必要があります。NAT の動作によっては、パブリック バインディングが既知であってもピアの接続が制限される場合があります。Interactive Connectivity Establishment (ICE) プロトコルは、2 つのピア間の最適な通信パスを決定するための構造化されたメカニズムを提供します。Session Initiation Protocol (SIP) 拡張機能は、2 つのホスト間の通話を設定するときに ICE を使用できるように定義されています。

ネットワーク アドレス変換は、さまざまなアドレスおよびポート マッピング スキームを介して実装されますが、そのいずれも標準化されていません。

STUN は、すべてのNAT展開シナリオに適用できる自己完結型の NAT トラバーサル ソリューションではなく、すべての NAT 展開シナリオで正しく動作するわけではありません。これは、他の方法の 1 つであるツールであり、NAT トラバーサル、特にTraversal Using Relay NAT (TURN) とInteractive Connectivity Establishment (ICE) を扱う他のプロトコル用のツールです。

STUN は、フル コーン NAT、制限付きコーン NAT、ポート制限付きコーン NATの 3 種類の NAT で動作します。制限付きコーン NAT またはポート制限付きコーン NAT の場合、NAT がエンドポイントからクライアントへのパケットを許可する前に、クライアントがエンドポイントにパケットを送信する必要があります。STUN は、大企業のネットワークでよく見られる対称 NAT (双方向 NAT とも呼ばれる) では動作しません。STUNサーバーのIP アドレスはエンドポイントの IP アドレスと異なるため、対称 NAT の場合、NAT マッピングは STUN サーバーとエンドポイントで異なります。対称 NAT では、 TURN の方が優れた結果をもたらします。

• ポート制御プロトコル(PCP)
• NAT ポート マッピング プロトコル(NAT-PMP)
• インターネット ゲートウェイ デバイス プロトコル(UPnP IGD)
• UDP ホールパンチング

• STUNTMAN - オープンソースのSTUNサーバーソフトウェア
• YouTubeの Yahoo VoIP STUN
• STUNT: Wayback Machineでの TCP NAT トラバーサル(2017-09-11 アーカイブ)