複数の Hub-spoke アーキテクチャで spoke-to-spoke を実現する
という方法はいくつかあると思っていて試していくシリーズのひとつです。
ここでは以下のアーキテクチャを考えます。
- spk は spoke の略です
- spk12 に丸がなくなっちゃってますが気にしないでください。。
- Hub-spoke アーキテクチャが 2 つあって、その間を VPN Gateway の VPN + BGP の構成でつないであります
その他の実装方法はこちらにまとめています。
動作確認
このアーキテクチャで、手元の PC からまずは spoke11 にある Azure VM へログインします。
このリモート デスクトップ接続には hub01 にある Bastion を利用しています。
そのうえで、hub01 にある Azure VM、hub02 にある Azure VM、spoke11 にある Azure VM、spoke12 にある VM とそれぞれログインした画面が以下のとおりです。
裏に隠れてしまっているのが spoke11 の VM に直接ログインしたそのままの画面で、真ん中上が hub01、左下から右に向かって hub02、spoke11、spoke12 という順に並んでいます。
先ほどのアーキテクチャの図に合わせるとこのような感じでしょうか。
spoke01 から spoke02 は UDR を書いていないのでつながりません。
それ以外は UDR を書かなくとも、BGP の経路制御のみで相互に接続できています。
vm-spoke10 の effective routes はどのようになっているか
vm-spoke10 の NIC である nic-spoke10 において、effective routes から表示させます。
10.10.0.0/16 が vm-spoke10 のある VNet の IP アドレス空間となっています。
10.0.0.0/16 は直接つながっている hub となっているので Next Hop Type が VNet peering となっています。
そのほか 2 番目の hub である 10.100.0.0/16 やその先にある spoke たちである 10.110.0.0/16 と 10.120.0.0/16 は Virtual network gateway となっています。
ExpressRoute のパターンとは異なり、それぞれの経路が 1 回ずつしか表示されていませんが、VPN Gateway を Act-Act で BGP を張ればまた違った見た目になるかとは思います。
ここで見えている 20.239.118.196 は VPN Gateway #2 の Public IP です。
ちょっと謎ですがまぁそういうもんなんでしょう。
この情報だけでは対向を見てみないと何とも言えませんが、基本的には vm-spoke20 以外とは通信できそうなことがうかがえます。
| Source | State | Address Prefixes | Next Hop Type | Next Hop IP Address | User Defined Route Name |
|---|---|---|---|---|---|
| Default | Active | 10.10.0.0/16 | Virtual network | - | - |
| Default | Active | 10.0.0.0/16 | VNet peering | - | - |
| Virtual network gateway | Active | 10.100.200.254/32 | Virtual network gateway | 20.239.118.196 | - |
| Virtual network gateway | Active | 10.100.0.0/16 | Virtual network gateway | 20.239.118.196 | - |
| Virtual network gateway | Active | 10.110.0.0/16 | Virtual network gateway | 20.239.118.196 | - |
| Virtual network gateway | Active | 10.120.0.0/16 | Virtual network gateway | 20.239.118.196 | - |
tracert の結果はどうなるか
事前に、tracert に反応させるため、それぞれの Windows Server では Windows Firewall with Advanced Security を無効化しておきます。
結果として、それぞれの VM へと通信ができることを確認しています。
なかなか不思議なもので、VPN でつながっている部分での hop 追加がなく、すべてが 1 hop で見えてますね。
2 つの Hub-spoke 構成はそれぞれ east asia にあり、同じリージョンなので latency もかなり小さいようです。
> tracert -d 10.0.0.4
Tracing route to 10.0.0.4 over a maximum of 30 hops
1 3 ms <1 ms 1 ms 10.0.0.4
Trace complete.
> tracert -d 10.100.0.4
Tracing route to 10.100.0.4 over a maximum of 30 hops
1 6 ms 3 ms 3 ms 10.100.0.4
Trace complete.
> tracert -d 10.110.0.4
Tracing route to 10.110.0.4 over a maximum of 30 hops
1 4 ms 5 ms 4 ms 10.110.0.4
Trace complete.
> tracert -d 10.120.0.4
Tracing route to 10.120.0.4 over a maximum of 30 hops
1 4 ms 3 ms 3 ms 10.120.0.4
Trace complete.
参考実装はこちらです。
書き直したタイミングで Ubuntu Server 20.04 にしてしまいました、ごめんなさい。
Discussion