Diagnostiquer un problème de filtre de trafic réseau sur une machine virtuelle

Dans cet article, vous allez apprendre à diagnostiquer les problèmes de filtre de trafic réseau pour une machine virtuelle. Le processus implique l’affichage des règles de sécurité effectives appliquées par le groupe de sécurité réseau (NSG).

Les groupes de sécurité réseau vous permettent de contrôler les types de trafic entrant et sortant d’une machine virtuelle. Vous pouvez associer un groupe de sécurité réseau à un sous-réseau dans un réseau virtuel Azure, une interface réseau attachée à une machine virtuelle, ou les deux. Les règles de sécurité effectives appliquées à une interface réseau sont une agrégation des règles qui existent dans un NSG associé à l’interface réseau, et de celles du sous-réseau dans lequel se trouve l’interface réseau. Les règles dans différents groupes de sécurité réseau peuvent parfois entrer en conflit entre elles et affecter la connectivité réseau d’une machine virtuelle. Vous pouvez afficher toutes les règles de sécurité effectives issues des groupes de sécurité réseau (NSG) appliqués aux interfaces réseau de votre machine virtuelle. Si vous n’êtes pas familier avec les concepts de groupe de sécurité réseau, d’interface réseau ou de réseau virtuel, consultez Vue d’ensemble du réseau virtuel, Interface réseau, et Vue d’ensemble des groupes de sécurité réseau.

Scénario

Vous essayez de vous connecter à une machine virtuelle via le port 80 à partir d’internet, mais la connexion échoue. Pour déterminer la raison pour laquelle le port 80 n’est pas accessible à partir d’internet, vous pouvez afficher les règles de sécurité effectives pour une interface réseau à l’aide du portail Azure, de PowerShell, ou de Azure CLI.

Les étapes qui suivent supposent que vous avez une machine virtuelle existante dont les règles de sécurité efficace peuvent être affichées. Si vous ne possédez pas une telle machine, commencez par déployer une machine virtuelle Linux ou Windows pour pouvoir accomplir les tâches de cet article. Les exemples contenus dans cet article sont prévus pour une machine virtuelle nommée myVM, avec une interface réseau nommée myVMVMNic. La machine virtuelle et l’interface réseau se trouvent dans un groupe de ressources nommé myResourceGroup, et se situent dans la région USA Est. Modifiez les valeurs dans les étapes, le cas échéant, pour la machine virtuelle pour laquelle vous diagnostiquez le problème.

Diagnostiquer à l’aide du portail Azure

Connectez-vous au portail Azure avec un compte Azure disposant des autorisations nécessaires.
En haut du portail Azure, entrez le nom de la machine virtuelle dans la zone de recherche. Quand le nom de cette machine virtuelle apparaît dans les résultats de la recherche, sélectionnez-le.
Développez Mise en réseau dans le volet gauche. Sélectionnez Paramètres réseau. Les illustrations suivantes montrent les paramètres du groupe de sécurité réseau pour l’interface réseau de la machine virtuelle.

Les règles que vous voyez dans les figures précédentes concernent une interface réseau nommée vm-1445. Vous voyez qu’il existe des Règles de port entrant pour l’interface réseau en provenance de deux groupes de sécurité réseau différents :
- NSG-subnet : Associé au sous-réseau dans lequel se trouve l’interface réseau.
- NSG-NIC : Associé à l’interface réseau dans la VM nommée vm-1445.
La règle nommée DenyAllInBound est celle qui empêche les communications entrantes vers la machine virtuelle via le port 80 à partir d’internet, comme décrit dans le scénario. La règle liste 0.0.0.0/0 pour SOURCE, ce qui inclut l’internet. Aucune autre règle avec une priorité plus élevée (numéro inférieur) ne permet de trafic entrant par le port 80. Pour autoriser le trafic entrant par le port 80 vers la machine virtuelle à partir d’internet, consultez Résoudre un problème. Pour plus d’informations sur les règles de sécurité et de quelle façon Azure les applique, consultez Groupes de sécurité réseau Azure.

Au bas de l’image, vous voyez également les Règles de port sortant. Les règles de port sortant pour l’interface réseau sont répertoriées.

Bien que l’image montre uniquement quatre règles de trafic entrant pour chaque groupe de sécurité réseau, vos groupes de sécurité réseau peuvent avoir beaucoup plus de quatre règles. Sur l’image, vous voyez VirtualNetwork sous Source et Destination et AzureLoadBalancer sous SOURCE. VirtualNetwork et AzureLoadBalancer sont des balises de service. Les balises de service représentent un groupe de préfixes d’adresses IP qui permet de simplifier la création de règles de sécurité.
Pour afficher les règles de sécurité effectives, sélectionnez l’interface dans les paramètres réseau de la machine virtuelle. Vérifiez que la machine virtuelle est en cours d’exécution avant de continuer.
Dans les paramètres de l’interface réseau, dépliez Aide, puis sélectionnez Règles de sécurité effectives.

L’exemple suivant montre l’exemple d’interface réseau vm-1445 avec les règles de sécurité efficaces sélectionnées.

Les règles répertoriées sont identiques à celles de l’étape 3, bien qu’il existe différents onglets pour le groupe de sécurité réseau associé à l’interface réseau et au sous-réseau. Comme vous pouvez le voir dans l’image, seules les 50 premières règles sont affichées. Pour télécharger un fichier CSV contenant toutes les règles, sélectionnez Télécharger.
Les étapes précédentes montraient les règles de sécurité pour une interface réseau nommée vm-1445. Que se passe-t-il si une machine virtuelle a deux interfaces réseau ? La machine virtuelle dans cet exemple a deux interfaces réseau attachées. Les règles de sécurité effectives peuvent être différentes pour chaque interface réseau.

Pour voir les règles de l’interface réseau vm-nic-2, sélectionnez-la. Comme montré dans l’exemple suivant, l’interface réseau a les mêmes règles associées à son sous-réseau que l’interface réseau vm-1445 , car les deux interfaces réseau sont dans le même sous-réseau. Lorsque vous associez un groupe de sécurité réseau à un sous-réseau, ses règles sont appliquées à toutes les interfaces réseau dans le sous-réseau.

Contrairement à l’interface réseau vm-1445 , l’interface réseau vm-nic-2 ne possède pas de groupe de sécurité réseau associé. Chaque interface réseau et sous-réseau peuvent avoir aucun ou un groupe de sécurité réseau associé. Le groupe de sécurité réseau associé à chaque interface réseau ou sous-réseau peut être le même ou différent. Vous pouvez associer le même groupe de sécurité réseau à autant d’interfaces réseau et de sous-réseaux que vous le souhaitez.

Bien que les règles de sécurité effectives aient été affichées au moyen de la machine virtuelle, vous pouvez aussi les consulter avec les éléments individuels suivants :

Interface réseau : découvrez comment afficher une interface réseau.
NSG : découvrez comment afficher un NSG.

Diagnostiquer à l’aide de PowerShell

Note

Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.

Vous pouvez exécuter les commandes qui suivent dans Azure Cloud Shell, ou en exécutant PowerShell à partir de votre ordinateur. Azure Cloud Shell est un interpréteur de commandes interactif gratuit. Il contient des outils Azure courants préinstallés et configurés pour être utilisés avec votre compte. Si vous exécutez PowerShell sur votre ordinateur, vous devez utiliser le module Azure PowerShell version 1.0.0 ou ultérieure. Exécutez Get-Module -ListAvailable Az sur votre ordinateur pour trouver la version installée. Si vous devez effectuer une mise à niveau, consultez Installer le module Azure PowerShell. Si vous utilisez PowerShell localement, vous devez aussi exécuter Connect-AzAccount pour vous connecter à Azure avec un compte disposant des permissions nécessaires].

Obtenez les règles de sécurité effectives pour une interface réseau avec Get-AzEffectiveNetworkSecurityGroup. L’exemple suivant obtient les règles de sécurité efficaces pour une interface réseau nommée vm-nic qui fait partie d’un groupe de ressources nommé test-rg :

$Params = @{
  NetworkInterfaceName = "vm-nic"
  ResourceGroupName    = "test-rg"
}
Get-AzEffectiveNetworkSecurityGroup @Params

La sortie est retournée au format json. Pour comprendre la sortie, consultez Interpréter la sortie de commande. La sortie est renvoyée uniquement si un groupe de sécurité réseau est associé à l’interface réseau, le sous-réseau auquel l’interface réseau appartient, ou les deux. La machine virtuelle doit être en cours d’exécution. Une machine virtuelle peut avoir plusieurs interfaces réseau avec différents groupes de sécurité réseau appliqués. Lors de la résolution du problème, exécutez la commande pour chaque interface réseau.

Si vous rencontrez toujours un problème de connectivité, consultez Diagnostics supplémentaires et Considérations.

Si vous connaissez uniquement le nom de la machine virtuelle, utilisez les commandes suivantes pour répertorier tous les ID d’interface réseau attachés à la machine virtuelle.

$Params = @{
  Name              = "vm-1"
  ResourceGroupName = "test-rg"
}
$VM = Get-AzVM @Params
$VM.NetworkProfile

Le résultat ressemble à ce qui suit :

NetworkInterfaces
-----------------
{/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/vm-nic

Dans la sortie précédente, le nom de l’interface réseau est vm-nic.

Diagnostiquer à l’aide d’Azure CLI

Si vous utilisez des commandes Azure CLI pour accomplir les tâches décrites dans cet article, exécutez les commandes dans Azure Cloud Shell ou en exécutant Azure CLI sur votre ordinateur. Azure CLI version 2.0.32 ou ultérieure est nécessaire pour cet article. Exécutez az --version pour connaître la version installée. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI. Si vous exécutez Azure CLI localement, vous devez aussi exécuter az login et vous connecter à Azure avec un compte disposant des autorisations nécessaires.

Obtenez les règles de sécurité effectives d’une interface réseau avec az network nic list-effective-nsg. L’exemple suivant obtient les règles de sécurité efficaces pour une interface réseau nommée vm-nic qui fait partie d’un groupe de ressources nommé test-rg :

az network nic list-effective-nsg \
  --name vm-nic \
  --resource-group test-rg

La sortie est renvoyée au format JSON. Pour comprendre la sortie, consultez Interpréter la sortie de commande. La sortie est renvoyée uniquement si un groupe de sécurité réseau est associé à l’interface réseau, le sous-réseau auquel l’interface réseau appartient, ou les deux. La machine virtuelle doit être en cours d’exécution. Une machine virtuelle peut avoir plusieurs interfaces réseau avec différents groupes de sécurité réseau appliqués. Lors de la résolution du problème, exécutez la commande pour chaque interface réseau.

Si vous rencontrez toujours un problème de connectivité, consultez Diagnostics supplémentaires et Considérations.

Si vous connaissez uniquement le nom de la machine virtuelle, utilisez les commandes suivantes pour répertorier tous les ID d’interface réseau attachés à la machine virtuelle.

az vm show \
  --name vm-1 \
  --resource-group test-rg

Dans les résultats retournés, vous obtenez des informations similaires à l’exemple suivant :

"networkProfile": {
    "additionalProperties": {},
    "networkInterfaces": [
      {
        "additionalProperties": {},
        "id": "/subscriptions/<ID>/resourceGroups/test-rg/providers/Microsoft.Network/networkInterfaces/vm-nic",
        "primary": true,
        "resourceGroup": "test-rg"
      },

Dans la sortie précédente, le nom de l’interface réseau est vm-nic

Interpréter la sortie de commande

Indépendamment du fait d’avoir utilisé PowerShell ou Azure CLI pour diagnostiquer le problème, vous recevez une sortie contenant les informations suivantes :

NetworkSecurityGroup : l’ID du groupe de sécurité réseau.
Association : indique si le groupe de sécurité réseau est associé à une interface réseau ou à un sous-réseau. Si l’état de l’association du groupe de sécurité réseau change juste avant d’exécuter la commande, attendez quelques secondes pour que la sortie reflète la mise à jour.
EffectiveSecurityRules : une explication de chaque propriété est détaillée dans Créer une règle de sécurité. Les noms de règles commençant par defaultSecurityRules/ sont des règles de sécurité par défaut qui existent dans chaque groupe de sécurité réseau. Les noms de règles précédés de securityRules/ sont des règles créées par les utilisateurs. Les règles qui spécifient une balise de service, comme Internet, VirtualNetwork, et AzureLoadBalancer pour les propriétés destinationAddressPrefix ou sourceAddressPrefix, ont également des valeurs pour la propriété expandedDestinationAddressPrefix. La propriété expandedDestinationAddressPrefix répertorie tous les préfixes d’adresse représentés par la balise de service.

Les règles en double se manifestent dans le compte rendu lorsqu’un groupe de sécurité réseau est lié à la fois à l’interface réseau et au sous-réseau. Les règles par défaut et toutes les règles personnalisées partagées entre les groupes de sécurité réseau provoquent ces doublons.

La règle nommée defaultSecurityRules/DenyAllInBound est celle qui empêche les communications entrantes vers la machine virtuelle via le port 80, à partir d’internet, comme décrit dans le scénario. Aucune autre règle avec une priorité plus élevée (numéro inférieur) n’autorise le trafic entrant sur le port 80 à partir d’internet.

Résoudre un problème

Vous pouvez diagnostiquer le problème décrit dans le scenario à l’aide du Azure portal, PowerShell ou du Azure CLI. La solution consiste à créer une règle de sécurité réseau avec les propriétés suivantes :

Propriété	Valeur
Source	Quelconque
Plages de ports source	Quelconque
Destination	L’adresse IP de la machine virtuelle, une plage d’adresses IP ou toutes les adresses dans le sous-réseau.
Plages de ports de destination	80
Protocole	TCP
Action	Autoriser
Priorité	100
Nom	Allow-HTTP-All

Après la création de la règle, le port 80 est autorisé en entrée depuis Internet car sa priorité est supérieure à celle de la règle par défaut DenyAllInBound. Si les NSG (groupes de sécurité réseau) sont associés à la fois à l'interface réseau et au sous-réseau, créez la même règle dans les deux NSG. Apprenez à créer une règle de sécurité.

Scénarios de gestion Windows nécessitant RPC/DCOM

L’instrumentation de gestion Windows (WMI) et le Modèle d’objet composant distribué (DCOM) utilisent l’appel de procédure à distance (RPC). Le client se connecte d’abord au RPC Endpoint Mapper sur le port TCP 135. Le mappeur de points de terminaison dirige alors le client vers un port TCP alloué dynamiquement. Sur les paramètres par défaut actuels de Windows, la plage dynamique TCP est 49152-65535. Vérifiez la plage configurée sur la VM Windows cible avant de créer la règle ; si l’hôte utilise une plage personnalisée, utilisez cette plage vérifiée au lieu de supposer 49152-65535.

Pour chaque NSG associé au sous-réseau ou à l’interface réseau de la VM cible, créez les deux règles d’autorisation entrantes. Remplacez <management-source-prefix> par le réseau de gestion, l’hôte ou le service approuvé, et remplacez <target-vm-nic-or-subnet-prefix> par la destination cible VM, carte réseau ou sous-réseau. Remplacez <priority-rpc-endpoint-mapper> et <priority-rpc-dynamic> par des priorités entières distinctes inutilisées entre 100 et 4096. Les deux règles sont nécessaires car un test TCP 135 uniquement peut réussir alors que la connexion RPC dynamique suivante est bloquée.

Pour plus d’informations sur ce flux WMI/DCOM, voir Dépannage des configurations incorrectes de NSG qui bloquent le trafic dans Réseau virtuel Azure. Pour les détails sur les ports Windows et le RPC, voir Aperçu du service et exigences des ports réseau, Dépannage d’une connexion WMI distante, et Fonctionnement des ports dynamiques RPC avec les pare-feu.

az network nsg rule create \
  --resource-group <resource-group> \
  --nsg-name <nsg-name> \
  --name Allow-RpcEndpointMapper \
  --priority <priority-rpc-endpoint-mapper> \
  --source-address-prefixes <management-source-prefix> \
  --source-port-ranges '*' \
  --destination-address-prefixes <target-vm-nic-or-subnet-prefix> \
  --destination-port-ranges 135 \
  --access Allow \
  --protocol Tcp \
  --direction Inbound

az network nsg rule create \
  --resource-group <resource-group> \
  --nsg-name <nsg-name> \
  --name Allow-RpcDynamic \
  --priority <priority-rpc-dynamic> \
  --source-address-prefixes <management-source-prefix> \
  --source-port-ranges '*' \
  --destination-address-prefixes <target-vm-nic-or-subnet-prefix> \
  --destination-port-ranges 49152-65535 \
  --access Allow \
  --protocol Tcp \
  --direction Inbound

La 49152-65535 valeur dans la règle dynamique est uniquement la valeur par défaut. Si vous avez vérifié une plage personnalisée sur la VM Windows cible, remplacez-la dans cette règle.

$managementSourcePrefix = "<management-source-prefix>"
$targetDestinationPrefix = "<target-vm-nic-or-subnet-prefix>"
$rpcEndpointMapperPriority = 300
$rpcDynamicPriority = 310

$networkSecurityGroup = Get-AzNetworkSecurityGroup `
  -Name "<nsg-name>" `
  -ResourceGroupName "<resource-group>"

Add-AzNetworkSecurityRuleConfig `
  -Name "Allow-RpcEndpointMapper" `
  -Description "Allow RPC Endpoint Mapper from approved management source" `
  -NetworkSecurityGroup $networkSecurityGroup `
  -Access Allow `
  -Protocol Tcp `
  -Direction Inbound `
  -Priority $rpcEndpointMapperPriority `
  -SourceAddressPrefix $managementSourcePrefix `
  -SourcePortRange "*" `
  -DestinationAddressPrefix $targetDestinationPrefix `
  -DestinationPortRange "135"

Add-AzNetworkSecurityRuleConfig `
  -Name "Allow-RpcDynamic" `
  -Description "Allow RPC dynamic ports from approved management source" `
  -NetworkSecurityGroup $networkSecurityGroup `
  -Access Allow `
  -Protocol Tcp `
  -Direction Inbound `
  -Priority $rpcDynamicPriority `
  -SourceAddressPrefix $managementSourcePrefix `
  -SourcePortRange "*" `
  -DestinationAddressPrefix $targetDestinationPrefix `
  -DestinationPortRange "49152-65535"

Set-AzNetworkSecurityGroup -NetworkSecurityGroup $networkSecurityGroup

Lorsque Azure traite le trafic entrant, il traite les règles du groupe de sécurité réseau associé au sous-réseau (s'il existe un groupe de sécurité réseau associé), puis traite les règles du groupe de sécurité réseau associé à l'interface réseau. S'il existe un NSG associé à l'interface réseau et au sous-réseau, le port doit être ouvert dans les deux NSG, pour que le trafic atteigne la machine virtuelle (VM). Pour faciliter les problèmes d’administration et de communication, nous vous recommandons d’associer un groupe de sécurité réseau à un sous-réseau, plutôt que des interfaces réseau individuelles. Si des machines virtuelles au sein d’un sous-réseau ont besoin de règles de sécurité différentes, vous pouvez rendre les interfaces réseau membres d’un groupe de sécurité d’application (ASG) et spécifier un ASG comme source et destination d’une règle de sécurité. Pour en savoir plus sur les groupes de sécurité d’application.

Si des problèmes de communication subsistent, consultez Considérations et Diagnostic supplémentaire.

Considérations

Lors de la résolution de problèmes de connectivité, considérez les points suivants :

Des règles de sécurité par défaut bloquent l’accès entrant à partir d’internet et n’autorisent que le trafic entrant à partir du réseau virtuel. Pour autoriser le trafic entrant à partir d’internet, ajoutez des règles de sécurité avec une priorité plus élevée que les règles par défaut. En savoir plus sur les règles de sécurité par défaut, ou comment ajouter une règle de sécurité.
Pour les réseaux virtuels peered, par défaut, le tag de service VIRTUAL_NETWORK s’élargit automatiquement pour inclure des préfixes pour les réseaux virtuels peered. Pour résoudre des problèmes liés au peering de réseau virtuel, vous pouvez consulter les préfixes dans la liste ExpandedAddressPrefix. En savoir plus sur le peering de réseaux virtuels et les balises de service.
Azure affiche uniquement des règles de sécurité effectives pour une interface réseau lorsqu'un groupe de sécurité réseau est associé à l'interface réseau ou au sous-réseau de la machine virtuelle. En outre, la machine virtuelle doit être dans l’état en cours d’exécution.
Si l’interface réseau ou le sous-réseau ne possède pas de NSG associé, tous les ports restent ouverts pour l’accès entrant et sortant lorsqu’une VM possède une adresse IP publique. Cette configuration permet un accès illimité à et depuis n’importe où. Pour sécuriser la machine virtuelle, appliquez un groupe de sécurité réseau au sous-réseau hébergeant l’interface réseau s’il a une adresse IP publique.

Diagnostics supplémentaires

Pour exécuter un test rapide pour déterminer si le trafic est autorisé vers ou à partir d’une machine virtuelle, utilisez la capacité IP flow verify de Azure Network Watcher. IP Flow Verify vous indique si le trafic est autorisé ou refusé. Si le trafic est refusé, IP Flow Verify vous indique la règle de sécurité qui refuse le trafic.
S’il n’existe aucune règle de sécurité entraînant l’échec de la connectivité réseau d’une machine virtuelle, le problème peut être dû à :
- Logiciel de pare-feu s’exécutant à l’intérieur du système d’exploitation de la machine virtuelle
- Itinéraires configurés pour des appliances virtuelles ou un trafic local. Le trafic Internet peut être redirigé localement vers votre réseau local au moyen d’un tunneling forcé. Si vous forcez le trafic Internet vers une appliance virtuelle ou localement, vous ne pourrez peut-être pas vous connecter à la machine virtuelle à partir d’Internet. Pour apprendre à diagnostiquer les problèmes de routage qui pourraient entraver le flux du trafic hors de la VM, voir Diagnostiquer un problème de routage du trafic réseau d’une machine virtuelle.

Étapes suivantes

En savoir plus sur toutes les tâches, les propriétés et les paramètres pour un groupe de sécurité réseau et les règles de sécurité.
En savoir plus sur les règles de sécurité par défaut, les balises de service, et comment Azure traite les règles de sécurité pour le trafic entrant et sortant pour une machine virtuelle.

Commentaires

Cette page a-t-elle été utile ?

Dernière mise à jour : 2026-10-08