Partager via

Azure 仮想マシンで送受信するネットワークパケットをキャプチャする

  • Article

はじめに

Microsoft Azure の IaaS（というか 仮想マシン）を使用したシステムを構築する際に、最も頭を悩ませるのがネットワーク周りの設計です（個人の主観です）。ところが先日 Azure Network Watcher の Public Preview が開始されました。こちらを利用することでネットワークパケットキャプチャを取得し、仮想マシンが実際にどんな通信を行っているのか具体的に把握することが出来るようになります。というわけで本記事ではその利用イメージを紹介していきたいと思います。

取得編

パケットキャプチャを取得するために必要な作業は大まかに以下の4つですが、より詳細な手順に関してはこちらのドキュメントをご参照ください。なお 本記事の 執筆時点では Network Watcher が利用できるリージョンが限られているため、お試しいただく際には仮想マシンや仮想ネットワークを当該リージョンに指定する必要がありますのでご注意ください。

  1. Microsoft.Network リソースプロバイダーの Azure Network Watcher 機能を有効化する
  2. Azure Network Watcher を利用するサブスクリプションおよびリージョンを選択する
  3. キャプチャを取得したい仮想マシンに拡張機能「Network Watcher Agent for Windows/Linux」をインストールする
  4. Network Watcher に上記の仮想マシンをターゲットとするパケットキャプチャを追加する

追加したパケットキャプチャが「実行中」となっている間、当該仮想マシンで発生した送受信のログが拡張機能によって取得され、上記の手順４で指定した仮想マシンのローカルファイルとして、あるいはストレージアカウント上のBlobとして保存されます。

capture

解析編

確認したい通信が完了した頃合いを見計らってキャプチャを停止し、ストレージアカウント等に保存されたファイルを解析用の端末のダウンロードします。このファイルは拡張子 .cap のファイルになっており、Microsoft Message Analyzer や Wireshark 等で内容を確認することができます。下記は Microsoft Message Analyzerで実際にキャプチャファイルを読み込んだ画面です。

mma

中段左側に仮想マシン(10.0.0.4)と通信した相手先毎にグループ化されていますので、それらをドリルダウンしていくことで通信内容を確認することが出来ます。このあたりの解析作業などはオンプレミス環境で実際にネットワークに携わっていた方ならお手の物かと思います。

ちなみに上記は仮想マシンを作成しただけでほぼほったらかしの状態で取得したキャプチャなのですが、それでもいろいろと通信が行われていることがわかります。気持ち悪いですね。このうちのいくつかは Azure 仮想マシンを利用するうえで知っておかないと混乱の元になるものですので、いくつかご紹介したいと思います。

操作端末との通信

前述の図でフォーカスされている一番上のグループになるのですが、これは仮想マシンに SSH でログオンしている私の端末です。仮想マシンから見て通信相手の IP アドレスは私のオフィスからインターネットに出ていく際に通過するどこかのルーターアドレスになっていると思われます。当然この IP アドレスは環境次第で異なってくるわけですので、念のため自分の IP アドレスと突き合わせて確認します。方法はいろいろあると思いますが、私はこちらのサイトなどをよく利用します。

インフラストラクチャとの通信（168.63.129.16）

パケットキャプチャを見るとこちらのアドレスを用いて仮想マシンとインバウンド／アウトバウンド共に通信を行っているのがわかります。気持ち悪いですね。しかしこちらは仮想マシンが動作する上で絶対に必要な、Azure のインフラストラクチャとの通信になります。詳細は下記の Blog 等をご参照ください。

この IP アドレスは全リージョンで共通のものですので、どこに配置した仮想マシンでも同じような通信が発見されるはずです。このアドレスと通信をしていても問題はないですし、このアドレスとの通信は絶対に阻害しないようにお願いします。

メタデータサービスとの通信（169.254.169.254）

このアドレスはそのレンジからわかるように APIPA ( Automatic Private IP Addressing）によって割り当てられる IP アドレスのはずです。Azure の仮想マシンは 配置された仮想ネットワークから DHCP によってアドレスを割り当てられるはずなのに・・・、気持ち悪いですね。しかしこれはメタデータサービスとの通信のようです。これを利用することで仮想マシンは自分自身に関する情報を取得することができるんですね。

というわけでこのアドレスも問題なさそうです。実際にキャプチャを見ても全て仮想マシンから見たアウトバウンド通信で、そもそもこのアドレスはルーティングできないわけですから。

ストレージアカウントとの通信（blob.*.store.core.windows.net）

一部の相手先がいかにも Blob っぽい、しかしドキュメント等で記載されているアドレスフォーマット（accountname.blob.core.windows.net）と微妙に異なるものが表示されています。気持ち悪いですねえ。Azure 仮想マシンのディスクは Blob に保存されている VHD ファイルなのですが、これは仮想マシン内部からの通信ではないので、そのディスク I/O は仮想ネットワークを利用しません。しかしディスク以外の用途にも実はストレージアカウントが使用されています。

  • 仮想マシン内で動作するエージェントが仮想マシンの状態を記録
    • ディスク（.vhd）と一緒のストレージアカウントに 、JSON 形式のステータス（.status）ファイルが定期的に保存される
  • 各種の拡張機能が出力する情報
    • 仮想マシンの診断機能の構成時に指定したストレージアカウントに、イベントログ、IISログ、 パフォーマンスログ等の指定したログ情報が保存される
    • それ以外の拡張機能もストレージアカウントにデータを出力するケースが多い（今回のテーマである Network Watcher もその１つ）

ここで仮想マシンや拡張機能の構成時に指定したストレージアカウントの FQDN 名を nslookup で調べてみると、以下のような結果が返ってきます。ストレージアカウント作成時に指定した方の名前（accountname.blob.core.windows.net）はあくまでも CNAME レコードで指定されたエイリアスであり、ネットワークキャプチャで取得した名前が A レコードとして登録された実際の名前（blob.???????.store.core.windows.net）であることがわかります。

storage

仮想マシンや拡張機能の構成時に指定したストレージアカウント（意図した名前を持つ）の A レコードが、キャプチャで出てきた Blob っぽい奇妙な名前と一致するのが確認できれば、問題ないと言えるでしょう。