二つの暗号マップ、一つのフロー：後から追加したエントリはバックアップではない

同じアドレスペアに対して二つ目の暗号マップエントリを追加し、それを別のピアに向ければ、フェイルオーバー計画を書いたことになる。それが俗説であり、それが生き残るのは、設定した他のあらゆる順序付きリストと同じに見えるからだ。暗号マップの順序が決めるのは、新しいフローをどのエントリが要求するかであり、ピアが応答をやめたときにどのエントリが引き継ぐかではない。そのリストの中の何も遠端を監視していないので、二つ目のエントリは何も要求せずにそこに座っているだけだ。

俗説：順序はフォールバックを意味する

二つのエントリと一つの共有定義を持つ順序付きリストは、プライマリとセカンダリのように感じられる。似ているのは構文までだ。Cisco の ASA ドキュメントは、暗号マップを保護トラフィックに一致させ、そのためのピア配置を指定するポリシーモデルとして説明しており、一致はフローを最初に要求するエントリに対して行われる。リモートピアの可用性はその評価の一部ではない。

あなたが構築したのは、そのフローでは決して参照されないポリシーと、冗長性を主張する変更記録のコメントだ。

順序はフローを要求する、一度だけ

各エントリはアクセス制御リストまたは保護フロー定義を保持し、新しい送信パケットは順序に従ってそれらの定義と比較される。定義が一致する最初のエントリがフローとそのピアを所有する。同一の定義を持つ二つ目のエントリは、最初のものがすでに一致しているから決して順番が回ってこないが、より狭い定義を持つ二つ目のエントリは、最初のものが要求しなかったフローだけを処理する。

この動作は、広いポリシーから意図的に例外を切り出すときには有用であり、フェイルオーバー機構としては役に立たない。show crypto map と show crypto ipsec sa peer で実際に何が起きたかを確認し、次に、通ると信じている経路で合成パケットを追跡しよう。追跡はそれを要求したエントリを名指しするが、それが重要となる唯一の答えだ。

経路選択とポリシーの所有は別々の決定である

ルーティングテーブルは、パケットがどこに転送されるかに答える。暗号ポリシーは、選択されたトラフィックにどの保護とどのピアが適用されるかに答える。送信元と宛先のペアを別のピアの下で複製すると、二つ目の決定が変わり、一つ目は手つかずのままなので、応答は古いゲートウェイをたどり続けながら、送信パケットは新しいピアを取ることがある。その非対称性は、稼働中と報告しながら何も通さないトンネルを生む。

遠端との契約も相互に保とう： 受け入れられた ID、保護されたアドレス範囲、興味のあるプレフィックスの戻り経路、サービスへの許可。相手側が期待しない代替の送信選択は代替経路ではなく、その半分だ。

本当の代替経路に必要なもの

その仕事のために設計された仕組み、つまりサポートされたピア候補のグループ、フローティングスタティックまたは動的ルーティング隣接を備えたルーティング済みトンネル、あるいはプラットフォームがそのサービス向けに文書化している冗長設計のいずれかを選ぼう。次に、どのコンポーネントが障害を検出し、どのコンポーネントが代替を選択するのかを、二つの異なる機能でありしばしば二つの異なるチームだからこそ書き留めよう。

アドレス変換もサイトに二つ目の提示アドレスを与えられるが、同時にセレクタ、ログ、送信元ベースのアクセスルールを変えてしまう。それを、二つの曖昧なエントリのための回避策ではなく、明示的な要件として扱おう。

三つの状態をテストしよう、一つではなく

設定が完成するのは、通常運用、プライマリ障害の状態、プライマリへの復帰に対して、弁護できる答えを持ったときだけだ。三つすべてをテストし、それぞれにどのポリシーエントリとどのピアが対応したかを記録しよう。最初の状態で止まるテストは、何も問題がないときに設計が機能することを証明するにすぎず、それは確認する必要のなかった状態だ。

キー再生成中の新旧の関連付けの正当な共存と、設定された重複も区別しよう。複数のアクティブな SA は正常で一時的だが、一つのフローを奪い合う二つのエントリは恒久的で目に見えない。