前のお話で、境界が外に持っているグローバルIPがひとつしかない場面でも、ポートという第2の番号で対応表の行を分ければ、内側に大勢いる端末を多対1で外に乗せられることを腹に置いた。あなたの手元には「ひとつのグローバルIPに大勢が乗れるのは、ポートで行を見分けられるから」の 1 行が残った。

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

ここまでで、いくつもの住所が出てきた。内側にいる端末の住所、境界の外側のグローバルIPの住所、外のサーバの住所、境界が行きで書き換えた住所、応答で書き戻る住所。1 つの通信の中で、住所がいくつも動いている。対応表の各行を読むときに、これらの住所は何か秩序立った整理の仕方で並んでいるのだろうか。境界の手元の対応表をもしのぞき込んだとしたら、そこに並ぶ住所はどう整理されているのだろう。

ここで、その渇りに正面から向き合う。実際に境界 R-NAT で show ip nat translations を叩いてみると、画面には 4 つの列が並んでいる。前のお話までで腹に置いたのは「内側のIP+ポート / 外側のIP+ポート」の 2 列だった。なのに、実機の画面には 4 列。なぜ 4 列なのだろう。増えた 2 列は、何を表しているのだろう。

そこで見えてくるのは、住所には「どこにいるか」と「どこから見たか」という 2 つの軸があり、その 2 軸の直積で 4 つの顔ができる、という素朴な構造。Inside / Outside は端末がどこにいるか、Local / Global はどこから見た住所か。軸さえ決まれば、4 つの顔は機械的に並ぶ。show ip nat translations の 4 列は、その 4 つの顔をそのまま並べたもの。ここまでを歩き終えると、あなたの手元には「4 つの顔は、内/外×Local/Global の 2 軸の直積でしかない」という 1 行が残る。

考えてみよう: 本論に入る前に、5 秒だけ自分の頭で先に置いてみてほしい。境界 R-NAT で show ip nat translations を叩いたら、画面には 4 つの列が並んでいた。前のお話までで腹に置いた対応表は「内側のIP+ポート / 外側のIP+ポート」の 2 列だったはずだ。なのに、実機の出力では 4 列。残りの 2 列は、何を表しているのだろう。Inside と Outside、Local と Global という名前は、それぞれ何かの軸で整理されているのだろうか。手探りでいい、自分なりの予想を 5 秒だけ置いてから先へ進んでほしい。

1. 実機の画面に並ぶ、4 つの列

本論に入る前に、立てたい場面を手元に置きたい。

OPS-PC01(10.1.50.10)が外の Web サーバ(203.0.113.80)を見に行く。前のお話までで腹に置いた仕組みでは、行きで送信元IPと送信元ポートが境界で書き換わって、対応表に「内側のIP+ポート / 外側のIP+ポート」の 1 行が記録される。応答が戻ってきたら、宛先のIP+ポートで対応表を引いて、内側に書き戻す。

ここで、境界 R-NAT で show ip nat translations を叩いてみる。画面に並んだのは、こんな出力。

R-NAT# show ip nat translations
Pro Inside global       Inside local        Outside local       Outside global
tcp 203.0.113.1:50001   10.1.50.10:50001    203.0.113.80:80     203.0.113.80:80

最初の Pro 列はプロトコル(tcp)。その後ろに 4 つの列が並んでいる。

• Inside global = 203.0.113.1:50001
• Inside local = 10.1.50.10:50001
• Outside local = 203.0.113.80:80
• Outside global = 203.0.113.80:80

前のお話までで腹に置いた対応表は、「内側のIP+ポート / 外側のIP+ポート」の 2 列だった。なのに、実機の画面では 4 列。Inside と Outside で 2 つに分かれていて、それぞれに local と global という枝が付いている。残りの 2 列は何を語っているのだろう。

そして、もうひとつ気になることがある。Outside local と Outside global は、どちらも 203.0.113.80:80 で同じ値が並んでいる。同じ値なら、なぜ列を分けて並べる必要があるのだろう。

この 2 つの問いに、ここで正面から向き合う。

ポイント: 実機で show ip nat translations を叩くと、画面には 4 つの列が並んでいる。前のお話で腹に置いた「内側のIP+ポート / 外側のIP+ポート」の 2 列ではなく、Inside と Outside で 2 つに分かれて、それぞれに local と global の枝が付いている。同じ値が並ぶ列もある。なぜ 4 列なのか、どんな軸で整理されているのか — この先で、その正体を解き明かす。

2. 内/外 × Local/Global、2 つの軸

ここで、列の名前を素直に分解してみたい。Inside global / Inside local / Outside local / Outside global。並びを眺めると、Inside と Outside の前置きが付いた 2 つの組と、local と global の後置きが付いた 2 つの組が、組み合わさっているのが見える。

最初の前置き、Inside と Outside。これは、境界 R-NAT から見て端末がどちら側にいるかを表している。OPS-PC01 は内側にいる端末だから Inside。EXT-WEB-SRV は外側にいる端末だから Outside。境界の左側にいるか、右側にいるかの区別。これが 1 つ目の軸。

後ろの後置き、local と global。これは、住所をどこから見たときの顔かを表している。local は「境界の内側の世界から見た住所」、global は「境界の外側の世界から見た住所」。同じ端末でも、内側から見たときの住所と外側から見たときの住所が違うことがある — これが 2 つ目の軸。

軸が 2 つあれば、組み合わせは 2×2 の 4 通り。

混乱の元は「なぜ 4 つもあるのか」ではなく、軸が見えていなかったこと。Inside / Outside という「どこにいるか」と、Local / Global という「どこから見たか」。この 2 軸が決まれば、4 つの顔は自然に並ぶ。

(念のため: ここで言う Local は「境界の内側の世界での通用」、Global は「境界の外側の世界での通用」を指している。日常的な言葉の「ローカル」「グローバル」とほぼ同じ意味だが、ここでは特に「どこから見た住所か」の軸として捉えてほしい。)

ポイント: 4 つの顔は、Inside / Outside(端末がどこにいるか)と Local / Global(どこから見た住所か)という 2 つの軸の直積でできている。混乱の元は名前の数ではなく、軸が見えていなかったこと。軸さえ決まれば、4 つの顔は 2×2 の表の中に機械的に並ぶ。

3. 4 つの顔に、具体値を当てはめる

軸が決まれば、後は具体値を当てはめるだけ。OPS-PC01 → EXT-WEB-SRV の通信を例に、4 つの顔それぞれを読み解いてみる。

Inside Local(内側にいる端末を、内側から見た住所)。OPS-PC01 が内側で持っている、実際の住所。10.1.50.10:50001。あなたが社内で OPS-PC01 を見たとき、まさにこの住所が見える。

Inside Global(内側にいる端末を、外側から見た住所)。OPS-PC01 が外側の世界に対して見せる住所。境界で書き換えた後のグローバルIP。203.0.113.1:50001。外の Web サーバから見ると、OPS-PC01 はこの住所で旅をしてきたように見える。

Outside Global(外側にいる端末を、外側から見た住所)。EXT-WEB-SRV が外側の世界で持っている、実際のグローバル住所。203.0.113.80:80。インターネットの誰から見ても、EXT-WEB-SRV はこの住所で届く。

Outside Local(外側にいる端末を、内側から見た住所)。EXT-WEB-SRV を、内側のあなたから見たときの住所。203.0.113.80:80。

ここで気になることに戻る。Outside Local と Outside Global が、どちらも 203.0.113.80:80 で同じ値になっている。なぜ同じ値なのに、列を分けて並べているのだろう。

答えは、軸の話に戻る。Outside Local と Outside Global は、軸の上では別の場所にいる。「内側から見た外側の住所」と「外側から見た外側の住所」が、たまたま同じ値だっただけ。多くの場合は同じ値になるが、概念上は別物として扱う。表に並べるときには、4 つのセルそれぞれに値が入る形を保つ。

(ここでは深入りしないが、設計によっては内側から外側を別の住所で見せたい場合があり、そのときは Outside Local と Outside Global が違う値になる。Essential では「同じ値が多いが、概念上は別の枠」までを腹に置いておきたい。)

つまり、show ip nat translations の 4 列は、軸 2×2 の表をそのまま 1 行に展開したもの。

3 台同時通信(前のお話の場面)なら、対応表には行が 3 つ並ぶ。各行が、それぞれの 4 つの顔を持つ。

R-NAT# show ip nat translations
Pro Inside global       Inside local        Outside local       Outside global
tcp 203.0.113.1:50001   10.1.50.10:50001    203.0.113.80:80     203.0.113.80:80
tcp 203.0.113.1:50002   10.1.50.20:50002    203.0.113.80:80     203.0.113.80:80
tcp 203.0.113.1:50003   10.1.50.30:50003    203.0.113.80:80     203.0.113.80:80

Inside global 列の IP 部分はすべて 203.0.113.1 で同じだが、ポート部分が 50001 / 50002 / 50003 と別。これが、前のお話で見た「ポートで対応表の行を分ける」ことの実機での姿。

ポイント: 4 つの顔それぞれは、軸 2×2 の表の各セルに対応する。Inside Local = 実際の内側のIP+ポート、Inside Global = 境界で書き換えた後のグローバルIP+ポート、Outside Local = 外側端末を内側から見た住所、Outside Global = 外側端末の本来のグローバル住所。Outside Local と Outside Global は同じ値が多いが、軸の上では別のセル。show ip nat translations の 4 列は、この表をそのまま 1 行に展開したもの。

4. 規模感の現在地と、書き換えの瞬間

show ip nat translations で「いま境界の対応表に何が並んでいるか」の現在地は読めた。けれど、対応表の行が 1 つだけなのか、3 つなのか、何百あるのか、全体の規模感は別の窓で見ないと分からない。境界がいま抱えているプール(借りているグローバルIPの空き枠)の使われ方も、別の窓で読む。

そこで使うのが show ip nat statistics。

R-NAT# show ip nat statistics
Total active translations: 3 (0 static, 3 dynamic; 3 extended)
Outside interfaces:
  GigabitEthernet0/0
Inside interfaces:
  GigabitEthernet0/1
...(略)

最初の行が、いちばん効く。Total active translations: 3。境界の対応表に、いま生きている行が 3 つあるという規模感の現在地。台数が増えれば、その分ここも大きくなる。境界が抱えている「いまの忙しさ」を一目で確認できる窓。

Outside interfaces と Inside interfaces は、「どの面が外側で、どの面が内側か」を境界が記憶している現在地。設定で決めた境界の境目が、いま生きている形で並んでいる。

(各行のカウンタには Hits / Misses / Expired translations / Dynamic mappings のような細目もあるが、ここでは Essential 粒度で「総行数と境界面の現在地」までを腹に置けばいい。各カウンタの細部は運用上の話として後の機会に譲る。)

show ip nat translations が対応エントリの現在地を読む窓なら、show ip nat statistics は規模感の現在地を読む窓。「いまどの行が生きているか」と「いま全体でどれだけの行が抱えられているか」は、別の問い。

そして、もう 1 つの窓がある。debug ip nat。

R-NAT# debug ip nat
IP NAT debugging is on
*Apr 29 14:00:01.123: NAT*: s=10.1.50.10->203.0.113.1, d=203.0.113.80 [12345]
*Apr 29 14:00:01.234: NAT*: s=203.0.113.80, d=203.0.113.1->10.1.50.10 [12345]

各行は、書き換えが起きるたびにルータが流すリアルタイムのログ。1 行目は行きの瞬間 — s=10.1.50.10->203.0.113.1、つまり送信元(s = source)が 10.1.50.10 から 203.0.113.1 に書き換わった瞬間の演出。2 行目は帰りの瞬間 — d=203.0.113.1->10.1.50.10、つまり宛先(d = destination)が 203.0.113.1 から 10.1.50.10 に書き戻った瞬間の演出。前のお話までで観念的に語っていた「行きで送信元側が書き換わる / 帰りで宛先側が書き戻る」が、リアルタイムにログで流れる窓。

ただし、debug ip nat は本番運用では負荷が高い。境界を通る全パケットの書き換えがログに流れるので、トラフィックが多い境界では止めておく方が安全。「演出を一瞬だけ流し見できる窓」として、必要なときだけ短時間だけ使う。

3 つの窓は、それぞれ別のことを語っている。

ポイント: 境界の対応表を読む窓は、show ip nat translations(各行の現在地)、show ip nat statistics(規模感と境界面)、debug ip nat(書き換えの瞬間の演出)の 3 つ。それぞれが別のことを語っている。「いまの 1 行」「全体の規模」「動きの瞬間」を、別の窓で読み分ける。debug は本番では負荷が高いので慎重に使う。

5. 同じ視点が、別のプロトコルでも生きる

ここまでの 3 つの窓 — 現在地 / 規模感 / 演出 — の使い分けは、別のプロトコルでもこれまで繰り返してきたパターン。

OSPF を扱った回では、show ip ospf neighbor で隣接の現在地を、show ip route ospf で採用された経路の規模感を、debug ip ospf adj で隣接が育つ瞬間の演出を見てきた。BGP の入門回では、show ip bgp summary でピアの規模感を、show ip bgp で経路の現在地を、show ip route bgp で採用結果を、別の窓で読み分けた。距離ベクタの回でも、設定 / 現在地 / 演出の 3 つの視点が並んでいた。

NAT でも、同じ視点が使える。

プロトコルが変わっても、「いまの対応を読む窓」「全体の規模を読む窓」「動きの瞬間を流し見する窓」の 3 つの視点で組み立てると、初見のコマンドでも何を語っているかが推測できる。書き換えの世界 NAT でも、その視点はそのまま使える。

これが、4 つの顔と一緒に手元に残しておきたい、もうひとつの収穫。

ポイント: 3 つの窓(現在地 / 規模感 / 演出)の使い分けは、距離ベクタ・リンクステート・AS を跨ぐ世界・境界の翻訳と、4 つのプロトコルで同じ形をしている。プロトコルが変わっても視点は同じ。新しいコマンドに出会ったら、まず「これは現在地を読む窓? 規模感を読む窓? 演出を流し見する窓?」と分類すれば、何を語っているかが推測できる。

旅は、4 つの顔の地図から続く

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

実機で show ip nat translations を叩いたら、画面には 4 つの列が並んでいた。前のお話までで腹に置いた「内側のIP+ポート / 外側のIP+ポート」の 2 列とは違う。なぜ 4 列なのか — その答えは、住所が Inside / Outside(端末がどこにいるか)と Local / Global(どこから見た住所か)の 2 軸を持つから。2 軸の直積で 4 つの顔ができる。Inside Local / Inside Global / Outside Local / Outside Global。show ip nat translations の 4 列は、その 4 つの顔をそのまま並べたもの。

軸さえ決まれば、4 つの顔は機械的に並ぶ。Outside Local と Outside Global が同じ値で並ぶことが多くても、軸の上では別のセル。表の構造が変わるわけではない。

3 つの窓の使い分けも、ここで揃った。show ip nat translations(各行の現在地)、show ip nat statistics(規模感と境界面)、debug ip nat(書き換えの瞬間の演出)。距離ベクタ・リンクステート・AS を跨ぐ世界で身につけた「現在地 / 規模感 / 演出」の視点が、境界の翻訳でもそのまま使える。

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

4 つの顔は、内/外 × Local/Global の 2 軸の直積でしかない。show ip nat translations の 4 列は、それをそのまま並べたもの。

明日、現場で誰かが show ip nat translations の 4 列を前にして首をかしげていたら、横から「Inside と Outside は端末がどこにいるか、Local と Global はどこから見た住所か。2 軸の直積で 4 つの顔ができる」と言葉を貸せる。show ip nat statistics の Total active translations を見て、いま境界の対応表が抱えている行の数の規模感を一緒に読む。debug ip nat を一瞬だけ流して、書き換えが本当に起きている瞬間を見せる。3 つの窓は、それぞれ別のことを語っている。

シリーズの旅は、まだ続く。地図の端からは、もうひとつの問いが立ち上がっている。

これまでの旅で、境界が外でも通用する名前を貸してくれること、行きと帰りで書き換える側が違うこと、ポートで多対1を成立させること、4 つの顔と 3 つの窓で対応表を読めること、を順に腹に置いた。書き換えで往復する翻訳の世界が、ひととおり見えた。

だが、ここまでの見方だけで、地図は全部と言い切れるのだろうか。境界の先には、まだ別の景色が残っているのだろうか。

その問いには、次のお話が正面から答えてくれる。4 つの顔と 3 つの窓を手元に残してほしい。次の世界では、ここまでの旅をもう一段だけ引いて見る景色が待っている。