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

  • [アーティクル]

はじめに

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

この機能を初めて使用する場合は、「Key Vault を Azure Private Link と統合する」を参照してください。

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

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

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

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

この記事を読む方法

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

それでは作業を始めましょう。

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

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

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

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

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

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

このガイドは、Microsoft によって管理されているソリューションには適用されません。その場合、キー コンテナーは、お客様の仮想ネットワークとは別に存在する Azure 製品によってアクセスされます。 そのようなシナリオの例としては、保存時の暗号化用に構成された Azure Storage または Azure SQL、お客様提供のキーを使用してデータを暗号化する Azure Event Hubs、キー コンテナーに格納されているサービス資格情報にアクセスする Azure Data Factory、キー コンテナーからシークレットを取得する Azure Pipelines などがあります。 このような場合は、" 、ファイアウォールを有効にしたキー コンテナーが製品によってサポートされているかどうかを確認する必要があります"。 通常、このサポートは Key Vault ファイアウォールの信頼できるサービス機能を使用して実行されます。 ただし、さまざまな理由から、多くの製品が信頼できるサービスの一覧に含まれていません。 その場合は、製品固有のサポートにご連絡ください。

少数ですが、VNet インジェクションの概念をサポートしている Azure 製品があります。 簡単に言えば、この製品によってネットワーク デバイスがお客様の仮想ネットワークに追加され、仮想ネットワークにデプロイされているかのように要求を送信できるようになります。 典型的な例は Azure Databricks です。 このような製品の場合、プライベート リンクを使用してキー コンテナーへの要求を行うことができるので、このトラブルシューティング ガイドが役に立つことがあります。

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

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

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

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

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

重要

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

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

  1. Azure portal を開き、お使いのキー コンテナー リソースを開きます。
  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: Loopback
  • 169.254.x.x: リンク ローカル
  • 168.63.129.16: 内部 DNS

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

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

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

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

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

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

Note

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

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 別名がないことがわかります。 別名については後で説明するので、今は気にしないでください。

コンピューターが仮想ネットワークに接続されているか、インターネットに接続されている任意のコンピューターであるかにかかわらず、上の結果が予想されます。 このようになるのは、キー コンテナーに承認済み状態のプライベート エンドポイント接続がなく、したがってキー コンテナーでプライベート リンクをサポートする必要がないためです。

キー コンテナーに承認済み状態のプライベート エンドポイント接続が 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 の新しい別名があることです。 これは、キー コンテナーのデータ プレーンが、プライベート リンクからの要求を受け入れられる状態であることを意味します。

(ちょうど使用したもののような) 仮想ネットワークの "外部にある" コンピューターから実行された要求によって、プライベート リンクが使用されることを意味するわけではありません。使用されません。 それは、ホスト名が引き続きパブリック IP アドレスに解決されることからわかります。 プライベート リンクを使用できるのは、"仮想ネットワークに接続されている" コンピューターだけです。 これについては後で詳しく説明します。

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

キー コンテナーに承認済み状態のプライベート エンドポイント接続が 1 つ以上あり、プライベート エンドポイントが作成された仮想ネットワークに接続されているコンピューターからホスト名を解決する場合は、次のような応答になります。

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 の後に他の別名はありません。 このようになるのは、仮想ネットワークの DNS サーバーによって別名のチェーンが "インターセプト" され、名前 fabrikam.privatelink.vaultcore.azure.net からプライベート IP アドレスが直接返されるためです。 そのエントリは、実際にはプライベート DNS ゾーン内の A レコードです。 これについては後で詳しく説明します。

Note

上のような結果になるのは、プライベート エンドポイントが作成された仮想ネットワークに接続されている仮想マシンにおいてだけです。 プライベート エンドポイントが含まれる仮想ネットワークに VM がデプロイされていない場合は、デプロイし、それにリモート接続した後、nslookup コマンド (Windows) または host コマンド (Linux) を実行します。

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

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

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

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

お使いの Azure サブスクリプションには、以下とまったく同じ名前のプライベート DNS ゾーン リソースが必要です。

privatelink.vaultcore.azure.net

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

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

このリソースがない場合は、サブスクリプションで新しいプライベート DNS ゾーン リソースを作成します。 名前は、スペースや追加のドットを使用せずに、正確に privatelink.vaultcore.azure.net にする必要があることに注意してください。 間違った名前を指定した場合、この記事で説明されている名前解決は機能しません。 このリソースを作成する方法の詳細については、「Azure portal を使用して Azure プライベート DNS ゾーンを作成する」を参照してください。 そのページに従っている場合、この時点では既に存在しているはずなので、仮想ネットワークの作成をスキップできます。 また、仮想マシンでの検証手順もスキップできます。

プライベート DNS ゾーンが仮想ネットワークにリンクされていることを確認する

プライベート DNS ゾーンがあるだけでは不十分です。 プライベート エンドポイントが含まれる仮想ネットワークにリンクされている必要もあります。 プライベート DNS ゾーンが正しい仮想ネットワークにリンクされていない場合、その仮想ネットワークからの DNS の解決では、プライベート DNS ゾーンが無視されます。

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

プライベート DNS ゾーンを仮想ネットワークにリンクすると、その仮想ネットワークから発信された DNS 要求で、プライベート DNS ゾーン内の名前が検索されるようになります。 プライベート エンドポイントが作成された仮想ネットワークに接続されている仮想マシンでアドレス解決が正しく実行されるためには、これが必要です。

Note

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

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

ポータルを使用し、privatelink.vaultcore.azure.net という名前のプライベート DNS ゾーンを開きます。 [概要] ページにすべてのレコードが表示されます。 既定では、名前が @ で種類が SOA (Start of Authority) である 1 つのレコードが存在します。 それには触れないでください。

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

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

Note

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

複数の仮想ネットワークに対する DNS の解決

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

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

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

前のセクションで説明したように、プライベート リンクを使用するキー コンテナーには、その "パブリックな" 登録に、{vaultname}.privatelink.vaultcore.azure.net という別名があります。 仮想ネットワークで使用される DNS サーバーにおいては、パブリックな登録が使用されますが、"プライベートな" 登録ですべての別名が確認され、見つかった場合は、パブリックな登録で定義されている以降の別名は停止されます。

このロジックは、仮想ネットワークが privatelink.vaultcore.azure.net という名前のプライベート DNS ゾーンにリンクされていて、そのキー コンテナーに対するパブリック DNS の登録に fabrikam.privatelink.vaultcore.azure.net という別名がある場合 (キー コンテナーのホスト名のサフィックスが、プライベート DNS ゾーンの名前と完全に一致することに注意してください)、DNS クエリによって "プライベート DNS ゾーン内" で fabrikam という名前の Aレコードが検索されることを意味します。 A レコードが見つかった場合、DNS クエリからはその IP アドレスが返され、パブリック DNS の登録に対してそれ以上の参照は実行されません。

このように、名前の解決はユーザーの制御下にあります。 この設計の原理は次のとおりです。

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

キー コンテナーの /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;

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

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

Note

/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 から返される値が異なる場合は、各要求でターゲットになっているエンドポイントが異なります。 どちらのケースに誤りがあり、修正する必要があるかを判断するには、前のセクションの x-ms-keyvault-network-info からの addr フィールドの説明を参照してください。

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

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

仮想ネットワークでカスタム DNS サーバーを診断する

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

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

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

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

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

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

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

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

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