Azure Key Vaultでのプライベート リンクの構成に関する問題を診断する

はじめに

この記事は、ユーザーがKey Vaultとプライベート リンク機能に関連する問題を診断して修正するのに役立ちます。 このガイドは、プライベート リンクを初めて稼働させる場合や、何かを変更したらプライベート リンクが動かなくなったときに修正する場合など、構成の側面に役立ちます。

この機能を初めて使用する場合は、 Azure Private Linkを使用したKey Vaultの統合に関する記事を参照してください。

この記事で説明されている問題

  • DNS クエリから、プライベート リンク機能を使用すると予想されるプライベート IP アドレスではなく、キー コンテナーのパブリック IP アドレスがまだ返されます。
  • プライベート リンクを使用している特定のクライアントによって行われたすべての要求がタイムアウトまたはネットワーク エラーで失敗し、問題は断続的ではありません。
  • キー コンテナーにはプライベート IP アドレスがありますが、要求でまだ 403 応答と ForbiddenByFirewall 内部エラー コードが発生します。
  • プライベート リンクを使用していますが、キー コンテナーではまだパブリック インターネットからの要求が受け付けられます。
  • キー コンテナーに 2 つのプライベート エンドポイントがあります。 一方を使用する要求は正常に機能しますが、もう一方を使用する要求は失敗します。
  • プライベート リンクを使用している別のサブスクリプション、キー コンテナー、または仮想ネットワークがあります。 新しく似たデプロイを作成する必要がありますが、そこでプライベート リンクを動かすことができません。

この記事で説明されていない問題

  • 断続的な接続の問題があります。 特定のクライアントで、動作する要求と、動作しない要求があります。 断続的な問題は、プライベート リンク構成の問題によって引き起こされることはほとんどありません。これらは、ネットワークまたはクライアントのオーバーロードの兆候です。
  • BYOK (Bring Your Own Key)、CMK (カスタマー マネージド キー)、またはキー コンテナーに格納されているシークレットへのアクセスをサポートするAzure製品を使用しています。 キー コンテナーの設定でファイアウォールを有効にすると、その製品でキー コンテナーにアクセスできなくなります。 製品固有のドキュメントを参照してください。 ファイアウォールを有効にした状態でキーボールトがサポートされていることが明記されていることを確認してください。 必要な場合は、その特定の製品のサポートにお問い合わせください。

この記事を読む方法

プライベート リンクを初めて使用する場合、または複雑なデプロイを評価する場合は、記事全体を読んでおくことをお勧めします。 それ以外の場合は、発生している問題に関係のありそうなセクションを自由に選択してください。

それでは始めましょう。

1. クライアント接続を所有していることを確認する

クライアントが仮想ネットワークで実行されていることを確認する

このガイドは、アプリケーション コードから行われたキー コンテナーへの接続の修正を支援することが意図されています。 たとえば、Azure 仮想マシン、Azure Service Fabric クラスター、Azure App Service、Azure Kubernetes Service (AKS)などで実行されるアプリケーションとスクリプトがあります。 このガイドは、ブラウザーがキー コンテナーに直接アクセスする、Azure ポータルの Web ベース ユーザー インターフェイスで実行されるアクセスにも適用されます。

プライベート リンクの定義では、アプリケーション、スクリプト、またはポータルは、Private Endpoint リソースがデプロイされたVirtual Networkに接続されているコンピューター、クラスター、または環境で実行されている必要があります。

アプリケーション、スクリプト、またはポータルが、インターネットに接続された任意のネットワーク上で実行されている場合、このガイドは適用されず、おそらくプライベート リンクは使用できません。 この制限は、ユーザー ブラウザーではなくオンデマンドで提供されるリモート Azure コンピューターで実行されるため、Azure Cloud Shellで実行されるコマンドにも適用されます。

マネージド ソリューションを使用する場合は、特定のドキュメントを参照する

マネージド Azure サービスには異なる構成が必要

このガイドは、Virtual Networkの外部からKey VaultにアクセスするMicrosoftマネージド サービスには適用されません。 これらのシナリオは、次のとおりです。

  • 保存時の暗号化を使用して構成されたAzure Storage
  • カスタマー マネージド キーを使用したAzure SQL
  • Azure Event Hubsは、あなたのキーを使用してデータを暗号化します。
  • Key Vaultに格納されている資格情報にアクセスするAzure Data Factory
  • Key Vaultからシークレットを取得するAzure Pipelines

これらのシナリオでは、特定のAzure サービスがファイアウォールを有効にした Key Vault へのアクセスをサポートしているかどうかを確認する必要があります。 多くのサービスでは、Trusted Services 機能を使用して、ファイアウォールの制限にもかかわらずKey Vaultに安全にアクセスします。 ただし、アーキテクチャ上のさまざまな理由により、すべてのAzure サービスが信頼されたサービスの一覧に表示されるわけではありません。

Key Vaultにアクセスする特定のAzure サービスで問題が発生した場合は、そのサービスのドキュメントを参照するか、サポート チームに連絡して特定のガイダンスを確認してください。

いくつかのAzure製品は、vnet インジェクションの概念をサポートしています。 簡単に言うと、製品は顧客Virtual Networkにネットワーク デバイスを追加し、Virtual Networkにデプロイされたかのように要求を送信できるようにします。 注目すべき例は、Azure Databricksです。 このような製品の場合、プライベート リンクを使用してキー コンテナーへの要求を行うことができるので、このトラブルシューティング ガイドが役に立つことがあります。

2. 接続が承認され、成功することを確認する

次の手順を使用して、プライベート エンドポイント接続が承認され、成功することを検証します。

  1. Azure ポータルを開き、キー コンテナー リソースを開きます。
  2. 左側のメニューで、 [ネットワーク] を選択します。
  3. [ プライベート エンドポイント接続 ] タブを選択すると、すべてのプライベート エンドポイント接続とそれぞれの状態が表示されます。 接続がない場合、またはVirtual Networkの接続がない場合は、新しいプライベート エンドポイントを作成する必要があります。 これについては後で説明します。
  4. 引き続き [プライベート エンドポイント接続] で、診断しているものを見つけ、[接続状態] が [承認済み] であり、[プロビジョニング状態] が [成功] であることを確認します。
    • 接続が [保留中] 状態である場合は、承認だけで済む可能性があります。
    • 接続が [拒否]、[失敗]、[エラー]、[切断]、またはその他の状態の場合、まったく有効ではないため、新しいプライベート エンドポイント リソースを作成する必要があります。

繁雑にならないよう、無効な接続を削除することをお勧めします。

3. Key Vault ファイアウォールが正しく構成されていることを確認する

重要

ファイアウォールの設定を変更すると、プライベート リンクをまだ使用していない正当なクライアントからのアクセスが削除される場合があります。 ファイアウォールの構成を変更するとどのような影響があるかを認識しておいてください。

重要な概念として、プライベートリンク機能はデータ流出を防ぐために閉じられた仮想ネットワーク内のキー ボールトへのアクセスを許可するだけであるということです。 既存のアクセスが "削除される" ことはありません。 パブリック インターネットからのアクセスを効果的にブロックするには、Key Vault ファイアウォールを明示的に有効にする必要があります。

  1. Azure ポータルを開き、キー コンテナー リソースを開きます。
  2. 左側のメニューで、 [ネットワーク] を選択します。
  3. 上部で [ファイアウォールと仮想ネットワーク] タブが選択されていることを確認します。
  4. [すべてのネットワークからのパブリック アクセスを許可する] が選択されている場合、それが、外部クライアントからキー コンテナーにまだアクセスできる理由です。 Key VaultにPrivate Link経由でのみアクセスできるようにする場合は、[パブリック アクセスの許可を選択します。

ファイアウォールの設定については次のことも適用されます。

  • プライベート リンク機能を使用する場合、Key Vault ファイアウォールの設定で "仮想ネットワーク" を指定する必要はありません。 キー コンテナーのプライベート IP アドレスを使用するすべての要求 (次のセクションを参照) が、Key Vault ファイアウォールの設定で仮想ネットワークが指定されていない場合でも、機能する必要があります。
  • プライベート リンク機能を使用する場合、Key Vault ファイアウォールの設定で IP アドレスを指定する必要はありません。 やはり、キー コンテナーのプライベート IP アドレスを使用するすべての要求が、ファイアウォールの設定で IP アドレスが指定されていない場合でも、機能する必要があります。

プライベート リンクを使用している場合、Key Vault ファイアウォールで仮想ネットワークまたは IP アドレスの指定が必要になるのは、次の場合だけです。

  • 一部のクライアントではプライベート リンクを使用し、一部はサービス エンドポイントを使用し、一部はパブリック IP アドレスを使用するハイブリッド システムがあります。
  • プライベート リンクに移行している。 この場合は、すべてのクライアントでプライベート リンクが使用されていることを確認したら、Key Vault ファイアウォールの設定から仮想ネットワークと IP アドレスを削除する必要があります。

4. キー コンテナーにプライベート IP アドレスがあることを確認する

プライベート IP アドレスとパブリック IP アドレスの違い

プライベート IP アドレスの形式は、常に次のいずれかです。

  • 10.x.x.x: 例: 10.1.2.3、10.56.34.12。
  • 172.16.x.x から 172.32.x.x: 例: 172.20.1.1、172.31.67.89。
  • 192.168.x.x: 例: 192.168.0.1、192.168.100.7

次のような特定の IP アドレスと範囲は予約されています。

  • 224.x.x.x: マルチキャスト
  • 255.255.255.255: ブロードキャスト
  • 127.x.x.x: ループバック
  • 169.254.x.x: リンク ローカル
  • 168.63.129.16: 内部 DNS

他のすべての IP アドレスはパブリックです。

ポータルを参照すると、または IP アドレスが表示されるコマンドを実行すると、その IP アドレスがプライベート、パブリック、予約のいずれであるかを確認できます。 プライベート リンクを正常に動作させるためには、キー ボルトのホスト名を、仮想ネットワークのアドレス空間に属するプライベート IP アドレスに解決する必要があります。

仮想ネットワーク内のキー コンテナーのプライベート IP アドレスを検索する

ホスト名の解決を診断する必要があります。そのため、プライベート リンクが有効になっているキー コンテナーの正確なプライベート IP アドレスを知っている必要があります。 そのアドレスを見つけるには、次の手順に従います。

  1. Azure ポータルを開き、キー コンテナー リソースを開きます。
  2. 左側のメニューで、 [ネットワーク] を選択します。
  3. [ プライベート エンドポイント接続 ] タブを選択します。結果のビューには、すべてのプライベート エンドポイント接続とそれぞれの状態が表示されます。
  4. 診断している接続を見つけて、"接続状態" が 承認され 、プロビジョニング状態が成功したことを確認 します。 状態が異なる場合は、ドキュメントの前のセクションに戻ります。
  5. 適切な項目が見つかると、[ プライベート エンドポイント ] 列でリンクを選択します。 このアクションにより、プライベート エンドポイント リソースが開きます。
  6. [概要] ページに [カスタム DNS 設定] というセクションが表示される場合があります。 キー コンテナーのホスト名と一致するエントリが 1 つだけであることを確認します。 そのエントリには、キー コンテナーのプライベート IP アドレスが表示されます。
  7. ネットワーク インターフェイスでリンクを選択し、プライベート IP アドレスが前の手順で表示されているのと同じであることを確認することもできます。 ネットワーク インターフェイスは、キー ボールトを表す仮想デバイスです。

IP アドレスは、VM やその他のデバイスが同じ仮想ネットワークで実行されているキー・ボールトに接続するために使用するものです。 その IP アドレスを記録しておくか、ブラウザーのタブを開いたままにしておき、さらに調査を行う間それに触れないようにします。

注

お使いのキー コンテナーに複数のプライベート エンドポイントがある場合は、複数のプライベート IP アドレスがあります。 これは、複数の仮想ネットワークが同じキー コンテナーにアクセスし、それぞれが独自のプライベート エンドポイントを介してアクセスしている場合にのみ役立ちます (プライベート エンドポイントは 1 つのVirtual Networkに属します)。 正しいVirtual Networkの問題を診断し、上記の手順で適切なプライベート エンドポイント接続を選択してください。 同じVirtual Network内の同じKey Vaultに対して複数のプライベート エンドポイントを作成しないでください。 これは必要ではなく、混乱の原因になります。

5. DNS の解決を検証する

DNS の解決とは、キー コンテナーのホスト名 (例: fabrikam.vault.azure.net) を IP アドレス (例: 10.1.2.3) に変換するプロセスです。 以下のサブセクションでは、各シナリオで予想される DNS の解決の結果を示します。

このセクションは学習のためのものです。 キー コンテナーに承認済み状態のプライベート エンドポイント接続がない場合、ホスト名を解決すると、次のような結果が得られます。

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

名前がパブリック IP アドレスに解決され、privatelink 別名がないことがわかります。 別名については後で説明するので、今は気にしないでください。

この結果は、Virtual Networkに接続されているコンピューターからクエリを実行しているか、インターネットに接続されているコンピューターからクエリを実行しているかに関係なく、同じように表示されます。 結果は、キー コンテナーに承認済み状態のプライベート エンドポイント接続がないため、キー コンテナーがプライベート リンクをサポートする必要がないために発生します。

キー コンテナーに承認済み状態のプライベート エンドポイント接続が 1 つ以上あり、インターネットに接続されている任意のマシン (プライベート エンドポイントが存在する仮想ネットワークに接続されていないマシン) からホスト名を解決すると、次のような結果が得られます。

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

前のシナリオとの大きな違いは、値が {vaultname}.privatelink.vaultcore.azure.net の新しい別名があることです。 Key Vault データ プレーンは、プライベート リンクからの要求を受け入れる準備ができています。

これは、Virtual Networkの外にあるマシンからの要求（あなたが使用したもののように）がプライベートリンクを使用することを意味しません。実際には使用されていません。 それは、ホスト名が引き続きパブリック IP アドレスに解決されることからわかります。 プライベート リンク<使用できるのは、Virtual Networkコンピューター>だけです。

privatelink という別名が表示されない場合は、キー コンテナーに Approved 状態のプライベート エンドポイント接続がないことを意味します。 再度試みる前に、このセクションに戻ってください。

キー コンテナーに承認済み状態のプライベート エンドポイント接続が 1 つ以上あり、プライベート エンドポイントが作成されたVirtual Networkに接続されているマシンからホスト名を解決する場合、これは予想される応答です。

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  10.1.2.3
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net has address 10.1.2.3

大きな違いが 2 つあります。 まず、名前はプライベート IP アドレスに解決されます。 それは、この記事の対応するセクションで確認した IP アドレスである必要があります。 第 2 に、privatelink の後に他の別名はありません。 これは、Virtual Network DNS サーバーがエイリアスのチェーンを傍受し、名前fabrikam.privatelink.vaultcore.azure.netから直接プライベート IP アドレスを返すために起こります。 このエントリは、実際には プライベート DNS ゾーン内の A レコードです。

注

この結果は、プライベート エンドポイントが作成されたVirtual Networkに接続されている仮想マシンでのみ発生します。 プライベート エンドポイントを含む VM がVirtual Networkにデプロイされていない場合は、VM をデプロイしてリモートで接続し、nslookup コマンド (Windows) または host コマンド (Linux) を実行します。

プライベート エンドポイントが作成された仮想ネットワークに接続されている仮想マシンでこれらのコマンドを実行しても、キー コンテナーのプライベート IP アドレスが表示されなければ、次のセクションが問題の解決に役立つかもしれません。

6. プライベート DNS ゾーンを検証する

前のセクションで説明したように DNS 解決が機能しない場合は、プライベート DNS ゾーンに問題がある可能性があり、このセクションが役立つ可能性があります。 DNS 解決で正しいキー コンテナーのプライベート IP アドレスが示されている場合は、プライベート DNS ゾーンが正しい可能性があります。 このセクションは丸ごとスキップできます。

必要な プライベート DNS Zone リソースが存在することを確認する

Azure サブスクリプションには、次の正確な名前の プライベート DNS Zone リソースが必要です。

privatelink.vaultcore.azure.net

このリソースが存在することを確認するには、ポータルでサブスクリプションのページに移動し、左側のメニューで [リソース] を選択します。 リソース名は privatelink.vaultcore.azure.net、リソースの種類は プライベート DNS zone である必要があります。

通常、このリソースは、一般的な手順を使用してプライベート エンドポイントを作成すると自動的に作成されます。 ただし、このリソースが自動的に作成されず、手動で行うことが必要な場合もあります。 このリソースが誤って削除された可能性もあります。

このリソースがない場合は、サブスクリプションに新しい プライベート DNS Zone リソースを作成します。 名前は、スペースや余分なドットを使用せずに、正確に privatelink.vaultcore.azure.netする必要があります。 間違った名前を指定すると、この記事で説明されている名前解決は失敗します。 このリソースを作成する方法の詳細については、「Azure ポータルを使用してAzureプライベート DNS ゾーンを作成するを参照してください。 そのページに従う場合は、この時点で既に作成する必要があるため、Virtual Networkの作成をスキップできます。 Virtual Machinesを使用して検証手順をスキップすることもできます。

プライベート DNS ゾーンがVirtual Networkにリンクされていることを確認します

プライベート DNSゾーンを持つだけでは不十分です。 プライベート エンドポイントを含むVirtual Networkにもリンクする必要があります。 プライベート DNS ゾーンが正しいVirtual Networkにリンクされていない場合、そのVirtual Networkの DNS 解決はプライベート DNS ゾーンを無視します。

プライベート DNS ゾーン リソースを開き、左側のメニューの Virtual ネットワーク リンク オプションを選択します。 リンクの一覧が表示され、それぞれにサブスクリプション内のVirtual Networkの名前が表示されます。 プライベート エンドポイント リソースを含むVirtual Networkを次に示す必要があります。 ない場合は追加します。 詳細な手順については、「仮想ネットワークのリンク」を参照してください。 [自動登録を有効にする] はオフのままでかまいません。その機能はプライベート リンクとは関係ありません。

プライベート DNS ゾーンがVirtual Networkにリンクされると、そのネットワーク内から送信されるすべての DNS 要求で、このプライベート ゾーンの名前解決が自動的に確認されます。 このリンケージは、プライベート エンドポイントと同じVirtual Network内のVirtual Machinesが、キー コンテナーのホスト名をパブリック アドレスではなくプライベート IP アドレスに正しく解決するために不可欠です。

注

リンクを保存したばかりの場合は、ポータルで操作が完了したと表示された後でも、有効になるには時間がかかる場合があります。 DNS の解決をテストするために使用している VM を再起動することも、必要な場合があります。

プライベート DNS ゾーンに適切な A レコードが含まれていることを確認する

ポータルを使用して、名前が privatelink.vaultcore.azure.net のプライベート DNS ゾーンを開きます。 [概要] ページにすべてのレコードが表示されます。 既定では、名前が @ で SOAを入力したレコードが 1 つ存在します。これは、権限の開始を意味します。 それには触れないでください。

キー コンテナーの名前解決が機能するには、サフィックスやドットが付いていない単純なコンテナー名を持つ A レコードが必要です。 たとえば、ホスト名が fabrikam.vault.azure.net である場合、サフィックスやドットを含まない A という名前の fabrikam レコードが必要です。

また、A レコードの値 (IP アドレス) は、キー コンテナーのプライベート IP アドレスである必要があります。 A レコードが見つかっても、含まれる IP アドレスが正しくない場合は、間違った IP アドレスを削除して新しい IP アドレスを追加する必要があります。 Aレコード全体を削除し、新しいレコードを追加することをお勧めします。

注

A レコードを削除または変更しても、TTL (Time To Live) の値の有効期限がまだ切れていない可能性があるため、マシンが古い IP アドレスに解決される場合があります。 TTL には常に、10 秒以上で 600 秒 (10 分) 以下の値を指定することを推奨します。 大きすぎる値を指定した場合、クライアントが障害から回復するのに時間がかかりすぎることがあります。

複数のVirtual Networkの DNS 解決

複数の仮想ネットワークがあり、それぞれに同じキー コンテナーを参照する独自のプライベート エンドポイント リソースがある場合は、キー コンテナーのホスト名が、ネットワークに応じた異なるプライベート IP アドレスに解決される必要があります。 つまり、複数のプライベート DNS ゾーンも必要であり、それぞれが異なるVirtual Networkにリンクされ、A レコードで異なる IP アドレスを使用します。

より高度なシナリオでは、仮想ネットワークでピアリングが有効になっている可能性があります。 この場合、プライベート エンドポイント リソースが必要なVirtual Networkは 1 つだけですが、どちらも プライベート DNS ゾーン リソースにリンクする必要がある場合があります。 このシナリオについては、このドキュメントでは直接説明されてはいません。

DNS の解決を制御できることを理解する

前のセクションで説明したように、プライベート リンクを使用するキー コンテナーには、その "{vaultname}.privatelink.vaultcore.azure.net" 登録に、 という別名があります。 Virtual Networkによって使用される DNS サーバーはパブリック登録を使用しますが、private 登録のすべてのエイリアスをチェックし、見つかった場合は、パブリック登録で定義されているエイリアスのフォローを停止します。

このロジックは、Virtual Networkが名前がprivatelink.vaultcore.azure.netのプライベート DNSゾーンにリンクされている場合、キーボールトのパブリックDNS登録にはエイリアスfabrikam.privatelink.vaultcore.azure.netがあります（キーボールトのホスト名サフィックスはプライベート DNSゾーン名と正確に一致します）。その後、DNSクエリは名前がfabrikamのAレコードをプライベート DNSゾーンで検索します。 A レコードが見つかった場合、DNS クエリからはその IP アドレスが返され、パブリック DNS の登録に対してそれ以上の参照は実行されません。

ご覧の通り、名前解決はあなたの管理下にあります。 この設計の合理的な理由は次のとおりです。

  • カスタム DNS サーバーと、オンプレミス ネットワークとの統合の両方が関係する、複雑なシナリオがある場合があります。 その場合は、名前が IP アドレスに変換される方法を、ユーザーが制御する必要があります。
  • プライベート リンクを使用せずに、キー コンテナーにアクセスすることが必要になる場合があります。 その場合、プライベート リンクのないキー コンテナーには名前の登録に privatelink エイリアスがないため、Virtual Networkからホスト名を解決するとパブリック IP アドレスが返される必要があります。

キー コンテナーの /healthstatus エンドポイントのクエリを実行する

キー ボールトからは /healthstatus エンドポイントが提供されており、診断に活用できます。 応答ヘッダーには、キー ボールト サービスによって認識されるように、送信元 IP アドレスが含まれます。 次のコマンドを使用して、そのエンドポイントを呼び出すことができます (忘れずに、自分のキー コンテナーのホスト名を使用してください)。

Windows (PowerShell):

PS C:\> $(Invoke-WebRequest -UseBasicParsing -Uri https://fabrikam.vault.azure.net/healthstatus).Headers

Key                           Value
---                           -----
Pragma                        no-cache
x-ms-request-id               3729ddde-eb6d-4060-af2b-aac08661d2ec
x-ms-keyvault-service-version 1.2.27.0
x-ms-keyvault-network-info    addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security     max-age=31536000;includeSubDomains
Content-Length                4
Cache-Control                 no-cache
Content-Type                  application/json; charset=utf-8

Linux、または curl を含むWindows 10の最新バージョン:

joe@MyUbuntu:~$ curl -i https://fabrikam.vault.azure.net/healthstatus

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
x-ms-request-id: 6c090c46-0a1c-48ab-b740-3442ce17e75e
x-ms-keyvault-service-version: 1.2.27.0
x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security: max-age=31536000;includeSubDomains
Content-Length: 4

そのような出力が得られない場合、またはネットワーク エラーが発生する場合は、指定したホスト名 (例では fabrikam.vault.azure.net) を使用してキー コンテナーにアクセスできないことを意味します。 ホスト名が正しい IP アドレスに解決されていないか、トランスポート層で接続の問題が発生しています。 原因としては、ルーティングの問題、パッケージの削除、その他の理由が考えられます。 さらに調査する必要があります。

応答には、ヘッダー x-ms-keyvault-network-info が含まれている必要があります。

x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;

addr ヘッダーの x-ms-keyvault-network-info フィールドでは、要求の送信元の IP アドレスが示されています。 この IP アドレスは、次のいずれかになります。

  • 要求を行っているコンピューターのプライベート IP アドレス。 これは、要求でプライベート リンクまたはサービス エンドポイントが使用されていることを示します。 これは、プライベート リンクに対して予想される結果です。
  • 要求を行っているコンピューターからでは "ない"、他の何らかのプライベート IP アドレス。 これは、何らかのカスタム ルーティングが有効であることを示します。 それでも、要求でプライベート リンクまたはサービス エンドポイントが使用されていることを示します。
  • 何らかのパブリック IP アドレス。 これは、要求がゲートウェイ (NAT) デバイスを通してインターネットにルーティングされていることを示します。 これは、要求でプライベート リンクが使用されておらず、何らかの問題を解決する必要があることを示します。 これの一般的な理由は、1) プライベート エンドポイントが承認済みの成功状態ではなく、2) ホスト名がキー コンテナーのプライベート IP アドレスに解決されていないことです。 この記事には、両方の場合のトラブルシューティング手順が含まれています。

注

/healthstatus に対する要求が機能しても、x-ms-keyvault-network-info ヘッダーがない場合は、エンドポイントがキーボールトによって管理されていない可能性があります。 上記のコマンドを使用すると HTTPS 証明書も検証されるので、ヘッダーの欠落は改ざんを示している可能性があります。

キー ボールトの IP アドレスを直接照会する

重要

HTTPS 証明書を検証せずにキー コンテナーにアクセスすることは危険であり、学習目的でのみ使用できます。 運用コードの場合、このクライアント側の検証を行わずにキー コンテナーにアクセスしてはいけません。 問題を診断しているだけであっても、キー保管庫への要求で HTTPS 証明書の検証を頻繁に無効にしている場合、改ざんの試みが発覚しないことがあります。

最新バージョンの PowerShell をインストールした場合は、-SkipCertificateCheck を使用して HTTPS 証明書のチェックをスキップし、キー コンテナーの IP アドレスを直接ターゲットにすることができます。

PS C:\> $(Invoke-WebRequest -SkipCertificateCheck -Uri https://10.1.2.3/healthstatus).Headers

curl を使用している場合は、-k 引数を使用して同じようにすることができます。

joe@MyUbuntu:~$ curl -i -k https://10.1.2.3/healthstatus

応答は、前のセクションと同じである必要があります。つまり、同じ値を持つ x-ms-keyvault-network-info ヘッダーが含まれる必要があります。 /healthstatus エンドポイントには、キーの保管庫のホスト名または IP アドレスのどちらを使用しているかは関係ありません。

キー コンテナーのホスト名を使用した要求と、IP アドレスを使用した要求で、x-ms-keyvault-network-info から返される値が異なる場合は、各要求でターゲットになっているエンドポイントが異なります。 どちらのケースに誤りがあり、修正する必要があるかを判断するには、前のセクションの addr からの x-ms-keyvault-network-info フィールドの説明を参照してください。

8. 影響を与える可能性のあるその他の変更とカスタマイズ

次の項目の調査は、完全なものではありません。 さらに問題を探すべき場所が示されますが、これらのシナリオでの問題を解決するには、ネットワークに関する詳細な知識が必要です。

Virtual Networkでカスタム DNS サーバーを診断する

ポータルで、Virtual Network リソースを開きます。 左側のメニューで、 [DNS サーバー] を開きます。 "カスタム" を使用している場合は、DNS の解決がこのドキュメントで説明されているようにならない可能性があります。 DNS サーバーによるキー コンテナーのホスト名の解決方法を診断する必要があります。

既定のAzure指定された DNS サーバーを使用している場合は、このドキュメント全体が適用されます。

仮想マシンで hosts の上書きまたはカスタム DNS サーバーを診断する

多くのオペレーティング システムで、ホスト名ごとに明示的な固定の IP アドレスを設定できます。通常は、hosts ファイルを変更することで行います。 また、DNS サーバーを上書きできる場合もあります。 これらのシナリオのいずれかを使用している場合は、システム固有の診断オプションに進んでください。

無作為検出プロキシ (Fiddler など)

明記されている場合を除き、この記事の診断オプションは、環境に無作為検出プロキシが存在しない場合にのみ機能します。 診断対象のコンピューターにこれらのプロキシが排他的にインストールされていることがよくありますが (Fiddler は最も一般的な例です)、高度な管理者は、ルート証明機関 (CA) を上書きし、ネットワーク内の複数のコンピューターに対応するゲートウェイ デバイスに無作為検出プロキシをインストールしている場合があります。 これらのプロキシは、セキュリティと信頼性の両方に大きく影響する可能性があります。 Microsoftでは、このような製品を使用する構成はサポートされていません。

接続に影響する可能性のあるその他の事項

これは、高度なシナリオまたは複雑なシナリオで見つかる可能性がある項目の完全なリストではありません。

  • Virtual Networkに接続されているAzure Firewall、またはVirtual Networkまたはマシンにデプロイするカスタム ファイアウォール ソリューションのファイアウォール設定。
  • ネットワーク ピアリング。使用される DNS サーバーとトラフィックのルーティング方法に影響を与える可能性があります。
  • カスタム ゲートウェイ (NAT) ソリューション。DNS クエリからのトラフィックなど、トラフィックのルーティング方法に影響を与える可能性があります。

次のステップ

  • Last updated on