Tech Learning Daily

MTU と MSS: パケットには「通れる大きさ」がある

MTU（Maximum Transmission Unit）とは、あるリンクが 1 回で運べる IP パケットの最大バイト数である。AWS のドキュメントが述べるとおり、標準的な Ethernet v2 フレームは 1500 MTU を扱い、これがインターネットの大半で通る最大サイズになっている。

TCP はこの上限を前提に、1 セグメントに載せるデータ量を決める。その値が MSS（Maximum Segment Size: TCP セグメント 1 個に載せるデータ部分の最大バイト数）で、IPv4 では MTU から IP ヘッダ 20 バイトと TCP ヘッダ 20 バイトを引いた値になる。MTU 1500 なら MSS は 1460 で、各端は自分のインターフェースから計算した MSS を SYN に載せて相手に伝える。

ここに落とし穴がある。MSS を決めるのは両端のインターフェースであり、途中の経路は計算に入っていない。クライアントもサーバーも MTU 1500 の NIC を持っていれば、間に MTU 1400 のトンネルが挟まっていても、ハンドシェイクは 1460 で合意してしまう。

Path MTU Discovery: 「大きすぎた」を ICMP で教わる仕組み

途中に細い区間がある問題に対して IP が用意している仕組みが PMTUD（Path MTU Discovery: 経路全体で通る最小の MTU を送信側が学習する手順）である。送信側は IP ヘッダの DF ビット（Don't Fragment: 途中で分割するなという指示）を立てて送る。Linux では PMTUD を止める ip_no_pmtu_disc の既定が FALSE なので、TCP は普通この方式で送っている。

DF 付きのパケットが自分の MTU より大きいとき、ルータはパケットを分割せずに捨て、送信元に ICMP の Destination Unreachable: Fragmentation Needed and Don't Fragment was Set（Type 3, Code 4）を返す。このメッセージには「この先は何バイトまで」が書かれていて、送信側はそれを経路の MTU としてキャッシュし、小さく切り直して再送する。IPv6 ではルータが分割を一切しないため、同じ役割を ICMPv6 の Packet Too Big（Type 2）が担う。

クライアント    VPN 区間       サーバー
 MTU 1500     MTU 1400       MTU 1500
    │            │              │
    │ SYN (小)   │              │
    │───────────▶│─────────────▶│ 通る
    │            │   応答 1500B │
    │            │◀─────────────│ DF 付き
    │            │ 捨てる       │
    │            │ ICMP 3/4     │
    │            │─────────────▶│
    │            │      ✕       │
    │            │  FW が ICMP  │
    │            │  を捨てる    │
    │ 届かない…  │              │
    ▼ タイムアウト              ▼

なぜわざわざ DF を立てるのか。途中のルータに分割させる方式も IPv4 にはあるが、断片が 1 つでも落ちるとパケット全体が失われ、分割と再組み立ての負荷もかかる。だから「端が経路に合わせて小さく送る」設計が選ばれた。その代わり、ICMP が送信元に届くことが前提になった。

ICMP を捨てると何が起きるか: PMTUD ブラックホール

ICMP は ping のための補助的なものだと思われがちで、「念のため ICMP は全部遮断」というファイアウォール設定は珍しくない。RFC 2923 もファイアウォールが ICMP を丸ごと抑制するよう誤設定されていることが多いと書いている。こうして Type 3 Code 4 が送信元に戻らなくなった状態が PMTUD ブラックホールである。

症状は冒頭の謎とそのまま重なる。SYN は小さいので通りハンドシェイクは成功し、小さな対話的通信も動く。しかし RFC 2923 が書くとおり、一括転送は最初の大きなパケットで止まり、接続はやがてタイムアウトする。ping も通るので、「ネットワークは生きている、アプリが遅い」と誤診しやすい。

帯域の問題に見えるが、実際には大きさの問題である。同じ API でも件数が少ないときは応答が MTU に収まって返り、件数が増えて 1 パケットを超えた途端に固まる。データ量で再現が変わるため、アプリのバグと区別しにくい。

MTU が縮む場所と、3 つの対策

MTU が端より小さくなるのは、元のパケットに外側のヘッダを足して運ぶ区間である。Calico のドキュメントによれば、IPv4 の VXLAN は 50 バイト、IP-in-IP は 20 バイト、IPv4 の WireGuard は 60 バイトのヘッダを足すので、物理 MTU 1500 の上では Pod 側の MTU をそれぞれ 1450 / 1480 / 1440 にすることが推奨されている。逆向きの段差もあり、AWS の VPC 内は最大 9001 MTU のジャンボフレームを使えるが、インターネットゲートウェイと VPN 接続を通る通信は 1500 に制限される。

1 つ目の対策は ICMP を通すことである。AWS はセキュリティグループで ICMP を許可していても、サブネットのネットワーク ACL が ICMP を拒否していればやはり遮断されると注意している。ping（Echo）を許すかどうかとは別に、Type 3 Code 4 と ICMPv6 Packet Too Big は通す、と分けて考える。

2 つ目は、細い区間の入口にあるルータで SYN に載った MSS を書き換える MSS クランプである。iptables の TCPMSS ターゲットに --clamp-mss-to-pmtu を付けると、MSS を経路 MTU から IPv4 なら 40、IPv6 なら 60 を引いた値まで下げる。両端は最初から小さいセグメントで話すので、ICMP に頼らずに済む。

# VPN ゲートウェイ等の転送経路で SYN の MSS を下げる
iptables -t mangle -A FORWARD -p tcp \
  --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

ただし man ページは、行きと帰りで経路 MTU が違う非対称経路では期待どおり動かないことがあると注意している。3 つ目は、トンネルの内側にあるインターフェースの MTU 自体を小さく設定することだ（ip link set dev wg0 mtu 1420 のように）。MTU を合わせておけば両端の MSS は最初から正しい値になる。Calico のように MTU を自動検出する CNI もあるが、使わないカプセル化を有効のままにしていると検出を誤ることがある。

端末側の保険として、Linux には net.ipv4.tcp_mtu_probing がある。これは ICMP に頼らず TCP 自身が小さいサイズを試して経路 MTU を探る方式（Packetization-Layer PMTUD）を制御し、0 で無効、1 でブラックホールを検知したときだけ有効、2 で常に有効（初期 MSS は tcp_base_mss）になる。1 にすると、ブラックホールを検知した接続は再送タイムアウトを経て小さいサイズに落とすので、固まり続ける代わりに「最初だけ遅い」接続で済むことが多い。