NAT 越えの仕組み｜STUN・TURN・ICE と NAT タイプの関係

はじめに

『NAT とは｜変換テーブルの仕組みと NAPT・IP マスカレードの違い』では、NAT の本質を「変換テーブルによる行きと戻りの対応付け」として整理し、その帰結の 1 つとして「NAT の内側にある端末同士は、直接通信できない」という問題があることに触れました。VoIP・ビデオ会議・オンラインゲーム・P2P アプリケーション、そして IPsec VPN のように、双方が NAT の内側にいる状態で通信を確立したい場面では、この問題が正面から立ちはだかります。

この課題に対応する技術が、一般に NAT 越え（NAT traversal） と呼ばれます。本記事では、なぜこの問題が起こるのかを NAT タイプの違いから整理し、それに対する 2 系統の解決策、すなわち UDP ベースの通信（VoIP・WebRTC 等）向けの STUN・TURN・ICE と、IPsec VPN 向けの NAT-T（NAT Traversal） を解説します。一次資料として RFC 8489（STUN）・RFC 8656（TURN）・RFC 8445（ICE）・RFC 4787（NAT の挙動分類）・RFC 3947 / 3948（IPsec の NAT-T）を参照します。

なお、これらは「NAT の内側同士」の通信を扱う技術です。同じ NAT の内側から、自社が NAT の外側に公開しているサーバーへグローバル IP でアクセスできないという別の問題（内側から外側公開アドレスへの折り返し）については、関連記事『ヘアピン NAT とは｜内部からグローバル IP でアクセスできない原因と対処』で解説しています。両者は「NAT を挟んで直接届かない」という点で似ていますが、通信の相手が内側にいるか外側にいるかが異なります。

先に結論を示すと、NAT 越えの技術は大きく 2 系統に分かれます。UDP ベースの汎用アプリケーション向けには STUN・TURN・ICE の組み合わせが標準 であり、IPsec VPN のように特定のプロトコル（IKE・ESP）を対象とする用途には NAT-T という専用の解決策 が用意されています。共通する考え方は、「NAT の外から見た自分のアドレスを知る」「直接届かなければ中継する」「複数の経路候補を試して最良のものを選ぶ、または NAT を通過できる形に変換する」というアプローチです。

なぜ NAT の内側同士は直接通信できないのか

STUN・TURN・ICE・NAT-T という個別の技術に入る前に、そもそもの問題を整理します。ここを理解しておくと、各技術が「何を」解決しているのかが素直につながります。

変換テーブルとエントリの片方向性のおさらい

ハブ記事で解説した通り、NAT の変換テーブルのエントリは 内側からの通信（行き）によって作られ、外部起点の新規通信はそのエントリがなければ内側へ届きません。

双方が別々の NAT の内側にいる 2 台の端末（A・B）が通信しようとする場面を考えます。

• A が B へ向けて送信すると、A 側の NAT にエントリが作られますが、B 側の NAT にはまだ何のエントリもありません。B の NAT は「外部からの新規通信」としてこのパケットを破棄します。
• 同時に B が A へ向けて送信しても、状況は対称的で、A 側の NAT で同じ理由により破棄されます。

この根本問題を解決するには、どちらか一方（あるいは両方）が先に相手へ向けてパケットを送り、自分側の NAT にエントリを作っておく 必要があります。これが後述する「穴あけ（hole punching）」の基本原理です。ただし、エントリの作られ方は NAT の実装によって異なり、この違いが穴あけの成否を左右します。

NAT タイプによる挙動の違い（フルコーン・制限コーン・ポート制限コーン・シンメトリック）

NAT が外向き通信に対してどうエントリ（マッピング）を作り、どの外部からの通信を受け入れる（フィルタリングする）かは、機器の実装によって異なります。この違いを分類したのが、伝統的な「NAT タイプ」の 4 分類です。

NAT タイプ	外部からの着信を許可する条件
フルコーン（Full Cone）	一度でも外向き通信をした内部ポートには、送信元を問わずどこからでも届く
制限コーン（Restricted Cone）	過去に送信した宛先の IP アドレス からのみ届く（ポートは問わない）
ポート制限コーン（Port Restricted Cone）	過去に送信した宛先の IP アドレスとポートの組 からのみ届く
シンメトリック（Symmetric）	宛先ごとに異なる外部ポートを割り当てる。同じ宛先・同じポートからの応答しか受け付けない

シンメトリック NAT が最も穴あけを困難にします。A が B 向けに送信して作られる外部ポートと、A が STUN サーバー向けに送信して作られる外部ポートが異なる ため、「STUN で調べた自分の外部アドレス」を B に伝えても、B からの応答はそのポートに届きません。これがシンメトリック NAT 環境で STUN 単体による直接接続（穴あけ）が失敗する理由です。

なお、この 4 分類は 2003 年の RFC 3489（STUN の旧版）に由来する伝統的な整理です。現行の RFC 4787 は、この挙動を マッピング（Mapping） と フィルタリング（Filtering） という独立した 2 つの軸に分解して定義し直しています。

参考: RFC 4787 – NAT Behavioral Requirements for Unicast UDP
“The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port”
（NAT は、同一の内部アドレスとポート（X:x）から送信された後続のパケットに対し、宛先の外部アドレス・ポートによらず同じポートマッピングを再利用します）
https://datatracker.ietf.org/doc/html/rfc4787

この定義（Endpoint-Independent Mapping）が、伝統的な分類における「フルコーン・制限コーン・ポート制限コーン」に共通するマッピング挙動（宛先によらず外部ポートが変わらない）に相当し、逆に宛先ごとに外部ポートが変わる挙動（Address and Port-Dependent Mapping）が「シンメトリック」に相当します。フィルタリングの軸（Endpoint-Independent / Address-Dependent / Address and Port-Dependent）と組み合わせることで、伝統的な 4 分類よりも精密に NAT の挙動を記述できます。実務上は、「マッピングが宛先に依存しないか（Endpoint-Independent Mapping）」が、後述する ICE によるピアツーピア接続の成否を分ける最大の要因 と理解しておけば十分です。

STUN・TURN・ICE の役割分担

第 1 章で整理した通り、NAT の内側同士が通信するには「自分の外部アドレスを知る」「相手に先に穴あけしてもらうか、中継してもらう」「複数の経路を試して最良のものを選ぶ」という段階が必要です。STUN・TURN・ICE は、この 3 つの役割にそれぞれ対応する、独立しつつ協調して使われる技術です。

STUN（自分の外側アドレスを知る）

STUN（Session Traversal Utilities for NAT）は、端末が自分自身の外部アドレス（NAT 変換後の IP アドレスとポート）を知るための、最も基本的な技術です。

参考: RFC 8489 – Session Traversal Utilities for NAT (STUN)
“enables clients behind NATs to discover their public IP addresses and ports by sending Binding requests to a STUN server”
（STUN は、NAT の内側にあるクライアントが STUN サーバーへ Binding リクエストを送信することで、自身のパブリック IP アドレスとポートを発見できるようにします）
https://datatracker.ietf.org/doc/html/rfc8489

動作は単純です。端末がインターネット上の STUN サーバーへリクエストを送ると、STUN サーバーは「そのリクエストがどの送信元アドレス・ポートから届いたか」をそのまま応答に含めて返します。端末はこれを見ることで、NAT がどのグローバルアドレス・ポートに自分を変換したかを知ることができます。

STUN が提供するのは アドレス発見のみで、中継機能を持ちません。前章で整理した NAT タイプのうち、フルコーン・制限コーン・ポート制限コーンのように マッピングが宛先によらず一定（Endpoint-Independent Mapping） な NAT であれば、STUN で調べたアドレスを相手に伝え、双方から同時に送信し合う「穴あけ（hole punching）」によって直接通信を確立できます。一方、シンメトリック NAT（宛先ごとにマッピングが変わる NAT）同士では、STUN で調べたアドレスが実際の通信で使われるアドレスと一致しないため、穴あけは失敗します。

TURN（それでも直接届かない場合の中継）

TURN（Traversal Using Relays around NAT）は、STUN による直接接続が成立しない場合の 中継サーバー を提供する技術です。

参考: RFC 8656 – Traversal Using Relays around NAT (TURN)
“relays media when direct paths fail”
（直接経路が確立できない場合に、メディアを中継します）
https://www.forasoft.com/learn/video-streaming/articles-streaming/nat-stun-turn-ice-webrtc

TURN サーバーは、STUN の機能を拡張し、パブリックなインターネット上に「両端末がそれぞれ話しかけられる中継アドレス」を用意します。双方の端末がこの中継アドレスに向けて通信することで、シンメトリック NAT 同士のように直接の穴あけが不可能な組み合わせでも通信が成立します。

TURN の代償は明確です。すべての通信が中継サーバーを経由するため、直接通信に比べて遅延が増え、中継サーバー側の帯域・処理コストが発生します。WebRTC サービスの運用では、TURN 中継の発生率とコストが実装上の重要な設計要素になることが知られています。TURN は「最後の手段」として位置づけられ、可能な限り直接経路（STUN による穴あけ）を優先するのが実装の基本方針です。

ICE（候補を集めて最適な経路を選ぶ）

ICE（Interactive Connectivity Establishment）は、STUN と TURN を組み合わせて 最も良い経路を自動的に選択する ための、いわば司令塔となるプロトコルです。

参考: RFC 8445 – Interactive Connectivity Establishment (ICE)
“This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN)”
（このプロトコルは Interactive Connectivity Establishment（ICE）と呼ばれます。ICE は STUN プロトコルおよびその拡張である TURN を利用します）
https://datatracker.ietf.org/doc/html/rfc8445

ICE は、通信を開始する前に、端末が到達可能な 候補（candidate） をすべて収集します。

• ホスト候補: 端末が直接持つローカル IP アドレス（同一 LAN 内であればこれで通信できます）
• サーバーリフレクシブ候補: STUN で調べた、NAT 変換後の外部アドレス
• リレー候補: TURN サーバー経由の中継アドレス

双方の端末がこれらの候補を交換し、優先度の高い組み合わせ（同一 LAN 内なら直接、次に STUN による直接、最後に TURN 中継）から順に接続性を検査し、実際に疎通した中で最も優先度の高い経路を採用 します。

3 技術の関係を整理すると、以下のようになります。

技術	役割	単体での位置づけ
STUN	自分の外部アドレスを知る	直接接続（穴あけ）の材料を提供する
TURN	直接届かない場合に中継する	最終手段としての通信路を保証する
ICE	STUN / TURN の候補から最適経路を選ぶ	実際のアプリケーションが呼び出す統合窓口

実務では、STUN・TURN を個別に呼び出すのではなく、WebRTC をはじめとする多くの実装が ICE を通じてこれらを利用 します。アプリケーション開発者が STUN / TURN サーバーの URL を設定すれば、その後の候補収集・接続性検査・経路選択は ICE が自動的に行う、という関係です。

IPsec VPN における NAT 越え（NAT-T）

STUN・TURN・ICE が UDP ベースの汎用アプリケーション向けの解決策であるのに対し、IPsec VPN には NAT-T（NAT-Traversal） という専用の解決策があります。ハブ記事で「IPsec のトランスポートモードは NAT のヘッダ書き換えと原理的に両立しない」と整理した問題への、実装上の回答です。

IKE と ESP が NAT を越えられない理由

IPsec VPN が NAT 環境で失敗する原因は、IKE（鍵交換）と ESP（暗号化パケット）それぞれに存在します。

ESP（Encapsulating Security Payload）の問題

ESP は IP ヘッダの直後に独自のプロトコル番号（50）を使って続く、TCP・UDP とは別のプロトコルです。ここに 2 つの問題があります。

• 多くの NAPT 実装は ESP をポート番号ベースで多重化できません。NAPT は TCP / UDP のポート番号でセッションを識別しますが、ESP にはポート番号の概念がなく、複数の内部端末が同時に ESP 通信をすると、どの端末宛かを区別できなくなります。
• ESP には認証（ICV: Integrity Check Value）が含まれ、NAT によるヘッダ書き換えを検知して通信を破棄する場合があります。IPsec は改ざん検知の一環として送信元アドレスを含む情報を検証対象にすることがあり、NAT による書き換えがこの検証と衝突します。

IKE（Internet Key Exchange）の問題

IKE は UDP ポート 500 を使う鍵交換プロトコルです。ポート番号を持つため NAPT 自体は通過できますが、IKE のペイロードには送信元・宛先の識別情報が含まれる場合があり、NAT 変換によって両エンドポイントの認識が食い違う ことがあります。また、複数の VPN クライアントが同一の NAT 配下にいる場合、それぞれの IKE セッションを NAT 側がどう識別するかという問題も生じます。

これらの問題を解決するために標準化されたのが NAT-T です。

NAT-T によるカプセル化と自動検知の仕組み

NAT-T の基本方針はシンプルで、ESP パケットを UDP でカプセル化し、NAPT が扱える形にする というものです。

参考: RFC 3948 – UDP Encapsulation of IPsec ESP Packets
“The solution proposed by RFC 3948 is to encapsulate ESP packets in UDP datagrams, which then allows to apply Port Address Translation”
（RFC 3948 が提案する解決策は、ESP パケットを UDP データグラムでカプセル化することであり、これにより Port Address Translation の適用が可能になります）
https://docs.strongswan.org/docs/latest/howtos/ipsecProtocol.html

ESP を UDP ヘッダで包むことで、ポート番号ベースの NAPT がそのまま扱える通信に変換されます。カプセル化後は、IKE と ESP の両方が同じ UDP ポート 4500 を共有して使用します。

NAT-T の運用でもう 1 つ重要なのが、NAT の存在を自動的に検知する仕組み です。両エンドポイントは、IKE のフェーズ 1（IKE_SA_INIT）の中で、送受信した IP アドレス・ポートのハッシュ値を交換します。

参考: strongSwan Documentation – Introduction to the IPsec Protocol
“The detection is based on the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications sent in the IKE_SA_INIT exchange”
（検知は、IKE_SA_INIT 交換で送信される NAT_DETECTION_SOURCE_IP と NAT_DETECTION_DESTINATION_IP の通知に基づきます）
https://docs.strongswan.org/docs/latest/howtos/ipsecProtocol.html

送信したハッシュ値と、相手が実際に受信したアドレスから計算したハッシュ値が一致しなければ、経路上に NAT が存在すると判定され、双方が自動的に UDP ポート 4500 での通信（NAT-T）へ切り替わります。この検知と切り替えは自動で行われるため、通常は管理者が意識して設定する項目ではありません。ただし、以下の点は実務上押さえておく価値があります。

UDP ポート 500・4500 の双方が、経路上のファイアウォールで通過を許可されている必要がある

特に 4500 番が塞がれていると、NAT 環境下での IPsec VPN 接続がフェーズ 1 を過ぎたあたりで失敗します。

キープアライブが必要

NAPT の変換テーブルのエントリはハブ記事で解説した通りタイムアウトで消滅するため、無通信状態が続くとエントリが失われ、通信が途切れます。NAT-T 環境では、この消滅を防ぐための定期的な NAT キープアライブパケットが送信されます。

拠点間 VPN で双方が固定グローバル IP を持つ構成では、NAT-T は本来不要

それでも、経路上に想定外の NAT（ISP 側の透過的な変換等）が存在する場合に備え、NAT-T を無効化せず自動検知に任せる運用が一般的です。

FortiGate における NAT-T の実例（Double NAT 環境での VPN 構築）は、関連記事『FortiGate NAT 設定の手順｜VIP と IP Pool の使い分けと確認コマンド』および既存記事『FortiGate IPsec VPN の構築手順｜IKEv2 と NAT 越えの設定例』もあわせて参照してください。

実務での注意点

最後に、NAT 越えを扱う際に実務で押さえておきたい注意点を整理します。

NAT タイプの判定結果を過信しない

オンラインゲームのコンソールやネットワーク診断ツールが表示する「NAT タイプ: 厳格 / 中程度 / 開放」といった判定は、第 1 章で解説した 4 分類に基づく簡易的な推定です。RFC 4787 が指摘する通り、同一の NAT 機器であっても、内部ホストやセッションの状況によって挙動が変わる実装が存在します。判定結果は目安として扱い、実際の疎通結果を優先して切り分けることが推奨されます。

CGNAT 環境では NAT が二重になる

モバイル回線や一部の固定回線では、ISP 側でも NAT（CGNAT / LSN）が行われており、宅内ルーターの NAT とあわせて NAT が二重に存在する状態 になります。この環境では、宅内ルーターの設定でポート開放をしても外部から到達できず、また NAT 越えの成功率も低下します。CGNAT の仕組みと制約は別記事で扱う予定です。

TURN 中継のコストを設計に織り込む

前章で触れた通り、TURN はすべての通信が中継サーバーを経由するため、帯域コストと遅延が発生します。「TURN サーバーを用意すれば必ず繋がる」のは事実ですが、その分のコストは中継量に比例して増加します。サービスとして提供する場合は、直接接続の成功率と TURN 中継の発生率を計測し、コスト試算に反映することが推奨されます。

ALG との干渉に注意する

ハブ記事で触れた通り、多くのルーター・ファイアウォールには SIP ALG などの機能が搭載されており、これがペイロード内のアドレスを書き換えます。アプリケーション側が STUN / ICE で正しく NAT 越えを行おうとしているところに ALG が介入し、かえって通信が不安定になる ことがあります。VoIP システムのトラブルシューティングで SIP ALG の無効化が定石とされるのはこのためです。ALG に任せるか、端末側の NAT 越え機能に任せるか、方針を統一することが重要です。

IPsec VPN では UDP 4500 の疎通を確認する

NAT 環境での IPsec VPN 接続が失敗する場合、経路上のファイアウォールで UDP 500・4500 の双方が許可されているかを最初に確認します。NAT-T の自動検知が成立していても、切り替え先のポートが塞がれていれば通信は成立しません。

まとめ

本記事では、NAT の内側同士が直接通信できない理由を変換テーブルの片方向性から整理し、UDP アプリケーション向けの STUN・TURN・ICE と、IPsec VPN 向けの NAT-T という 2 系統の解決策を解説しました。いずれも「NAT の外から見た自分を知り、届く形に変換する」という同じ発想に立っています。

• 原因は変換テーブルのエントリが内側からの通信でしか作られないこと
• NAT タイプのうちシンメトリックは穴あけによる直接接続が困難
• STUN は自分の外部アドレスを知るための仕組み
• TURN は直接届かない場合の中継であり帯域コストを伴う
• ICE は STUN と TURN の候補から最適経路を自動選択する
• IPsec の NAT-T は ESP を UDP 4500 でカプセル化して通過させる
• NAT-T の検知は自動だが UDP 500・4500 の疎通確認が前提となる

以上、最後までお読みいただきありがとうございました。