前のお話で、行きと帰りで書き換わる側が違うこと、内側から外への通信(SNAT)と外側から内への通信(DNAT)で書き換わる側が反転すること、境界の手元には「いまどの対応が生きているか」を覚えておく手がかりが残っていて行きと帰りの往復を支えていることを腹に置いた。あなたの手元には「書き換える側は、通信の向きで決まる」の 1 行が残った。

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

境界が外に持っているグローバルIPは、たいていひとつしかない。そして、内側には大勢の端末がいる。同じ住所から同時に旅立った通信を、応答が戻ってきたときに境界はどうやって元の端末を見分けているのだろう。対応の手がかりは、何で行を見分けているのだろう。

ここで、その渇りに正面から向き合う。3 台のPCが同時に同じWebサーバを見に行って、3 台とも同じ 203.0.113.1 で外に出ていったら、応答も全部 203.0.113.1 宛で戻ってくる。境界はどうやって元の端末を見分けるのだろう。IPアドレスだけで足りるのだろうか。

そこで見えてくるのは、IPアドレスだけでは多対1が成立しないという行き詰まりと、ポート番号という第2の番号でそれを解く発想。境界はIPだけでなく送信元ポートまで書き換えて対応表に記録し、応答ではポートで行を見分けて元の内側に書き戻す。仕組みには PAT、NAPT、IPマスカレード という複数の名前があるが、どれも同じ翻訳。家庭用ブロードバンドルータが普段当たり前にやっている、その正体。ここまでを歩き終えると、あなたの手元には「ひとつのグローバルIPに大勢が乗れるのは、ポートで行を見分けられるから」という 1 行が残る。

考えてみよう: 本論に入る前に、5 秒だけ自分の頭で先に置いてみてほしい。あなたの会社の OPS-PC01(10.1.50.10) / OPS-PC02(10.1.50.20) / OPS-PC03(10.1.50.30)の 3 台が、同時に外の同じWebサーバ(203.0.113.80)を見に行くとする。前のお話で、行きの送信元IPは境界の外側の住所(203.0.113.1)に書き換わることを腹に置いた。3 台全部が同じ 203.0.113.1 で外に出ていったら、応答パケットは全部 203.0.113.1 宛で戻ってくるはずだ。境界は、3 つの応答のうちどれが OPS-PC01 宛で、どれが OPS-PC02 宛で、どれが OPS-PC03 宛かを、どうやって見分けるのだろう。IPアドレスだけで足りるのだろうか? もし足りないとしたら、何の手がかりが必要だろう?

1. 1 つのグローバルIPに、大勢の内側

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

境界が外に持っているグローバルIPは、たいていひとつ。家庭でも、小さな会社でも、ISPから割り当てられるグローバルIPは 1 個か、せいぜい数個。一方、内側には端末が大勢いる。家なら PC、スマホ、タブレット、テレビ、ゲーム機。会社ならフロアの PC、サーバ、業務端末、複合機。みんなが同時にネットを使う。この場面が、ここから歩き始める出発点。

前のお話で、行きのパケットが境界 R-NAT を通る瞬間に送信元IPが書き換わることまで腹に置いた。OPS-PC01(10.1.50.10)が単独で外のWebサーバ(203.0.113.80)を見に行く場合、行きで送信元IPが 203.0.113.1 に書き換わり、応答は 203.0.113.1 宛で戻ってきて、境界が 10.1.50.10 に書き戻す。1 台の往復なら、対応表に 1 行あればいい。

ここで、OPS-PC01 / OPS-PC02 / OPS-PC03 の 3 台が同時に同じWebサーバを見に行く場面を考えてみたい。3 台それぞれの行きのパケットは、境界を通る瞬間に送信元IPが書き換わって 203.0.113.1 になる。3 本の通信が、外側からは全部「送信元 = 203.0.113.1」として見える。境界の手元の対応表には、3 行ぶんの対応が並んでいないといけない。そして、応答が戻ってきたときに、3 行のうちどの行を引けばいいのかを、境界は何かの手がかりで見分ける必要がある。その手がかりは、いまの設計で足りているのだろうか。

ポイント: 境界が外に持っているグローバルIPはたいていひとつ。けれど内側には大勢の端末がいる。3 台が同時に外と通信したら、対応表には 3 行が並ぶ。境界が応答を元の端末に書き戻すには、3 行のどれを引けばいいかを見分ける手がかりが要る。この先で、その手がかりがIPアドレスだけでは足りないことに気づく。

2. IP だけでは、行が分けられない

実際に、3 台の同時通信を、行きと帰りに分けて並べてみたい。前のお話で見た SNAT(行きで送信元を書き換える、応答で宛先を書き戻す)に沿って追ってみる。

行きのパケットを 3 本並べる。出発時はそれぞれ別の送信元IPで(OPS-PC01 = 10.1.50.10、OPS-PC02 = 10.1.50.20、OPS-PC03 = 10.1.50.30)、宛先IPは 3 本とも 203.0.113.80。境界 R-NAT を通過する瞬間に、3 本それぞれの送信元IPが 203.0.113.1 に書き換わる。

境界通過後のパケットを並べると、こうなる:

外から見ると、3 本のパケットは全部「送信元 = 203.0.113.1、宛先 = 203.0.113.80」の同じ姿。住所欄だけでは、もう区別がつかない。

外のWebサーバが応答を返す。応答パケットは、送信元と宛先が入れ替わるから、3 本とも次の姿で 203.0.113.1 宛に戻ってくる。

• 送信元IP = 203.0.113.80
• 宛先IP = 203.0.113.1

ここで困りごとが発生する。境界 R-NAT は 3 本の応答を受け取った。住所欄を見ると、どれも同じ「送信元 = 203.0.113.80、宛先 = 203.0.113.1」。境界は、3 本のうちどの応答が OPS-PC01 宛で、どれが OPS-PC02 宛で、どれが OPS-PC03 宛かを、どうやって見分ければいいのだろう。

前のお話で見た「対応の手がかり」を引きたい。境界の手元には、行きで書き換えた対応がメモされているはず。でも、もし対応表に「内側 = 10.1.50.10、外側 = 203.0.113.1」「内側 = 10.1.50.20、外側 = 203.0.113.1」「内側 = 10.1.50.30、外側 = 203.0.113.1」の 3 行が並んでいるとしたら — 応答パケットの宛先 203.0.113.1 で対応表を引いたとき、どの行が当たるのかが決まらない。

IPアドレスだけでは、対応表の行を分ける手がかりが足りない。

境界に応答が戻ってきた時点で、宛先(203.0.113.1)は 3 本とも同じ。送信元(203.0.113.80)も 3 本とも同じ。住所欄の 2 つだけを見ても、行が選べない。

対応表の各行を区別する手がかりとして、IPの他にもう一つ別の番号が要る。

ポイント: 境界が外に持っているグローバルIPがひとつしかない場面で、3 台が同時に外と通信すると、行きでも応答でも住所欄が全部同じ姿になる。境界の対応表は 3 行になっているはずだが、IPアドレスだけでは応答が戻ってきたときにどの行を引けばいいかが決まらない。対応表の行を見分けるには、IP の他にもう一つ別の番号が要る。

3. ポートという第2の番号

その「もう一つ別の番号」は、すでに身近にある。通信のパケットには、IP ヘッダの 2 つの住所欄(送信元IPと宛先IP)に加えて、その後ろにもうひとつ、TCPやUDPの窓口番号 — ポート番号 — が乗っている。ポート番号は 0 から 65535 までの数字で、送信元ポートと宛先ポートの 2 つが、IP の 2 つの住所欄と並んでパケットの先頭付近に並ぶ。

ポート番号は、もともと「同じIPの中の複数のサービスや通信を区別する窓口」として使われている。Webサーバなら 80、HTTPS なら 443 のようにサービスごとに番号が決まっているものもあるし、PCのアプリが外と通信を始めるときに OS が動的に割り当てる番号もある。

3 台のPCのアプリが同時に外を見に行くとき、それぞれの送信元ポートには、OS が動的に割り当てた別々の番号が入る。たとえば次のように:

(50001 / 50002 / 50003 はあくまで説明用の例。実際の番号はOSが場面ごとにその都度割り当てる。)

IP は 3 台とも違う。ポートも 3 台とも違う。IP+ポートの組で見れば、3 本の通信は別々の組として区別がつく。境界 R-NAT はここで「ひとひねり」する。行きで送信元IPだけでなく送信元ポートも書き換え、対応表の行に IP+ポートの組を書く。

対応表の中身(概念的なイメージ):

外側のIPは 3 行とも同じ 203.0.113.1。でも、外側のポートが 50001 / 50002 / 50003 と別。IP+ポートの組で見れば、3 行はちゃんと別々の行として並んでいる。

(実際の境界では、外側のポートは行きの送信元ポートをそのまま再利用することもあれば、衝突を避けるために別の番号に書き換えることもある。ここで大事なのは「内側のIP+ポートと、外側のIP+ポートの対応が、対応表の各行に並んでいる」という構造。)

応答が戻ってくるときは、行きの送信元/宛先が入れ替わる。応答パケット 3 本はすべて送信元 = 203.0.113.80 + 80、宛先 IP = 203.0.113.1 で同じ。違うのは宛先ポートだけで、それぞれ 50001 / 50002 / 50003。境界 R-NAT は応答パケットの宛先(203.0.113.1 + 宛先ポート)で対応表を引き、ポートでヒットした行を見つけて、宛先を内側のIP+ポートに書き戻す。50001 なら 1 行目を引いて 10.1.50.10 + 50001 に、50002 なら 2 行目を引いて 10.1.50.20 + 50002 に、50003 なら 3 行目を引いて 10.1.50.30 + 50003 に。

ポート番号という第2の番号があるから、対応表の行が分けられて、応答が正しい内側に戻る。

この設計の名前は、PAT(Port Address Translation)。Cisco IOS ではこの呼び名が広く使われる。同じ仕組みは、RFC 用語では NAPT(Network Address Port Translation)、Linux の世界では IPマスカレード(IP Masquerading)という名前でも呼ばれる。3 つの名前は、どれも同じ翻訳を指している。

ひとつのグローバルIPの上で、ポート空間(0 から 65535 までの数万の番号)を使って多対1の対応を成立させる。これが、ひとつのグローバルIPに大勢の通信が乗れる仕掛け。境界が抱えている対応表のサイズや管理の細部は機種・運用に依存するが、規格の上では数千〜数万のオーダーの同時通信が、ひとつのグローバルIPの上で並走できる桁感を持つ。

ポイント: IP の住所欄に並んで、TCP / UDP の送信元ポートと宛先ポートという L4 の 2 つの窓口番号がパケットに乗っている。境界は行きで送信元IPだけでなく送信元ポートも書き換えて、対応表に IP+ポートの組で行を書く。応答が戻ってきたら、宛先のIP+ポートで対応表を引いて、ポートで行を見分けて元の内側に書き戻す。PAT(Port Address Translation)、NAPT、IPマスカレード という 3 つの名前は、どれも同じ仕組みを指している。

4. 家庭用ルータの正体

ここまでの仕組みは、ひとつ思い当たる場面につながる。家のWi-Fiルータ。

ISPから家に割り当てられているグローバルIPは、ふつう 1 個。けれど、家の中には PC、スマホ、タブレット、スマートテレビ、ゲーム機、スマート家電など何台ものデバイスがWi-Fiにぶら下がり、みんなが同時に動画やメッセンジャーやオンライン対戦を動かしている。

ぶら下がっているデバイスは家の中だけで意味を持つプライベートIP(192.168.x.x や 10.x.x.x 等)を持ち、外に出るときに境界の Wi-Fi ルータが家の 1 個のグローバルIPに名乗り直す。Wi-Fi ルータは各デバイスの通信について(内側のIP, 内側のポート)→(外側のIP, 外側のポート)の対応を対応表に記録し、応答が戻ってきたらポートで行を見分けて書き戻している。やっていることは、ここで見た PAT そのもの。

前のお話の最後で、家庭用Wi-Fiルータの設定画面の「ポートフォワーディング」「仮想サーバ」のメニューに触れた。あれは外から内への通信を境界が宛先を書き換えて中の特定の端末へ振り直す DNAT の設計。それとは別に、内側から外への通信のために PAT が背景で常に動いていて、こちらは設定画面に明示的なメニューとしては出てこないことが多い(ISP接続を有効にした時点で自動的に動いている)。家のWi-Fiに何台もぶら下がっているのに普段問題なく動いているのは、PAT が当たり前のように対応表を回しているから。普段は気にしないこの仕組みが、ここまでの手土産。

ポイント: 家庭用ブロードバンドルータが、ISPから割り当てられた 1 個のグローバルIPの上で、家の中の何台もの端末を同時に外と通信させているのは、PAT が対応表に IP+ポートの行を記録して回しているから。普段は意識せず使っているWi-Fi の挙動が、ここで見た多対1の書き換えそのもの。これが PAT の正体。

多対1は、ポート番号で成立する

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

境界が外に持っているグローバルIPはたいていひとつ。内側には大勢の端末がいる。3 台が同時に外と通信したら、行きでも応答でも住所欄は全部同じ姿になる。IPアドレスだけでは、対応表の行を分ける手がかりが足りない。

足りない手がかりはポート番号。境界は行きで送信元IPだけでなく送信元ポートも書き換え、対応表に IP+ポートの組で行を書く。応答が戻ってきたら、宛先のIP+ポートで対応表を引いて、ポートで行を見分けて元の内側に書き戻す。多対1の翻訳は、ポートという第2の番号があるから対応表の行が分けられて成立する。それだけ。

この設計には、3 つの名前がある。Cisco IOS では PAT(Port Address Translation)、RFC では NAPT(Network Address Port Translation)、Linux の世界では IPマスカレード。どれも同じ仕組みを指している。家庭用ブロードバンドルータが当たり前にやっているのが、この PAT。家のWi-Fiに何台もぶら下がっているのに普段問題なく動いているのは、境界のルータが対応表を回し続けているから。

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

ひとつのグローバルIPに大勢が乗れるのは、ポートという第2の番号で対応表の行を見分けられるから。

明日、家のWi-Fiに何台もデバイスがぶら下がっているのを見たら、それが、ここで扱った PAT の現場。境界の対応表に各デバイスの(内側のIP, 内側のポート)→(外側のIP, 外側のポート)の行が並んでいて、応答が戻ってくるたびにポートで行を見分けて書き戻している。家や小規模オフィスで多数の通信が同じ外側IPに乗るとき、境界は有限なポート番号を行の目印として使っている、という見方を手元に持っておきたい。

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

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

その問いには、次のお話が正面から答えてくれる。ポートで行を見分ける、という仕掛けを手元に残してほしい。次の世界では、ここまでに登場した住所たちを整理して読む練習に出会っていく。