前のお話で、show ip nat translations の出力に並ぶ 4 列が「Inside / Outside × Local / Global」の 2 軸の直積で機械的に並ぶこと、4 つの顔それぞれの意味、show ip nat statistics で規模感の現在地、debug ip nat で書き換えの瞬間の演出を読む 3 つの窓があることを腹に置いた。あなたの手元には「4 つの顔は、内/外×Local/Global の 2 軸の直積でしかない」の 1 行が残った。

けれど、お話の最後にも渇りが残されていた。

ここまでの旅で、境界が外でも通用する名前を貸してくれること、行きと帰りで書き換える側が違うこと、ポートで多対1を成立させること、4 つの顔と 3 つの窓で対応表を読めること、を順に腹に置いた。書き換えで往復する翻訳の世界が、ひととおり見えた。だが、ここまでの見方だけで、地図は全部と言い切れるのだろうか。すべての通信が、この往復のリズムをそのまま踏めるのだろうか。書き換えが効かない場面は、本当にないのだろうか。

ここで、その渇りに正面から向き合う。実際のところ、書き換えで支えきれない通信が 3 類型ある。アプリ層に IPアドレスを書くプロトコル、外から内への能動接続、対称性が必要な通信。3 類型はいずれも NAT の不具合ではなく、書き換えという仕組みそのものの構造的な限界。NAT が触っているのは L3(IPヘッダの送信元 / 宛先)と L4(ポート)だけで、それ以外の場所に住所が書かれていたり、対応表に行が無かったりすると、書き換えだけでは通信が成立しない場面が立ち上がる。

そこで見えてくるのは、書き換えという道具の射程と、その外側にある世界。ここまでを歩き終えると、あなたの手元には「書き換えで支えきれない通信が 3 類型ある。書き換えという仕組みの構造的な限界。」という 1 行と、ここまでの旅を振り返る 5 つの動詞(出る・書き換える・詰める・読む・詰まる)が残る。地図の端からは、別の道具で支える世界と、住所そのものを根から解く方向の 2 方向が見えてくる。

考えてみよう: 本論に入る前に、5 秒だけ自分の頭で先に置いてみてほしい。前のお話までで、書き換えで往復する翻訳の世界がひととおり見えた。境界が外でも通用する名前を貸してくれること、行きと帰りで書き換える側が違うこと、ポートで多対1を成立させること、4 つの顔と 3 つの窓で対応表を読めること。これらの仕組みは強そうだ。でも、すべての通信が、この往復のリズムをそのまま踏めるのだろうか。書き換えが効かない場面は本当にないのだろうか。手探りでいい、自分なりの予想を 5 秒だけ置いてから先へ進んでほしい。

1. 5 つの動詞で、ここまでの旅を振り返る

本論に入る前に、ここまでの旅をひとつの形に並べてみたい。

最初のお話で、内側でだけ意味を持つ住所が、外に出るときに名前が変わることを腹に置いた。出る。続いて、行きと帰りで書き換える側が違うこと(SNAT / DNAT)を観察した。書き換える。次のお話では、ひとつのグローバルIPに大勢を載せるためにポートで多対1を成立させる仕組み(PAT)を観察した。詰める。前のお話では、対応表の各行を 4 つの顔(Inside / Outside × Local / Global)で読み、3 つの窓(現在地 / 規模感 / 演出)で対応表を覗き込む視点を獲得した。読む。

4 つの動詞 — 出る、書き換える、詰める、読む。ここまでで、書き換えで往復する翻訳の世界が、ひととおり見えてきた。境界 R-NAT が、内側の 10.1.50.10 を外側の 203.0.113.1 に書き換え、行きと帰りで違う側を扱い、ポートで多対1を成立させ、対応表を 4 つの顔で読む。仕組みは強そうだ。

ここで出会うのは、5 つ目の動詞。書き換えで支えきれない通信があり、書き換えという仕組みの構造的な限界にぶつかる場面がある。詰まる。

5 つの動詞が並ぶと、ひとつの物語として読める。

最後の動詞「詰まる」を、ここで腹に置く。

ポイント: ここまでの旅は、5 つの動詞で振り返れる。出る(外に出るとき名前が変わる)、書き換える(行きと帰りで違う側を)、詰める(ポートで多対1に)、読む(4 つの顔と 3 つの窓で)、そして最後の 詰まる(書き換えが効かない通信もある)。5 つの動詞が並ぶと、ひとつの物語として読める。

2. 書き換えで支えきれない通信の、3 類型

まずは、NAT が触る範囲を明確にしておきたい。NAT が書き換えるのは、IP ヘッダの送信元 / 宛先(L3)と、ポート番号(L4)。それだけ。アプリケーションが運ぶデータの中身(ペイロード、L7)や、対応表の作られ方、ポートの振り分けの仕組みは、書き換えの射程の外にある。

この境界線を意識すると、書き換えで支えきれない通信が 3 類型に整理できる。順に見ていく。

(a) アプリ層に IPアドレスを書くプロトコル

ある種のプロトコルは、アプリケーション層のペイロードの中に IPアドレスを書いて運ぶ設計になっている。古典的な例は FTP(File Transfer Protocol)。

FTP のクライアントが「自分のIPアドレスはこれで、このポート番号で待っているから、データはここに送ってほしい」とサーバに伝えるために、PORT というコマンドを使う。RFC 959 §5.3.1 で定義されている書き方は、こんな形:

PORT 10,1,50,10,127,138

カンマ区切りで「10.1.50.10」というIPアドレスと、「127×256+138 = 32650」というポート番号を、文字列として送っている。これがそのまま TCP のペイロード(L7)に入って、サーバに届く。

ここで境界 R-NAT の行きの書き換えを思い出してみる。境界が書き換えるのは、IP ヘッダの送信元(10.1.50.10 → 203.0.113.1)と、L4 のポート(必要に応じて別の番号に)。L3 と L4 は書き換わる。だが、アプリ層のペイロードに書かれた 10,1,50,10 という文字列は、書き換えの対象ではない。境界がそこまで覗いていないから、内側の住所がそのまま外に流れ出す。

サーバ側で受け取った FTP は、ペイロードに書かれた 10.1.50.10 という住所宛に能動的に繋ごうとする。けれど 10.1.50.10 は内側の住所で、サーバから直接は届かない。通信が成立しない。

FTP は古典だが、同じ「アプリ層で住所を再交渉する」設計は、現代のいくつかの通信にも残っている。これらに対応するには、境界が L3 / L4 に加えてペイロードまで覗いて書き換える必要があり、書き換えとは別の道具が要る。後で出会う ALG(Application Layer Gateway)が、この仕事を担う。ここでは、「ペイロードに住所を書く設計は、書き換えの射程の外にある」という構造を腹に置いておきたい。

(b) 外から内への能動接続

NAT の対応表は、内側からの行きで初めて書かれる。前のお話までで何度も見てきた構造を、もう一度なぞる。OPS-PC01(10.1.50.10)が外の Web サーバに通信を始めた瞬間に、境界が「内側 10.1.50.10:50001 ⇔ 外側 203.0.113.1:50001」の対応行を書く。応答は対応表を引いて内側に戻る。行きが先、対応行が次、応答は対応行を引く、という順番。

では、外側の端末が先に通信を始めたらどうなるだろう。境界 R-NAT に、外側から「203.0.113.1:80 への TCP 接続」が届く。境界は対応表を引く。だが、対応表に該当する行が無い。

R-NAT# show ip nat translations
(対応エントリなし)

境界には、内側の誰に渡せばいいかの手がかりが無い。

これは PAT で多対1にしているとき、特に顕著。外側のグローバルIP 203.0.113.1 ひとつに、内側に多くの端末がいる構造のため、外から「203.0.113.1:80 に来た通信を内側の誰に渡すか」を境界が判断できない。境界はパケットを落とす。

この場面で外公開を成立させるには、書き換えとは別の方法が要る。

• DNAT / Port Forwarding: 「203.0.113.1:80 に来た通信は、内側の 10.1.50.100:80 に渡す」のような対応表の行を、内側からの行き無しに常設する設定。Web サーバを公開する場面の典型。境界に手で行を作っておく発想。
• 動的に穴を空ける仕組み(UPnP-IGD / NAT-PMP / PCP): 内側端末が境界に「自分宛の穴を空けてほしい」と動的に要求する仕組み。家庭用ルータのオンラインゲームや P2P アプリで使われている。

これらも、書き換えとは別の道具。ここでは、「対応表は内側からの行きで初めて書かれる」「外から先に来た通信は、戻り先の手がかりが無い」という構造を腹に置いておきたい。

(c) 対称性が必要な通信

PAT は、ひとつのグローバルIPに大勢を載せるため、内側端末ごとに違うポート番号を割り当てる。前のお話で見た、対応表に並ぶ複数行(50001 / 50002 / 50003)が、その姿だった。

ここで、ひとつの内側端末が 同じ宛先と複数の会話 を持つ場面を考えてみる。OPS-PC01(10.1.50.10)が、外の P2P 通信相手と 1 つ目の会話を始めると、Inside Global は 203.0.113.1:50001 のような住所になる。後で別の会話を始めると、Inside Global は 203.0.113.1:50087 のような違うポートになる。

対等な P2P 通信(動画配信、ゲーム、VoIP)では、相手から見た自分の住所が会話のたびに変わると、困る場面がある。「先ほど 50001 番で会話した相手と、新しい接続を張る」が、ポート番号が 50087 に変わったとたんに崩れる。境界の対応表のどこに繋がっているかが、相手にとって不安定になる。

さらに、NAT 装置の内部の振る舞いには複数の流派があって、外側のどの相手に対しても同じ Inside Global に見える振る舞いと、相手によって見え方が変わる振る舞いがある。これらの組み合わせで、別のサーバで観測した自分の住所と、実際の相手から見える自分の住所が同じとは限らない(ここでは深入りしない)。

対等な通信を NAT 越しで成立させるには、書き換えとは別の経路で「自分が外からどう見えているか」を確かめ、相手と共有する仕組みが要る。STUN(自分が外からどう見えているかを問い合わせるプロトコル)、TURN(中継するサーバ)、ICE(STUN と TURN を組み合わせて経路を選ぶ仕組み)が、その道具。これらも書き換えとは別の道具。

ここでは、「PAT で多対1にすると、会話ごとにポート番号が違う」「対等な通信では相手から見た自分の住所が安定しない場面がある」という構造を腹に置いておきたい。

ポイント: 書き換えで支えきれない通信は 3 類型ある。(a) アプリ層に IPアドレスを書くプロトコル(NAT は L3 / L4 までしか触らない、FTP の PORT コマンドが典型)、(b) 外から内への能動接続(対応表は内側からの行きで初めて書かれる、外から先に来た通信は戻り先が決まらない)、(c) 対称性が必要な通信(PAT の多対1で会話ごとにポート番号が変わる、対等な P2P 通信で相手から見た住所が安定しない)。それぞれを支えるには、書き換えとは別の道具が要る。

3. 書き換えという仕組みの、構造的な限界

3 類型を並べてみると、見えてくるのは「NAT の不具合」ではない。「書き換えという仕組みそのものの構造的な性質から生まれる限界」。それぞれを 1 行で整理すると、こんな表になる。

どの類型も、NAT の動作が壊れているわけではない。境界ルータは、設計通りに動いている。L3 / L4 を書き換え、対応表を内側からの行きで作り、ポートで多対1を成立させる。それぞれの動作はそのまま、書き換えで支えきれない通信が立ち上がってくる。

言い換えると、書き換えという道具には射程がある。射程の中に収まる通信は、5 動詞の最初の 4 つ(出る・書き換える・詰める・読む)で気持ちよく往復する。射程の外にある通信は、5 つ目の動詞「詰まる」に出会う。

この整理は、明日の現場でも効く。「FTP が NAT 越しで動かない」「家庭用ルータでオンラインゲームのホストができない」「P2P アプリの通信が一方向に止まる」のような場面に出会ったとき、「これは書き換えの射程の中の問題か、外の問題か」を最初に問える。射程の外なら、書き換えの設定をいじっても解決しない。別の道具を呼ぶ局面だと、最初に判断できる。

ポイント: 3 類型はいずれも NAT の不具合ではなく、書き換えという仕組みそのものの構造的な限界。書き換えという道具には射程があり、射程の中の通信は 4 動詞で気持ちよく往復し、射程の外の通信は 5 つ目の動詞「詰まる」に出会う。

4. 地図の端から見える、2 方向 — 別の道具で支える世界 / 住所を根から解く方向

射程の外にある通信は、放置されているわけではない。書き換えとは別の道具で支える世界が、すでに育っている。地図の端から見える方向は、2 つに整理できる。

方向 1: 書き換えで支えきれない通信を、別の道具で支える世界

類型ごとに、対応する道具が育っている。

• 類型 (a) ペイロードに IPアドレスを書く → ALG(Application Layer Gateway)。境界がペイロードまで覗いて書き換える専用の仕組み。FTP の PORT コマンドのような「アプリ層に住所を書く」場面で、境界がペイロードを解釈して内側の住所を外側の住所に書き換える。プロトコルごとに別の処理が要る(FTP の ALG / SIP の ALG / など)。
• 類型 (b) 外から内への能動接続 → DNAT / Port Forwarding で対応表の行を常設する設定。あるいは hairpin / NAT loopback で、内側同士が外側経由で会話する場面の対応。動的に穴を空ける仕組み(UPnP-IGD / NAT-PMP / PCP)もある。家庭用ルータのオンラインゲーム機能などは、UPnP で動的に穴が開いている。
• 類型 (c) 対称性が必要 → STUN / TURN / ICE。NAT 越しの P2P 通信を成立させるための一連のプロトコル群。STUN が「自分が外からどう見えているか」をサーバに問い合わせ、TURN が中継のリレー、ICE が複数の経路から最適なものを選ぶ。

これらの仕組みの細部には、ここでは踏み込まない。この先、具体的な道具を扱う世界で、それぞれの道具に出会っていくことになる。ここで持ち帰るのは「書き換えの限界が、別の道具を呼ぶ」という全体の構造。

方向 2: 住所そのものを根から解く方向

NAT は IPv4 の延命の核心と言える。住所(IPv4)が足りないからこそ、ポートで多対1に詰めて凌いできた。書き換えで支えきれない通信に出会うたびに、別の道具を継ぎ足しながら成立させてきた。NAT は、IPv4 という限られた住所空間を、現代のインターネット規模で使い続けるための工夫の総体。

だが、住所そのものを増やす方向もある。IPv6 は IPv4 の後継として設計された次の世代のアドレス空間で、住所が十分に大きい。原理上は、内側端末ひとつひとつに世界で通用する住所を配ることができる。住所が足りないという前提が薄くなれば、ポートで詰める動機も薄くなり、IPv4 NAT が生んでいた制約の一部は別の形に変わっていく。

ただし、世界はすぐには切り替わらない。IPv4 と IPv6 が共存する移行期には、別の翻訳(NAT64)が必要な場面がある。IPv6 だけのクライアントが IPv4 だけのサーバに通信したいとき、境界が IPv6 と IPv4 を翻訳する。NAT が IPv4 と IPv4 を翻訳していたのが、IPv6 と IPv4 を翻訳する世界に拡がる。

IPv6 の世界も、ここではこれ以上踏み込まない。次の世界で出会う。ここで持ち帰るのは「住所の不足を根から解く方向に、次の世代のアドレス空間がある」という渇り。

2 方向の渇りは、地図の端から同時に見える。書き換えという道具を磨いていく方向と、住所そのものを増やす方向。どちらも、ここまで。

ポイント: 地図の端からは 2 方向が見える。方向 1: 書き換えで支えきれない通信を別の道具で支える世界(ALG / DNAT / hairpin / 動的穴あけ / STUN・TURN・ICE)。方向 2: 住所そのものを根から解く方向(IPv6 / NAT64)。どちらも、続きは次の世界で出会う。

書き換えの限界と、5 つの動詞統合 — L3 Essential の物語として閉じる

冒頭で抱えていた渇りに、いま、自分の言葉で答えられる。

書き換えで往復する翻訳の世界が、ひととおり見えた。だが、すべての通信がこの往復のリズムをそのまま踏めるわけではない。書き換えで支えきれない通信が 3 類型ある。

アプリ層に IPアドレスを書くプロトコル(NAT は L3 / L4 までしか触らない)。外から内への能動接続(対応表は内側からの行きで初めて書かれる)。対称性が必要な通信(PAT で会話ごとにポート番号が変わる)。3 類型はいずれも NAT の不具合ではなく、書き換えという仕組みそのものの構造的な限界。

ここまでの旅は、5 つの動詞で振り返れる。

出る(外に出るとき名前が変わる)、書き換える(行きと帰りで違う側を)、詰める(ポートで多対1に)、読む(4 つの顔と 3 つの窓で)、そして最後の 詰まる(書き換えが効かない通信もある)。5 つの動詞が並ぶと、ひとつの物語として読める。

ここまでの手土産は、ひとつの 1 行に集約される。

書き換えで支えきれない通信が 3 類型ある。書き換えという仕組みの構造的な限界。NAT の旅は、出る・書き換える・詰める・読む・詰まる の 5 動詞で振り返れる。

明日、現場で「FTP が NAT 越しで動かない」「家庭用ルータでオンラインゲームのホストができない」「P2P アプリが一方向に止まる」のような場面に出会ったら、3 類型のフレームを通せる。アプリ層に IPアドレスが書かれているか、外から内への能動接続が要るか、対称性が必要な通信か。3 類型に当てはめると、トラブルシュートの最初の見立てがつく。書き換えの射程の中の問題なら、境界の設定を確認する。射程の外なら、別の道具(ALG / DNAT / hairpin / 動的穴あけ / STUN / TURN / ICE)が要ると判断できる。

地図の端からは、もうひとつの景色が見える。

書き換えで支えきれない通信は、別の道具で支える世界がある。ALG がペイロードまで覗いて書き換え、DNAT / Port Forwarding が外公開のために対応表に行を常設し、hairpin が内側同士の通信を支え、動的穴あけ(UPnP / NAT-PMP / PCP)が穴を動的に開け、STUN / TURN / ICE が P2P の対等性を別の経路で補う。これらは、書き換えの限界が呼ぶ別の道具たち。次の世界で出会う。

そして、住所そのものを根から解く方向には、IPv6 と NAT64 が待っている。NAT は IPv4 の延命の核心。住所が足りないから、ポートで詰めて凌いできた。住所そのものを増やす次の世代のアドレス空間が、地図の端から手招きしている。これも次の世界。

内側でだけ意味を持つ住所から始まった旅が、境界で世界に通じる名前を借り、行きと帰りで違う側を書き換え、ポートで多対1を成立させ、4 つの顔と 3 つの窓で対応表を読み、書き換えで支えきれない通信の限界に出会うまで、5 つの動詞で進んできた。

L3 Essential の旅は、ここで物語として閉じる。

5 つの動詞と、3 類型の整理と、2 方向の渇り。手元に残ったこれらの言葉を、次の世界で待っているそれぞれの道具と、それぞれのアドレス空間が、新しい景色で迎えてくれる。