1.はじめに
2020/12月のアップデートで、AWSに__「VPC Reachability Analyzer」__が追加されました。
この機能は、 2 つのエンドポイント間での到達性を解析できるものですが、この機能を知っているか知らないかで、障害調査時間が大きく変わってきます。
しかしですね…Azureにはすでに同格の機能があるのです。
その名も__｢Network Watcher｣！__
はい、というわけで今回は__｢Network Watcher｣__の紹介と、調査例について紹介していきます(雑な導入)。
2.Network Watcherとは
Azure仮想network内のリソースの監視・診断・メトリックの表示・ログの有効化/無効化を行うツールを提供する機能です。
特に対象のリソースは、仮想マシン、Vnet、ApplicationGateway、Loadbalancerなど。
IaaS系統のネットワーク正常性を監視や修正するように設計されています。
一言でネットワーク障害調査に対して何が良いかというと…
「NSGの設定ミスか他の原因かが一目でわかること。」
まずはこれに尽きます。
NSGの設定ミスというのはごくごく一般的に発生するものです。
設定するIPアドレスが間違っていたり、古い設定値を入れていたり、設定自体がなかったり。
そんなとき、原因調査をアプリケーション側から行っていくと、調査にすごく時間がかかってしまいます。
結局NSGの設定ミスであることがわかり、設定をし直してもらうと10分で解決したり。
3日間ぐらいかけてあちこち確認した結果が10分で解決できると…なんというか…疲れますよね。
そんなことにならないように、Network Watcherを活用しましょう！
なお、Network Watcherを利用するためには、NetworkWatcher用のリソースグループが必要です。
主な機能
Network Watcherの主な機能を簡単に記載します。
| 分類 | 機能名 | 機能説明 |
|---|---|---|
| 監視 | 接続モニター | 仮想マシンとIPアドレス間のネットワーク接続を監視する。 |
| トポロジ | 仮想ネットワーク、サブネット、ネットワークインタフェース、仮想マシンなどのエンドツーエンドのネットワーク接続をグラフィカルに表示する。 | |
| 診断 | IPフローの確認 | 送信元および宛先 IPv4 アドレス、ポート、プロトコル (TCP または UDP)、トラフィックの方向 (受信または送信) を指定し接続テストを行う。 |
| 次ポップ | ソースの仮想マシンのIPアドレスと宛先のIPアドレスを指定して、次ホップの種類、IPアドレス、使用したルートテーブルのIDを表示する。 | |
| 有効なセキュリティルール | 仮想マシンに関連付けられたNSGとNSGのルールを表示する。 | |
| VPNのトラブルシューティング | VPNゲートウェイと接続に関する最も一般的な問題を診断できる。 | |
| パケットキャプチャ | 詳細なフィルターオプションにより、VMに接続しなくとも多様なパケットキャプチャを行える。 | |
| 接続のトラブルシューティング | ある VM と別の VMまたはApplicationGatewayの、FQDN、URI、または IPv4 アドレスとの間の接続をテストできる。 | |
| メトリック | 使用料 + クォータ | サブスクリプションおよびリージョンでデプロイした各ネットワーク リソースの数の概要のほか、リソースに関する制限が確認できる。 |
| ログ | NSGフローログ | ネットワークセキュリティグループ（NSG）を介して送受信されるIPトラフィックの情報をストレージアカウントに格納する。 |
| 診断ログ | Azure ネットワーク リソースの診断ログを有効にできる。 |
このように様々な機能があるのですが、今回調査に利用するのは、「IPフローの確認」と「接続のトラブルシューティング」です。
3.障害調査例
では実際のサンプル環境を見ていきましょう。
このように、2つのVNetに別々の仮想マシンが動作しています。(ちなみにこの図はトポロジ機能で出力しました。)
 |
|---|
test-iis(IPアドレス:192.16.0.4)は、プライベートIPを利用してtest-iis2(IPアドレス:192.17.0.5)へ送信します。
利用するポートは送信側・受信側ともに8080です。
しかしながら、うまく通信ができません。
VNetはピアリングしており、ローカルでの通信はできるはずです。
これは何故でしょうか？
IPフローの確認をする
早速Network WatcherにてIPフローの確認をしていきます。
test-iis ⇒ test-iis2の、受信規則を調べます。
 |
|---|
| このように入力し、「チェック」を選択してみると… |
 |
|---|
はい、『アクセスが拒否されました』と表示されます。
この結果から、test-iis2のNSG受信規則に問題があることがわかります。
NSGを正しく設定しなおしてみると、この通り。
 |
|---|
しかし、アプリケーションは正しく動作していません。さらにどこが問題なのか、調査しなくてはなりません。
IPフローの確認ではここまでしかわからないので、次に__「接続のトラブルシューティング」__を行ってみます。
接続のトラブルシューティングをする
ではさっそく接続のトラブルシューティングを行ってみます。
 |
|---|
このように入力し、「チェック」を選択してみます。
 |
|---|
結果は、状態には__到達不可能__となっていますが、グリッドビューでは両方に緑☑がついていますね。
これはどういうことなんだろう？と混乱するところですが、
要するに__「Azure上の設定では問題なかったけど、要求を送信しても応答がなかったよ」__
という状態です。
そのため、この場合だと仮想マシン上のアプリケーションで利用するポートが間違っている、アプリケーションが正しく動作していないなどが考えられます。
接続のトラブルシューティングでは、IPフローの確認よりも詳細に確認できますが、NSGに問題があった場合でも結果に反映されてしまいます。
そのため、まずIPフローの確認でNSGに問題がないかを確認し、その後接続のトラブルシューティングを試すことをお勧めします。
4.まとめ
- Network Watcherを利用すると、調査時間を大幅に短縮することができます。
- IPフローの確認でアクセスが拒否される場合は、NSGに問題があるので、NSG設定を見直します。
- さらに調査する場合は、接続のトラブルシューティングを利用します。
5.おわりに
障害対応で調査していくと、意外としょうもないこういったNSGとかでミスが見つかるものです。
何かのお役に立てれば幸いです。
もうちょっと複雑な障害事例を入れようとしたら再現するのが面倒だったのでやめました
参考
Azure Network Watcher とは
https://docs.microsoft.com/ja-jp/azure/network-watcher/network-watcher-monitoring-overview