停止なしで一つのサブネットを新しいVPNトンネルへ移行する

新しいトンネルを起動し、一つのサブネットを移すと、ほかはすべて完璧なのにそのサブネットだけが断続的に失敗する。中途半端に移行したVPNがまさにこう失敗するのは、トンネルが決して難しい部分ではなかったからだ。経路には、どのルートが勝つか、どのセレクターが一致するか、アクセス規則が何を許すか、応答がどう戻るか、そして古い設計が適用していた変換も含まれる。トンネルだけを移しても、そのどれも移したことにはならない。

トンネルは経路の易しい半分にすぎない

部分移行のあとに断続的な失敗が出るのは、通常、二つの経路がどちらも成立しうるという意味だ。新しいトンネルを選ぶフローもあれば古いほうに残るフローもあり、状態を覚える機器は、要求が一度も使っていない経路から応答が届くのを見る。経路が二つあれば自動的に一つより安全というわけではなく、二つは食い違えるものだ。カウンターは最後まで健全に見えるのだから、トンネルのカウンターではなくフラップの報告を見るべきだ。

役に立つ最初の問いは、どちらのトンネルが優れているかではない。今日どのフローがどの経路を選ぶのか、そして要求と応答が同じ答えを得るのかどうかだ。

好む前に宛先を作る

ピア同士が互換であり、新しいトンネルが意図したアドレス範囲を運ぶことを確認する。まだ優先されない経路であるうちに必要な転送とサービスの許可を追加しておけば、切り替え自体は選択だけを変え、ほかは何も変えない。

遠隔サイトに、通信をどう戻すのかを尋ねる。応答がまだ古いトンネルから出ていくなら、新しいローカルルートは非対称を生むか、状態を覚えるフィルターで落ちる。変換が設計に入るのも同じ理由で、送信元アドレスが変われば戻り経路も変わる。

狭く切り替え、戻り道を知っておく

正確なサブネットと、その新しいルートやセレクターを優先するプラットフォーム対応の仕組みを名指しする。ポリシーベースの定義はルートメトリックのようには振る舞わないことがあるので、より具体的な一致が勝つと決めつける前に、実装の重複ポリシーの規則を読む。

移すのは一つのサブネットで、一つの拠点ではない。管理アクセスは触らない経路に残し、何かを適用する前に、どのルートやポリシーを戻すのか、誰がやるのか、その間どうつながり続けるのかを書き留める。

非対称と古い状態

ファイアウォールやNAT機器は、フローが使ったインターフェースを覚えている。要求と応答が別のトンネルを通ると、どちらの経路も単独では機能していても、機器が応答を捨てることがある。確立済みのセッションは何時間も古い経路を使い続けることがあるので、変更後に開いたフローで試すこと。

観測される送信元アドレスが動いたなら、古いほうを名指しするポリシーをすべて探す。送信元を静かに変える移行は、誰もVPN設計の一部として分類していなかった規則を壊す。

両方の答えを証明してから、古いポリシーを退役させる

移行したサブネット上の普通のホストから、意図したサービスに到達し、観測される送信元と応答のインターフェースを確認する。次に、移行は両方の答えが正しいときに初めて終わるのだから、古いトンネルに残るはずのネットワークを試す。二つ目の試験こそが人が飛ばすものであり、意図より広いセレクターを捕まえるのもそれだ。

残ったサブネットがどれも依存しなくなってから古いポリシーを退役させ、最終的なルートを所有者とともにセレクター台帳へ記録する。完了とは新しいトンネルが起動を報告することではなく、すべてのネットワークが意図した経路をたどることだ。