VPNフェイルオーバー：戻り経路が古いトンネルに残るとき

予備トンネルが上がり、本番トンネルが落ちても、アプリケーションは依然としてタイムアウトします。両拠点ともトンネルの状態は正常に見え、そこが混乱の原因です。要求だけを予備に移し、応答を古い経路に残すのはフェイルオーバーではありません。以下の手順は、ハンドシェイクだけでなく戻り経路を試験します。

まず両端でルートを記録しますが、片方の拠点だけを見ても非対称な経路は分かりません。時間に追われると最も飛ばされやすい手順でもあります。

試験の前に両拠点のルートを記録する

保護対象のプレフィックスごとに、本番ルート、予備ルート、両者を選ぶ優先度を書き留めます。各VPNエンドポイントの背後にあるLANゲートウェイも、エンドポイントが最後のホップになることはほとんどないため、含めてください。

静的メトリック、追跡ルート、動的ルーティングでは、適格性の表し方が異なります。設計がどれを使うのか、代替経路を有効にする条件は何かを把握してください。条件はルートのそばに書き、たとえばプローブが失敗するまでメトリックを下げるとします。

これを両拠点で行います。片側で優先され、もう片側で無視される予備経路は、避けたい非対称をそのまま生み出します。

各段階で要求と応答を観察する

無害で許可されたアプリケーションを使い、通常、本番経路の障害、復旧の三段階を観察します。各段階で、どのトンネルが要求を運び、どれが応答を運ぶかを記録します。到達可能なピアアドレスは、保護されたアプリケーション経路が機能する証拠ではありません。片方向の流れが見えるよう、両拠点で記録してください。

要求が移り、応答が移らない場合は、遠隔拠点からクライアントプレフィックスへのルートと、バックアップへの優先度を確認します。これはルーティングの判断であり、トンネルの障害ではありません。

試験後に元の状態へ戻し、本番経路が再び優先されることを確認します。復旧した本番経路が優先されないなら、そのフェイルオーバー設計は未完成です。

ゲートウェイが変わるときのセッション状態を扱う

ファイアウォールとNATは接続状態を一方のゲートウェイに保持でき、別のゲートウェイへの経路変更ではそれが引き継がれません。アプリケーションによっては自ら再接続しますが、セッションが再確立されるまで失敗するものもあります。予備経路が公開元アドレスや変換後のプライベートアドレスを変えると、リモートアクセス規則も反応することがあります。中断のないフェイルオーバーを約束するのではなく、想定されるセッション再起動を文書化してください。

アプリケーションが要求する場所では、安定したアドレス指定を維持します。セッションごとに送信元アドレスを変えるフェイルオーバー設計は設計上の選択であり、文書に残すべきです。その選択が、利用者が実際に気づく停止の大きさを決めます。

新しい要求だけでなく、長いセッションを保持するアプリケーションも試験してください。

本番経路を戻し、フラッピングを確認する

ルート広告や優先度が揺れずに収束することを確認します。フラッピングする本番経路は、遷移のたびに状態がリセットされるため、明確な障害より混乱を招くことがあります。

ゲートウェイ管理は復旧経路から到達できるようにし、試験そのものが締め出さないようにします。段階、観測した経路、復旧時間を記録してください。strongSwanの転送に関するメモは、エンドポイントがLinuxホストである場合に役立ちます。