IPsec ゲートウェイからの ping は別の送信元アドレスを使う

IPsec ゲートウェイから対向側へ ping を送り、応答が返らないのでトンネルが壊れていると結論しても、ゲートウェイ背後のワークロードはすべて正常にトラフィックを流しています。この二つの結果は矛盾しません。ゲートウェイ上で開始した ping はローカル送信元のパケットであり、ゲートウェイは自身のルーティングテーブルから送信元アドレスを選びます。その選択は実際のサイトトラフィックが使うアドレスと異なることがあり、どのポリシーに一致し、どの戻り経路が適用されるかを変えます。結果から何かを読み取る前に、テストが何を証明すべきかを決めてください。

ping が答えられる三つの異なる問い

一つ目の問いは、このホストから対向側にそもそも到達できるかどうかです。二つ目は、トンネルのセレクタまたはルートベースのポリシーが特定の送信元からのトラフィックを許可するかどうかです。三つ目は、ゲートウェイ背後のワークロードからの転送トラフィックが端から端まで機能するかどうかです。一つのコマンドでは三つに答えられず、それらを分けるのは送信元アドレスです。

まず問いを選んでください。さもないと、失敗した ping が、すでに持っていた説の証拠になってしまいます。

ゲートウェイが予想外のアドレスを選ぶ理由

宛先に ping すると、ローカルスタックはそれに一致するルートから送信元を選びます。ルートベースのトンネルでは、それが トンネルインターフェースのリンクアドレス であることがあり、多くのサイト設計ではポイントツーポイントのホップ用に選ばれた 169.254.x.x の対です。そのアドレスはリンクを機能させるために存在し、対向側でアプリケーションの送信元ネットワークとして広告されることはありません。

したがって対向側は、戻り経路がないアドレス、あるいはどのセレクタにも一致しないアドレスからエコー要求を受け取ることがあります。トンネルは健全でも ping は失敗しうるのであり、それがまさにこの記事が扱う偽陰性です。

送信元を意図的に選ぶ

管理された Linux ゲートウェイでは、すでにローカルに割り当てられた送信元を選びます: ping -c 4 -I 10.30.0.1 10.40.0.20。ここに示したアドレスは例なので、ゲートウェイの実際の内側アドレスと実際の対向先に置き換え、選んだ送信元がこのデバイスに属し、サイトポリシーで許可されていることを確認してください。

テストのためにワークロードのアドレスを借りないでください。ゲートウェイに割り当てられていないホストを装うと、誰も再現できない結果が生まれ、一部のスタックではトンネルの障害のように見える失敗をします。

要求だけでなく戻り経路を読む

実際にどの送信元が対向先に届いているかを、途中の意図的な変換も含めて確認します。次に、対向側からその送信元への戻り経路と、それを許可するセレクタまたはポリシーを確認します。予期しない送信元で届く要求は、暗号の問題ではなくルーティングとポリシーの問題です。

ここではもう一度 ping するよりもパケットキャプチャが役立ちます、対向側が見た送信元が分かり、そのアドレスに返信が届かなければならないからです。

次にワークロードをテストする

決定的なテストは、ゲートウェイ背後の通常のホストから、対向ゲートウェイ背後の通常のホストへの ping です。これによりゲートウェイの転送の役割、実際のアプリケーション送信元、本当の戻り経路が試され、それが利用者が気にするフローです。

結果はノートで、ゲートウェイからの到達性、選んだ送信元に対するポリシーの許可、転送トラフィックという三つに分けておいてください。固定した送信元での ping の成功は、トンネルが何かを運んでいるという有用な証拠ですが、すべての転送フローが動く証明ではありません。そして到達できない自動選択のゲートウェイ送信元は、サイトのトンネルが落ちている証拠ではありません。

診断の答えを一つ得るためだけに 169.254.0.0/16 の包括的なルートを追加しないでください。それは誤解を招くテストを恒久的なルーティング決定と引き換えにし、次の人が文脈なしでそれを引き継ぎます。