二つのアクティブなIPsecトンネルには今も戻り経路の計画が必要

一方のサイトのワークステーションで端末を開き、もう一方のサイトのサーバーに接続する。この一本のTCP会話は、二つではなく四つのゲートウェイを通過しなければならず、面白いのは良い日に動くかどうかではない。面白いのは、往路がどのゲートウェイ対を選んだのか、復路がどの対を選ぶのか、そしてその間フローの状態を誰が保持しているのかだ。ルーティングテーブルはそのどれも決めてくれない。

ルートを描く前に四つのゲートウェイを描く

各サイトに独立したVPNファイアウォールを二台、ISPごとに一対を置く二重アクティブ構成は、使える経路を二本と、それを壊す三つの方法を与える。何かを設定する前にアドレスを書き出そう：各ゲートウェイの前後で見えるクライアント、同様にサーバー、往路のネクストホップ、復路のネクストホップだ。

その表が設計だ。その後のすべては、機器がその表に同意するかどうかの問題である。

往路はどう選ばれるか

等コストのマルチパスルーティング層は、ヘッダーフィールドをハッシュしてフローをネクストホップに振り分けるが、この仕組みをRFC 2992が詳しく述べている。この選択は完全にステートレスでよい：コネクショントラッキングのエントリは不要で、変わらないフィールド上の安定したハッシュだけで足りる。経路集合とハッシュへの入力を一定に保てば、フローのすべてのパケットが同じネクストホップを選ぶ。

フロー単位の選択は、遅延の異なるリンクでパケット単位の分散が引き起こす並べ替えを避ける。ルーティングコストが等しいからといって実測遅延も等しいとは約束しない、実際そうならないからだ。また経路の構成が変わればフローは再マッピングされるので、障害時のコネクション維持は経路選択とは別の要件である。

戻り経路に本当に必要なもの

ここで話は対称でなくなる。安定した往路ハッシュは、遠隔サイトが応答をどう扱うかについて何も教えてくれない。独立したファイアウォールが有用な状態を保つために接続の両方向を見る必要があるなら、それを迂回する戻り経路は何にも一致しないトラフィックを残す。似たルールセットを持つ二台の箱は共有状態ではない。

実装された双方向の挙動を確認するか、必要な境界を整合させて保つ明示的なポリシーを書く。ここでの推測は、障害の最中に、それを楽しんでいない人々によって発見される。

変換があなたの代わりに決める場所

NATはもう一方のレバーであり、必須ではなく任意だ。経路ごとに変換された識別子は、応答を状態を持つゲートウェイへ戻すことができ、これは正当な設計である。ただしマッピング、戻り経路、その状態の所有者が増えるので、声に出して言える要件にだけ負担を受け入れよう。

要件が単に、両方の経路がトラフィックを運び、どちらかがISPの喪失を生き延びることなら、整合した戻りルーティングを備えた素朴なフロー単位マルチパスのほうが通常は小さい設計だ。

受け入れを順番に歩く

この順序で試験し、各段階のアドレスを記録する：経路Aでの新しい接続とその応答経路、経路Bでも同じ、次にISPの一つの喪失、次に復旧だ。各結果について、どの確立済みフローが移動したか、どれが再接続を要したか、新しいフローがその後どこへ行ったかを記す。まず期待値を書き、それからキャプチャと比較する。確立済みのトンネル二本はそのどれも証明しない。

設計が完成するのは、書いた表がキャプチャの示す内容と一致したときであり、両方のトンネルが上がったときではない。