ICMP リダイレクトと VPN ルート：実際に変わるのは何か

トンネルを通るべきフローが別のネクストホップを選び、キャプチャに ICMP リダイレクトが写っている。それは診断ではなく仮説だ。リダイレクトは、より良いネクストホップについてのルーターの提案であり、ホストがそれに従うかどうかは、プラットフォーム、インターフェース、アドレスファミリーごとに異なる設定に依存する。

リダイレクトはルーターからの提案にすぎない

IPv4 の ICMP リダイレクトには専用のメッセージ種別があり、成立条件は限られている：ルーターがパケットを受け取ったインターフェースからそのまま転送し、同じリンク上に宛先へより近いネクストホップがあると分かっている場合だ。ルーターはそのネクストホップを直接使うよう、送信者に伝える。メッセージには新しいゲートウェイが示され、送信者がフローと照合できるよう元のパケットの一部も含まれる。これはローカルなトポロジーについての好意の通知であり、送信者が提案されたゲートウェイと同じリンク上にいることを前提にしている。

送信者はそれを無視してもかまわない。プロトコルはホストにテーブルの変更を要求しておらず、キャプチャされたリダイレクトは、ルーターが送ったという事実しか証明しない。

リダイレクトの調査が失敗するのは、たいていこの区別を外すところにある。

IPv4 と IPv6 では届き方が違う

IPv6 では、ICMPv4 の中ではなく近隣探索の中に類似の仕組みがあり、メッセージ形式も検証ルールも異なる。概念は似ていても、パケットは別物だ。ICMP type 5 向けに書いたキャプチャフィルターは IPv6 ネットワークでは何も表示せず、それがリダイレクトは起きていないという証拠と読み違えられることがある。

ポリシーの設定項目も別々なので、IPv4 のリダイレクトは受け入れて IPv6 のものは無視するホストもあれば、その逆もある。

対象のフローがどちらのファミリーを使い得るなら、両方を確認すべきだ。

受け入れるかどうかはホストのポリシーであり、ネットワークの事実ではない

Linux では、リダイレクトの受け入れはインターフェース単位とグローバルで制御され、既定値はホスト役とルーター役で異なる。リダイレクトを受け入れるトンネルインターフェースは奇妙な設計で、ポイントツーポイントのトンネル内には同じリンク上の代替ネクストホップという意味のあるものが存在しない。だからこの設定は、決めつけずに読む価値がある。

セキュアリダイレクトの設定は、どのゲートウェイを信頼してよいかをさらに絞り込む。

ホストを厳格化するなら、見直すべきはこれらの設定項目であり、同じネットワーク上の二台のマシンが違う挙動を示す理由もそこにある。デバッグの近道としてではなく、ポリシーとして変えるべきだ。

リダイレクトでは説明できないもの

具体的なルート、ポリシールーティングのルール、ローカルインターフェースがあれば、リダイレクトがまったくなくても、想定外の経路のほとんどは説明できる。より具体的なプレフィックス、送信元アドレスに一致するルール、あるいは別テーブルの第二のデフォルトルートはいずれも、期待したルートを上書きする。決定的で目に見えるから、まずはそれらを確認すべきだ。

ネットワークを変えたクライアントはローカルゲートウェイが違うので、古いキャプチャも罠になる。

以前の接続時のリダイレクトは現在の経路については何も説明しないので、いま制御トラフィックをどのインターフェースが受けているかを記録しておくべきだ。

トンネルを疑う前にルートを確認する

カーネルに、宛先に対してどのルートを使うかを尋ねる、次にそれを、意図したテーブルと突き合わせる。答えがテーブルと一致するなら、リダイレクトは何も変えておらず、調査すべき場所は別にある。一致しないなら、トンネルのせいだと決める前に、キャッシュされたリダイレクト、ポリシールール、別のテーブルを探す。経路検索が唯一の根拠であり、それ以外は、そこに至った経緯の物語にすぎない。

リダイレクトが理由で保護された経路が黙って保護されない経路に変わってしまうことがないよう、受け入れポリシーは設計レビューで扱うべきだ。RFC 792 の定義は、IPv4 メッセージが何を伝えてよいかの基準であり続ける。

ルート検索の結果とキャプチャの時刻を一緒に書き残せば、次の人があなたの結論を再現できる。