オンプレから Azure へ ExpressRoute/VPN で接続し、Azure Firewall 等を経由させる構成にすると Azure Firewall や Application Gateway 等にもオンプレと接続するためのルーティングが反映されます。Hub&Spoke の構成でよくある構成となりますが、ルーティングが適切に構成されていないため、想定通りに接続できないといったトラブルはよくあります。
Azure VM であればネットワーク インタフェースの有効なルートから反映されているルートテーブルを確認することができます。一方、Azure Firewall, Application Gateway 等の Azure Managed サービスは、ポータル上で有効なルートを確認する機能が用意されていません。
サポートリクエストを上げれば確認してもらえますが、自分で確認できた方が効率的です。今回は Azure Network Watcher の接続のトラブルシューティングの機能を用いて Azure Firewall, Application Gateway のルーティングの構成 (NextHop の確認) 、疎通確認を行う方法をご紹介します。
構成図
以下のような構成で疑似オンプレ環境と接続し、強制トンネリングによりクライアントからのデフォルトルートの通信がすべて Azure Firewall とオンプレ側の NVA を経由するような構成とします。
Route Server や NVA の構築は以下を参照ください。Azure Firewall も強制トンネリングモードで作成します。
https://qiita.com/Isato-Hiyama/items/6d1c2cba146b2c8ec1b6
Azure Firewall に適用されてるルーティングを確認
Azure Firewall には接続のトラブルシューティングを実行する機能がありませんので、Azure Firewall を経由しているクライアントで接続のトラブルシューティングを実行します。
接続のトラブルシューティングの結果から Azure Firewall のルーティングを確認することができます。
ポータル上でクライアントの VM を選択し、"接続のトラブルシューティング > 詳細なトレースを行うために Network Watcher を使用する" をクリックします。
詳細なトレースを選ばない場合、対象の仮想マシンに適用された NSG のみを評価するため、実際の通信可否やルーティングは確認することができません。
宛先の画面にて、"手動で指定" を選択して、"URI、FQDN、IP アドレスのいずれか" に経路を確認したい宛先を入力します。実際にクライアントの VM から TCP 3way Handshake が行われますが、ルーティングの確認の場合、この宛先は通信できない IP でも問題ありません。
プロトコル TCP を選択し、宛先ポートを入力後、チェックをクリックします。
※ 実行すると自動的に NetworkWatcher の拡張機能が VM に追加されます。ネットワーク診断ツールとして少量の課金も発生します。
https://azure.microsoft.com/ja-jp/pricing/details/network-watcher/
無効な宛先だったため、結果としては "到達不可能" になっていますが、クライアントから通信の NextHop が Azure Firewall となり、Azure Firewall からの通信の NextHop が VPN Gateway のパブリック IP アドレスとなっていることがわかります。
このことから、Azure Firewall のルーティングとして、パブリック IP アドレス宛ての通信の NextHop が仮想ネットワークゲートウェイとなっていることがわかります。
※VPN Gateway 以降の通信の経路は表示されません。
Azure Firewall の NextHop がインターネットとなっている場合、以下の様に VPN Gateway リソースは出てきません。
Azure Firewall も経由していない場合、以下のような表示になります。
Azure Application Gateway に適用されてるルーティングを確認
VM と同様ポータル上で Application Gateway を選択し、"接続のトラブルシューティング" をクリックします。
宛先の画面にて、"手動で指定" を選択して、"URI、FQDN、IP アドレスのいずれか" に経路を確認したい宛先を入力します。実際に Application Gateway から TCP 3way Handshake が行われますが、ルーティングの確認の場合、この宛先は通信できない IP でも問題ありません。
プロトコル TCP を選択し、宛先ポートを入力後、チェックをクリックします。
以下の様に Application Gateway からの通信の NextHop が VPN Gateway となっていることを確認できます。
この結果は強制トンネリングとなっているためです。Application Gateway の場合、サポートされた構成ではありませんので UDR を適用して回避する必要があります。https://docs.microsoft.com/ja-jp/azure/application-gateway/configuration-infrastructure#supported-user-defined-routes
ゲートウェイのルート伝達を無効化する UDR を適用し、再度実行してみます。
以下の様に NextHop に VPN Gateway が表示されておらず、NextHop が Internet となっていることを確認できます。
ちなみにこの接続のトラブルシューティングは Application Gateway のインスタンスから名前解決と TCP 3way handshake を行いますので、バックエンドのホスト名が DNS にて名前解決ができてるかどうか、ホスト名で TCP の通信が可能かといった切り分けにも役立ちます。
接続のトラブルシューティングに対応してるサービス
Network Watcher の画面から確認しましたが、現状、接続のトラブルシューティングを実行できるのは仮想マシン、Application Gateway、Bastion のみのようです。
各レスポンスの詳細は以下にありますので、Azure VM, Application Gateway, Azure Bastion でのネットワーク接続で困ったときは一度利用してみるとよいでしょう。
https://docs.microsoft.com/ja-jp/azure/network-watcher/network-watcher-connectivity-overview
Network Watcher の仕組みの考察
該当の VM の NSG にて ICMP, TCP, UDP の送信接続を宛先 Any で拒否した状態で、実行した場合でも以下の様に NextHop が正しく表示されましたので、VM 内部で tracerouote (ICMP) 等を実行した結果から判定しているわけではないようです。どのように NextHop を判定しているのかは公開された情報がありませんでしたが、動作をふまえると Azure 基盤側の仕組みでクライアントの VM, NextHop のサービス毎に情報を取得して表示していると考えられます。
