共有IPなしの二台のIPsecゲートウェイ：フェイルオーバーが実際に行うこと

会議中にゲートウェイAを落とすと、一分後にトンネルはB経由で戻ってくるが、接続は機能してもビデオ通話はそうでないかもしれない。これが、独立したアドレスを持つ二台のIPsecゲートウェイ間のコールドフェイルオーバーの正直な姿だ。クライアントはエンドポイントを選び直して新しい関係を構築し、これにより古いセッションの暗号状態を移さずに到達性が回復する。手順をたどれば、設計が守れる約束が明確になる。

場面を設定する：二つのアドレス、フローティングIPなし

ゲートウェイAは一方の到達可能なアドレスで応答し、ゲートウェイBはもう一方で応答する。AがいなくなったときにBを選ぶ承認済みの方法がクライアントにあり、両方のゲートウェイが主張する共有の外部アドレスは存在しない。この設計で仮想IPとは、その共有の入口を指し、リモートアクセスクライアントに割り当てられる内部アドレスではない。

この定義が重要になるのは、二つの考えがチケットで混同され、一方の修正が他方の修正ではないからだ。共有の入口がゲートウェイに追従しなかったという報告は、一つの設計を説明している。ノートPCが内部アドレスを失ったという報告は、クライアントのリースを説明している。所有者もログも修理も異なる。

障害をたどる：検出してから選び直す

まず何かが、Aが応答をやめたことに気づく。それはトンネル層でのデッドピア検出かもしれないし、経路を取り下げるルーティングプロトコルかもしれないし、最終的に再接続を強いるアプリケーションのタイムアウトかもしれない。それぞれ時間スケールが異なり、ふつう最も遅いものがユーザーの待ち時間を決める。

次にクライアントは、配備がサポートする仕組み、すなわち二つ目の設定済みリモート、正常なアドレスに解決されるDNS名、または別の経路を優先するようになったルーティングによってBを選ぶ。選択はポリシーの段階であり、障害の前に存在しなければ偶然に起きてしまう。

Bが継承できるものとできないもの

BはAと設定テンプレート、認証局、認証ポリシーを共有できる。ただし、稼働中のセキュリティアソシエーションは継承できない。セッションキー、セキュリティパラメータインデックス、シーケンス状態は、Aとクライアントが確立した関係に属し、Bはどれも持っていない。

その状態をゲートウェイ間で移すのは本物の工学問題であり、だからこそstrongSwanの高可用性の文書はそれを設定フラグではなくクラスタ設計として扱う。特定のクラスタレシピはクラウドネットワークの一般的な答えではなく、支えるインフラなしにコピーすれば継続性ではなく複雑さを買うことになる。

新しい関係を確立する

Bが選ばれると、クライアントは新しいIKE交換、すなわち新しいnonce、新しいDiffie-Hellman値、結果として生じるアソシエーションの新しい識別子を実行する。認証はBで再び行われる。設計がマシン資格情報に依存するなら再接続は無人で進められるが、人的要素を要するならフェイルオーバーを完了するために誰かが立ち会わなければならない。

そのユーザー体験は障害の最中ではなく、障害の前に定義すること。クライアントが何をし、どれだけ試し、諦めたときに何を示すのかを明確に言うべきなのは、一分の再接続とサポートへの電話の違いがたいてい文書と試験済みのプロファイルだからだ。

同じ内部アドレスを保つことは、安定したローカル識別子を期待するアプリケーションに役立つが、そのセッションは保たない。NATバインディングは期限切れになり、TCP接続はリセットされ、独自のタイムアウトを持つものは再試行するかどうかを独立に決める。

二本のトンネルを並行させるのは別の設計

両方のトンネルを同時に動かすのは、両方のゲートウェイとルーティング設計が対応していれば有効なパターンだ。そのとき経路選択がアクティブな経路を選び、戻りの経路も一致しなければならず、そうでなければトラフィックは一方のゲートウェイから出て他方から戻り、対応づける状態がない。

トンネルポリシーの重複は、それ自体では整然としたフェイルオーバーを生まない。二つの候補を作るだけで、どちらかを決定的に選ぶ何か、すなわちルーティングメトリック、ポリシー優先度、クライアントでの明示的な優先指定のいずれかが必要だ。

どの形を選ぶにせよ、障害をどう検出し、代替をどう選び、代替がどの認証を要求し、再接続にどれだけかかる見込みなのかという契約を書き下すこと。共有IPは発見を簡単にできるが、継続状態の同義語ではなく、可用性はいずれにせよ設計である。