仮想ネットワークに関する問題のトラブルシューティング

この記事では、Microsoft Power Platform の 仮想ネットワーク の一般的なシナリオをトラブルシューティングするためのガイダンスを提供します。 この記事では、 Microsoft.PowerPlatform.EnterprisePolicies PowerShell モジュールを使用して、仮想ネットワーク構成に関連する問題を特定して解決する方法について説明します。

診断 PowerShell モジュールを使用する

Microsoft.PowerPlatform.EnterprisePolicies PowerShell モジュールは、Power Platform の仮想ネットワーク構成に関連する問題の診断とトラブルシューティングに役立ちます。 このツールを使用して、Power Platform 環境と仮想ネットワークの間の接続を確認できます。 また、これを使用して、問題の原因となる可能性のある構成の誤りを特定することもできます。 診断 PowerShell モジュールは、PowerShell ギャラリーとその GitHub リポジトリ である PowerPlatform-EnterprisePolicies から入手できます。

モジュールをインストールする

診断 PowerShell モジュールをインストールするには、次の PowerShell コマンドを実行します。

Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies

診断関数を実行する

モジュールをインストールしたら、次のコマンドを実行して PowerShell セッションにインポートします。

Import-Module Microsoft.PowerPlatform.EnterprisePolicies

このモジュールには、仮想ネットワーク構成に関連する問題を診断およびトラブルシューティングするためのいくつかの機能が含まれています。 主な機能の一部を次に示します。

  • Get-EnvironmentRegion: 指定された Power Platform 環境のリージョンを取得します。
  • Get-EnvironmentUsage: 指定された Power Platform 環境の使用状況に関する情報を提供します。
  • Test-DnsResolution: 指定されたドメイン名の DNS 解決をテストします。
  • Test-NetworkConnectivity: Power Platform 環境とターゲット リソースの間のネットワーク接続をテストします。
  • Test-TLSHandshake: Power Platform 環境と宛先リソースの間で TLS ハンドシェイクを確立できるかどうかをテストします。

診断モジュール内で使用可能な関数の完全な一覧については、 Microsoft.PowerPlatform.EnterprisePolicies モジュールを参照してください。

診断モジュールの問題を報告する

診断モジュールの実行時に問題が発生した場合は、モジュールがホストされている GitHub リポジトリを通じて報告します。 リポジトリは PowerPlatform-EnterprisePolicies にあります。

問題を報告するには、リポジトリの [問題 ] セクションに移動し、 新しい問題を開きます。 発生した問題に関する詳細情報を入力します。 問題を調査するときに役立つ可能性のあるエラー メッセージまたはログ エントリを含めます。 レポートに機密情報を含めないでください。

一般的な問題のトラブルシューティング

1 つの環境は機能しますが、別の環境では動作しません

すべてが正しく構成されていても問題が引き続き発生する場合は、診断 PowerShell モジュールの Get-EnvironmentRegion 関数を使用して、Power Platform 環境のリージョンが同じかどうかを確認します。 次のコマンドを実行します。

Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"

環境が異なるリージョンにあり、1 つが機能しても動作しない場合、問題は障害が発生したリージョンの仮想ネットワークのセットアップにあります。 完全セットアップが正しく構成されていることを確認するには、両方のリージョンに対してさらに診断コマンドを実行します。 リージョンを指定するには、 -Region パラメーターを含めます。 例えば次が挙げられます。

Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>" -Region "<AzureRegion>"

環境は特定の Power Platform 地域に属しています。 ただし、Power Platform リージョンは 2 つの Azure リージョンにまたがる場合があります。 環境はどちらのリージョンにも配置でき、それらの間で自動的にフェールオーバーすることもできます。 そのため、高可用性と接続性を確保するには、Power Platform リージョンに関連付けられている両方の Azure リージョンで仮想ネットワークを構成する必要があります。 仮想ネットワーク機能をサポートする Azure リージョンに Power Platform リージョンをマップする方法については、「 Power Platform リージョン」を参照してください。

ホスト名が見つかりません

ホスト名の解決に影響する問題が発生した場合は、診断 PowerShell モジュールの Test-DnsResolution 関数を使用して、ホスト名が正しく解決されているかどうかを確認します。 次のコマンドを実行します。

Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>"

このコマンドは、Power Platform 環境のコンテキストで、指定されたホスト名の DNS 解決をテストします。 要求は委任されたサブネットから開始され、仮想ネットワーク用に構成された DNS サーバーを使用してホスト名の解決を試みます。 ホスト名が正しく解決されない場合は、DNS 設定を確認して、ホスト名が正しく構成されていることを確認する必要があります。

Important

DNS のセットアップが正しくなくて、仮想ネットワークの DNS サーバー設定を更新する必要がある場合は、「 Microsoft.PowerPlatform/enterprisePolicies」に委任された後に仮想ネットワークの DNS アドレスを更新できますか?

要求では、プライベート IP アドレスではなくパブリック IP アドレスが使用されます

リソースへの要求がプライベート IP アドレスではなくパブリック IP アドレスを使用する問題が発生した場合、リソース ホスト名の DNS 解決によってパブリック IP アドレスが返される可能性があります。 この問題は、Azure リソースと Azure 以外のリソースの両方に影響する可能性があります。

プライベート エンドポイントのない Azure 以外のリソース

Azure 以外のリソースにプライベート エンドポイントはありませんが、仮想ネットワークからアクセスできる場合は、リソースのホスト名をプライベート IP アドレスに解決するように DNS サーバーを構成する必要があります。 リソースのホスト名をプライベート IP アドレスにマップする DNS A レコードを DNS サーバーに追加します。

  • カスタム DNS サーバーを使用している場合は、A レコードをサーバーに直接追加します。
  • Azure 提供の DNS を使用している場合は、 Azure プライベート DNS ゾーンを作成し、仮想ネットワークにリンクします。 次に、A レコードをプライベート DNS ゾーンに追加します。

このマッピングにより、そのプライベート IP アドレスを使用してリソースにアクセスできるようになります。

プライベート エンドポイントを持つ Azure リソース

Azure リソースにプライベート エンドポイントがある場合、リソースのホスト名の DNS 解決は、プライベート エンドポイントに関連付けられているプライベート IP アドレスを返す必要があります。 DNS 解決が代わりにパブリック IP アドレスを返す場合は、DNS 構成にレコードがない可能性があります。 次の手順に従います。

  1. リソースの種類に対してプライベート DNS ゾーンが存在することを確認します。 たとえば、Azure SQL Database の場合、privatelink.database.windows.net です。 プライベート DNS ゾーンが存在しない場合は、 作成します。
  2. プライベート DNS ゾーンが仮想ネットワークにリンクされていることを確認します。 プライベート DNS ゾーンが仮想ネットワークにリンクされていない場合は、 リンクします。

プライベート DNS ゾーンを仮想ネットワークにリンクすると、リソースホスト名はプライベート エンドポイントに関連付けられているプライベート IP アドレスに解決されます。

DNS 構成の変更をテストする

DNS 構成を更新した後、診断 PowerShell モジュールの Test-DnsResolution 関数を使用して、ホスト名が正しいプライベート IP アドレスに解決されることを確認します。 次のコマンドを実行します。

Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>"

リソースに接続できない

リソースへの接続に影響する問題が発生した場合は、診断 PowerShell モジュールの Test-NetworkConnectivity 関数を使用して接続を確認します。 次のコマンドを実行します。

Test-NetworkConnectivity -EnvironmentId "<EnvironmentId>" -Destination "<ResourceAddress>" -Port 1433

このコマンドは、Power Platform 環境のコンテキストで、指定された宛先とポートへの TCP 接続を確立しようとします。 要求は委任されたサブネットから開始され、仮想ネットワークからのネットワーク構成を使用して、指定された宛先への接続を試みます。 接続に失敗した場合は、ネットワーク設定を確認して、仮想ネットワークから宛先に到達できることを確認する必要がある場合があります。 正常な接続は、Power Platform 環境と指定されたリソースの間にネットワーク接続が存在することを示します。

注

このコマンドは、指定された宛先とポートへの TCP 接続を確立できるかどうかをテストします。 リソースが使用可能かどうか、またはアプリケーション レベルの問題がリソースへのアクセスを妨げている可能性があるかどうかをテストしません。

TLS ハンドシェイクを確立できない

一部のファイアウォールでは TCP 接続の確立が許可されますが、リソースへの実際のトラフィック (HTTPS など) はブロックされます。 したがって、 Test-NetworkConnectivity 関数がネットワーク接続を示している場合でも、その状態ではリソースが完全にアクセス可能であることが保証されません。

Test-TLSHandshake 関数を使用して、ハンドシェイクを確立できない理由を診断します。 次のコマンドを実行します。

Test-TLSHandshake -EnvironmentId "<EnvironmentId>" -Destination "<ResourceAddress>" -Port 1433

このコマンドは、ハンドシェイクが失敗した理由をデバッグするのに役立つ情報を返します。 出力には、サーバーが提示した証明書、暗号スイート、プロトコル、SSL エラーの説明が含まれます。

Important

パブリックに信頼された証明書のみがサポートされます。 詳細については、「不明な証明書をサポートしていますか?」を参照してください。

接続は成功したが、アプリケーションはまだ動作していない

接続テストが成功しても、アプリケーションで問題が発生している場合は、アプリケーション レベルの設定と構成を確認します。

  1. 委任されたサブネットからリソースへのアクセスがファイアウォールで許可されていることを確認します。
  2. リソースが提示する証明書がパブリックに信頼されていることを確認します。
  3. リソースへのアクセスを妨げる認証または承認の問題がないことを確認します。

診断 PowerShell モジュールを使用して問題を診断または解決できない場合があります。 この場合は、仮想ネットワークに委任なしでサブネットを作成し、そのサブネットに仮想マシン (VM) をデプロイします。 その後、VM を使用して、ネットワーク トラフィックのチェック、ログの分析、アプリケーション レベルの接続のテストなど、さらに診断とトラブルシューティングの手順を実行できます。

トラブルシューティング シナリオの例

Contoso LLC は、ヨーロッパ全体に複数の Power Platform 環境を持ち、西ヨーロッパと北ヨーロッパの仮想ネットワークを持つ多国籍企業です。 各仮想ネットワークには、Power Platform に委任されたサブネットがあります。 各サブネットは、Power Platform 環境にリンクされているエンタープライズ ポリシーに関連付けられます。

次のシナリオは、Contoso が前のセクションで提供した診断コマンドレットを使用して、このセットアップに影響する接続の問題をトラブルシューティングする方法を示しています。

プライベート エンドポイントを介して Azure Key Vault に接続する

Contoso は、Power Platform 環境が仮想ネットワーク経由でキー コンテナーに接続することを望み、パブリック インターネットからの要求を拒否するようにキー コンテナーを構成します。 Contoso が環境からキー コンテナーに接続しようとすると、要求が正しくルーティングされないため、接続は拒否されます。 問題を診断するために、Contoso は次のトラブルシューティング手順を使用します。

まず、 Get-EnvironmentRegion を実行して、送信先のサブネット要求を確認します。

Get-EnvironmentRegion -EnvironmentId "00000000-0000-0000-0000-000000000001"
Get-EnvironmentRegion -EnvironmentId "00000000-0000-0000-0000-000000000002"

返されるリージョンは、調査する仮想ネットワークを識別します。 たとえば、コマンドが西ヨーロッパを返す場合、Contoso は西ヨーロッパ仮想ネットワークのトラブルシューティングに集中する必要があります。

次に、Contoso は、キー コンテナーの完全修飾ドメイン名 (FQDN) の DNS 解決から返される IP アドレスがプライベート IP アドレスであることを確認します。 会社は両方のリージョンに環境を持っているため、 Test-DnsResolution を使用して各リージョンの DNS 解決をテストする必要があります。

Test-DnsResolution -EnvironmentId "00000000-0000-0000-0000-000000000001" -HostName "contoso-keyvault.vault.azure.net" -Region "westeurope"
Test-DnsResolution -EnvironmentId "00000000-0000-0000-0000-000000000001" -HostName "contoso-keyvault.vault.azure.net" -Region "northeurope"

DNS 解決がプライベート IP アドレスではなくパブリック IP アドレスを返す場合、キー コンテナーの プライベート エンドポイント が正しく構成されていない可能性があります。 Contoso は次のことを確認する必要があります。

  1. キー コンテナーのプライベート エンドポイントが存在し、適切な仮想ネットワークに関連付けられています。
  2. キー コンテナーの プライベート DNS ゾーン ( privatelink.vaultcore.azure.net など) が存在し、仮想ネットワークにリンクされています。
  3. プライベート DNS ゾーンには、キー コンテナーのホスト名をプライベート エンドポイントのプライベート IP アドレスにマップする A レコードが含まれています。

Contoso が西ヨーロッパの DNS 解決テストを実行すると、コマンドによってパブリック IP アドレスが返されることを検出します。 調査の結果、キーボールトのプライベート DNS ゾーンが西ヨーロッパの仮想ネットワークにリンクされていないことがわかります。 Contoso は、プライベート DNS ゾーンを仮想ネットワークにリンクし、テストを再実行すると、DNS 解決によって正しいプライベート IP アドレスが返されます。

DNS 解決が両方のリージョンで正しいプライベート IP アドレスを返した後、次の手順は、 Test-NetworkConnectivity を使用してキー コンテナーへのネットワーク接続をテストすることです。

Test-NetworkConnectivity -EnvironmentId "00000000-0000-0000-0000-000000000001" -Destination "contoso-keyvault.vault.azure.net" -Port 443 -Region "westeurope"
Test-NetworkConnectivity -EnvironmentId "00000000-0000-0000-0000-000000000001" -Destination "contoso-keyvault.vault.azure.net" -Port 443 -Region "northeurope"

接続に失敗した場合、 ネットワーク セキュリティ グループ (NSG) の規則またはファイアウォール設定によって、委任されたサブネットからキー コンテナーへのトラフィックがブロックされている可能性があります。 Contoso は次のことを確認する必要があります。

  1. 委任されたサブネットに関連付けられている NSG ルールでは、ポート 443 での送信トラフィックが許可されます。
  2. Key Vault ファイアウォールでは、委任されたサブネットの IP 範囲からの受信接続が許可されます。
  3. トラフィック パス内の Azure Firewall またはネットワーク仮想アプライアンスは、接続を許可します。

この場合、Contoso は、キー ボールトのファイアウォールがプライベート ソースからの接続を許可するように設定されていないことを発見しました。 委任されたサブネットからの接続を許可するようにファイアウォール設定が更新されると、ネットワーク接続テストが成功し、Power Platform 環境は仮想ネットワーク経由でキー コンテナーに正常に接続できます。

オンプレミス ネットワークでホストされている Web サーバーに接続する

Contoso は、Power Platform 環境がオンプレミス ネットワークでホストされている Web サーバーに接続することも望んでいます。 Web サーバーには、 ExpressRoute 接続を介して会社の仮想ネットワークを介してアクセスできます。 Contoso が Power Platform 環境から Web サーバーに接続しようとすると、接続は失敗します。

DNS 解決によって正しい IP アドレスが返され、ネットワーク接続テストが成功しても、Contoso は Web サーバーにアクセスできません。 この問題を診断するために、会社は Test-TLSHandshake を使用して TLS ハンドシェイクをテストします。

Test-TLSHandshake -EnvironmentId "00000000-0000-0000-0000-000000000001" -Destination "webserver.contoso.local" -Port 443 -Region "westeurope"

TLS ハンドシェイクが失敗した場合、出力には、使用された証明書、暗号スイート、プロトコルに関する詳細が表示されます。 Contoso はこの情報を使用して、証明書または TLS 構成の問題を特定できます。 このコマンドは、返された出力の初期分析と、いくつかの基本的な問題に関するアラートを実行します。 ただし、Contoso は完全な出力を分析して、問題をより詳細に調査できます。

この場合、Contoso は、証明書が信頼されていないために TLS ハンドシェイクを確立できないことを検出します。 会社は、コマンド出力の証明書の詳細を調査した後、Web サーバーが自己署名証明書を使用していると判断します。 Power Platform には、TLS 接続に対してパブリックに信頼された証明書が必要です。 Contoso は、 パブリックに信頼された証明機関によって署名された証明書を使用するように Web サーバーを更新すると、TLS ハンドシェイクが成功し、Power Platform 環境が Web サーバーに接続できるようになります。

Azure サービスによって信頼されている証明機関の詳細については、「 Azure 証明機関の詳細」を参照してください。

  • Last updated on