Azureポータル上から特定の宛先に疎通確認してみた

Azure NetworkWatcher

Network Watcherの「接続のトラブルシューティング」という機能を利用することでAzure上にある仮想マシンのOS内に入らずにAzureポータル上から特定の宛先に対して疎通確認することが可能となります。

記事の後半部分では「疎通不可の宛先に通信した場合にどのような出力結果となるのか？」といった、少し疑問に思った接続のトラブルシューティングの挙動についても試してみたので参考としてみていただけると幸いです。

広告

１．接続のトラブルシューティングで疎通確認してみる

必要なRBAC権限

接続のトラブルシューティングで疎通確認を実施するためには、Azure上で以下のRBAC権限が必要です。

RABC権限必要となる理由
Microsoft.Network/networkWatchers/readNetwork Watcher を取得するため
Microsoft.Network/networkWatchers/writeNetwork Watcher を作成するため
Microsoft.Network/networkWatchers/deleteNetwork Watcher を削除するため
Microsoft.Network/networkWatchers/connectivityCheck/action接続のトラブルシューティング テストを開始するため
Microsoft.Network/networkWatchers/queryTroubleshootResult/action接続のトラブルシューティング テストのクエリ結果を実行するため
Microsoft.Network/networkWatchers/troubleshoot/action接続のトラブルシューティング テストを実行するため
Microsoft.Compute/virtualMachines/extensions/Read
Microsoft.Compute/virtualMachines/extensions/Write		Network Watcher 拡張機能が存在するかどうかの確認と必要に応じたインストールに使用するため

一つ一つ付与するのは少し手間なので、今回は上記権限を包含する「ネットワーク共同作成者」と「仮想マシン共同作成者」の権限を付与して実施しました。

疎通確認を実施

・Azureポータルから[Network Watcher]を開き、[接続のトラブルシューティング]をクリックし、以下の画面を開きます。

[接続のトラブルシューティング]のページ

・送信元となる仮想マシンを選択し、[宛先]：[手動で指定]を選択してIPを入力して画面下部の「チェック」をクリックします。
　今回は同一Vnet内の宛先に対してFQDNではなくIPアドレスを指定し、ICMPで疎通確認を実施します。

ICMPを選択した画面

実行結果

「チェック」の下の欄に実行結果が記載されます。

通信可能かどうかや到達までにHOPしたインターフェースまで確認することができます。

ICMPの実行結果

トポロジビューも参考として載せておきます。

実行結果のトポロジビュー

インターネット向きに疎通確認（23.102.135.246）

次にインターネットの宛先に対してIPアドレスを指定し、TCPで疎通確認を実施します。
今回は広く知られているKMSサーバの宛先にKMSのポート(1688)で確認を実施してみます。

[プロトコル]：[TCP]を選択しポートに1688を入力して「チェック」をクリックします。

[TCP]を選択しポートに1688を入力した画面

実行結果

先ほどと同じような情報が出力されます。

今回はNSGで制限をかけたりOS内で制限をかけているわけではないので疎通が取れています。
また、先ほどの宛先のアイコンと異なりアイコンがインターネット用のものに変わっています。

TCP1688の実行結果

接続のトラブルシューティングを利用するにあたっての注意点

送信元仮想マシンにNetwork Watcherエージェントがインストールされる

この機能を利用するためには、送信元となる仮想マシンに拡張機能として「Network Watcherエージェント」がインストールされます。

拡張機能インストールができない場合には、この機能は利用することができません。

尚、送信元となる仮想マシンで初めてNetwork Watcherを利用し「チェック」をクリックして疎通確認を実行しようとすると、以下のポップアップが出現し勝手にエージェントインストールが始まります。

エージェントインストール通知の画面

仮想マシン側では以下のように拡張機能がインストールされた状態となります。

仮想マシンの拡張機能としてエージェントがインストールされている画面

２．疎通不可の宛先に通信した場合の挙動を試してみた

Network Watcher の [接続のトラブルシューティング] で疎通不可の宛先に通信した場合にどのような出力結果となるのか？など、少し疑問に思った挙動についても試してみました。

試した内容

今回は絶対に疎通が取れない通信となる以下の3つの場合において試してみます。

①存在しない宛先を指定した場合

同一サブネット上の利用していないIPを指定して、ICMPを利用して疎通確認を実施してみます。

結果

[状態]：[到達不可能]となり、オレンジ色のマークが表示されました。

疎通不可能の場合にはこのような画面表示となるみたいです。

①存在しない宛先を指定した場合の実行結果

②NSGで制限をかけた場合

送信元となる仮想マシンのNICに適用されるNSGで、以下のように「All-Deny」ルールを追加して送信ができないようにします。

②NSGで制限をかけた場合におけるNSGの設定画面

その上で、KMSサーバ(23.102.135.246)に対して1688ポートで疎通確認を実施してみます。

結果

なんと、[状態]：[到達可能]となり、緑色のマークが表示されました。

念のため該当の仮想マシンにアクセスして外部への通信が可能かを確認しましたが、外部への疎通はできない状態でした。

すごく驚きましたが、なんでだろうか？という疑問も出てくる結果となりました。

②NSGで制限をかけた場合の実行結果

③RouteTableで宛先を消した場合

最後にRouteTableで宛先が「null」となるような状態にした場合にどうなるのかを試してみます。

送信元となる仮想マシンのサブネットに適用されるRouteTableで、デフォルトルートが「null」となるように設定を入れ、仮想マシンでは経路が以下のように認識されるように設定します。

③RouteTableで宛先を消した場合におけるルートテーブルの設定画面

その上で、KMSサーバ(23.102.135.246)に対して1688ポートで疎通確認を実施してみます。

結果

[状態]：[到達不可能]となり、オレンジ色のマークが表示されました。

ですが、「グリッドビュー」では、宛先の状態が緑色を示しています。

③RouteTableで宛先を消した場合の実行結果

まとめ

主に後半部分についての話にはなりますが、
基本的に疎通できない場合には、[状態]：[到達不可能]となりオレンジ色のマークが表示されるようです。

「②NSGで制限をかけた場合」の結果「NSGの送信制御をかけても通信が成り立つ」ことについては疑問が残りますが、あくまで試した結果なのでAzureの仕様として理解するしかないのかもしれません。

なので、今の状態ではNetwork Watcher の [接続のトラブルシューティング] は NSG の機能を検証するなどの確認には使えなさそうですが、
疎通確認としての機能は申し分ないのでこれからも疎通確認の際には使っていこうかなと思いました。

タイトルとURLをコピーしました