Diagnostiquer un problème de routage réseau d’une machine virtuelle à l’aide d’Azure CLI

Article
10/31/2024

Dans cet article, vous apprendrez à utiliser l’outil Tronçon suivant Azure Network Watcher pour résoudre et diagnostiquer le problème de routage d’une machine virtuelle qui l’empêche de communiquer correctement avec d’autres ressources.

Prérequis

Compte Azure avec un abonnement actif. Créez un compte gratuitement.
Azure Cloud Shell ou Azure CLI.

Dans les étapes de cet article, vous exécutez les commandes Azure CLI de manière interactive dans Azure Cloud Shell. Pour exécuter les commandes dans le Cloud Shell, sélectionnez Ouvrir Cloud Shell dans le coin supérieur droit d’un bloc de code. Sélectionnez Copier pour copier le code, puis collez-le dans Cloud Shell afin de l’exécuter. Vous pouvez démarrer Azure Cloud Shell depuis le Portail Azure.

Vous pouvez également installer Azure CLI localement afin d’exécuter les commandes. Cet article nécessite la version 2.0 ou ultérieure d’Azure CLI. Exécutez la commande az --version pour rechercher la version installée. Si vous exécutez Azure CLI localement, connectez-vous à Azure à l’aide de la commande az login.

Création d'une machine virtuelle

Avant de pouvoir créer une machine virtuelle, vous devez créer un groupe de ressources pour qu’il contienne la machine virtuelle. Créez un groupe de ressources avec la commande az group create. L’exemple suivant crée un groupe de ressources nommé myResourceGroup à l’emplacement eastus :

az group create --name myResourceGroup --location eastus

Créez une machine virtuelle avec la commande az vm create. Si des clés SSH n’existent pas déjà dans un emplacement de clé par défaut, la commande les crée. Pour utiliser un ensemble spécifique de clés, utilisez l’option --ssh-key-value. L’exemple suivant crée une machine virtuelle nommée myVm :

az vm create \
  --resource-group myResourceGroup \
  --name myVm \
  --image Ubuntu2204 \
  --generate-ssh-keys

La création de la machine virtuelle ne nécessite que quelques minutes. Ne passez pas aux étapes restantes avant que la machine virtuelle ne soit créée et qu’Azure CLI ne retourne la sortie.

Tester la communication réseau

Pour tester une communication réseau avec Network Watcher, commencez par activer un observateur réseau dans la région de la machine virtuelle que vous souhaitez tester, puis utilisez la fonctionnalité de tronçon suivant de Network Watcher pour tester la communication.

Activer Network Watcher

Si vous disposez déjà d’un observateur réseau activé dans la région USA Est, passez à l’étape Utiliser le tronçon suivant. Utilisez la commande az network watcher configure pour créer un observateur réseau dans la région USA Est :

az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations eastus \
  --enabled

Utiliser le tronçon suivant

Azure crée automatiquement des itinéraires vers les destinations par défaut. Vous pouvez créer des itinéraires personnalisés pour remplacer les itinéraires par défaut. Parfois, les itinéraires personnalisés peuvent entraîner l’échec de la communication. Pour tester le routage à partir d’une machine virtuelle, utilisez la commande az network watcher show-next-hop afin de déterminer le tronçon de routage suivant lorsque le trafic est destiné à une adresse spécifique.

Testez la communication sortante de la machine virtuelle vers l’une des adresses IP pour www.bing.com :

az network watcher show-next-hop \
  --dest-ip 13.107.21.200 \
  --resource-group myResourceGroup \
  --source-ip 10.0.0.4 \
  --vm myVm \
  --nic myVmVMNic \
  --out table

Après quelques secondes, la sortie vous informe que NextHopType est défini sur Internet et que RouteTableId est défini sur System Route (Itinéraire système). Ce résultat vous permet de savoir qu’il existe un itinéraire valide vers la destination.

Testez la communication sortante de la machine virtuelle vers l’adresse 172.31.0.100 :

az network watcher show-next-hop \
  --dest-ip 172.31.0.100 \
  --resource-group myResourceGroup \
  --source-ip 10.0.0.4 \
  --vm myVm \
  --nic myVmVMNic \
  --out table

La sortie retournée vous informe que Aucun est la valeur de NextHopType et que RouteTableId est également défini sur System Route (Itinéraire système). Ce résultat vous permet de savoir que s’il existe un itinéraire système valide vers la destination, il n’existe aucun tronçon suivant pour acheminer le trafic vers la destination.

Afficher les détails d’un itinéraire

Pour procéder à une analyse plus approfondie du routage, passez en revue les itinéraires réels de l’interface réseau avec la commande az network nic show-effective-route-table :

az network nic show-effective-route-table \
  --resource-group myResourceGroup \
  --name myVmVMNic

Le texte suivant est inclus dans la sortie retournée :

{
  "additionalProperties": {
    "disableBgpRoutePropagation": false
  },
  "addressPrefix": [
    "0.0.0.0/0"
  ],
  "name": null,
  "nextHopIpAddress": [],
  "nextHopType": "Internet",
  "source": "Default",
  "state": "Active"
},

Lorsque vous avez utilisé la commande az network watcher show-next-hop pour tester la communication sortante vers l’adresse IP 13.107.21.200 dans la zone Use next hop (Utiliser le tronçon suivant), l’itinéraire présentant le préfixe d’adresse 0.0.0.0/0** a été utilisé pour router le trafic vers l’adresse, car aucun autre itinéraire n’inclut cette adresse. Par défaut, toutes les adresses non spécifiées dans le préfixe d’adresse d’un autre itinéraire sont acheminées vers Internet.

Toutefois, lorsque vous avez utilisé la commande az network watcher show-next-hop pour tester la communication sortante vers l’adresse IP 172.31.0.100, le résultat vous a informé de l’absence de type de tronçon suivant. Dans les résultats retournés, vous voyez également le texte suivant :

{
  "additionalProperties": {
    "disableBgpRoutePropagation": false
      },
  "addressPrefix": [
    "172.16.0.0/12"
  ],
  "name": null,
  "nextHopIpAddress": [],
  "nextHopType": "None",
  "source": "Default",
  "state": "Active"
},

Comme vous pouvez le voir dans la sortie de la commande az network watcher nic show-effective-route-table, même s’il existe un itinéraire par défaut pour le préfixe 172.16.0.0/12, qui inclut l’adresse 172.31.0.100, NextHopType est défini sur None (Aucun) . Azure crée un itinéraire par défaut pour 172.16.0.0/12, mais ne spécifie pas de type de tronçon suivant tant qu’aucune raison ne motive cette spécification. Si, par exemple, vous avez ajouté la plage d’adresses 172.16.0.0/12 à l’espace d’adressage du réseau virtuel, Azure modifie NextHopType pour le définir sur Réseau virtuel pour l’itinéraire. Une vérification permet ensuite d’afficher Réseau virtuel en tant que NextHopType.

Nettoyer les ressources

Quand vous n’avez plus besoin d’un groupe de ressources, vous pouvez utiliser az group delete pour le supprimer, ainsi que toutes les ressources qu’il contient :

az group delete --name myResourceGroup --yes

Étapes suivantes

Dans cet article, vous avez créé une machine virtuelle et diagnostiqué un problème de routage réseau à partir de celle-ci. Vous avez appris qu’Azure crée plusieurs itinéraires par défaut et testé le routage vers deux destinations différentes. En savoir plus sur le routage dans Azure et la création d’itinéraires personnalisés.

Pour les connexions sortantes d’une machine virtuelle, vous pouvez également déterminer la latence, le trafic réseau autorisé et refusé entre la machine virtuelle et un point de terminaison, à l’aide de la fonctionnalité Résolution des problèmes de connexion de Network Watcher. Vous pouvez effectuer un monitoring des communications entre une machine virtuelle et un point de terminaison, par exemple une adresse IP ou une URL, au fil du temps à l’aide de la fonctionnalité de monitoring des connexions de Network Watcher. Pour plus d’informations, consultez Effectuer le monitoring d’une connexion réseau.

Partager via