Questions fréquentes (FAQ) sur Network Watcher

Network Watcher fournit une suite d’outils pour surveiller, diagnostiquer, afficher des métriques et activer ou désactiver des journaux pour les ressources IaaS (Infrastructure as a Service), notamment les machines virtuelles, les réseaux virtuels, les passerelles applicatives, les équilibreurs de charge et autres ressources d’un réseau virtuel Azure. Il ne s’agit pas d’une solution pour superviser l’infrastructure PaaS (plateforme en tant que service) ni pour obtenir une analytique web/mobile.

Network Watcher propose trois principaux ensembles de fonctionnalités :

• Supervision
  • La vue Topologie vous montre les ressources figurant dans votre réseau virtuel et les relations entre ces ressources.
  • Le moniteur de connexion vous permet de surveiller la connectivité et la latence entre les points de terminaison à l’intérieur et à l’extérieur d’Azure.
• Outils de diagnostic réseau
  • La vérification des flux IP vous permet de détecter les problèmes de filtrage du trafic au niveau d’une machine virtuelle.
  • Les diagnostics de groupe de sécurité réseau vous permettent de détecter les problèmes de filtrage du trafic au niveau d’une machine virtuelle, d’un groupe de machines virtuelles identiques ou d’une passerelle applicative.
  • Le tronçon suivant vous aide à vérifier les itinéraires de trafic et à détecter les problèmes de routage.
  • La résolution des problèmes de connexion permet une connexion ponctuelle et la vérification de la latence entre une machine virtuelle et un hôte Bastion, une passerelle applicative ou une autre machine virtuelle.
  • La capture de paquets vous permet de capturer le trafic de votre machine virtuelle.
  • La résolution des problèmes liés au VPN exécute plusieurs vérifications de diagnostic sur vos connexions et passerelles VPN pour aider à résoudre les problèmes.
• Trafic
  • Les journaux de flux de réseau virtuel et les journaux de flux de groupe de sécurité réseau vous permettent d'enregistrer le trafic réseau transitant respectivement par vos réseaux virtuels et vos groupes de sécurité réseau (NSG).
  • Analyse du trafic traite les données de vos journaux de flux de groupes de sécurité réseau, ce qui vous permet de visualiser, d’interroger, d’analyser et de comprendre votre trafic réseau.

Pour plus d’informations, consultez la vue d’ensemble de Network Watcher.

Pour plus d’informations sur la tarification des différents composants Network Watcher, consultez Tarification Network Watcher.

Consultez Régions Network Watcher pour en savoir plus sur les régions qui prennent en charge Network Watcher.

Consultez Autorisations RBAC Azure requises pour utiliser Network Watcher pour obtenir la liste détaillée des autorisations requises pour chacune des fonctionnalités de Network Watcher.

Le service Network Watcher est automatiquement activé pour chaque abonnement. Vous devez activer manuellement Network Watcher si vous avez refusé de l’activer automatiquement. Pour plus d’informations, consultez Activer ou désactiver Azure Network Watcher.

La ressource parente Network Watcher est déployée avec une instance unique sur chaque région. Format de nommage par défaut : NetworkWatcher_RegionName. Exemple : NetworkWatcher_centralus est la ressource Network Watcher pour la région « USA Centre ». Vous pouvez personnaliser le nom de l'instance Network Watcher à l'aide de PowerShell ou de l'API REST.

Network Watcher a juste besoin d’être activé une seule fois par région dans un abonnement pour que ses fonctionnalités fonctionnent. Network Watcher est activé dans une région en créant une instance Network Watcher dans cette région.

La ressource Network Watcher représente le service back-end pour Network Watcher qui est entièrement géré par Azure. Cependant, vous pouvez créer ou supprimer la ressource Network Watcher pour l’activer ou la désactiver dans une région particulière. Pour plus d’informations, consultez Activer ou désactiver Azure Network Watcher.

Non, le déplacement d’une ressource Network Watcher ou de l’une de ses ressources enfants entre des régions n’est pas pris en charge. Pour plus d'informations, consultez la section Prise en charge des opérations de déplacement des ressources réseau.

Oui, le déplacement d’une ressource Network Watcher entre les groupes de ressources est pris en charge. Pour plus d'informations, consultez la section Prise en charge des opérations de déplacement des ressources réseau.

NetworkWatcherRG est un groupe de ressources créé automatiquement pour les ressources Network Watcher. Par exemple, les instances régionales Network Watcher et les ressources du journal de flux de groupe de sécurité réseau sont créées dans le groupe de ressources NetworkWatcherRG. Vous pouvez personnaliser le nom du groupe de ressources Network Watcher à l'aide de PowerShell, d'Azure CLI ou de l'API REST.

Azure Network Watcher ne stocke pas les données client à l’exception du Moniteur de connexion. Le moniteur de connexion stocke des données client, qui sont automatiquement stockées par Network Watcher, dans une seule région pour répondre aux exigences de résidence des données dans la région.

Network Watcher a les limites suivantes :

Oui, le service Network Watcher est résilient aux zones par défaut.

Aucune configuration n’est nécessaire pour activer la résilience des zones. La résilience des zones pour les ressources Network Watcher est disponible par défaut et gérée par le service lui-même.

L’agent Network Watcher est requis pour toute fonctionnalité Network Watcher qui génère ou intercepte le trafic d’une machine virtuelle.

Les fonctionnalités Moniteur de connexion, Capture de paquets et Résolution des problèmes de connexion (test de connectivité) nécessitent la présence de l’extension Network Watcher.

La version la plus récente de l’extension Network Watcher est 1.4.3783.1. Pour plus d’informations, consultez Mettre à jour l’extension Azure Network Watcher vers la dernière version.

• Linux : l’agent Network Watcher utilise les ports disponibles à partir de port 50000 jusqu’à atteindre port 65535.
• Windows : l’agent Network Watcher utilise les ports par lesquels le système d’exploitation répond lorsqu’il est interrogé sur les ports disponibles.

L’agent Network Watcher nécessite une connectivité TCP sortante vers 169.254.169.254 plutôt que port 80 et 168.63.129.16 plutôt que port 8037. L’agent utilise ces adresses IP pour communiquer avec la plateforme Azure.

Non, le Moniteur de connexion ne prend pas en charge les machines virtuelles classiques. Pour plus d'informations, consultez Migration de ressources IaaS d’un environnement Classic vers Azure Resource Manager.

La topologie peut être décorée de Non-Azure en Azure uniquement si la ressource Azure de destination et la ressource du Moniteur de connexion se trouvent dans la même région.

La même machine virtuelle Azure ne peut pas être utilisée avec différentes configurations dans le même moniteur de connexion. Par exemple, l’utilisation de la même machine virtuelle avec un filtre et sans filtre dans le même moniteur de connexion n’est pas prise en charge.

Les problèmes affichés sur le tableau de bord du Moniteur de connexion sont détectés lors de la découverte de la topologie ou de l'exploration des tronçons. Il peut arriver que le seuil fixé pour le % de perte ou le RTT soit dépassé, mais qu'aucun problème ne soit détecté au niveau des tronçons.

Il n’y a pas d’option de sélection du protocole dans le Moniteur de connexion (classique). Les tests dans le moniteur de connexion (classique) utilisent uniquement le protocole TCP, et c’est pourquoi, pendant la migration, nous créons une configuration TCP dans les tests dans le nouveau moniteur de connexion.

Il existe actuellement une limite régionale lorsqu'un point de terminaison utilise Azure Monitor et les agents Arc avec l'espace de travail Log Analytics associé. En raison de cette limitation, l'espace de travail Log Analytics associé doit se trouver dans la même région que le point de terminaison Arc. Les données ingérées dans des espaces de travail individuels peuvent être regroupées pour une vue unique, consultez Interroger des données sur des espaces de travail, des applications et des ressources Log Analytics dans Azure Monitor.

Les journaux de flux vous permettent de journaliser les informations de flux à cinq tuples concernant le trafic IP Azure qui passe par un groupe de sécurité réseau ou un réseau virtuel Azure. Les journaux de flux bruts sont placés dans un compte de stockage Azure. Vous pouvez ensuite les traiter, les analyser, les interroger ou les exporter selon vos besoins.

Les données du journal de flux sont collectées en dehors du chemin d’accès de votre trafic réseau ; ils n’affectent donc pas le débit ou la latence du réseau. Vous pouvez créer ou supprimer des journaux de flux sans risque d’impact sur les performances du réseau.

Les journaux de flux d'un groupe de sécurité réseau enregistrent le trafic transitant par un groupe de sécurité réseau. D'autre part, les diagnostics NSG renvoient tous les groupes de sécurité réseau que votre trafic traverse et les règles de chaque groupe de sécurité réseau qui sont appliquées à ce trafic. Utilisez les diagnostics de NSG pour vérifier que vos règles de groupe de sécurité réseau sont appliquées comme prévu.

Non, les journaux de flux de groupes de sécurité réseau ne prennent pas en charge les protocoles ESP et AH.

Non, les journaux de flux de groupe de sécurité réseau et les journaux de flux de réseau virtuel ne prennent pas en charge le protocole ICMP.

Oui. La ressource de journal de flux associée sera également supprimée. Les données du journal de flux sont conservées dans le compte de stockage pendant la période de rétention configurée dans le journal de flux.

Oui, mais vous devez supprimer la ressource du journal de flux associée. Après la migration du groupe de sécurité réseau, vous devez recréer les journaux de flux pour activer la journalisation de flux sur celui-ci.

Oui, vous pouvez utiliser un compte de stockage d’un autre abonnement tant que celui-ci se trouve dans la même région que le groupe de sécurité réseau et qu’il est associé au même locataire Microsoft Entra que le groupe de sécurité réseau ou l’abonnement du réseau virtuel.

Pour utiliser un compte de stockage derrière un pare-feu, vous devez autoriser les services Azure de confiance à accéder à votre compte de stockage :

1. Accédez au compte de stockage en entrant le nom du compte de stockage dans la zone de recherche en haut du portail.
2. Sous Sécurité + mise en réseau, sélectionnez Mise en réseau, puis Pare-feu et réseaux virtuels.
3. Dans Accès au réseau public, choisissez Activé à partir des réseaux virtuels et adresses IP sélectionnés. Sous Exceptions, cochez la case Autoriser les services Azure figurant dans la liste des services approuvés à accéder à ce compte de stockage.
4. Activez les journaux de flux en créant un journal de flux pour votre ressource cible à l'aide du compte de stockage. Pour plus d’informations, consultez Créer un journal de flux.

Vous pouvez vérifier les journaux de stockage après quelques minutes. Vous devriez voir un horodatage mis à jour ou un fichier JSON nouvellement créé.

Aujourd’hui, un compte de stockage prend en charge 100 règles et chaque règle peut prendre en charge 10 préfixes d’objet blob. Si vous atteignez la limite, vous pouvez définir sur 0 la stratégie de rétention lorsque vous activez de nouveaux journaux de flux de réseau virtuel, et ensuite ajouter manuellement une règle de rétention pour l’abonnement.

Pour créer une règle d’abonnement de stratégie de rétention, procédez comme suit :

1. Accédez au compte de stockage en entrant le nom du compte de stockage dans la zone de recherche en haut du portail.
2. Sous Gestion des données, sélectionnez Gestion du cycle de vie.
3. Sélectionnez + Ajouter une règle.
4. Dans la section Détails, sélectionnez les paramètres suivants : Étendue de la règle :Limiter les objets blob avec des filtres, type d’objet blob :objets blob par blocs, et sous-type d’objet blob :objets blob de base.
5. Dans la section Blobs de base, configurez vos paramètres de rétention.
6. Dans la section Jeu de filtres, mettez en forme le préfixe Blob comme suit : "insights-logs-flowlogflowevent/flowLogResourceID=/<yourSubscriptionId>_NETWORKWATCHERRG"
7. Sélectionnez Ajouter.

La règle avec une période de rétention plus courte est prioritaire.

Network Watcher dispose d’un mécanisme de secours intégré qu’il utilise lors de la connexion à un compte de stockage situé derrière un pare-feu. Il tente de se connecter au compte de stockage à l’aide d’une clé et, en cas d’échec, il bascule vers l’utilisation d’un jeton. Dans ce cas, une erreur 403 est consignée dans le journal d’activité du compte de stockage.

Oui, Network Watcher prend en charge l'envoi des données des journaux de flux vers un compte de stockage configuré avec un point de terminaison privé.

Les journaux de flux sont compatibles avec les points de terminaison de service sans nécessiter de configuration supplémentaire. Pour plus d’informations, consultez Activer un point de terminaison de service.

La version 2 des journaux de flux introduit le concept d'état de flux et stocke des informations sur les octets et les paquets transmis. Pour plus d’informations, consultez Format de journaux de flux de groupes de sécurité réseau.

Non, un verrou en lecture seule sur un groupe de sécurité réseau empêche la création du journal de flux de groupe de sécurité réseau correspondant.

Oui, un verrou impossible à supprimer sur le groupe de sécurité réseau n’empêche pas la création ou la modification du journal de flux de groupe de sécurité réseau correspondant.

Oui, vous pouvez automatiser les journaux de flux de groupes de sécurité réseau via des modèles Azure Resource Manager (modèles ARM). Pour plus d’informations, consultez la section Configurer les journaux de flux NSG à l’aide d’un modèle Azure Resource Manager (ARM).

Oui, les réseaux virtuels et les groupes de sécurité réseau peuvent se trouver dans des régions différentes de celles de votre région d’espace de travail Log Analytics.

Oui.

Dans la liste déroulante de sélection des ressources dans le tableau de bord d’analyse du trafic, le groupe de ressources de la ressource réseau virtuel doit être sélectionné, et non le groupe de ressources de la machine virtuelle ou du groupe de sécurité réseau.

Traffic Analytics effectue une analyse de découverte des ressources toutes les 6 heures pour identifier les nouvelles machines virtuelles, cartes réseau, réseaux virtuels et sous-réseaux. Lorsqu’une machine virtuelle ou une carte réseau est créée après le dernier cycle de découverte et que les données de flux sont collectées avant la découverte suivante, l’analytique du trafic ne peut pas encore associer le trafic à une ressource connue. Par conséquent, ces ressources sont temporairement étiquetées comme étant inconnues dans la vue analytique.

Oui, vous pouvez désactiver l’accès public à la ressource de point de terminaison de collecte de données (DCE) pour bloquer le trafic entrant public vers celui-ci. L’ingestion continue de fonctionner sans associer la ressource DCE à une étendue Azure Monitor Private Link.

Oui. Si vous sélectionnez un espace de travail existant, vérifiez qu’il a été migré vers le nouveau langage de requête. Si vous ne souhaitez pas mettre à niveau l’espace de travail, vous devez en créer un nouveau. Pour plus d’informations sur le langage de requête Kusto (KQL), consultez Requêtes de journal dans Azure Monitor.

Oui, votre compte de stockage Azure peut se trouver dans un abonnement, et votre espace de travail Log Analytics peut se trouver dans un autre abonnement.

Oui. Vous pouvez configurer les journaux de flux à envoyer à un compte de stockage situé dans un autre abonnement, à condition que vous disposiez des privilèges appropriés et que le compte de stockage se trouve dans la même région que le groupe de sécurité réseau (journaux de flux de groupe de sécurité réseau) ou réseau virtuel (journaux de flux de réseau virtuel). Le compte de stockage de destination doit partager le même locataire Microsoft Entra du groupe de sécurité réseau ou du réseau virtuel.

Non. Toutes les ressources doivent se trouver dans le même tenant, y compris les groupes de sécurité réseau (journaux de flux de groupe de sécurité réseau), les réseaux virtuels (journaux de flux de réseau virtuel), les journaux de flux, les comptes de stockage et les espaces de travail Log Analytics (si l’analyse du trafic est activée).

Oui.

Les classeurs Traffic Analytics sont alimentés par des requêtes Log Analytics. Si la requête dépasse les limites d'analyse des journaux, le classeur peut présenter des erreurs de mémoire insuffisante. Pour améliorer les performances et réduire les erreurs de mémoire faible, les utilisateurs peuvent utiliser des clusters Log Analytics dédiés.

Non. Si vous supprimez le compte de stockage utilisé pour les journaux de flux, les données stockées dans l’espace de travail Log Analytics ne seront pas affectées. Vous pouvez toujours afficher les données historiques dans l’espace de travail Log Analytics (certaines métriques seront affectées), mais l’analytique du trafic ne traite plus les nouveaux journaux de flux tant que vous n’avez pas mis à jour les journaux de flux pour utiliser un autre compte de stockage.

Sélectionnez une région prise en charge. Si vous sélectionnez une région non prise en charge, vous recevez une erreur « Introuvable ». Pour plus d’informations, consultez les régions prises en charge par Traffic Analytics.

Le fournisseur doit être inscrit pour que la Microsoft.Insights journalisation des flux fonctionne correctement. Si vous ne savez pas si le Microsoft.Insights fournisseur est inscrit pour votre abonnement, consultez les instructions de gestion des journaux de flux NSG sur la façon de l’inscrire.

Le tableau de bord peut prendre jusqu’à 30 minutes pour afficher les rapports pour la première fois. La solution doit d’abord agréger suffisamment de données pour qu’elle dérive des insights significatifs, puis génère des rapports.

Essayez les options suivantes :

• Modifiez l’intervalle de temps dans la barre supérieure.
• Sélectionnez un autre espace de travail Log Analytics dans la barre supérieure.
• Essayez d’accéder à l’analytique du trafic après 30 minutes, si elle a été récemment activée.

Ce message peut s’afficher, car :

• L’analytique du trafic a été récemment activée et n’a peut-être pas encore agrégé suffisamment de données pour qu’elle dérive des insights significatifs.
• Vous utilisez la version gratuite de l’espace de travail Log Analytics et elle dépasse les limites de quota. Vous devrez peut-être utiliser un espace de travail avec une plus grande capacité.

Essayez les solutions suggérées pour la question précédente. Si des problèmes persistent, soulèvez des problèmes dans Microsoft Q&A.

Vous voyez les informations sur les ressources sur le tableau de bord ; toutefois, aucune statistique liée au flux n’est présente. Les données peuvent ne pas être présentes en raison d’aucun flux de communication entre les ressources. Attendez 60 minutes et revérifier l’état. Si le problème persiste et que vous êtes sûr que les flux de communication entre les ressources existent, soulèvez des préoccupations dans Microsoft Q&A.

L’analytique du trafic est mesurée. Le contrôle est basé sur le traitement des données de journal de flux brutes par le service. Pour plus d’informations, consultez la tarification de Network Watcher.
Les journaux améliorés ingérés dans l’espace de travail Log Analytics peuvent être conservés sans frais pendant les 31 premiers jours (ou 90 jours si Microsoft Sentinel est activé sur l’espace de travail). Pour plus d’informations, consultez la tarification d’Azure Monitor.

L’intervalle de traitement par défaut de l’analytique du trafic est de 60 minutes. Toutefois, vous pouvez sélectionner un traitement accéléré à 10 minutes. Pour plus d’informations, consultez Agrégation de données dans l’analytique du trafic.

L’analytique du trafic crée et gère les ressources de règle de collecte de données (DCR) et de point de terminaison de collecte de données (DCE) dans le même groupe de ressources que l’espace de travail, préfixé par NWTA. Si vous effectuez une opération sur ces ressources, l’analytique du trafic peut ne pas fonctionner comme prévu. Pour plus d’informations, consultez Agrégation de données dans l’analytique du trafic. Pour plus d’informations, consultez les règles de collecte de données dans azure Monitor et les points de terminaison de collecte de données dans Azure Monitor.

Il n’est pas recommandé d’appliquer des verrous aux ressources DCR et DCE créées par l’analytique du trafic, car ces ressources sont gérées par le service. Les ressources verrouillées ne sont pas nettoyées lors de la suppression des journaux de flux associés. Si vous effectuez une opération sur ces ressources, l’analytique du trafic peut ne pas fonctionner comme prévu. Pour plus d’informations, consultez Agrégation de données dans l’analytique du trafic.

L’analytique du trafic s’appuie sur les systèmes de renseignement sur les menaces internes de Microsoft pour considérer une adresse IP comme malveillante. Ces systèmes utilisent diverses sources de télémétrie telles que les produits et services Microsoft, l’Unité de crimes numériques Microsoft (DCU), le Centre de réponse à la sécurité Microsoft (MSRC) et les flux externes et créent des informations sur celui-ci. Certaines de ces données sont internes à Microsoft. Si une adresse IP connue est signalée comme malveillante, créez un ticket de support pour connaître les détails.

Traffic Analytics n’a pas de prise en charge intégrée des alertes. Toutefois, étant donné que les données d’analyse du trafic sont stockées dans Log Analytics, vous pouvez écrire des requêtes personnalisées et définir des alertes sur celles-ci. Suivez ces étapes :

• Vous pouvez utiliser le lien Log Analytics dans l’analytique du trafic.
• Utilisez le schéma d’analyse du trafic pour écrire vos requêtes.
• Sélectionnez Nouvelle règle d’alerte pour créer l’alerte.
• Consultez Créer une règle d’alerte pour créer l’alerte.

Non, il n’est actuellement pas pris en charge. Si un espace de travail Log Analytics est déployé derrière un périmètre de sécurité réseau, l’analytique du trafic ne pourra pas ingérer des données à partir de celle-ci.

Oui. Le dépannage de la connexion et les diagnostics NSG ne prennent pas en charge les déploiements Azure Application Gateway. Pour plus d’informations, consultez Déploiement d’une passerelle applicative privée.