クイック スタート:仮想マシン ネットワーク トラフィック フィルターの問題を診断する - Azure CLI

このクイック スタートでは、仮想マシン (VM) を展開してから、IP アドレスと URL への通信および IP アドレスからの通信をチェックします。 通信障害の原因と解決方法を特定します。

Azure サブスクリプションをお持ちでない場合は、開始する前に Azure 無料アカウントを作成してください。

前提条件

  • Azure Cloud Shell で Bash 環境を使用します。 詳細については、Azure Cloud Shell の Bash のクイックスタートに関するページを参照してください。

    Launch Cloud Shell in a new window

  • CLI リファレンス コマンドをローカルで実行する場合、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。 詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。

    • ローカル インストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。 認証プロセスを完了するには、ターミナルに表示される手順に従います。 その他のサインイン オプションについては、Azure CLI でのサインインに関するページを参照してください。

    • 初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。 拡張機能の詳細については、Azure CLI で拡張機能を使用する方法に関するページを参照してください。

    • az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。 最新バージョンにアップグレードするには、az upgrade を実行します。

  • このクイックスタートには、Azure CLI のバージョン 2.0 以降が必要です。 Azure Cloud Shell を使用している場合は、最新バージョンが既にインストールされています。

  • このクイックスタートの Azure CLI コマンドは、Bash シェルで実行するように書式設定されています。

VM の作成

VM を作成する前に、その VM を含めるリソース グループを作成する必要があります。 az group create を使用して、リソース グループを作成します。 次の例では、myResourceGroup という名前のリソース グループを eastus に作成します。

az group create --name myResourceGroup --location eastus

az vm create を使用して VM を作成します。 既定のキーの場所にまだ SSH キーが存在しない場合は、コマンドを使って SSH キーを作成します。 特定のキーのセットを使用するには、--ssh-key-value オプションを使用します。 次の例では、myVm という名前の VM を作成します。

az vm create \
  --resource-group myResourceGroup \
  --name myVm \
  --image UbuntuLTS \
  --generate-ssh-keys

VM の作成には数分かかります。 VM が作成されて、Azure CLI から出力が返されるまでは、次の手順に進まないでください。

ネットワーク通信をテストする

Network Watcher を使ってネットワーク通信をテストするには、最初にテスト対象の VM が含まれるリージョンにおいて Network Watcher を有効にしてから、Network Watcher の IP フローの確認機能を使って通信をテストする必要があります。

ネットワーク ウォッチャーを有効にする

米国東部リージョンで既に Network Watcher を有効にしている場合は、「IP フローの確認を使用する」に進んでください。 az network watcher configure コマンドを使用して、米国東部リージョンにネットワーク ウォッチャーを作成します。

az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations eastus \
  --enabled

IP フローの確認を使用する

VM を作成すると、Azure は既定に従って、VM との間でやり取りされるネットワーク トラフィックを許可および拒否します。 後で Azure の既定値をオーバーライドして、他の種類のトラフィックを許可または拒否する場合があります。 さまざまな送信先へのトラフィックまたは送信元 IP アドレスからのトラフィックが許可または拒否されるかどうかをテストするには、az network watcher test-ip-flow コマンドを使います。

VM から www.bing.com のいずれかの IP アドレスへの送信通信をテストします。

az network watcher test-ip-flow \
  --direction outbound \
  --local 10.0.0.4:60000 \
  --protocol TCP \
  --remote 13.107.21.200:80 \
  --vm myVm \
  --nic myVmVMNic \
  --resource-group myResourceGroup \
  --out table

数秒後に、DenyAllOutBound という名前のセキュリティ規則によってアクセスが許可されていることを示す結果が返されます。

VM から 172.31.0.100 への送信通信をテストします。

az network watcher test-ip-flow \
  --direction outbound \
  --local 10.0.0.4:60000 \
  --protocol TCP \
  --remote 172.31.0.100:80 \
  --vm myVm \
  --nic myVmVMNic \
  --resource-group myResourceGroup \
  --out table

返される結果では、DenyAllOutBound という名前のセキュリティ規則によってアクセスが拒否されることが示されています。

172.31.0.100 から VM への受信通信をテストします。

az network watcher test-ip-flow \
  --direction inbound \
  --local 10.0.0.4:80 \
  --protocol TCP \
  --remote 172.31.0.100:60000 \
  --vm myVm \
  --nic myVmVMNic \
  --resource-group myResourceGroup \
  --out table

返される結果では、DenyAllInBound という名前のセキュリティ規則のためにアクセスが拒否されることが示されています。 VM へのトラフィックまたは VM からのトラフィックを許可または拒否しているセキュリティ規則がわかったので、問題を解決する方法を決定できます。

セキュリティ規則の詳細を表示する

IP フローの確認を使用する」の規則が通信を許可または拒否している理由を特定するには、az network nic list-effective-nsg コマンドを使って、ネットワーク インターフェイスに対して有効なセキュリティ規則を確認します。

az network nic list-effective-nsg \
  --resource-group myResourceGroup \
  --name myVmVMNic

返される出力には、前の「IP フローの確認を使用する」の手順で www.bing.com への送信アクセスを許可した AllowInternetOutbound 規則に関する次のテキストが含まれます。

{
 "access": "Allow",
 "additionalProperties": {},
 "destinationAddressPrefix": "Internet",
 "destinationAddressPrefixes": [
  "Internet"
 ],
 "destinationPortRange": "0-65535",
 "destinationPortRanges": [
  "0-65535"
 ],
 "direction": "Outbound",
 "expandedDestinationAddressPrefix": [
  "1.0.0.0/8",
  "2.0.0.0/7",
  "4.0.0.0/6",
  "8.0.0.0/7",
  "11.0.0.0/8",
  "12.0.0.0/6",
  ...
 ],
 "expandedSourceAddressPrefix": null,
 "name": "defaultSecurityRules/AllowInternetOutBound",
 "priority": 65001,
 "protocol": "All",
 "sourceAddressPrefix": "0.0.0.0/0",
 "sourceAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "sourcePortRange": "0-65535",
 "sourcePortRanges": [
  "0-65535"
 ]
},

前の出力では、destinationAddressPrefixInternet であることがわかります。 ただし、13.107.21.200 が Internet にどのように関係しているのかはっきりしません。 expandedDestinationAddressPrefix には複数のアドレス プレフィックスが列記されています。 リストのプレフィックスの 1 つは 12.0.0.0/6 であり、これは 12.0.0.1-15.255.255.254 の IP アドレス範囲を包含します。 13.107.21.200 はそのアドレス範囲内にあるため、AllowInternetOutBound 規則は送信トラフィックを許可します。 さらに、前の出力で示されている規則の中には、この規則をオーバーライドする優先順位の高い (小さい値の) 規則はありません。 ある IP アドレスへの送信通信を拒否するには、その IP アドレスへのポート 80 での送信を拒否する、優先順位の高いセキュリティ規則を追加します。

IP フローの確認を使用する」で az network watcher test-ip-flow コマンドを実行して 172.131.0.100 への送信通信をテストしたとき、出力では DenyAllOutBound 規則により通信が拒否されることが示されました。 DenyAllOutBound 規則は、az network nic list-effective-nsg コマンドからの次の出力で示されている DenyAllOutBound 規則と同じです。

{
 "access": "Deny",
 "additionalProperties": {},
 "destinationAddressPrefix": "0.0.0.0/0",
 "destinationAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "destinationPortRange": "0-65535",
 "destinationPortRanges": [
  "0-65535"
 ],
 "direction": "Outbound",
 "expandedDestinationAddressPrefix": null,
 "expandedSourceAddressPrefix": null,
 "name": "defaultSecurityRules/DenyAllOutBound",
 "priority": 65500,
 "protocol": "All",
 "sourceAddressPrefix": "0.0.0.0/0",
 "sourceAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "sourcePortRange": "0-65535",
 "sourcePortRanges": [
  "0-65535"
 ]
}

ルールでは、destinationAddressPrefix として 0.0.0.0/0 が含まれます。 172.131.0.100 は az network nic list-effective-nsg コマンドからの出力の他のどの送信規則の destinationAddressPrefix にも含まれないので、規則はこのアドレスへの送信通信を拒否します。 この送信通信を許可するには、172.131.0.100 のポート 80 への送信トラフィックを許可する、優先順位の高いセキュリティ規則を追加します。

IP フローの確認を使用する」で az network watcher test-ip-flow コマンドを実行して 172.131.0.100 からの受信通信をテストしたとき、出力では DenyAllInBound 規則により通信が拒否されることが示されました。 DenyAllInBound 規則は、az network nic list-effective-nsg コマンドからの次の出力で示されている DenyAllInBound 規則と同じです。

{
 "access": "Deny",
 "additionalProperties": {},
 "destinationAddressPrefix": "0.0.0.0/0",
 "destinationAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "destinationPortRange": "0-65535",
 "destinationPortRanges": [
  "0-65535"
 ],
 "direction": "Inbound",
 "expandedDestinationAddressPrefix": null,
 "expandedSourceAddressPrefix": null,
 "name": "defaultSecurityRules/DenyAllInBound",
 "priority": 65500,
 "protocol": "All",
 "sourceAddressPrefix": "0.0.0.0/0",
 "sourceAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "sourcePortRange": "0-65535",
 "sourcePortRanges": [
  "0-65535"
 ]
},

出力で示されているように、az network nic list-effective-nsg コマンドからの出力には、172.131.0.100 から VM へのポート 80 での受信を許可する優先順位の高い規則が他に存在しないため、DenyAllInBound 規則が適用されます。 この受信通信を許可するには、ポート 80 での 172.131.0.100 からの受信を許可する優先順位の高いセキュリティ規則を追加します。

このクイック スタートのチェックでは、Azure の構成をテストしました。 チェックから予想どおりの結果が返ったにもかかわらず、まだネットワークの問題がある場合は、VM と通信対象のエンドポイントとの間にファイアウォールが存在しないこと、および VM のオペレーティング システムに通信を許可または拒否するファイアウォールが含まれないことを確認します。

リソースをクリーンアップする

不要になったら、az group delete を使用して、リソース グループとそのグループに含まれているすべてのリソースを削除できます。

az group delete --name myResourceGroup --yes

次のステップ

このクイック スタートでは、VM を作成し、受信および送信ネットワーク トラフィック フィルターを診断しました。 ネットワーク セキュリティ グループの規則が、VM との間でやり取りされるトラフィックを許可または拒否することを学習しました。 セキュリティ規則およびセキュリティ規則を作成する方法について、さらに詳しく学習してください。

適切なネットワーク トラフィック フィルターを適用してもまだ、ルーティングの構成のために VM への通信が失敗する可能性があります。 VM ネットワークのルーティングの問題を診断する方法については、「VM のルーティングに関する問題を診断する」をご覧ください。送信ルーティング、待機時間、およびトラフィック フィルター処理の問題を 1 つのツールで診断する方法については、接続のトラブルシューティングに関するページをご覧ください。