Diagnostiquer les problèmes de configuration des liaisons privées sur Azure Key Vault

Présentation

Cet article aide les utilisateurs à diagnostiquer et à résoudre les problèmes impliquant Key Vault et la fonctionnalité Liaisons privées. Ce guide vous aide sur les aspects de la configuration, tels que la première obtention de liaisons privées ou la résolution d’une situation dans laquelle des liaisons privées cessent de fonctionner en raison d’une modification.

Si vous débutez avec cette fonctionnalité, consultez Integrate Key Vault avec Azure Private Link.

Problèmes traités dans cet article

• Vos requêtes DNS renvoient toujours une adresse IP publique pour le coffre de clés au lieu d’une adresse IP privée que vous attendez de l’utilisation de la fonctionnalité de liaisons privées.
• Toutes les demandes effectuées par un client donné qui utilise une liaison privée échouent avec des délais d’expiration ou des erreurs réseau, et le problème n’est pas intermittent.
• Le coffre de clés a une adresse IP privée, mais les requêtes reçoivent toujours une réponse 403 avec le code d’erreur interne ForbiddenByFirewall.
• Vous utilisez des liaisons privées, mais votre coffre de clés accepte toujours des requêtes provenant de l’Internet public.
• Votre coffre de clés a deux points de terminaison privés. Les requêtes qui en utilisent un fonctionnent correctement, mais les requêtes qui utilisent l’autre échouent.
• Vous disposez d’un autre abonnement, d’un coffre de clés ou d’un réseau virtuel qui utilise des liaisons privées. Vous souhaitez effectuer un nouveau déploiement similaire, mais vous ne parvenez pas à obtenir de liaisons privées pour l’utiliser.

Problèmes NON traités dans cet article

• Il y a un problème de connectivité intermittente. Dans un client donné, vous constatez que certaines requêtes fonctionnent et que d’autres non. Les problèmes intermittents sont rarement causés par un problème dans la configuration des liaisons privées ; il s’agit d’un signe de surcharge réseau ou client.
• Vous utilisez un produit Azure qui prend en charge BYOK (Bring Your Own Key), CMK (Clés gérées par le client) ou l’accès aux secrets stockés dans le coffre de clés. Lorsque vous activez le pare-feu dans les paramètres du coffre de clés, ce produit ne peut pas accéder à votre coffre de clés. Consultez la documentation spécifique au produit. Assurez-vous qu’il prend explicitement en charge les coffres de clés avec le pare-feu activé. Contactez le support pour ce produit spécifique si nécessaire.

Lecture de cet article

Si vous débutez avec des liens privés ou si vous évaluez un déploiement complexe, il est recommandé de lire l’intégralité de l’article. Sinon, n’hésitez pas à choisir la section la plus appropriée au problème que vous rencontrez.

Commençons !

1. Confirmer que vous êtes propriétaire de la connexion cliente

Confirmer que votre client s’exécute sur le réseau virtuel

Ce guide est conçu pour vous aider à résoudre les connexions au coffre de clés qui proviennent du code d’application. Par exemple, les applications et les scripts qui s’exécutent dans des Machines virtuelles Azure, des clusters Azure Service Fabric, des Azure App Service, des Azure Kubernetes Service (AKS) et d’autres types similaires. Ce guide s’applique également aux accès effectués dans l’interface utilisateur de base web du portail Azure, où le navigateur accède directement à votre coffre de clés.

Par définition de liens privés, l’application, le script ou le portail doivent s’exécuter sur l’ordinateur, le cluster ou l’environnement connecté au Réseau virtuel où la ressource de point de terminaison Private Endpoint a été déployée.

Si l’application, le script ou le portail s’exécute sur un réseau arbitraire connecté à Internet, ce guide n’est PAS applicable et il est probable que des liaisons privées ne puissent pas être utilisées. Cette limitation s’applique également aux commandes exécutées dans le Azure Cloud Shell, car elles s’exécutent sur un ordinateur Azure distant fourni à la demande au lieu du navigateur utilisateur.

Si vous utilisez une solution managée, reportez-vous à la documentation correspondante

Les services de Azure managés nécessitent une configuration différente

Ce guide ne s’applique pas aux services gérés par Microsoft qui accèdent à votre Key Vault en dehors de votre Réseau virtuel. Il s’agit entre autres des scénarios suivants :

• stockage Azure configuré avec le chiffrement au repos
• Azure SQL à l’aide de clés gérées par le client
• Azure Event Hubs chiffrant des données avec vos clés
• Azure Data Factory accéder aux informations d’identification stockées dans Key Vault
• Azure Pipelines accédant aux secrets stockés dans Key Vault

Pour ces scénarios, vous devez vérifier si le service de Azure spécifique prend en charge l’accès aux coffres de clés avec les pare-feu activés. De nombreux services utilisent la fonctionnalité Trusted Services pour accéder en toute sécurité à votre Key Vault malgré les restrictions de pare-feu. Toutefois, tous les services Azure n’apparaissent pas dans la liste des services approuvés en raison de diverses raisons architecturales.

Si vous rencontrez des problèmes avec un service de Azure spécifique accédant à votre Key Vault, consultez la documentation de ce service ou contactez son équipe de support technique pour obtenir des conseils spécifiques.

Quelques produits Azure prennent en charge le concept d’injection de vnet. En termes simples, le produit ajoute un appareil réseau au client Réseau virtuel, ce qui lui permet d’envoyer des demandes comme s’il a été déployé sur le Réseau virtuel. Un exemple notable est Azure Databricks. Les produits comme celui-ci peuvent effectuer des requêtes auprès du coffre de clés à l’aide des liaisons privées, et ce guide de résolution des problèmes peut être utile.

2. Confirmer que la connexion est approuvée et réussie

Les étapes suivantes permettent de confirmer que la connexion au point de terminaison privé est approuvée et réussie :

1. Ouvrez le portail Azure et ouvrez votre ressource key vault.
2. Dans le menu de gauche, sélectionnez Mise en réseau.
3. Sélectionnez l’onglet Connexions de point de terminaison privé pour afficher toutes les connexions de point de terminaison privé et leurs états respectifs. S’il n’existe aucune connexion ou si la connexion de votre Réseau virtuel est manquante, vous devez créer un point de terminaison privé. Ce sujet sera abordé ultérieurement.
4. Toujours dans Connexions de point de terminaison privé, recherchez celle que vous diagnostiquez et confirmez que « État de la connexion » est Approuvé et que « État de l’approvisionnement » est Réussi.
   • Si la connexion est à l’état « En attente », vous pouvez simplement l’approuver.
   • Si la connexion est à l’état « Rejeté », « Échec », « Erreur », « Déconnecté » ou un autre état, cela signifie qu’elle n’est pas effective et vous devez créer une nouvelle ressource de point de terminaison privé.

Il est préférable de supprimer les connexions inefficaces pour maintenir l'ordre.

3. Confirmer que le pare-feu du coffre de clés est correctement configuré

Il est important de noter que la fonctionnalité de liaisons privées donne uniquement l’accès à votre coffre de clés dans un réseau virtuel fermé pour empêcher l’exfiltration des données. Elle ne supprime aucun accès existant. Pour bloquer efficacement les accès depuis l’Internet public, vous devez activer explicitement le pare-feu du coffre de clés :

1. Ouvrez le portail Azure et ouvrez votre ressource key vault.
2. Dans le menu de gauche, sélectionnez Mise en réseau.
3. Assurez-vous que l’onglet Pare-feux et réseaux virtuels est sélectionné en haut.
4. Si Autoriser l’accès public à partir de tous les réseaux est sélectionné, cela explique pourquoi des clients externes sont toujours en mesure d’accéder au coffre de clés. Si vous souhaitez que le Key Vault soit accessible uniquement sur Private Link, sélectionnez Disable Public Access.

Les considérations suivantes s’appliquent également aux paramètres du pare-feu :

• La fonctionnalité de liaisons privées ne requiert pas nécessairement de spécifier un « réseau virtuel » dans les paramètres du pare-feu du coffre de clés. Toutes les requêtes qui utilisent l’adresse IP privée du coffre de clés (voir la section suivante) doivent fonctionner, même si aucun réseau virtuel n’est spécifié dans les paramètres du pare-feu du coffre de clés.
• La fonctionnalité de liaisons privées ne requiert pas nécessairement de spécifier une adresse IP dans les paramètres du pare-feu du coffre de clés. Là encore, toutes les requêtes qui utilisent l’adresse IP privée du coffre de clés doivent fonctionner, même si aucune adresse IP n’a été spécifiée dans les paramètres du pare-feu.

Si vous utilisez des liaisons privées, les seules motivations pour spécifier un réseau virtuel ou une adresse IP dans le pare-feu de coffre de clés sont les suivantes :

• Vous disposez d’un système hybride où certains clients utilisent des liaisons privées, certains utilisent des points de terminaison de service, certaines utilisent une adresse IP publique.
• Vous effectuez la transition vers des liaisons privées. Dans ce cas, une fois que vous avez confirmé que tous les clients utilisent des liaisons privées, vous devez supprimer les réseaux virtuels et les adresses IP des paramètres du pare-feu du coffre de clés.

4. Vérifier que le coffre de clés a une adresse IP privée

Différence entre adresses IP privées et publiques

Une adresse IP privée se présente toujours dans l’un des formats suivants :

• 10.x.x.x : Exemples : 10.1.2.3, 10.56.34.12.
• 172.16.x.x à 172.32.x.x : Exemples : 172.20.1.1, 172.31.67.89.
• 192.168.x.x : Exemples : 192.168.0.1, 192.168.100.7

Certaines adresses IP et plages sont réservées :

• 224.x.x.x : Multicast
• 255.255.255.255 : Diffusion
• 127.x.x.x : Loopback
• 169.254.x.x : Link-local
• 168.63.129.16 : DNS interne

Toutes les autres adresses IP sont publiques.

Lorsque vous parcourez le portail ou que vous exécutez une commande qui affiche l’adresse IP, assurez-vous de pouvoir déterminer si cette adresse IP est privée, publique ou réservée. Pour que les liens privés fonctionnent, le nom d’hôte du coffre de clés doit être résolu en une adresse IP privée appartenant à l’espace d’adressage du réseau virtuel.

Rechercher l’adresse IP privée du coffre de clés dans le réseau virtuel

Vous devez diagnostiquer la résolution du nom d’hôte. Pour cela, vous devez connaître l’adresse IP privée exacte de votre coffre de clés avec les liaisons privées activées. Pour trouver cette adresse, procédez comme suit :

1. Ouvrez le portail Azure et ouvrez votre ressource key vault.
2. Dans le menu de gauche, sélectionnez Mise en réseau.
3. Sélectionnez l’onglet Connexions de point de terminaison privé . La vue obtenue affiche toutes les connexions de point de terminaison privé et leurs états respectifs.
4. Recherchez la connexion que vous diagnostiquez et vérifiez que l’état « État de connexion » est approuvé et que l’état d’approvisionnement est Réussi. Si l’état diffère, revenez aux sections précédentes du document.
5. Lorsque vous trouvez l’élément approprié, sélectionnez le lien dans la colonne point de terminaison privé. L’action ouvre la ressource de point de terminaison privé.
6. La page Vue d’ensemble peut afficher une section appelée Paramètres DNS personnalisés. Vérifiez qu’une seule entrée correspond au nom d’hôte du coffre de clés. Cette entrée indique l’adresse IP privée de Key Vault.
7. Vous pouvez également sélectionner le lien à l’interface réseau et confirmer que l’adresse IP privée est la même affichée à l’étape précédente. L’interface réseau est un appareil virtuel qui représente le coffre de clés.

L’adresse IP est celle que les machines virtuelles et d’autres appareils fonctionnant dans le même réseau virtuel utilisent pour se connecter au coffre de clés. Notez l’adresse IP ou conservez l’onglet du navigateur ouvert et ne le touchez pas pendant les recherches ultérieures.

5. Valider la résolution DNS

La résolution DNS est le processus de traduction du nom d’hôte du coffre de clés (exemple : fabrikam.vault.azure.net) en adresse IP (exemple : 10.1.2.3). Les sous-sections suivantes montrent les résultats de résolution DNS attendus dans chaque scénario.

Coffres de clés sans liaison privée

Cette section est conçue à des fins d’apprentissage. Lorsque le coffre de clés n’a pas de connexion de point de terminaison privé à l’état Approuvé, la résolution du nom d’hôte donne un résultat similaire à celui-ci :

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

Vous pouvez voir que le nom est résolu en une adresse IP publique et qu’il n’y a pas d’alias privatelink. L’alias sera expliqué ultérieurement, ne vous en souciez pas pour le moment.

Ce résultat s'affiche de la même façon que vous exécutez la requête à partir d'un ordinateur connecté au Réseau virtuel ou à partir d'un ordinateur disposant d'une connexion Internet. Le résultat se produit car le coffre de clés n’a pas de connexion de point de terminaison privé à l’état Approuvé. Le coffre de clés n’a donc pas besoin de prendre en charge les liaisons privées.

Coffre de clés avec résolution de liaison privée à partir d’un ordinateur Internet arbitraire

Lorsqu’un Key Vault dispose d’une ou plusieurs connexions via un point de terminaison privé en état approuvé, et que le nom d’hôte est résolu depuis une machine quelconque connectée à Internet, c’est-à-dire hors du réseau virtuel hébergeant ce point de terminaison, le résultat obtenu est similaire à celui-ci XXX :

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

La différence notable par rapport au scénario précédent est qu’il existe un nouvel alias avec la valeur {vaultname}.privatelink.vaultcore.azure.net. Le plan de données du coffre de clés est prêt à accepter les demandes des liaisons privées.

Cela ne signifie pas que les requêtes effectuées à partir de machines en dehors du Réseau Virtuel (comme celle que vous venez d'utiliser) utilisent des liens privés - elles ne le font pas. Vous pouvez le constater car le nom d’hôte est toujours résolu en adresse IP publique. Seules les machines connectées au Réseau virtuel peuvent utiliser des liens privés.

Si vous ne voyez pas l’alias privatelink, cela signifie que le coffre de clés n’a aucune connexion de point de terminaison privé à l’état Approved. Revenez à cette section avant de réessayer.

Coffre de clés avec résolution de liaison privée à partir d’un réseau virtuel

Lorsque le coffre de clés a une ou plusieurs connexions de point de terminaison privé à l’état Approuvé et que vous résolvez le nom d’hôte à partir d’un ordinateur connecté au réseau virtuel sur lequel le point de terminaison privé a été créé, la réponse attendue est la suivante :

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

Deux différences notables sont à noter. Premièrement, le nom est résolu en adresse IP privée. Il doit s’agir de l’adresse IP que nous avons trouvée dans la section correspondante de cet article. Deuxièmement, il n’y a pas d’autres alias après privatelink. Cela se produit parce que les serveurs DNS Réseau virtuel interceptent la chaîne d’alias et retournent l’adresse IP privée directement à partir du nom fabrikam.privatelink.vaultcore.azure.net. Cette entrée est en fait un enregistrement A dans une zone de DNS privé.

Si vous exécutez ces commandes sur une machine virtuelle connectée au Réseau Virtuel où le point de terminaison privé a été créé, et qu'elles n'affichent pas l’adresse IP privée du Key Vault, la section suivante peut vous aider à résoudre le problème.

6. Valider la zone DNS privé

Si la résolution DNS ne fonctionne pas comme décrit dans la section précédente, il peut y avoir un problème avec votre zone DNS privé et cette section peut vous aider. Si la résolution DNS affiche l’adresse IP privée du Key Vault correcte, votre zone DNS privée est probablement correcte. Vous pouvez ignorer toute cette section.

Vérifiez que la ressource de zone DNS privé requise existe

Votre abonnement Azure doit avoir une ressource DNS privé Zone avec ce nom exact :

privatelink.vaultcore.azure.net

Vous pouvez vérifier la présence de cette ressource en accédant à la page de l’abonnement dans le portail et en sélectionnant « Ressources » dans le menu de gauche. Le nom de la ressource doit être privatelink.vaultcore.azure.net, et le type de ressource doit être DNS privé zone.

Cette ressource est normalement créée automatiquement lorsque vous créez un point de terminaison privé à l’aide d’une procédure courante. Toutefois, dans certains cas, cette ressource n’est pas créée automatiquement et vous devez le faire manuellement. Cette ressource peut également avoir été supprimée par accident.

Si vous n'avez pas cette ressource, créez une ressource de zone DNS privé dans votre abonnement. N’oubliez pas que le nom doit être exactement privatelink.vaultcore.azure.net, sans espaces ou points supplémentaires. Si vous spécifiez le nom incorrect, la résolution de noms expliquée dans cet article échoue. Pour plus d’informations sur la création de cette ressource, consultez Créer une zone DNS privée Azure à l’aide du portail Azure. Si vous suivez cette page, vous pouvez ignorer la création de Réseau Virtuel, car à ce stade, vous devriez déjà en avoir un. Vous pouvez également ignorer les procédures de validation avec Machines Virtuelles.

Vérifiez que la zone DNS privé est liée au Réseau virtuel

Il n’est pas suffisant d’avoir une zone DNS privé. Elle doit également être liée au Réseau virtuel qui contient le point de terminaison privé. Si la zone DNS privé n’est pas liée à la Réseau virtuel correcte, toute résolution DNS de cette Réseau virtuel ignore la zone de DNS privé.

Ouvrez la ressource zone DNS privé et sélectionnez l’option Liens réseau virtuels dans le menu de gauche. Vous voyez une liste de liens, chacun portant le nom d’un Réseau virtuel dans votre abonnement. Les Réseau virtuel qui contiennent la ressource de point de terminaison privé doivent être répertoriées ici. Si ce n’est pas le cas, ajoutez-le. Pour connaître la procédure détaillée, consultez Lier le réseau virtuel. Vous pouvez laisser l’option « Activer l’inscription automatique » décochée, car cette fonctionnalité n’est pas liée aux liaisons privées.

Une fois la zone DNS privé liée au Réseau virtuel, toutes les requêtes DNS provenant de ce réseau vérifient automatiquement cette zone privée pour la résolution de noms. Cette association est indispensable afin que les machines virtuelles situées dans le même réseau virtuel que le point de terminaison privé puissent résoudre correctement le nom d’hôte du Key Vault vers son adresse IP privée, plutôt que vers son adresse publique.

Vérifiez que la zone DNS privé contient l’enregistrement A approprié

À l’aide du portail, ouvrez la zone DNS privé avec le nom privatelink.vaultcore.azure.net. La page Vue d’ensemble affiche tous les enregistrements. Par défaut, il existe un enregistrement portant le nom @ et le type SOA, ce qui signifie début d'autorité. N’y touchez pas.

Pour que la résolution de noms du coffre de clés fonctionne, il doit exister un enregistrement A avec le nom du coffre simple sans suffixe ni points. Par exemple, si le nom d’hôte est fabrikam.vault.azure.net, il doit exister un enregistrement A portant le nom fabrikam, sans suffixe ni points.

De même, la valeur de l’enregistrement A (adresse IP) doit être l’adresse IP privée du coffre de clés. Si vous trouvez l’enregistrement A mais qu’il contient une adresse IP incorrecte, vous devez supprimer l’adresse IP incorrecte et en ajouter une nouvelle. Il est recommandé de supprimer l’enregistrement entier A et d’en ajouter un nouveau.

Résolution DNS pour plusieurs Réseau virtuel

S’il existe plusieurs réseaux virtuels et que chacun possède sa propre ressource de point de terminaison privé référençant le même coffre de clés, le nom d’hôte du coffre de clés doit être résolu en une adresse IP privée différente en fonction du réseau. Cela signifie que plusieurs zones DNS privées sont également nécessaires, chacune étant liée à un réseau virtuel différent et utilisant une adresse IP différente dans l’enregistrement A.

Dans des scénarios plus avancés, le Peering est peut-être activé dans les réseaux virtuels. Dans ce cas, une seule Réseau virtuel a besoin de la ressource de point de terminaison privé, bien que les deux puissent être liées à la ressource zone DNS privé. Ce scénario n’est pas directement traité dans ce document.

Comprendre que vous contrôlez la résolution DNS

Comme expliqué dans la section précédente, un coffre de clés avec des liaisons privées a l’alias {vaultname}.privatelink.vaultcore.azure.net dans son inscription publique. Le serveur DNS utilisé par le réseau virtuel utilise l’enregistrement public, mais il vérifie chaque alias pour un enregistrement privé, et s’il en trouve un, il arrête de suivre les alias définis lors de l’enregistrement public.

Cette logique signifie que si le Réseau virtuel est lié à une zone de DNS privé avec le nom privatelink.vaultcore.azure.net, et l’inscription DNS publique pour le coffre de clés a l’alias fabrikam.privatelink.vaultcore.azure.net (notez que le suffixe du nom d’hôte du coffre de clés correspond exactement au nom de zone DNS privé), puis la requête DNS recherche un enregistrement A avec le nom fabrikamin le zone DNS privé. Si l’enregistrement A est trouvé, son adresse IP est retournée dans la requête DNS et aucune recherche supplémentaire n’est effectuée lors de l’inscription DNS publique.

Comme vous pouvez le constater, vous contrôlez la résolution de noms. La logique de cette conception est la suivante :

• Vous pouvez avoir un scénario complexe qui implique des serveurs DNS personnalisés et une intégration aux réseaux locaux. Dans ce cas, vous devez contrôler comment les noms sont traduits en adresses IP.
• Vous devrez peut-être accéder à un coffre de clés sans liaisons privées. Dans ce scénario, la résolution du nom d’hôte depuis le réseau virtuel doit retourner l’adresse IP publique, puisque les Key Vault dépourvus de liaisons privées ne possèdent pas d’alias privatelink dans l’enregistrement de nom.

7. Vérifier que les requêtes envoyées au coffre de clés utilisent une liaison privée

Interroger le point de terminaison /healthstatus du coffre de clés

Votre coffre de clés fournit le point de terminaison /healthstatus, qui peut être utilisé pour les diagnostics. Les en-têtes de réponse incluent l’adresse IP d’origine, telle qu’elle est vue par le service de coffre de clés. Vous pouvez appeler ce point de terminaison à l’aide de la commande suivante (n’oubliez pas d’utiliser le nom d’hôte de votre coffre de clés) :

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 ou une version récente de Windows 10 qui inclut curl :

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

Si vous n’obtenez pas une sortie similaire à celle-ci, ou si vous obtenez une erreur réseau, cela signifie que votre coffre de clés n’est pas accessible via le nom d’hôte que vous avez spécifié (fabrikam.vault.azure.net dans l’exemple). Soit le nom d’hôte ne résout pas à l'adresse IP correcte, soit vous rencontrez un problème de connectivité au niveau de la couche de transport. Cela peut être dû à des problèmes de routage, à des suppressions de packages et à d’autres raisons. Vous devez approfondir vos investigations.

La réponse doit inclure un en-tête x-ms-keyvault-network-info :

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

Le champ addr dans l’en-tête x-ms-keyvault-network-info indique l’adresse IP de l’origine de la requête. Cette adresse IP peut être l’une des suivantes :

• L’adresse IP privée de l’ordinateur formulant la requête. Cela indique que la requête utilise des liaisons privées ou des points de terminaison de service. Il s’agit du résultat attendus pour les liaisons privées.
• Une autre adresse IP privée ne provenant pas de l’ordinateur formulant la requête. Cela indique qu’un routage personnalisé s’applique. Cela indique toujours que la requête utilise des liaisons privées ou des points de terminaison de service.
• Une adresse IP publique. Cela indique que la requête est acheminée vers Internet via une passerelle (NAT). Cela indique que la requête n’utilise PAS de liaisons privées et qu’un problème doit être résolu. Les raisons les plus courantes sont que 1) le point de terminaison privé n’est pas à l’état approuvé et réussi ; et que 2) le nom d’hôte n’est pas résolu en l’adresse IP privée du coffre de clés. Cet article comprend des actions de résolution des problèmes pour les deux cas.

Interroger directement l’adresse IP du coffre de clés

Si vous avez installé une version récente de PowerShell, vous pouvez utiliser -SkipCertificateCheck pour ignorer les vérifications de certificat HTTPS, puis cibler directement l’adresse IP du coffre de clés :

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

Si vous utilisez curl, vous pouvez faire de même avec l’argument -k :

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

Les réponses doivent être identiques à celles de la section précédente, ce qui signifie qu’elles doivent inclure l’en-tête x-ms-keyvault-network-info avec la même valeur. Le point de terminaison /healthstatus ne se soucie pas de savoir si vous utilisez le nom d’hôte ou l’adresse IP du coffre de clés.

Si vous constatez que x-ms-keyvault-network-info retourne une valeur pour la requête utilisant le nom d’hôte du coffre de clés et une autre valeur pour la requête utilisant l’adresse IP, cela signifie que chaque requête cible un point de terminaison différent. Reportez-vous à l’explication du champ addr de x-ms-keyvault-network-info dans la section précédente pour déterminer quel cas est incorrect et doit être corrigé.

8. Autres modifications et personnalisations ayant un impact

Les éléments suivants sont des actions d’investigation non exhaustives. Ils vous indiquent où rechercher d’autres problèmes, mais vous devez avoir une connaissance approfondie du réseau pour résoudre les problèmes dans ces scénarios.

Diagnostiquer des serveurs DNS personnalisés à Réseau virtuel

Dans le portail, ouvrez la ressource Réseau virtuel. Dans le menu de gauche, ouvrez Serveurs DNS. Si vous utilisez « Personnalisé », la résolution DNS peut ne pas être la même que celle décrite dans ce document. Vous devez diagnostiquer la manière dont vos serveurs DNS résolvent le nom d’hôte du coffre de clés.

Si vous utilisez les serveurs DNS fournis par défaut Azure, cet ensemble de ce document s’applique.

Diagnostiquer le remplacement d’hôtes ou les serveurs DNS personnalisés sur la machine virtuelle

De nombreux systèmes d’exploitation autorisent la définition d’une adresse IP fixe explicite par nom d’hôte, généralement en modifiant le fichier hosts. Ils peuvent également autoriser le remplacement des serveurs DNS. Si vous utilisez l’un de ces scénarios, passez aux options de diagnostic spécifiques au système.

Proxies de proximité (Fiddler, etc.)

Sauf mention contraire, les options de diagnostic dans cet article ne fonctionnent que si aucun proxy de proximité n’est présent dans l’environnement. Bien que ces proxies soient souvent installés exclusivement dans l’ordinateur faisant l’objet d’un diagnostic (Fiddler en est l’exemple le plus courant), les administrateurs avancés peuvent remplacer les autorités de certification (CA) racine et installer un proxy de proximité dans les périphériques de passerelle qui servent plusieurs ordinateurs du réseau. Ces proxies peuvent avoir un impact considérable sur la sécurité et la fiabilité. Microsoft ne prend pas en charge les configurations qui utilisent ces produits.

Autres éléments susceptibles d’affecter la connectivité

Il s’agit d’une liste non exhaustive d’éléments qui peuvent être présents dans des scénarios avancés ou complexes :

• Paramètres de pare-feu, Pare-feu Azure connectés au Réseau virtuel, ou une solution de pare-feu personnalisée déployée dans le Réseau virtuel ou sur la machine.
• Peering de réseau, qui peut avoir un impact sur les serveurs DNS utilisés et sur la façon dont le trafic est acheminé.
• Des solutions de passerelle (NAT) personnalisées, qui peuvent avoir un impact sur la façon dont le trafic est acheminé, notamment le trafic provenant de requêtes DNS.

Étapes suivantes

• Integrate Key Vault avec Azure Private Link
• Configurer la sécurité réseau pour Azure Key Vault
• Secure your Azure Key Vault