TL;DR
- Remote Gateway が使えなくても使っているような感じで通信ができるようにしたい
- いくつかの方法があるので、pros/cons 考えて選択していただければと
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 などで通信させる必要が出てきます。
そんな時にどうしようか、ということでいくつかのパターンを考えてみます。
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 を経由するようにする
参考実装はこちら
Discussion