NAT 越え技術：ホールパンチングと NAT 種別

なぜ NAT 越えが難問なのか

NAT 配下の端末は、内側から発信した通信には返事を受け取れますが、外から突然来る着信は変換テーブルに対応が無いため捨てられます。この基本動作は /network/nat/ で扱ったとおりです。問題は、双方が NAT の内側にいる P2P（WebRTC のメディア、オンラインゲーム、ファイル直送など）で起きます。どちらも「先に着信を待つ」側になれないため、素朴には永遠につながりません。

ここで効くのが、NAT が 内側から外へ出たときに作るマッピング（穴） を、戻り通信が一定条件で再利用できるという性質です。両端が「先に外へ撃って穴を開け、その穴へ相手を呼び込む」ことができれば、中継なしで直結できます。これがホールパンチングの核心ですが、成功するかどうかは NAT の 種別 に強く依存します。

NAT 種別：マッピングとフィルタリングを分けて捉える

RFC 3489（旧 STUN）由来の古典的分類では、NAT を4種に分けます。鍵は2つの軸です。ひとつは マッピング挙動（同じ内側アドレスから出すとき、宛先が変わっても同じ外側ポートを使い回すか）、もうひとつは フィルタリング挙動（外から来たパケットを、どの送信元なら穴へ通すか）です。

cone 型に共通するのは、外側ポートが 宛先に依存しない ことです。つまり STUN サーバーへ問い合わせて観測した外側アドレスが、相手ピアへ向けて使う外側アドレスと一致します。フィルタリングの厳しさ（誰を通すか）はホールパンチングの手順で吸収できます。一方 Symmetric は、宛先が変わると外側ポートまで変わるため、STUN で観測した値が相手向けには通用しません。これが後述の破綻原因です。

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

ホールパンチングを始めるには、まず各端末が 自分が外からどう見えるか（NAT 変換後の外側 IP とポート）を知る必要があります。これを担うのが STUN（Session Traversal Utilities for NAT）です。

Client(内側 192.168.1.10:50000)
  -> STUN サーバー(203.0.113.50:3478) へ Binding Request

STUN サーバーは受信パケットの「送信元」をそのまま返す
  <- Binding Success: XOR-MAPPED-ADDRESS = 198.51.100.7:40000

STUN サーバーは特別なことをせず、受け取ったパケットの送信元 IP/ポート（=その端末の NAT がそのとき作った外側マッピング）を応答に詰めて返すだけです。クライアントは自分の内側アドレスと、返ってきた外側アドレスを比べることで、NAT 配下かどうかと、外側アドレスの値を把握します。

ここで重要なのは、STUN への問い合わせで観測した外側ポートが、そのまま相手ピアへ使えるとは限らない ことです。cone 型なら使えますが、Symmetric では STUN サーバー宛のマッピングと相手ピア宛のマッピングが別物になります。

UDP ホールパンチングの手順

両端 A・B が、シグナリング経路（事前に用意したサーバー経由のチャネル）で互いの外側アドレスを交換できる前提で進めます。シグナリングは制御情報のやり取りだけで、メディア本体は流しません。トランスポートに UDP を使うのは、TCP の対称的な接続確立（3 ウェイハンドシェイク）がホールパンチングと相性が悪いためです（/network/tcp-udp/ 参照）。

1. A,B それぞれ STUN で自分の外側アドレスを取得
     A_pub = 198.51.100.7:40000
     B_pub = 203.0.113.9:50000
2. シグナリングサーバー経由で A_pub と B_pub を相互に交換
3. A は B_pub 宛、B は A_pub 宛へ、ほぼ同時に UDP を送信
     - この「外向き送信」が各自の NAT に穴を開け、
       相手 IP をフィルタの許可リストへ登録する
4. 先に着いた側はフィルタで弾かれることがあるが、
     後続パケットは互いの穴が開いた後なので通る
5. 双方向に到達確認できたら、その経路で直接通信を継続

成立の条件を分解すると次のとおりです。第一に、両端が相手宛へ外向き送信すること。一方だけが待っていてはフィルタが開きません。第二に、cone 型のように STUN 観測アドレス＝相手向けアドレス が成り立つこと。第三に、開けた穴が応答到達まで タイムアウトせず維持 されること。UDP マッピングは無通信だと数十秒で消えるため、定期的なパケット送信で温め続けます（この keepalive の必要性は /network/socket-port/ のポート寿命とも通じます）。

なぜ Symmetric NAT で破綻するのか

Symmetric NAT は、内側アドレスが同じでも 宛先（IP とポート）が変わるたびに別の外側ポートを割り当てます。この一点がホールパンチングを崩します。

A の NAT が Symmetric の場合:
  A -> STUN(203.0.113.50:3478)  で観測: 198.51.100.7:40000
  A -> B_pub(203.0.113.9:50000) で実際に使う外側: 198.51.100.7:41001 (別ポート)

B は「198.51.100.7:40000 へ撃て」と教わっているが、
A が B 向けに開けた穴は 41001。B の着信は 40000 宛なので
A のフィルタに一致せず破棄される。逆方向も同様にずれる。

STUN で観測した :40000 は STUN サーバー宛に作られた穴であり、相手ピア宛の穴 :41001 とは別物です。相手に伝えたアドレスが指す穴が存在しないため、撃ち合っても到達しません。両端のどちらかが Symmetric なら、もう片方が cone 型でも、外側ポートが事前に予測できないため基本的に直結は失敗します。

ポート番号が連番で増える実装を狙って次のポートを推測する ポート予測 という回避策もありますが、割り当てがランダム化された NAT や CGN（キャリアグレード NAT）では成功率が低く、信頼できる手段にはなりません。

TURN：直結を諦めて中継する

直結が成立しないときの最終手段が TURN（Traversal Using Relays around NAT）です。TURN サーバーは公開アドレスを持つ 中継器 で、両端は「外向き通信」として TURN へ接続し、以降のメディアを TURN 経由で相手へ転送してもらいます。

A <-(外向き)-> TURN(公開IP) <-(外向き)-> B

A も B も自分から TURN へ発信するため、NAT 種別に関係なく
マッピングが作れる。TURN は A から来たデータを B へ、
B から来たデータを A へリレーする。

要点は、両端ともに 自分から TURN へ外向き接続する ため、Symmetric であっても穴は問題なく開く点です。直結（ホールパンチング）が NAT 種別に依存するのに対し、TURN は中継で確実性を買います。代償は、すべてのトラフィックがサーバーを経由することによる 遅延の増加・帯域コスト・サーバー負荷 です。だから TURN は常用せず、直結が無理なときの退避先に位置づけます。

WebRTC が使う ICE（Interactive Connectivity Establishment）は、この優先順位を体系化した枠組みです。

ICE は複数の候補（ローカル、STUN 由来、TURN 由来）を集め、ペアごとに疎通確認（connectivity check）を行い、通った中で最良のものを選びます。つまり「まず直結を試し、ダメなら中継へ落ちる」という退避を自動化したものが ICE であり、本記事の STUN・ホールパンチング・TURN はその構成部品にあたります。

まとめ：種別が運命を決める

NAT 越えの成否は、煎じ詰めると マッピングが宛先に依存するか で決まります。cone 型は外側ポートを使い回すため STUN 観測アドレスがそのまま相手に使え、両端が撃ち合えばホールパンチングで直結できます。Symmetric は宛先ごとにポートを変えるため、観測した穴と相手向けの穴がずれて破綻し、TURN 中継へ退避するしかありません。実務では、まず ICE に任せて自動で最良経路を選ばせつつ、TURN を確実な保険として用意しておくのが定石です。NAT そのものの変換テーブルの仕組みは /network/nat/ を、UDP を土台に選ぶ理由は /network/tcp-udp/ を併せて読むと理解が固まります。