Zenn
Microsoft (有志)Publicationへの投稿
🫐

ExpressRoute 経由で hub-spoke1-spoke2 の spoke2 までは届きません！

Masato Ueda
2023/07/15に公開
Azure
network
Microsoft
ExpressRoute
tech

はじめに

Azure VNet の VNet Peering は推移的ではありません。
例えば
VNet1 ---(peerig)--- VNet2 ---(peering)--- VNet3
という場合、VNet Peering で接続されている VNet1 から VNet2 へは通信できますが、その奥の VNet3 への通信はできません。

https://learn.microsoft.com/ja-jp/windows-server/networking/sdn/vnet-peering/sdn-vnet-peering#requirements-and-constraints

さて、ExpressRoute も加えた以下の構成の場合には、オンプレミス拠点から、VNet1,2,3 どこまで通信で可能でしょうか？
On-Premise ---(ExpressRoute)--- VNet1 ---(peerig)--- VNet2 ---(peering)--- VNet3


答えは VNet2 まで、です。

試す - VNetPeering - useRemoteGateway の設定

では、VNetを作り、Peering をしていきます。
まずは ExpressRoute Gateway を配置している Hub VNet と Spoke VNet 間の VNet Peering です。
Hub側では、Spoke側に ExpressRoute Gateway の利用を許可する設定、また、
Spoke 側から、Hub側にあるゲートウェイを利用する設定が実施できます。


一方で、Spoke VNet 間の VNet Peering を設定します。
こちらの Peering では、ゲートウェイを利用する設定ができません。


この設定の有無がほぼ答えなのですが、ExpressRoute 経由でオンプレミスに広報されるルートは、リモートゲートウェイ設定の有無で決まります。

動作を確認

オンプレミスの PC から、各 VNet 内の VM へ ping を実施します。
想定通りの以下の結果が得られました。

VNet1 (hub) : 10.200.0.4 - 応答アリ
VNet2 (spoke1) : 10.210.0.4 - 応答アリ
VNet3 (spoke2) : 10.220.0.4 - 応答なし

C:\Windows\System32>ping 10.200.0.4

10.200.0.4 に ping を送信しています 32 バイトのデータ:
10.200.0.4 からの応答: バイト数 =32 時間 =5ms TTL=62
10.200.0.4 からの応答: バイト数 =32 時間 =4ms TTL=62
10.200.0.4 からの応答: バイト数 =32 時間 =4ms TTL=62
10.200.0.4 からの応答: バイト数 =32 時間 =3ms TTL=62

10.200.0.4 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 3ms、最大 = 5ms、平均 = 4ms

C:\Windows\System32>
C:\Windows\System32>ping 10.210.0.4

10.210.0.4 に ping を送信しています 32 バイトのデータ:
10.210.0.4 からの応答: バイト数 =32 時間 =5ms TTL=62
10.210.0.4 からの応答: バイト数 =32 時間 =3ms TTL=62
10.210.0.4 からの応答: バイト数 =32 時間 =4ms TTL=62
10.210.0.4 からの応答: バイト数 =32 時間 =4ms TTL=62

10.210.0.4 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 3ms、最大 = 5ms、平均 = 4ms

C:\Windows\System32>
C:\Windows\System32>ping 10.220.0.4

10.220.0.4 に ping を送信しています 32 バイトのデータ:
10.100.20.1 からの応答: 宛先ホストに到達できません。
10.100.20.1 からの応答: 宛先ホストに到達できません。
要求がタイムアウトしました。
10.100.20.1 からの応答: 宛先ホストに到達できません。

10.220.0.4 の ping 統計:
    パケット数: 送信 = 4、受信 = 3、損失 = 1 (25% の損失)、

C:\Windows\System32>

ルートテーブルなど

ExpressRoute 側のルートテーブルを見てみます。
ExpressRoute Gateway の存在する 10.200.0.0/16 のサブネットと、リモートゲートウェイの設定を有効化した Spoke1 の 10.210.0.0/16 のサブネットが、オンプレミス側に広報されていることがわかります。
Spoke2 の 10.220.0.0/16 のサブネットは、オンプレミス側に広報されていません。

また、オンプレミス側スイッチのルートテーブルを見てみます。
ExpressRoute 側から広報されているルートを BGP で受け取っていることを確認できます。

Router#
Router#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C        10.100.20.0/24 is directly connected, Vlan20
L        10.100.20.1/32 is directly connected, Vlan20
B        10.200.0.0/16 [20/0] via 172.16.0.10, 20:40:04
B        10.210.0.0/16 [20/0] via 172.16.0.10, 00:01:29
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.0.8/30 is directly connected, GigabitEthernet9.722
L        172.16.0.9/32 is directly connected, GigabitEthernet9.722
Router#
Router#show ip bgp
BGP table version is 20, local router ID is 172.16.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.100.20.0/24   0.0.0.0                  0         32768 i
 *>  10.200.0.0/16    172.16.0.10                            0 12076 i
 *>  10.210.0.0/16    172.16.0.10                            0 12076 i
Router#

まとめ

VNet Peering が推移的でないことにより、On-Premise(ExpressRoute) - Hub - Spoke1 - Spoke2 の構成で、On-Premise から Spoke2 への通信ができないことがわかりました。

このことはある種制限のようにも思えますが、この特徴を生かし、Spoke2 を DMZ のように利用することが可能です。
Spoke1 に配置したアプリケーション類を オンプレミス側 からも、Spoke2 に配置した ApplicationGateway(WAF) を経由して インターネット側からも利用可能にしつつ、Spoke2 インターネット側 から オンプレミス への侵入を難しくすることができるからです。

この点は、こちらのガイド "Azure CAF Landing Zones 設計・構築ハンズオン"-"10.Spoke B DMZ WAF の作成" で詳しく解説されており、参考になります。

参考URL

https://learn.microsoft.com/ja-jp/windows-server/networking/sdn/vnet-peering/sdn-vnet-peering#requirements-and-constraints

https://github.com/nakamacchi/AzureCAF.LandingZones.Demo#L1

Microsoft (有志)
Microsoft (有志)Publication

Microsoft Azureをはじめとする最新技術情報をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。

Discussion