VPN上のBGPがアンダーレイ経路を制御しない理由

VPN上のBGPは到達性を交換し経路ポリシーを適用しますが、アンダーレイは依然として外側の経路を選びます。セッションが実際に制御するもの。

二つのサイトがIPsecトンネル越しにBGPをピアリングし、互いのプレフィックスを学習すると、図は経路制御としてラベル付けし直されます。そのラベルこそが混乱の始まりです。セッションは確かに到達性を交換し、ポリシーも適用しますが、どのプロバイダー、ケーブル、ルーターが暗号化パケットを運ぶかについては発言権がありません。BGP経路の変更で、セッションが決して影響を与えられない別のファイバー経路へトラフィックが移ると期待して、動作しているトンネルを作り直したチームを見たことがあります。

セッションが何を買うと人々は思うか

期待のほとんどは、ラボで経路変更がどう見えるかから来ます。トンネル越しにプレフィックスを広告し、遠端がそれをインストールし、トラフィックが動きます。同じ流れは、トラフィックエンジニアリングのつまみを実際に持つルーターでも起こるので、両者は混同されます。ラボでは通常、両サイトが一本のアクセスリンクを共有しており、まさにそのためにそこで違いは現れません。

BGPは到達性のプロトコルです。プレフィックスに対してパケットを届けられるとピアに伝え、受け取った提案を各側が順位付けできるようにします。これはトンネル越しに本当に有用です。サイトが現れては消えるにつれてプレフィックスも現れては消え、各エッジ機器に静的経路を書かずに範囲を拒否できます。やらないのは、プロバイダーのルーターをあなたの管理下に置くことです。

アンダーレイは外側のヘッダーを運びます。トンネルの端点は暗号化パケットをピアアドレスに送り、その二つのアドレス間のネットワークが、その運営者がインストールした経路でそれらを転送します。BGPセッションの中の何もその決定を変えません。同じプロバイダーがそうする対応サービスを提供している場合を除きます。

セッションが実際に運ぶもの

BGPスピーカーはピアのポート179にTCP接続を開き、RFC 4271で定義されたメッセージ形式とパス属性を使います。ピアアドレスがトンネル内にある場合、セッションが始まる前にトンネルが上がっていてそのアドレスに到達できる必要があります。完了したIKE交換はBGPネイバーではありません。ルートベースのIPsec実装は対応するトンネルルートが存在して初めてトラフィックを通し、ポリシーベースの実装は保護セレクター内にピアアドレスを必要とします。これを逆にすると、トンネルは緑なのにセッションが待機したままという典型的な状態になります。

セッションが上がると、ポリシーが何を通過させるかを決めます。プレフィックスリスト、ASパスフィルター、最大プレフィックス数の上限、デフォルトルートについての明示的な決定が最低限で、両方向に適用されます。受け取ったものをすべて受け入れるピアは、ローカルのインターネットアクセスを静かに置き換えるデフォルトルートを渡してくる可能性があります。二つの方向には別々のリストが必要です。ピアから受け入れるものと、ピアに広告するものは別の決定だからです。

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

次にMTUが効いてきます。カプセル化で使えるペイロードが縮むため、完全に確立しているように見えるセッションが大きなアップデートで止まることがあります。ピアは上がったまま、プレフィックスは決して届かず、ログにも目立つものは残りません。フィルターを疑う前に、トンネルインターフェースでTCP MSSをクランプするか、オーバーヘッドの余地を残したトンネルMTUを設定してください。

外側のパケットはそれでもどこへ行くか

一方のサイトから他方へ向かう暗号化パケットは、ローカルルーターがピアのパブリックアドレスに対して選ぶ経路から出ていきます。両サイトが同じプロバイダーからトランジットを買っている、同じメトロ施設を通過している、片側がキャリアグレードNATの背後にある、といった場合、トンネルがプロバイダー障害を生き延びるのは偶然だけです。監視ツールでトンネルのアイコンを数えても、そのことについては何も分かりません。

経路選択と転送のインストールも別々の出来事です。プレフィックスはBGPテーブルで最良として座っていても、次ホップが解決できない、あるいはより具体的な経路が勝つために転送テーブルから欠けていることがあります。BGPがプレフィックスを学習したのにトラフィックが流れないという報告では、インストールされているか、どの次ホップを指しているかが有用な問いです。

設計レビューに対する正直な答えは、共有依存関係のリストです。アクセス回線、上流プロバイダー、施設、そして戻り経路上のあらゆるステートフル機器。トンネル越しのセッションは、その上に乗っていない依存関係を外すことはできません。

切り分ける価値のある三つの決定

設計がこれらを混ぜると、障害の会話は堂々巡りになります。まず紙の上で切り分け、次にそれぞれを実際に強制する機器に割り当ててください。

DecisionWho controls itTypical failure
Which prefixes may cross the relationship?Both sides, through prefix and AS-path policy you configure deliberatelyA default route accepted by mistake, or a vague aggregate
Which overlay next hop wins?Local BGP selection plus next-hop resolution on your own routersPrefix learned, never installed in the forwarding table
Where do the encrypted packets travel?The underlay operators, unless a supported service adds real controlPath diversity that was never there

行ごとに所有者が違います。一つ目は交渉、二つ目はあなたの機器の設定、三つ目は主に他人のネットワークです。触れる行を名指しした変更要求は、BGPの問題と言う要求よりはるかに承認しやすいものです。

計画しておく価値のある障害モード

ピアのサマリールートを受け入れるのが最も多い自傷です。誰かが交換を簡単にするために短い集約を広告し、遠端がそれを受け入れ、トンネルの背後にない範囲のトラフィックがトンネルをたどって死にます。期待するプレフィックスを正確にフィルターするか、正しい境界のプレフィックスリストを使い、セッションが整って見えるからといって裸の集約を決して受け入れないでください。

撤回のタイミングが二つ目です。検出はホールドタイマー、有効にしていればBFD、トンネルのデッドピア検出、そして遠端が広告をやめる速さに依存します。既存のセッションは別問題です。新しい経路は新しい接続を回復しても、確立済みのTCPセッションは古いアドレスを使い続け、経路上のステートフルファイアウォールやNATは一致しなくなったエントリを保持することがあります。経路変更で全てが解決すると思い込むのではなく、アプリケーションの回復を受け入れ基準に入れてください。

三つ目は戻り経路の非対称性です。トラフィックがトンネルで到着し、それを運ぶために作られたわけではないプロバイダーリンクで戻ることがあり、片方向の音声、失敗するハンドシェイク、応答を落とすファイアウォールとして現れます。両方向を別々に確認してください。

契約に何を書き、どう検証するか

各範囲を生成する権限が誰にあるか、デフォルトルートが許可されるか、トンネルサービスがどのアドレスファミリーをサポートするかを含め、許可するプレフィックスを書面で求めてください。RFC 8212は、それに従う実装において、明示的なインポートとエクスポートのポリシーをeBGPの期待事項にしました。暗黙の全部受け入れ動作にまだ頼っているピアは、問い合わせる価値があります。

次に図ではなく機器から検証してください。FRR系ルーターで有用なコマンド：

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

ルーティングテーブルが与えられない二つの観察を加えてください。カプセル化されたパケットが実際にどのアドレスを狙っているかを確認するには、たとえばtcpdump -ni eth0 udp port 51820のように、WireGuardトンネルやIPsecのESPフィルターで外側インターフェースをキャプチャしてください。次にピアのパブリックアドレスへ向けてトレースし、トンネル内のトレースとホップを比較して、両方が同じプロバイダーの連鎖をたどるなら、あなたの冗長性はネットワークではなくルーティングポリシーに住んでいます。

最後に、撤回を意図的にテストしてください。メンテナンスウィンドウ中にトンネルを落とし、プレフィックスがどれだけインストールされたままか、既存セッションがどうなるか、遠端が実際に受け入れられる経路にフォールバックするかを記録します。その演習は、どんな図よりも設計について多くを語ります。

経路は認可ではありません。交換に合意したプレフィックスは、どのユーザーがトンネルの背後のどのサービスに到達できるかを何も語らないので、認証、許可サービス、ホストファイアウォールは元の場所にそのまま置いてください。到達可能なピアも、無制限のトランジットや任意のアドレスの生成の許可ではなく、その種の権限は商業的な問題として契約に属し、BGPポリシーの行に属しません。

  • 各側が生成できるプレフィックスと、決して受け入れてはならないプレフィックスを挙げてください。
  • トンネルでMSSをクランプし、大きなアップデートが実際に届くことを確認してください。
  • 共有アンダーレイ依存関係を列挙し、トンネルの数ではありません。
  • 実際の撤回を計測し、アプリケーションがどう振る舞うか記録してください。

関連記事