IPフラグメンテーションの悪夢：NATゲートウェイ内部でパケットが「粉砕」されるとき
クラウドネイティブなインフラの設計において、パケットがルーティングされ、トランスポート層がセッションを確立し、アプリケーション層がデータをやり取りする――この一連の流れは、普段私たちが触れる抽象化されたレイヤーの向こう側で、極めて泥臭く、かつ精緻な物理的・論理的演算の積み重ねによって成り立っている。
とりわけ、パケットサイズがインターフェースの最大転送単位（MTU）を超過した瞬間に発生する「IPフラグメンテーション」と、それがパブリッククラウドの境界にそびえる「NATゲートウェイ」を通過する際の挙動は、多くのインフラエンジニアが頭を悩ませるブラックボックスの一つだ。
教科書を開けば「MTUを超えるパケットは分割され、宛先で再組み立てされる」と一言で片付けられる。しかし、SREの現場で幾多の障害夜間対応を経験した者なら知っているはずだ。NATゲートウェイという「ステートフルな変換装置」が絡んだ途端、この単純なフラグメント処理は、CPU枯渇、セッションテーブルの圧迫、さらには巧妙なレイヤー3セキュリティバイパス攻撃の温床へと変貌する。
今回は、パケットレベルの内部挙動からLinuxカーネルのチューニング、そしてTLSハンドシェイクの最適化に至るまで、極限のパフォーマンスと堅牢性を追求するプロフェッショナルに向けたディープな知見を紐解いていこう。
—
1. パケットレベルの内部挙動：NATゲートウェイでの再組み立て（Reassembly）の真実
まず直面する最大の誤解は、「NATゲートウェイは、通過するフラグメント化されたパケットをその場で即座に個別変換し、スルーしている」という思い込みだ。
実際のパブリッククラウド（AWSのNAT GatewayやGCPのCloud NATなど）や、Linuxの netfilter (iptables/nftables の MASQUERADE / SNAT) が内部でどう動いているか。結論から言えば、高度なステートフルNATは、最初のフラグメント（L4ヘッダーを含むもの）を受信しただけでは、後続のフラグメントを安全に変換できない。
フラグメントの構造とL4情報の欠落
IPパケットがMTU（通常はクラウド環境の標準である 1500 バイト、あるいはJumbo Frameの 9001 バイトなど）を超えると、ルーターや送信元ホストによって分割される。
分割されたパケットのうち、オフセットが 0 の最初のフラグメントには、IPヘッダーの他にTCPやUDPのポート番号といったL4ヘッダーが含まれている。しかし、オフセットが 0 以外の後続フラグメントには、L4ヘッダーが一切含まれていない。
ここでNATゲートウェイの立場になって考えてみてほしい。後続フラグメント単体では「どのコネクション（どのローカルIP・ポートから、どのグローバルIP・ポートへの変換か）」を特定するための情報がゼロなのだ。
ゲートウェイ内部での強制的なバッファリングと再組み立て
このジレンマを解決するため、まともなルーターやNATゲートウェイ（およびその基盤となるカーネルのネットワーキングスタック）は、次のような挙動を示す。
1. ファーストフラグメントの捕捉: オフセット 0 のパケットを受け取り、L4ヘッダーからコネクションを特定し、NATセッションテーブルのエントリを引く（または新規作成する）。
2. 後続フラグメントの待ち受けとバッファリング: オフセット非 0 のパケット群を一時的にメモリ上のキューにバッファリングする。
3. 完全なパケットの再組み立て (Reassembly): すべてのフラグメントが揃った段階で、メモリー上で元の巨大なIPパケットを一時的に復元する。
4. NAT変換の適用: 復元されたパケット全体に対して、IPアドレスとポート番号の書き換えてチェックサムを再計算する。
5. 再分割 (Re-segmentation / Fragmentation): 変換後のパケットサイズが、出力側インターフェースのMTUを再び超えている場合、再度細かく分割し直して宛先へ送出する。
お気づきだろうか。NATゲートウェイは、単なる「パケットの転送屋」ではなく、場合によってはレイヤー3の再組み立てと再分割という重いCPU処理をインラインで強制されているのだ。これが、トラフィックが高負荷な環境でフラグメントが多発した際、NATゲートウェイのCPU使用率が跳ね上がり、パケットドロップやレイテンシの悪化を引き起こす根本原因である。
—
2. トランスポート層とTLSハンドシェイクの最適化：MSS Clampingの極意
このような無駄なCPUサイクルやパケットロスを避けるための王道かつ最大の防御策が、MSS (Maximum Segment Size) Clamping である。
パケットがNATゲートウェイやVPNトンネル（IPsecやVXLANなど、オーバーヘッドで実効MTUが削られる環境）を通過する場合、レイヤー3でのフラグメント発生を防ぐ最もエレガントな方法は、TCPのネゴシエーション段階でパケットサイズをあらかじめ小さく制限することだ。
Linuxカーネル（iptables / nftables）によるMSS Clampingの設定
Kubernetesのノードや、プライベートサブネットのゲートウェイとして機能するLinuxルーターでは、netfilter を用いてSYNパケットのTCPオプション（MSS）を強制的に書き換える。
# iptablesを使用して、ルーティング通過時のTCP MSSを強制的に1360バイトにクランプする
# (例: 標準MTU 1500から、IP/TCPヘッダーのオーバーヘッド40バイトを引いた値、あるいはそれ以上安全な値)
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360
# nftablesを使用する場合の同等設定
sudo nft add rule ip filter forward tcp flags & (syn | rst) == syn tcp option maxseg size set 1360> SREの現場知見:
> クラウド環境（AWS等）でマネージドなNAT Gatewayを使用している場合、AWS側がよしなに処理してくれるケースが多いが、独自にEC2でNATインスタンスを構築している場合や、複雑なマルチクラウド・オンプレミス間のDirectConnect/VPN環境では、このMSS Clampingが適切に行われていないために、特定の巨大なTLS証明書チェーンを持つリクエストだけが沈黙（ブラックホール化）するというトラップに頻繁に遭遇する。
TLSハンドシェイクとフラグメンテーションの悲劇
なぜTLSハンドシェイクがフラグメンテーションの標的になりやすいのか。
現代のセキュリティ要件では、TLS 1.3が主流となり、暗号スイートや証明書チェーンの肥大化に伴って、初期のClientHelloメッセージやServerHelloメッセージのサイズが簡単に 1500 バイトを超える。
もし、Path MTU Discovery (PMTUD) が途中のファイアウォール（ICMPのブロックなど）によって正常に機能していない状態で、これら巨大なTLSハンドシェイクパケットがフラグメント化されてNATを通過しようとすると、前述したバッファリングと再組み立てのコストが直撃する。さらに悪いことに、セキュリティ機器やDDoS防御装置が、セキュリティ上の理由（後述）からフラグメントパケットそのものをドロップするように設定されている場合、TLSハンドシェイクは永遠に完了せず、接続はタイムアウトを迎える。
—
3. セキュリティ上の脅威：IPフラグメント攻撃とNATの脆弱性
パフォーマンスの観点だけでなく、セキュリティの観点からも、IPフラグメンテーションとNATの組み合わせは厳重な警戒が必要だ。攻撃者は、このプロトコルの仕様の隙を突いてセキュリティ境界を突破しようとする。
1. ティアードロップ攻撃 (Teardrop Attack) の変種
古典的なTeardrop攻撃は、意図的にオーバーラップするフラグメントオフセット値を送信し、受信側のOSの再組み立てバッファをクラッシュさせるものだった。現代のカーネルはこれに対して堅牢になっているが、ステートフルNATゲートウェイに対して大量の不正なフラグメントを送りつけることで、再組み立て用のメモリプールを枯渇させ、正当なトラフィックをも巻き込むDDoS状態を作り出すことは依然として可能である。
2. レイヤー4ヘッダー隠蔽によるIDS/IPSバイパス
前述の通り、オフセットが 0 以外の後続フラグメントにはTCP/UDPポートやHTTPヘッダーの情報が含まれていない。
悪意ある攻撃者は、攻撃ペイロードの最初の部分をあえてオフセット 0 以外のフラグメントに分割して送りつける。これを受信するIDS（侵入検知システム）やWAFが、フラグメントの再組み立てを行わずにインスペクション（ディープ・パケット・インスペクション）を行っている場合、危険なペイロードがセキュリティフィルターをすり抜けて内部ネットワークへ到達してしまう。
セキュリティ対策としてのLinuxカーネルハードニング
クラウド上のプライベートネットワークを守るLinuxインスタンスやルーターでは、カーネルパラメータを調整し、不審なフラグメント処理を厳格に制限すべきである。
/etc/sysctl.conf に以下の設定を施し、フラグメントに対する防御を固める。
# カーネルによるIPフラグメントの再組み立てを完全に無効化し、ルーターとしての転送時のみ処理させる
# （もしこのノードが直接の終端ではなく純粋なルーター/NATである場合）
net.ipv4.ip_forward = 1
# フラグメント再組み立てにおけるメモリ消費量の上限を設定（デフォルト値より厳しく制限してDDoSを防ぐ）
net.ipv4.ipfrag_high_thresh = 262144 # 256KB
net.ipv4.ipfrag_low_thresh = 196608 # 192KB
# フラグメントパケットの保持タイムアウトを短縮（秒単位。デフォルトは30秒だが、素早く解放する）
net.ipv4.ipfrag_time = 15—
4. 極限のパフォーマンスチューニング：RTT削減とTCPバッファの調律
最後に、フラグメントが起きうる過酷なネットワーク環境においても、スループットを最大化し、往復遅延時間（RTT）を最小限に抑えるためのカーネルチューニングのレシピを公開する。
パケットロスやフラグメント再送が発生した際、TCPの混雑制御アルゴリズムとバッファサイズが適切に設定されていないと、帯域幅BDP (Bandwidth-Delay Product) を十分に活かすことができない。
高スループット・低遅延を実現する sysctl チューニング設定
以下の設定を /etc/sysctl.d/99-network-performance.conf として配置し、sysctl --system で適用せよ。
# ==========================================
# TCPメモリおよびバッファの動的チューニング
# ==========================================
# TCP送受信バッファの最小値、デフォルト値、最大値（バイト単位）
# 高速なバックボーンや大容量のBDPに対応するため、最大バッファを16MBに拡張
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# システム全体で使用できるTCPメモリの制限（ページ単位: 4KB基準）
# 低, 圧迫開始, 限界値
net.ipv4.tcp_mem = 786432 1048576 26777216
# ==========================================
# Path MTU Discovery (PMTUD) の最適化
# ==========================================
# パスMTUディスカバリーを有効にし、ルート上の最小MTUを自動検知
net.ipv4.ip_no_pmtu_disc = 0
# PMTUDブラックホール（ICMPがドロップされるネットワーク）を検知した際、
# 自動的にMSSを下げて通信を継続させるフォールバック機能を有効化
net.ipv4.tcp_mtu_probing = 1
# ==========================================
# 混雑制御アルゴリズムの選定
# ==========================================
# 損失ベースのCUBICではなく、遅延ベースと帯域計測を組み合わせたBBRを採用し、
# パケットロスやフラグメントによるスループットの急落を劇的に防ぐ
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrなぜ BBR と tcp_mtu_probing = 1 が救世主になるのか？
従来のTCP混雑制御（CUBICなど）は、「パケットロス＝輻輳（混雑）」とみなすため、フラグメントの破損やドロップによる再送が発生した瞬間にウィンドウサイズを強制的に半分に縮小してしまう。これが、フラグメント多発環境でのスループット急降下の正体だ。
Googleが開発した TCP BBR は、パケットロスではなく「実際の帯域幅」と「伝搬遅延（RTT）」をベースに送信レートを決定する。そのため、万が一フラグメント起因の微小なロスが発生しても、無駄にウィンドウを縮小せず、パイプラインを流し続けることができる。
さらに、net.ipv4.tcp_mtu_probing = 1 を有効にしておくことで、クラウド特有の「セキュリティグループやファイアウォールがICMP Destination Unreachable（Fragmentation Needed）を闇雲にドロップする」という悪夢のような環境であっても、カーネルが自律的にパケットサイズをプローブし、最適なMTUへと安全に着地させることが可能になる。
—
結びにかえて
IPフラグメンテーションとNATゲートウェイの交差点で何が起きているか――その全貌をパケットレベルからカーネル内部のメモリ管理、そして最新のTCP BBRチューニングに至るまで俯瞰した。
「動いているから触らない」という姿勢は、平時には美徳かもしれないが、クラウドの大規模障害やセキュリティインシデントの現場では、まさに致命傷となる。ネットワークの奥底でパケットがどのように分割され、どこでバッファリングされ、どのようなセキュリティリスクを孕んでいるのかを正確に把握している者だけが、真にレジリエントなクラウドインフラを設計・運用できる。
あなたのアーキテクチャは、巨大なパケットの波が押し寄せたとき、美しく、かつ強靭に耐え抜く準備ができているだろうか？ 今すぐ手元のカーネルパラメータとネットワークパスを見直してほしい。
コメント