WireGuard が止まる：MTU の上限か、転送ルールの欠落か

WireGuard の挙動がおかしくなるとすぐ MTU を下げるのが習慣になっていますが、その習慣は別の障害を隠します。転送しないゲートウェイと、大きなパケットを運べない経路は、区別できるパターンを生みます：一方は両方向で、あらゆるサイズで失敗し、もう一方は小さな要求を生き延びて大きなものでは死にます。どの数値を変える前に、どちらの形なのかを特定してください。テストは安価で、考えられる原因の半分を排除します。

二つの障害、二つの形

転送の問題はサーバーのすぐ先で現れます。ハンドシェイクは成功し、トンネルのアドレスは応答し、ゲートウェイの先には小さな要求でも何も届きません。パケットはサーバーに届いたのに転送されなかったか、応答に戻りの経路がなかったのです。

サイズの問題はしきい値を超えたときだけ現れます。DNS、TCP のハンドシェイク、小さな API 呼び出しは動くのに、ファイルのダウンロードや大きな応答は止まります。収まったパケットは端から端まで通り、収まらなかったものはどこかで使える報告もなく捨てられました。

その説明は別の担当者と別の設定ファイルを指すので、推測より形を測るほうが価値があります。ゲートウェイへの ping 一回では両者を分けられません。

何かを小さくする前に転送を除外する

ゲートウェイそのものではなく、その先の宛先を試してください。サーバーのトンネルアドレスへの ping は、インターフェースが起動していてトンネルを終端するマシンに届くことだけを証明します。より広いネットワークへの通信は、そのマシンで IP 転送が有効になっていることと、転送されたフローを許可するファイアウォールに依存します。どちらも真である必要があり、片方が偽なら同じ沈黙が生まれます。

戻り経路も同じくらい重要です。宛先ネットワークがクライアントのトンネルアドレスへの到達方法を知らなければ、要求は届いて応答は消え、クライアントは破棄された転送と見分けのつかないタイムアウトを報告します。

設計がアドレス変換を使う場合、変換ルールはその戻り経路の一部です。MTU の問題を追いながらそれを削除すると、動いていた設計が壊れた設計になりますので、編集する前に既存のルールを読んでください。

どこから壊れるかを測る

まず転送の状態とフィルタールールを読みます。これは読み取りだけの確認で、安価な問いに答えます：

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

次に、クライアントからゲートウェイの先のホストに向けて、don’t-fragment ビットでサイズを試します：

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

最初の確認が通り二番目が断片化エラーで失敗するなら、経路は使えるサイズを教えています。どちらも通らないなら、転送かルーティングを見ているのであり、MTU は変えるべき変数ではありません。

証明した層を直す

転送が原因なら、修正は転送ルールか経路であり、設計が許す範囲で最も狭く表現します。サイズが原因なら、修正はこの特定の経路のカプセル化を考慮した MTU であり、必要とするインターフェースに適用し、艦隊のすべてのアダプターには適用しません。

いずれにせよ、その後で同じ宛先に同じ作業を繰り返してください。元の大きな転送が今完了するなら、変更は失敗していた層に対処しています。小さな確認だけが改善したなら、症状を扱っただけで、本当の限界はまだそこにあります。

変更前に見た形を書き留めてください。修正の隣に記録されたその一行が、次に来る人が決して問題ではなかった MTU を下げるのを防ぎます。