GET VPNメンバーの安定した登録元を選ぶ

グループメンバーの登録をループバックアドレスに向け、GET VPNの不安定さは解決したと宣言する人がいます。実際にそうなることもあります。しかし多くの場合、ループバックに到達できるのはメンバー自身のルーティングテーブルからだけで、他のどこからも届きません。そのため、それを運んでいたアップリンクが次に揺らぐと、登録はまた壊れます。登録アドレスはコントロールプレーン上の識別子であり、両方向に実際の経路が存在するときだけ役に立ちます。意図して選ぶ価値はあり、巷の説が示すよりも小さな変更です。

登録アドレスが識別するもの

GDOIの導入では、グループメンバーは鍵サーバーに登録し、そこからグループポリシーを受け取ります。鍵サーバーが記録するアドレスが、その対話におけるメンバーの識別子です。

この識別子が対象とするのはコントロールの対話です。登録、鍵の更新、ポリシーのダウンロードが含まれます。 顧客トラフィックの送信元になることはありませんし、どのインターフェースがどのフローを保護するかも変えません。

この二つを分けて考えるのが最初の一歩です。この設定をめぐる混乱の多くは、コントロールプレーンの変更がデータプレーンの症状を直すという期待から生まれます。

ループバックは経路の良さ以上には良くならない

ループバックは、物理アップリンクが一つ落ちても消えない論理アドレスをメンバーに与えます。鍵サーバーへの経路が複数あるルーターでは、これは実際の利点です。

ただし、それは単なるアドレスでもあります。鍵サーバー側に戻りの経路がなければ、登録は以前とまったく同じように失敗します。メンバーのルーティングテーブルが一つのアップリンク経由でしか鍵サーバーに届かないなら、ループバックは安定していても経路は安定していません。

生き残らせたい各アップリンクを通して、両方向の到達性を確認してください。管理上アップのままのループバックは転送について何も証明せず、障害はインターフェースの問題ではなく、到達できない鍵サーバーとして現れます。確認は想定ではなく、アップリンクごとのコマンドとして書いてください。そうすれば次の変更作業は図ではなく証拠から始まります。

コントロールと保護対象トラフィックを分ける

CiscoのGDOIバイパスガイドは、登録インターフェースと、登録およびバイパス処理の関係を説明しています。一つの表現を万能のコマンドとして扱うのではなく、実際に稼働しているリリースの挙動を読んでください。

コントロール経路のフィルタリングと変換を見直し、鍵管理のトラフィックが、取得しようとしているグループポリシーそのものに依存する保護ポリシーへ誤って取り込まれていないことを確認してください。この循環依存は、動作していた導入がポリシー変更後に失敗する典型的な原因です。

データプレーンのポリシーは別の設計です。登録の送信元を変えても、保護されるフロー、セレクター、バイパスの規則はそのままの位置に残ります。

移行の前後で識別子を確認する

変更の前に、グループ、選択した登録アドレス、鍵サーバーの宛先、ルーティングのコンテキスト、許可されるコントロール経路を記録します。承認されたアップリンク変更の後で、鍵サーバーの登録メンバー表示とメンバーのコントロール状態を再度確認します。

見たいのは、意図した論理エンドポイントが引き続き到達可能で、設計どおりに表現されていることです。見たくないのは、意図しなかったアドレスからの二つ目の登録です。メンバーエントリの重複は、まさにそうして生まれます。

そのうえで、保護対象のアプリケーショントラフィックを別に試します。転送が成功しても、次の鍵更新の行き先がないことがあり、登録の成功は、特定のフローが正しく選択されルーティングされているかを何も語りません。

安定した送信元が直せないもの

以前の設定ミスで作られたメンバーエントリの重複は取り除けません。メンバーと鍵サーバーのポリシー不一致による鍵更新の失敗は修復できません。鍵サーバーへの唯一の経路を奪った物理経路の障害には耐えられません。

それがするのは変数を一つ減らすことです。アップリンクのアドレスが変わっても識別子が変わりません。これは持つ価値があり、設計の全体ではなく設計の一行です。

作業の順序は、コントロール経路に名前を付け、両方向に経路のあるアドレスを選び、鍵サーバーの表示を確認し、そのうえで保護対象トラフィックを別に試すことです。それでも登録が失敗するなら、ループバックが原因だったことは一度もありません。