等コスト経路が VPN 障害をわかりにくくする理由

ある利用者が、社内アプリケーションは一方のマシンでは動くが別のマシンでは失敗し、ゲートウェイから実行した ping はどちらでも成功すると報告しています。同じコストのトンネルが複数ある場合、これは矛盾ではありません。各フローはそれぞれのネクストホップに配置されるため、あなたの確認と利用者のセッションが単に別の経路を使っているだけかもしれません。以下の手順では、何かを変更する前にこの選択を再現します。

一度の ping、複数の経路候補

経路に同じコストのネクストホップが複数ある場合、ルーターはパケットごとに一つを選ぶ必要があります。多くの実装はパケットのフィールド、通常は送信元と宛先のアドレスにプロトコルとポートを加えたものをハッシュするため、応答は同じ経路にとどまります。アプリケーションが違えば、同じアプリケーションの別の接続でも、生成されるハッシュは異なります。

ゲートウェイからの診断がほとんど何も証明しないのはそのためです。ゲートウェイ自身の確認には独自のアドレスとポートがあり、したがって独自のハッシュがあります。正常なトンネルに着地する一方で、利用者は壊れたトンネルに着地し続けることがあります。

プラットフォームがネクストホップを選ぶ仕組み

推測するのではなく、選択を再現してください。失敗しているセッションと同じ送信元と宛先に対してカーネルがどの経路を使うかを尋ねます。この検索には、単純な宛先検索が無視するフィールドも含まれます。動作しているクライアントからも実行し、二つの答えを比較します。

ip route get 10.20.5.7 from 10.20.0.14

新しい iproute2 のリリースではプロトコルと宛先ポートも指定でき、ハッシュがそれらを含む場合には重要です。その出力を、動作しているクライアントからの同じ検索と比較すれば、その差があなたに欠けていた証拠です。

ルートテーブルではなく、失敗するフローをたどる

ルートテーブルは両方のトンネルを一覧し、定義上は正しく見えます。問題は、選択された後に各トンネルがパケットをどう扱うかです。両方が同じ保護プレフィックス、同じ転送許可、そして同じクライアントに届く戻り経路を持つことを確認してください。

途中にあるステートフルな機器に注意してください。要求が一方のトンネルから出て、応答がもう一方から戻る場合、元のフローを一度も見ていないファイアウォールや NAT はそれを破棄します。二つのトンネルはどちらも正しく転送しているのに、接続は失敗します。

経路ごとに MTU も確認してください。追加のカプセル化がある経路では使えるサイズが小さくなり、一方のトンネルで成功する転送が、もう一方では小さいほうが壊れるまさにそのサイズで止まります。

一度に一つの経路を比較する

設計が保守を許す場合は、一方のトンネルを運用から外し、利用者の作業を繰り返してください。障害が消えれば、問題は外した経路に属しており、次の手順はルートテーブルを再検討するのではなく、その設定を隣の経路と比較することです。

繰り返しの ping ではなく、実際のアプリケーションを比較してください。障害が特定のネクストホップ、パケットサイズ、再接続後の遷移のどれに従うかを記録します。これら三つのパターンは別々の修理を示すからです。

最後に、なぜその経路が等価と見なされるのか、障害によってどう一方を運用から外すのかを書き留めてください。マルチパスが安全なのは経路が本当に交換可能なときだけであり、これは前提にするのではなく確認する価値のある設計上の主張です。