Azure Firewall, Application Gateway のルーティングを確認する方法

オンプレから Azure へ ExpressRoute/VPN で接続し、Azure Firewall 等を経由させる構成にすると Azure Firewall や Application Gateway 等にもオンプレと接続するためのルーティングが反映されます。Hub&Spoke の構成でよくある構成となりますが、ルーティングが適切に構成されていないため、想定通りに接続できないといったトラブルはよくあります。
Azure VM であればネットワーク インタフェースの有効なルートから[反映されているルートテーブルを確認する](https://docs.microsoft.com/ja-jp/azure/virtual-network/diagnose-network-routing-problem#diagnose-using-azure-portal)ことができます。一方、Azure Firewall, Application Gateway 等の Azure Managed サービスは、ポータル上で有効なルートを確認する機能が用意されていません。
サポートリクエストを上げれば確認してもらえますが、自分で確認できた方が効率的です。今回は Azure Network Watcher の接続のトラブルシューティングの機能を用いて Azure Firewall, Application Gateway のルーティングの構成 (NextHop の確認) 、疎通確認を行う方法をご紹介します。

https://docs.microsoft.com/ja-jp/azure/network-watcher/network-watcher-connectivity-overview

## 構成図
以下のような構成で疑似オンプレ環境と接続し、強制トンネリングによりクライアントからのデフォルトルートの通信がすべて Azure Firewall とオンプレ側の NVA を経由するような構成とします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/c67bfda0-6d91-9e90-2b58-2487538ebf86.png)

Route Server や NVA の構築は以下を参照ください。Azure Firewall も強制トンネリングモードで作成します。
https://qiita.com/Isato-Hiyama/items/6d1c2cba146b2c8ec1b6


https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-p2s-advertise-custom-routes#forced-tunneling

## Azure Firewall に適用されてるルーティングを確認

Azure Firewall には接続のトラブルシューティングを実行する機能がありませんので、Azure Firewall を経由しているクライアントで接続のトラブルシューティングを実行します。
接続のトラブルシューティングの結果から Azure Firewall のルーティングを確認することができます。

ポータル上でクライアントの VM を選択し、"接続のトラブルシューティング > 詳細なトレースを行うために Network Watcher を使用する" をクリックします。
詳細なトレースを選ばない場合、対象の仮想マシンに適用された NSG のみを評価するため、実際の通信可否やルーティングは確認することができません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/47a3c927-baf5-bc5f-bff8-113aa287874a.png)

宛先の画面にて、"手動で指定" を選択して、"URI、FQDN、IP アドレスのいずれか" に経路を確認したい宛先を入力します。実際にクライアントの VM から TCP 3way Handshake が行われますが、ルーティングの確認の場合、この宛先は通信できない IP でも問題ありません。
プロトコル TCP を選択し、宛先ポートを入力後、チェックをクリックします。
※ 実行すると自動的に NetworkWatcher の拡張機能が VM に追加されます。ネットワーク診断ツールとして少量の課金も発生します。
https://azure.microsoft.com/ja-jp/pricing/details/network-watcher/

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/bca95bcd-7962-8cd2-e1dc-68474283796d.png)

無効な宛先だったため、結果としては "到達不可能" になっていますが、クライアントから通信の NextHop が Azure Firewall となり、Azure Firewall からの通信の NextHop が VPN Gateway のパブリック IP アドレスとなっていることがわかります。
このことから、Azure Firewall のルーティングとして、パブリック IP アドレス宛ての通信の NextHop が仮想ネットワークゲートウェイとなっていることがわかります。
※VPN Gateway 以降の通信の経路は表示されません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/17f66deb-53bc-76db-e502-62a69805f3a8.png)

Azure Firewall の NextHop がインターネットとなっている場合、以下の様に VPN Gateway リソースは出てきません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/477b5c2a-aae7-952b-710e-c8aa3d35a217.png)

Azure Firewall も経由していない場合、以下のような表示になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/5176e3f3-cb34-9161-d295-c2efc6ccc2da.png)

## Azure Application Gateway に適用されてるルーティングを確認

VM と同様ポータル上で Application Gateway を選択し、"接続のトラブルシューティング" をクリックします。
宛先の画面にて、"手動で指定" を選択して、"URI、FQDN、IP アドレスのいずれか" に経路を確認したい宛先を入力します。実際に Application Gateway から TCP 3way Handshake が行われますが、ルーティングの確認の場合、この宛先は通信できない IP でも問題ありません。
プロトコル TCP を選択し、宛先ポートを入力後、チェックをクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/171d05db-4425-0804-392b-d11529ac8f5d.png)

以下の様に Application Gateway からの通信の NextHop が VPN Gateway となっていることを確認できます。
この結果は強制トンネリングとなっているためです。Application Gateway の場合、サポートされた構成ではありませんので UDR を適用して回避する必要があります。https://docs.microsoft.com/ja-jp/azure/application-gateway/configuration-infrastructure#supported-user-defined-routes

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/7804c4d1-34c2-87bd-7869-133cbfff5aba.png)

ゲートウェイのルート伝達を無効化する UDR を適用し、再度実行してみます。
以下の様に NextHop に VPN Gateway が表示されておらず、NextHop が Internet となっていることを確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/22541353-ec3e-a55a-96bf-96c17a63fadb.png)

ちなみにこの接続のトラブルシューティングは　Application Gateway のインスタンスから名前解決と TCP 3way handshake を行いますので、バックエンドのホスト名が DNS にて名前解決ができてるかどうか、ホスト名で TCP の通信が可能かといった切り分けにも役立ちます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/69794cc0-3843-baaf-fe9c-1c41ea002b57.png)

## 接続のトラブルシューティングに対応してるサービス

Network Watcher の画面から確認しましたが、現状、接続のトラブルシューティングを実行できるのは仮想マシン、Application Gateway、Bastion のみのようです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/09c53799-6a91-9c72-d7ee-f0031157f53f.png)

各レスポンスの詳細は以下にありますので、Azure VM, Application Gateway, Azure Bastion でのネットワーク接続で困ったときは一度利用してみるとよいでしょう。
https://docs.microsoft.com/ja-jp/azure/network-watcher/network-watcher-connectivity-overview

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/4578b1a5-92b1-3ab0-d2cc-90127c9750c2.png)

## Network Watcher の仕組みの考察

該当の VM の NSG にて ICMP, TCP, UDP の送信接続を宛先 Any で拒否した状態で、実行した場合でも以下の様に NextHop が正しく表示されましたので、VM 内部で tracerouote (ICMP) 等を実行した結果から判定しているわけではないようです。どのように NextHop を判定しているのかは公開された情報がありませんでしたが、動作をふまえると Azure 基盤側の仕組みでクライアントの VM, NextHop のサービス毎に情報を取得して表示していると考えられます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/d46fbd51-612e-c385-814d-b1c5c98cd843.png)