MTU 1420：一部のサイトが固まる理由と対処法

MTU とは、ネットワーク上でフラグメンテーションなしに送信できる最大パケットサイズです。イーサネットでの一般的な値は 1500 バイトです。トラフィックがトンネルを通過する場合、トンネル自身のヘッダーが領域の一部を占めるため、ペイロードが減ります。一般的な値は 1420 です。

これ自体は問題ではありません。問題は、一方が 1500 を送信できると認識しているのに、経路上に 1420 のセグメントが存在し、その通知が失われたときに発生します。

症状の見え方

• SSH は接続でき、グリーティングも届くのに、大きなディレクトリで ls を実行するとセッションがハングする。
• ページの読み込みが始まり、途中で固まる。
• curl -I（ヘッダーのみ）は動作するのに、通常の curl はハングする。
• apt update は成功するのに、apt upgrade はダウンロード中に停止する。
• 小さなリクエストは飛ぶように通るのに、大きなレスポンスはまったく届かない。

共通する兆候は同じです。小さなパケットは通過し、大きなパケットはエラーも出さずに消えます。接続は切断されず、ただ沈黙します。

原因は、パケットサイズのネゴシエーション機構が ICMP のサービスメッセージに依存していることです。経路上のどこかでこれらがフィルタリングされていると、送信側はパケットが大きすぎることを知らないまま、何度も何度も送信し続けます。

確認

don't-fragment ビットを設定したパケットを送信し、通過するまでサイズを減らします。

ping -M do -s 1472 -c 2 1.1.1.1
ping -M do -s 1392 -c 2 1.1.1.1

-s のサイズには 28 バイトのヘッダーが加算されます。1472 は MTU 1500 に、1392 は MTU 1420 に対応します。最初のオプションが失敗し、2 番目が成功すれば、限界値が見つかったことになります。

現在のインターフェースの値:

ip link show
ip route get 1.1.1.1

修正方法

一時的な確認:

ip link set dev eth0 mtu 1420

永続的に設定する場合、systemd-networkd 経由 — ファイル /etc/systemd/network/10-eth0.network:

[Match]
Name=eth0

[Link]
MTUBytes=1420

systemctl restart systemd-networkd

NetworkManager がネットワークを管理している場合:

nmcli connection modify "System eth0" 802-3-ethernet.mtu 1420
nmcli connection up "System eth0"

MTU に触れられない場合に役立つ第 2 の手法は、境界で TCP セグメントサイズをクランプすることです。nftables では:

tcp flags syn tcp option maxseg size set rt mtu

どのような場合に影響するか

Millida VDS マシン自体では、ネットワークは適切に構成されており、通常は MTU を手動で触る必要はありません。自分でトンネルを設定する場合に対処が必要になります。WireGuard、OpenVPN、GRE、オフィスへの VPN、またはマシン間のリンクなどです。トンネル内では MTU は常に小さくなるため、明示的に設定する必要があります。

WireGuard の場合、[Interface] セクションで:

MTU = 1420

よくある間違い

ping -M do コマンドで症状を再現するまでは、MTU に触らないでください。この確認なしでは、動作している構成を推測で変更することになり、古い問題の代わりに新しい問題を抱えることになります。ICMP を完全にブロックしないでください。詳しくは nftables を参照してください。