はじめに
Azure 上の仮想ネットワークが VNet ピアリングで接続されている場合、オンプレミスから ExpressRoute 経由で到達できる範囲は限られています。
例えば次の構成を組んだ場合、VNet ピアリングで意図的に設定を追加しない限り、オンプレミスから到達できるのは HubVnet のみです。仮想ネットワークが ExpressRoute 回線に広報するアドレス帯が HubVnet だけだからです。
到達できる範囲1
VNet ピアリングの設定で Gateway Transit を有効化すると、オンプレミスから twoHopVnet まで到達できます。Gateway Transit を有効化すると、仮想ネットワークは ExpressRoute 回線に対して、HubVnet だけでなく twoHopVnet のアドレス帯も広報するようになるからです。
到達できる範囲2
参考：仮想ネットワーク ピアリングの VPN ゲートウェイ転送を構成する
ですが、VNet ピアリングの設定だけでは、どう頑張っても threeHopVnet には到達できません。
オンプレミスから threeHopVnet に到達出来るようにするには以下のいずれかの構成にする必要があります。
- twoHopVnet 上にリバースプロキシや仮想アプライアンスを設置して、threeHopVnet のアドレス帯を宛先 NAT する。つまり、オンプレがアクセスする IP アドレスはあくまでも twoHopVnet のアドレス帯
- hubVnet と threeHopVnet を Gateway Transit つきの VNet ピアリングで接続しつつ、ユーザ定義ルートで twoHopVnet の仮想アプライアンスを経由で通信するようにする
- twoHopVnet 上に仮想アプライアンスを設置して、Azure Route Server を利用して threeHopVnet のアドレス帯をオンプレミスに広報する
過去に案1の構成の NAT 版はブログを書きました。
参考：Azure 仮想ネットワーク上で NAT を実現する際のポイント
案2のイメージは次の通りです。
案2の構成イメージ
オンプレミスに threeHotVnet のアドレス帯を広報するために、Gateway Transit が有効な VNet ピアリングで HubVnet と ThreeHopVnet を接続します。ですがこのままだと VNet ピアリングによって有効になったルーティングによって、オンプレミスと threeHopVnet が twoHopVnet を経由せずに直接通信してしまいます。そこで、twoHopVnet の仮想アプライアンスを経由するユーザ定義ルートを追加することで、VNet ピアリングで有効になったルーティングを打ち消します。
できるといえばできますが、打ち消すルーティングの設定を誤ると非対称ルーティングになったり、twoHopVnet を経由しなくなったりします。オンプレミスから広報されるアドレス帯または Azure で利用アドレス帯が増減する環境だと、運用の負担が高いです。
というわけで、案2よりもシンプルに実装できる案3を試しました。
やりたいこと
せっかくなので？たくさんの仮想アプライアンスをを経由してオンプレミスと ThreeHopVnet 間の通信を実現します。HubVnet に Azure Firewall が存在しており、オンプレミスと Azure 間の通信を Azure Firewall で制御するようなシナリオを採用されているお客様もいると思うので、Azure Firewall 相当の hubVnet の NVA を経由した上で、twoHopVnet の NVA を経由して threeHopVnet を目指します。
やりたいことの構成イメージ
Azure Route Serve を利用して threeHopVnet のアドレスを広報する
オンプレミスから threeHopVnet にアクセスするためには、ExpressRoute 回線がオンプレミスに対して threeHopVnet のアドレス帯を広報しなければなりません。そのために利用するものが Azure Route Server です。Azure Route Server は BGP で学習した経路を VNet に注入するサービスですが、ブランチ間接続のオプションを有効化することで、仮想ネットワークゲートウェイとも経路交換をはじめます。
ExpressRoute と Azure VPN に対する Azure Route Server のサポート
> (Get-AzRouteServer -ResourceGroupName multihop -RouteServerName rs).AllowBranchToBranchTraffic
True
threeHopVnet のアドレス帯をどこの NVA から広報するか悩みますが、せっかくなのでピアリング先の twoHopVnet 上の NVA(10.2.0.4) から広報することにしました。
> (Get-AzRouteServer -ResourceGroupName multihop -RouteServerName rs).Peerings
PeerAsn Name PeerIp ProvisioningState
------- ---- ------ -----------------
65147 twoHubNva 10.2.0.4 Succeeded
この時点で次のような構成になっています。
Route Server 導入後の構成イメージ
ただし、普通に広報すると threeHopVnet のアドレス帯のネクストホップが経路を広報した twoHopVnet 上の NVA(10.2.0.4) になってしまい、通信時に hubNva を経由しません。
> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName multihop -VirtualNetworkGatewayName ergw
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
10.1.0.140 10.1.0.0/24 10.1.0.140 Network 32768
10.1.0.140 192.168.0.0/26 10.1.0.132 10.1.0.132 EBgp 12076-31898 32769
10.1.0.140 192.168.0.0/26 10.1.0.133 10.1.0.133 EBgp 12076-31898 32769
10.1.0.140 10.2.0.0/24 10.2.0.4 10.1.0.69 IBgp 65147 32768
10.1.0.140 10.2.0.0/24 10.2.0.4 10.1.0.68 IBgp 65147 32768
10.1.0.140 10.3.0.0/16 10.2.0.4 10.1.0.69 IBgp 65147 32768
10.1.0.140 10.3.0.0/16 10.2.0.4 10.1.0.68 IBgp 65147 32768
10.1.0.140 192.168.0.0/26 10.1.0.133 10.1.0.68 IBgp 12076-31898 32768
10.1.0.140 192.168.0.0/26 10.1.0.133 10.1.0.69 IBgp 12076-31898 32768
これを回避するために、ルートマップを利用して twoHopVnet 上の NVA から広報する経路の NextHop を 自分自身の 10.2.0.4 から hubVnet 上の NVA の 10.1.0.4 に変更します。
ip route 10.3.0.0/16 10.2.0.1
ip route 10.2.0.0/24 10.2.0.1
!
router bgp 65147
bgp log-neighbor-changes
no bgp ebgp-requires-policy
neighbor 10.1.0.68 remote-as 65515
neighbor 10.1.0.68 ebgp-multihop
neighbor 10.1.0.69 remote-as 65515
neighbor 10.1.0.69 ebgp-multihop
!
address-family ipv4 unicast
network 10.2.0.0/24
network 10.3.0.0/16
neighbor 10.1.0.68 route-map out out
neighbor 10.1.0.69 route-map out out
exit-address-family
exit
!
route-map out permit 10
set ip next-hop 10.1.0.4
exit
!
end
そうすると、ExpressRoute Gateway が学習する threeHopVnet のアドレス帯のネクストホップが 10.1.0.4 に変わります。
> Get-AzRouteServerPeerLearnedRoute -ResourceGroupName multihop -RouteServerName rs -PeerName twoHubNva
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
10.1.0.69 10.2.0.0/24 10.1.0.4 10.2.0.4 EBgp 65147 32768
10.1.0.69 10.3.0.0/16 10.1.0.4 10.2.0.4 EBgp 65147 32768
10.1.0.68 10.2.0.0/24 10.1.0.4 10.2.0.4 EBgp 65147 32768
10.1.0.68 10.3.0.0/16 10.1.0.4 10.2.0.4 EBgp 65147 32768
> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName multihop -VirtualNetworkGatewayName ergw
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
10.1.0.140 10.1.0.0/24 10.1.0.140 Network 32768
10.1.0.140 192.168.0.0/26 10.1.0.132 10.1.0.132 EBgp 12076-31898 32769
10.1.0.140 192.168.0.0/26 10.1.0.133 10.1.0.133 EBgp 12076-31898 32769
10.1.0.140 10.3.0.0/16 10.1.0.4 10.1.0.68 IBgp 65147 32768
10.1.0.140 10.3.0.0/16 10.1.0.4 10.1.0.69 IBgp 65147 32768
10.1.0.140 10.2.0.0/24 10.1.0.4 10.1.0.68 IBgp 65147 32768
10.1.0.140 10.2.0.0/24 10.1.0.4 10.1.0.69 IBgp 65147 32768
10.1.0.140 192.168.0.0/26 10.1.0.132 10.1.0.69 IBgp 12076-31898 32768
10.1.0.140 192.168.0.0/26 10.1.0.132 10.1.0.68 IBgp 12076-31898 32768
ExpressRoute Gateway は学習した経路をオンプレミスに広報します。AdvertizedRoute の中に threeHopVnet のアドレス帯が含まれていることが分かります。また、該当の経路の AS-PATH に twoHopVnet の NVA の AS 番号である65147が含まれていることが分かります。
> Get-AzVirtualNetworkGatewayAdvertisedRoute -ResourceGroupName multihop -VirtualNetworkGatewayName ergw -Peer 10.1.0.132
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
10.1.0.140 10.1.0.0/24 10.1.0.140 Igp 65515 0
10.1.0.140 10.3.0.0/16 10.1.0.140 Igp 65515-65147 0
10.1.0.140 10.2.0.0/24 10.1.0.140 Igp 65515-65147 0
オンプレミス相当の OCI が学習しているルーティングにもしっかり threeHopVnet のアドレス帯が含まれます。
OCI 側のルートテーブル
「逆もまたしかり」ですので、twoHopVnet 上の NVA は Azure Route Server 経由でオンプレミスの経路を学習します。
twoHopNva# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 10.2.0.4, local AS number 65147 VRF default vrf-id 0
BGP table version 16
RIB entries 7, using 672 bytes of memory
Peers 2, using 40 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
10.1.0.68 4 65515 117 110 16 0 0 00:07:02 2 4 N/A
10.1.0.69 4 65515 115 111 16 0 0 00:06:58 2 4 N/A
Total number of neighbors 2
twoHopNva#
twoHopNva# show ip route
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 10.2.0.1, eth0, src 10.2.0.4, 01:31:50
B> 10.1.0.0/24 [20/0] via 10.1.0.68 (recursive), weight 1, 00:06:49
* via 10.2.0.1, eth0, weight 1, 00:06:49
via 10.1.0.69 (recursive), weight 1, 00:06:49
via 10.2.0.1, eth0, weight 1, 00:06:49
S>* 10.2.0.0/24 [1/0] via 10.2.0.1, eth0, weight 1, 01:31:49
C>* 10.2.0.0/26 is directly connected, eth0, 01:31:50
L>* 10.2.0.4/32 is directly connected, eth0, 01:31:50
S>* 10.3.0.0/16 [1/0] via 10.2.0.1, eth0, weight 1, 01:31:49
K>* 168.63.129.16/32 [0/100] via 10.2.0.1, eth0, src 10.2.0.4, 01:31:50
K>* 169.254.169.254/32 [0/100] via 10.2.0.1, eth0, src 10.2.0.4, 01:31:50
B> 192.168.0.0/26 [20/0] via 10.1.0.68 (recursive), weight 1, 00:06:49
* via 10.2.0.1, eth0, weight 1, 00:06:49
via 10.1.0.69 (recursive), weight 1, 00:06:49
via 10.2.0.1, eth0, weight 1, 00:06:49
ユーザ定義ルートをひたすら整える
ここまでくれば勝ったも同然です。あとはユーザ定義ルートをひたすら整えれば良いです。
ExpressRoute Gateway が送信した twoHopVnet と threeHopVnet 宛てのパケットを hubVnet の NVA（10.1.0.4）に届ける必要があるので、GatewaySubnet にルートテーブルを関連付けて次の UDR を追加します。
> (Get-AzRouteTable -ResourceGroupName multihop -Name hubGwSubRt).Routes
AddressPrefix Name NextHopType NextHopIpAddress ProvisioningState
------------- ---- ----------- ---------------- -----------------
10.2.0.0/24 twoHop VirtualAppliance 10.1.0.4 Succeeded
10.3.0.0/16 threeHop VirtualAppliance 10.1.0.4 Succeeded
パケットを受け取った hubVnet の NVA は、twoHopVnet と threeHopVnet 宛てのパケットを twoHopVnet の NVA（10.2.0.4）に届ける必要があるので、サブネットにルートテーブルを関連付けて次の UDR を追加します。
> (Get-AzRouteTable -ResourceGroupName multihop -Name hubNvaSubRt).Routes
AddressPrefix Name NextHopType NextHopIpAddress ProvisioningState
------------- ---- ----------- ---------------- -----------------
10.2.0.0/24 twoHop VirtualAppliance 10.2.0.4 Succeeded
10.3.0.0/16 threeHop VirtualAppliance 10.2.0.4 Succeeded
パケットを受けっとった twoHopVnet の NVA は threeHopVnet との VNet ピアリングによって threeHopVnet のアドレス帯へのルーティングを学習しています。なので threeHopVnet に到達する観点でのルーティングは不要です。
ただし、twoHopVnet 上の NVA が存在するサブネットにはオンプレミス宛てのルーティングが存在しません。そこで次のルーティングを追加して、オンプレミスへのパケットが hubVnet の NVA 経由になるようにします。
> (Get-AzRouteTable -ResourceGroupName multihop -Name twoHopNvaSubRt).Routes
AddressPrefix Name NextHopType NextHopIpAddress ProvisioningState
------------- ---- ----------- ---------------- -----------------
192.168.0.0/16 onpremise VirtualAppliance 10.1.0.4 Succeeded
パケットを受け取った threeHopVnet 上の VM は、twoHopVnet との VNet ピアリングで学習した twoHopVnet のアドレス帯のルーティングだけを知っています。このままではオンプレミスにパケットが戻らないので、オンプレミス宛ての通信を twoHopVnet の NVA（10.2.0.4）に戻すように、次のルーティングを追加します。
> (Get-AzRouteTable -ResourceGroupName multihop -Name threeHopVmSubRt).Routes
AddressPrefix Name NextHopType NextHopIpAddress ProvisioningState
------------- ---- ----------- ---------------- -----------------
192.168.0.0/26 onpremise VirtualAppliance 10.2.0.4 Succeeded
有効なルートの状態
hubVnet の NVA
オンプレミスの NextHop が ExpressRoute Gateway に向いています。また、threeHopVnet(10.3.0.0/16)の NextHop が twoHopVnet の NVA(10.2.0.4)に向いています。よさそう。
> Get-AzEffectiveRouteTable -NetworkInterfaceName hubNvaNic -ResourceGroupName multihop | Select-Object State,Source, AddressPrefix, NextHopType,NextHopIpAddress | ft *
State Source AddressPrefix NextHopType NextHopIpAddress
----- ------ ------------- ----------- ----------------
Active Default {10.1.0.0/24} VnetLocal {}
Invalid Default {10.2.0.0/24} VNetPeering {}
Active VirtualNetworkGateway {192.168.0.0/26} VirtualNetworkGateway {10.2.146.123}
Active VirtualNetworkGateway {192.168.0.0/26} VirtualNetworkGateway {10.2.146.122}
Invalid VirtualNetworkGateway {10.3.0.0/16} VirtualNetworkGateway {10.1.0.4}
Active Default {0.0.0.0/0} Internet {}
（デフォで入るNone系は省略）
Active User {10.2.0.0/24} VirtualAppliance {10.2.0.4}
Active User {10.3.0.0/16} VirtualAppliance {10.2.0.4}
twoHopVnet の NVA
オンプレミスの NextHop が HubVnet の NVA(10.1.0.4) に向いています。また、threeHopVnet(10.3.0.0/16)の NextHop が VNet ピアリングに向いています。よさそう。
> Get-AzEffectiveRouteTable -NetworkInterfaceName twoHopNvaNic -ResourceGroupName multihop | Select-Object State,Source, AddressPrefix, NextHopType,NextHopIpAddress | ft *
State Source AddressPrefix NextHopType NextHopIpAddress
----- ------ ------------- ----------- ----------------
Active Default {10.2.0.0/24} VnetLocal {}
Active Default {10.3.0.0/24} VNetPeering {}
Active Default {10.1.0.0/24} VNetPeering {}
Active Default {0.0.0.0/0} Internet {}
（デフォで入るNone系は省略）
Active User {192.168.0.0/16} VirtualAppliance {10.1.0.4}
threeHopVnet の VM
オンプレミスの NextHop が twoHopVnet の NVA(10.2.0.4) に向いています。よさそう。
> Get-AzEffectiveRouteTable -NetworkInterfaceName threeHopVmNic -ResourceGroupName multihop | Select-Object State,Source, AddressPrefix, NextHopType,NextHopIpAddress | ft *
State Source AddressPrefix NextHopType NextHopIpAddress
----- ------ ------------- ----------- ----------------
Active Default {10.3.0.0/24} VnetLocal {}
Active Default {10.2.0.0/24} VNetPeering {}
Active Default {0.0.0.0/0} Internet {}
（デフォで入るNone系は省略）
Active User {192.168.0.0/26} VirtualAppliance {10.2.0.4}
動作確認
オンプレ相当の OCI 上の仮想マシンで threeHopVnet の VM（10.3.0.68）に対して Traceroute した結果は次の通りです。2つの NVA（10.1.0.4と10.2.0.4）を経由して 10.3.0.68に到達していることが分かります。
root@instance-20240528-2358:~# traceroute -T 10.3.0.68
traceroute to 10.3.0.68 (10.3.0.68), 30 hops max, 60 byte packets
1 140.204.227.55 (140.204.227.55) 0.204 ms 140.91.194.97 (140.91.194.97) 0.166 ms 140.204.226.233 (140.204.226.233) 0.147 ms
2 192.168.1.6 (192.168.1.6) 0.978 ms 0.987 ms 0.908 ms
3 * * *
4 10.1.0.4 (10.1.0.4) 21.107 ms 20.517 ms 20.458 ms
5 10.2.0.4 (10.2.0.4) 23.471 ms 23.981 ms 23.421 ms
6 10.3.0.68 (10.3.0.68) 24.773 ms 22.957 ms 23.804 ms
root@instance-20240528-2358:~#
threeHopVnet からオンプレミスの VM に対しても、2つの NVA（10.2.0.4と10.1.0.4）を経由していることが分かります。
root@threeHopVm:~# traceroute -T 192.168.0.53
traceroute to 192.168.0.53 (192.168.0.53), 30 hops max, 60 byte packets
1 10.2.0.4 (10.2.0.4) 2.549 ms 2.518 ms 2.490 ms
2 10.1.0.4 (10.1.0.4) 5.434 ms 5.410 ms 5.385 ms
3 10.1.0.132 (10.1.0.132) 24.804 ms 10.1.0.133 (10.1.0.133) 22.868 ms 10.1.0.132 (10.1.0.132) 24.743 ms
4 * * *
5 192.168.0.53 (192.168.0.53) 24.542 ms !X 24.976 ms !X 24.942 ms !X
まとめ
Azure Route Server を利用して、通常の構成では実現できない「オンプレミスから隣の隣の隣の VNet へのアクセス」を実現しました。できはしますが構成が複雑になりますのでご利用は計画的に。
なお、今回は NVA をシングル構成で導入しましたが、もしこの構成を採用する場合には NVA を冗長化しましょう。Azure Route Server に経路を広報している NVA が止まると、threeHopVnet 向けのルーティングが消失するためです。
Note
- 当サイトは個人のブログです。このブログに示されている見解や意見は個人的なものであり、所属組織の見解や意見を表明するものではありません。
- 公開情報を踏まえて正確な情報を掲載するよう努めますが、その内容の完全性や正確性、有用性、安全性、最新性について一切保証しません。
- 添付文章やリンク先などを含む本サイトの内容は作成時点でのものであり、予告なく変更される場合があります。