すべての ICMP を遮断すると動作中の VPN 経路が壊れる理由

認証が通り、ping を運び、その後の最初の大きな転送で止まるトンネルは、VPN の故障ではなく ICMP メッセージの欠落を示す典型的な兆候です。送信側はパケットが大きすぎたことを知らないまま同じサイズを再試行し、アプリケーションは待ち続けます。直すのはファイアウォールのポリシー判断であり、クライアントの再インストールではありません。順序が重要です。まずサイズの境界がどこにあるかを測り、次に報告を飲み込んだルールを狭めます。

この経路で ICMP が実際に運ぶもの

IPv4 の経路 MTU 探索 は、don't-fragment ビットを立てたパケットを転送できなかったとルーターが報告することに依存します。その報告が ICMP Fragmentation Needed メッセージであり、これがなければ送信側はセグメントのサイズを小さくする理由を持ちません。IPv6 はより厳格です。ルーターは中継時に分割しないため、ICMPv6 Packet Too Big メッセージだけが送信側を縮めさせる信号になります。

どちらのメッセージも制御プレーンのフィードバックであり、診断用のエコーではありません。ping を遮断するポリシーとすべての ICMP を遮断するポリシーはルール一覧では似て見えますが、ネットワーク上での振る舞いは大きく異なります。後者は、正しく寸法を合わせたトンネルを、経路上で最も小さいリンクより大きなすべての通信にとって片方向の経路に変えてしまいます。

一部のトランスポートは RFC 4821 が述べるように探査パケットで独自の探索を行うため、このフィードバックへの依存が小さくなります。これはどのトランスポートを使っているかを確認すべき理由であり、どのトンネルも影響を受けないと決めつける理由ではありません。

障害はサイズに依存する

障害がパケットサイズと相関するかを確認します。ログインページ、DNS クエリ、短い API 呼び出しは成功する一方、ファイルのアップロード、大きな応答、画像のダウンロードは止まります。このパターンは両端のどこかにサイズの上限があることを示しており、認証やルーティングの問題ではありません。小さな ping の成功は、その境界がどこにあるかについてほとんど何も語りません。

トンネルの内部には考慮すべき二つの層があります。ペイロードのパケットと、外側のカプセル化されたパケットです。内側の送信側が正しく動作していても、外側の経路がトンネルの想定より小さいことがあり、だからこそトンネル自身の MTU 設定とその下の物理リンクの両方が重要になります。

ルールを編集する前に測る

don't-fragment ビットと、自分で選んだペイロードサイズで探査する、障害のあるクライアントから保護されたアドレスに向けて:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

1472 バイトのペイロードに 28 バイトのヘッダーを加えると 1500 バイトのパケットになります。大きな探査が分割エラーで失敗し、小さな探査が通れば境界が見つかったことになります。トンネルのオーバーヘッドを考慮して調整し、動作するサイズが安定するまで繰り返します。

次に、その隙間が報告そのものであることを確認します。探査がエラーも応答もなく静かに失敗するなら、メッセージは届かずに破棄されている可能性が高く、疑うべきはルールです。

ルールを狭め、それからタスクを再テストする

修正はプロトコル全体ではなく、特定の制御メッセージを許可するべきです。iptables のホストでは、形式はタイプ固有の許可です。構文はお使いのプラットフォームでファイアウォールを管理するものに合わせてください:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

それがローカルポリシーなら、エコー応答は遮断したままで構いません。経路が必要としているのはそこではないからです。そのうえで、当初失敗した転送を新しい接続から再テストし、ルールのカウンターがメッセージの到着を示すことを確認します。

メッセージを許可した後も大きな転送が止まるなら、残る制限は別の場所にあります。高すぎるトンネル MTU、パケットを書き換えるプロキシ、報告せずに破棄する中間装置のいずれかです。ICMP のルールは必要でしたが、十分ではありませんでした。