こんにちは！SREとして日夜クラウドとコンテナネットワークの海を泳いでいるライターの私です。
クラウドの世界へ足を踏み入れたばかりの頃、「なんだか通信が途中でプツッと途切れる…」「大きなファイルをアップロードしようとするとタイムアウトする…」そんな不可解な現象に頭を悩ませたことはありませんか？
その裏側では、もしかすると今回のお題である「IPフラグメンテーション」と「NATゲートウェイ」のドラマチックな攻防戦が繰り広げられているのかもしれません。
今回は、パケットの旅路に思いを馳せながら、この一見難解なテーマを身近な例えと一緒に一歩ずつ紐解いていきましょう！
—
1. そもそも「IPフラグメンテーション」ってなに？（郵便配達で考えてみよう）
インターネットの世界では、私たちが送受信するデータはすべて「パケット」という小さな封筒に入れられて運ばれています。この封筒には「一度に運べる最大の大きさ」というルールがあり、これをネットワーク用語でMTU（Maximum Transmission Unit）と呼びます。大体のネットワークでは、この大きさは 1500 バイトに設定されています。
さて、ここに 3000 バイトの特大サイズの手紙（データ）があるとします。
- そのままでは門前払い：
大きな封筒のままでは、途中の狭い道（ネットワーク機器）を通れません。
- そこで登場するのが「フラグメンテーション（断片化）」：
郵便局の窓口（ルーターなど）で、大きな手紙をパパッと2枚の小さな封筒に切り分け、それぞれに宛先を書いて送り出す作業のことです。
目的地に着いた受信側のコンピュータは、「あ、これとこれはさっきの手紙の続きだな」とパズルを合わせるように元の形に組み立て直します。これが、IPフラグメンテーションの基本的な仕組みです。
—
2. クラウドの関所「NATゲートウェイ」をパケットが通るとき
私たちがAWSの NAT Gateway やGCPの Cloud NAT といったマネージドサービスを使うとき、プライベートサブネットにあるたくさんのサーバー（コンテナ含む）が、1つのグローバルIPアドレスを共有して外のインターネットへ出られるようになっています。
ここで、先ほどのように「途中で切り分けられた（フラグメントされた）パケット」がNATゲートウェイにやってきたら、いったいどうなるでしょうか？
一歩ずつ、パケットの気持ちになって考えてみましょう。
NATゲートウェイは「記憶力抜群の受付係」
NATゲートウェイは、ただパケットを右から左へ流すだけの存在ではありません。プライベートIPアドレスをグローバルIPアドレスに書き換える（＝IPマスカレードを行う）ため、「どのサーバーが、どの通信をしているか」をメモ帳（セッションテーブル）にしっかり記録しています。
通常、通信の目印になる「TCPポート番号」は、パケットの最初のほう（ヘッダー部分）に書かれています。
ここに大きなトラップがあるのです！
もし、パケットが途中でバラバラに切り刻まれてしまったらどうなるでしょう？
なんと、2枚目以降の切り分けられたパケットには、TCPポート番号が書かれていないのです！（ポート番号は一番最初のパケットにしか書かれていないことが多いのです）
「あれっ？ この2枚目の手紙、宛先は書いてあるけど、どの部屋の誰宛のメモだっけ…？」
NATゲートウェイの受付係は困ってしまいます。この状態のままセキュリティの厳しい設定（ファイアウォールなど）をすり抜けようとすると、NATゲートウェイがパケットを正しくルーティングできず、通信が迷子になってしまうという現象が起きます。
クラウドのNATはパケットを「お裁縫」する
AWSやGCPのような現代のクラウドの強力なNATゲートウェイは、このピンチをスマートに乗り越えます。
バラバラになって届いたフラグメントパケットを、一度NATゲートウェイの内部で「パッと組み立て直して（再組み立て）」から、ポート番号を確認して宛先を書き換え、必要に応じて再び切り分ける（再分割）という、まるで職人芸のような処理を行ってくれているのです。
—
3. セキュリティとパフォーマンスの落とし穴
「なるほど、クラウドのNATが上手に組み立て直してくれるなら安心だね！」……と言いたいところですが、SREの現場ではここからが腕の見せ所です。実は、このフラグメントされたパケットの処理には、いくつか注意すべきリスクが潜んでいます。
1. CPUへの負荷（DDoS攻撃の温床に）
悪意ある攻撃者が、あえて細切れにしたパケットを大量に送りつけると、NATゲートウェイやルーターは「組み立て作業」に追われてCPUリソースを大量に消費してしまいます。これが原因で、正規の通信までスローダウンしてしまうことがあります。
2. MSS Clamping（パスMTUディスカバリーの重要性）
そもそも、最初からNATを通過するような大きなパケットを生まないようにするのが一番の対策です。TCPの接続開始時に「うちはこれくらいのサイズしか受け取れないよ（MSS）」とあらかじめ教え合う仕組みや、ルーター同士で「ここから先はもっと小さいサイズにしてね」と調整する機能（MSS Clamping）を適切に設定することが、インフラエンジニアの腕の見せ所となります。
—
4. 実務で役立つ！KubernetesやLinuxでの確認・設定アプローチ
それでは、私たちが普段のインフラ構築やトラブルシューティングで、このフラグメント問題にどう向き合えばよいのか、具体的なアプローチを見ていきましょう。
例えば、KubernetesのPodから外部へ大きなデータを送信する際、ノード（EC2やGCEインスタンス）のMTU設定と、コンテナネットワークプラグイン（CiliumやCalicoなど）のカプセル化（VXLANやGeneveなど）のオーバーヘッドによって、パケットが思わぬサイズオーバーを起こすことがあります。
Linux環境で現在のインターフェースのMTUを確認したり、調整したりするには、以下のようなコマンドを使います。
# 現在のネットワークインターフェース（例: eth0）のMTUを確認する
ip link show eth0
# 出力例:
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP ...もしクラウド上の仮想ルーターやコンテナ基盤でMTUのミスマッチが疑われる場合、パケットが勝手にフラグメントされないように「DF（Don’t Fragment：フラグメント禁止）フラグ」を立てたテストパケットを ping で飛ばして確認することができます。
# サイズ 1472 バイト（IPヘッダー20byte + ICMPヘッダー8byte ＝ 合計1500byte）のパケットを
# フラグメント禁止(-M do)の条件で Google のパブリックDNSへ送信してみる
ping -c 4 -M do -s 1472 8.8.8.8もしこのコマンドで Frag needed and DF set というエラーメッセージ返ってきたら、「おっと、途中の道が狭すぎるから、パケットのサイズをもっと小さくしなきゃいけないな」と気づくことができます。
KubernetesのPodやサービスの定義、あるいはクラウドのVPC設定（DHCPオプションなど）で適切なMTU（例: カプセル化を考慮して 1400 や 8901 など）を明示的に指定してあげることで、そもそもフラグメンテーションが発生しない「スムーズで美しいネットワーク」をデザインできるようになります。
—
まとめ
いかがでしたでしょうか？
「IPフラグメンテーションとNATゲートウェイの再組み立て」と聞くと、なんだか冷たくて難解な専門用語の羅列に聞こえますが、本質は「大きな荷物を上手に小さく分けて、受付でしっかり管理しながら安全に届ける仕組み」に他なりません。
クラウドやコンテナのネットワークを設計・運用する際は、パケットがどこを通るときにどんな変身（分割・組み立て）をするのか、そのストーリーを頭に思い描けるようになると、トラブルシューティングのスピードが劇的に上がります。
ぜひ、日々のインフラ触る楽しさを感じながら、一歩ずつマスターしていってくださいね！それではまた次回の技術でお会いしましょう。
コメント