前のお話で、組織の境界には外でも通用する世界で一意な住所が用意してあって、外に出る瞬間に住所が名乗り直されることを腹に置いた。応答は世界で一意な住所宛で戻ってきて、境界が内側の住所に書き戻す。仕組み全体の名前は NAT。
けれど、お話の最後にも、ふたつの渇きが残されていた。
境界での名乗り直しは、外との一回の往復を確かに成立させた。けれど、境界の手元には、その往復を支えるために何かが残っているはずだ。境界はそれをどう持ち続けているのだろう。そして、境界での名乗り直しは、いつもこの形で起きるものなのだろうか。
IPパケットの先頭(IPヘッダ)には、住所が 2 つ並んでいる。送信元IPと宛先IPの 2 つ。前のお話で、外に出る瞬間に住所が書き換わるところまでは見た。けれど、書き換わるのは送信元側か、宛先側か、それとも両方か。行きで書き換わったとして、応答が戻ってくるときは何が書き換わっているのだろう。さらに、社内に置いたサーバを外に公開するような場面 — 外から先に通信が来る場面では、境界はどちらの住所欄を書き換えているのだろう。前のお話と同じ書き換え方なのだろうか。
書き換える側は、通信の向きで決まる。
境界がパケットを書き換えるのは、IPヘッダの送信元と宛先のどちらか片方だけだ。内側から外へ出る通信と、外から内へ届く通信では、行きで書き換わる側が反転する。行きと帰りでは送信元と宛先が入れ替わるから、書き戻る側も反対になる。
考えてみよう
あなたが OPS-PC01(10.1.50.10)から外のWebサーバ(203.0.113.80)を見に行く場面を想像する。行きのパケットが境界を通る瞬間、送信元のIPが境界の外側の住所に書き換わることは腹に置いた。では、応答パケットが戻ってくるとき、境界では何が書き換わるのだろう。送信元IPか、宛先IPか、それとも両方か。行きと帰りで、書き換わる側は同じだろうか、違うだろうか。
1. IPヘッダには 2 つの住所欄が並ぶ
IPパケットの先頭(IPヘッダ)には、住所が 2 つ並んでいる。送信元IPと宛先IPの 2 つ。どちらも、そのパケットがどこから来てどこへ向かうのかを表すラベルだ。
OPS-PC01(10.1.50.10)から外のWebサーバ(203.0.113.80)を見に行くとき、行きのパケットの 2 つの住所欄はこうなる。
- 送信元IP = 10.1.50.10
- 宛先IP = 203.0.113.80
外のWebサーバが応答を返そうとすると、住所欄は入れ替わる。応答の宛先には行きの送信元が入り、応答の送信元には行きの宛先が入る。
- 送信元IP = 203.0.113.80
- 宛先IP = 10.1.50.10
これは、双方向の通信が成立する自然な裏返しだ。行きで A から B へ送ったなら、応答は B から A へ戻ってくる。送信元と宛先は、行きと帰りで入れ替わる。
前のお話で、境界は外に出る瞬間に住所を書き換えていた。書き換えられる対象は、この 2 つの住所欄のどちらかのはずだ。両方を同時に書き換えているのか、それとも片方だけなのか。行きと帰りで、書き換える側は同じなのか、違うのか。
答えは、片方だけだ。行きと帰りで、書き換える側は違う。
2. 内側から外へ — 行きで送信元、帰りで宛先
あなたの会社の OPS-PC01(10.1.50.10)が、外のWebサーバ(203.0.113.80)を見に行く通信。行きのパケットが境界を通る瞬間、送信元のIPが境界の外側の住所(203.0.113.1)に書き換わる。そのときの 2 つの住所欄を追ってみる。
OPS-PC01 を出発したとき:
- 送信元IP = 10.1.50.10
- 宛先IP = 203.0.113.80
境界 R-NAT を通過する瞬間に、送信元IPだけが書き換わる:
- 送信元IP = 203.0.113.1(書き換わった)
- 宛先IP = 203.0.113.80(変わらず)
外のインターネットへ送り出されたとき:
- 送信元IP = 203.0.113.1
- 宛先IP = 203.0.113.80
書き換わったのは、送信元IPだけ。宛先IPは変わらない。境界が手をつけているのは、パケットの「自分の名前」の側だけで、「届け先の名前」の側ではない。
応答が戻ってくるときはどうだろう。
外のWebサーバを出発したとき:
- 送信元IP = 203.0.113.80
- 宛先IP = 203.0.113.1
境界 R-NAT を通過する瞬間に、宛先IPだけが書き戻る:
- 送信元IP = 203.0.113.80(変わらず)
- 宛先IP = 10.1.50.10(書き戻った)
OPS-PC01 に届いたとき:
- 送信元IP = 203.0.113.80
- 宛先IP = 10.1.50.10
書き戻ったのは、宛先IPだけ。送信元IPは変わらない。
行きでは送信元、帰りでは宛先。書き換わる側が、行きと帰りで違う。これは、行きと帰りで送信元と宛先がそもそも入れ替わっていることの自然な裏返しだ。境界が「行きでこの内側のIPを外側のIPに書き換えた」という対応を覚えていれば、応答が境界に戻ってきたときに、応答の宛先(行きで書き換えた外側のIPがそのまま入っている)を見て、対応の手がかりを引いて、内側のIPに書き戻すことができる。
内側から外への通信で、行きの送信元IPを書き換えるこの設計のことを SNAT(Source NAT)と呼ぶ。送信元(Source)を書き換える NAT、という素直な命名だ。家庭用ブロードバンドルータも企業の境界ルータも、内側のPCが外のインターネットを見るときには、自動的にこの SNAT が動いている。
3. 外側から内へ — 行きで宛先、帰りで送信元
あなたの会社が、社内に Web サーバ(住所 10.1.50.80、本シリーズでは WEB-SRV-INSIDE と呼んでおく)を持っていて、それを外のインターネットからも見られるようにしたい場面。たとえば、社外のお客さま向けのサービスを社内サーバで動かしている、といった想定だ。
社内サーバの住所 10.1.50.80 は内側でだけ意味を持つ住所だ。外のインターネット側からは、10.1.50.80 という宛先で直接届くことができない。前のお話で見た通り、世界中に同じ番号がたくさん並んでいるからだ。
外のクライアントから見えているのは、境界の外側のグローバルIP(203.0.113.1)だけ。境界がそのグローバルIPで通信を受け付け、行きの宛先IPを社内サーバの内側の住所(10.1.50.80)に書き換えて、社内へ振り直す。
外のクライアントを出発したとき:
- 送信元IP = 外のクライアントの住所
- 宛先IP = 203.0.113.1
境界 R-NAT を通過する瞬間に、宛先IPだけが書き換わる:
- 送信元IP = 外のクライアントの住所(変わらず)
- 宛先IP = 10.1.50.80(書き換わった)
WEB-SRV-INSIDE に届いたとき:
- 送信元IP = 外のクライアントの住所
- 宛先IP = 10.1.50.80
書き換わったのは、宛先IPだけ。送信元IPは変わらない。境界が手をつけているのは、パケットの「届け先の名前」の側だけで、「自分の名前」の側ではない。
§2 では行きで「送信元」が書き換わっていた。§3 では行きで「宛先」が書き換わっている。書き換わる側が反転している。
WEB-SRV-INSIDE を出発したとき:
- 送信元IP = 10.1.50.80
- 宛先IP = 外のクライアントの住所
境界 R-NAT を通過する瞬間に、送信元IPだけが書き戻る:
- 送信元IP = 203.0.113.1(書き戻った)
- 宛先IP = 外のクライアントの住所(変わらず)
外のクライアントに届いたとき:
- 送信元IP = 203.0.113.1
- 宛先IP = 外のクライアントの住所
書き戻ったのは、送信元IPだけ。
内側から外への通信は、行きで送信元、帰りで宛先。外側から内への通信は、行きで宛先、帰りで送信元。書き換わる側が、通信の向きで反転する。
外側から内への通信の側を DNAT(Destination NAT)と呼ぶ。宛先(Destination)を書き換える NAT、という素直な命名だ。家庭用Wi-Fiルータの設定画面に「ポートフォワーディング」「仮想サーバ」という名前で並んでいるメニューが、この DNAT だ。家庭で外から見えるのは境界の外側のIPひとつだけだから、内側の特定の端末(ゲーム機、NAS、ホームサーバなど)へ届けたいときは、境界に「外側のこの宛先で来た通信は、内側のこの端末へ振り直す」という対応のルールを置く。
4. 行きで書いて、帰りで読み戻す — 対応の手がかり
境界の手元には、対応の手がかりが残っている。
SNAT の場面でいえば、行きで送信元IPを 10.1.50.10 から 203.0.113.1 に書き換えたとき、境界はその対応(「内側 10.1.50.10 を、外側 203.0.113.1 に名乗り直して外へ出した」)を、自分の手元にメモする。応答が 203.0.113.1 宛で戻ってきたとき、そのメモを引いて、宛先を 10.1.50.10 に書き戻す。行きで書いて、帰りで読み戻す。
DNAT の場面でも同じ仕掛けが動いている。行きで宛先を 203.0.113.1 から 10.1.50.80 に書き換えたとき、境界はその対応を手元にメモする。応答が WEB-SRV-INSIDE から戻ってきたとき、そのメモを引いて、送信元を 203.0.113.1 に書き戻す。
この対応の手がかりが境界の手元に残っているからこそ、行きと帰りの往復が破綻なく成立する。書き換えは、瞬間的な一回限りの動作ではない。書き換えた対応を覚えていて、応答が戻ってきたときに引き戻す。そういう、行きと帰りを橋渡しする仕掛けだ。
対応の手がかりの中身(具体的にどんな形で並んでいるのか / どのくらい生きているのか / どこまで覚えていられるのか)については、後ろのお話で順に近寄っていく。ここで受け取りたいのは、「境界の手元に対応の手がかりが残っていて、行きで書き、帰りで読み戻している」という最上位の構造まで。
書き換える側は、通信の向きで決まる
家のWi-Fiルータの設定画面を開いたとき、「ポートフォワーディング」や「仮想サーバ」のメニューが並んでいるのを見たら、それが、ここで扱った DNAT の姿だ。外から先に来た通信を、境界が宛先を書き換えて、内側の特定の端末へ振り直す設計。会社で『社内のサーバを外に公開した、でも外からつながらない』という相談に出会ったら、『境界で行きの宛先が内側のサーバへ書き換わるルールが入っているか』を最初の問いにしてほしい。書き換えるのは行きの宛先 — その対応関係が境界に置かれているか、という視点が、最初の見立てを支える。
書き換える側は、通信の向きで決まる。
けれど、境界が外に持っているグローバルIPは、たいていひとつしかない。そして、内側には大勢の端末がいる。同じ 203.0.113.1 から同時に旅立つ通信を、境界はどうやって区別しているのだろう。対応の手がかりは、何で行を見分けているのだろう。
その問いには、次のお話が正面から答えてくれる。