クラウド VPN には BGP が必要: 他のルーティングプロトコルが機能しない理由

IPsec のセキュリティアソシエーションは上がり、トンネルのカウンターは動いているのに、クラウドのプレフィックスへの通信が消える。そこで運用者は顧客ルーターで OSPF を有効にしようとし、隣接が形成されると期待するが、何も起きない。トンネルが欠けていた部品だったことは一度もない。マネージドクラウド VPN は明確に定義されたルーティング契約を提供し、大規模プラットフォームではその契約が BGP である。セッションが存在し、プレフィックスが受け入れられるまで、トンネルは行き先のない暗号化された経路にすぎない。

トンネルは上がっているのにルートがない

フェーズ 1 とフェーズ 2 の完了は、両者が保護について合意したことを証明するだけで、どちらかの側が通信をどこへ送るかを知っていることの証明ではない。これらは別々の障害モードを持つ別々の状態機械である。

順番に三つの問いを立てる。プレフィックスは広告されたか、相手に受け入れられたか、転送用にインストールされたか。広告されてフィルタされたプレフィックスはポリシーの問題である。一度も広告されていないプレフィックスはセッションか設定の問題である。受け入れられたがインストールされていないプレフィックスはルート選択の問題であり、それぞれの答えは設定の異なる部分を指す。

プロバイダーが実際に提供するもの

マネージド VPN ゲートウェイは無制限のルーターではない。プロバイダーが提供するのは、対応するピアアドレス、自律システムの設定、プレフィックスの上限、そして定義された障害時の挙動を備えたゲートウェイである。その表面こそが製品である。

Google Cloud は HA VPN 向けの動的 BGP ルーティングを文書化しており、Cloud Router がピアルートを学習し、適格なカスタム動的ルートを VPC に供給する。AWS Site-to-Site VPN は静的ルーティングと動的ルーティングの選択を文書化し、BGP の生存確認がトンネルのフェイルオーバーに有用だと説明しつつ、BGP を持たない機器向けのヘルスチェックもサポートする。どちらかのプラットフォームの挙動を、もう一方の製品名から推測してはならない。

実務上の結論は、まずマネージドモードを選び、そのうえで対応するパラメーターを読むことだ。サービスが提供しない隣接の種類を前提とした設計は、顧客ルーターで解くべき設定の問題ではない。

トンネルの保護と到達性は別の作業

IPsec はトンネル用に選択された通信を保護する。BGP はプレフィックスを適格にする到達性の情報を供給する。トンネルが動いていることは、期待するプレフィックスが広告され、受け入れられ、インストールされたことを証明しない。

二つの適格なトンネル経路で 10.42.0.0/16 を広告する拠点を想像してほしい。使える経路を一つ外すと、誰かが各ワークロードのルートを編集しなくてもルート選択が変わりうる。検出、ルート選択、アプリケーションの復旧は即時ではなく、展開によっても同じではない。したがってフェイルオーバー試験は、通過した最初のパケットではなく、一連の流れ全体を観測しなければならない。

クラウドのプレフィックスに到達できないときは、暗号に触れる前にセッションの状態と学習したルートを確認する。背後にルートのないまま上がった SA が、この症状の最も一般的な形である。

OSPF の前提が崩れるところ

IPsec トンネルの内側で OSPF や IS-IS などのプロトコルを動かすことは、両端と転送設計を自分で所有する自己管理アプライアンスなら十分に可能である。その事実は、動的ルーティングのモードとして BGP しか提供しないマネージドサービスについては何も語らない。

提案された設計がサービスでサポートされない隣接を必要とするなら、アーキテクチャを意図的に変えるべきだ。選択肢には、VPC 内の自己管理アプライアンス、サービスが対応する範囲での静的ルーティング、あるいは別の接続製品がある。顧客ルーターだけでプロトコルを設定しても、存在しないクラウド側のピアを追加することはできず、プレフィックスが現れることもない。

あるベンダーの答えを別のベンダーのゲートウェイに持ち込んではならない。動的ルーティングやトンネルのフェイルオーバーといった同じ言葉が、異なる仕組みと異なる限界を指すことがある。

サービスの要件を読み、それから設計する

最初の設定行の前に、隣接のアドレス、自律システム番号、広告して受け入れるプレフィックス、ルートの上限、トンネル障害時に期待する挙動を書き出す。その五項目が、設計の基準となる契約である。

次に同じ順序で検証する。セッションの確立、プレフィックスの受信、VPC のルートテーブルにルートが存在すること、そしてサービスアドレスへの実際のフローである。 強制的なフェイルオーバーの後に繰り返す。再確立したセッションは異なるルート集合で戻ることがあるからだ。設計が一秒未満の収束に依存するなら、仮定せずに測定する。

サービスの契約は変更記録とともに保管する。後になって、なぜトンネルで OSPF を動かせないのかと誰かが尋ねたら、答えはプロトコルの制限ではなく製品の境界であり、記録にもそう書くべきである。