セキュリティ保護付きAzure Virtual Hubの挙動確認①

# 概要
## 本記事について
最近Azure Virtual WANに色んな意味でハマっています。
セキュリティ保護付きかつNVAをデプロイしたVirtual Hub内の通信のルーティングに苦労しておりまして、情報整理するために挙動確認していて気になっている点を記録しておきます。

ただし、NVA入りの環境を自身の検証環境に再現できないため、セキュリティ保護付きVirtual Hubの挙動のみ記録しています。
目的の検証ができておらず、結局どういうこと？という内容になっています。追加の検証ができて気になる点が明らかになった際には追記しようと思います。

## Virtual Hub
Virtual Hub (vHub)はVirtual WANにデプロイされるマネージドのハブVNetです。
このvHubにはポイント対サイト、サイト間VPN用のゲートウェイやExpress Routeゲートウェイ、各種NVA (Network Virtual Appliance)をデプロイできます。
これらは通常のゲートウェイと異なりマネージドなサービスとして管理されます。

## セキュリティ保護付きVirtual Hub
vHub内にはAzure Firewall (Azure FW)をデプロイすることができ、このAzure FWをデプロイしたvHubをセキュリティ保護付きvHubと呼びます。
vHub内のAzure FWはFirewall Managerから管理します。

# 検証
## 検証目的
vHub内の通信の挙動やAzureポータルにおける有効なルートを確認し、vHub内のルーティングについて明らかにしたい。

## 検証構成
1. **通常のvHub**
![network01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/3e2e7b89-702a-dcf0-be5f-1c49530c4c15.png)

- vHubには2つのスポークVNetをピアリングし、それぞれにVMを1台ずつ用意
- アドレス情報
   |#|項目|アドレス(空間)|備考|
   |:--|:--|:--|:--|
   |1|vHub|10.1.0.0/24||
   ||vHub内のルータ|10.1.0.68, 10.1.0.69|自動作成|
   |2|スポークVNet #1|10.10.0.0/24|サブネットはVNetと同サイズ|
   ||VM #1|10.10.0.4||
   |3|スポークVNet #2|10.20.0.0/24|サブネットはVNetと同サイズ|
   ||VM #2|10.20.0.4||

2. **セキュリティ保護付きvHub**
![network02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/330f76de-db6d-96a1-8456-8930f737c704.png)

- vHubには2つのスポークVNetをピアリングし、それぞれにVMを1台ずつ用意
- ルーティングインテントを有効化し、プライベートトラフィック (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)をAzure FWにルーティング、インターネットトラフィックはAzure FWにルーティングしない
- Azure FWのファイアウォールポリシーではvHub、スポークVNetのアドレス空間の間でのICMPをネットワークルールで許可
- アドレス情報
   |#|項目|アドレス(空間)|備考|
   |:--|:--|:--|:--|
   |1|vHub|10.2.0.0/24||
   ||vHub内のルータ|10.2.0.68, 10.2.0.69|自動作成|
   ||vHub内のAzure FW|10.2.0.132||
   |2|スポークVNet #1|10.10.0.0/24|サブネットはVNetと同サイズ|
   ||VM #1|10.10.0.4||
   |3|スポークVNet #2|10.20.0.0/24|サブネットはVNetと同サイズ|
   ||VM #2|10.20.0.4||


## 検証結果
1. **通常のvHub**
- vHubの有効なルート
DefaultルートテーブルにピアリングしているスポークVNetが見えています。
![01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/a0729ed6-d818-a423-3006-f9ef557356ed.png)


- スポークVNetにおける有効なルート
スポークVNetのVMで有効なルートを確認すると、別のピアリングしたVNet宛てのネクストホップが **謎のグローバルIPアドレス(20.210.xx.xx)** になっています。
![02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/f895d42c-ab74-d728-75d6-8cc34b9fa71f.png)


- ピアリングしたVNet間のルーティング
tracerouteの結果から **vHub内のルータ(10.1.0.68)** が通信を中継していることがわかります。
![03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/2b166107-f2ec-d5d0-9e56-2c62758ebbe6.png)


2. **セキュリティ保護付きvHub**
- vHubの有効なルート
プライベートIPアドレスに対する通信がすべてAzure FW向いていることがわかります。
![04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/a4be93e7-3f4e-a500-6376-31c40a5cacc8.png)
また、Azure FWではピアリングしているスポークVNetとデフォルトルートが見えています。
![05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/2ea28079-e440-4abc-ef23-da43e30d3fee.png)


- スポークVNetにおける有効なルート
スポークVNetのVMで有効なルートを確認すると、プライベートIPアドレス宛てのネクストホップが **Azure FWのプライベートIPアドレス(10.2.0.132)** になっています。
![06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/7686f4d7-b911-9d76-fc93-fb919a21481e.png)


- ピアリングしたVNet間のルーティング
tracerouteの結果からvHub内のルータ(10.2.0.68, 69)ではなく、 **vHub内の謎のIPアドレス(10.2.0.165)** が通信を中継していることがわかります。
![07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/20e3a297-7e32-9b92-0651-8ff206f9e497.png)
また、追加のVMを構築して同様にtracerouteを実行すると別のIPアドレス(10.2.0.167)が通信を中継しています(※3台目で試すと.165でした)。
![08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/8da052a8-3b79-e5ba-1a17-0814292166b8.png)


- vHub内のICMP応答のあるIPアドレス
ピアリングしたVNetからAzure FW (10.2.0.132)にtracerouteを実行していると、時々(10.2.0.133)というIPアドレスが紛れ込むことがありましたので、vHub内のIPアドレスについてICMPの応答があるIPアドレスを洗い出してみました。
![09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/8d057542-8b9f-88dd-9b79-bef87a8ef0e6.png)
vHubのルータはICMP応答なし、Azure FWは応答ありということがわかりますが、加えて上記懸賞の中で通信を中継していた.165や.167、その他にもいくつかのIPアドレスから応答が確認できました。
なお、Azure FWの存在しない通常のvHubではすべて応答が無く、.70のIPアドレスのみ同様の挙動が見られました。
   |#|宛先IPアドレス|結果|
   |:--|:--|:--|
   |1|10.2.0.**68**|応答なし|
   |2|10.2.0.**69**|応答なし|
   |3|10.2.0.**70**|10.2.0.68⇒10.2.0.69とルーティングされ、その先に進まない|
   |4|10.2.0.**132**|応答あり|
   |5|10.2.0.**133**|応答あり|
   |6|10.2.0.**135**|応答あり|
   |7|10.2.0.**165**|応答あり|
   |8|10.2.0.**167**|応答あり|
※記載がないIPは応答なし

## 検証結果の不明点抜粋
検証で見られた不明なIPアドレス情報をまとめると以下の通りです。
vHub内のルーティングは原則マネージドでおこなわれるため、基本的には考慮する必要のないIPアドレスではあるのですが、NVAデプロイのシナリオでは内部のルーティングについて気にしなければならない部分も出てきます。
今回は検証の都合上、NVAは除いたシンプルな構成でvHub内の様子をまとめました。これらの不明点について明らかにできた際にはまた追記しようと思います。
### 通常のvHub
- スポークVNetから見た有効なルートで別のスポークVNet宛てのネクストホップに現れるグローバルIPアドレス

### セキュリティ保護付きvHub
- スポークVNet間の通信を中継するvHub内のIPアドレス(.165と.167)
- スポークVNetからAzure FWにtracerouteを実行した際に時々紛れ込む.133というIPアドレス