NAT トラバーサルとは、一方または双方のエンドポイントがネットワークアドレス変換装置 (NAT) の内側に配置されている場合に通信を確立または維持するために使用される手法を指します。簡単に言えば、プライベートアドレス、ポート書き換え、ファイアウォールのような動作によって直接のエンドツーエンド接続が困難になったときに、アプリケーションが動作し続けるのを助ける実用的なツールキットです。
これが重要である理由は、現代の通信がフラットで公的に到達可能なネットワークで行われることは稀だからです。IP電話、ソフトフォン、WebRTCブラウザ、会議クライアント、ゲームシステム、IoTデバイス、リモートコラボレーションツールは、多くの場合、ホームルーター、エンタープライズファイアウォール、キャリアグレードNAT、またはクラウドエッジセキュリティ制御の背後に配置されています。NATトラバーサルがなければ、これらのエンドポイントの多くはトラフィックを送信できても、直接メディアやピアツーピアトラフィックを予測可能な方法で受信することは困難でしょう。
NATトラバーサルが実際に意味するもの
単一のプロトコルではない
NATトラバーサルは、単一の固定された標準ではなく、技術的なアプローチとして理解するのが最適です。一部のアプリケーションは、静的ポートフォワーディングやアプリケーション対応ゲートウェイなどの単純な方法に依存しています。その他のアプリケーションは、STUN、TURN、ICE上に構築されたより高度なフレームワークを使用して、複数のパスをテストし、最も適切なものを自動的に選択します。
この区別は重要です。エンジニアがあるアプリケーションが「NATトラバーサルをサポートしている」と言う場合、通常、そのアプリケーションが到達可能なアドレスを発見し、NATバインディングを維持し、接続性をテストし、直接通信が失敗した場合にはリレーパスにフォールバックできることを意味します。正確な組み合わせは、プロトコルスタック、ネットワークポリシー、およびNATやファイアウォール環境の制限の度合いに依存します。
NATが接続性の問題を生み出す理由
従来のNATデバイスは、内部のプライベートIPアドレスをパブリック向けアドレスに書き換えます(多くの場合、変換されたポート番号も含む)。これはパブリックIPv4アドレスを節約し、プライベートネットワークを隠すのに役立ちますが、あるエンドポイントがアプリケーションがローカルに見るアドレスを使用して常に別のエンドポイントに直接到達できるという前提も破壊します。
クライアント-サーバートラフィックの場合、クライアントがパブリックサーバーに向けて接続を開始するため、この制限はしばしば管理可能です。ピアツーピア、リアルタイムメディア、または双方向の音声・ビデオセッションの場合、問題はより困難です。ローカルエンドポイントに見えるアドレスとポートは、必ずしもNATのパブリック側で見えるものとは限らず、互換性のあるマッピングがすでに存在しない限り、着信パケットはドロップされる可能性があります。

NATトラバーサルは単純な課題から始まります。2つのエンドポイントは両方ともオンラインかもしれないが、どちらもアプリケーションが期待する方法で直接到達可能ではありません。
NATトラバーサルの仕組み
ステップ1:パブリック向けアドレスの発見
最初のタスクは多くの場合、アドレス発見です。NATの背後にあるエンドポイントは、192.168.x.xや10.x.x.xのような内部アドレスを知っていても、そのアドレスはパブリックインターネット上のピアにとって有用ではありません。発見サービスは、エンドポイントが自分の送信トラフィックに対してNATが割り当てたパブリックIPアドレスとポートマッピングを学習するのに役立ちます。
これがSTUNが非常に広く使用されている理由の一つです。STUNサーバーは観測された送信元アドレスとポートを反射して返し、クライアントに現在存在するパブリックマッピングを学習させます。そのマッピングはその後、候補パスとしてリモート側と共有できます。
ステップ2:直接通信が可能かどうかのテスト
パブリックマッピングを学習しても、自動的に成功が保証されるわけではありません。一部のNATデバイスは、特定のタイミングまたは宛先条件でのみ戻りトラフィックを許可します。その他のデバイスはポートマッピングを積極的に変更したり、未承諾の着信パケットを完全にブロックしたりします。そのため、現代のNATトラバーサルはアドレス発見で止まりません。
代わりに、エンドポイントは候補アドレスを交換し、接続性チェックを実行します。ICEはこの動作で最もよく知られたフレームワークです。ローカル候補、サーバーリフレクシブ候補、リレー候補を収集し、優先順位順にテストし、機能するパスを選択します。環境が許せば、結果は直接ピアパスになります。許さなければ、アプリケーションはリレーパスを選択することで引き続き動作できます。
ステップ3:必要に応じたトラフィックのリレー
STUNが利用可能な場合でも、直接ピアツーピアメディアには制限が強すぎるネットワーク環境もあります。エンタープライズファイアウォール、対称NAT動作、厳密に制御されたイグレスポリシーは、直接接続の安定化を妨げる可能性があります。そのような場合、リレーが信頼できるフォールバックとなります。
TURNはそのリレーモデルを提供します。両方のピアに強制的に直接接続させる代わりに、各エンドポイントはパブリックリレーサーバーにトラフィックを送信し、サーバーがパケットを転送します。これによりコスト、帯域幅消費、やや遅延が増加しますが、困難なネットワーク条件下でもアプリケーションが動作する可能性を大幅に高めます。
優れたNATトラバーサル設計は、どんな犠牲を払ってでもピアツーピアを強制することではありません。それは、接続性、メディア品質、セキュリティ、運用信頼性のバランスをとる最善の利用可能なパスを見つけることです。
NATトラバーサルの背後にある中核技術
発見とキープアライブのためのSTUN
STUN(Session Traversal Utilities for NAT)は、外部から見えるパブリックIPアドレスとポートを発見するために一般的に使用されます。また、接続性の確認やNATバインディングを維持するのにも役立ちます。これにより、特にUDPベースのリアルタイム通信において有用な構成要素となります。
同時に、STUNはそれ自体で完全な回答として扱われるべきではありません。実際の展開では、より広範なNATトラバーサル設計の一部として最適に機能します。NAT動作が厳しすぎる場合、STUN単独ではマッピングを明らかにしても安定したメディアパスを提供できない可能性があります。
リレーベース接続のためのTURN
TURN(Traversal Using Relays around NAT)は、直接接続を確立できない場合や十分に信頼できない場合に使用されます。エンドポイントはTURNサーバー上にリレーアドレスを割り当て、ピアは直接パスの確立に頼る代わりに、そのリレーを介してパケットを交換します。
運用の観点からは、TURNはしばしば、予測不能なネットワーク上でリアルタイムアプリケーションを利用可能に保つセーフティネットです。これは、ブラウザベースのWebRTCセッション、リモートビデオコラボレーション、異なるネットワーク間をローミングするモバイルユーザー、およびファイアウォールポリシーが消費者ブロードバンドNAT動作よりも制限的な環境において特に重要です。
意思決定フレームワークとしてのICE
ICE(Interactive Connectivity Establishment)はプロセスをまとめます。候補パスを収集し、優先順位を付け、チェックを実行し、実際にメディアを運ぶべきパスを指名します。そのパスは、同じネットワーク上のホスト間、NATを介したサーバーリフレクシブ、またはTURNを介したリレーベースの場合があります。
これが、現代の音声・ビデオシステムにおけるNATトラバーサルを考える上で、ICEがしばしば最も実用的な方法である理由です。一つのパスがどこでも機能すると仮定するのではなく、ICEは接続性をネゴシエーション問題として扱い、動的に解決します。
NATトラバーサルの主な特徴
エンドポイントの到達可能性の向上
NATトラバーサルの最も目に見える利点は、エンドポイントを実際の通信に十分なほど到達可能にすることです。プライベートネットワークの背後にあるデバイスは、すべてのサイトがパブリックアドレスを所有したり、複雑な手動ファイアウォールルールを維持したりする必要なく、セッションに参加できます。
これは、ユーザーがオフィス、自宅、ホテル、モバイルネットワーク、一時的なサイトから参加する分散組織において特に価値があります。NATトラバーサルは、単にデバイスが間違ったタイプのルーターやセキュリティアプライアンスの後ろにあるという理由だけで通信が失敗するケースの数を減らします。
適応的なパス選択
強力なNATトラバーサル設計は、単一のトランスポートパスに依存しません。最初に直接パスを試み、利用可能な場合は低遅延オプションを優先し、必要な場合にのみリレーにフォールバックできます。この柔軟性により、多くのセッションは効率的な直接メディアを使用でき、困難なセッションも機能し続けるため、ユーザーエクスペリエンスが向上します。
音声とビデオにとって、これは非常に重要です。メディア品質は遅延、損失、ジッターに依存します。変化するネットワーク条件に適応できるパス選択プロセスは、常にリレーを強制するか、直接接続が魔法のように機能すると仮定する単一の設計よりも通常は優れています。
リアルタイム通信のサポート
NATトラバーサルは、ライブメディアを伝送するアプリケーションにとって特に重要です。シグナリングトラフィックは多くの場合、あまり問題なくパブリックサーバーに到達できますが、RTPまたはピアメディアパスが障害の発生箇所です。NATトラバーサルは、メディアレイヤーがシグナリングレイヤーと同じくらい信頼できるようにするのに役立ちます。
これが、VoIP、SIPコラボレーション、ブラウザ通話、ソフトフォン展開、会議、エッジデバイス通信においてこの用語が頻繁に登場する理由です。これらの環境では、セッションを確立しても双方向メディアを配信できないシステムは、真に使用可能とは言えません。
NATトラバーサルの応用
VoIPおよびSIP通話
最も一般的なユースケースの一つは、SIPおよびRTP通信です。IP電話、ソフトフォン、SIPインターホン端末、リモートワーカーは多くの場合NATの背後にあり、一方、PBX、SBC、またはコラボレーションプラットフォームはデータセンターやクラウド環境にあります。NATトラバーサルは、シグナリングとメディアがそれらの間で機能するパスを見つけるのに役立ちます。
実際の展開では、これにはSIP対応エッジデバイス、セッションボーダーコントローラー、ICEサポート、RTPラッチング動作、またはリレーサービスが含まれる場合があります。目標は単純です:通話を接続させ、双方向音声を配信し、片方向音声や無音メディア障害を防ぐことです。
WebRTCとブラウザベースの会議
WebRTCは、現代のNATトラバーサルが動作している最も明確な例の一つです。ブラウザーは一般的にSTUNとTURNを備えたICEを使用するため、ユーザーは手動でポートを開けることなく、ホームネットワーク、エンタープライズネットワーク、モバイルアクセス環境から通話に参加できます。
これは、ビデオ会議、埋め込みウェブサイト通話、リモートカスタマーサポート、テレヘルス、クラウドコンタクトセンター、ブラウザベースのディスパッチツールにとって重要です。NATトラバーサルがなければ、ウェブリアルタイム通信は通常のユーザー環境でははるかに頻繁に機能しなくなります。
ゲームとピアツーピアアプリケーション
オンラインゲームやピアツーピアデータ交換プラットフォームも、エンドポイント間の低遅延直接通信を望む場合、NATトラバーサルに依存します。直接ピアパスは中央インフラの負荷を減らし、応答性を向上させることができますが、それはピアが実際にルートを発見し検証できる場合に限ります。
これが、NATトラバーサルがエンタープライズ音声・ビデオの外でも関連性を持つ理由です。エンドツーエンドトラフィックの恩恵を受けるアプリケーションは、プライベートアドレッシングとエッジ変換の現実を突破する何らかの方法を必要とする可能性があります。
リモートデバイス、IoT、およびエッジシステム
産業用ゲートウェイ、センサー、監視デバイス、アクセス端末、スマート家電は、プラットフォームオペレーターが完全に制御できないルーターの背後に展開されることがよくあります。NATトラバーサルは、クラウドサービスがテレメトリ、通知、診断、限定的なピア通信のための到達可能性を維持するのに役立ちます。
これらの場合、設計はより保守的でなければなりません。アプリケーションは既知のプラットフォームへの安全な発信登録を優先し、デバイスを未承諾の着信インターネットトラフィックに広くさらすことなくセッション継続性を維持するためにNAT対応技術を使用する場合があります。

NATトラバーサルは、IP電話やWebRTCからゲームや接続されたエッジデバイスまで、エンドポイントがプライベートネットワークを介して通信する必要があるあらゆる場所で登場します。
展開に関する考慮事項
セキュリティは後付けではいけない
NATトラバーサルを、セキュリティポリシーを盲目的に回避する許可と誤解してはなりません。メディアリレーを公開したり、緩いファイアウォールルールを開いたり、アクセス制御なしでパブリックTURNサービスを展開したりすると、不必要なリスクが生じる可能性があります。安全な認証、適切なリレーポリシー、レート制限、ネットワークセグメンテーションは依然として重要です。
エンタープライズおよびサービスプロバイダー環境では、NATトラバーサルは通常、明確なエッジ設計と組み合わせることで最も効果的に機能します。これには、SBC、リバースプロキシ、専用TURNインフラストラクチャ、証明書ベースのセキュリティ、またはシグナリングとメディアに対するポリシー駆動型アクセス制御が含まれる場合があります。
リレーの使用はコストとパフォーマンスに影響する
TURNは接続性を向上させますが、無料ではありません。リレーされたメディアはパブリックサーバーの帯域幅を消費し、インフラストラクチャ負荷を追加し、直接パスと比較して遅延を増加させる可能性があります。そのため、成熟した展開では通常、安定した直接接続を最大化し、本当に必要なセッションのためにTURNを予約しようとします。
ここでは適切な容量計画が重要です。TURN容量が少なすぎるシステムはテストでは動作しても、ピーク時や制限の厳しいエンタープライズネットワーク条件下では失敗する可能性があります。これはまさに信頼できるフォールバックが最も重要となる時です。
アプリケーションの動作が依然として重要
強力なNATトラバーサルであっても、すべてのアプリケーション設計の問題を修正できるわけではありません。キープアライブのタイミング不良、弱いICE処理、誤った候補優先順位付け、メディアタイムアウト、不整合なシグナリングは依然として障害を引き起こす可能性があります。NATトラバーサルは、アプリケーション、トランスポート動作、およびエッジインフラストラクチャが一緒に設計されたときに最も効果的に機能します。
これが、トラブルシューティングがSTUNサーバーに到達できるかどうかを確認する以上のことを必要とする理由でもあります。エンジニアは、本当の原因が明らかになる前に、ICE候補、リレー割り当て動作、ファイアウォールログ、メディアポート、パケットキャプチャを検査する必要があるかもしれません。
結論
NATトラバーサルは、現代のアプリケーションがプライベートネットワーク、変換済みネットワーク、ポリシー制御ネットワークを越えて機能するのを助ける結合組織です。単一のプロトコルでも単一のトリックでもありません。それは発見、テスト、持続性、フォールバックを中心に構築された実用的な通信戦略です。
音声、ビデオ、ブラウザコラボレーション、ピアアプリケーション、リモートエッジシステムにとって、その戦略は、サービスが理論上接続するだけなのか、それとも現実世界で信頼性高く動作するのかをしばしば決定します。最高のNATトラバーサル設計とは、ユーザーがほとんど気付かないものです。なぜなら、通話、会議、データパスは、必要なときに単に維持されるからです。
よくある質問
NATトラバーサルはSTUNと同じですか?
いいえ。STUNはNATトラバーサルで使用されるツールの一つです。エンドポイントがパブリック向けアドレスを学習し、接続性を維持するのに役立ちますが、完全なNATトラバーサルでは多くの場合、ICEとTURNも使用されます。
STUNが既に存在するのに、なぜTURNが必要なのですか?
STUNは発見といくつかの直接接続ケースに役立ちますが、制限的なネットワークでの成功を保証するものではありません。TURNは、直接ピア通信を確実に確立できない場合にリレーパスを提供します。
NATトラバーサルはWebRTC専用ですか?
いいえ。WebRTCは主要なユースケースですが、NATトラバーサルはSIP音声、ビデオ会議、ゲーム、ピアツーピアソフトウェア、リモートアクセスツール、および一部のIoTやエッジ通信システムにとっても重要です。
NATトラバーサルはセキュリティを低下させますか?
それ自体では低下させません。セキュリティの結果はシステムの設計方法に依存します。NATトラバーサルは、認証、制御されたリレー、ポリシーの適用、安全なシグナリングとメディア処理によって安全に実装できます。
NATトラバーサルは直接ピアツーピア接続を保証できますか?
いいえ。直接パスがしばしば好まれますが、一部のネットワークはそれを許可しません。優れたNATトラバーサル設計はその現実を受け入れ、セッションを完全に失敗させる代わりに、必要な場合にリレーを使用します。