Résoudre les problèmes de réseau virtuel

Cet article fournit des conseils pour résoudre les scénarios courants pour les réseaux virtuels dans Microsoft Power Platform. L’article se concentre sur l’utilisation du module PowerShell Microsoft.PowerPlatform.EnterprisePolicies pour vous aider à identifier et résoudre les problèmes liés aux configurations de réseau virtuel.

Utiliser le module PowerShell de diagnostics

Le Microsoft.PowerPlatform.EnterprisePolicies module PowerShell vous aide à diagnostiquer et résoudre les problèmes liés aux configurations de réseau virtuel dans Power Platform. Vous pouvez utiliser l’outil pour vérifier la connectivité entre votre environnement Power Platform et votre réseau virtuel. Vous pouvez également l’utiliser pour identifier les configurations incorrectes susceptibles de provoquer des problèmes. Le module PowerShell de diagnostics est disponible à partir de PowerShell Gallery et de son dépôt GitHub, PowerPlatform-EnterprisePolicies.

Installez le module

Pour installer le module PowerShell de diagnostics, exécutez la commande PowerShell suivante :

Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies

Exécuter les fonctions de diagnostic

Après avoir installé le module, importez-le dans votre session PowerShell en exécutant la commande suivante :

Import-Module Microsoft.PowerPlatform.EnterprisePolicies

Le module inclut plusieurs fonctions pour diagnostiquer et résoudre les problèmes liés aux configurations de réseau virtuel. Voici quelques-unes des fonctions clés :

• Get-EnvironmentRegion : récupère la région de l’environnement Power Platform spécifié.
• Get-EnvironmentUsage : fournit des informations sur l’utilisation de l’environnement Power Platform spécifié.
• Test-DnsResolution : teste la résolution DNS pour le nom de domaine spécifié.
• Test-NetworkConnectivity : teste la connectivité réseau entre l’environnement Power Platform et la ressource de destination.
• Test-TLSHandshake : teste si une négociation TLS peut être établie entre l’environnement Power Platform et la ressource de destination.

Pour obtenir la liste complète des fonctions disponibles dans le module diagnostics, consultez le module Microsoft.PowerPlatform.EnterprisePolicies.

Signaler des problèmes dans le module diagnostics

Si vous rencontrez des problèmes lors de l’exécution du module de diagnostic, signalez-les via le référentiel GitHub où le module est hébergé. Le référentiel est disponible sur : PowerPlatform-EnterprisePolicies.

Pour signaler un problème, accédez à la section Problèmes du référentiel et ouvrez un nouveau problème. Fournissez des informations détaillées sur le problème que vous rencontrez. Incluez les messages d’erreur ou les entrées de journal qui peuvent vous aider lorsque vous examinez le problème. N’incluez aucune information sensible dans votre rapport.

Résolution des problèmes courants

Un environnement fonctionne, mais un autre ne fonctionne pas

Si tout est correctement configuré, mais que vous rencontrez toujours des problèmes, utilisez la fonction Get-EnvironmentRegion à partir du module PowerShell de diagnostics pour vérifier si les régions de vos environnements Power Platform sont identiques. Exécutez la commande suivante:

Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"

Si les environnements se trouvent dans des régions différentes, et que l’un fonctionne mais que l’autre ne le fait pas, le problème se trouve dans la configuration du réseau virtuel pour la région défaillante. Pour vous assurer que votre configuration complète est correctement configurée, exécutez d’autres commandes de diagnostic sur les deux régions. Pour spécifier une région, incluez le -Region paramètre. Par exemple:

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

Votre environnement appartient à une zone géographique Power Platform spécifique. Toutefois, une région Power Platform peut s’étendre sur deux régions Azure. Votre environnement peut se trouver dans l’une ou l’autre région, et il peut également basculer automatiquement entre eux. Par conséquent, pour garantir la haute disponibilité et la connectivité, vous devez configurer vos réseaux virtuels dans les deux régions Azure associées à votre région Power Platform. Pour savoir comment les régions Power Platform sont mappées aux régions Azure qui prennent en charge la fonctionnalité de réseau virtuel, consultez les régions Power Platform.

Nom d’hôte introuvable

Si vous rencontrez des problèmes qui affectent la résolution du nom d’hôte, utilisez la fonction Test-DnsResolution du module PowerShell de diagnostics pour vérifier si le nom d’hôte est résolu correctement. Exécutez la commande suivante:

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

Cette commande teste la résolution DNS pour le nom d’hôte spécifié dans le contexte de votre environnement Power Platform. La demande démarre à partir de votre sous-réseau délégué et tente de résoudre le nom d’hôte à l’aide du serveur DNS configuré pour votre réseau virtuel. Si le nom d’hôte n’est pas résolu correctement, vous devrez peut-être vérifier vos paramètres DNS pour vous assurer que le nom d’hôte est configuré correctement.

La requête utilise une adresse IP publique au lieu de l’adresse IP privée

Si vous rencontrez des problèmes dans lesquels les demandes adressées à une ressource utilisent une adresse IP publique au lieu de l’adresse IP privée, la résolution DNS du nom d’hôte de ressource peut retourner une adresse IP publique. Ce problème peut affecter les ressources Azure et non-Azure.

Ressource non-Azure sans point de terminaison privé

Si une ressource non-Azure n’a pas de point de terminaison privé, mais que vous pouvez y accéder à partir de votre réseau virtuel, vous devez configurer votre serveur DNS pour résoudre le nom d’hôte de la ressource en son adresse IP privée. Ajoutez un enregistrement DNS A à votre serveur DNS qui mappe le nom d’hôte de la ressource à son adresse IP privée :

• Si vous utilisez un serveur DNS personnalisé, ajoutez l’enregistrement A directement à votre serveur.
• Si vous utilisez un DNS fourni par Azure, créez une zone DNS privée Azure et liez-la à votre réseau virtuel. Ensuite, ajoutez l’enregistrement A à la zone DNS privée.

Ce mappage garantit que vous accédez à la ressource via son adresse IP privée.

Ressource Azure qui a un point de terminaison privé

Si une ressource Azure a un point de terminaison privé, la résolution DNS du nom d’hôte de la ressource doit retourner l’adresse IP privée associée au point de terminaison privé. Si la résolution DNS retourne une adresse IP publique à la place, votre configuration DNS peut manquer d’enregistrements. Suivez ces étapes :

1. Vérifiez qu’une zone DNS privée existe pour votre type de ressource. Par exemple, privatelink.database.windows.net pour Azure SQL Database. Si la zone DNS privée n’existe pas, créez-en une.
2. Vérifiez que la zone DNS privée est liée à votre réseau virtuel. Si la zone DNS privée n’est pas liée à votre réseau virtuel, liez-la.

Après avoir lié la zone DNS privée à votre réseau virtuel, le nom d'hôte de ressource doit se résoudre à l'adresse IP privée liée au point de terminaison privé.

Tester les modifications de configuration DNS

Après avoir mis à jour la configuration DNS, utilisez la fonction Test-DnsResolution à partir du module PowerShell de diagnostics pour vérifier que le nom d’hôte est résolu en l’adresse IP privée correcte. Exécutez la commande suivante:

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

Impossible de se connecter à la ressource

Si vous rencontrez des problèmes qui affectent la connectivité à une ressource, utilisez la fonction Test-NetworkConnectivity à partir du module PowerShell de diagnostics pour vérifier la connectivité. Exécutez la commande suivante:

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

Cette commande tente d’établir une connexion TCP à la destination et au port spécifiés dans le contexte de votre environnement Power Platform. La demande démarre à partir de votre sous-réseau délégué et tente de se connecter à la destination spécifiée à l’aide de la configuration réseau de votre réseau virtuel. Si la connexion échoue, vous devrez peut-être vérifier vos paramètres réseau pour vous assurer que la destination est accessible à partir de votre réseau virtuel. Une connexion réussie indique que la connectivité réseau existe entre l’environnement Power Platform et la ressource spécifiée.

Impossible d’établir un handshake TLS

Certains pare-feu peuvent autoriser l’établissement de connexions TCP, mais ils bloquent ensuite le trafic réel vers la ressource (par exemple, HTTPS). Par conséquent, même si la fonction Test-NetworkConnectivity indique la connectivité réseau, cet état ne garantit pas que la ressource est entièrement accessible.

Utilisez la fonction Test-TLSHandshake pour diagnostiquer pourquoi un handshake ne peut pas être établi. Exécutez la commande suivante:

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

Cette commande retourne des informations qui peuvent vous aider à déboguer pourquoi la négociation a échoué. La sortie inclut le certificat présenté par le serveur, la suite de chiffrement, le protocole et toutes les descriptions d’erreurs SSL.

La connectivité réussit, mais l’application ne fonctionne toujours pas

Si les tests de connectivité réussissent, mais que vous rencontrez toujours des problèmes dans votre application, vérifiez les paramètres et configurations au niveau de l’application :

1. Vérifiez que votre pare-feu autorise l’accès du sous-réseau délégué à la ressource.
2. Vérifiez que le certificat présenté par la ressource est approuvé publiquement.
3. Assurez-vous qu’aucun problème d’authentification ou d’autorisation n’empêche l’accès à la ressource.

Vous ne pouvez peut-être pas diagnostiquer ou résoudre le problème à l’aide du module PowerShell de diagnostics. Dans ce cas, créez un sous-réseau sans délégation dans votre réseau virtuel et déployez une machine virtuelle dans ce sous-réseau. Ensuite, vous pouvez utiliser la machine virtuelle pour effectuer d’autres étapes de diagnostic et de résolution des problèmes, telles que la vérification du trafic réseau, l’analyse des journaux et le test de la connectivité au niveau de l’application.

Exemples de scénarios de résolution des problèmes

Rencontrez Contoso LLC, une entreprise multi-nationale qui a plusieurs environnements Power Platform dans toute l’Europe et des réseaux virtuels en Europe Ouest et Europe Nord. Chaque réseau virtuel a un sous-réseau délégué à Power Platform. Chaque sous-réseau est associé à une stratégie d’entreprise liée à l’environnement Power Platform.

Les scénarios suivants montrent comment Contoso utilise les applets de commande de diagnostic fournies dans les sections précédentes pour résoudre les problèmes de connectivité qui affectent cette configuration.

Se connecter à un coffre de clés Azure via un point de terminaison privé

Contoso souhaite que ses environnements Power Platform se connectent à son coffre de clés via le réseau virtuel et configure le coffre de clés pour rejeter les demandes provenant de l’Internet public. Lorsque Contoso tente de se connecter au coffre de clés depuis son environnement, la connexion est rejetée car les requêtes ne sont pas acheminées correctement. Pour diagnostiquer le problème, Contoso utilise les étapes de résolution des problèmes suivantes.

Tout d’abord, il exécute Get-EnvironmentRegion pour vérifier les demandes de sous-réseau envoyées à :

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

La région retournée identifie le réseau virtuel à examiner. Par exemple, si la commande retourne Europe Ouest, Contoso doit se concentrer sur la résolution des problèmes sur le réseau virtuel Europe Ouest.

Ensuite, Contoso vérifie que l’adresse IP retournée par la résolution DNS du nom de domaine entièrement qualifié du coffre de clés est une adresse IP privée. Étant donné que l’entreprise dispose d’environnements dans les deux régions, elle doit tester la résolution DNS pour chaque région à l’aide de Test-DnsResolution :

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"

Si la résolution DNS retourne une adresse IP publique au lieu d’une adresse IP privée, le point de terminaison privé du coffre de clés peut ne pas être configuré correctement. Contoso doit vérifier que :

1. Un point de terminaison privé existe pour le Key Vault, et il est associé au réseau virtuel approprié.
2. Une zone DNS privée existe pour le coffre de clés (par exemple), privatelink.vaultcore.azure.netet elle est liée au réseau virtuel.
3. La zone DNS privée contient un enregistrement A qui associe le nom d’hôte du coffre de clés à l’adresse IP privée du point de terminaison privé.

Lorsque Contoso exécute le test de résolution DNS pour l’Europe Ouest, l’entreprise découvre que la commande retourne une adresse IP publique. Après que l’entreprise a mené l’enquête, elle constate que la zone DNS privée pour le coffre-fort de clés n’a pas été liée au réseau virtuel de l’Europe de l’Ouest. Une fois que Contoso lie la zone DNS privée au réseau virtuel et réexécute le test, la résolution DNS retourne l’adresse IP privée correcte.

Une fois que la résolution DNS renvoie l’adresse IP privée correcte dans les deux régions, l’étape suivante consiste à tester la connectivité réseau vers le coffre de clés à l'aide de 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"

Si la connexion échoue, les règles de groupe de sécurité réseau (NSG) ou les paramètres de pare-feu peuvent bloquer le trafic du sous-réseau délégué vers le coffre de clés. Contoso doit vérifier si :

1. Les règles de groupe de sécurité réseau associées au sous-réseau délégué autorisent le trafic sortant sur le port 443.
2. Le pare-feu key vault autorise les connexions entrantes à partir de la plage d’adresses IP du sous-réseau délégué.
3. Tout pare-feu Azure ou appliance virtuelle de réseau sur le chemin du trafic autorise la connexion.

Dans ce cas, Contoso constate que le pare-feu du coffre de clés n’a pas été configuré pour autoriser les connexions entrantes à partir d’une source privée. Une fois les paramètres de pare-feu mis à jour pour autoriser les connexions à partir du sous-réseau délégué, le test de connectivité réseau réussit et l’environnement Power Platform peut se connecter au coffre de clés via le réseau virtuel.

Se connecter à un serveur web hébergé dans un réseau local

Contoso souhaite également que son environnement Power Platform se connecte à un serveur web hébergé dans son réseau local. Le serveur web est accessible via le réseau virtuel de l’entreprise via une connexion ExpressRoute . Lorsque Contoso tente de se connecter au serveur web à partir de son environnement Power Platform, la connexion échoue.

Même si la résolution DNS retourne l’adresse IP correcte et que le test de connectivité réseau réussit, Contoso ne peut toujours pas accéder au serveur web. Pour diagnostiquer ce problème, l'entreprise teste la négociation TLS à l’aide de Test-TLSHandshake :

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

Si la négociation TLS échoue, le résultat fournit des détails sur le certificat, la suite de chiffrement et le protocole utilisés. Contoso peut utiliser ces informations pour identifier les problèmes de configuration de certificat ou TLS. La commande effectue une analyse initiale de la sortie retournée et émet des alertes sur certains problèmes de base. Toutefois, Contoso peut analyser la sortie complète pour examiner le problème plus en détail.

Dans ce cas, Contoso découvre que le handshake TLS ne peut pas être établi car le certificat n’est pas de confiance. Une fois que l’entreprise examine les détails du certificat dans la sortie de commande, il détermine que le serveur web utilise un certificat auto-signé. Power Platform nécessite des certificats approuvés publiquement pour les connexions TLS. Une fois que Contoso met à jour le serveur web pour utiliser un certificat signé par une autorité de certification approuvée publiquement, la négociation TLS réussit et l’environnement Power Platform peut se connecter au serveur web.

Pour plus d’informations sur les autorités de certification approuvées par les services Azure, consultez les détails de l’autorité de certification Azure.