サイト間 VPN 上の静的ルートか、ルーティングプロトコルか

どちらの選択肢もサイト間でパケットを運ぶため、判断はどちらのプロトコルが新しいかではなく、トンネルの大きさでも決まりません。決めるのは三つの条件で、どれだけのプレフィックスがどれくらいの頻度で変わるか、経路間の自動フェイルオーバーが必要か、チームが午前三時にどれだけの制御プレーンの仕組みを運用できるかです。これらに正直に答えれば、選択はたいてい自然に決まります。本稿の残りは、それぞれの答えが何を要するかです。

三つの条件が決める

第一の条件は変化の多さです。所有が明確な安定したサブネットが数個なら、何年も手作業で維持でき、各ルートは誰かが読んで確認できる一行のままです。プロジェクトの出入りに合わせて動く何十ものプレフィックスは別の問題で、移動のたびに古い経路をまだ覚えているすべての機器へ届ける必要があります。

第二は障害時の振る舞いです。予備経路が人の気づかないうちに有効にならなければならないとき、何かが障害を検出してルートを撤回する必要があります。静的ルーティングでそれができるのは追跡や条件付きインストールを通じた場合だけで、しかも事前に想定した障害に限られます。

第三は二つ目の制御プレーンに対する意欲です。ルーティングプロトコルはセッション、認証、フィルタ、選択ポリシーを追加し、そのどれもが監視と変更手順を必要とします。これは一時的な設定作業ではなく、恒久的な運用コストです。

第三段落の下の表が短い版で、その後の三つの節が各行がその位置にある理由を説明します。選ぶ前に各行を自分のサイト数と照らし合わせてください、運用コストを無視した判断は半分の判断にすぎないからです。

静的ルーティングに実際いくらかかるか

静的ルートはトンネルの両側で正しくなければなりません。サブネットを追加するとは、遠端のゲートウェイ、ローカルのゲートウェイ、そして通常は戻り経路を編集することを意味し、どれか一つを忘れるとアプリケーションの不具合に見える片方向の障害になります。アプリケーションチームにはタイムアウトが見え、ネットワークチームには存在していて一見健全なルートが見えます。どちらのチームも間違っておらず、だからこそこの障害の所在を突き止めるのに時間がかかります。

静的エントリは、その下の経路が消えた後もインストールされたまま残ります。プラットフォームが追跡を提供しない限り、ルートは転送しなくなったネクストホップを指し続け、トラフィックは切り替わるのではなく消えます。その静けさが、単純な選択肢を選ぶときに受け入れる費用です。

追跡の方法を各ルートの隣に書き、どの障害を覆うのかを記し、その一覧をトンネル設定と一緒に保管してください。そうしなければ次の障害はネットワークではなく利用者に見つかり、それは常により高くつく発見です。

動的ルーティングに実際いくらかかるか

プロトコルは新しいプレフィックスを通知し、到達不能なものを撤回し、経路間の優先度を表明します。複数のサイトや冗長なトンネルが、そうでなければ変更のたびに調整された編集を必要とする場合、これは本当に役立ちます。同時に、最悪の瞬間にプロトコルがあなたを驚かせうる理由でもあります。そうした動作の一つひとつは、あなた自身が行っていない状態変化です。

一致しないことがある二つの状態を生みます。トンネルが上がっているのにルーティングセッションが下がっていることがあり、セッションが上がっているのにその通知がアプリケーションの必要とするサブネットを落としていることがあります。どちらも半分だけ動くネットワークに見え、どちらもトンネルの状態ページからは見えません。

したがってフィルタとポリシーは後付けではなく設計の一部になります。すべてを通知するプロトコルはいつか何か間違ったものを通知し、間違ったプレフィックスはそれを直せる人より速く移動します。最初のセッションを有効にする前にフィルタを書き、最初の通知がすでに意図的なものになるようにしてください。

ルーティングセッションが何を言えるかを制御する

ピアごとに許可するプレフィックスの一覧を決め、入口で強制してください、外向きのフィルタではピアがあなたにデフォルトルートを送ることを止められないからです。ここで高くつく誤りはデフォルトルートと集約です、正当に見える一つの学習済みエントリで、無関係な経路を静かに置き換えてしまうからです。設計が本当に望まない限り、明示的に拒否してください。

最初のセッションが上がる前に、各ネットワークの隣に所有サイトを書いてください、その対応表がフィルタ一覧の源であり文書の飾りではないからです。それがなければ、フィルタを編集する人はどのサイトがプレフィックスを通知すべきかを推測しなければなりません。

二つのプロトコル間の再配布はループが始まる場所であり、同じプレフィックスがきれいに比較できない属性を伴って二度届く場所です。特定の要件が強いるまで再配布は設計から外し、必要なら境界でルートに印を付けてフィルタしてください。

ルートベースのトンネルインターフェースは動的ルーティングを表現しやすくします、トンネルがセレクタを照合するポリシーではなく、ルートを持つインターフェースになるからです。それでもピアの範囲という問題は消えません、IPsec のセレクタは、ルーティングしようとするトラフィックを依然として許可する必要があります。

障害の経路を試し、順調な経路を試さない

何を選んでも、一つのアップリンクを落として、トラフィックが移動すること、または文書化したとおりに失敗することを確認してください。両方の経路が健全な状態でしか試していない設計は、まったく試していない設計です。その場で検出時間を測ってください、測った数値が利用者が経験する数値だからです。

次に戻り経路を独立に確認してください、VPN 上の非対称ルーティングはよくあり、状態を持つ機器が応答を落とすまで見えません。一方向で動くフローは経路の半分しか証明しません。

作業順序は、プレフィックスを数え、障害をどう検出するかを決め、誰がプロトコルを運用できるかを確認し、何を通知するかを制御し、最後に一つの障害を端から端まで試すことです。各段階は次の段階が必要とする事実を生みます。