1 | 概要
本ドキュメントは、オンプレミスでFortiGateをActive-PassiveのHA構成で運用し、冗長化された回線でAzure VPN GatewayとBGP接続する際の経路制御について、その**実現可能性と限界**を解説するものである。特に、Azureからオンプレミスへの「帰り」のトラフィックを意図通りに制御できる構成と、できない構成の違いに焦点を当てる。
2 | 主な課題: BGP属性とNext-Hop解決時のECMP
この問題は、BGPの経路選択プロセスと、その手前で動作するAzureネットワーク基盤のECMP（Equal-Cost Multi-Path）の相互作用に起因する。
- Next-Hopへの到達性解決: Azureのネットワーク基盤は、まずBGPで学習した経路のNext-Hop（この場合はFortiGateのBGPピアIP）への到達方法を解決する。
- ECMPの適用: この解決の段階で、Next-Hopへのパスが複数等コストで存在する場合、この時点でECMPが適用され、トラフィックの分散が決定される。
- BGPベストパス選定: BGPのパス属性（AS PATH長やConnection Weight）の比較は、この後段で行われる。しかし、ステップ2でECMPが適用された場合、BGP属性でパスに差をつけても、物理的な回線（トンネル）の選択には影響を与えられない。
つまり、「帰り」の制御が不能となるのは、BGP属性の比較が行われる前に、AzureのECMP動作が優先されてしまうためである。
3 | 制御不能な構成パターン: フルメッシュ
冗長性を最大化するためにVPNトンネルをフルメッシュで構成した場合、Azure側のECMP動作により「帰り」の経路制御は**不能**となる。
3-1 | 前提条件
| コンポーネント | 構成 |
|---|---|
| FortiGate | Active-Passive HA (単一の論理BGPピアとして動作) |
| オンプレミス物理回線 | 2本 (例: ISP-A, ISP-B) |
| Azure VPN Gateway | Active-Active 冗長化 (2インスタンスで動作) |
| VPNトンネル | フルメッシュ (合計4本のトンネル) |
[Azure VNet] <--> [VPN GW Inst-A] -- [VPN GW Inst-B]
| \ / |
(Tunnels via ISP-A & ISP-B)
| \ / |
[FortiGate HA Cluster]
Azureの各GWインスタンス（GW-A, GW-B）から見て、FortiGate HAという単一BGPピアへの到達経路が、ISP-A経由とISP-B経経由の2つずつ存在する。これらがNext-Hop解決の段階で等コスト（ECMP）と判断されるため、BGPのAS PATHプリペンドやConnection Weightを操作しても、トラフィックが着信する回線を選択することはできない。
4 | 制御可能な構成パターン: 回線ごとに接続を分離
各オンプレミス回線が、それぞれ特定のAzure VPN GWインスタンスとのみピアを確立するよう意図的に構成することで、ECMPの前提を崩し、「帰り」の経路制御を可能にする。
4-1 | 前提条件
| コンポーネント | 構成 |
|---|---|
| FortiGate | Active-Passive HA (単一の論理BGPピアとして動作) |
| オンプレミス物理回線 | 2本 (例: ISP-A, ISP-B) |
| Azure VPN Gateway | Active-Active 冗長化 (2インスタンスで動作) |
| VPNトンネル | 回線ごとに１つのVPNゲートウェイにのみ接続 (合計2本のトンネル) |
4-2 | 構成図
[Azure VNet] ---> [VPN GW Inst-A] [VPN GW Inst-B]
| |
(Tunnel-A via ISP-A) (Tunnel-B via ISP-B)
| |
[FortiGate HA Cluster] <--------------------
4-3 | なぜ制御可能になるのか
この構成では、Azure側から見たBGP Next-Hopへの到達経路がECMPとならないため、BGPのパス選択アルゴリズムが意図通りに機能する。
- Next-Hopへの経路が単一化される: Azure GW-Aから見るとFortiGateピアへの経路はTunnel-Aの1つだけ、Azure GW-Bから見るとTunnel-Bの1つだけになる。
- BGPのパス選択が有効になる: Next-Hop解決でECMPが発生しないため、Azure VNetはGW-A経由とGW-B経由の経路をBGPの属性（AS PATH長）で正しく比較・選択する。
5 | 各構成パターンのメリット・デメリット比較
| 比較項目 | 制御可能な構成（回線ごとに接続） | 制御不能な構成（フルメッシュ） |
|---|---|---|
| 「帰り」の経路制御 | ◎ 可能 | × 不可能 |
| 冗長性 | △ 限定的（回線またはAzure GWインスタンス障害で片系がダウン） | ◎ 最大（4本のトンネルで最大限の冗長性を確保） |
| パフォーマンス/帯域 | △ 帯域は優先回線分に制限される | ○ ECMPにより複数トンネルに分散し、帯域を有効活用できる |
| 推奨ユースケース | 「帰り」の経路を厳密に制御する必要がある場合（例: 特定のセキュリティ機器を経由させたい） | 冗長性とスループットを最優先し、「帰り」の経路が分散しても許容できる場合 |
6 | アーキテクチャの変更による解決策
フルメッシュ構成の冗長性を維持しつつ「帰り」の経路を制御したい場合は、BGP属性の操作ではなく、AzureがECMPを適用する前提そのものを変える**アーキテクチャの変更**が必要となる。
| 構成 | 概要 | なぜ解決できるのか |
|---|---|---|
| VRRP / VDOM構成 | 各FortiGateやVDOMを独立したBGPルータとして動作させる。 | Azureからは**2つの異なるBGPピア**として認識される。これにより、Next-Hopが異なるためECMPの対象とならず、純粋なBGPパス選択アルゴリズムでピアごとに経路を決定するため、制御が可能になる。 |
| Azure Virtual WAN / ハブNVA | Azure側で経路制御を集中管理するアーキテクチャ。 | Azureのルーティングポリシーを明示的に設定し、VPN GatewayのデフォルトECMP動作を上書きすることができる。これにより、オンプレミス側の構成に依存せず、Azure側で能動的に経路を制御できる。 |
7 | 経路制御の粒度について
本ドキュメントで解説する経路制御は、**回線単位**での主従制御と、**宛先単位**でのポリシー制御の2つの粒度で考える必要がある。
| 構成パターン | 回線単位の制御 | 宛先単位の制御 |
|---|---|---|
| フルメッシュ | 不可能 | 不可能 |
| 回線ごとに接続を分離 | 可能 (AS PATHプリペンド等で実現) |
可能 (FortiGateのルートマップとポリシールーティングの組み合わせで実現) |
8 | まとめ
FortiGate HA構成とAzure VPN Gateway間の経路制御における要点は以下の通りである。
- 「帰り」の経路制御の可否は、Azureのネットワーク基盤がBGPのNext-Hop解決時に**ECMPを適用するか否か**で決まる。
- VPNトンネルを**フルメッシュ**で構成すると、ECMPが適用されるため、BGP属性による「帰り」の経路制御は**不可能**となる。
- VPNトンネルを**回線ごとに１つのVPNゲートウェイにのみ接続**（パスを分離）する構成にすれば、ECMPを回避でき、AS PATHプリペンドによる経路制御が**可能**となる。
- 構成の選択は、経路制御の厳密性と冗長性・スループットのどちらを優先するかのトレードオフで決定されるべきである。
- フルメッシュ構成で厳密な経路制御が必要な場合は、**アーキテクチャの変更**が唯一の解決策となる。