TL;DR
- Remote Gateway が使えなくても使っているような感じで通信ができるようにしたい
- いくつかの方法があるので、pros/cons 考えて選択していただければと
Update log
- 全体的に
# (見出し1)から## (見出し2)に変更 - 2024/04/22 - VNet-to-VNet のパターンを追加し、パターンのまとめも追加 - 2024/04/22
Remote Gateway が使えない状況とは
VNet Peering の設定として useRemoteGateways がありますが、これは VNet の中に Virtual Network Gateway があると使えません。
一般的な Hub-Spoke 構成であれば Spoke 側に Virtual Network Gateway を作成することはなく、問題はありません。
ただし、さまざまな事情が重なり、たとえば ExpressRoute Gateway を持っている VNet 同士を接続し、かつそれを Hub-Spoke 構成のようにオンプレミスから通信させる必要が出てくることがあります。
Remote Gateway が使えないとどうなるのか
たとえば ExpressRoute で接続されている拠点目線だと、useRemoteGateway が設定されていない VNet Peering 先のアドレス空間は BGP で経路広報されてきません。
オンプレミスの中だけであれば Static Route を書くことで何とかできそうな気がしますが、ExpressRoute にかかわるコンポーネントの関係上、それだけでは通信できません。
そのため、なんらかの形で経路が見えるようにするか、経路が見えなかったとしても NAT などで通信させる必要が出てきます。
そんな時にどうしようか、ということでいくつかのパターンを考えてみます。
パターンまとめ
ざっとまとめておきます。
以前は書いていなかった 1 のパターンが一番いいんじゃないかということで、3 ～ 5 の存在意義が薄くなっています。。
| 項番 | パターン | メリット | デメリット |
|---|---|---|---|
| 1 | VNet-to-VNet の VPN を利用するパターン | マネージド サービスだけで構成できる | VPN Gateway のサイズに制限される、Azure Route Server は必要 |
| 2 | NAT を利用するパターン | マネージド サービスだけで構成できる、帯域の制限はない | 片方向ずつの対応になる |
| 3 | Azure Route Server を利用するパターン #1 | ない、 | 構成が難しい |
| 4 | Azure Route Server を利用するパターン #2 | ない、、 | 構成が難しい |
| 5 | Azure Route Server を利用するパターン #3 | ない、、、 | 構成が難しい |
| 6 | VXLAN を用いたパターン | コストとしては一番最小かもしれない | NVA が必要 |
VNet-to-VNet の VPN を利用するパターン
ExpressRoute Gateway に加えて、VPN Gateway を hub と spoke に追加で配置し、hub と spoke の VNet 間で VNet-to-VNet の VPN を構成するパターンです。
前提として、ExpressRoute と VPN の相互乗り入れを実現するためには Azure Route Server (ARS) が必要ですが、その場合 VPN Gateway の ASN は 65515 である必要があります。
しかし、(VNet-to-VNet ではない) 通常の VPN を利用する場合、対向の IP アドレス等のリソースを表す Local Network Gateway で ASN 65515 を指定することができず、詰みます。
ということで VNet-to-VNet の VPN を利用する、ということになります。
メリットとしては ExpressRoute Gateway、VPN Gateway、Azure Route Server ということで、すべてマネージドサービスで構成することができ、冗長性に関しても比較的簡単に構成ができます。
デメリットとしては、VPN Gateway を通ることになるため、本来 hub-spoke 間の VNet Peering には存在しない、帯域の制限がかかってしまいます。
大量のトラフィックを流す必要がある場合、VPN Gateway の SKU を上げる必要が出てきます。
NAT を利用するパターン
次に紹介するパターンでは NAT を利用します。
NAT といっても NVA などでの NAT ではなく、Private Link Service を利用した Azure Managed な NAT 環境を利用します。
ただし、NAT を利用しているので片方向からしか通信可能ではない。
- Spoke 側の Azure VM の前に Standard Load Balancer を配置し、Private Link Service を作成する
- Private Link Service に対して、Hub 側 VNet で Private Endpoint を作成する
- オンプレミスからは Hub 側の VNet にある IP アドレスへ通信しているように見えて、実際には Spoke 側へと通信させる
参考実装はこちら
Azure Route Server を利用するパターン #1
経路が見えないなら見えるようにしてしまおう、ということで ARS (Azure Route Server) と NVA を利用するパターンです。
ARS 自体にそこそこコストがかかることと、NVA の運用にやや負荷のかかるのがデメリットですが、接続できれば Remote Gateway を使っているのとほぼ変わらないように通信が可能です。
- Hub 側の VNet に ARS を配置し、同 VNet に配置した NVA から Spoke VNet のアドレス空間を経路広報する
- Spoke からオンプレミスへのトラフィックは UDR (User Defined Route) で戻りの経路を書き、next-hop は Hub の NVA とする
- オンプレミス側では経路が見えているので何も工夫しなくてもよい
参考実装はこちら
Azure Route Server を利用するパターン #2
以下の docs に書いてある構成を参考にしたアーキテクチャを考えます。
dual-homed-topology-expressroute
書かれている図を書き直したものがこちらです。
ExpressRoute and Azure Route Server on dual homed network
NVA で 2 つの ARS に対して BGP の経路交換を行い、双方の経路が見えるようにします。
中央上の ARS と NVA との BGP においては、以下のような経路が交換される。
- ARS → NVA に中央上の VNet のアドレス空間が経路広報される
- NVA → ARS に ExpressRoute でもらってきた経路を (を ARS から受け取って) 経路広報する
次に、NVA と同じ VNet にある ARS との間では以下のような経路が好感される。
- ARS → NVA に ExpressRoute でもらってきた経路が経路広報される
- NVA → ARS に中央上の VNet のアドレス空間が経路広報され、ARS を経由して ExpressRoute 経由でオンプレミスに経路広報されていく
これにより、Remote Gateway を使っていないにもかかわらず、中央上の VNet のアドレス空間と、ExpressRoute で接続された拠点のネットワークアドレスが互いに見えるようになり、双方向での通信が可能となる。
ちなみに、なぜこんなに複雑な構成になるかというと、ExpressRoute が接続される Hub 的な VNet が複数ある状態では、両方の Hub への VNet Peering で use remote gateway の設定を有効化できないためです。
そのため、Spoke の IP アドレス空間が ExpressRoute 経由でオンプレミスに広報されないため、これを ARS で補う必要があります。
これは逆もしかりで、remote gateway の設定が使えないために Spoke 側で ExpressRoute でもらってきた経路を学習できないため、これも ARS で補う必要があります。
Azure Route Server を利用するパターン #3
#2 のパターンを少し崩し、一部の設定が自動で変更されないものの、中央上の VNet に ARS を置かずに、UDR で個別に書くことで実現するパターンです。
構成のイメージ図はこちらです。
ExpressRoute and Azure Route Server on dual homed network with User Defined Routes
中央上の VNet で ARS を利用すると、Remote Gateway が使えなくなってしまうため、Virtual WAN との VNet peering で問題が発生したため試してみた構成です。
ExpressRoute で接続された拠点のネットワークアドレスは中央上の ARS へと BGP 経路広報されてくる、という動作がないため、これの代わりに UDR を書くという感じです。
拠点のネットワークアドレスが増減するたびに UDR を書き換える必要がありますが、それ以外は #2 と同じです。
VXLAN を用いたパターン
こちらは ARS を利用せず純粋に NVA だけで実装するパターンです。
NVA および VXLAN ということであまり慣れていないことも多いでしょうが、原理的には一番コストが安いのではないかと思います。
厳密にいえば VXLAN の header overhead があるので少しパケットは小さくなるはず
- オンプレミス側の NVA と Hub の NVA の間で VXLAN tunnel を張る
- オンプレミス側から Spoke、Spoke からオンプレミス側は NVA を通る必要があるため UDR を書く
- NVA 同士は Static Route を駆使して、必要なトラフィックのみが VXLAN を経由するようにする
参考実装はこちら
まとめ
さまざまな理由により、Remote Gateway が使えない状況でも オンプレミス - ExpressRoute - Hub - Spoke のような構成が必要になることがあります。
その場合の回避策、構成案についてまとめてみました。
Discussion