フローティングVPNバックアップルートが切り替わらない：フェイルオーバー確認手順

フローティング静的ルートはパケットの停止ではなく適格性を待つ。VPNバックアップにおけるプローブ経路、しきい値、戻り切替の六つの順序立った確認。

フローティングVPNルートは設定済みで、バックアップの距離はプライマリより大きく、それなのに何も動きません。あるいは動いた後、数分で戻ってしまい、無線リンクはまだダウンしたままです。どちらの場合も、気にしている障害とは別の何かがルートの適格性を決めています。

これらの確認を順番に行います。それぞれに停止条件があり、失敗した確認は後続の確認では救えません。例ではRouterOSの構文を使います。距離、ゲートウェイ到達性、再帰的なネクストホップがそこでは設定上見えるからですが、順序自体は追跡付き静的ルートを持つ任意のルーターに当てはまります。

バックアップがカバーすべき障害に名前を付ける

「プライマリがダウン」は四つの異なる観測です。相手を失う無線、キャリアを失うインターフェース、応答をやめる遠隔ゲートウェイ、動作をやめるアプリケーションは、ルーターの位置からはどれも違って見えます。誰かが距離の値を変える前に、設計がどれを対象にしているかを書き留めます。

次に独立性を確認します。VPNの外側トランスポートが同じ無線経路を通る場合、あるいは同じ上流を共有するアクセス回線を通る場合、バックアップは第二の故障ドメインではなく、必要なまさにそのときにダウンします。紙の上でプライマリのケーブルを抜いてみます。トンネル自身のトランスポートが一緒に死ぬなら、フローティングルートがカバーするのは設定ミスだけで、障害ではありません。

距離に何かを検出させるのをやめる

距離を大きくするとルートの優先度が下がります。役割はそれだけです。プライマリの静的ルートが適格である限り、フローティングルートは非アクティブのままで、これはバグではなく正しい動作です。障害が見えるのは、プライマリが取り下げられるか到達不能と印を付けられたときだけです。

静的ルートでは明示的なトラッカーが必要です：

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

これが何を試すのかを読みます。目的地ではなくネクストホップです。ローカル側ではまだ応答するが、その先への転送が壊れている無線は、プライマリルートをアクティブに保ちます。これが沈黙のケースで、距離とゲートウェイ確認では捉えられません。そのケースが重要なら、検出は遠い側を観測するものから来なければなりません。ルーティングプロトコルの隣接、あるいは経路と結果の規則を自分で定義したプローブです。

プローブ自身のパケットがどこへ行くかを追う

ヘルスプローブにもルートがあります。データトラフィックがVPNに移ると、同じ遠隔アドレスへの制約のないプローブがそれを追い、成功し、プライマリが復旧した証拠として読まれることがあります。トラフィックは壊れた経路に戻り、サイクルが繰り返されます。

プローブを、判定すべき経路に固定します。RouterOSでは通常、プライマリゲートウェイ経由で監視対象へのホストルートを作り、他のどのルートも解決できないほど小さなスコープにします。RouterOSマニュアルの再帰フェイルオーバーの例が構築するのはこれです。設定のコメントではなく、バックアップを有効にした状態のライブテーブルで確認します：

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

ターゲットを追加する前に、プローブ結果の意味を定義する

ICMPを拒否する、あるいはメンテナンスに入るターゲットは、経路障害とまったく同じに見えます。規則のない三つのターゲットは三つの意見を与えるだけです。まず規則を決め、それから実装します。たとえば、三つのうち二つのターゲットが二回連続の間隔で失敗したらプライマリはダウンと数える、と運用マニュアルに書きます。次の担当者がそこに見つけられるようにします。

障害と復旧のしきい値を、パケット一個の喪失でサイトが動かないように設定します。ヒステリシスは検出時間を少し犠牲にして安定性を買い戻します。間隔はプローブをどれだけ速く回せるかではなく、障害をどれだけ許容できるかから選び、戻りは切り替えより遅くして、プライマリがトラフィックを取り戻す前に自分を証明するようにします。

戻り経路とセッションの話を確認する

外向きにしか機能しないフェイルオーバーは設計の半分です。遠隔サイトには、VPN経由で送信元レンジへの戻りルートが必要ですそうでなければ戻りトラフィックは予期しないアドレスから届き、もはや一致しないファイアウォール状態に当たります。新しい接続が機能しても既存セッションは切れるので、転送の生存を約束する代わりに受け入れ基準に入れます。

管理アクセスを試験対象の経路から外します。唯一の入口がプライマリ経由なら、フェイルオーバー試験は誤動作している機器からあなたを締め出します。

受け入れ手順を実行する

三つの試験で大半をカバーできます。プライマリの物理的喪失、インターフェースが上がったままの沈黙転送障害、プライマリの復旧です。それぞれについて、プローブの送信元とネクストホップ、アクティブな宛先ルート、双方向の新たに許可されたアプリケーション交換を記録します。

設計を分けるのは沈黙のケースです。そこでバックアップが引き継がないなら、経路監視ではなくリンク監視を作ったことになります。それが許容できるかを決め、制限をオンコールの技術者が読む場所に書きます。二本目の接続済みトンネルは、それ自体では完成したバックアップ方針ではありません.

関連記事