仮想マシンとネットワークリソースの関係を知る：Azure ハイッ！ ここ大事！（2/3 ページ）
Azureではネットワークやストレージなどを「リソース」として管理しています。今回はAzure仮想マシンにおけるネットワークリソースの扱いについて見てみましょう。
Azure仮想マシンのネットワーク構成
ARMを利用した、Azureの仮想マシンにおけるネットワーク関連のアーキテクチャをもう少し詳しく見てみます。図にすると次のようになります。
Azureのネットワーク関連のアーキテクチャ
Azureでは仮想ネットワークやサブネット、IPアドレスなど、全てをリソースとして管理しています。仮想ネットワークには複数のサブネットが含まれ、仮想マシンはこのサブネット上に配置されます。仮想マシンにはプライベートIPアドレスが割り当てられていますが、インターネットへアクセスする場合はNATによってパブリックIPアドレスに変換されます。
ネットワークリソースには、以下の要素が含まれます
- 仮想ネットワーク（VNET）
- サブネット
- ネットワークインタフェース（NIC）
- パブリックIPアドレス
- プライベートIPアドレス
- NAT（ネットワークアドレス変換機能）
- ネットワークセキュリティグループ（NSG）
仮想ネットワーク（VNET）リソース
「仮想ネットワーク（VNET）」は、Azure上に自分が作成した複数の仮想マシンを収容するためのネットワークを表します。このネットワーク全体に対して、例えば「10.0.0.0/16」＊1というプライベートIPアドレスを割り当てます。
＊1 「xx.xx.xx.xx/16」などの表記について
IPアドレスの直後に付けた「/16」「/24」などの表記は「サブネットマスク」を表しています。数字は2進数で数えたbit数を意味しており、例えば「/16」は左端から16bitだけ1が並んでいる数値、すなわち「255.255.0.0」を表します。
・TIPS「IPアドレスとサブネットマスクをまとめて表記する」
仮想ネットワークはAzureのリージョン（東日本や西日本など）ごとに独立していて、リージョンをまたいで1つの仮想ネットワークを構築することはできません。異なるリージョンの異なる仮想ネットワーク内にある仮想マシン同士で通信させたければ、別途VPNゲートウェイなどを利用して、仮想ネットワーク間を連結する必要があります。
【ハイッ！ ここ大事！】
Azureで構築した仮想マシンは、直接インターネットに接続されているのではなく、Azure内に構築された仮想ネットワーク環境内にあります。「仮想ネットワーク」といっても、リージョンごとには独立していて、異なるリージョンをまたいだりはできません。
サブネットリソース
仮想ネットワークの中には、1つ以上の「サブネット」が収容されています。それぞれのサブネットには、例えば「10.0.0.0/24」「10.0.1.0/24」……のような、仮想ネットワークの部分集合となるIPアドレスセットを（サブネットアドレスが重複しないように）割り当てます。
1つのサブネットには、複数台の仮想マシン（のネットワークインタフェース）を収容できます。同じサブネット上の仮想マシンは、ルーターを介さずに直接通信できます。またサブネット内の仮想マシン同士はお互いに通信できるように設定されています（ネットワークセキュリティグループで、そのようなデフォルト規則が定義されている。詳細は後述）。
【ハイッ！ ここ大事！】
同一サブネットにある仮想マシン同士はルーターを介さず直接通信できます。会社で部署ごとにルーターでネットワークを分離しても、同じ部署内のコンピュータ同士は直接通信できるのと同じです。
ネットワークインタフェース（NIC）リソース
1台の仮想マシンには、1つ以上のネットワークインタフェース（NIC）を付けることができます。
各ネットワークインタフェースには、IPアドレスを1つ割り当てます。割り当ては、DHCPによる動的な割り当てと、固定的な（静的な）割り当てを選択できます。
【ハイッ！ ここ大事！】
1台の仮想マシンに、複数のネットワークインタフェースを接続して、それぞれにIPアドレスを割り当てて使えます。1つのコンピュータに複数のネットワークカードを差して使うのと同じですね。
パブリックIPアドレスリソース
パブリックIPアドレスとは、インターネット側からアクセスできるように、仮想マシンに対して（正確にはNATのインターネット側に対して）割り当てられるグローバルIPアドレスのことです。
インターネットに直接公開するサービスを提供するなら、このパブリックIPアドレスを1つ（以上）割り当てる必要があります。パブリックIPアドレスがないと、外部からリモートデスクトップ接続やSSH接続（Linuxの場合）することはできません。
しかしインターネットへ公開するつもりがない仮想マシンなら（例えばバックエンドで動作するDBなど、仮想ネットワークからアクセスさえできれば構わないようなシステムの場合）、パブリックIPアドレスを割り当てずに運用することもできます。ただしこのようなケースでも、仮想マシンからインターネットへアクセスすることは可能です（その場合は、一時的なパブリックIPアドレスが利用されます）。以下のページも参照してください。
- 「Azure の仮想マシンとIPアドレス」（マイクロソフトCloud OS Tech Blog）
なおパブリックIPアドレスリソースは（基本的には）有償です。なので、例えば静的なパブリックIPアドレスを利用すると、仮想マシンを停止（割り当て解除）している場合でも課金が発生することになります。
プライベートIPアドレスリソース
これは仮想マシンのNICに割り当てるローカルなIPアドレスのことを表します。一般的には「10.0.0.0/8」や「172.16.0.0/20」「192.168.0.0/16」の範囲内から割り当てます。インターネットへアクセスする場合は、次のNATによって、パブリックIPアドレスに変換されて通信が行われます。
NAT（ネットワークアドレス変換機能）リソース
NATとは、仮想マシンから発信されたインターネット向けのパケットに対して、ネットワークアドレスやポート番号などの変換を行って、インターネット側へ中継する機能です。仮想ネットワークやサブネット上のホストはプライベートIPアドレスを持っているため、そのままでインターネット側へ送信することはできません（プライベートIPアドレス情報をそのままインターネットへ送信してはいけません）。
NATでは、このようなパケットの送信元IPアドレスやTCP／UDPのポート番号などの情報を、Azureが割り当てたグローバルIPアドレス情報（前述したインターネット側からアクセスするための「パブリックIPアドレス」） などに置き換えて送信します。これにより、プライベートIPアドレスを持つ仮想マシンでもインターネットと問題なく通信できます。
本来のWindows ServerのHyper-VではこのようなNAT機能を持っておらず、必要ならNATを行う機能を何らかの方法で用意する必要がありました＊2。でもAzureでは自動で行ってくれます。
＊2 Hyper-VとNAT機能
Windows Server 2016（および2016年のAnniversary Update以降のWindows 10）ではNATが利用できるようになっています。詳細は次の記事を参照してください。
・TIPS「Windows 10／Windows Server 2016のHyper-VでNAT（ネットワークアドレス変換機能を利用する」
ネットワークセキュリティグループ（NSG）リソース
「ネットワークセキュリティグループ（NSG）」は、ネットワーク上を通過するパケットに対するフィルタ（パケットフィルター）です。通信パケットを許可したり、ブロックしたりするために使われます。
ネットワークセキュリティグループは、サブネットかネットワークインタフェースのいずれかに対して適用できます。デフォルトでは、ネットワークインタフェースに対して適用されるようになっています。
ネットワークセキュリティグループの設定画面
通信パケットを許可したり禁止したりするには、ネットワークセキュリティグループを利用します。
（1）仮想マシンに割り当てられているネットワークセキュリティグループのリソース。
（2）受信パケットに対する規則。2つの規則しか定義されていないように見えますが、これ以外に「既定の受信規則」もあります。
（3）送信パケットに対する規則。何も定義されていないように見えますが、これ以外に「既定の送信規則」もあります。
（4）これらの規則は、「サブネット」に対しては適用しない。
（5）「ネットワークインターフェイス」に対しては適用する。
デフォルトで設定されているセキュリティ規則は、受信規則はリモートデスクトップ以外全て拒否、送信規則は全て許可、となっています。ただし仮想ネットワーク上同士の通信は許可するなど、いくつか例外規則が用意されています（次の画面参照）。
ネットワークセキュリティグループの「既定の受信セキュリティ規則」
先の画面で［受信セキュリティ規則］をクリックすると詳細を確認できます。
（1）これをクリックすると、既定の規則を表示できます。
（2）これが後から追加した定義。上側はリモートデスクトップ用の受信セキュリティ規則（仮想マシン作成時に自動的に追加された）、下側がIIS用に前回手動で追加した規則です。
（3）この3つは、最初から定義されている既定の規則。「優先度」の数値が小さいほど優先されます（先に適用されます）。
既定の受信／送信セキュリティ規則の詳細は次のようになっています。
| ■既定の受信規則 | |||
| 送信元→宛先 | ポート | 許可／禁止 | |
| （任意）→（任意） | TCP 3389（リモートデスクトップ） | 許可 | |
| VNET→VNET | （任意） | 許可 | |
| Azureロードバランサー→（任意） | （任意） | 許可 | |
| （任意）→（任意） | （任意） | 禁止 | |
| ■既定の送信規則 | |||
| 送信元→宛先 | ポート | 許可／禁止 | |
| VNET→VNET | （任意） | 許可 | |
| （任意）→インターネット | （任意） | 許可 | |
| （任意）→（任意） | （任意） | 禁止 | |
| 既定の受信／送信セキュリティ規則の詳細 左側はパケットの送信元と送信先のIPアドレスの組み合わせ。VNET上の仮想マシン同士の通信は許可していますが、外部（任意）のIPアドレスからの通信は、基本的には禁止（ブロック）されています。管理者が明示的に許可しない限り、通信はできません。 | |||
仮想マシン上のOSの持つファイアウォール機能とNSGの関係
一般的に、仮想マシンにインストールしたOSではそれぞれ独自のファイアウォール機能を持っています。例えばWindows Server 2016なら「Windowsファイアウォール」と「セキュリティが強化されたWindowsファイアウォール」という2つのパケットフィルターを持っています。
ですが、このOS独自のファイアウォールと、Azureのネットワークセキュリティグループの設定は特に連動はしていません。インターネットに向けてサービスポートを公開したい場合は、ローカルのOS上で受信パケットフィルターを許可するのと同時に、Azureのネットワークセキュリティグループでも通信を許可する必要があります。
【ハイッ！ ここ大事！】
Azureのセキュリティグループと、各仮想マシン上のOSのセキュリティ設定は連動しません。インターネット上にサービスを公開するには、双方のセキュリティ設定を適切に設定します。
Copyright© Digital Advantage Corp. All Rights Reserved.