Azure Virtual Network

Parlez-nous de l’expérience de téléchargement de PDF.
Documentation Réseau virtuel

Apprenez à utiliser le Réseau virtuel Microsoft Azure. Les démarrages rapides, tutoriels,
exemples et autres informations vous apprennent à déployer un réseau virtuel, contrôler
le filtrage et le routage du trafic et connecter un réseau virtuel à d’autres réseaux
virtuels.
À propos du Réseau virtuel
ｅ VUE D’ENSEMBLE
Présentation du réseau virtuel Azure
ｐ CONCEPT
FAQ sur le Réseau virtuel
ｄ ENTRAINEMENT
Introduction aux réseaux virtuels Azure
｀ DÉPLOYER
Provisionner une zone d’atterrissage réseau
Provisionner une nouvelle application dans un réseau existant
Provisionner une infrastructure de région Azure secondaire
Implémenter une sécurité réseau Azure
Bien démarrer
ｆ DÉMARRAGE RAPIDE
Création d’un réseau virtuel
ｃ GUIDE PRATIQUE
Créer, modifier ou supprimer un réseau virtuel
Ajouter, changer ou supprimer un sous-réseau

sécurisent le trafic réseau
ｐ CONCEPT
Groupes de sécurité réseau
Groupes de sécurité d’application
Points de terminaison de service de réseau virtuel
FAQ sur la sécurité du réseau virtuel
Accès sortant par défaut
ｇ DIDACTICIEL
Filtrer le trafic réseau avec des groupes de sécurité réseau
Restreindre l’accès réseau à l’aide de points de terminaison de service
Utiliser des groupes de sécurité d’application
ｄ ENTRAINEMENT
Sécuriser et isoler l’accès aux ressources Azure
Connecter des réseaux virtuels
ｐ CONCEPT
Peering de réseau virtuel
FAQ sur le peering de réseaux virtuels
ｇ DIDACTICIEL
Connecter des réseaux virtuels avec le peering de réseaux virtuels
ｃ GUIDE PRATIQUE
Même mode de déploiement - même abonnement
Même modèle de déploiement - abonnements différents
Modèles de déploiement différents - même abonnement
Modèles de déploiement différents - abonnements différents

ｄ ENTRAINEMENT
Communiquer sur un réseau virtuel avec le peering
Router le trafic
ｐ CONCEPT
Router le trafic réseau avec des tables de routage
ｇ DIDACTICIEL
Router le trafic réseau - Portail
ｄ ENTRAINEMENT
Gérer et contrôler le flux de trafic dans votre déploiement Azure à l’aide de routes
Créer des adresses IP
ｐ CONCEPT
Types d’adresses IP et méthodes d’allocation
ｃ GUIDE PRATIQUE
Créer, modifier ou supprimer une adresse IP publique
Ajouter une adresse IP publique sur une machine virtuelle
Créer une machine virtuelle avec une adresse IP statique
Configurer une adresse IP privée statique pour une machine virtuelle
Attribuer plusieurs adresses IP à une machine virtuelle
Créer un IPv6 pour des réseaux virtuels
ｐ CONCEPT
Qu’est-ce que le protocole IPv6 pour réseau virtuel Azure ?

Qu est ce que e p otoco e 6 pou éseau tue ue?
｀ DÉPLOYER
Déployer une application double pile IPV6 - Standard Load Balancer
Surveillance des réseaux virtuels
ｐ CONCEPT
Point d’accès terminal de réseau virtuel (TAP)
FAQ sur le TAP de réseau virtuel
ｃ GUIDE PRATIQUE
Créer un TAP de réseau virtuel
Gérer les services IP
ｐ CONCEPT
Types d’adresses IP et méthodes d’allocation
Qu’est-ce que le protocole IPv6 pour réseau virtuel Azure ?
Préfixe d’adresse IP publique
ｃ GUIDE PRATIQUE
Créer, modifier ou supprimer une adresse IP publique
Déployer une application double pile IPV6
Créer, changer ou supprimer un préfixe d’adresse IP publique
Découvrir l’architecture de réseau virtuel
ｅ VUE D’ENSEMBLE
Conception de l’architecture réseau
ｄ
ｄ ENTRAINEMENT
Concevoir une infrastructure de réseau dans Azure
ｉ RÉFÉRENCE
Connecter un réseau local à Azure
Implémenter un réseau hybride sécurisé
Topologie réseau hub-and-spoke dans Azure
Scénarios de haute disponibilité et de reprise d’activité pour les applications IaaS
Informations de référence
ｉ RÉFÉRENCE
Azure CLI
Azure PowerShell
REST
Présentation du réseau virtuel Azure
Article • 15/05/2023
Le Réseau virtuel Azure est le composant fondamental de votre réseau privé dans Azure.
Le réseau virtuel permet à de nombreux types de ressources Azure, telles que les
machines virtuelles (VM) Azure, de communiquer de manière sécurisée entre elles, avec
Internet et avec les réseaux locaux. Un réseau virtuel est similaire à un réseau
traditionnel que vous utiliseriez dans votre propre centre de données. Cependant, le
réseau virtuel Microsoft Azure apporte les avantages de l’infrastructure Azure tels que la
mise à l’échelle, la disponibilité et l’isolation.
Pourquoi utiliser un réseau virtuel Azure ?

Le réseau virtuel Azure permet aux ressources Azure de communiquer de manière
sécurisée entre elles, avec Internet et sur des réseaux locaux.
Les principaux scénarios que vous pouvez exécuter avec un réseau virtuel incluent :
La communication de ressources Azure avec Internet
La communication entre des ressources Azure
La communication avec des ressources locales
Filtrage du trafic réseau
Routage du trafic réseau
Intégration aux services Azure.
Communiquer avec Internet

Toutes les ressources d’un réseau virtuel peuvent communiquer en sortie vers Internet,
par défaut. Vous pouvez effectuer des communications entrantes vers une ressource en
lui assignant une adresse IP publique ou un équilibreur de charge public. Vous pouvez
également utiliser des adresses IP publiques, une passerelle NAT ou un équilibreur de
charge public pour gérer vos connexions sortantes. Pour en savoir plus sur les
connexions sortantes dans Azure, consultez Connexions sortantes, Adresses IP publiques
et passerelle NAT et Équilibreur de charge.
７ Notes
Lorsque vous utilisez un Standard Load Balancer (équilibreur de charge standard)
interne, une connectivité sortante n’est pas disponible jusqu’à ce que vous
définissiez le fonctionnement des connexions sortantes pour travailler avec une
adresse IP publique au niveau de l’instance ou un équilibreur de charge public.
Communiquer entre les ressources Azure

Les ressources Azure communiquent en toute sécurité entre elles de l’une des manières
suivantes :
Via un réseau virtuel : vous pouvez déployer des machines virtuelles et d’autres
types de ressources Azure sur un réseau virtuel. Parmi les exemples de ressources,
on peut citer les environnements Azure App Service Environment, Azure
Kubernetes Service (AKS) et les Virtual Machine Scale Sets Azure. Pour obtenir la
liste complète des ressources Azure que vous pouvez déployer sur un réseau
virtuel, consultez Intégration des services de réseau virtuel.
Via un point de terminaison de service de réseau virtuel : étendez votre espace

d’adressage privé de réseau virtuel et l’identité de votre réseau virtuel aux services
Azure. Les comptes de stockage Azure et Azure SQL Database, via une connexion
directe, sont des exemples de ressources. Les points de terminaison de service
vous permettent de sécuriser vos ressources critiques du service Azure pour un
réseau virtuel uniquement. Pour plus d’informations, consultez Présentation des
points de terminaison de service de réseau virtuel.
Avec l’appairage VNet : vous pouvez connecter des réseaux virtuels entre eux, ce
qui permet aux ressources de ces réseaux virtuels de communiquer entre elles à
l’aide d’un appairage de réseaux virtuels. Les réseaux virtuels que vous connectez
peuvent être situés dans des régions Azure identiques ou différentes. Pour en
savoir plus, consultez Peering de réseaux virtuels.
Communiquer avec les ressources locales

Vous pouvez connecter vos ordinateurs et réseaux locaux à un réseau virtuel à l’aide de
n’importe quelle option suivante :
Réseau privé virtuel (VPN) de point à site : connexion établie entre un réseau
virtuel et un ordinateur unique de votre réseau. Chaque ordinateur qui doit établir
une connexion avec un réseau virtuel doit configurer ses connexions. Ce type de
connexion est utile si vous n’êtes pas familiarisé avec Azure, ou pour les
développeurs car elle nécessite peu voire pas de modifications de votre réseau
existant. La communication entre votre ordinateur et un réseau virtuel passe par un
tunnel chiffré via Internet. Pour plus d’informations, consultez VPN de point à site.
VPN de site à site : connexion établie entre votre appareil VPN local et une
passerelle VPN Azure déployée dans un réseau virtuel. Ce type de connexion
permet à n’importe quelle ressource locale de votre choix d’accéder à un réseau
virtuel. La communication entre votre appareil VPN local et une passerelle VPN
Azure passe par un tunnel chiffré via Internet. Pour plus d’informations, consultez
VPN de site à site.
Azure ExpressRoute : connexion établie entre votre réseau et Azure via un

partenaire ExpressRoute. Cette connexion est privée. Toutefois, le trafic ne transite
pas par Internet. Pour plus d’informations, consultez ExpressRoute.
Filtrer le trafic
Vous pouvez filtrer le trafic réseau entre les sous-réseaux à l’aide d’une des deux options
suivantes :
Groupes de sécurité réseau : les groupes de sécurité réseau et les groupes de

sécurité d’application peuvent contenir plusieurs règles de sécurité entrantes et
sortantes. Ces règles vous permettent de filtrer le trafic échangé avec les
ressources par adresse IP source ou de destination, port ou protocole. Pour en
savoir plus, consultez Groupes de sécurité réseau et Groupes de sécurité
d’application.
Appliances virtuelles réseau : une appliance virtuelle réseau est une machine
virtuelle exécutant une fonction réseau, telle qu’un pare-feu, l’optimisation du
WAN ou une autre fonction réseau. Pour afficher la liste des appliances virtuelles
réseau disponibles que vous pouvez déployer dans un réseau virtuel, consultez
Place de marché Microsoft Azure .
Router le trafic
Les itinéraires Azure se chargent de l’acheminement entre les sous-réseaux, les réseaux
virtuels connectés, les réseaux locaux et Internet, par défaut. Vous pouvez implémenter
une ou les deux options suivantes pour remplacer les itinéraires par défaut créés par
Azure :
Tables de routage : vous pouvez créer des tables de routage personnalisées avec
des itinéraires qui contrôlent où le trafic est acheminé pour chaque sous-réseau.
Découvrez-en plus sur les tables de routage.
Itinéraires BGP : si vous connectez votre réseau virtuel à votre réseau local via une
connexion ExpressRoute ou la passerelle VPN Azure, vous pouvez propager vos
itinéraires BGP locaux à vos réseaux virtuels. En savoir plus sur l’utilisation du
protocole BGP avec la passerelle VPN Azure et ExpressRoute.
Intégration d’un réseau virtuel pour les services Azure

L’intégration des services Azure à un réseau virtuel Azure permet un accès privé au
service à partir de machines virtuelles ou de ressources de calcul dans le réseau virtuel.
Vous pouvez intégrer des services Azure dans votre réseau virtuel, grâce aux options
suivantes :
Déploiement d’instances dédiées du service dans un réseau virtuel. Les services

sont alors accessibles de manière privée dans le réseau virtuel, et à partir des
réseaux locaux.
Utilisation de Liaison privée pour accéder en privé à une instance spécifique du

service à partir de votre réseau virtuel et de réseaux locaux.
Vous pouvez également accéder au service à l’aide de points de terminaison

publics en étendant un réseau virtuel au service par le biais de points de
terminaison de service. Les points de terminaison de service permettent de
sécuriser les ressources de service au sein du réseau virtuel.
Limites du réseau virtuel Azure

Le nombre de ressources Azure que vous pouvez déployer est limité. La plupart des
limites de mise en réseau Azure sont des valeurs maximales. Toutefois, vous pouvez
augmenter certaines limites de mise en réseau comme spécifié dans la page consacrée
aux limites de réseau virtuel.
Réseaux virtuels et zones de disponibilité

Les réseaux virtuels et les sous-réseaux couvrent toutes les zones de disponibilité d’une
région. Vous n’avez pas besoin de les diviser par zones de disponibilité pour prendre en
charge les ressources zonales. Par exemple, si vous configurez une machine virtuelle
zonale, vous n’avez pas besoin de prendre en compte le réseau virtuel quand vous
sélectionnez la zone de disponibilité pour la machine virtuelle. Il en va de même pour les
autres ressources zonales.
Tarifs
L’utilisation du réseau virtuel Microsoft Azure est gratuite. Des frais standards
s’appliquent aux ressources telles que les machines virtuelles et d’autres produits. Pour
plus d’informations, voir la tarification des réseaux virtuels et la calculatrice de prix
Azure.
Étapes suivantes
Découvrez les concepts et bonnes pratiques du réseau virtuel Azure.
Pour commencer à utiliser un réseau virtuel, créez-en un, déployez-y plusieurs

machines virtuelles et communiquez entre les machines virtuelles. Pour en savoir
plus, consultez l’article de démarrage rapide Créer un réseau virtuel.
Module Learn : Présentation des réseaux virtuels Azure

Démarrage rapide : Utiliser le Portail
Azure pour créer un réseau virtuel
Article • 09/06/2023
Ce guide de démarrage rapide explique comment créer un réseau virtuel à l’aide du

Portail Azure. Vous créez ensuite deux machines virtuelles dans le réseau, vous déployez
Azure Bastion pour vous connecter en toute sécurité aux machines virtuelles à partir
d’Internet et communiquer en privé entre les machines virtuelles.
Un réseau virtuel est l’élément de construction fondamental pour les réseaux privés
dans Azure. Le réseau virtuel Microsoft Azure permet à des ressources Azure, comme
des machines virtuelles, de communiquer de manière sécurisée entre elles et sur
Internet.
Prérequis
Compte Azure avec un abonnement actif. Vous pouvez créer un compte
gratuitement .
Connexion à Azure
Connectez-vous au portail Azure avec votre compte Azure.
Créer un réseau virtuel et un hôte bastion

La procédure suivante crée un réseau virtuel avec un sous-réseau de ressources, un
sous-réseau Azure Bastion et un hôte Azure Bastion.
1. Dans le portail, recherchez et sélectionnez Réseaux virtuels.
2. Dans la page Réseaux virtuels, sélectionnez Créer.

3. Sous l’onglet Général de la page Créer un réseau virtuel, entrez ou sélectionnez
les informations suivantes :
Paramètre Valeur
Détails du projet
Abonnement Sélectionnez votre abonnement.
Resource group Sélectionnez Créer nouveau.

Entrez test-rg dans Nom.
Sélectionnez OK.
Détails de l’instance
Nom Entrez vnet-1.
Région Sélectionnez USA Est.
4. Sélectionnez Suivant : Adresses IP dans la partie inférieure de la page.
5. Dans l’onglet Adresses IP, sous Espace d’adressage IPv4, sélectionnez l’icône de
corbeille pour supprimer tout espace d’adressage qui apparaît déjà, puis entrez
10.0.0.0/16.
6. Sélectionnez + Ajouter un sous-réseau.
7. Dans Ajouter un sous-réseau, saisissez ou sélectionnez les informations suivantes :
Paramètre Valeur
Nom du sous-réseau Entrez subnet-1.
Plage d’adresses de sous-réseau Entrez 10.0.0.0/24.
8. Sélectionnez Ajouter.
9. Sélectionnez Suivant : Sécurité en bas de la page.
10. Sous l’onglet Sécurité, dans BastionHost, sélectionnez Activer.
７ Notes
Azure Bastion utilise votre navigateur web pour se connecter aux machines
virtuelles de votre réseau virtuel au moyen de SSH (Secure Shell) ou RDP
(Remote Desktop Protocol) à l’aide de leurs adresses IP privées. Les machines
virtuelles ne requièrent pas d’adresse IP publique, de logiciel client ou de
configuration spéciale. Pour plus d’informations sur Azure Bastion, voir Azure
Bastion.
11. Entrez ou sélectionnez les informations suivantes :
Paramètre Valeur
Nom du bastion Entrez bastion.
Espace d’adressage AzureBastionSubnet Entrez 10.0.1.0/26.
Adresse IP publique Sélectionnez Créer nouveau.

Entrez public-ip dans Nom.
Sélectionnez OK.
12. Sélectionnez Vérifier + créer dans la partie inférieure de l’écran, puis une fois la
validation réussie, sélectionnez Créer.
Créer des machines virtuelles

La procédure suivante crée deux machines virtuelles nommées vm-1 et vm-2 dans le
réseau virtuel.
1. Dans le portail, recherchez et sélectionnez Machines virtuelles.
2. Dans Machines virtuelles, sélectionnez + Créer, puis Machine virtuelle Azure.
3. Sous l’onglet Général de la page Créer une machine virtuelle, entrez ou

sélectionnez les informations suivantes :
Paramètre Valeur
Détails du projet
Resource group Sélectionnez test-rg.
Nom de la machine virtuelle Entrez vm-1.
Options de disponibilité Sélectionnez Aucune redondance d’infrastructure

requise.
Type de sécurité Conservez la valeur par défaut Standard.
Image Sélectionnez Ubuntu Server 22.04 LTS - x64 Gen2.
Architecture de machine Laissez la valeur par défaut x64.

virtuelle
Taille Sélectionnez une taille.
Compte administrateur
Type d'authentification Sélectionnez Mot de passe.
Nom d’utilisateur entrez azureuser.
Mot de passe Entrez un mot de passe.
Confirmer le mot de passe Entrez de nouveau le mot de passe.

Paramètre Valeur
Règles des ports d’entrée
Aucun port d’entrée public Sélectionnez Aucun.
4. Sélectionnez l’onglet Réseau en haut de la page.
5. Entrez ou sélectionnez les informations suivantes sous l’onglet Réseau :
Paramètre Valeur
Interface réseau
Réseau virtuel Sélectionnez vnet-1.
Subnet Sélectionnez subnet-1 (10.0.0.0/24).
Adresse IP publique Sélectionnez Aucun.
Groupe de sécurité réseau de la carte Sélectionnez Avancé.

réseau
Configurer un groupe de sécurité Sélectionnez Créer nouveau.

réseau Entrez nsg-1 pour le nom.
Pour le reste, laissez les valeurs par défaut et
sélectionnez OK.
6. Pour les autres paramètres, laissez les valeurs par défaut, puis sélectionnez Vérifier
+ créer.
7. Passez en revue les paramètres, puis sélectionnez Créer.
8. Répétez les étapes précédentes pour créer une deuxième machine virtuelle avec
les paramètres suivants :
Paramètre Valeur
Nom de la machine virtuelle Entrez vm-2.
Réseau virtuel Sélectionnez vnet-1.
Subnet Sélectionnez subnet-1 (10.0.0.0/24).
Groupe de sécurité réseau de la carte réseau Sélectionnez Avancé.
Configurer un groupe de sécurité réseau Sélectionnez nsg-1.

７ Notes
Les machines virtuelles d’un réseau virtuel avec un hôte bastion n’ont pas besoin
d’adresses IP publiques. Bastion fournit l’adresse IP publique et les machines
virtuelles utilisent des adresses IP privées pour communiquer au sein du réseau.
Vous pouvez supprimer les adresses IP publiques des machines virtuelles des
réseaux virtuels hébergés par bastion. Pour plus d’informations, consultez Dissocier
une adresse IP publique d’une machine virtuelle Azure.
７ Notes
Azure fournit une adresse IP d’accès sortant par défaut pour les machines virtuelles
qui n’ont pas d’adresse IP publique ou qui se trouvent dans le pool de back-ends
d’un Azure Load Balancer de base interne. Le mécanisme d’adresse IP d’accès
sortant par défaut fournit une adresse IP sortante qui n’est pas configurable.
L’adresse IP d’accès sortant par défaut est désactivée quand une adresse IP
publique est affectée à la machine virtuelle, quand la machine virtuelle est placée
dans le pool back-end d’un équilibreur de charge standard, avec ou sans règles de
trafic sortant, ou si une ressource de passerelle NAT de réseau virtuel Azure est
affectée au sous-réseau de la machine virtuelle.
Les machines virtuelles créées par des groupes de machines virtuelles identiques en
mode d’orchestration flexible n’ont pas d’accès sortant par défaut.
Pour plus d’informations sur les connexions sortantes dans Azure, consultez Accès
sortant par défaut dans Azure et Utiliser la traduction d’adresses réseau sources
(SNAT) pour les connexions sortantes.
Connexion à une machine virtuelle

2. Dans la page Machines virtuelles, sélectionnez vm-1.
3. Dans la page Vue d’ensemble de vm-1, sélectionnez Connecter.
4. Dans la page Se connecter à la machine virtuelle, sélectionnez l’onglet Bastion.
5. Sélectionnez Utiliser Bastion.

6. Entrez le nom d’utilisateur et le mot de passe que vous avez créés au moment de
créer la machine virtuelle, puis sélectionnez Connecter.
Établir une communication entre les machines

virtuelles
1. À l’invite bash pour vm-1, entrez ping -c 4 vm-2 .
Vous recevez une réponse similaire au message suivant :
Sortie
azureuser@vm-1:~$ ping -c 4 vm-2

PING vm-2.3bnkevn3313ujpr5l1kqop4n4d.cx.internal.cloudapp.net
(10.0.0.5) 56(84) bytes of data.
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=1 ttl=64
time=1.83 ms
time=0.987 ms
time=0.864 ms
time=0.890 ms
2. Fermez la connexion Bastion à VM1.
3. Répétez les étapes décrites dans Se connecter à une machine virtuelle pour vous
connecter à VM2.
Sortie

(10.0.0.4) 56(84) bytes of data.
time=0.695 ms
time=0.896 ms
time=3.43 ms
time=0.780 ms
Nettoyer les ressources

Lorsque vous avez fini d’utiliser la ressources créées, vous pouvez supprimer le groupe
de ressources et toutes ses ressources.
1. Depuis le portail Azure, recherchez et sélectionnez Groupes de ressources.
2. Dans la page Groupes de ressources, sélectionnez le groupe de ressources test-rg.
3. Dans la page test-rg, sélectionnez Supprimer le groupe de ressources.
4. Entrez test-rg dans Entrez le nom du groupe de ressources pour confirmer la

suppression, puis sélectionnez Supprimer.
Étapes suivantes
Dans ce guide de démarrage rapide, vous avez créé un réseau virtuel avec deux sous-
réseaux, l’un contenant deux machines virtuelles, l’autre pour Azure Bastion. Vous avez
déployé Azure Bastion et vous l’avez utilisé pour vous connecter aux machines virtuelles,
ensuite vous avez communiqué de manière sécurisée entre les machines virtuelles. Pour
plus d’informations sur les paramètres de réseau virtuel, consultez Créer, changer ou
supprimer un réseau virtuel.
La communication privée entre les machines virtuelles n’est pas limitée dans un réseau
virtuel. Poursuivez avec l’article suivant pour en savoir plus sur la configuration de
différents types de communications dans un réseau de machines virtuelles.
Filtrer le trafic réseau

Démarrage rapide : utiliser
Azure PowerShell pour créer un réseau
virtuel
Article • 28/03/2023 • 6 minutes de lecture
Ce démarrage rapide vous explique comment créer un réseau virtuel à l’aide d’Azure
PowerShell. Vous créez ensuite deux machines virtuelles dans le réseau, vous vous
connectez en toute sécurité aux machines virtuelles à partir d’Internet et vous
communiquez en privé entre les machines virtuelles.
dans Azure. Le Réseau virtuel Azure permet à des ressources Azure, comme des
machines virtuelles, de communiquer de manière sécurisée entre elles et sur Internet.
Prérequis
gratuitement .
Azure Cloud Shell ou Azure PowerShell.
Les étapes de ce démarrage rapide exécutent les applets de commande Azure

PowerShell de manière interactive dans Azure Cloud Shell. Pour exécuter les
commandes dans le Cloud Shell, sélectionnez Ouvrir Cloudshell dans le coin
supérieur droit d’un bloc de code. Sélectionnez Copier pour copier le code, puis
collez-le dans Cloud Shell pour l’exécuter. Vous pouvez également exécuter le
Cloud Shell à partir du Portail Azure.
Vous pouvez également installer Azure PowerShell localement pour exécuter les
applets de commande. Les étapes de cet article nécessitent le module Azure
PowerShell version 5.4.1 ou ultérieure. Exécutez Get-Module -ListAvailable Az
pour rechercher la version installée. Si vous devez effectuer une mise à niveau,
consultez Mise à jour d’Azure PowerShell.
Si vous exécutez PowerShell localement, exécutez Connect-AzAccount pour vous

connecter à Azure.
Créez un réseau virtuel

1. Tout d’abord, utilisez New-AzResourceGroup pour créer un groupe de ressources
afin d’héberger le réseau virtuel. Exécutez le code suivant pour créer un groupe de
ressources nommé TestRG dans la région Azure eastus .
Azure PowerShell
$rg = @{
Name = 'TestRG'
Location = 'eastus'
}
New-AzResourceGroup @rg
2. Utilisez New-AzVirtualNetwork pour créer un réseau virtuel nommé VNet avec le

préfixe d’adresse IP 10.0.0.0/16 dans le groupe de ressources TestRG et
l’emplacement eastus .
Azure PowerShell
$vnet = @{
Name = 'VNet'
ResourceGroupName = 'TestRG'
Location = 'eastus'
AddressPrefix = '10.0.0.0/16'
}
$virtualNetwork = New-AzVirtualNetwork @vnet
3. Azure déploie des ressources vers un sous-réseau au sein d’un réseau virtuel.
Utilisez Add-AzVirtualNetworkSubnetConfig pour créer une configuration de sous-
réseau nommée default avec un préfixe d’adresse 10.0.0.0/24 .
Azure PowerShell
$subnet = @{
Name = 'default'
VirtualNetwork = $virtualNetwork
}
$subnetConfig = Add-AzVirtualNetworkSubnetConfig @subnet
4. Associez ensuite la configuration du sous-réseau au réseau virtuel à l’aide de Set-

AzVirtualNetwork.
Azure PowerShell
$virtualNetwork | Set-AzVirtualNetwork
Déployer Azure Bastion
Azure Bastion utilise votre navigateur web pour se connecter aux machines virtuelles de
votre réseau virtuel au moyen de SSH (Secure Shell) ou RDP (Remote Desktop Protocol)
à l’aide de leurs adresses IP privées. Les machines virtuelles ne requièrent pas d’adresse
IP publique, de logiciel client ou de configuration spéciale. Pour plus d’informations sur
Azure Bastion, voir Azure Bastion.
1. Configurez le sous-réseau Azure Bastion pour votre réseau virtuel. Ce sous-réseau

est réservé exclusivement aux ressources Azure Bastion et doit être nommé
AzureBastionSubnet .
Azure PowerShell
$subnet = @{
Name = 'AzureBastionSubnet'
VirtualNetwork = $virtualNetwork
}
$subnetConfig = Add-AzVirtualNetworkSubnetConfig @subnet
2. Définissez la configuration.
Azure PowerShell
3. Créez une adresse IP publique pour Azure Bastion. L’hôte bastion utilise l’adresse
IP publique pour accéder au protocole SSH(Secure Shell) et au protocole RDP sur
le port 443.
Azure PowerShell
$publicip = New-AzPublicIpAddress -ResourceGroupName "TestRG" -name

"VNet-ip" -location "EastUS" -AllocationMethod Static -Sku Standard
4. Utilisez la commande New-AzBastion pour créer un hôte Azure Bastion de

référence SKU Standard dans AzureBastionSubnet.
Azure PowerShell
New-AzBastion -ResourceGroupName "TestRG" -Name "VNet-bastion" `

-PublicIpAddressRgName "TestRG" -PublicIpAddressName "VNet-ip" `
-VirtualNetworkRgName "TestRG" -VirtualNetworkName "VNet" `
-Sku "Standard"
Le déploiement des ressources Bastion prend environ 10 minutes. Vous pouvez créer
des machines virtuelles dans la section suivante lors du déploiement de Bastion sur
votre réseau virtuel.

Utilisez New-AzVM pour créer deux machines virtuelles nommées VM1 et VM2 dans le
sous-réseau default du réseau virtuel. Lorsque vous êtes invité à entrer des
informations d’identification, entrez des noms d’utilisateur et des mots de passe pour
les machines virtuelles.
1. Pour créer la première machine virtuelle, exécutez le code suivant :
Azure PowerShell
$vm1 = @{
Location = 'eastus'
Name = 'VM1'
VirtualNetworkName = 'VNet'
SubnetName = 'default'
}
New-AzVM @vm1
2. Pour créer la deuxième machine virtuelle, exécutez le code suivant :
Azure PowerShell
$vm2 = @{
Location = 'eastus'
Name = 'VM2'
VirtualNetworkName = 'VNet'
SubnetName = 'default'
}
New-AzVM @vm2
 Conseil
Vous pouvez utiliser l’option -AsJob pour créer une machine virtuelle en arrière-
plan pendant que vous poursuivez d’autres tâches. Par exemple, exécutez New-AzVM
@vm1 -AsJob . Lorsqu’Azure commence la création de la machine virtuelle en arrière-
plan, vous obtenez quelque chose similaire à l’entrée suivante :

PowerShell
Id Name PSJobTypeName State HasMoreData

Location Command
-- ---- ------------- ----- ----------- --
------ -------
1 Long Running... AzureLongRun... Running True
localhost New-AzVM
Il ne faut que quelques minutes à Azure pour créer les machines virtuelles. Une fois
qu’Azure a fini de créer les machines virtuelles, l’application retourne la sortie vers
PowerShell.
７ Notes
Les adresses IP publiques ne sont pas nécessaires pour les machines virtuelles d’un
réseau virtuel avec un hôte Bastion. Bastion fournit l’adresse IP publique et les
machines virtuelles utilisent des adresses IP privées pour communiquer au sein du
réseau. Vous pouvez supprimer les adresses IP publiques de n’importe laquelle des
machines virtuelles dans des réseaux virtuels hébergés par Bastion. Pour plus
d’informations, consultez l’article Dissocier une adresse IP publique d’une machine
virtuelle Azure.
Se connecter à une machine virtuelle

2. Dans la page Machines virtuelles, sélectionnez VM1.
3. En haut de la page VM1, sélectionnez la flèche déroulante après Se connecter, puis

Bastion.
4. Dans la page Bastion, entrez le nom d’utilisateur et le mot de passe créés pour la
machine virtuelle, puis sélectionnez Se connecter.

virtuelles
1. À partir du bureau de VM1, ouvrez PowerShell.
2. Entrez ping myVM2 . Vous recevez une réponse similaire au message suivant :
PowerShell
PS C:\Users\VM1> ping VM2
Pinging VM2.ovvzzdcazhbu5iczfvonhg2zrb.bx.internal.cloudapp.net with 32

bytes of data
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.0.0.5:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Le test Ping a échoué, car il utilise le protocole ICMP (Internet Control Message
Protocol). Par défaut, le protocole ICMP n’est pas autorisé par un pare-feu
Windows.
3. Pour autoriser l’entrée du protocole ICMP via un pare-feu Windows sur cette
machine virtuelle, entrez la commande suivante :
PowerShell
New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4
4. Fermez la connexion du bureau à distance vers VM1.
connecter à VM2.
6. À partir de PowerShell sur VM2, entrez ping VM1 .
Cette fois, vous recevez une réponse de réussite similaire au message suivant, car
vous avez autorisé le protocole ICMP via le pare-feu sur VM1.
Invite de commandes Windows
PS C:\Users\VM2> ping VM1
Pinging VM1.e5p2dibbrqtejhq04lqrusvd4g.bx.internal.cloudapp.net
[10.0.0.4] with 32 bytes of data:
Reply from 10.0.0.4: bytes=32 time=2ms TTL=128
Reply from 10.0.0.4: bytes=32 time<1ms TTL=128

Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 0ms
7. Fermez la connexion du bureau à distance vers VM2.

Lorsque vous en avez terminé avec le réseau virtuel et les machines virtuelles, utilisez
Remove-AzResourceGroup pour supprimer le groupe de ressources et toutes ses
ressources.
Azure PowerShell
Remove-AzResourceGroup -Name 'TestRG' -Force
Étapes suivantes
Dans ce démarrage rapide, vous avez créé un réseau virtuel avec un sous-réseau par
défaut contenant deux machines virtuelles. Vous avez déployé Azure Bastion et vous
l’avez utilisé pour vous connecter aux machines virtuelles, ensuite vous avez
communiqué de manière sécurisée entre les machines virtuelles. Pour plus
d’informations sur les paramètres de réseau virtuel, consultez Créer, changer ou
La communication privée entre les machines virtuelles d’un réseau virtuel n’est pas
illimitée. Poursuivez avec l’article suivant pour en savoir plus sur la configuration de
différents types de communications réseau de machines virtuelles.

Démarrage rapide : Utiliser Azure CLI
pour créer un réseau virtuel
Article • 12/06/2023
Ce guide de démarrage rapide vous montre comment créer un réseau virtuel au moyen
d’Azure CLI, l’interface de ligne de commande d’Azure. Vous créez ensuite deux
machines virtuelles dans le réseau, vous vous y connectez en toute sécurité à partir
d’Internet et vous communiquez en privé entre elles.
Internet.
Si vous n’avez pas d’abonnement Azure, créez un compte gratuit Azure avant de
commencer.
Prérequis
Utilisez l’environnement Bash dans Azure Cloud Shell. Pour plus d’informations,
consultez Démarrage rapide pour Bash dans Azure Cloud Shell.
Si vous préférez exécuter les commandes de référence de l’interface de ligne de

commande localement, installez l’interface Azure CLI. Si vous exécutez sur
Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker.
Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans
un conteneur Docker.
Si vous utilisez une installation locale, connectez-vous à Azure CLI à l’aide de la

commande az login. Pour finir le processus d’authentification, suivez les étapes
affichées dans votre terminal. Pour connaître les autres options de connexion,
consultez Se connecter avec Azure CLI.
Lorsque vous y êtes invité, installez l’extension Azure CLI lors de la première
utilisation. Pour plus d’informations sur les extensions, consultez Utiliser des
extensions avec Azure CLI.
Exécutez az version pour rechercher la version et les bibliothèques dépendantes

installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az
upgrade.
Créer un groupe de ressources

1. Utilisez la commande az group create pour créer un groupe de ressources afin
d’héberger le réseau virtuel. Exécutez le code suivant pour créer un groupe de
ressources nommé test-rg dans la région eastus2 Azure.
Azure CLI
az group create \
--name test-rg \
--location eastus2
Créer un réseau virtuel et un sous-réseau

1. Utilisez la commande az network vnet create pour créer un réseau virtuel nommé
vnet-1 avec un sous-réseau nommé subnet-1 dans le groupe de ressources test-rg.
Azure CLI
az network vnet create \

--name vnet-1 \
--resource-group test-rg \
--address-prefix 10.0.0.0/16 \
--subnet-name subnet-1 \
--subnet-prefixes 10.0.0.0/24

Azure Bastion utilise votre navigateur web pour se connecter aux machines virtuelles de
votre réseau virtuel au moyen de SSH (Secure Shell) ou RDP (Remote Desktop Protocol)
à l’aide de leurs adresses IP privées. Les machines virtuelles ne requièrent pas d’adresse
IP publique, de logiciel client ou de configuration spéciale. Pour plus d’informations sur
Azure Bastion, voir Azure Bastion.
1. Utilisez la commande az network vnet subnet create pour créer un sous-réseau

Azure Bastion pour votre réseau virtuel. Ce sous-réseau est exclusivement réservé
aux ressources Azure Bastion et doit être nommé AzureBastionSubnet.
Azure CLI
az network vnet subnet create \

--name AzureBastionSubnet \
--vnet-name vnet-1 \
--address-prefix 10.0.1.0/26
2. Créez une adresse IP publique pour Azure Bastion. Cette adresse IP est utilisée
pour se connecter à l’hôte Bastion à partir d’Internet. Utilisez la commande az
network public-ip create pour créer une adresse IP publique nommée public-ip
dans le groupe de ressources test-rg.
Azure CLI
az network public-ip create \

--name public-ip \
--sku Standard \
--location eastus2 \
--zone 1 2 3
3. Utilisez la commande az network bastion create pour créer un hôte Azure Bastion
dans le azureBastionSubnet de votre réseau virtuel.
Azure CLI
az network bastion create \

--name bastion \
--public-ip-address public-ip \
--vnet-name vnet-1 \
--location eastus2
Le déploiement des ressources Bastion prend environ 10 minutes. Vous pouvez créer
des machines virtuelles dans la section suivante lors du déploiement de Bastion sur
Utilisez la commande az vm create pour créer deux machines virtuelles nommées VM1
et VM2 dans le sous-réseau subnet-1 du réseau virtuel. Lorsque vous êtes invité à entrer
des informations d’identification, entrez des noms d’utilisateur et des mots de passe
pour les machines virtuelles.
1. Pour créer la première machine virtuelle, utilisez la commande suivante :
Azure CLI
az vm create \
--admin-username azureuser \
--authentication-type password \
--name vm-1 \
--image Ubuntu2204 \
--public-ip-address ""
2. Pour créer la deuxième machine virtuelle, utilisez la commande suivant :
Azure CLI
az vm create \
--authentication-type password \
--name vm-2 \
--image Ubuntu2204 \
--public-ip-address ""
 Conseil
Vous pouvez également utiliser l’option --no-wait pour créer une machine virtuelle
en arrière-plan pendant que vous poursuivez d’autres tâches.
La création des machines virtuelles peut prendre plusieurs minutes. Une fois la création
des différentes machines virtuelles effectuée par Azure, Azure CLI retourne une sortie
semblable au message suivant :
Sortie
{
"fqdns": "",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/test-
rg/providers/Microsoft.Compute/virtualMachines/vm-2",
"location": "eastus2",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "10.0.0.5",
"publicIpAddress": "",
"resourceGroup": "test-rg"
"zones": ""
}
７ Notes
réseau. Vous pouvez supprimer les adresses IP publiques de n’importe laquelle des
machines virtuelles dans des réseaux virtuels hébergés par Bastion. Pour plus
d’informations, consultez Dissocier une adresse IP publique d’une machine
virtuelle Azure.
７ Notes

2. Dans la page Machines virtuelles, sélectionnez vm-1.
3. Dans la page Vue d’ensemble de vm-1, sélectionnez Connecter.
4. Dans la page Se connecter à la machine virtuelle, sélectionnez l’onglet Bastion.
5. Sélectionnez Utiliser Bastion.
6. Entrez le nom d’utilisateur et le mot de passe que vous avez créés au moment de
créer la machine virtuelle, puis sélectionnez Connecter.

virtuelles
Sortie

(10.0.0.5) 56(84) bytes of data.
time=1.83 ms
time=0.987 ms
time=0.864 ms
time=0.890 ms
connecter à VM2.
Sortie

(10.0.0.4) 56(84) bytes of data.
time=0.695 ms
time=0.896 ms
time=3.43 ms
time=0.780 ms

Lorsque vous en avez terminé avec le réseau virtuel et les machines virtuelles, utilisez az
group delete pour supprimer le groupe de ressources et toutes ses ressources.
Azure CLI
az group delete \
--name test-rg \
--yes
Étapes suivantes
Dans ce démarrage rapide, vous avez créé un réseau virtuel avec un sous-réseau par
défaut contenant deux machines virtuelles. Vous avez déployé Azure Bastion et vous
l’avez utilisé pour vous connecter aux machines virtuelles, ensuite vous avez
communiqué de manière sécurisée entre les machines virtuelles. Pour plus
d’informations sur les paramètres de réseau virtuel, consultez Créer, changer ou
La communication privée entre machines virtuelles d’un réseau virtuel est illimitée par
défaut. Poursuivez avec l’article suivant pour en savoir plus sur la configuration de
différents types de communications dans un réseau de machines virtuelles.

Démarrage rapide : utiliser des modèles
Bicep pour créer un réseau virtuel
Ce guide de démarrage rapide vous montre comment créer un réseau virtuel avec deux
machines virtuelles, puis déployer Azure Bastion sur le réseau virtuel, à l’aide de modèles
Bicep. Vous vous connectez alors en toute sécurité aux machines virtuelles à l’aide
d’Azure Bastion via Internet, et communiquez en privé entre les deux machines
virtuelles.
Un réseau virtuel est un élément de construction fondamental pour les réseaux privés
Internet.
Bicep est un langage spécifique à un domaine (DSL) qui utilise la syntaxe déclarative
pour déployer des ressources Azure. Il fournit une syntaxe concise, une cohérence des
types fiable et une prise en charge de la réutilisation du code. Bicep offre la meilleure
expérience de création pour vos solutions d’infrastructure en tant que code dans Azure.
Prérequis
gratuitement .
Pour déployer les fichiers Bicep avec Azure CLI ou PowerShell installé.
INTERFACE DE LIGNE DE COMMANDE
1. Installez Azure CLI localement pour exécuter les commandes. Vous avez
besoin d’Azure CLI, version 2.0.28 ou ultérieure. Exécutez az version pour
connaître votre version installée et les bibliothèques dépendantes, puis
exécutez az upgrade pour effectuer une mise à niveau.
2. Connectez-vous à Azure à l’aide de la commande az login.
Créer le réseau virtuel et les machines virtuelles

Ce guide de démarrage rapide utilise le modèle Bicep Deux machines virtuelles dans un
réseau virtuel à partir des modèles de démarrage rapide Azure pour créer le réseau
virtuel, le sous-réseau de ressources et les machines virtuelles. Le modèle Bicep définit
les ressources Azure suivantes :
Microsoft.Network virtualNetworks : permet de créer un réseau virtuel Azure.

Microsoft.Network virtualNetworks/subnets : permet de créer un sous-réseau pour
Microsoft.Compute virtualMachines : permet de créer les machines virtuelles.
Microsoft.Compute availabilitySets : permet de créer un groupe à haute
disponibilité.
Microsoft.Network networkInterfaces : permet de créer des interfaces réseau.
Microsoft.Network loadBalancers : permet de créer un équilibreur de charge
interne.
Microsoft.Storage storageAccounts : permet de créer un compte de stockage.
Examiner le fichier Bicep :
Bicep
@description('Admin username')
param adminUsername string
@description('Admin password')
@secure()
param adminPassword string
@description('Prefix to use for VM names')

param vmNamePrefix string = 'BackendVM'
@description('Location for all resources.')

param location string = resourceGroup().location
@description('Size of the virtual machines')

param vmSize string = 'Standard_D2s_v3'
var availabilitySetName = 'AvSet'

var storageAccountType = 'Standard_LRS'
var storageAccountName = uniqueString(resourceGroup().id)
var virtualNetworkName = 'vNet'
var subnetName = 'backendSubnet'
var loadBalancerName = 'ilb'
var networkInterfaceName = 'nic'
var subnetRef = resourceId('Microsoft.Network/virtualNetworks/subnets',
virtualNetworkName, subnetName)
var numberOfInstances = 2
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-08-01' = {

name: storageAccountName
location: location
sku: {
name: storageAccountType
}
kind: 'StorageV2'
}
resource availabilitySet 'Microsoft.Compute/availabilitySets@2021-11-01' = {

name: availabilitySetName
location: location
sku: {
name: 'Aligned'
}
properties: {
platformUpdateDomainCount: 2
platformFaultDomainCount: 2
}
}
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2021-05-01' = {

name: virtualNetworkName
location: location
properties: {
addressSpace: {
addressPrefixes: [
'10.0.0.0/16'
]
}
subnets: [
{
name: subnetName
properties: {
addressPrefix: '10.0.2.0/24'
}
}
]
}
}
resource networkInterface 'Microsoft.Network/networkInterfaces@2021-05-01' =

[for i in range(0, numberOfInstances): {
name: '${networkInterfaceName}${i}'
location: location
properties: {
ipConfigurations: [
{
name: 'ipconfig1'
properties: {
privateIPAllocationMethod: 'Dynamic'
subnet: {
id: subnetRef
}
loadBalancerBackendAddressPools: [
{
id:
resourceId('Microsoft.Network/loadBalancers/backendAddressPools',
loadBalancerName, 'BackendPool1')
}
]
}
}
]
}
dependsOn: [
virtualNetwork
loadBalancer
]
}]
resource loadBalancer 'Microsoft.Network/loadBalancers@2021-05-01' = {

name: loadBalancerName
location: location
sku: {
name: 'Standard'
}
properties: {
frontendIPConfigurations: [
{
properties: {
subnet: {
id: subnetRef
}
privateIPAddress: '10.0.2.6'
privateIPAllocationMethod: 'Static'
}
name: 'LoadBalancerFrontend'
}
]
backendAddressPools: [
{
name: 'BackendPool1'
}
]
loadBalancingRules: [
{
properties: {
frontendIPConfiguration: {
id:
resourceId('Microsoft.Network/loadBalancers/frontendIpConfigurations',
loadBalancerName, 'LoadBalancerFrontend')
}
backendAddressPool: {
id:
resourceId('Microsoft.Network/loadBalancers/backendAddressPools',
loadBalancerName, 'BackendPool1')
}
probe: {
id: resourceId('Microsoft.Network/loadBalancers/probes',
loadBalancerName, 'lbprobe')
}
protocol: 'Tcp'
frontendPort: 80
backendPort: 80
idleTimeoutInMinutes: 15
}
name: 'lbrule'
}
]
probes: [
{
properties: {
protocol: 'Tcp'
port: 80
intervalInSeconds: 15
numberOfProbes: 2
}
name: 'lbprobe'
}
]
}
dependsOn: [
virtualNetwork
]
}
resource vm 'Microsoft.Compute/virtualMachines@2021-11-01' = [for i in

range(0, numberOfInstances): {
name: '${vmNamePrefix}${i}'
location: location
properties: {
availabilitySet: {
id: availabilitySet.id
}
hardwareProfile: {
vmSize: vmSize
}
osProfile: {
computerName: '${vmNamePrefix}${i}'
adminUsername: adminUsername
adminPassword: adminPassword
}
storageProfile: {
imageReference: {
publisher: 'MicrosoftWindowsServer'
offer: 'WindowsServer'
sku: '2019-Datacenter'
version: 'latest'
}
osDisk: {
createOption: 'FromImage'
}
}
networkProfile: {
networkInterfaces: [
{
id: networkInterface[i].id
}
]
}
diagnosticsProfile: {
bootDiagnostics: {
enabled: true
storageUri: storageAccount.properties.primaryEndpoints.blob
}
}
}
}]
Déployer le modèle Bicep

1. Enregistrez le fichier Bicep sur votre ordinateur sous main.bicep.
2. Déployez le fichier Bicep à l’aide d’Azure CLI ou d’Azure PowerShell.
Azure CLI
az group create --name TestRG --location eastus

az deployment group create --resource-group TestRG --template-file
main.bicep
Une fois le déploiement terminé, un message s’affiche pour indiquer que le déploiement
a réussi.

Azure Bastion utilise votre navigateur pour se connecter aux machines virtuelles de votre
réseau virtuel via le protocole SSH(Secure Shell) ou le protocole RDP à l’aide de leurs
adresses IP privées. Les machines virtuelles n’ont pas besoin d’adresses IP publiques, de
logiciels clients ou de configuration spéciale. Pour plus d’informations sur Azure Bastion,
voir Azure Bastion.
Utilisez le modèle Bicep Azure Bastion as a service à partir des modèles de démarrage
rapide Azure pour déployer et configurer Azure Bastion dans votre réseau virtuel. Ce
modèle Bicep définit les ressources Azure suivantes :
Microsoft.Network virtualNetworks/subnets : permet de créer un sous-réseau
AzureBastionSubnet.
Microsoft.Network bastionHosts : permet de créer l’hôte bastion.
Microsoft.Network publicIPAddresses : permet de créer une adresse IP publique
pour l’hôte Azure Bastion.
Microsoft Network networkSecurityGroups : permet de contrôler les paramètres du
groupe de sécurité réseau (NSG).
Examiner le fichier Bicep :
Bicep
@description('Name of new or existing vnet to which Azure Bastion should be

deployed')
param vnetName string = 'vnet01'
@description('IP prefix for available addresses in vnet address space')

param vnetIpPrefix string = '10.1.0.0/16'
@description('Specify whether to provision new vnet or deploy to existing

vnet')
@allowed([
'new'
'existing'
])
param vnetNewOrExisting string = 'new'
@description('Bastion subnet IP prefix MUST be within vnet IP prefix address

space')
param bastionSubnetIpPrefix string = '10.1.1.0/26'
@description('Name of Azure Bastion resource')

param bastionHostName string
@description('Azure region for Bastion and virtual network')

param location string = resourceGroup().location
var publicIpAddressName = '${bastionHostName}-pip'

var bastionSubnetName = 'AzureBastionSubnet'
resource publicIp 'Microsoft.Network/publicIPAddresses@2022-01-01' = {

name: publicIpAddressName
location: location
sku: {
name: 'Standard'
}
properties: {
publicIPAllocationMethod: 'Static'
}
}
// if vnetNewOrExisting == 'new', create a new vnet and subnet

resource newVirtualNetwork 'Microsoft.Network/virtualNetworks@2022-01-01' =
if (vnetNewOrExisting == 'new') {
name: vnetName
location: location
properties: {
addressSpace: {
addressPrefixes: [
vnetIpPrefix
]
}
subnets: [
{
name: bastionSubnetName
properties: {
addressPrefix: bastionSubnetIpPrefix
}
}
]
}
}
// if vnetNewOrExisting == 'existing', reference an existing vnet and create

a new subnet under it
resource existingVirtualNetwork 'Microsoft.Network/virtualNetworks@2022-01-
01' existing = if (vnetNewOrExisting == 'existing') {
name: vnetName
}
resource subnet 'Microsoft.Network/virtualNetworks/subnets@2022-01-01' = if
(vnetNewOrExisting == 'existing') {
parent: existingVirtualNetwork
name: bastionSubnetName
properties: {
addressPrefix: bastionSubnetIpPrefix
}
}
resource bastionHost 'Microsoft.Network/bastionHosts@2022-01-01' = {

name: bastionHostName
location: location
dependsOn: [
newVirtualNetwork
existingVirtualNetwork
]
properties: {
ipConfigurations: [
{
name: 'IpConf'
properties: {
subnet: {
id: subnet.id
}
publicIPAddress: {
id: publicIp.id
}
}
}
]
}
}
Déployer le modèle Bicep

1. Enregistrez le fichier Bicep sur votre ordinateur sous bastion.bicep.
2. Utilisez un éditeur de texte ou de code pour apporter les modifications suivantes

dans le fichier :
Ligne 2 : modifiez param vnetName string , remplacez 'vnet01' par 'VNet' .

Ligne 5 : modifiez param vnetIpPrefix string , remplacez '10.1.0.0/16' par
'10.0.0.0/16' .
Ligne 12 : modifiez param vnetNewOrExisting string , remplacez 'new' par
'existing' .
Ligne 15 : modifiez param bastionSubnetIpPrefix string , remplacez

'10.1.1.0/26' par '10.0.1.0/26' .
Ligne 18 : remplacez param bastionHostName string par param

bastionHostName = 'VNet-bastion' .
Les 18 premières lignes de votre fichier Bicep devraient maintenant ressembler à

ceci :
Bicep
@description('Name of new or existing vnet to which Azure Bastion

should be deployed')
param vnetName string = 'VNet'
@description('IP prefix for available addresses in vnet address space')

param vnetIpPrefix string = '10.0.0.0/16'
@description('Specify whether to provision new vnet or deploy to

existing vnet')
@allowed([
'new'
'existing'
])
param vnetNewOrExisting string = 'existing'
@description('Bastion subnet IP prefix MUST be within vnet IP prefix

address space')
param bastionSubnetIpPrefix string = '10.0.1.0/26'
@description('Name of Azure Bastion resource')

param bastionHostName = 'VNet-bastion'
3. Enregistrez le fichier bastion.bicep .
4. Déployez le fichier Bicep à l’aide d’Azure CLI ou d’Azure PowerShell.
Azure CLI
az deployment group create --resource-group TestRG --template-file

bastion.bicep
Une fois le déploiement terminé, un message s’affiche pour indiquer que le déploiement
a réussi.
７ Notes
réseau. Vous pouvez supprimer les adresses IP publiques de n’importe quelle
machine virtuelle dans des réseaux virtuels hébergés par Bastion. Pour plus
d’informations, consultez Dissocier une adresse IP publique d’une machine
virtuelle Azure.
Vérifier les ressources déployées

Utilisez Azure CLI, Azure PowerShell ou le portail Azure pour examiner les ressources
déployées.
Azure CLI
az resource list --resource-group TestRG

Se connecter à une machine virtuelle
1. Dans le portail Azure , recherchez et sélectionnez Machines virtuelles.
2. Sur la page Machines virtuelles, sélectionnez BackendVM1.
3. En haut de la page BackendVM1, sélectionnez Se connecter.
4. Sur la page Se connecter, sélectionnez Autres façons de se connecter, puis

Accéder à Bastion.
5. Sur la page Bastion, entrez le nom d’utilisateur et le mot de passe créés pour la
machine virtuelle, puis sélectionnez Se connecter.

virtuelles
1. À partir du bureau de BackendVM1, ouvrez PowerShell.
2. Entrez ping BackendVM0 . Vous recevez une réponse similaire au message suivant :
PowerShell
PS C:\Users\BackendVM1> ping BackendVM0
Pinging BackendVM0.ovvzzdcazhbu5iczfvonhg2zrb.bx.internal.cloudapp.net
with 32 bytes of data
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Le test Ping a échoué car il utilise le protocole ICMP (Internet Control Message
Protocol). Par défaut, le protocole ICMP n’est pas autorisé par un pare-feu
Windows.
3. Pour autoriser l’entrée du protocole ICMP via un pare-feu Windows sur cette
machine virtuelle, entrez la commande suivante :
PowerShell
4. Fermez la connexion Bastion à BackendVM1.
connecter à BackendVM0.
6. Dans PowerShell sur BackendVM0, entrez ping BackendVM1 .
Cette fois, vous recevez une réponse de réussite similaire au message suivant, car
vous avez autorisé le protocole ICMP via le pare-feu sur VM1.
PS C:\Users\BackendVM0> ping BackendVM1
Pinging BackendVM1.e5p2dibbrqtejhq04lqrusvd4g.bx.internal.cloudapp.net
[10.0.0.4] with 32 bytes of data:
Reply from 10.0.0.4: bytes=32 time=2ms TTL=128

Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 0ms
7. Fermez la connexion Bastion à BackendVM0.

Lorsque vous en avez terminé avec le réseau virtuel, utilisez Azure CLI, Azure PowerShell
ou le portail Azure pour supprimer le groupe de ressources et toutes ses ressources.

Azure CLI
az group delete --name TestRG
Étapes suivantes
Dans ce guide de démarrage rapide, vous avez créé un réseau virtuel avec deux sous-
réseaux, l’un contenant deux machines virtuelles, et l’autre pour Azure Bastion. Vous
avez déployé Azure Bastion puis l’avez utilisé pour vous connecter aux machines
virtuelles et vous avez communiqué de manière sécurisée entre les machines virtuelles.
Pour plus d’informations sur les paramètres de réseau virtuel, consultez Créer, changer
ou supprimer un réseau virtuel.
La communication privée entre les machines virtuelles n’est pas limitée dans un réseau
virtuel. Poursuivez avec l’article suivant pour en savoir plus sur la configuration de
différents types de communications réseau de machines virtuelles.

Démarrage rapide : Créer un réseau
virtuel – Modèle Resource Manager
Ce démarrage rapide montre comment créer un réseau virtuel avec deux sous-réseaux à
l’aide du modèle Azure Resource Manager. Un réseau virtuel est le bloc de construction
fondamental de votre réseau privé dans Azure. Il permet à des ressources Azure, comme
des machines virtuelles, de communiquer de manière sécurisée entre elles et avec
Internet.
Un modèle de gestionnaire des ressources est un fichier JSON (JavaScript Object

Notation) qui définit l’infrastructure et la configuration pour votre projet. Le modèle
utilise la syntaxe déclarative. Dans la syntaxe déclarative, vous décrivez le déploiement
souhaité sans écrire la séquence de commandes de programmation pour créer le
déploiement.
Vous pouvez également suivre ce guide de démarrage rapide en utilisant le portail

Azure, Azure PowerShell ou Azure CLI.
Prérequis
Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de
commencer.
Vérifier le modèle
Le modèle utilisé dans ce guide de démarrage rapide est tiré des modèles de démarrage
rapide Azure .
JSON
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"metadata": {
"_generator": {
"name": "bicep",
"version": "0.6.18.56646",
"templateHash": "10806234693722113459"
}
},
"parameters": {
"vnetName": {
"type": "string",
"defaultValue": "VNet1",
"metadata": {
"description": "VNet name"
}
},
"vnetAddressPrefix": {
"type": "string",
"defaultValue": "10.0.0.0/16",
"metadata": {
"description": "Address prefix"
}
},
"subnet1Prefix": {
"type": "string",
"metadata": {
"description": "Subnet 1 Prefix"
}
},
"subnet1Name": {
"type": "string",
"defaultValue": "Subnet1",
"metadata": {
"description": "Subnet 1 Name"
}
},
"subnet2Prefix": {
"type": "string",
"metadata": {
"description": "Subnet 2 Prefix"
}
},
"subnet2Name": {
"type": "string",
"defaultValue": "Subnet2",
"metadata": {
"description": "Subnet 2 Name"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"resources": [
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2021-08-01",
"name": "[parameters('vnetName')]",
"location": "[parameters('location')]",
"properties": {
"addressSpace": {
"addressPrefixes": [
"[parameters('vnetAddressPrefix')]"
]
},
"subnets": [
{
"name": "[parameters('subnet1Name')]",
"properties": {
"addressPrefix": "[parameters('subnet1Prefix')]"
}
},
{
"name": "[parameters('subnet2Name')]",
"properties": {
"addressPrefix": "[parameters('subnet2Prefix')]"
}
}
]
}
}
]
}
Les ressources Azure suivantes ont été définies dans le modèle :
Microsoft.Network/virtualNetworks : permet de créer un réseau virtuel Azure.

Microsoft.Network/virtualNetworks/subnets : permet de créer un sous-réseau.
Déployer le modèle
Déployez le modèle Resource Manager sur Azure :
1. Sélectionnez Déployer sur Azure pour vous connecter à Azure et ouvrir le modèle.
Le modèle crée un réseau virtuel avec deux sous-réseaux.
2. Dans le portail, dans la page Créer un réseau virtuel avec deux sous-réseaux,
tapez ou sélectionnez les valeurs suivantes :
Groupe de ressources : sélectionnez Créer nouveau, saisissez CreateVNetQS-

rg comme nom du groupe de ressources et sélectionnez OK.
Nom du réseau virtuel : tapez le nom du nouveau réseau virtuel.
3. Sélectionnez Examiner + créer, puis sélectionnez Créer.
4. Une fois le déploiement terminé, sélectionnez le bouton Accéder à la ressource

pour passer en revue les ressources déployées.
Vérifier les ressources déployées

Explorez les ressources qui ont été créées avec le réseau virtuel en parcourant les
panneaux des paramètres pour VNet1.
1. Sous l’onglet Vue d’ensemble, vous verrez l’espace d’adressage défini 10.0.0.0/16.
2. Sous l’onglet Sous-réseaux, vous verrez les sous-réseaux déployés Subnet1 et

Subnet2 avec les valeurs appropriées du modèle.
Pour découvrir la syntaxe et les propriétés JSON d’un réseau virtuel dans un modèle,
consultez Microsoft.Network/azureFirewalls.

Quand vous n’avez plus besoin des ressources que vous avez créées avec le pare-feu,
supprimez le groupe de ressources. Cela a pour effet de supprimer le réseau virtuel et
toutes les ressources associées.
Pour supprimer le groupe de ressources, appelez l’applet de commande Remove-

AzResourceGroup :
Azure PowerShell
Remove-AzResourceGroup -Name <your resource group name>
Étapes suivantes
Dans ce démarrage rapide, vous avez déployé un réseau virtuel Azure avec deux sous-
réseaux. Pour en savoir plus sur les réseaux virtuels Azure, consultez le tutoriel sur les
réseaux virtuels.
Ressources supplémentaires
 Documentation
Exemples de modèles Azure Resource Manager pour un réseau virtuel

Apprenez-en davantage sur les différents modèles Azure Resource Manager disponibles pour vous
permettre de déployer des réseaux virtuels Azure.
Démarrage rapide : Créer un équilibreur de charge public - Bicep - Azure Load

Balancer
Ce guide de démarrage rapide montre comment créer un équilibreur de charge à l’aide d’un fichier
Bicep.
Démarrage rapide : Créer une IP publique à l’aide d’un modèle Resource Manager -
Azure Virtual Network
Apprendre à créer une IP publique à l’aide d’un modèle Resource Manager
Démarrage rapide : Créer un équilibreur de charge interne - Modèle ARM

Ce guide de démarrage rapide montre comment créer un équilibreur de charge Azure interne à
l'aide d'un modèle Azure Resource Manager (modèle ARM).
Démarrage rapide : Créer un équilibreur de charge public : modèle ARM - Azure Load
Balancer
Ce guide de démarrage rapide vous montre comment créer un équilibreur de charge avec le modèle
Azure Resource Manager.
Set-AzVirtualNetwork (Az.Network)
L’applet de commande Set-AzVirtualNetwork met à jour un réseau virtuel.
Démarrage rapide : Créez un réseau virtuel - Portail Azure - Azure Virtual Network
Dans ce démarrage rapide, vous allez créer un réseau virtuel à l’aide du portail Azure. Un réseau
virtuel permet à des ressources Azure de communiquer entre elles et avec Internet.
Démarrage rapide : Configurer les journaux de flux de groupe de sécurité réseau

Network Watcher en utilisant un fichier Bicep
Découvrez comment activer par programmation les journaux de flux de groupe de sécurité réseau en
utilisant Bicep et Azure PowerShell.
Afficher 5 de plus
 Entrainement
Parcours d’apprentissage
Déployer et gérer des ressources dans Azure en utilisant des modèles ARM JSON -
Training
Découvrez comment les modèles ARM JSON vous permettent de gérer les déploiements
d’infrastructure à la fois simples et complexes sur Azure.
Certification
Microsoft Certified: Azure Network Engineer Associate - Certifications
Les candidats à cette certification doivent avoir une expertise en matière de planification,
d’implémentation et de gestion des solutions réseau Azure, y compris l’infrastructure réseau
principale, la connectivité hybride, les services de distribution d’applications, l’accès privé aux servic…
Tutoriel : Filtrer le trafic réseau avec un
groupe de sécurité réseau à l’aide du
portail Azure
Article • 01/06/2023
Vous pouvez utiliser un groupe de sécurité réseau pour filtrer le trafic réseau sortant et
entrant respectivement à destination et en provenance de ressources Azure dans un
réseau virtuel Azure.
Les groupes de sécurité réseau contiennent des règles de sécurité qui filtrent le trafic
réseau par adresse IP, port et protocole. Quand un groupe de sécurité réseau est associé
à un sous-réseau, des règles de sécurité sont appliquées aux ressources déployées dans
ce sous-réseau.
Dans ce tutoriel, vous allez apprendre à :
＂ Créer un groupe de sécurité réseau et les règles associées

＂ Créer des groupes de sécurité d’application
＂ Créer un réseau virtuel et associer un groupe de sécurité réseau à un sous-réseau
＂ Déployer des machines virtuelles et associer leurs interfaces réseau aux groupes de
sécurité d’application
＂ Tester les filtres de trafic

commencer.
Prérequis
Un abonnement Azure
Connexion à Azure
Connectez-vous au portail Azure .
Créer un réseau virtuel

1. Dans le menu du portail Azure, sélectionnez + Créer une ressource>Mise en
réseau>Réseau virtuel ou, dans la zone de recherche du portail, recherchez Réseau
virtuel.
2. Sélectionnez Create (Créer).
3. Sous l’onglet Informations de base de la page Créer un réseau virtuel, entrez ou

Paramètre Valeur
Détails du projet

Entrez myResourceGroup.
Sélectionnez OK.
Nom Entrez myVNet.
4. Sélectionnez l’onglet Vérifier + créer, ou sélectionnez le bouton bleu Vérifier +

créer situé au bas de la page.
Créer des groupes de sécurité d’application

Un groupe de sécurité d’application vous permet de regrouper des serveurs dont les
fonctions sont similaires, comme des serveurs Web.

réseau>Groupe de sécurité d’application ou, dans la zone de recherche du portail,
recherchez Groupe de sécurité d’application.
3. Dans Créer un groupe de sécurité d’application, sous l’onglet De base, entrez ou

Paramètre Valeur
Détails du projet
Resource group Sélectionnez myResourceGroup.

Paramètre Valeur
Nom Entrez myAsgWebServers.
Région Sélectionnez (États-Unis) USA Est.

6. Répétez les étapes précédentes en spécifiant les valeurs suivantes :
Paramètre Valeur
Détails du projet
Nom Entrez myAsgMgmtServers.

Créer un groupe de sécurité réseau

Un groupe de sécurité réseau (NSG) sécurise le trafic réseau dans votre réseau virtuel.

réseau>Groupe de sécurité réseau ou, dans la zone de recherche du portail,
recherchez Groupe de sécurité réseau.
3. Dans Créer un groupe de sécurité réseau, sous l’onglet De base, entrez ou

Paramètre Valeur
Détails du projet
Nom Entrez myNSG.
Emplacement Sélectionnez (États-Unis) USA Est.

Associer le groupe de sécurité réseau au sous-

réseau
Dans cette section, vous allons associer le groupe de sécurité réseau au sous-réseau du
réseau virtuel que vous avez créé.
1. Dans la zone de recherche du portail, recherchez myVMNVA.
2. Dans la section Paramètres de myNSG, sélectionnez Sous-réseaux.
3. Dans la page Sous-réseaux, sélectionnez + Associer :

4. Sous Associer un sous-réseau, pour Réseau virtuel, sélectionnez myVNet.
5. Pour Sous-réseau, sélectionnez Par défaut, puis OK.
Créer des règles de sécurité

1. Dans la section Paramètres de myNSG, sélectionnez Règles de sécurité de trafic
entrant.
2. Dans la page Règles de sécurité de trafic entrant, sélectionnez + Ajouter :
3. Créez une règle de sécurité qui autorise les ports 80 et 443 dans le groupe de
sécurité d’application myAsgWebServers. Dans la page Ajouter une règle de
sécurité de trafic entrant, entrez ou sélectionnez les informations suivantes :
Paramètre Valeur
Paramètre Valeur
Source Conservez la valeur par défaut Tous.
Source port ranges Conservez la valeur par défaut de (*).
Destination Sélectionnez Groupe de sécurité

d’application.
Groupes de sécurité d’application de Sélectionnez myAsgWebServers.

destination
Service Conservez la valeur par défaut Personnalisé.
Plages de ports de destination Entrez 80,443.
Protocol Sélectionnez TCP.
Action Conservez la valeur par défaut Autoriser.
Priority Conservez la valeur par défaut 100.
Nom Entrez Allow-Web-All.


5. Répétez les étapes 3 à 4 à l’aide des informations suivantes :

Paramètre Valeur

d’application.
Groupe de sécurité d’application de Sélectionnez myAsgMgmtServers.

destination
Plages de ports de destination Entrez 3389.
Protocol sélectionnez N'importe laquelle.
Nom Entrez Allow-RDP-All.
Ｕ Attention
Dans cet article, le protocole RDP (port 3389) est exposé à Internet pour la
machine virtuelle affectée au groupe de sécurité d’application
myAsgMgmtServers.
Pour les environnements de production, au lieu d’exposer le port 3389 sur

Internet, il est recommandé de vous connecter aux ressources Azure à gérer
via un réseau VPN ou Azure Bastion.
Pour plus d'informations sur Azure Bastion, consultez Présentation d'Azure

Bastion.
Une fois que vous avez terminé les étapes 1 à 3, passez en revue les règles que vous
avez créées. Votre liste doit ressembler à la liste de l’exemple suivant :
Créez deux machines virtuelles dans le réseau virtuel.
Créer la première machine virtuelle

1. Dans le menu du portail Azure, sélectionnez + Créer une
ressource>Calcul>Machine virtuelle ou, dans la zone de recherche du portail,
recherchez Machine virtuelle.
2. Dans Créer une machine virtuelle, entrez ou sélectionnez les informations

suivantes sous l’onglet Informations de base :
Paramètre Valeur
Détails du projet
Nom de la machine Entrez myVMWeb.

virtuelle
Options de disponibilité Conservez la valeur par défaut Aucune redondance

d’infrastructure requise.

Paramètre Valeur
Image Sélectionnez Windows Server 2019 Datacenter – Gen2.
Instance Azure Spot Conservez la valeur par défaut (case non cochée).
Taille Sélectionnez Standard_D2s_V3.
Nom d’utilisateur Entrez un nom d’utilisateur.
Confirmer le mot de Retapez le mot de passe.

passe
Règles des ports

d’entrée
Sélectionner des ports Sélectionnez Aucun.

d’entrée
3. Sélectionnez l’onglet Réseau.
4. Sous l’onglet Mise en réseau, entrez ou sélectionnez les informations suivantes :
Paramètre Valeur
Interface réseau
Réseau virtuel Sélectionnez myVNet.
Subnet Sélectionnez par défaut (10.0.0.0/24) .
Adresse IP publique Conservez la valeur par défaut indiquant une

nouvelle IP publique.
Groupe de sécurité réseau de la Sélectionnez Aucun.

carte réseau

6. Sélectionnez Create (Créer). Le déploiement de la machine virtuelle peut prendre

quelques minutes.
Créer la deuxième machine virtuelle

Répétez les étapes 1 à 6 mais, à l’étape 2, pour le nom de la machine virtuelle, entrez
myVMMgmt.
Attendez que le déploiement des machines virtuelles soit terminé avant de passer à la
section suivante.
Associer des interfaces réseau à un groupe de

Quand vous avez créé les machines virtuelles, Azure a créé une interface réseau pour
chacune d’elles et l’a attachée à celle-ci.
Ajoutez l’interface réseau de chaque machine virtuelle à l’un des groupes de sécurité
d’application que vous avez créés précédemment :
1. Dans la zone de recherche du portail, recherchez myVMWeb.
2. Dans la section Paramètres de la machine virtuelle myVMWeb, sélectionnez Mise

en réseau.
3. Sélectionnez l’onglet Groupes de sécurité d’application, puis sélectionnez

Configurer les groupes de sécurité d’application.
4. Dans Configurer les groupes de sécurité d’application, sélectionnez

myAsgWebServers. Sélectionnez Enregistrer.

5. Répétez les étapes 1 et 2, en recherchant la machine virtuelle myVMMgmt et en

sélectionnant le groupe de sécurité d’application (ASG) myAsgMgmtServers.
Tester les filtres de trafic

1. Dans la zone de recherche du portail, recherchez myVMMgmt.
2. Dans la page Vue d’ensemble, sélectionnez le bouton Se connecter, puis RDP.
3. Sélectionnez Télécharger le fichier RDP.
4. Ouvrez le fichier RDP téléchargé et sélectionnez Connecter. Entrez le nom

d’utilisateur et le mot de passe spécifiés lors de la création de la machine virtuelle.
5. Sélectionnez OK.
6. Vous pouvez éventuellement recevoir un avertissement lié au certificat pendant le

processus de connexion. Si vous recevez l’avertissement, sélectionnez Oui ou
Continuer pour poursuivre le processus de connexion.
La connexion aboutit parce que le trafic entrant en provenance d’Internet à

destination du groupe de sécurité d’application myAsgMgmtServers est autorisé
via le port 3389.
L’interface réseau de myVMMgmt est associée au groupe de sécurité d’application
myAsgMgmtServers et autorise la connexion.
7. Ouvrez une session PowerShell sur myVMMgmt. Connectez-vous à myVMWeb en

procédant comme suit :
PowerShell
mstsc /v:myVmWeb
La connexion RDP de myVMMgmt à myVMWeb aboutit parce que des machines

virtuelles dans le même réseau peuvent communiquer entre elles sur n’importe
quel port par défaut.
Vous ne pouvez pas créer de connexion RDP à la machine virtuelle myVMWeb à

partir d’Internet. La règle de sécurité de myAsgWebServers empêche les
connexions entrantes en provenance d’Internet sur le port 3389. Par défaut, le
trafic entrant en provenance d’Internet est refusé pour toutes les ressources.
8. Pour installer Microsoft IIS sur la machine virtuelle myVMWeb, entrez la

commande suivante à partir d’une session PowerShell sur la machine virtuelle
myVMWeb :
PowerShell
Install-WindowsFeature -name Web-Server -IncludeManagementTools
9. Une fois l’installation d’IIS effectuée, déconnectez-vous de la machine virtuelle

myVMWeb. Cela vous laisse ensuite uniquement la connexion Bureau à distance
de la machine virtuelle myVMMgmt.
10. Déconnectez-vous de la machine virtuelle myVMMgmt.
12. Dans la page Vue d’ensemble de myVMWeb, notez l’adresse IP publique de votre
machine virtuelle. L’adresse affichée dans l’exemple suivant est 23.96.39.113, mais
votre adresse est différente :
13. Pour vérifier si vous pouvez accéder au serveur web myVMWeb depuis Internet,
ouvrez un navigateur Internet sur votre ordinateur et accédez à http://<public-
ip-address-from-previous-step> .
Vous voyez cette page par défaut IIS parce que le trafic entrant en provenance
d’Internet à destination du groupe de sécurité d’application myAsgWebServers est
autorisé via le port 80.
L’interface réseau attachée à myVMWeb est associée au groupe de sécurité

d’application myAsgWebServers et autorise la connexion.

Quand vous n’avez plus besoin du groupe de ressources, supprimez-le, ainsi que toutes
les ressources qu’il contient :
1. Entrez myResourceGroup dans le champ Recherche en haut du portail. Quand

myResourceGroup apparaît dans les résultats de la recherche, sélectionnez-le.
2. Sélectionnez Supprimer le groupe de ressources.
3. Entrez myResourceGroup dans TAPER NOM DU GROUPE DE RESSOURCES : puis
sélectionnez Supprimer.
Étapes suivantes
Dans ce tutoriel, vous allez :
Vous avez créé un groupe de sécurité réseau, et vous l’avez associé à un sous-
réseau de réseau virtuel.
Vous avez créé des groupes de sécurité d’application pour le web et la gestion.
Créez deux machines virtuelles et associez leurs interfaces réseau aux groupes de
sécurité d’application.
Vous avez testé le filtrage réseau du groupe de sécurité d’application.
Pour en savoir plus sur les groupes de sécurité réseau, consultez Vue d’ensemble d’un
groupe de sécurité réseau et Gérer un groupe de sécurité réseau.
Azure achemine par défaut le trafic entre les sous-réseaux. À la place, vous pouvez
choisir par exemple d’acheminer le trafic entre les sous-réseaux via une machine
virtuelle, agissant comme un pare-feu.
Pour apprendre à créer une table de routage, passez au didacticiel suivant.
Créer une table de routage

Tutoriel : Acheminer le trafic réseau avec
une table de routage à l’aide du portail
Azure
Article • 14/04/2023
Azure achemine le trafic entre tous les sous-réseaux au sein d’un réseau virtuel par
défaut. Vous pouvez créer vos propres itinéraires pour remplacer le routage par défaut
d’Azure. Les itinéraires personnalisés sont utiles, par exemple, quand vous souhaitez
router le trafic entre des sous-réseaux via une appliance virtuelle réseau (NVA).
＂ Créer un réseau virtuel et des sous-réseaux

＂ Créer une appliance NVA qui route le trafic
＂ Déployer des machines virtuelles sur différents sous-réseaux
＂ Créer une table de routage
＂ Créer un itinéraire
＂ Associer une table de routage à un sous-réseau
＂ Router le trafic d’un sous-réseau vers un autre via une NVA
Ce tutoriel utilise le portail Azure. Vous pouvez également le suivre avec l’interface Azure
CLI ou PowerShell.

commencer.
Vue d’ensemble
Ce diagramme montre les ressources créées dans ce tutoriel ainsi que les routes réseau
attendues.
Prérequis
Un abonnement Azure
Connexion à Azure

Dans cette section, vous allez créer un réseau virtuel, trois sous-réseaux et un hôte
bastion. Vous utiliserez l’hôte bastion pour vous connecter de manière sécurisée aux
machines virtuelles.

réseau>Réseau virtuel, ou recherchez Réseau virtuel dans la zone de recherche du
portail.

Paramètre Valeur
Resource group Sélectionnez Créer et entrez myResourceGroup.

Sélectionnez OK.
Nom Entrez myVirtualNetwork.
4. Sélectionnez l’onglet Adresses IP, ou sélectionnez le bouton Suivant : Adresses IP

au bas de la page.
5. Dans Espace d’adressage IPv4, sélectionnez l’espace d’adressage existant, puis

remplacez-le par 10.0.0.0/16.
6. Sélectionnez + Ajouter un sous-réseau, puis entrez Public comme Nom du sous-

réseau et 10.0.0.0/24 comme Plage d’adresses de sous-réseau.
8. Sélectionnez + Ajouter un sous-réseau, puis entrez Privé comme Nom du sous-

10. Sélectionnez + Ajouter un sous-réseau, puis entrez DMZ comme Nom du sous-
12. Sélectionnez l’onglet Sécurité, ou sélectionnez le bouton Suivant : Sécurité situé

au bas de la page.
13. Sous BastionHost, sélectionnez Activer. Entrez les informations suivantes :
Paramètre Valeur
Nom du bastion Entrez myBastionHost.

Paramètre Valeur

Dans le champ Nom, entrez myBastionIP.
Sélectionnez OK.
14. Sélectionnez l’onglet Vérifier + créer, ou sélectionnez le bouton Vérifier + créer.
Créer une machine virtuelle NVA

Les appliances virtuelles réseau (NVA) sont des machines virtuelles qui facilitent les
fonctions réseau, telles que le routage et l’optimisation du pare-feu. Dans cette section,
vous allez créer une NVA à l’aide d’une machine virtuelle Windows Server 2019
Datacenter. Si vous le souhaitez, vous pouvez sélectionner un autre système
d’exploitation.

ressource>Calcul>Machine virtuelle, ou recherchez Machine virtuelle dans la zone
de recherche du portail.
3. Sous l’onglet Informations de base de la page Créer une machine virtuelle, entrez
ou sélectionnez les informations suivantes :
Paramètre Valeur
Détails du
projet
Groupe de Sélectionnez myResourceGroup.

ressources
Détails de
l’instance
Nom de la Entrez myVMNVA.

machine
virtuelle

Paramètre Valeur
Options de Sélectionnez Aucune redondance d’infrastructure requise.

disponibilité
Type de Sélectionnez Standard.

sécurité
Instance Azure Sélectionnez Non.

Spot
Taille Choisissez la taille de la machine virtuelle ou acceptez le paramètre par

défaut.
Compte
administrateur
Nom Entrez un nom d’utilisateur.

d’utilisateur
Mot de passe Entrez un mot de passe. Le mot de passe doit contenir au moins 12
caractères et satisfaire aux exigences de complexité définies.
Confirmer le Retapez le mot de passe.

mot de passe
Règles des
ports d’entrée
Aucun port Sélectionnez Aucun.

d’entrée public
4. Sélectionnez l'onglet Mise en réseau ou choisissez Suivant : Disques, puis

Suivant : Mise en réseau.
5. Sous l’onglet Réseau, sélectionnez ou entrez :
Paramètre Valeur
Interface réseau
Réseau virtuel Sélectionnez myVirtualNetwork.
Subnet Sélectionnez DMZ
Adresse IP publique Sélectionnez Aucun
Groupe de sécurité réseau de la carte réseau Sélectionnez De base

Paramètre Valeur
Réseau des ports entrants publics Sélectionnez Aucun.
6. Sélectionnez l’onglet Vérifier + créer ou sélectionnez le bouton Vérifier + créer en

bas de la page.
Créer des machines virtuelles publique et

privée
Vous allez créer deux machines virtuelles dans le réseau virtuel myVirtualNetwork, puis
vous autoriserez le protocole ICMP (Internet Control Message Protocol) sur celles-ci afin
de pouvoir utiliser l’outil tracet pour suivre le trafic.
７ Notes
Pour les environnements de production, nous ne recommandons pas d’autoriser le

protocole ICMP (Internet Control Message Protocol) via le pare-feu Windows.
Créer une machine virtuelle publique

1. Dans le menu du portail Azure, sélectionnez Créer une ressource>Calcul>Machine
virtuelle.

Paramètre Valeur
Détails du
projet

ressources
Détails de
l’instance
Paramètre Valeur
Nom de la Entrez myVMPublic.

machine
virtuelle

disponibilité

sécurité

Spot

défaut.
Compte
administrateur

d’utilisateur

mot de passe
Règles des
ports d’entrée

d’entrée public

Paramètre Valeur
Interface réseau

Paramètre Valeur
Subnet Sélectionnez Public.
Groupe de sécurité réseau de la carte réseau Sélectionnez De base.

Créer une machine virtuelle privée

virtuelle.

Paramètre Valeur
Détails du
projet

ressources
Détails de
l’instance
Nom de la Entrez myVMPrivate.

machine
virtuelle

disponibilité

sécurité

Paramètre Valeur

Spot

défaut.
Compte
administrateur

d’utilisateur

mot de passe
Règles des
ports d’entrée

d’entrée public

Paramètre Valeur
Interface réseau
Subnet Sélectionnez Privé.


Autoriser ICMP dans le pare-feu Windows
1. Sélectionnez Accéder à la ressource ou rechercher myVMPrivate dans la zone de
recherche du portail.
2. Sur la page de présentation de myVMPrivate, sélectionnez Se connecter, puis

Bastion.
3. Entrez le nom d’utilisateur et le mot de passe que vous avez précédemment créés
pour la machine virtuelle myVMPrivate.
4. Sélectionnez le bouton Connecter.
5. Ouvrez Windows PowerShell après vous être connecté.
6. Entrez cette commande :
PowerShell
7. À partir de PowerShell, établissez une connexion Bureau à distance avec la machine

virtuelle myVMPublic :
PowerShell
mstsc /v:myvmpublic
8. Après vous être connecté à la machine virtuelle myVMPublic, ouvrez Windows

PowerShell et entrez la même commande qu’à l’étape 6.
9. Mettez fin à la connexion Bureau à distance avec la machine virtuelle myVMPublic.
Activer le transfert IP
Pour acheminer le trafic via l’appliance virtuelle réseau (NVA), activez le transfert IP dans
Azure et dans le système d’exploitation de la machine virtuelle myVMNVA. Une fois le
transfert IP activé, tout trafic reçu par la machine virtuelle myVMNVA et destiné à une
autre adresse IP ne fait l’objet d’aucune suppression et est transféré vers la bonne
destination.
Activer le transfert IP dans Azure

Dans cette section, vous allez activer le transfert IP pour l’interface réseau de la machine
virtuelle myVMNVA dans Azure.
1. Recherchez myVMNVA dans la zone de recherche du portail.
2. Sur la page de présentation de myVMNVA, accédez à la section Paramètres et

sélectionnez Mise en réseau.
3. Sur la page Mise en réseau de myVMNVA, sélectionnez l’interface réseau située en

regard de Interface réseau :. Le nom de l’interface commence par myvmnva.
4. Sur la page de présentation de l’interface réseau, accédez à la section Paramètres

et sélectionnez Configurations IP.
5. Dans la page Configurations IP, définissez Transfert IP sur Activé, puis

sélectionnez Enregistrer.
Activer le transfert IP dans le système d’exploitation
Dans cette section, vous allez activer le transfert IP pour le système d’exploitation de la
machine virtuelle myVMNVA afin de rediriger le trafic réseau. Vous utiliserez la
connexion bastion à la machine virtuelle myVMPrivate que vous avez lancée
précédemment pour établir une connexion Bureau à distance avec la machine virtuelle
myVMNVA.
1. À partir de PowerShell sur la machine virtuelle myVMPrivate, établissez une

connexion Bureau à distance avec la machine virtuelle myVMNVA :
PowerShell
mstsc /v:myvmnva
2. Après vous être connecté à la machine virtuelle myVMNVA, ouvrez Windows

PowerShell et entrez la commande suivante pour activer le transfert IP :
PowerShell
Set-ItemProperty -Path
HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name
IpEnableRouter -Value 1
3. Redémarrez la machine virtuelle myVMNVA.
PowerShell
Restart-Computer
Dans cette section, vous allez créer une table de routage.

réseau>Table de routage, ou recherchez Table de routage dans la zone de
3. Sous l’onglet Informations de base de la page Créer une table de routage, entrez
Paramètre Valeur
Détails du projet
Name Entrez myRouteTablePublic.
Propager des itinéraires de passerelle Sélectionnez Oui.

Créer un itinéraire
Dans cette section, vous allez créer un itinéraire dans la table de routage que vous avez
créée précédemment.
1. Sélectionnez Accéder à la ressource ou rechercher myRouteTablePublic dans la

zone de recherche du portail.
2. Sur la page myRouteTablePublic, accédez à la section Paramètres et sélectionnez

Itinéraires.
3. Sur la page Itinéraires, sélectionnez le bouton + Ajouter.
4. Dans Ajouter un itinéraire, entrez ou sélectionnez ces informations :
Paramètre Valeur
Nom de l’itinéraire Entrez ToPrivateSubnet.

Paramètre Valeur
Destination du préfixe Sélectionnez Adresses IP.

d’adresse
Plages d’adresses Entrez 10.0.1.0/24 (plage d’adresses du sous-réseau Privé créé

IP/CIDR de destination précédemment).
Type de tronçon Sélectionnez Appliance virtuelle.

suivant
adresse de tronçon Entrez 10.0.2.4 (adresse de la machine virtuelle myVMNVA créée

suivant précédemment dans le sous-réseau DMZ).
Associer une table de routage à un sous-réseau

Dans cette section, vous allez associer la table de routage que vous avez créée
précédemment à un sous-réseau.
1. Recherchez myVirtualNetwork dans la zone de recherche du portail.

2. Sur la page myVirtualNetwork, accédez à la section Paramètres et sélectionnez
Sous-réseaux.
3. Dans la liste de sous-réseaux du réseau virtuel, sélectionnez Public.
4. Dans Table de routage, sélectionnez la ressource myRouteTablePublic que vous

avez créée précédemment.
5. Sélectionnez Enregistrer pour associer votre table de route au sous-réseau Public.
Tester le routage du trafic réseau

À l’aide de l’outil tracet, vous allez tester le routage du trafic réseau de la machine
virtuelle myVMPublic vers la machine virtuelle myVMPrivate, puis vous le testerez dans
l’autre sens.
Tester le trafic réseau de la machine virtuelle myVMPublic

vers la machine virtuelle myVMPrivate
connexion Bureau à distance avec la machine virtuelle myVMPublic :
PowerShell
mstsc /v:myvmpublic

PowerShell et entrez la commande tracert suivante pour suivre le routage du trafic
réseau de la machine virtuelle myVMPublic vers la machine virtuelle myVMPrivate.
PowerShell
tracert myvmprivate
La réponse ressemble à cet exemple :
PowerShell
Tracing route to
myvmprivate.q04q2hv50taerlrtdyjz5nza1f.bx.internal.cloudapp.net
[10.0.1.4]
over a maximum of 30 hops:
1 1 ms * 2 ms myvmnva.internal.cloudapp.net
[10.0.2.4]
2 2 ms 1 ms 1 ms myvmprivate.internal.cloudapp.net
[10.0.1.4]
Trace complete.
Vous pouvez voir qu’il existe deux tronçons dans la réponse ci-dessus pour le suivi
tracert du trafic ICMP de la machine virtuelle myVMPublic vers la machine virtuelle
myVMPrivate. Le premier tronçon correspond à la machine virtuelle myVMNVA et
le deuxième à la machine virtuelle myVMPrivate de destination.
Azure a envoyé le trafic du sous-réseau Public à travers la NVA et non directement
vers le sous-réseau Privé parce que vous avez précédemment ajouté l’itinéraire
ToPrivateSubnet à la table de routage myRouteTablePublic et l'avez associée au
sous-réseau Public.
Tester le trafic réseau de la machine virtuelle

myVMPrivate vers la machine virtuelle myVMPublic
1. À partir de PowerShell sur la machine virtuelle myVMPrivate, entrez cette
commande tracet pour suivre le routage du trafic réseau de la machine virtuelle
myVmPrivate vers la machine virtuelle myVmPublic.
PowerShell
tracert myvmpublic
PowerShell
Tracing route to
myvmpublic.q04q2hv50taerlrtdyjz5nza1f.bx.internal.cloudapp.net
[10.0.0.4]
1 1 ms 1 ms 1 ms myvmpublic.internal.cloudapp.net
[10.0.0.4]
Trace complete.
Vous pouvez voir qu’il n’existe qu’un seul tronçon dans la réponse ci-dessus. Celui-
ci correspond à la machine virtuelle myVMPublic de destination.
Azure a envoyé le trafic directement du sous-réseau Privé au sous-réseau Public.

Par défaut, Azure achemine directement le trafic entre les sous-réseaux.
2. Fermez la session bastion.

Quand vous n’avez plus besoin du groupe de ressources, supprimez myResourceGroup
et toutes les ressources qu’il contient :
1. Entrez myResourceGroup dans le champ Recherche en haut du portail Azure.
Quand myResourceGroup apparaît dans les résultats de la recherche,
sélectionnez-le.

Étapes suivantes
Créé une table de route que vous avez associée à un sous-réseau.

Créé une appliance virtuelle réseau (NVA) simple qui a routé le trafic d’un sous-
réseau public vers un sous-réseau privé.
Vous pouvez déployer, à partir de la Place de marché Azure , différentes appliances

virtuelles réseau préconfigurées qui fournissent de nombreuses fonctions réseau utiles.
Pour en savoir plus sur le routage, consultez Routage du trafic de réseau virtuel et Créer,
modifier ou supprimer une table de routage.
Pour apprendre à restreindre l’accès réseau aux ressources PaaS avec des points de
terminaison de service de réseau virtuel, passez au tutoriel suivant.

Tutoriel : Restreindre l’accès réseau aux
ressources PaaS avec des points de
terminaison de service de réseau virtuel
en utilisant le portail Azure
Article • 01/06/2023
Les points de terminaison de service de réseau virtuel permettent de restreindre l’accès

réseau à certaines ressources du service Azure en n’autorisant leur accès qu’à partir d’un
sous-réseau du réseau virtuel. Vous pouvez également supprimer l’accès Internet aux
ressources. Les points de terminaison de service fournissent une connexion directe entre
votre réseau virtuel et les services Azure pris en charge, ce qui vous permet d’utiliser
l’espace d’adressage privé de votre réseau virtuel pour accéder aux services Azure. Le
trafic destiné aux ressources Azure via les points de terminaison de service reste
toujours sur le serveur principal de Microsoft Azure.
＂ Créer un réseau virtuel avec un sous-réseau

＂ Ajouter un sous-réseau et activer un point de terminaison de service
＂ Créer une ressource Azure et autoriser l’accès réseau à cette ressource uniquement
à partir d’un sous-réseau
＂ Déployer une machine virtuelle sur chaque sous-réseau
＂ Vérifier l’accès à une ressource à partir d’un sous-réseau
＂ Vérifier que l’accès à une ressource est refusé à partir d’un sous-réseau et d’Internet
CLI ou PowerShell.

commencer.
Prérequis
Un abonnement Azure
Connexion à Azure
1. Dans le menu du portail Azure, sélectionnez + Créer une ressource.
2. Recherchez Réseau virtuel, puis sélectionnez Créer.
3. Dans l'onglet De base, entrez les informations suivantes, puis sélectionnez

Suivant : Adresses IP >.
Paramètre Valeur

4. Dans l'onglet Adresses IP, sélectionnez les paramètres d'adresse IP suivants, puis
sélectionnez Réviser + créer.
Paramètre Valeur
Espace d’adressage IPv4 Laissez la valeur par défaut.
Nom du sous-réseau Sélectionnez Par défaut et changez le nom du sous-réseau en

« Public ».
Plage d’adresses de sous- Laissez la valeur par défaut.

réseau
5. Si les contrôles de validation réussissent, sélectionnez Créer.
6. Attendez que le déploiement se termine, puis sélectionnez Accéder à la ressource

ou passez à la section suivante.
Activer un point de terminaison de service

Les points de terminaison de service sont activés par service, par sous-réseau. Pour créer
un sous-réseau et activer un point de terminaison de service pour le sous-réseau :
1. Si vous n’êtes pas déjà sur la page de ressources du réseau virtuel, vous pouvez
rechercher le réseau virtuel créé dans la case située en haut du portail. Saisissez
myVirtualNetwork, et sélectionnez-le dans la liste.
2. Sélectionnez Sous-réseaux sous Paramètres, puis sélectionnez + Sous-réseau

comme indiqué ici :
3. Dans la page Ajouter un sous-réseau, entrez ou sélectionnez les informations
suivantes, puis sélectionnez Enregistrer :
Paramètre Valeur
Name Privé
Plage d’adresses de sous-réseau Laissez la valeur par défaut
Points de terminaison de service Sélectionnez Microsoft.Storage
Stratégies de points de terminaison de Conservez la valeur par défaut. 0

service sélectionné.
Ｕ Attention
Avant d’activer un point de terminaison de service pour un sous-réseau existant qui

contient des ressources, consultez Modifier les paramètres de sous-réseau.
Restreindre l’accès réseau d’un sous-réseau

Par défaut, toutes les instances de machines virtuelles d’un sous-réseau peuvent
communiquer avec l’ensemble des ressources. Vous pouvez limiter les communications
vers et à partir de toutes les ressources d’un sous-réseau par la création d’un groupe de
sécurité réseau et son association au sous-réseau :
1. Dans la zone de recherche située en haut du portail Azure, recherchez les groupes
de sécurité réseau.
2. Dans la page Groupe de sécurité réseau, sélectionnez + Créer.

Paramètre Valeur
Abonnement Sélectionnez votre abonnement
Resource group Sélectionnez myResourceGroup dans la liste
Nom Entrez myNsgPrivate
Emplacement Sélectionnez USA Est.
4. Sélectionnez Vérifier + créer et, lorsque le contrôle de validation est réussi,

sélectionnez Créer.
5. Une fois le groupe de sécurité réseau créé, sélectionnez Accéder à la ressource ou
recherchez myNsgPrivate en haut du portail Azure.
6. Sous Paramètres, sélectionnez Règles de sécurité de trafic sortant, puis sélectionnez

+ Ajouter.
7. Créer une règle qui autorise les communications sortantes vers le service Stockage
Azure. Saisissez ou sélectionnez les informations suivantes, puis sélectionnez
Ajouter :
Paramètre Valeur
Source Sélectionnez Service Tag (Identification)
Balise du service Sélectionnez VirtualNetwork

source
Source port *
ranges
Destination Sélectionnez Service Tag (Identification)
Identification de Sélectionnez Stockage

destination
Service Laissez Personnalisé par défaut.
Plages de ports Remplacez par 445. Le protocole SMB est utilisé pour se connecter à un
de destination partage de fichiers créé lors d’une étape ultérieure.
Protocol Quelconque
Action Autoriser
Priority 100
Nom Renommez avec Allow-Storage-All

8. Créer une règle de sécurité de trafic sortant qui refuse les communications vers
Internet. Cette règle qui permet la communication Internet sortante se substitue à
une règle par défaut dans tous les groupes de sécurité réseau. Répétez les étapes 6
à 9 ci-dessus en utilisant les valeurs suivantes, puis sélectionnez Ajouter :
Paramètre Valeur
Balise du service source Sélectionnez VirtualNetwork
Source port ranges *
Identification de destination Sélectionnez Internet
Plages de ports de destination *
Protocol Quelconque
Action Modifiez la valeur par défaut en spécifiant Refuser.
Priority 110
Name Remplacez par Deny-Internet-All

9. Créez une règle de sécurité de trafic entrant qui autorise le trafic du protocole RDP
(Remote Desktop Protocol) vers le sous-réseau en provenance de n’importe quel
endroit. La règle remplace une règle de sécurité par défaut qui refuse tout le trafic
entrant provenant d’Internet. Les connexions Bureau à distance sont autorisées sur
le sous-réseau afin que la connectivité puisse être testée dans une étape ultérieure.
Sous Paramètres, sélectionnez Règles de sécurité de trafic entrant, puis sélectionnez
+ Ajouter.
10. Entrez ou sélectionnez les valeurs suivantes, puis sélectionnez Ajouter.

Paramètre Valeur
Source Quelconque
Identification de destination Sélectionnez VirtualNetwork
Plages de ports de destination Remplacez par 3389
Protocol Quelconque
Action Autoriser
Priority 120
Name Remplacez par Allow-RDP-All

２ Avertissement
Le port RDP 3389 est exposé à Internet. Ceci est recommandé uniquement
pour les tests. Pour Environnements de production, nous vous recommandons
d’utiliser une connexion VPN ou privée.
11. Sélectionnez Sous-réseaux sous Paramètres, puis sélectionnez + Associer.
12. Sélectionnez myVirtualNetwork sous Réseau virtuel, puis sélectionnez Privé sous
Sous-réseaux. Sélectionnez OK pour associer le groupe de sécurité réseau au sous-
réseau sélectionné.
Restreindre l’accès réseau à une ressource

Les étapes nécessaires pour restreindre l’accès réseau aux ressources créées par le biais
des services Azure, qui sont activées pour les points de terminaison varient d’un service
à l’autre. Pour connaître les étapes à suivre, consultez la documentation relative à
chacun des services. La suite de ce tutoriel comprend des étapes permettant de
restreindre, par exemple, l’accès réseau pour un compte Stockage Azure.
Créez un compte de stockage.

1. Sélectionnez + Créer une ressource en haut à gauche du portail Azure.
2. Entrez « Compte de stockage » dans la barre de recherche, puis sélectionnez-le

dans le menu déroulant. Sélectionnez ensuite Créer.
3. Entrez les informations suivantes :
Paramètre Valeur
Resource Sélectionner myResourceGroup

group
Nom du Entrez un nom qui est unique dans tous les emplacements Azure. La
compte de longueur du nom doit être comprise entre 3 et 24 caractères, en utilisant
stockage uniquement des chiffres et des lettres minuscules.
Région Sélectionnez (États-Unis) USA Est
Performances standard
Redondance Stockage localement redondant (LRS)

4. Sélectionnez Créer + vérifieret, lorsque les contrôles de validation ont réussi,
cliquez sur Créer.
７ Notes
Le déploiement peut prendre quelques minutes.
5. Une fois le compte de stockage créé, sélectionnez Accéder à la ressource.
Créer un partage de fichiers dans le compte de stockage

1. Sélectionnez Partages de fichiers sous Stockage de données, puis sélectionnez +
Partage de fichiers.
2. Entrez ou définissez les valeurs suivantes pour le partage de fichiers, puis
sélectionnez Créer :
Paramètre Valeur
Nom my-file-share
Quota Sélectionnez Définir sur la valeur maximale.
Niveau Laissez la valeur par défaut, Transaction optimisée.

3. Le nouveau partage de fichiers devrait apparaître sur la page de partage de
fichiers, si ce n'est pas le cas, sélectionnez le bouton Actualiser en haut de la page.
Restreindre l’accès réseau à un sous-réseau

Par défaut, les comptes de stockage acceptent les connexions réseau provenant des
clients de n’importe quel réseau, y compris Internet. Vous pouvez limiter l’accès réseau à
partir d’Internet et de tous les autres sous-réseaux de tous les réseaux virtuels (à
l’exception du sous-réseau Privé du réseau virtuel myVirtualNetwork). Pour limiter
l’accès réseau à un sous-réseau :
1. Sous Paramètres pour votre compte de stockage (nom unique), sélectionnez Mise
en réseau.
2. Sélectionnez Autoriser l’accès de Réseaux sélectionnés puis + Ajouter un réseau

existant.
3. Sous Ajouter des réseaux, sélectionnez les valeurs suivantes puis Ajouter :
Paramètre Valeur
Réseaux virtuels myVirtualNetwork
Sous-réseaux Privé
4. Sélectionnez le bouton Enregistrer pour enregistrer la configuration du réseau

virtuel.
5. Sélectionnez Clés d'accès sous Sécurité + mise en réseau pour le compte de
stockage et sélectionnez Afficher les clés. Notez la valeur de clé1 pour l'utiliser
dans une étape ultérieure lors du mappage du partage de fichiers dans une
machine virtuelle.

Pour tester l’accès réseau à un compte de stockage, déployez une machine virtuelle sur
chaque sous-réseau.

1. Dans le portail Azure, sélectionnez + Créer une ressource.
2. Sélectionnez Calcul, puis Créer sous Machine virtuelle.
3. Sous l’onglet Informations de base, entrez ou sélectionnez les informations

suivantes :
Paramètre Valeur
Resource Sélectionnez myResourceGroup, qui a été créé précédemment.

group
Paramètre Valeur
Nom de la Entrez myVmPublic

machine
virtuelle
Région (États-Unis) USA Est
Options de Zone de disponibilité

disponibilité
Zone de 1
disponibilité
Image Sélectionnez une image de système d’exploitation. Pour cette machine

virtuelle, Centre de données Windows Server 2019 – Gen1 est sélectionnée.
Taille Sélectionnez la taille d’instance de machine virtuelle que vous souhaitez

utiliser
Nom Entrez un nom d’utilisateur de votre choix.

d’utilisateur
Mot de passe Entrez un mot de passe de votre choix. Le mot de passe doit contenir au
moins 12 caractères et satisfaire aux exigences de complexité définies.
Aucun port Autoriser les ports sélectionnés

d’entrée
public
Sélectionner Conservez le paramètre par défaut RDP (3389)

des ports
d’entrée

Paramètre Valeur
Réseau Sélectionnez myVirtualNetwork.

virtuel
Groupe de Sélectionnez Avancé. Le portail crée automatiquement pour vous un

sécurité groupe de sécurité réseau qui autorise le port 3389. Vous aurez besoin de
réseau de la ce port ouvert pour vous connecter à la machine virtuelle dans une étape
carte réseau ultérieure.

5. Sélectionnez Examiner et créer, puis Créer et attendez la fin du déploiement.
6. Sélectionnez Accéder à la ressource ou ouvrez la page Accueil > Machines

virtuelles, puis sélectionnez la machine virtuelle que vous venez de créer,
myVmPublic, qui doit être démarrée.

1. Répétez les étapes 1-5 pour créer une deuxième machine virtuelle. À l’étape 3,
nommez la machine virtuelle myVmPrivate. À l’étape 4, sélectionnez le sous-réseau
Privé et définissez le groupe de sécurité réseau sur Aucun.

２ Avertissement
Ne passez à l’étape suivante que lorsque le déploiement sera terminé.

myVmPrivate, qui doit être démarrée.
Vérifier l’accès au compte de stockage

1. Une fois que la machine virtuelle myVmPrivate a été créée, allez à la page d'aperçu
de la machine virtuelle. Pour vous connecter à la machine virtuelle, sélectionnez
Connexion, puis sélectionnez RDP dans la liste déroulante.
2. Sélectionnez Télécharger le fichier RDP pour télécharger le fichier de Bureau à

distance sur votre ordinateur.
3. Ouvrez le fichier .rdp téléchargé. Lorsque vous y êtes invité, sélectionnez
Connexion.
4. Entrez le nom d’utilisateur et le mot de passe spécifiés lors de la création de la

machine virtuelle. Vous devrez peut-être sélectionner Plus de choix puis Utiliser un
autre compte pour spécifier les informations d’identification que vous avez entrées
lorsque vous avez créé la machine virtuelle. Pour le champ d’adresse e-mail, entrez
les informations d’identification « Compte d’administrateur : nom d’utilisateur »
que vous avez spécifiées précédemment. Sélectionnez OK pour vous connecter à la
machine virtuelle.
７ Notes
Un avertissement de certificat peut s’afficher pendant le processus de

connexion. Si vous recevez l’avertissement, sélectionnez Oui ou Continuer
pour poursuivre le processus de connexion.
5. Une fois connecté, ouvrez Windows PowerShell. Utilisez le script ci-dessous pour
mapper le partage de fichiers Azure au lecteur Z à l’aide de PowerShell. Remplacez
<storage-account-key> et les deux variables <storage-account-name> par les
valeurs récupérées plus tôt lors des étapes de création du compte de stockage.
PowerShell
$acctKey = ConvertTo-SecureString -String "<storage-account-key>" -

AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential -
ArgumentList "Azure\<storage-account-name>", $acctKey
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storage-account-
name>.file.core.windows.net\my-file-share" -Credential $credential
PowerShell retourne un résultat semblable à l’exemple suivant :

PowerShell
Name Used (GB) Free (GB) Provider Root

---- --------- --------- -------- ----
Z FileSystem
\\mystorage007.file.core.windows.net\my-f...
Le partage de fichiers Azure est correctement mappé au lecteur Z.
6. Fermez les sessions Bureau à distance sur la machine virtuelle myVmPrivate.
Vérifier que l’accès au compte de stockage est

refusé
À partir de myVmPublic :
1. Entrez myVmPublic dans le champ Rechercher des ressources, services et
documents en haut du portail. Quand myVmPublic apparaît dans les résultats de
la recherche, sélectionnez cette entrée.
2. Répétez les étapes 1 à 5 ci-dessus dans Vérifier l’accès au compte de stockage

pour la machine virtuelle myVmPublic.
Après un court délai d’attente, vous recevez une erreur New-PSDrive : Access is
denied . L’accès est refusé car la machine virtuelle myVmPublic est déployée sur le
sous-réseau Public. Le sous-réseau Public ne dispose d’aucun point de terminaison

de service activé pour le Stockage Azure. Le compte de stockage permet
uniquement l’accès à partir du sous-réseau Private et non au sous-réseau Public.
PowerShell
New-PSDrive : Access is denied

At line:1 char:1
+ New-PSDrive -Name Z -PSProvider FileSystem -Root "\\mystorage007.file
...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Z:PSDriveInfo) [New-
PSDrive], Win32Exception
+ Fu llyQualifiedErrorId :
CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand
3. Fermez les sessions Bureau à distance sur la machine virtuelle myVmPublic.

À partir d’un ordinateur local :
1. Dans le portail Azure, accédez au compte de stockage nommé de manière unique
que vous avez créé précédemment. Par exemple, mystorage007.
2. Sélectionnez Partages de fichiers sous Stockage de données, puis sélectionnez le

fichier my-file-share créé plus tôt.
3. Vous devriez obtenir le message d’erreur suivant :
７ Notes
L’accès est refusé, car votre ordinateur ne se trouve pas dans le sous-réseau Private
du réseau virtuel MyVirtualNetwork.

Quand vous n’avez plus besoin du groupe de ressources, supprimez-le ainsi que toutes

Étapes suivantes
Dans ce tutoriel, vous avez activé un point de terminaison de service pour un sous-
réseau de réseau virtuel. Vous avez vu que les points de terminaison de service peuvent
être activés pour les ressources déployées à partir de différents services Azure. Vous
avez créé un compte Stockage Azure et un accès réseau à ce compte de stockage, limité
aux ressources du sous-réseau du réseau virtuel. Pour en savoir plus sur les points de
terminaison de service, consultez Points de terminaison de service de réseau virtuel et
Ajouter, modifier ou supprimer un sous-réseau de réseau virtuel.
Si vous avez plusieurs réseaux virtuels dans votre compte, vous souhaiterez peut-être
établir une connectivité entre eux afin que les ressources puissent communiquer entre
elles. Pour savoir comment connecter des réseaux virtuels, passez au didacticiel suivant.

Tutoriel : Connecter des réseaux virtuels
à l’aide du peering de réseaux virtuels
Article • 01/06/2023
Vous pouvez connecter des réseaux virtuels entre eux à l’aide du peering de réseaux
virtuels. Ces réseaux virtuels peuvent appartenir à la même région ou à des régions
différentes (connexion également appelée Global VNet Peering). Une fois les réseaux
virtuels appairés, les ressources des deux réseaux virtuels peuvent communiquer entre
elles via une connexion à faible latence et à bande passante élevée à l’aide du réseau
principal Microsoft.
＂ Créer des réseaux virtuels

＂ Connecter deux réseaux virtuels à l’aide du peering de réseaux virtuels
＂ Déployer une machine virtuelle sur chaque réseau virtuel
＂ Établir une communication entre les machines virtuelles
Ce tutoriel utilise le portail Azure. Vous pouvez également le suivre avec Azure CLI ou
PowerShell.

commencer.
Prérequis
Un abonnement Azure
Connexion à Azure
Créer des réseaux virtuels

1. Dans le portail Azure, sélectionnez Créer une ressource.

3. Sous l’onglet Bases, entrez ou sélectionnez les informations suivantes, puis
acceptez les valeurs par défaut pour les autres paramètres :
Paramètre Valeur
Nom Saisissez myVirtualNetwork1.

4. Sous l’onglet Adresses IP, entrez 10.0.0.0/16 dans le champ Espace d’adressage
IPv4. Sélectionnez le bouton + Ajouter un sous-réseau situé dessous, puis entrez
Subnet1 sous Nom du sous-réseau et 10.0.0.0/24 sous Plage d’adresses de sous-
réseau.
5. Sélectionnez Vérifier + créer, puis sélectionnez Créer.
6. Répétez les étapes 1 à 5 pour créer un deuxième réseau virtuel avec les paramètres
suivants :
Paramètre Valeur
Nom myVirtualNetwork2
Espace d’adressage 10.1.0.0/16
Resource group myResourceGroup
Nom du sous-réseau Sous-réseau2
Plage d’adresses de sous-réseau 10.1.0.0/24
Appairer des réseaux virtuels

1. Dans la zone de recherche en haut du portail Azure, recherchez
myVirtualNetwork1. Quand la mention myVirtualNetwork1 apparaît dans les
résultats de recherche, sélectionnez-la.
2. Sous Paramètres, sélectionnez Peerings, puis sélectionnez + Ajouter, comme

illustré dans l’image suivante :
3. Entrez ou sélectionnez les informations suivantes, acceptez les valeurs par défaut
pour les autres paramètres, puis cliquez sur Ajouter.
Paramètre Valeur
Ce réseau
virtuel
Paramètre Valeur
Nom du lien Entrez myVirtualNetwork1-myVirtualNetwork2 comme nom de peering de

de peering myVirtualNetwork1 vers le réseau virtuel distant.
Réseau
virtuel
distant
Nom du lien Entrez myVirtualNetwork2-myVirtualNetwork1 comme nom de peering du

de peering réseau virtuel distant vers myVirtualNetwork1.
Abonnement Sélectionnez votre abonnement pour le réseau virtuel distant.
Réseau Sélectionnez myVirtualNetwork2 comme nom du réseau virtuel distant. Le

virtuel réseau virtuel distant peut se trouver dans la même région que
myVirtualNetwork1 ou dans une autre région.

Sur la page Peerings, l’état de peering est Connecté, comme indiqué dans l’image
suivante :
Si vous ne voyez pas d’état Connecté, cliquez sur le bouton Actualiser.

Créez une machine virtuelle sur chaque réseau virtuel afin de pouvoir tester la
communication entre elles.

1. Dans le portail Azure, sélectionnez Créer une ressource.

3. Entrez ou sélectionnez les informations suivantes dans l’onglet Informations de
base. Acceptez les valeurs par défaut pour les autres paramètres, puis cliquez sur
Créer :
Paramètre Valeur
Resource Sélectionnez myResourceGroup.

group
Nom Entrez myVm1.
Image Sélectionnez une image de système d’exploitation. Pour ce tutoriel,

Windows Server 2019 Datacenter - Gen2 est sélectionné.
Taille Sélectionnez une taille de machine virtuelle. Pour ce tutoriel,

Standard_D2s_v3 est sélectionné.
Nom Entrez un nom d’utilisateur. Pour ce tutoriel, le nom d’utilisateur azure est
d’utilisateur utilisé.

4. Dans l’onglet Mise en réseau, sélectionnez les valeurs suivantes :
Paramètre Valeur
Réseau virtuel Sélectionnez myVirtualNetwork1.
Subnet Sélectionnez Subnet1.
Groupe de sécurité réseau de la carte Sélectionnez De base.

réseau
Aucun port d’entrée public Sélectionnez Autoriser les ports

sélectionnés.
Paramètre Valeur
Sélectionner des ports d’entrée Sélectionnez RDP (3389).
5. Sélectionnez Vérifier + créer, puis Créer pour démarrer le déploiement de la

machine virtuelle.
Créer la seconde machine virtuelle

Répétez à nouveau les étapes 1 à 5 pour créer une deuxième machine virtuelle avec les
modifications suivantes :
Paramètre Valeur
Nom myVm2
Réseau virtuel myVirtualNetwork2

La création des machines virtuelles peut prendre plusieurs minutes. Attendez que les
deux machines virtuelles aient été créées avant de passer aux étapes restantes.
７ Notes

virtuelles
Testez la communication entre les deux machines virtuelles sur le peering de réseau
virtuel en effectuant un test ping de myVm2 vers myVm1.
1. Dans la zone de recherche située en haut du portail, recherchez myVm1. Quand

myVm1 apparaît dans les résultats de la recherche, sélectionnez-la.
2. Pour vous connecter à la machine virtuelle, sélectionnez Connexion, puis
sélectionnez RDP dans la liste déroulante. Sélectionnez Télécharger le fichier RDP
pour télécharger le fichier de Bureau à distance.
3. Pour vous connecter à la machine virtuelle, ouvrez le fichier RDP téléchargé. Si

vous y êtes invité, sélectionnez Connexion.
4. Entrez le nom d’utilisateur et le mot de passe spécifiés lors de la création de
myVm1 (il se peut que vous deviez choisir Plus de choix, puis Utiliser un compte
différent pour spécifier les informations d’identification que vous avez entrées lors
de la création de la machine virtuelle), puis sélectionnez OK.
5. Un avertissement de certificat peut s’afficher pendant le processus de connexion.

SélectionnezOui pour continuer le processus de connexion.
6. Dans une étape ultérieure, un test ping sera utilisé pour communiquer avec
myVm1 depuis myVm2. Le test ping utilise le protocole ICMP, qui est interdit par le
Pare-feu Windows par défaut. Sur myVm1, autorisez ICMP à travers le pare-feu
Windows afin de pouvoir effectuer un test ping pour cette machine virtuelle à
partir de myVm2 lors d’une étape ultérieure, en utilisant PowerShell :
PowerShell
Bien que ce test ping soit utilisé pour établir une communication entre les
machines virtuelles dans ce tutoriel, il n’est pas recommandé d’autoriser le
protocole IMCP via le pare-feu Windows lors de déploiements de production.
7. Pour établir une connexion avec myVm2 à partir de myVm1, entrez la commande
suivante à partir d’une invite de commandes sur myVm1 :
mstsc /v:10.1.0.4
8. Entrez le nom d’utilisateur et le mot de passe que vous avez spécifiés lors de la
création de myVm2, puis sélectionnez Oui si vous recevez un avertissement de
certificat pendant le processus de connexion.
9. Étant donné que vous avez activé la commande ping sur myVm1, vous pouvez
désormais y effectuer un test ping à partir de myVm2 :
PowerShell
ping 10.0.0.4
10. Déconnectez vos sessions RDP sur myVm1 et myVm2.


sélectionnez-le.

Étapes suivantes
créé un peering entre deux réseaux virtuels ;

testé la communication entre deux machines virtuelles sur le peering de réseaux
virtuels à l’aide de la commande ping.
Pour en savoir plus sur le peering de réseaux virtuels :

Concepts et meilleures pratiques relatifs
au Réseau virtuel Azure
Article • 15/05/2023
Cet article décrit les concepts clés et les meilleures pratiques pour le Réseau
virtuel Azure.
Concepts de réseau virtuel

Espace d’adressage : lors de la création d’un réseau virtuel, vous devez spécifier un
espace d’adressage IP privé personnalisé à l’aide d’adresses publiques et privées
(RFC 1918). Azure attribue aux ressources d’un réseau virtuel une adresse IP privée
à partir de l’espace d’adressage que vous attribuez. Par exemple, si vous déployez
une machine virtuelle dans un réseau virtuel avec l’espace d’adressage 10.0.0.0/16,
la machine virtuelle se voit attribuer une adresse IP privée telle que 10.0.0.4.
Sous-réseaux : les sous-réseaux vous permettent de segmenter le réseau virtuel en

sous-réseaux et d’allouer une partie de l’espace d’adressage du réseau virtuel à
chaque sous-réseau. Vous pouvez ensuite déployer des ressources Azure dans un
sous-réseau spécifique. Comme dans un réseau traditionnel, les sous-réseaux vous
permettent de segmenter votre espace d’adressage de réseau virtuel en segments
appropriés pour le réseau interne de l’organisation. La segmentation améliore
également l’efficacité de l’allocation d’adresse. Vous pouvez sécuriser des
ressources au sein de sous-réseaux à l’aide de Groupes de sécurité réseau. Pour
plus d’informations, consultez Groupes de sécurité réseau.
Régions : un réseau virtuel s’étend à une seule région/localisation. Toutefois,

plusieurs réseaux virtuels de différentes régions peuvent être connectés à l’aide de
l’appairage de réseaux virtuels.
Abonnement : un réseau virtuel est limité à un abonnement. Vous pouvez

implémenter plusieurs réseaux virtuels au sein de chaque abonnement Azure et de
chaque région Azure.
Meilleures pratiques
Lorsque vous créez votre réseau dans Azure, il est important de garder à l’esprit les
principes de conception universels suivants :
Vérifiez que les espaces d’adressage ne se chevauchent pas. Assurez-vous que
votre espace d’adressage de réseau virtuel (bloc CIDR) ne chevauche pas d’autres
plages réseau de votre organisation.
Vos sous-réseaux ne doivent pas couvrir l’espace d’adressage entier du réseau

virtuel. Planifiez et réserver de l’espace d’adressage pour l’avenir.
Il est recommandé d’avoir moins de grands réseaux virtuels plutôt que plusieurs
petits réseaux virtuels pour éviter la surcharge de gestion.
Sécurisez vos réseaux virtuels en attribuant des groupes de sécurité réseau (NSG)
aux sous-réseaux situés en dessous. Pour plus d’informations sur les concepts de
sécurité du réseau, consultez Vue d’ensemble de la sécurité réseau Azure.
Étapes suivantes
Pour commencer à utiliser un réseau virtuel, créez-en un, déployez-y plusieurs machines
virtuelles et communiquez entre les machines virtuelles. Pour en savoir plus, consultez
l’article de démarrage rapide Créer un réseau virtuel.
Réseau virtuel – Continuité des activités
Vue d’ensemble
Un réseau virtuel est une représentation logique de votre réseau dans le cloud. Il vous
permet de définir votre propre espace d’adressage IP privé et de segmenter le réseau en
sous-réseaux. Les réseaux virtuels servent de limite de confiance pour héberger vos
ressources de calcul telles que les machines virtuelles Azure et les équilibreurs de
charge. Un réseau virtuel permet la communication IP privée directe entre les ressources
qu’il héberge. Vous pouvez lier un réseau virtuel à un réseau local via une passerelle
VPN ou ExpressRoute.
Les réseaux virtuels sont créés dans l’étendue d’une région. Vous pouvez créer des
réseaux virtuels avec le même espace d’adressage dans deux régions différentes, mais
vous ne pourrez pas les connecter les uns aux autres en raison de leur espace
d’adressage en commun.
Continuité de l’activité
Peut-être que votre application peut être interrompue de différentes manières. Une
région peut être coupée complètement des autres en raison d’une catastrophe naturelle
ou d’une catastrophe partielle en raison d’une panne de plusieurs appareils ou services.
L’effet sur le service de réseau virtuel est différent dans chacune de ces situations.
Q : si une panne se produit pour une région entière, que faire ? Par exemple, si une
région est entièrement coupée en raison d’une catastrophe naturelle ? Que se passe-
t-il pour les réseaux virtuels hébergés dans la région ?
A : le réseau virtuel et les ressources dans la région affectée restent inaccessibles

pendant la durée de l’interruption de service.
Q : Comment puis-je recréer le même réseau virtuel dans une autre région ?
A : les réseaux virtuels sont des ressources relativement légères. Vous pouvez appeler
des API Azure pour créer un réseau virtuel avec le même espace d’adressage dans une
région différente. Pour recréer le même environnement que celui qui était présent dans
la région affectée, redéployez les machines virtuelles et d’autres ressources. Vous devrez
également créer une passerelle VPN et vous connecter à votre réseau local si vous aviez
une connectivité locale (comme dans un déploiement hybride).
Pour créer un réseau virtuel, consultez Création d’un réseau virtuel.
Q : un réplica d’un réseau virtuel dans une région donnée peut-il être recréé dans une
autre région à l’avance ?
R : oui, vous pouvez créer deux réseaux virtuels utilisant les mêmes espaces d’adressage
IP privé et les mêmes ressources dans deux régions différentes à l’avance. Si vous
hébergez des services Internet dans le réseau virtuel, vous auriez pu configurer Traffic
Manager pour router géographiquement le trafic vers la région active. Toutefois, vous
ne pouvez pas connecter deux réseaux virtuels avec le même espace d’adressage de
réseau local sous peine de causer des problèmes de routage. En cas d’incident et de
perte d’un réseau virtuel dans une région, vous pouvez connecter à votre réseau local
l’autre réseau virtuel dans la région disponible avec l’espace d’adressage correspondant.
Pour créer un réseau virtuel, consultez Création d’un réseau virtuel.

Routage du trafic de réseau virtuel
Article • 01/06/2023
En savoir plus sur la façon dont Azure achemine le trafic entre Azure, sur site et les
ressources Internet. Azure crée automatiquement une table de routage pour chaque
sous-réseau au sein d’un réseau virtuel Azure et y ajoute les itinéraires par défaut du
système. Pour plus d’informations sur les réseaux virtuels et les sous-réseaux, voir
Présentation du réseau virtuel. Vous pouvez remplacer certaines des routes système
d’Azure par des routes personnalisées, et ajouter d’autres routes personnalisées aux
tables de routage. Azure achemine le trafic sortant à partir d’un sous-réseau selon les
itinéraires disponibles dans la table de routage d’un sous-réseau.
Itinéraires système
Azure crée des itinéraires système automatiquement et assigne les itinéraires pour
chaque sous-réseau dans un réseau virtuel. Vous ne pouvez pas créer ou supprimer des
itinéraires système, mais vous pouvez remplacer certains itinéraires système avec des
itinéraires personnalisés. Azure crée des routes système par défaut pour chaque sous-
réseau et ajoute d’autres routes par défaut facultatives à des sous-réseaux spécifiques,
ou à chaque sous-réseau, quand vous utilisez des fonctionnalités Azure spécifiques.
Default
Chaque itinéraire comporte un préfixe d’adresse et le type de tronçon suivant. Lorsque
le trafic sortant d’un sous-réseau est envoyé à une adresse IP dans le préfixe d’adresse
d’un itinéraire, l’itinéraire qui contient le préfixe est l’itinéraire utilisé par Azure. En savoir
plus sur la façon dont Azure choisit un itinéraire lorsque plusieurs itinéraires contiennent
les mêmes préfixes, ou des préfixes qui se chevauchent. Chaque fois qu’un réseau virtuel
est créé, Azure crée automatiquement les itinéraires système par défaut suivants pour
chaque sous-réseau au sein du réseau virtuel :
Source Préfixes d’adresse Type de tronçon suivant
Default Propre au réseau virtuel Réseau virtuel
Default 0.0.0.0/0 Internet
Default 10.0.0.0/8 None
Par défaut 172.16.0.0/12 Aucun

Les types de tronçon suivants répertoriés dans le tableau précédent représentent la

façon dont Azure achemine le trafic à destination du préfixe d’adresse répertorié. Des
explications sont fournies ci-après pour les types de tronçon suivants :
Réseau virtuel : achemine le trafic entre les plages d’adresses au sein de l’espace
d’adressage d’un réseau virtuel. Azure crée un itinéraire avec un préfixe d’adresse
qui correspond à chaque plage d’adresses définie dans l’espace d’adressage d’un
réseau virtuel. Si plusieurs plages d’adresses sont définies dans l’espace
d’adressage de réseau virtuel, Azure crée un itinéraire individuel pour chaque
plage d’adresses. Azure achemine automatiquement le trafic entre les sous-
réseaux à l’aide des itinéraires créés pour chaque plage d’adresses. Il n’est pas
nécessaire de définir des passerelles pour qu’Azure achemine le trafic entre les
sous-réseaux. Bien qu'un réseau virtuel contienne des sous-réseaux ayant chacun
une plage d'adresses définie, Azure ne crée pas d’itinéraires par défaut pour les
plages d'adresses de sous-réseau. Chaque plage d’adresses de sous-réseau se
trouve dans une plage d’adresses de l’espace d’adressage d’un réseau virtuel.
Internet : achemine le trafic spécifié par le préfixe d’adresse à Internet. L’itinéraire

par défaut du système spécifie le préfixe d’adresse 0.0.0.0/0. Si vous ne substituez
pas les itinéraires par défaut d’Azure, Azure achemine le trafic pour n’importe
quelle adresse non spécifiée par une plage d’adresses au sein d’un réseau virtuel à
Internet. Il existe une exception à ce routage. Si l’adresse de destination
correspond à l’un des services d’Azure, Azure achemine le trafic directement au
service via le réseau principal d’Azure plutôt que d’acheminer le trafic vers Internet.
Le trafic entre les services Azure ne traverse pas le réseau Internet, quelle que soit
la région Azure où le réseau virtuel existe ou la région Azure dans laquelle une
instance du service Azure est déployée. Vous pouvez remplacer l’itinéraire système
par défaut d’Azure pour le préfixe d’adresse 0.0.0.0/0 avec un itinéraire
personnalisé.
Aucun : le trafic acheminé vers le type de tronçon suivant Aucun est supprimé,
plutôt que routé à l’extérieur du sous-réseau. Azure crée automatiquement des
itinéraires par défaut pour les préfixes d’adresse suivants :
10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16 : réservé à un usage privé dans le

document RFC 1918.
100.64.0.0/10 : réservé dans RFC 6598.

Si vous assignez l’une des plages d’adresses précédentes au sein de l’espace
d’adressage d’un réseau virtuel, Azure modifie automatiquement le type de
tronçon suivant pour l’itinéraire de Aucun en Réseau virtuel. Si vous affectez une
plage d’adresses à l’espace d’adressage d’un réseau virtuel qui comprend, mais
n’est pas identique à, un des quatre préfixes d’adresse réservés, Azure supprime
l’itinéraire pour le préfixe et ajoute un itinéraire pour le préfixe d’adresse que vous
avez ajouté, avec Réseau virtuel en tant que type de tronçon suivant.
Itinéraires par défaut facultatifs

Azure ajoute d’autres routes système par défaut pour les différentes fonctionnalités
d’Azure, mais uniquement celles que vous activez. En fonction de la fonctionnalité,
Azure ajoute les itinéraires par défaut facultatifs soit à des sous-réseaux spécifiques ou à
tous les sous-réseaux au sein d’un réseau virtuel. Les autres routes système et les types
de tronçon suivants qu’Azure peut ajouter lorsque vous activez des fonctionnalités
différentes :
Source Préfixes d’adresse Type de tronçon suivant Sous-

réseau au
sein d’un
réseau
virtuel
auquel
l’itinéraire
est ajouté
Default Unique pour le réseau virtuel, par Peering de réseaux virtuels Tous
exemple : 10.1.0.0/16
Passerelle Préfixes publiés à partir du site via le Passerelle de réseau virtuel Tous
de réseau protocole BGP, ou configurés dans la
virtuel passerelle de réseau local
Default Multiple VirtualNetworkServiceEndpoint Seul le

sous-
réseau
pour lequel
un point de
terminaison
de service
est activé.
Peering de réseau virtuel (VNet) : lorsque vous créez un peering de réseau virtuel
entre deux réseaux virtuels, le système ajoute un itinéraire pour chaque plage
d’adresses dans l’espace d’adressage de chaque réseau virtuel impliqué dans le
peering. En savoir plus sur le peering de réseaux virtuels.
Passerelle de réseau virtuel : un ou plusieurs itinéraires avec passerelle de réseau

virtuel répertorié comme le type de tronçon suivant sont ajoutés lorsqu’une
passerelle de réseau virtuel est ajoutée à un réseau virtuel. La source est également
passerelle de réseau virtuel, car la passerelle ajoute les itinéraires au sous-réseau. Si
votre passerelle réseau locale échange des itinéraires BGP (Border Gateway
Protocol) avec une passerelle de réseau virtuel, le système ajoute un itinéraire pour
chaque itinéraire. Ces itinéraires sont propagés à partir de la passerelle réseau
locale. Nous vous recommandons de résumer les itinéraires locaux aux plages
d’adresses les plus vastes possible, pour propager le plus petit nombre possible
d’itinéraires vers une passerelle de réseau virtuel Azure. Le nombre d’itinéraires
que vous pouvez propager vers une passerelle de réseau virtuel Azure est limité.
Pour plus d’informations, consultez limites Azure.
VirtualNetworkServiceEndpoint : les adresses IP publiques de certains services

sont ajoutées à la table de routage par Azure lorsque vous activez un point de
terminaison de service pour le service. Les points de terminaison de service sont
activés pour des sous-réseaux individuels d’un réseau virtuel, de telle sorte que
l’itinéraire est ajouté uniquement à la table de routage d’un sous-réseau pour
lequel un point de terminaison de service est activé. Les adresses IP publiques des
services Azure changent régulièrement. Azure gère automatiquement les adresses
dans la table de routage en cas de changement d’adresses. En savoir plus sur les
points de terminaison de service de réseau virtuel, et les services pour lesquels
vous pouvez créer des points de terminaison de service.
７ Notes
Les types de tronçon suivants du peering de réseau virtuel et

VirtualNetworkServiceEndpoint sont ajoutés uniquement aux tables de
routage des sous-réseaux au sein de réseaux virtuels créés par le biais du
modèle de déploiement Azure Resource Manager. Les types de tronçon
suivants ne sont pas ajoutés aux tables de routage qui sont associées à des
sous-réseaux de réseau virtuel créés par le biais du modèle de déploiement
classique. En savoir plus sur les modèles de déploiement Azure.
Itinéraires personnalisés
Vous pouvez créer des itinéraires soit en créant des itinéraires définis par l’utilisateur ou
en échangeant les itinéraires du protocole de passerelle frontière (BGP) entre votre
passerelle de réseau local et une passerelle de réseau virtuel Azure.
Défini par l’utilisateur

Vous pouvez créer des routes personnalisées ou définies par l’utilisateur (statiques) dans
Azure pour remplacer les routes système par défaut d’Azure, ou pour ajouter d’autres
routes à la table de routage d’un sous-réseau. Dans Azure, vous créez une table de
routage, puis associez cette dernière à zéro ou plusieurs sous-réseaux du réseau virtuel.
Chaque sous-réseau peut avoir zéro ou une table de routage associée. Pour en savoir
plus sur le nombre maximal d’itinéraires que vous pouvez ajouter à une table de
routage et le nombre maximal de tables de routage que vous pouvez créer par
abonnement Azure, consultez limites Azure. Quand vous créez une table de routage et
que vous l’associez à un sous-réseau, les routes de la table sont combinées aux routes
par défaut du sous-réseau. En cas de conflit d’affectations d’itinéraires, les itinéraires
définis par l’utilisateur remplacent itinéraires par défaut.
Vous pouvez spécifier les types suivants de tronçon suivants lors de la création d’un
itinéraire défini par l’utilisateur :
Appliance virtuelle : une appliance virtuelle réseau est une machine virtuelle qui
exécute une application réseau telle qu’un pare-feu. Pour en savoir plus sur les
diverses appliances virtuelles réseau préconfigurées que vous pouvez déployer
dans un réseau virtuel, consultez la Place de marché Azure . Lorsque vous créez
un itinéraire avec le appliance virtuelle type de tronçon, vous également spécifiez
les adresses IP de tronçon suivant. L’adresse IP peut être :
L’adresse IP privée d’une interface réseau attachée à une machine virtuelle.

L’optionActiver le transfert IP doit être activée pour toute interface réseau
attachée à une machine virtuelle qui transfère le trafic réseau vers une adresse
autre que celle qui lui appartient. Le paramètre désactive la vérification de la
source et de destination pour une interface réseau par Azure. En savoir plus sur
la façon d’activer le transfert IP pour une interface réseau. Bien que le paramètre
Activer le transfert IP soit un paramètre Azure, il se peut qu’il soit également
nécessaire d’activer le transfert IP au sein du système d’exploitation de la
machine virtuelle pour que l’appliance transfère le trafic entre les adresses IP
privées et les interfaces réseau Azure. Si l’appliance doit acheminer le trafic vers
une adresse IP publique, elle doit acheminer le trafic via proxy ou effectuer une
traduction d’adresses réseau (NAT) de l’adresse IP privée de la source vers sa
propre adresse IP privée. Azure effectue ensuite une opération NAT vers une
adresse IP publique avant d’envoyer le trafic vers Internet. Pour déterminer les
paramètres requis pour la machine virtuelle, consultez la documentation de
votre système d’exploitation ou application réseau. Pour comprendre les
connexions sortantes dans Azure, consultez Comprendre les connexions
sortantes dans Azure.
７ Notes
Déployer une appliance virtuelle dans un sous-réseau différent de celui des

ressources qui passent par l’appliance virtuelle. Le déploiement de
l’appliance virtuelle dans le même sous-réseau, puis l’application d’une
table de routage au sous-réseau qui achemine le trafic via l’appliance
virtuelle, peut entraîner des boucles de routage, où le trafic ne quitte
jamais le sous-réseau.
Une adresse IP privée de tronçon suivant doit disposer d’une connectivité

directe sans avoir besoin d’acheminer via la passerelle ExpressRoute ou
Virtual WAN. La définition du tronçon suivant sur une adresse IP sans
connectivité directe entraîne une configuration de routage définie par
l’utilisateur non valide.
L’adresse IP privée d’un équilibreur de charge interne Azure. Un équilibreur de

charge est souvent utilisé dans le cadre d’une stratégie de haute disponibilité
pour les appliances virtuelles du réseau.
Vous pouvez définir un itinéraire avec 0.0.0.0/0 comme préfixe d’adresse et un type
de tronçon suivant d’appliance virtuelle. Cette configuration permet à l’appliance
d’inspecter le trafic et de déterminer s’il faut transférer ou supprimer le trafic. Si
vous envisagez de créer un itinéraire défini par l’utilisateur contenant le préfixe
d’adresse 0.0.0.0/0, lisez d’abord la rubrique préfixe d’adresse 0.0.0.0/0.
Passerelle de réseau virtuel : indiquez quand vous souhaitez que le trafic destiné à
des préfixes d’adresse spécifiques soit routé vers une passerelle de réseau virtuel.
La passerelle de réseau virtuel doit être créée avec le type VPN. Vous ne pouvez
pas spécifier une passerelle de réseau virtuel créée en tant que type ExpressRoute
sur une route définie par l’utilisateur, car ExpressRoute exige d’utiliser BGP pour les
routes personnalisées. Vous ne pouvez pas spécifier de passerelles de réseau
virtuel si vous avez des connexions VPN et ExpressRoute coexistantes. Vous pouvez
définir un itinéraire qui dirige le trafic destiné au préfixe d’adresse 0.0.0.0/0 vers
une passerelle de réseau virtuel basée sur un itinéraire. Dans votre environnement
local, vous pouvez avoir un dispositif qui inspecte le trafic et détermine s’il faut le
transférer ou le supprimer. Si vous envisagez de créer un itinéraire défini par
l’utilisateur pour le préfixe d’adresse 0.0.0.0/0, lisez d’abord la rubrique préfixe
d’adresse 0.0.0.0/0. Au lieu de configurer un itinéraire défini par l’utilisateur pour le
préfixe d’adresse 0.0.0.0/0, vous pouvez publier un itinéraire avec le préfixe
0.0.0.0/0 via BGP, si vous avez activé BGP pour une passerelle de réseau virtuel
VPN.
Aucun : indiquez quand vous souhaitez supprimer le trafic vers un préfixe

d’adresse, plutôt que de le transférer vers une destination. Si vous n’avez pas
encore entièrement configuré une fonctionnalité, Azure peut définir l’option Aucun
pour certains des itinéraires système facultatifs. Par exemple, si vous voyez que
l’option Aucun est indiquée comme Adresse IP de tronçon suivant avec un Type
de tronçon suivant défini sur Passerelle de réseau virtuel ou Équipement virtuel,
c’est que l’appareil n’est pas en cours d’exécution ou n’est pas entièrement
configuré. Azure crée des itinéraires système par défaut pour les préfixes d’adresse
réservés avec Aucun en tant que type de tronçon suivant.
Réseau virtuel : spécifiez l’option Réseau virtuel quand vous souhaitez remplacer
le routage par défaut dans un réseau virtuel. Consultez Exemple de routage pour
voir un exemple de la raison pour laquelle vous pouvez créer un itinéraire avec le
type de tronçon suivant Réseau virtuel.
Internet : spécifiez l’option Internet si vous souhaitez explicitement acheminer le

trafic destiné à un préfixe d’adresse à Internet, ou si vous souhaitez que le trafic
destiné à des services Azure avec des adresses IP publiques reste dans le réseau
principal Azure.
Vous ne pouvez pas spécifier le type de tronçon suivant Appairage de réseaux virtuels
ou VirtualNetworkServiceEndpoint dans les itinéraires définis par l’utilisateur. Les
itinéraires avec les types de tronçon suivants Appairage de réseaux virtuels ou
VirtualNetworkServiceEndpoint sont créés uniquement par Azure, lorsque vous
configurez un appairage de réseaux virtuels ou un point de terminaison de service.
Étiquettes de service pour les itinéraires définis par

l’utilisateur
Vous pouvez désormais spécifier une étiquette de service comme préfixe d’adresse d’un
itinéraire défini par l’utilisateur au lieu d’une plage d’adresses IP explicite. Une balise de
service représente un groupe de préfixes d’adresses IP d’un service Azure donné.
Microsoft gère les préfixes d’adresse englobés par la balise de service et met à jour
automatiquement la balise de service quand les adresses changent. Ce qui permet de
réduire la complexité des mises à jour fréquentes des routes définies par l’utilisateur et
de réduire le nombre de routes que vous avez besoin de créer. Vous pouvez
actuellement créer jusqu’à 25 itinéraires avec des étiquettes de service dans chaque
table de routage. Avec cette version, l’utilisation des étiquettes de service dans les
scénarios de routage pour les conteneurs est également prise en charge.
Correspondance exacte
Le système privilégie l’itinéraire avec le préfixe explicite lorsqu’il existe une
correspondance de préfixe exacte entre un itinéraire avec un préfixe IP explicite et un
itinéraire avec une étiquette de service. Lorsque plusieurs itinéraires avec des étiquettes
de service ont des préfixes d’adresse IP qui correspondent, les itinéraires sont évalués
dans l’ordre suivant :
1. Étiquettes régionales (par exemple, Storage.EastUS, AppService.AustraliaCentral)
2. Étiquettes de niveau supérieur (par exemple, Stockage, AppService)
3. Étiquettes régionales AzureCloud (par exemple, AzureCloud.canadacentral,

AzureCloud.eastasia)
4. L’étiquette AzureCloud
Pour utiliser cette fonctionnalité, spécifiez un nom d’étiquette de service pour le

paramètre de préfixe d’adresse dans les commandes de table de routage. Par exemple,
dans PowerShell, vous pouvez créer un itinéraire pour diriger le trafic envoyé vers un
préfixe d’adresse IP de Stockage Azure vers une appliance virtuelle en utilisant :
Azure PowerShell
$param = @{
Name = 'StorageRoute'
AddressPrefix = 'Storage'
NextHopType = 'VirtualAppliance'
NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param
La même commande pour l’interface CLI est la suivante :
Azure CLI
az network route-table route create \

--resource-group MyResourceGroup \
--route-table-name MyRouteTable \
--name StorageRoute \
--address-prefix Storage \
--next-hop-type VirtualAppliance \
--next-hop-ip-address 10.0.100.4
Types de tronçon suivants dans les outils Azure

Le nom affiché et référencé pour les types de tronçon suivants diffère entre le portail
Azure et les outils en ligne de commande, et entre Azure Resource Manager et les
modèles de déploiement classique. Le tableau suivant répertorie les noms utilisés pour
faire référence à chaque type de tronçon suivant avec les différents outils et modèles de
déploiement:
Type de tronçon Azure CLI et PowerShell Azure CLI classique and PowerShell
suivant (Gestionnaire des ressources) (classique)
Passerelle de réseau VirtualNetworkGateway VPNGateway

virtuel
Réseau virtuel VnetLocal VNETLocal (non disponible dans

l’interface CLI classique en mode
Management des services)
Internet Internet Internet (non disponible dans

l’interface CLI classique en mode
Management des services)
Appliance virtuelle VirtualAppliance VirtualAppliance
None None Null (non disponible dans l’interface

CLI classique en mode Management
des services)
Peering de réseau Peering de réseaux virtuels Non applicable

virtuel
Point de terminaison VirtualNetworkServiceEndpoint Non applicable

de service de réseau
virtuel
Protocole de passerelle frontière

Une passerelle de réseau local peut échanger les itinéraires avec une passerelle de
réseau virtuel Azure à l’aide du protocole de passerelle frontière (BGP). L’utilisation du
protocole BGP avec une passerelle de réseau virtuel Azure dépend du type que vous
avez sélectionné lorsque vous avez créé la passerelle :
ExpressRoute : vous devez utiliser le protocole BGP pour publier les itinéraires
locaux vers le routeur Microsoft Edge. Vous ne pouvez pas créer de routes définies
par l’utilisateur pour forcer le routage du trafic vers la passerelle de réseau virtuel
ExpressRoute si vous déployez une passerelle de réseau virtuel avec le type
ExpressRoute. Vous pouvez utiliser des routes définies par l’utilisateur pour forcer
l’acheminement du trafic provenant d’ExpressRoute vers, par exemple, une
appliance virtuelle réseau.
VPN : vous pouvez éventuellement utiliser le protocole BGP. Pour plus

d’informations, consultez BGP avec les connexions VPN de site à site.
Lorsque vous échangez des itinéraires avec Azure à l’aide du protocole BGP, un itinéraire
distinct est ajouté à la table de routage de tous les sous-réseaux d’un réseau virtuel
pour chaque préfixe publié. L’itinéraire est ajouté avec Passerelle de réseau virtuel
comme source et type de tronçon suivant.
Vous pouvez désactiver la propagation des itinéraires de passerelle ER et VPN sur un

sous-réseau à l’aide d’une propriété sur une table de routage. Lorsque vous désactivez
la propagation d’itinéraires, le système n’ajoute pas d’itinéraires à la table de routage de
tous les sous-réseaux avec la propagation d’itinéraire de passerelle de réseau virtuel
désactivée. Ce processus s’applique aux itinéraires statiques et BGP. La connectivité avec
les connexions VPN est obtenue à l’aide d’itinéraires personnalisés avec un tronçon
suivant de type Passerelle de réseau virtuel. La propagation des routes ne doit pas être
désactivée sur GatewaySubnet. La passerelle ne fonctionne pas si ce paramètre est
désactivé. Pour plus d’informations, consultez Guide pratique pour désactiver la
propagation de la route de la passerelle réseau virtuel.
Comment Azure choisit un itinéraire

Lorsque le trafic sortant est envoyé à partir d’un sous-réseau, Azure choisit un itinéraire
sur la base de l’adresse IP de destination, à l’aide de l’algorithme de correspondance de
préfixe le plus long. Par exemple, une table de routage contient deux itinéraires : un
itinéraire spécifie le préfixe d’adresse 10.0.0.0/24, tandis que l’autre spécifie le préfixe
d’adresse 10.0.0.0/16. Azure dirige le trafic destiné à 10.0.0.5 vers le type de tronçon
suivant spécifié dans l’itinéraire avec le préfixe d’adresse 10.0.0.0/24. Ce processus se
produit parce que 10.0.0.0/24 est un préfixe plus long que 10.0.0.0/16, même si 10.0.0.5
se trouve dans les deux préfixes d’adresse. Azure dirige le trafic destiné à 10.0.1.5 vers le
type de tronçon suivant spécifié dans l’itinéraire avec le préfixe d’adresse 10.0.0.0/16. Ce
processus se produit parce que 10.0.1.5 n’est pas inclus dans le préfixe d’adresse
10.0.0.0/24, ce qui fait de l’itinéraire avec le préfixe d’adresse 10.0.0.0/16, le préfixe
correspondant le plus long.
Si plusieurs itinéraires contiennent le même préfixe d’adresse, Azure choisit le type
d’itinéraire en se basant sur l’ordre de priorité suivant :
1. Itinéraire défini par l’utilisateur
2. Itinéraire BGP
3. Itinéraire du système
７ Notes
Les itinéraires système pour le trafic lié au réseau virtuel, aux peerings de réseaux
virtuels ou aux points de terminaison de service de réseau virtuel, sont les
itinéraires sélectionnés par défaut, même si les itinéraires BGP sont plus spécifiques.
Par exemple, une table de routage contient les itinéraires suivants :
Default 0.0.0.0/0 Internet
Utilisateur 0.0.0.0/0 Passerelle de réseau virtuel
Lorsque le trafic est destiné à une adresse IP en dehors des préfixes d’adresses de tous
les itinéraires contenus dans la table de routage, Azure choisit l’itinéraire avec la source
Utilisateur, car les itinéraires définis par l’utilisateur ont une priorité plus élevée que les
itinéraires système par défaut.
Consultez Exemple de routage pour une table de routage complète avec des
explications des itinéraires de la table.
Préfixe d’adresse 0.0.0.0/0

Un itinéraire avec le préfixe d’adresse 0.0.0.0/0 fournit des instructions à Azure. Azure
utilise ces instructions pour acheminer le trafic destiné à une adresse IP qui n’est pas
dans le préfixe d’adresse de n’importe quel autre itinéraire figurant dans la table de
routage d’un sous-réseau. Lors de la création d’un sous-réseau, Azure crée un itinéraire
par défaut vers le préfixe d’adresse 0.0.0.0/0, avec Internet comme type de tronçon
suivant. Si vous ne substituez pas cet itinéraire, Azure achemine tout le trafic destiné à
des adresses IP non incluses dans le préfixe d’adresse de n’importe quel autre itinéraire
vers Internet. L’exception est que le trafic destiné aux adresses IP publiques des services
Azure reste sur le réseau principal Azure et qu’il n’est pas routé vers Internet. Lorsque
vous remplacez cet itinéraire par un itinéraire personnalisé, le trafic destiné aux adresses
qui ne se trouvent pas dans les préfixes d’adresse d’un autre itinéraire dans la table de
routage est dirigé. La destination varie selon que vous spécifiez une appliance virtuelle
réseau ou une passerelle de réseau virtuel dans l’itinéraire personnalisé.
Lorsque vous substituez le préfixe d’adresse 0.0.0.0/0, en plus du flux du trafic sortant
du sous-réseau via la passerelle de réseau virtuel ou l’appliance virtuelle, les
modifications suivantes se produisent avec le routage par défaut d’Azure :
Azure envoie tout le trafic vers le type de tronçon suivant spécifié dans l’itinéraire y
compris le trafic destiné à des adresses IP publiques de services Azure. Lorsque le
type de tronçon suivant de l’itinéraire avec le préfixe d’adresse 0.0.0.0/0 est
Internet, le trafic sortant du sous-réseau et destiné aux adresses IP publiques de
services Azure ne quitte jamais le réseau principal d’Azure, quelle que soit la région
Azure dans laquelle le réseau virtuel ou la ressource de service Azure existe.
Lorsque vous créez un itinéraire défini par l’utilisateur ou BGP avec le type de
tronçon suivant Passerelle de réseau virtuel ou Équipement virtuel, tout le trafic, y
compris le trafic envoyé aux adresses IP publiques des services Azure pour lesquels
vous n’avez pas activé des points de terminaison de service, est envoyé au type de
tronçon suivant spécifié dans l’itinéraire. Lorsque vous activez un point de
terminaison de service pour un service, Azure crée un itinéraire avec des préfixes
d’adresse pour le service. Le trafic vers le service n’est pas acheminé vers le type de
tronçon suivant dans un itinéraire avec le préfixe d’adresse 0.0.0.0/0. Les préfixes
d’adresse pour le service sont plus longs que 0.0.0.0/0.
Vous ne pouvez plus accéder directement aux ressources du sous-réseau à partir

d’Internet. Vous pouvez accéder indirectement aux ressources du sous-réseau à
partir d’Internet. L’appareil spécifié par le type de tronçon suivant pour un
itinéraire avec le préfixe d’adresse 0.0.0.0/0 doit traiter le trafic entrant. Une fois
que le trafic traverse l’appareil, le trafic atteint la ressource dans le réseau virtuel. Si
l’itinéraire contient les valeurs suivantes comme type de tronçon suivant :
Appliance virtuelle : L’appliance doit :
Être accessible à partir d’Internet
Avoir une adresse IP publique affectée,
Ne doit pas avoir de règle de groupe de sécurité réseau associée qui

empêche la communication avec l’appareil
Ne doit pas refuser la communication
Être en mesure de translater et de transférer une adresse réseau, ou

d’acheminer le trafic à travers un serveur proxy vers la ressource de
destination dans le sous-réseau, et de retourner le trafic à Internet.
Passerelle de réseau virtuel : si la passerelle est une passerelle de réseau virtuel,

un appareil local connecté à Internet peut translater et transférer les adresses
du réseau ou acheminer le trafic à travers un serveur proxy vers la ressource de
destination dans le sous-réseau, via le peering privé d’ExpressRoute.
Si votre réseau virtuel est connecté à une passerelle VPN Azure, n’associez pas de table
de routage au sous-réseau de passerelle qui inclut une route avec la destination
0.0.0.0/0. Cela peut empêcher la passerelle de fonctionner correctement. Pour plus
d’informations, consultez la question Pourquoi certains ports sont ouverts sur ma
passerelle VPN ? dans le FAQ sur la passerelle VPN.
Consultez Zone DMZ entre Azure et votre centre de données local pour obtenir les
détails de mise en œuvre lors de l’utilisation de passerelles de réseau virtuel entre
Internet et Azure.
Exemple de routage
Pour illustrer les concepts abordés dans cet article, les sections qui suivent décrivent :
Un scénario, avec la configuration requise
Les itinéraires personnalisés nécessaires pour satisfaire les besoins
La table de routage qui existe pour un sous-réseau qui comprend les itinéraires par
défaut et personnalisés nécessaires pour satisfaire aux exigences
７ Notes
Cet exemple n’a pas vocation à être une recommandation ni une bonne pratique. Il
est plutôt destiné uniquement à illustrer les concepts de cet article.
Spécifications
1. Mettre en œuvre deux réseaux virtuels dans la même région Azure et activer les
ressources de communication entre les réseaux virtuels.
2. Activer un réseau local pour communiquer en toute sécurité avec les deux réseaux
virtuels via un tunnel VPN sur Internet. Vous pouvez également utiliser une
connexion ExpressRoute, mais dans cet exemple, une connexion VPN est utilisée.
3. Pour un sous-réseau dans un réseau virtuel :
Forcer tout le trafic sortant du sous-réseau, sauf dans le stockage Azure et le

sous-réseau, à circuler via une appliance virtuelle de réseau pour inspection
et journalisation.
Ne pas inspecter le trafic entre les adresses IP privées dans le sous-réseau ;

autoriser le trafic à circuler directement entre toutes les ressources.
Supprimer tout trafic sortant destiné à l’autre réseau virtuel.
Permettre au trafic sortant vers le stockage Azure de circuler directement vers

le stockage, sans le forcer à traverser une appliance virtuelle de réseau.
4. Autoriser tout le trafic entre tous les autres sous-réseaux et réseaux virtuels.
Implémentation
L’illustration suivante montre une mise en œuvre basée sur le modèle de déploiement
Azure Resource Manager qui respecte les exigences précédentes :
Flèches indiquent le flux du trafic.

Tables de routage
Sous-réseau1
La table de routage du Sous-réseau1 dans l’image contient les itinéraires suivants :
id Source State Préfixes Type de tronçon suivant Adresse Nom

d’adresse IP de d’itinéraire
tronçon défini par
suivant l’utilisateur
1 Default Non 10.0.0.0/16 Réseau virtuel

valide
2 Utilisateur Actif 10.0.0.0/16 Appliance virtuelle 10.0.100.4 Au sein de

VNet1
3 Utilisateur Actif 10.0.0.0/24 Réseau virtuel Dans le

Sous-
réseau1
4 Default Non 10.1.0.0/16 Peering de réseaux virtuels

valide
5 Default Non 10.2.0.0/16 Peering de réseaux virtuels

valide
6 Utilisateur Actif 10.1.0.0/16 None ToVNet2-1-

Drop
7 Utilisateur Actif 10.2.0.0/16 None ToVNet2-2-

Drop
8 Default Non 10.10.0.0/16 Passerelle de réseau virtuel [X.X.X.X]

valide
9 Utilisateur Actif 10.10.0.0/16 Appliance virtuelle 10.0.100.4 To-On-

Prem
10 Default Actif [X.X.X.X] VirtualNetworkServiceEndpoint
11 Default Non 0.0.0.0/0 Internet

valide
12 Utilisateur Actif 0.0.0.0/0 Appliance virtuelle 10.0.100.4 Default-

NVA
Les identificateurs d’itinéraire sont décrits ci-dessous :

ID1 : Azure a automatiquement ajouté cette route pour tous les sous-réseaux de
Virtual-network-1, car 10.0.0.0/16 est la seule plage d’adresses définie dans
l’espace d’adressage du réseau virtuel. Si vous ne créez pas l’itinéraire défini par
l’utilisateur dans l’ID2 d’itinéraire, le trafic envoyé à une adresse comprise entre
10.0.0.1 et 10.0.255.254 est acheminé au sein du réseau virtuel. Ce processus est dû
au fait que le préfixe est plus long que 0.0.0.0/0 et qu’il n’entre pas dans les
préfixes d’adresse des autres itinéraires. Azure change automatiquement l’état de
Actif à Non valide, lorsque ID2, un itinéraire défini par l’utilisateur, est ajouté, car il
a le même préfixe que l’itinéraire par défaut, et les itinéraires définis par
l’utilisateur substituent les itinéraires par défaut. L’état de cet itinéraire est toujours
Actif pour le Sous-réseau2, car la table de routage à laquelle appartient l’itinéraire
défini par l’utilisateur, ID2, n’est pas associée au Sous-réseau2.
ID2 : Azure a ajouté cette route quand une route définie par l’utilisateur pour le
préfixe d’adresse 10.0.0.0/16 a été associée au sous réseau Subnet1 du réseau
virtuel Virtual-network-1. L’itinéraire défini par l’utilisateur spécifie 10.0.100.4
comme l’adresse IP de l’appliance virtuelle, car cette adresse est l’adresse IP privée
affectée à la machine virtuelle de l’appliance virtuelle. La table de routage à
laquelle cette route appartient n’est pas associée à Subnet2 et n’apparaît donc pas
dans la table de routage de Subnet2. Cet itinéraire remplace l’itinéraire par défaut
pour le préfixe 10.0.0.0/16 (ID1), qui a automatiquement acheminé le trafic adressé
à 10.0.0.1 et à 10.0.255.254 dans le réseau virtuel via le type de tronçon suivant de
réseau virtuel. Cet itinéraire existe pour répondre à l’exigence 3, afin de forcer tout
le trafic sortant à traverser une appliance virtuelle.
préfixe d’adresse 10.0.0.0/24 a été associée au sous-réseau Subnet1. Le trafic
destiné aux adresses comprises entre 10.0.0.1 et 10.0.0.254 reste dans le sous-
réseau, au lieu d’être acheminé vers l’appliance virtuelle spécifiée dans la règle
précédente (ID2), car il a un préfixe plus long que l’itinéraire ID2. Cette route n’a
pas été associée à Subnet2 et n’apparaît donc pas dans la table de routage de
Subnet2. Cet itinéraire substitue efficacement l’itinéraire ID2 pour le trafic au sein
du Sous-réseau1. Cet itinéraire existe pour répondre à l’exigence 3.
ID4 : Azure a ajouté automatiquement les routes dans les ID 4 et 5 de tous les
sous-réseaux de Virtual-network-1 quand le réseau virtuel a été appairé avec
Virtual-network-2. Virtual-network-2 possède deux plages d’adresses dans son
espace d’adressage : 10.1.0.0/16 et 10.2.0.0/16 ; Azure a donc ajouté une route
pour chaque plage. Si vous ne créez pas les itinéraires définis par l’utilisateur dans
les ID 6 et 7 d’itinéraire, le trafic envoyé à une adresse comprise entre 10.1.0.1-
10.1.255.254 et 10.2.0.1-10.2.255.254 est acheminé vers le réseau virtuel appairé.
Ce processus est dû au fait que le préfixe est plus long que 0.0.0.0/0 et qu’il n’entre
pas dans les préfixes d’adresse des autres itinéraires. Lorsque vous avez ajouté les
itinéraires dans les ID 6 et 7, Azure a automatiquement changé l’état d’Actif à Non
valide. Ce processus est dû au fait qu’ils ont les mêmes préfixes que les itinéraires
des ID 4 et 5, et que les itinéraires définis par l’utilisateur remplacent les itinéraires
par défaut. L’état des itinéraires dans ID 4 et 5 est toujours Actif pour le Sous-
réseau2, car la table de routage à laquelle appartiennent les itinéraires définis par
l’utilisateur dans ID 6 et 7 n’est pas associée au Sous-réseau2. Un peering de réseau
virtuel a été créé pour répondre à l’exigence 1.
ID5 : Même explication que pour ID4.
ID6 : Azure a ajouté cette route et la route dans ID7, quand des routes définies par
l’utilisateur pour les préfixes d’adresse 10.1.0.0/16 et 10.2.0.0/16 ont été associées
au sous-réseau Subnet1. Azure supprime le trafic destiné aux adresses comprises
entre 10.1.0.1 et 10.1.255.254 et entre 10.2.0.1 et 10.2.255.254 au lieu d’être
acheminé vers le réseau virtuel homologué, car les itinéraires définis par
l’utilisateur remplacent les itinéraires par défaut. Les routes ne sont pas associées à
Subnet2 et n’apparaissent donc pas dans la table de routage de Subnet2. Les
itinéraires remplacent les itinéraires ID4 et ID5 pour le trafic sortant du Sous-
réseau1. Les itinéraires ID6 et ID7 existent pour répondre à l’exigence 3 afin de
supprimer le trafic destiné à l’autre réseau virtuel.
ID7 : Même explication que pour ID6.
ID8 : Azure a ajouté automatiquement cette route pour tous les sous-réseaux de
Virtual-network-1 lorsqu’une passerelle de réseau virtuel de type VPN a été créée
au sein du réseau virtuel. Azure a ajouté l’adresse IP publique de la passerelle de
réseau virtuel à la table de routage. Le trafic envoyé vers n’importe quelle adresse
entre 10.10.0.1 et 10.10.255.254 est acheminé vers la passerelle de réseau virtuel.
Le préfixe est plus long que 0.0.0.0/0 et ne fait pas partie des préfixes d’adresse
des autres itinéraires. Une passerelle de réseau virtuel a été créée pour répondre à
l’exigence 2.
préfixe d’adresse 10.10.0.0/16 a été ajoutée à la table de routage associée à
Subnet1. Cet itinéraire remplace ID8. L’itinéraire envoie tout le trafic destiné au
réseau local à une NVA pour inspection, plutôt que d’acheminer le trafic
directement sur site. Cet itinéraire a été créé pour répondre à l’exigence 3.
ID10 : Azure a ajouté automatiquement cette route au sous-réseau lorsqu’un point

de terminaison de service pour un service Azure a été activé pour le sous-réseau.
Azure achemine le trafic à partir du sous-réseau vers une adresse IP publique du
service, sur le réseau d’infrastructure Azure. Le préfixe est plus long que 0.0.0.0/0 et
ne fait pas partie des préfixes d’adresse des autres itinéraires. Un point de
terminaison de service a été créé pour répondre à l’exigence 3, afin de permettre
au trafic destiné au stockage Azure de circuler directement vers le stockage Azure.
ID11: : Azure a automatiquement ajouté cette route à la table de routage de tous

les sous-réseaux de Virtual-network-1 et de Virtual-network-2. Le préfixe d’adresse
0.0.0.0/0 est le préfixe le plus court. Tout le trafic envoyé à des adresses avec un
plus long préfixe d’adresse est routé en fonction d’autres itinéraires. Par défaut,
Azure achemine tout le trafic destiné aux adresses autres que les adresses
spécifiées dans l’un des autres itinéraires vers Internet. Azure a automatiquement
changé l’état de Actif à Non valide pour le Sous-réseaut1 lorsqu’un itinéraire défini
par l’utilisateur pour le préfixe d’adresse 0.0.0.0/0 (ID12) a été associé au sous-
réseau. L’état de cet itinéraire est toujours Actif pour tous les autres sous-réseaux
dans les deux réseaux virtuels, car l’itinéraire n’est associé à aucun autre sous-
réseau au sein de tout autre réseau virtuel.
préfixe d’adresse 0.0.0.0/0 a été associée à Subnet1. L’itinéraire défini par
l’utilisateur spécifie 10.0.100.4 comme l’adresse IP de l’appliance virtuelle. Cette
route n’est pas associée à Subnet2 et n’apparaît donc pas dans la table de routage
de Subnet2. Tout le trafic destiné à toute adresse qui n’est pas incluse dans les
préfixes d’adresse de tout autre itinéraire est envoyé à l’appliance virtuelle. L’ajout
de cet itinéraire a changé l’état de l’itinéraire par défaut pour le préfixe d’adresse
0.0.0.0/0 (ID11) de Actif à Non valide pour le Sous-réseau1, car un itinéraire défini
par l’utilisateur remplace un itinéraire par défaut. Cette route existe pour répondre
à la troisièmeexigence.
Sous-réseau2
La table de routage du Sous-réseau2 dans l’image contient les itinéraires suivants :
Source State Préfixes Type de tronçon suivant Adresse IP de tronçon

d’adresse suivant
Default Actif 10.0.0.0/16 Réseau virtuel
Default Actif 10.1.0.0/16 Peering de réseau virtuel
Default Actif 10.2.0.0/16 Peering de réseau virtuel
Default Actif 10.10.0.0/16 Passerelle de réseau [X.X.X.X]

virtuel
Default Actif 0.0.0.0/0 Internet

Source State Préfixes Type de tronçon suivant Adresse IP de tronçon
d’adresse suivant
Default Actif 10.0.0.0/8 None
La table de routage du Sous-réseau2 contient tous les itinéraires par défaut créés par
Azure et les itinéraires facultatifs d’appairage de réseaux virtuels et de passerelle de
réseau virtuel. Azure a ajouté les itinéraires facultatifs à tous les sous-réseaux du réseau
virtuel lorsque la passerelle et le peering ont été ajoutés au réseau virtuel. Azure a
supprimé les itinéraires pour les préfixes d’adresse 10.0.0.0/8, 192.168.0.0/16 et
100.64.0.0/10 de la table de routage de Subnet1 lorsque l’itinéraire défini par l’utilisateur
pour le préfixe d’adresse 0.0.0.0/0 a été ajouté à Subnet1.
Étapes suivantes
Créer une table de routage définie par l’utilisateur avec des itinéraires et une
appliance virtuelle de réseau
Configurer BGP pour une passerelle VPN Azure
Utiliser le protocole BGP avec ExpressRoute
Afficher tous les itinéraires pour un sous-réseau. Une table de routage définie par
l’utilisateur vous montre uniquement les routes définies par l’utilisateur, et n’affiche
pas les routes par défaut et BGP pour un sous-réseau. L’affichage de tous les
itinéraires affiche les itinéraires par défaut, BGP et définis par l’utilisateur pour le
sous-réseau auquel une interface réseau appartient.
Déterminer le type de tronçon suivant entre une machine virtuelle et une adresse
IP de destination. La fonctionnalité de tronçon suivant d’Azure Network Watcher
vous permet de déterminer si le trafic a quitté un sous-réseau et s’il est en cours
de routage vers la destination escomptée.
Interopérabilité dans Azure –
Configuration de test
Cet article décrit une configuration de test que vous pouvez utiliser pour analyser
l’interopérabilité des services de mise en réseau au niveau du plan de contrôle et du
plan de données. Nous allons examiner brièvement les composants de la mise en réseau
Azure :
Azure ExpressRoute : Utilisez le peering privé d’Azure ExpressRoute pour

connecter directement des espaces IP privés de votre réseau local à vos
déploiements de réseau virtuel Azure. ExpressRoute vous permet d’obtenir une
bande passante supérieure et une connexion privée. De nombreux partenaires de
l’écosystème ExpressRoute proposent une connectivité ExpressRoute avec des
contrats SLA. Pour en savoir plus sur ExpressRoute et sa configuration, consultez
Présentation d’ExpressRoute.
VPN de site à site : Vous pouvez utiliser la passerelle VPN Azure comme un VPN
de site à site pour connecter en toute sécurité un réseau local à Azure via Internet
ou ExpressRoute. Pour savoir comment configurer un VPN site à site pour se
connecter à Azure, consultez Configurer une passerelle VPN.
Appairage de réseaux virtuels : utilisez l’appairage de réseaux virtuels pour établir

la connectivité entre les réseaux virtuels dans Azure. Pour plus d’informations sur
l’appairage de réseaux virtuels, consultez le Tutoriel : connecter des réseaux
virtuels avec l’appairage de réseaux virtuels – Portail Azure.
Configuration des tests

L’image suivante illustre la configuration de test :
Le cœur de la configuration de test est le réseau virtuel hub dans la région Azure 1. Le
réseau virtuel hub est connecté à différents réseaux, comme suit :
Le réseau virtuel hub est connecté au réseau virtuel spoke à l’aide de l’appairage
de réseaux virtuels. Le réseau virtuel spoke a un accès à distance aux deux
passerelles dans le réseau virtuel hub.
Le réseau virtuel hub est connecté au réseau virtuel de la branche à l’aide d’un VPN
site à site. La connectivité utilise eBGP pour échanger des itinéraires.
Le réseau virtuel hub est connecté au réseau local Emplacement 1 en utilisant le

peering privé ExpressRoute comme chemin d’accès primaire. Il utilise la
connectivité VPN de site à site comme chemin de secours. Dans le reste de cet
article, nous allons attribuer à ce circuit ExpressRoute le nom ExpressRoute 1. Par
défaut, les circuits ExpressRoute offrent une connectivité redondante pour une
haute disponibilité. Sur ExpressRoute 1, la sous-interface du routeur de périphérie
du client (CE) secondaire connectée au routeur Microsoft Enterprise Edge (MSEE)
secondaire est désactivée. Une ligne rouge sur la flèche double trait dans la figure
précédente représente la sous-interface désactivée du routeur CE.
Le réseau virtuel hub est connecté au réseau local Emplacement 2 en utilisant un

autre peering privé ExpressRoute. Dans le reste de cet article, nous allons attribuer
à ce second circuit ExpressRoute le nom ExpressRoute 2.
Le circuit ExpressRoute1 connecte également le réseau virtuel hub et le réseau

local Emplacement 1 à un réseau virtuel distant dans la région Azure 2.
Connectivité ExpressRoute et VPN de site à site
en tandem
VPN de site à site sur ExpressRoute

Vous pouvez configurer un VPN de site à site à l’aide du peering Microsoft ExpressRoute
pour échanger des données de façon privée entre votre réseau local et vos réseaux
virtuels Microsoft Azure. Avec cette configuration, vous pouvez échanger des données
en garantissant confidentialité, authenticité et intégrité. L’échange de données est
également soumis à un système anti-relecture. Pour plus d’informations sur la
configuration d’un VPN IPsec de site à site en mode tunnel via l’homologation Microsoft
ExpressRoute, consultez l’article Configurer un réseau VPN de site à site via le Peering
Microsoft ExpressRoute.
La principale limitation liée à la configuration d’un VPN de site à site qui utilise le
peering Microsoft est le débit. Le débit sur le tunnel IPsec est limité par la capacité de la
passerelle VPN. Le débit d’une passerelle VPN est inférieur au débit ExpressRoute. Dans
ce scénario, le fait d’utiliser le tunnel IPsec pour un trafic très sécurisé et d’utiliser le
peering privé pour toutes les autres catégories de trafic permet d’optimiser l’utilisation
de la bande passante ExpressRoute.
VPN de site à site en tant que chemin de basculement

sécurisé pour ExpressRoute
ExpressRoute est utilisé comme une paire de circuits redondants pour garantir une
haute disponibilité. Vous pouvez configurer une connectivité ExpressRoute géo-
redondante dans différentes régions Azure. En outre, comme nous l’avons démontré
dans notre initialisation (tearDown) de test, dans une région Azure, vous pouvez utiliser
un VPN de site à site pour créer un chemin de basculement pour votre connectivité
ExpressRoute. Quand les mêmes préfixes sont publiés sur ExpressRoute et un VPN de
site à site, Azure choisit en priorité ExpressRoute. Pour éviter un routage asymétrique
entre ExpressRoute et le VPN de site à site, la configuration réseau locale doit en faire
autant en utilisant la connectivité ExpressRoute avant la connectivité VPN de site à site.
Pour plus d’informations sur la façon de configurer des connexions coexistantes pour
ExpressRoute et un VPN de site à site, consultez Coexistence de connexions
ExpressRoute et de site à site.
Étendre la connectivité de back-end à des
réseaux virtuels spoke et à des emplacements
de branche
Connectivité de réseau virtuel spoke à l’aide de

l’appairage de réseaux virtuels
L’architecture du réseau virtuel hub-and-spoke est largement utilisée. Le hub est un
réseau virtuel dans Azure qui centralise la connectivité entre vos réseaux virtuels spoke
et vers votre réseau local. Les spokes sont des réseaux virtuels appairés avec le hub et
que vous pouvez utiliser pour isoler des charges de travail. Le trafic circule entre le
centre de données local et le hub via une connexion ExpressRoute ou VPN. Pour plus
d’informations sur l’architecture, consultez Implémenter une topologie réseau hub-and-
spoke dans Azure.
Dans l’appairage de réseaux virtuels au sein d’une région, les réseaux virtuels spoke
peuvent utiliser des passerelles de réseau virtuel hub (passerelles VPN et ExpressRoute)
pour communiquer avec des réseaux distants.
Connectivité de réseau virtuel de branche à l’aide d’un

VPN de site à site
Il est possible que vous souhaitiez que des réseaux virtuels de branche, qui se trouvent
dans différentes régions, et des réseaux locaux communiquent entre eux via un réseau
virtuel hub. La solution Azure native pour cette configuration est la connectivité VPN de
site à site à l’aide d’un VPN. Une autre solution consiste à utiliser une appliance virtuelle
réseau (NVA) pour le routage dans le hub.
Pour plus d’informations, consultez Qu’est-ce qu’une passerelle VPN ? et Déployer une
appliance virtuelle réseau hautement disponible.
Étapes suivantes
En savoir plus sur les détails de la configuration pour la topologie de test.
Découvrez-en plus sur l’analyse du plan de contrôle de configuration de test et les vues
de différents réseaux virtuels ou réseaux locaux virtuels (VLAN) dans la topologie.
En savoir plus sur l’analyse de plan de données de l’initialisation (tearDown) de test et

les affichages des fonctionnalités de supervision du réseau Azure.
Consultez le FAQ ExpressRoute pour :
Connaître le nombre de circuits ExpressRoute que vous pouvez connecter à une

passerelle ExpressRoute.
Connaître le nombre de passerelles ExpressRoute que vous pouvez connecter à un

circuit ExpressRoute.
Découvrir les autres limites de mise à l’échelle d’ExpressRoute.

Interopérabilité des fonctionnalités de
connectivité de back-end Azure – Détails
de la configuration de test
Article • 10/04/2023
Cet article décrit les détails de configuration de l’initialisation (tearDown) de test.

L’initialisation (tearDown) de test vous permet d’analyser l’interopérabilité des services
de mise en réseau au niveau du plan de contrôle et du plan de données.
Connectivité de réseaux virtuels spokes à l’aide

de l’appairage de réseaux virtuels
La figure suivante montre les détails de l’appairage de réseaux virtuels Azure d’un
réseau virtuel spoke. Pour plus d’informations sur l’appairage entre deux réseaux
virtuels, consultez Gérer l’appairage de réseaux virtuels. Si vous souhaitez que le réseau
virtuel spoke utilise les passerelles qui sont connectées au réseau virtuel hub,
sélectionnez Utiliser des passerelles distantes.
La figure suivante montre les détails de l’appairage de réseaux virtuels d’un réseau
virtuel hub. Si vous souhaitez que le réseau virtuel hub autorise le réseau virtuel spoke à
utiliser les passerelles du hub, sélectionnez Autoriser le transit par passerelle.
Connectivité de réseau virtuel branch à l’aide
d’un VPN site à site
Configurez la connectivité VPN de site à site entre les réseaux virtuels hub et branch à
l’aide de passerelles VPN dans une passerelle VPN Azure. Par défaut, les passerelles VPN
et les passerelles Azure ExpressRoute utilisent la valeur de numéro de système
autonome (ASN) privée 65515. Vous pouvez changer la valeur ASN dans la passerelle
VPN. Dans l’initialisation (tearDown) de test, la valeur ASN de la passerelle VPN du
réseau virtuel branch est remplacée par 65516 pour prendre en charge le routage eBGP
entre les réseaux virtuels hub et branch.
Connectivité de l’emplacement Location 1 local
à l’aide d’ExpressRoute et d’un VPN de site à
site
Détails de la configuration d’ExpressRoute 1

La figure suivante montre la configuration du circuit ExpressRoute de région Azure 1
vers les routeurs de périphérie du client (CE) de l’emplacement Location 1 local :
La figure suivante montre la configuration de la connexion entre le circuit
ExpressRoute 1 et le réseau virtuel hub :
La liste suivante montre la configuration de routeur CE principal pour la connectivité de

peering privé ExpressRoute. (Les routeurs Cisco ASR1000 sont utilisés en tant que
routeurs CE dans l’initialisation (tearDown) de test.) Quand les circuits ExpressRoute et le
VPN de site à site sont configurés en parallèle pour connecter un réseau local à Azure,
Azure choisit en priorité le circuit ExpressRoute par défaut. Pour éviter un routage
asymétrique, le réseau local doit également donner la priorité à la connectivité
ExpressRoute plutôt qu’à la connectivité VPN de site à site. La configuration suivante
établit la hiérarchisation des priorités en utilisant l’attribut BGP local-préférence :
config
interface TenGigabitEthernet0/0/0.300
description Customer 30 private peering to Azure
encapsulation dot1Q 30 second-dot1q 300
ip vrf forwarding 30
ip address 192.168.30.17 255.255.255.252
!
interface TenGigabitEthernet1/0/0.30
description Customer 30 to south bound LAN switch
encapsulation dot1Q 30
ip address 192.168.30.0 255.255.255.254
ip ospf network point-to-point
!
router ospf 30 vrf 30
router-id 10.2.30.253
redistribute bgp 65021 subnets route-map BGP2OSPF
network 192.168.30.0 0.0.0.1 area 0.0.0.0
default-information originate always
default-metric 10
!
router bgp 65021
!
address-family ipv4 vrf 30
network 10.2.30.0 mask 255.255.255.128
neighbor 192.168.30.18 remote-as 12076
neighbor 192.168.30.18 activate
neighbor 192.168.30.18 next-hop-self
neighbor 192.168.30.18 soft-reconfiguration inbound
neighbor 192.168.30.18 route-map prefer-ER-over-VPN in
neighbor 192.168.30.18 prefix-list Cust30_to_Private out
exit-address-family
!
route-map prefer-ER-over-VPN permit 10
set local-preference 200
!
ip prefix-list Cust30_to_Private seq 10 permit 10.2.30.0/25
!
Détails de la configuration VPN de site à site

La liste suivante montre la configuration du routeur CE principal pour la connectivité
VPN de site à site :
config
crypto ikev2 proposal Cust30-azure-proposal

encryption aes-cbc-256 aes-cbc-128 3des
integrity sha1
group 2
!
crypto ikev2 policy Cust30-azure-policy
match address local 66.198.12.106
proposal Cust30-azure-proposal
!
crypto ikev2 keyring Cust30-azure-keyring
peer azure
address 52.168.162.84
pre-shared-key local IamSecure123
pre-shared-key remote IamSecure123
!
crypto ikev2 profile Cust30-azure-profile
match identity remote address 52.168.162.84 255.255.255.255
identity local address 66.198.12.106
authentication local pre-share
authentication remote pre-share
keyring local Cust30-azure-keyring
!
crypto ipsec transform-set Cust30-azure-ipsec-proposal-set esp-aes 256 esp-
sha-hmac
mode tunnel
!
crypto ipsec profile Cust30-azure-ipsec-profile
set transform-set Cust30-azure-ipsec-proposal-set
set ikev2-profile Cust30-azure-profile
!
interface Loopback30
ip address 66.198.12.106 255.255.255.255
!
interface Tunnel30
ip address 10.2.30.125 255.255.255.255
tunnel source Loopback30
tunnel mode ipsec ipv4
tunnel destination 52.168.162.84
tunnel protection ipsec profile Cust30-azure-ipsec-profile
!
router bgp 65021
!
address-family ipv4 vrf 30
network 10.2.30.0 mask 255.255.255.128
neighbor 10.10.30.254 remote-as 65515
neighbor 10.10.30.254 ebgp-multihop 5
neighbor 10.10.30.254 update-source Tunnel30
neighbor 10.10.30.254 activate
neighbor 10.10.30.254 soft-reconfiguration inbound
exit-address-family
!
ip route vrf 30 10.10.30.254 255.255.255.255 Tunnel30
Connectivité de l’emplacement Location 2 local

à l’aide d’ExpressRoute
Un deuxième circuit ExpressRoute, très proche de l’emplacement Emplacement 2 local,
connecte l’emplacement Emplacement 2 local au réseau virtuel hub. La figure suivante
montre la deuxième configuration ExpressRoute :
La figure suivante montre la configuration de la connexion entre le deuxième circuit
ExpressRoute et le réseau virtuel hub :
Le circuit ExpressRoute1 connecte le réseau virtuel hub et l’emplacement

Emplacement 1 local à un réseau virtuel distant dans une autre région Azure :

en tandem

Vous pouvez configurer un VPN site à site à l’aide du peering Microsoft ExpressRoute
virtuels Azure. Avec cette configuration, vous pouvez échanger des données en
garantissant confidentialité, authenticité et intégrité. L’échange de données est


de branche
Connectivité de réseaux virtuels spokes à l’aide de

spoke dans Azure.

VPN site à site
Il est possible que vous souhaitiez que des réseaux virtuels branch, qui se trouvent dans
différentes régions, et des réseaux locaux communiquent entre eux via un réseau virtuel
hub. La solution Azure native pour cette configuration est la connectivité VPN de site à
site à l’aide d’un VPN. Une autre solution consiste à utiliser une appliance virtuelle
Étapes suivantes
Découvrez-en plus sur l’analyse du plan de contrôle de l’initialisation (tearDown) de test
et les affichages des différents réseaux virtuels ou réseaux locaux virtuels (VLAN) dans la
topologie.
Découvrez l’analyse du plan de données de l’initialisation (tearDown) de test et les

affichages des fonctionnalités de supervision de réseau Azure.



Interopérabilité dans Azure : analyse du
plan de contrôle
Cet article décrit l’analyse du plan de contrôle de l’initialisation (tearDown) de test. Vous
pouvez également consulter la configuration de l’initialisation (tearDown) de test et
l’analyse du plan de données de l’initialisation (tearDown) de test.
L’analyse du plan de contrôle examine essentiellement les itinéraires qui sont échangés
entre des réseaux au sein d’une topologie. L’analyse du plan de contrôle vous permet de
comprendre comment des réseaux différents affichent la topologie.
Perspective du réseau virtuel Hub-and-spoke

La figure suivante illustre le réseau du point de vue d’un réseau virtuel hub et d’un
réseau virtuel spoke (mis en évidence en bleu). Cette figure montre également le
numéro de système autonome (ASN) de différents réseaux et les itinéraires qui sont
échangés entre réseaux différents :
L’ASN de la passerelle Azure ExpressRoute du réseau virtuel est différent de l’ASN des
routeurs Microsoft Enterprise Edge Router (MSEE). Une passerelle ExpressRoute utilise
un ASN privé (valeur de 65515) et les MSEE utilisent un ASN public (valeur de 12076)
dans le monde entier. Lorsque vous configurez le peering ExpressRoute, étant donné
que le MSEE est l’homologue, vous utilisez l’ASN d’homologue 12076. Du côté Azure,
MSEE établit le peering eBGP la passerelle ExpressRoute. Le double peering eBGP que
MSEE établit pour chaque peering ExpressRoute est transparent au niveau du plan de
contrôle. Par conséquent, lorsque vous visualisez une table de routage ExpressRoute,
l’ASN de la passerelle ExpressRoute du réseau virtuel s’affiche pour les préfixes du
réseau virtuel.
La figure suivante montre un exemple de table de routage ExpressRoute :
Dans Azure, l’ASN n’est significatif que de la perspective du peering. Par défaut, l’ASN
de la passerelle ExpressRoute et de la passerelle du réseau privé virtuel est 65515 dans la
passerelle VPN Azure.
Perspective du réseau virtuel distant et de

Emplacement 1 local via ExpressRoute 1
Le réseau local Emplacement 1 et le réseau virtuel distant sont connectés au réseau
virtuel du hub via ExpressRoute 1. Ils partagent la même perspective de la topologie,
comme le montre le schéma suivant :
Perspective du réseau local Emplacement 1 et
du réseau virtuel de branche via le VPN de site
à site
Le réseau local Emplacement 1 et le réseau virtuel de branche sont tous deux connectés
à la passerelle VPN du réseau virtuel du hub via une connexion VPN de site à site. Ils
partagent la même perspective de la topologie, comme le montre le schéma suivant :
Perspective du réseau local Location 2
Le réseau local Emplacement 2 est connecté au réseau virtuel du hub via le Peering privé
d’ExpressRoute 2 :

en tandem

Vous pouvez configurer un VPN de site à site à l’aide du Peering Microsoft ExpressRoute
pour échanger des données de façon privée entre votre réseau local et vos Réseaux
virtuels Microsoft Azure. Avec cette configuration, vous pouvez échanger des données
en garantissant confidentialité, authenticité et intégrité. L’échange de données est

de branche
Connectivité de réseau virtuel spoke à l’aide du Peering

de réseaux virtuels
spoke dans Azure.
Dans le Peering de réseaux virtuels au sein d’une région, les réseaux virtuels spoke

VPN de site à site
Étapes suivantes
Découvrez l’analyse du plan de données de l’initialisation (tearDown) de test et les
affichages des fonctionnalités de supervision de réseau Azure.



Interopérabilité dans Azure : analyse du
plan de données
Cet article décrit l’analyse du plan de données de l’initialisation (tearDown) de test. Vous
pouvez également consulter la configuration de l’initialisation (tearDown) de test et
l’analyse du plan de contrôle de l’initialisation (tearDown) de test.
L’analyse du plan de données examine le chemin emprunté par les paquets qui vont
d’un réseau local (LAN ou réseau virtuel) à l’autre au sein d’une topologie. Le chemin
des données entre deux réseaux locaux n’est pas nécessairement symétrique. Dans cet
article, nous analysons donc le chemin de transfert d’un réseau local vers un autre
réseau qui est distinct du chemin inverse.
Chemin d’accès aux données depuis le réseau

virtuel hub
Chemin d’accès au réseau virtuel spoke

L’appairage de réseaux virtuels émule les fonctionnalités de pont réseau entre les deux
réseaux virtuels qui sont appairés. La sortie de la détermination d’itinéraire d’un réseau
virtuel hub à une machine virtuelle dans le réseau virtuel spoke apparaît ici :
Console
C:\Users\rb>tracert 10.11.30.4
Tracing route to 10.11.30.4 over a maximum of 30 hops
1 2 ms 1 ms 1 ms 10.11.30.4
Trace complete.
La figure suivante présente la vue graphique de la connexion entre le réseau virtuel hub
et le réseau virtuel spoke de la perspective d’Azure Network Watcher :
Chemin d’accès au réseau virtuel de branche
La sortie de la détermination d’itinéraire d’un réseau virtuel hub à une machine virtuelle
dans le réseau virtuel de branche apparaît ici :
Console
1 1 ms 1 ms 1 ms 10.10.30.142
2 * * * Request timed out.
3 2 ms 2 ms 2 ms 10.11.30.68
Trace complete.
Dans cette détermination d’itinéraire, le premier tronçon est la passerelle VPN dans
Azure VPN Gateway, dans le réseau virtuel hub. Le deuxième tronçon est la passerelle
VPN du réseau virtuel de branche. L’adresse IP de la passerelle VPN du réseau virtuel de
branche n’est pas publiée dans le réseau virtuel hub. Le troisième tronçon est la machine
virtuelle dans le réseau virtuel de branche.
La figure suivante présente la vue graphique de la connexion entre le réseau virtuel hub
et le réseau virtuel de branche de la perspective de Network Watcher :
Pour la même connexion, la figure suivante montre le mode Grille dans Network
Watcher :
Chemin vers l’emplacement Location 1 local
La sortie de détermination d’itinéraire d’un réseau virtuel hub à une machine virtuelle
dans l’emplacement Location 1 local apparaît ici :
Console
1 2 ms 2 ms 2 ms 10.10.30.132
4 2 ms 2 ms 2 ms 10.2.30.10
Trace complete.
Dans cette détermination d’itinéraire, le premier tronçon est le point de terminaison du

tunnel de la passerelle Azure ExpressRoute pour un routeur Microsoft Enterprise Edge
(MSEE). Le deuxième et le troisième tronçons sont le routeur de périphérie du client (CE)
et les adresses IP du réseau local Location 1 local. Ces adresses IP ne sont pas publiées
dans le réseau virtuel hub. Le quatrième tronçon est la machine virtuelle dans
l’emplacement Location 1 local.

La sortie de détermination d’itinéraire d’un réseau virtuel hub à une machine virtuelle
Console
1 76 ms 75 ms 75 ms 10.10.30.134
4 75 ms 75 ms 75 ms 10.1.31.10
Trace complete.

tunnel de la passerelle ExpressRoute vers un routeur MSEE. Le deuxième et le troisième
tronçons sont le routeur CE et les adresses IP du réseau local Location 2 local. Ces
adresses IP ne sont pas publiées dans le réseau virtuel hub. Le quatrième tronçon est la
machine virtuelle sur l’emplacement Location 2 local.
Chemin d’accès au réseau virtuel distant

La sortie de la détermination d’itinéraire d’un réseau virtuel hub à une machine virtuelle
dans le réseau virtuel distant apparaît ici :
Console
1 2 ms 2 ms 2 ms 10.10.30.132
3 69 ms 68 ms 69 ms 10.17.30.4
Trace complete.

tunnel de la passerelle ExpressRoute vers un routeur MSEE. Le deuxième tronçon est
l’adresse IP de la passerelle du réseau virtuel distant. La plage d’adresses IP du deuxième
tronçon n’est pas publiée dans le réseau virtuel hub. Le troisième tronçon est la machine
virtuelle dans le réseau virtuel distant.
virtuel spoke
Le réseau virtuel spoke partage l’affichage en réseau du réseau virtuel hub. Par
l’appairage de réseaux virtuels, le réseau virtuel spoke utilise la connectivité de
passerelle distante du réseau virtuel hub comme s’il était directement connecté au
réseau virtuel spoke.
Chemin d’accès au réseau virtuel hub

La sortie de la détermination d’itinéraire du réseau virtuel spoke à une machine virtuelle
dans le réseau virtuel hub apparaît ici :
Console
1 <1 ms <1 ms <1 ms 10.10.30.4
Trace complete.

dans le réseau virtuel de branche apparaît ici :
Console
1 1 ms <1 ms <1 ms 10.10.30.142

3 3 ms 2 ms 2 ms 10.11.30.68
Trace complete.
Dans cette détermination d’itinéraire, le premier tronçon est la passerelle VPN du réseau
virtuel hub. Le deuxième tronçon est la passerelle VPN du réseau virtuel de branche.
L’adresse IP de la passerelle VPN du réseau virtuel de branche n’est pas publiée dans le
réseau virtuel hub/spoke. Le troisième tronçon est la machine virtuelle dans le réseau
virtuel de branche.

La sortie de détermination d’itinéraire du réseau virtuel spoke à une machine virtuelle
Console
1 24 ms 2 ms 3 ms 10.10.30.132
4 3 ms 2 ms 2 ms 10.2.30.10
Trace complete.

tunnel de la passerelle ExpressRoute du réseau virtuel hub à un MSEE. Le deuxième et le
troisième tronçons sont le routeur CE et les adresses IP du réseau local Location 1 local.
Ces adresses IP ne sont pas publiées dans le réseau virtuel hub/spoke. Le quatrième
tronçon est la machine virtuelle dans l’emplacement Location 1 local.

La sortie de détermination d’itinéraire du réseau virtuel spoke à une machine virtuelle
Console
1 76 ms 75 ms 76 ms 10.10.30.134
4 75 ms 75 ms 75 ms 10.1.31.10
Trace complete.
tunnel de la passerelle ExpressRoute du réseau virtuel hub à un MSEE. Le deuxième et le
troisième tronçons sont le routeur CE et les adresses IP du réseau local Location 2 local.
Ces adresses IP ne sont pas publiées dans les réseaux virtuels hub/spoke. Le quatrième
tronçon est la machine virtuelle dans l’emplacement Location 2 local.

Console
1 2 ms 1 ms 1 ms 10.10.30.133
3 71 ms 70 ms 70 ms 10.17.30.4
Trace complete.

tunnel de la passerelle ExpressRoute du réseau virtuel hub à un MSEE. Le deuxième
tronçon est l’adresse IP de la passerelle du réseau virtuel distant. La plage d’adresses IP
du deuxième tronçon n’est pas publiée dans le réseau virtuel hub/spoke. Le troisième
tronçon est la machine virtuelle dans le réseau virtuel distant.

virtuel de branche

La sortie de la détermination d’itinéraire du réseau virtuel de branche à une machine
virtuelle dans le réseau virtuel hub apparaît ici :
Console
C:\Windows\system32>tracert 10.10.30.4

1 <1 ms <1 ms <1 ms 10.11.30.100
3 4 ms 3 ms 3 ms 10.10.30.4
Trace complete.
virtuel de branche. Le deuxième tronçon est la passerelle VPN du réseau virtuel hub.
L’adresse IP de la passerelle VPN du réseau virtuel hub n’est pas publiée dans le réseau
virtuel distant. Le troisième tronçon est la machine virtuelle dans le réseau virtuel hub.

La sortie de la détermination d’itinéraire du réseau virtuel de branche à une machine
virtuelle dans le réseau virtuel spoke apparaît ici :
Console
1 1 ms <1 ms 1 ms 10.11.30.100
3 4 ms 3 ms 2 ms 10.11.30.4
Trace complete.
virtuel distant. Le troisième tronçon est la machine virtuelle dans le réseau virtuel spoke.

La sortie de détermination d’itinéraire du réseau virtuel de branche à une machine
virtuelle dans l’emplacement Location 1 local apparaît ici :
Console
1 1 ms <1 ms <1 ms 10.11.30.100

3 3 ms 2 ms 2 ms 10.2.30.125
5 3 ms 3 ms 3 ms 10.2.30.10
Trace complete.
virtuel distant. Le troisième tronçon est le point de terminaison du tunnel VPN sur le
routeur CE principal. Le quatrième tronçon est une adresse IP interne de l’emplacement
Location 1 local. Cette adresse IP de réseau local n’est pas publiée en dehors du
routeur CE. Le cinquième tronçon est la machine virtuelle de destination dans
l’emplacement Location 1 local.
Chemin d’accès à l’emplacement Location 2 local et au

réseau virtuel distant
Comme nous l’avons indiqué dans l’analyse du plan de contrôle, le réseau virtuel de
branche n’a aucune visibilité sur l’emplacement Location 2 local ou sur le réseau virtuel
distant selon la configuration réseau. Les résultats de test ping suivants le confirment :
Console
C:\Users\rb>ping 10.1.31.10
Pinging 10.1.31.10 with 32 bytes of data:
Request timed out.

...
Request timed out.

Request timed out.

...
Request timed out.

Chemin des données à partir de l’emplacement
Location 1 local

La sortie de détermination d’itinéraire de l’emplacement Location 1 local à une machine
Console
1 <1 ms <1 ms <1 ms 10.2.30.3

2 <1 ms <1 ms <1 ms 192.168.30.0
3 <1 ms <1 ms <1 ms 192.168.30.18
5 2 ms 2 ms 2 ms 10.10.30.4
Trace complete.
Dans cette détermination d’itinéraire, les deux premiers tronçons font partie du réseau
local. Le troisième tronçon est l’interface MSEE principale qui est accessible sur le
routeur CE. Le quatrième tronçon est la passerelle ExpressRoute du réseau virtuel hub.
La plage d’adresses IP de la passerelle ExpressRoute du réseau virtuel hub n’est pas
publiée sur le réseau local. Le cinquième tronçon est la machine virtuelle de destination.
Network Watcher fournit uniquement une vue centrée sur Azure. D’un point de vue
local, nous utilisons Azure Network Performance Monitor. Network Performance
Monitor fournit des agents que vous pouvez installer sur des serveurs dans des réseaux
en dehors d’Azure pour l’analyse du chemin des données.
La figure suivante présente l’affichage de la topologie de la connectivité de la machine

virtuelle de l’emplacement Location 1 local à la machine virtuelle sur le réseau virtuel
hub via ExpressRoute :
Comme indiqué précédemment, l’initialisation (tearDown) de test utilise un VPN site à
site comme connectivité de sauvegarde pour ExpressRoute entre l’emplacement
Location 1 local et le réseau virtuel hub. Pour tester le chemin des données de
sauvegarde, nous allons provoquer un échec de la liaison ExpressRoute entre le routeur
CE principal de l’emplacement Location 1 local et le composant MSEE correspondant.
Pour provoquer l’échec d’une liaison ExpressRoute, arrêtez l’interface CE qui est
accessible sur le composant MSEE :
Console
1 <1 ms <1 ms <1 ms 10.2.30.3

2 <1 ms <1 ms <1 ms 192.168.30.0
3 3 ms 2 ms 3 ms 10.10.30.4
Trace complete.
L’affichage de topologie de la connectivité de machine virtuelle de l’emplacement

Location 1 local apparaît dans la figure suivante. Cette connectivité est établie à la
machine virtuelle sur le réseau virtuel hub. La connectivité est obtenue via la
connectivité VPN site à site lorsque la connectivité ExpressRoute est en panne :

Rétablissons la connectivité principale ExpressRoute pour effectuer l’analyse du chemin

d’accès aux données vers le réseau virtuel spoke :
Console

1 <1 ms <1 ms <1 ms 10.2.30.3
2 <1 ms <1 ms <1 ms 192.168.30.0
3 <1 ms <1 ms <1 ms 192.168.30.18
5 3 ms 2 ms 2 ms 10.11.30.4
Trace complete.
Établissons la connectivité ExpressRoute 1 principale pour le reste de l’analyse du

chemin des données.

virtuelle dans le réseau virtuel de branche apparaît ici :
Console
1 <1 ms <1 ms <1 ms 10.2.30.3

2 <1 ms <1 ms <1 ms 192.168.30.0
3 3 ms 2 ms 2 ms 10.11.30.68
Trace complete.

Comme nous l’avons indiqué dans l’analyse du plan de contrôle, l’emplacement
Location 1 local n’a aucune visibilité sur l’emplacement Location 2 local selon la
configuration réseau. Les résultats de test ping suivants le confirment :
Console
Request timed out.

...
Request timed out.

virtuelle dans le réseau virtuel distant apparaît ici :
Console
1 <1 ms <1 ms <1 ms 10.2.30.3

2 2 ms 5 ms 7 ms 192.168.30.0
3 <1 ms <1 ms <1 ms 192.168.30.18
5 69 ms 70 ms 69 ms 10.17.30.4
Trace complete.
Chemin des données à partir de l’emplacement

Location 2 local

Console
1 <1 ms <1 ms <1 ms 10.1.31.3

2 <1 ms <1 ms <1 ms 192.168.31.4
3 <1 ms <1 ms <1 ms 192.168.31.22
5 75 ms 74 ms 74 ms 10.10.30.4
Trace complete.

Console

1 <1 ms <1 ms 1 ms 10.1.31.3
2 <1 ms <1 ms <1 ms 192.168.31.0
3 <1 ms <1 ms <1 ms 192.168.31.18
5 75 ms 74 ms 74 ms 10.11.30.4
Trace complete.
Chemin d’accès au réseau virtuel de branche, à

l’emplacement Location 1 local et au réseau virtuel distant
Comme nous l’avons indiqué dans l’analyse du plan de contrôle, l’emplacement
Location 1 local n’a aucune visibilité sur le réseau virtuel de branche, l’emplacement
Location 1 local ou le réseau virtuel distant selon la configuration réseau.

virtuel distant

La sortie de la détermination d’itinéraire du réseau virtuel distant à une machine virtuelle
dans le réseau virtuel hub apparaît ici :
Console
1 65 ms 65 ms 65 ms 10.17.30.36
3 69 ms 68 ms 68 ms 10.10.30.4
Trace complete.
Console
1 67 ms 67 ms 67 ms 10.17.30.36
3 71 ms 69 ms 69 ms 10.11.30.4
Trace complete.
Chemin du réseau virtuel de branche et de l’emplacement

Location 2 local
Comme nous l’avons indiqué dans l’analyse du plan de contrôle, le réseau virtuel distant
n’a aucune visibilité sur le réseau virtuel de branche ou sur l’emplacement Location 2
local selon la configuration réseau.

La sortie de détermination d’itinéraire du réseau virtuel distant à une machine virtuelle
Console
1 67 ms 67 ms 67 ms 10.17.30.36
4 69 ms 69 ms 69 ms 10.2.30.10
Trace complete.
en tandem

Vous pouvez configurer un VPN site à site à l’aide du Peering Microsoft ExpressRoute
virtuels Azure. Avec cette configuration, vous pouvez échanger des données en
garantissant confidentialité, authenticité et intégrité. L’échange de données est

de branche
Connectivité de réseau virtuel spoke à l’aide de

spoke dans Azure.

VPN site à site
Étapes suivantes


Permettre aux conteneurs d’utiliser les
fonctionnalités du réseau virtuel Azure
Apportez aux conteneurs l’ensemble complet des fonctionnalités du réseau Azure en

utilisant la même pile de mise en réseau à définition logicielle que celle qui alimente les
machines virtuelles. Le plug-in CNI (Container Network Interface) du réseau virtuel Azure
s’installe sur une machine virtuelle Azure. À partir d’un réseau virtuel, il attribue des
adresses IP aux conteneurs affichés dans la machine virtuelle, en les attachant au réseau
virtuel et en les connectant directement à d’autres conteneurs et à des ressources du
réseau virtuel. En ce qui concerne la connectivité, ce plug-in ne s’appuie pas sur des
réseaux superposés, ou des itinéraires, et les performances qu’il fournit sont les mêmes
que les machines virtuelles. Globalement, le plug-in offre les fonctionnalités suivantes :
Une adresse IP de réseau virtuel est affectée à chaque pod pouvant se composer
d’un ou de plusieurs conteneurs.
Les pods peuvent se connecter à des réseaux virtuels appairés, et localement via
ExpressRoute ou un VPN de site à site. Les pods sont également accessibles à
partir de réseaux appairés et locaux.
Les pods peuvent accéder à des services, tels que le stockage Azure et Azure SQL
Database, qui sont protégés par des points de terminaison de service de réseau
virtuel.
Les itinéraires et les groupes de sécurité réseau peuvent être appliqués

directement aux pods.
Les pods peuvent être placés immédiatement derrière un équilibreur de charge

interne ou public Azure, tout comme les machines virtuelles.
Une adresse IP publique peut être affectée aux pods, ce qui les rend accessibles
directement depuis internet. Les pods peuvent également accéder eux-mêmes à
internet.
Fonctionne de façon transparente avec les ressources Kubernetes, telles que

Services, les contrôleurs d’entrée et Kube DNS. Un service Kubernetes peut
également être exposé en interne ou en externe via Azure Load Balancer.
L’image suivante illustre l’approvisionnement par le plug-in des fonctionnalités de

réseau virtuel Azure aux pods :
Le plug-in prend en charge les plateformes Linux et Windows.
Connexion de pods à un réseau virtuel

Les pods sont affichés sur une machine virtuelle qui fait partie d’un réseau virtuel. Un
pool d’adresses IP est configuré pour les pods en tant qu’adresses secondaires sur
l’interface réseau d’une machine virtuelle. Azure CNI configure la connectivité réseau de
base des pods et gère l’utilisation des adresses IP dans le pool. Quand un pod s’affiche
dans la machine virtuelle, Azure CNI attribue une adresse IP disponible à partir du pool
et connecte le pod à un pont logiciel dans la machine virtuelle. À l’extinction du pod,
l’adresse IP est restituée au pool. L’image suivante illustre la connexion des pods à un
réseau virtuel :
Accès à Internet
Pour permettre aux pods d’accéder à internet, le plug-in configure des règles iptables
pour traduire en adresse réseau (NAT) le trafic lié à internet provenant des pods.
L’adresse IP source du paquet est translatée vers l’adresse IP principale sur l’interface
réseau de la machine virtuelle. Les machines virtuelles Windows traduisent
automatiquement en adresses réseau sources (SNAT) le trafic destiné aux adresse IP
situées en dehors du sous-réseau dans lequel se trouve la machine virtuelle. En règle
générale, tout le trafic destiné à une adresse IP située en dehors de la plage IP du réseau
virtuel est traduit.
limites
Le plug-in prend en charge jusqu’à 250 pods par machine virtuelle, et jusqu’à
16 000 pods au sein d’un réseau virtuel. Ces limites sont différentes pour
l’environnement Azure Kubernetes Service.
Utilisation du plug-in
Le plug-in peut être utilisé de différentes manières, afin de fournir une attache de réseau
virtuel de base aux pods ou aux conteneurs Docker :
Azure Kubernetes Service : Le plug-in est intégré à Azure Kubernetes Service (AKS)
et peut être utilisé en choisissant l’option Advanced Networking (Mise en réseau
avancée). Une mise en réseau avancée vous permet de déployer un cluster
Kubernetes dans un réseau virtuel existant ou nouveau. Pour en savoir plus sur la
mise en réseau avancée et les étapes de sa configuration, consultez Configuration
avancée du réseau dans AKS.
AKS-Engine : AKS-Engine est un outil qui génère un modèle Azure Resource

Manager pour déployer un cluster Kubernetes dans Azure. Pour obtenir des
instructions détaillées, consultez Déployer le plug-in pour les clusters Kubernetes
AKS-Engine.
Création de votre propre cluster Kubernetes dans Azure : Le plug-in peut être
utilisé pour fournir la mise en réseau de base des pods dans les clusters
Kubernetes que vous déployez vous-même, sans appui nécessaire sur AKS, ou sur
des outils tels que AKS-Engine. Dans ce cas, le plug-in est installé et activé sur
chaque machine virtuelle d’un cluster. Pour obtenir des instructions détaillées,
consultez Déployer le plug-in pour un cluster Kubernetes que vous déployez vous-
même.
Attache de réseau virtuel pour les conteneurs Docker dans Azure : Le plug-in
peut être utilisé dans les cas où vous ne souhaitez pas créer de cluster Kubernetes,
mais aimeriez créer des conteneurs Docker avec des attaches de réseau virtuel, sur
les machines virtuelles. Pour obtenir des instructions détaillées, consultez Déployer
le plug-in pour Docker.
Étapes suivantes
Déployer la mise en réseau de conteneurs pour un hôte Docker Linux autonome
Déployer la mise en réseau de conteneurs pour un hôte Docker Windows

autonome
Déployer le plug-in pour des clusters Kubernetes ou des conteneurs Docker

Connectivité interréseau
Article • 01/06/2023
Fabrikam Inc. a une présence physique et un déploiement Azure importants dans la

région USA Est. Fabrikam a une connectivité back-end entre ses déploiements locaux et
Azure par le biais d’ExpressRoute. De même, Contoso Ltd. est présent et dispose d'un
déploiement Azure dans la région USA Ouest. Contoso a une connectivité back-end
entre ses déploiements locaux et Azure par le biais d’ExpressRoute.
Fabrikam Inc. acquiert Contoso Ltd. Suite à la fusion, Fabrikam souhaite interconnecter
les réseaux. La figure suivante illustre le scénario :
Les flèches pointillées situées au centre de la figure ci-dessus indiquent les

interconnexions réseau souhaitées. Plus précisément, les interconnexions souhaitées se
décomposent en trois types : 1) Interconnexion des réseaux virtuels de Fabrikam et
Contoso, 2) Connexions interrégionales locales et connexions entre réseaux virtuels
(c'est-à-dire la connexion du réseau local de Fabrikam au réseau virtuel de Contoso et la
connexion du réseau local de Contoso au réseau virtuel de Fabrikam), et 3)
Interconnexion des réseaux locaux de Fabrikam et Contoso.
Le tableau suivant présente la table de routage du peering privé du circuit ExpressRoute
de Contoso Ltd., avant la fusion.
Le tableau suivant présente les itinéraires effectifs d'une machine virtuelle de

l'abonnement Contoso, avant la fusion. Selon le tableau, la machine virtuelle du réseau
virtuel connaît l'espace d'adressage du réseau virtuel et le réseau local de Contoso, à
l'exception de ceux par défaut.

de Fabrikam Inc, avant la fusion.
Le tableau suivant présente les itinéraires effectifs d'une machine virtuelle de
l'abonnement Fabrikam, avant la fusion. Selon le tableau, la machine virtuelle du réseau
virtuel connaît l'espace d'adressage du réseau virtuel et le réseau local de Fabrikam, à
l'exception de ceux par défaut.
Dans cet article, nous allons passer chaque étape en revue et expliquer comment
obtenir les interconnexions souhaitées à l'aide des fonctionnalités réseau Azure
suivantes :

Connexion de réseau virtuel ExpressRoute
Global Reach
Interconnexion des réseaux virtuels

Le peering de réseaux virtuels (VNet Peering) est celui qui offre les meilleurs résultats et
les meilleures performances réseau lors de la connexion de deux réseaux virtuels. Le
peering de réseaux virtuels prend en charge le peering de deux réseaux virtuels dans la
même région Azure (communément appelé VNet Peering) ainsi que dans deux régions
Azure différentes (communément appelé Global VNet Peering).
Nous allons configurer le Global VNet Peering entre les réseaux virtuels des
abonnements Azure de Contoso et Fabrikam. Pour plus d’informations sur l’appairage
de deux réseaux virtuels, consultez l’article Créer un appairage de réseaux virtuels.
L'illustration suivante présente l'architecture réseau après la configuration du Global

VNet Peering.
Le tableau suivant présente les itinéraires connus pour accéder à la machine virtuelle de
l'abonnement Contoso. Prêtez attention à la dernière entrée du tableau. Cette entrée est
le résultat de l'interconnexion des réseaux virtuels.
l'abonnement Fabrikam. Prêtez attention à la dernière entrée du tableau. Cette entrée
est le résultat de l'interconnexion des réseaux virtuels.
Le VNet Peering relie directement deux réseaux virtuels (absence de tronçon suivant
pour l'entrée VNetGlobalPeering dans les deux tableaux ci-dessus)
Interconnexion des réseaux virtuels avec les

réseaux locaux
Nous pouvons connecter un circuit ExpressRoute à différents réseaux virtuels. Consultez
Limites du service et de l’abonnement pour connaître le nombre maximum de réseaux
virtuels qui peuvent être connectés à un circuit ExpressRoute.
Connectons le circuit ExpressRoute de Fabrikam au réseau virtuel de l'abonnement

Contoso et, de la même manière, le circuit ExpressRoute de Contoso au réseau virtuel de
l'abonnement Fabrikam afin de permettre l'interconnexion entre les réseaux virtuels et
les réseaux locaux. Pour connecter un réseau virtuel à un circuit ExpressRoute d'un autre
abonnement, vous devez créer et utiliser une autorisation. Consultez l'article : Connecter
un réseau virtuel à un circuit ExpressRoute.
L'illustration suivante présente l'architecture réseau après la configuration de

l'interconnexion du circuit ExpressRoute avec les réseaux virtuels.

de Contoso Ltd., après l'interconnexion des réseaux virtuels avec les réseaux locaux via
ExpressRoute. Vérifiez que la table de routage contient des itinéraires appartenant aux
deux réseaux virtuels.
de Fabrikam Inc., après l'interconnexion des réseaux virtuels avec les réseaux locaux via
ExpressRoute. Vérifiez que la table de routage contient des itinéraires appartenant aux
deux réseaux virtuels.
l'abonnement Contoso. Prêtez attention aux entrées Passerelle de réseau virtuel du
tableau. La machine virtuelle voit les itinéraires des deux réseaux locaux.
l'abonnement Fabrikam. Prêtez attention aux entrées Passerelle de réseau virtuel du
tableau. La machine virtuelle voit les itinéraires des deux réseaux locaux.
７ Notes
Dans l'un ou l'autre des abonnements Fabrikam et/ou Contoso, vous pouvez
également avoir des réseaux virtuels Spoke connectés au réseau virtuel Hub
correspondant (la conception Hub et Spoke n'est pas illustrée dans les diagrammes
d'architecture de cet article). Les interconnexions entre les passerelles de réseau
virtuel Hub et ExpressRoute permettront également la communication entre les
Hubs et Spokes Est et Ouest.
Interconnexion des réseaux locaux
ExpressRoute Global Reach assure la connectivité entre les réseaux locaux connectés à
différents circuits ExpressRoute. Configurons Global Reach entre les circuits
ExpressRoute de Contoso et Fabrikam. Comme les circuits ExpressRoute se trouvent
dans des abonnements différents, nous devons créer et utiliser une autorisation. Pour
des instructions détaillées, consultez l’article Configurer ExpressRoute Global Reach.
L'illustration suivante présente l'architecture réseau après la configuration de Global

Reach.

de Contoso Ltd., après la configuration de Global Reach. Vérifiez que la table de routage
contient des itinéraires appartenant aux deux réseaux locaux.
de Fabrikam Inc., après la configuration de Global Reach. Vérifiez que la table de routage
contient des itinéraires appartenant aux deux réseaux locaux.
Étapes suivantes
Pour toute question complémentaire sur les réseaux virtuels et le peering de réseau
virtuel, consultez l’article FAQ sur les réseaux virtuels. Pour toute question
complémentaire sur ExpressRoute et la connectivité des réseaux virtuels, consultez
l’article FAQ sur ExpressRoute.
Global Reach est déployé pays/région par pays/région. Pour vérifier si Global Reach est
disponible dans les pays/régions qui vous intéressent, consultez ExpressRoute Global
Reach.
Article • 28/05/2023
L'appairage de réseaux virtuels vous permet de connecter en toute transparence deux

ou plusieurs réseaux virtuels dans Azure. Les réseaux virtuels apparaissent comme un
seul réseau à des fins de connectivité. Le trafic entre les machines virtuelles des réseaux
virtuels appairés utilise l'infrastructure principale de Microsoft. À l’instar du trafic entre
les machines virtuelles du même réseau, le trafic est acheminé via le réseau privé de
Microsoft uniquement.
Azure prend en charge les types de Peering suivants :
Appairage de réseaux virtuels : connexion des réseaux virtuels au sein d’une

même région Azure.
Appairage de réseaux virtuels mondiaux : connecte des réseaux virtuels entre les
différentes régions Azure.
Voici quelques-uns des avantages du peering de réseaux virtuels, qu’il soit local ou
global :
Connexion à latence faible et haut débit entre les ressources de différents réseaux
virtuels.
Possibilité pour les ressources d’un réseau virtuel de communiquer avec celles d’un
autre réseau virtuel.
Possibilité de transférer des données entre des réseaux virtuels dans des
abonnements Azure, des locataires Azure Active Directory, des modèles de
déploiement et des régions Azure.
Possibilité d’appairer des réseaux virtuels créés via Azure Resource Manager.
Possibilité d’appairer un réseau virtuel créé via Resource Manager à un réseau créé
par le biais du modèle de déploiement classique. Pour en savoir plus sur les
modèles de déploiement Azure, consultez l’article Déploiement Azure Resource
Manager et déploiement classique : comprendre les modèles de déploiement et
l’état de vos ressources.
Aucune interruption des ressources dans un réseau virtuel lors de la création du

peering ou après que le peering est créé.
Le trafic réseau entre les réseaux virtuels homologués est privé. Le trafic entre les
réseaux virtuels reste sur le réseau principal de Microsoft. Aucun chiffrement et aucune
connexion Internet publique, ni passerelle ne sont nécessaires pour que les réseau
virtuels communiquent.
Connectivité
Pour les réseaux virtuels appairés, les ressources de l’un peuvent se connecter
directement à celles du réseau virtuel appairé.
La latence du réseau entre des machines virtuelles de réseaux virtuels homologués dans
la même région est la même que celle d’un seul réseau virtuel. Le débit du réseau
repose sur la bande passante autorisée pour la machine virtuelle proportionnellement à
sa taille. Aucune restriction de bande passante supplémentaire n’est appliquée au sein
du peering.
Le trafic entre les machines virtuelles dans des réseaux virtuels homologués est
acheminé directement via l’infrastructure principale de Microsoft et non via une
passerelle ou une connexion Internet publique.
Vous pouvez appliquer des groupes de sécurité réseau dans l’un ou l’autre des réseaux
virtuels pour bloquer l’accès à d’autres réseaux virtuels ou sous-réseaux. Quand vous
configurez le peering des réseaux virtuels, vous pouvez ouvrir ou fermer les règles de
groupe de sécurité réseau entre les réseaux virtuels. Si vous ouvrez totalement la
connectivité entre les réseaux virtuels appairés, vous pouvez appliquer des groupes de
sécurité réseau pour bloquer ou refuser certains accès. La connectivité entièrement
ouverte est l’option par défaut. Pour en savoir plus sur les groupes de sécurité réseau,
voir Groupes de sécurité.
Redimensionner l’espace d’adressage des

réseaux virtuels Azure appairés
Vous pouvez redimensionner l’espace d’adressage des réseaux virtuels Azure qui sont
appairés sans que cela n’entraîne de temps d’arrêt sur l’espace d’adressage
actuellement appairé. Cette fonctionnalité est utile lorsque vous devez redimensionner
l’espace d’adressage d’un réseau virtuel après avoir mis à l’échelle vos charges de travail.
Une fois l’espace d’adressage redimensionné, les homologues doivent se synchroniser
avec les nouvelles modifications de l’espace d’adressage. Le redimensionnement
fonctionne pour les espaces d’adressage IPv4 et IPv6.
Les adresses peuvent être redimensionnées des manières suivantes :

Modification du préfixe de plage d’adresses d’une plage d’adresses existante (par
exemple, changement de 10.1.0.0/16 en 10.1.0.0/18)
Ajout de plages d’adresses à un réseau virtuel
Suppression de plages d’adresses d’un réseau virtuel
Le redimensionnement de l’espace d’adressage est pris en charge entre locataires
La synchronisation des réseaux virtuels appairés est possible via le portail Azure ou avec
Azure PowerShell. Nous vous recommandons d’effectuer la synchronisation après
chaque nouvelle opération de redimensionnement de l’espace d’adressage au lieu de le
faire après plusieurs opérations de redimensionnement consécutives. Pour savoir
comment mettre à jour l’espace d’adressage d’un réseau virtuel appairé, consultez Mise
à jour de l’espace d’adressage d’un réseau virtuel appairé.
） Important
Cette fonctionnalité ne prend pas en charge les scénarios où le réseau virtuel à

mettre à jour est appairé avec :
Un réseau virtuel classique

Un réseau virtuel managé tel que le hub Azure VWAN
Chaînage de services
Le chaînage de services vous permet de diriger le trafic d’un réseau virtuel vers
l’appliance virtuelle ou la passerelle d’un réseau appairé via des itinéraires définis par
l’utilisateur.
Pour activer le chaînage de services, configurez des itinéraires définis par l’utilisateur qui
pointent vers des machines virtuelles de réseaux virtuels appairés en tant qu’adresse IP
du tronçon suivant. Les itinéraires définis par l’utilisateur peuvent également pointer vers
des passerelles de réseau virtuel pour activer le chaînage de services.
Vous pouvez également déployer des réseaux de type hub-and-spoke où le réseau

virtuel hub héberge des composants d’infrastructure tels qu’une appliance virtuelle
réseau ou une passerelle VPN. Tous les réseaux virtuels spoke peuvent ensuite être
homologués avec le réseau virtuel hub. Le trafic transite par des appliances virtuelles
réseau ou des passerelles VPN sur le réseau virtuel hub.
Le peering de réseaux virtuels permet de définir le tronçon suivant dans un itinéraire
défini par l’utilisateur sur l’adresse IP d’une machine virtuelle du réseau virtuel appairé
ou une passerelle VPN. Vous ne pouvez pas définir d’itinéraires entre plusieurs réseaux
virtuels avec un itinéraire défini par l’utilisateur qui spécifie une passerelle Azure
ExpressRoute comme type de tronçon suivant. Pour en savoir plus sur les routages
définis par l’utilisateur, voir Vue d’ensemble des routages définis par l’utilisateur. Pour
découvrir comment créer une topologie de réseau hub-and-spoke, consultez
Implémenter une topologie de réseau hub-and-spoke dans Azure.
Passerelles et connectivité locale

Chaque réseau virtuel, y compris un réseau virtuel appairé, peut avoir sa propre
passerelle. Un réseau virtuel peut utiliser sa passerelle pour se connecter à un réseau
local. Vous pouvez également configurer des connexions de réseau virtuel à réseau
virtuel à l’aide de passerelles, même pour les réseaux virtuels appairés.
Lorsque vous configurez les deux options d’interconnexion de réseaux virtuels, le trafic
entre les réseaux virtuels transite via la configuration de Peering. Le trafic utilise le
réseau principal Azure.
Vous pouvez également configurer la passerelle du réseau virtuel appairé en tant que
point de transit vers un réseau local. Dans ce cas, le réseau virtuel qui utilise une
passerelle distante ne peut pas posséder sa propre passerelle. Un réseau virtuel ne peut
avoir qu’une seule passerelle, et la passerelle doit être locale ou distante dans le réseau
virtuel appairé, comme illustré dans le diagramme suivant :
L’appairage de réseaux virtuels et l’appairage de réseaux virtuels mondiaux prennent en
charge le transit par passerelle.
Le transit par passerelle entre des réseaux virtuels créés via des modèles de déploiement
différents est pris en charge. La passerelle doit donc figurer dans un réseau virtuel du
modèle Resource Manager. Pour en savoir plus sur l’utilisation d’une passerelle pour le
transit, consultez Configure a VPN gateway for transit in a virtual network peering
(Configurer une passerelle VPN pour le transit dans une homologation de réseaux
virtuels).
Lorsque vous appairez des réseaux virtuels qui partagent une connexion Azure
ExpressRoute unique, le trafic entre eux transite par la relation de Peering. Ce trafic
utilise le réseau principal Azure. Vous pouvez toujours utiliser des passerelles locales
dans chaque réseau virtuel pour vous connecter au circuit local. Dans le cas contraire,
vous pouvez utiliser une passerelle partagée et configurer le transit pour la connectivité
locale.
Dépanner
Pour confirmer que les réseaux virtuels sont appairés, vous pouvez vérifier les itinéraires
effectifs. Vérifiez les itinéraires pour une interface réseau dans tout sous-réseau d’un
réseau virtuel. Si une homologation de réseaux virtuels existe, tous les sous-réseaux au
sein du réseau virtuel ont des itinéraires avec le type de tronçon suivant VNet Peering
pour chaque espace d’adressage de chaque réseau virtuel homologué. Pour plus
d’informations, consultez Diagnostiquer un problème de routage sur une machine
virtuelle.
Vous pouvez aussi résoudre les problèmes de connectivité à la machine virtuelle d’un
réseau virtuel appairé à l’aide d’Azure Network Watcher. Une vérification de la
connectivité vous permet de voir comment le trafic est acheminé à partir de l’interface
réseau d’une machine virtuelle source vers l’interface réseau d’une machine virtuelle de
destination. Pour plus d’informations, consultez Détecter un problème de connexion
avec Azure Network Watcher à l’aide du Portail Azure.
Vous pouvez également essayer Détecter un problème d’appairage de réseaux virtuels.
Contraintes pour les réseaux virtuels appairés

Les contraintes ci-après s’appliquent uniquement quand des réseaux virtuels sont
appairés à l’échelle mondiale :
Les ressources situées dans un réseau virtuel ne peuvent pas communiquer avec
l’adresse IP front-end d’un équilibreur de charge De base (interne ou public) dans
un réseau virtuel appairé à l’échelle mondiale.
Certains services qui utilisent un équilibreur de charge De base ne fonctionnent

pas sur l’appairage de réseaux virtuels mondiaux. Pour plus d’informations,
consultez Quelles sont les contraintes liées aux équilibreurs de charge et à
l’appairage de réseaux virtuels mondiaux ?.
Pour plus d’informations, consultez Configuration requise et contraintes. Pour en savoir

plus sur le nombre de Peerings pris en charge, consultez Limites de mise en réseau.
Autorisations
Pour en savoir plus sur les autorisations requises pour créer un appairage de réseaux
virtuels, consultez Autorisations.
Tarifs
Un coût nominal s’applique pour le trafic entrant et sortant qui utilise une connexion
d’appairage de réseaux virtuels. Pour plus d’informations, consultez Tarification de
Réseau virtuel Microsoft Azure .
Le transit par passerelle est une propriété de Peering qui permet à un réseau virtuel
d’exploiter la passerelle VPN/ExpressRoute d’un réseau virtuel appairé. Le transit par
passerelle fonctionne pour la connectivité intersite et de réseau à réseau. Le trafic vers la
passerelle (entrant ou sortant) dans le réseau virtuel appairé entraîne des frais
d’appairage de réseaux virtuels sur le réseau virtuel spoke (ou réseau virtuel sans
passerelle VPN). Pour plus d’informations, consultez Tarification de la passerelle VPN
pour connaître les frais de passerelle VPN et Tarification de la passerelle ExpressRoute
pour ceux de la passerelle ExpressRoute.
７ Notes
Une version précédente de ce document indiquait que les frais d’appairage de

réseaux virtuels ne s’appliquaient pas au réseau virtuel spoke (ou réseau virtuel
non-passerelle) avec un transit par passerelle. Le document reflète désormais la
tarification exacte, conformément à la page de tarification.
Étapes suivantes
Vous pouvez créer un Peering entre deux réseaux virtuels. Les réseaux peuvent
appartenir au même abonnement, à des modèles de déploiement différents dans
le même abonnement ou à des abonnements différents. Suivez un didacticiel pour
l’un des scénarios suivants :
Modèle de déploiement Azure Abonnement
Les deux modèles Resource Manager Identique
Différent
Un modèle Resource Manager, un modèle classique Identique
Différent
Pour découvrir comment créer une topologie de réseau hub-and-spoke, consultez

Implémenter une topologie de réseau hub-and-spoke dans Azure.
Pour en savoir plus sur tous les paramètres d’appairage de réseaux virtuels,
consultez Créer, modifier ou supprimer un appairage de réseaux virtuels.
Pour obtenir des réponses aux questions fréquentes sur l’appairage de réseaux
virtuels et l’appairage de réseaux virtuels mondiaux, consultez Appairage de
réseaux virtuels.
Intégrer des services Azure à des
réseaux virtuels pour l’isolement réseau
Article • 15/05/2023
L’intégration d’un réseau virtuel pour un service Azure vous permet de verrouiller l’accès
au service à votre infrastructure de réseau virtuel uniquement. L’infrastructure de réseau
virtuel comprend également des réseaux virtuels appairés et des réseaux locaux.
L’intégration au réseau virtuel offre aux services Azure les avantages de l’isolement
réseau et peut être accomplie à l’aide d’une ou plusieurs des méthodes suivantes :

réseaux locaux.
Utilisation d’un point de terminaison privé qui vous permet de vous connecter de
façon privée et sécurisée à un service basé sur Azure Private Link. Le point de
terminaison privé utilise une adresse IP privée de votre réseau virtuel pour
apporter le service à votre réseau virtuel de façon effective.
Accès au service à l’aide de points de terminaison publics en étendant un réseau

virtuel au service par le biais de points de terminaison de service. Les points de
terminaison de service permettent de sécuriser les ressources de service au sein du
réseau virtuel.
Utilisation d’étiquettes de service pour autoriser ou refuser le trafic vers vos

ressources Azure vers et depuis des points de terminaison IP publics.
Déployer des services Azure dédiés dans des

réseaux virtuels
Quand vous déployez des services Azure dédiés sur un réseau virtuel, vous pouvez
communiquer avec les ressources de service de manière privée, par le biais d’adresses IP
privées.
Le déploiement d’un service Azure dédié dans votre réseau virtuel offre les capacités
suivantes :
Les ressources situées sur le réseau virtuel peuvent communiquer entre elles de
manière privée, par le biais d’adresses IP privées. Exemple : le transfert direct des
données entre HDInsight et SQL Server sur une machine virtuelle, au sein d’un
réseau virtuel.
Les ressources locales peuvent accéder aux ressources d’un réseau virtuel à l’aide
d’adresses IP privées par le biais d’une connexion VPN site à site (passerelle VPN)
ou ExpressRoute.
Les réseaux virtuels peuvent être appairés pour permettre aux ressources situées
sur les réseaux virtuels de communiquer entre elles, par le biais d’adresses IP
privées.
Le service Azure gère entièrement les instances de service dans un réseau virtuel.
Cette gestion inclut la surveillance de l’intégrité des ressources et la mise à
l’échelle avec une charge.
Les instances de service sont déployées dans un sous-réseau d’un réseau virtuel.
L’accès au réseau entrant ou sortant pour le sous-réseau doit être ouvert par le
biais de groupes de sécurité réseau, selon les recommandations fournies par le
service.
Certains services imposent des restrictions sur le sous-réseau dans lequel ils sont
déployés. Ces restrictions limitent l’application de stratégies, d’itinéraires, ou la
combinaison de machines virtuelles et de ressources du service au sein d’un même
sous-réseau. Vérifiez sur chaque service les restrictions spécifiques, car elles
peuvent changer au fil du temps. Azure NetApp Files, Dedicated HSM, Azure
Container Instances, App Service sont des exemples de ces services.
Les services peuvent éventuellement nécessiter un sous-réseau délégué comme

identificateur explicit qu’un sous-réseau peut héberger un service particulier. Les
services Azure reçoivent des autorisations explicites pour créer des ressources
propres au service dans le sous-réseau délégué.
Consultez un exemple de réponse de l’API REST sur un réseau virtuel avec un sous-
réseau délégué. Une liste complète de services qui utilisent le modèle de sous-
réseau délégué peut être obtenue via l’API Available Delegations (Délégations
disponibles).
Pour obtenir la liste des services qui peuvent être déployés dans un réseau virtuel,
consultez Déployer des services Azure dédiés dans des réseaux virtuels.
Liaison privée et points de terminaison privés

Les points de terminaison privés autorisent l’entrée de trafic à partir de votre réseau
virtuel vers une ressource Azure en toute sécurité. Cette liaison privée est établie sans
qu’il soit nécessaire d’utiliser des adresses IP publiques. Un point de terminaison privé
est une interface réseau spéciale pour un service Azure dans votre réseau virtuel.
Lorsque vous créez un point de terminaison privé pour votre ressource, il offre une
connectivité sécurisée entre les clients de votre réseau virtuel et votre ressource Azure.
Une adresse IP est attribuée au point de terminaison privé à partir de la plage
d’adresses IP de votre réseau virtuel. La connexion entre le point de terminaison privé et
le service Azure utilise une liaison privée.
La partie droite du diagramme affiche une base de données Azure SQL Database en tant
que service PaaS cible. La cible peut être n’importe quel service qui prend en charge les
points de terminaison privés. Il existe plusieurs instances de SQL Server logique pour
plusieurs clients, qui sont toutes accessibles via des adresses IP publiques.
Dans ce cas, une instance de SQL Server logique est exposée avec un point de
terminaison privé. Le point de terminaison rend SQL Server accessible via une adresse IP
privée dans le réseau virtuel du client. En raison de la modification de la configuration
DNS, l’application cliente envoie maintenant son trafic directement à ce point de
terminaison privé. Le service cible verra le trafic provenant d’une adresse IP privée du
réseau virtuel.
La flèche verte représente une liaison privée. Une adresse IP publique peut encore
exister pour la ressource cible en même temps que le point de terminaison privé.
L’adresse IP publique n’est plus utilisée par l’application cliente. Le pare-feu peut
désormais interdire tout accès à cette adresse IP publique, ce qui la rend accessible
uniquement via des points de terminaison privés. Les connexions à un serveur SQL sans
point de terminaison privé du réseau virtuel sont toujours issues d’une adresse IP
publique. La flèche bleue représente ce flux.
L’application cliente utilise généralement un nom d’hôte DNS pour atteindre le service
cible. Aucune modification n’est requise pour l’application. La résolution DNS dans le
réseau virtuel doit être configurée pour résoudre le même nom d’hôte à l’adresse IP
privée de la ressource cible au lieu de l’adresse IP publique d’origine. Avec un chemin
d’accès privé entre le client et le service cible, le client ne repose pas sur l’adresse IP
publique. Le service cible peut désactiver l’accès public.
Cette exposition d’instances individuelles vous permet d'éviter le vol de données. Un

acteur malveillant ne peut pas collecter des informations de la base de données ni les
charger dans une autre base de données publique ou un autre compte de stockage.
Vous pouvez empêcher l’accès aux adresses IP publiques de tous les services PaaS. Vous
pouvez toujours autoriser l’accès aux instances PaaS via leurs points de terminaison
privés.
Pour plus d’informations sur Private Link et pour obtenir la liste des services Azure pris
en charge, consultez Qu’est-ce que Private Link ?
Points de terminaison de service

Les points de terminaison de service fournissent une connectivité directe et sécurisée
aux services Azure via le réseau principal Azure. Les points de terminaison permettent
de sécuriser vos ressources Azure critiques pour vos réseaux virtuels uniquement. Les
points de terminaison de service permettent aux adresses IP privées dans le réseau
virtuel d’atteindre un service Azure sans avoir besoin d’une adresse IP publique sortante.
Sans point de terminaison de service, il peut être difficile de limiter l’accès à votre réseau
virtuel uniquement. L’adresse IP source peut être modifiée ou partagée avec d’autres
clients. Par exemple, les services PaaS avec des adresses IP sortantes partagées. Avec les
points de terminaison de service, l’adresse IP source que le service cible voit devient une
adresse IP privée de votre réseau virtuel. Cette modification du trafic entrant permet
d’identifier facilement l’origine et de l’utiliser pour configurer des règles de pare-feu
appropriées. Par exemple, en autorisant uniquement le trafic à partir d’un sous-réseau
spécifique au sein de ce réseau virtuel.
Avec les points de terminaison de service, les entrées DNS pour les services Azure ne
sont pas modifiées et continuent de résoudre les adresses IP publiques attribuées au
service Azure.
Dans le diagramme ci-dessous, le côté droit est le même service PaaS cible. Sur la
gauche se trouve un réseau virtuel client avec deux sous-réseaux : le sous-réseau A, qui
a un point de terminaison de service vers Microsoft.Sql , et le sous-réseau B, qui n’a
aucun point de terminaison de service défini.
Lorsqu’une ressource du sous-réseau B tente d’atteindre un serveur SQL Server, elle

utilise une adresse IP publique pour les communications sortantes. La flèche bleue
représente ce trafic. Le pare-feu SQL Server doit utiliser cette adresse IP publique pour
autoriser ou bloquer le trafic réseau.
Lorsqu’une ressource du sous-réseau A tente d’atteindre un serveur de base de

données, elle est considérée comme une adresse IP privée à partir du réseau virtuel. Les
flèches vertes représentent ce trafic. Le pare-feu SQL Server peut désormais autoriser ou
bloquer spécifiquement le sous-réseau A. Il n’est pas nécessaire de connaître l’adresse IP
publique du service source.
Les points de terminaison de service s’appliquent à toutes les instances du service cible.
Par exemple, toutes les instances de SQL Server de clients Azure, pas seulement
l’instance du client.
Pour plus d’informations, consultez Points de terminaison de service de réseau virtuel.
Balises de service
Une balise de service représente un groupe de préfixes d’adresses IP d’un service Azure
donné. Avec des étiquettes de service, vous pouvez définir des contrôles d’accès réseau
sur des groupes de sécurité réseau ou le Pare-feu Azure. Vous pouvez autoriser ou
refuser le trafic pour le service. Pour autoriser ou refuser le trafic, spécifiez l’étiquette de
service dans le champ source ou de destination d’une règle.
Isoler le réseau et protéger vos ressources Azure d’Internet lorsque vous accédez aux
services Azure qui ont des points de terminaison publics. Créez des règles de groupe de
sécurité réseau entrant/sortant pour refuser le trafic vers et depuis Internet et autoriser
le trafic vers/à partir d’AzureCloud. Pour en savoir plus sur les étiquettes de service,
consultez Étiquettes de service disponibles pour des services Azure spécifiques.
Pour plus d’informations sur les étiquettes de service et les services Azure qui les
prennent en charge, consultez Vue d’ensemble des étiquettes de service.
Comparer des points de terminaison privés et

des points de terminaison de service
７ Notes
Microsoft recommande l’utilisation de Azure Private Link. Private Link offre de

meilleures fonctionnalités en termes d’accès privé au PaaS à partir d’un site local,
dans un service de protection et de mappage d’exfiltration des données intégré à
une adresse IP privée dans votre propre réseau. Pour plus d’informations, consultez
Azure Private Link
Plutôt que d’examiner uniquement leurs différences, il convient de souligner que les
points de terminaison de service et les points de terminaison privés ont des
caractéristiques communes.
Ces deux fonctionnalités sont utilisées pour un contrôle plus granulaire du pare-feu sur
le service cible. Par exemple, pour limiter l’accès aux bases de données SQL Server ou
aux comptes de stockage. Toutefois, l’opération est différente pour les deux, comme
indiqué plus en détail dans les sections précédentes.
Les deux approches résolvent le problème d'Insuffisance de ports SNAT (Network

Address Translation) sources. Vous risquez une insuffisance lorsque vous tunnelisez le
trafic via une appliance virtuelle réseau ou un service avec des limitations de port SNAT.
Lorsque vous utilisez des points de terminaison de service ou des points de terminaison
privés, le trafic prend directement un chemin d’accès optimisé vers le service cible. Les
deux approches peuvent tirer parti des applications gourmandes en bande passante, car
la latence et le coût sont réduits.
Dans les deux cas, vous pouvez toujours vous assurer que le trafic dans le service cible
traverse un pare-feu réseau ou appliance virtuelle réseau. Cette procédure est différente
pour les deux approches. Lorsque vous utilisez des points de terminaison de service,
vous devez configurer le point de terminaison de service sur le sous-réseau du pare-feu,
plutôt que sur le sous-réseau où le service source est déployé. Lorsque vous utilisez des
points de terminaison privés, vous placez un itinéraire défini par l’utilisateur (UDR) pour
l’adresse IP du point de terminaison privé sur le sous-réseau source. Pas dans le sous-
réseau du point de terminaison privé.
Pour comparer les références SKU et comprendre leurs différences, consultez le tableau
ci-dessous.
Considération Points de terminaison de service Points de

terminaison
privés
Portée du service à Totalité du service (par exemple, tous les serveurs Instance
chaque niveau SQL ou les comptes de stockage de tous les individuelle (par
d’application de la clients) exemple, une
configuration instance de SQL
Server
spécifique ou
un compte de
stockage que
vous possédez)
terminaison
privés
Protection d’exfiltration Non Oui

de données intégrée :
possibilité de
déplacer/copier des
données à partir d’une
ressource PaaS protégée
vers une autre ressource
PaaS non protégée par
un Insider malveillant
Accès privé à la ressource Non Oui

PaaS localement
Configuration du groupe Oui (à l’aide d’étiquettes de service) No

de sécurité réseau
requise pour l’accès au
service
Le service peut être Non Oui

atteint sans utiliser
d’adresse IP publique
Le trafic Azure vers Azure Oui Oui

reste sur le réseau
principal Azure
Le service peut désactiver Non Oui

son adresse IP publique
Vous pouvez facilement Oui (autoriser l’accès à partir de sous-réseaux Oui

limiter le trafic provenant spécifiques et ou utiliser des groupes de sécurité
d’un réseau virtuel Azure réseau)
Vous pouvez facilement N/A** Oui

limiter le trafic de
provenance locale
(VPN/ExpressRoute).
Requiert des Non Oui (consultez

modifications DNS Configuration
DNS)
Influence le coût de votre Non Oui (consultez

solution Tarification de
Private Link )
terminaison
privés
Influence le contrat SLA Non Oui (le service

composite de votre de liaison privée
solution dispose d’un
contrat SLA de
99,99 % )
Installation et Une configuration simple et un temps de gestion Des efforts

maintenance réduit supplémentaires
sont
nécessaires.
Limites Aucune limite sur le nombre total de points de Oui (consultez

terminaison de service dans un réseau virtuel. Les Limites de
services Azure peuvent appliquer des limites sur le Private Link)
nombre de sous-réseaux utilisés pour sécuriser la
ressource. (consultez [FAQ sur le réseau virtuel]
(virtual-networks-faq.md#are-there-any-limits-on-
how-many-virtual network-service-endpoints-i-
can-set-up-from-my-virtual network))
**Les ressources du service Azure sécurisées pour des réseaux virtuels ne sont pas
accessibles à partir des réseaux locaux. Si vous souhaitez autoriser le trafic depuis un
réseau local, autorisez également les adresses IP publiques (généralement NAT) à partir
de vos circuits locaux ou ExpressRoute. Ces adresses IP peuvent être ajoutées via la
configuration du pare-feu IP des ressources du service Azure. Pour plus d’informations,
consultez la FAQ sur le réseau virtuel.
Étapes suivantes
Découvrez comment intégrer votre application à un réseau Azure.
Découvrez comment restreindre l’accès aux ressources à l’aide d’étiquettes de

service.
Découvrez comment vous connecter en privé à un compte Azure Cosmos DB à

l’aide d’Azure Private Link.
Déployer des services Azure dédiés dans
des réseaux virtuels
Article • 06/05/2023
privées.
Le déploiement de services au sein d’un réseau virtuel fournit les fonctionnalités

suivantes :
réseau virtuel.
ou ExpressRoute.
privées.
service.
Certains services imposent des restrictions sur le sous-réseau vers lequel ils sont
déployés. Cette restriction limite l’application de stratégies, d’itinéraires, ou la
peuvent changer au fil du temps. Les services Azure NetApp Files, Dedicated HSM,
Azure Container Instances, App Service en sont des exemples.

identificateur explicit qu’un sous-réseau peut héberger un service particulier. Grâce
à la délégation, les services reçoivent des autorisations explicites pour créer des
ressources propres au service dans le sous-réseau délégué.
disponibles).
Services pouvant être déployés dans un réseau virtuel
Category Service Sous-réseau1

dédié
Calcul Machines virtuelles : Linux ou Windows Non

Groupes de machines virtuelles identiques Non
Service cloud : Réseau virtuel (classique) uniquement Non
Azure Batch Non 2
Réseau Application Gateway - WAF Oui

Azure Bastion Oui
Pare-feu Azure Oui
Serveur de routes Azure Oui
Passerelle ExpressRoute Oui
Appliances virtuelles réseau Non
Passerelle VPN Oui
Category Service Sous-réseau1
dédié
Données RedisCache Oui

Azure SQL Managed Instance Oui
Azure Database pour MySQL - Serveur flexible Oui
Azure Database pour PostgreSQL - Serveur flexible Oui
Analytics Azure HDInsight Non 2

Azure Databricks Non 2
Identité Services de domaine Azure Active Directory Non
Containers Azure Kubernetes Service (AKS) Non 2

Azure Container Instances (ACI) Oui
Moteur Azure Container Service avec le plug-in CNI Non
Réseau virtuel Azure Oui
Azure Functions
Web Gestion des API Oui

Web Apps Oui
Environnement App Service Oui
Azure Logic Apps Oui
Environnements d’applications Azure Container Oui
Hébergée Module de sécurité matériel (HSM) dédié Azure Oui

Azure NetApp Files Oui
Azure Spring Apps Déployer dans un réseau virtuel Azure (injection de Oui
réseau virtuel)
Infrastructure de Azure Lab Services Oui

bureau virtuel
1
« Dédié » implique que seules des ressources propres au service peuvent être
déployées dans ce sous-réseau et ne peuvent pas être combinées avec des machines
virtuelles/groupes de machines virtuelles identiques (VMSS) des clients
2
Il est recommandé, au titre de bonne pratique, d’avoir ces services dans un sous-
réseau dédié, mais il ne s’agit pas d’une obligation imposée par le service.
Qu’est-ce que Liaison privée Azure ?
Azure Private Link vous permet d’accéder aux services Azure PaaS (par exemple
Stockage Azure et SQL Database) ainsi qu’aux services de partenaires ou de clients
hébergés par Azure sur un point de terminaison privé dans votre réseau virtuel.
Le trafic entre votre réseau virtuel et le service transite par le réseau principal de
Microsoft. L’exposition de votre service à l’Internet public n’est plus nécessaire. Vous
pouvez créer votre propre service de liaison privée dans votre réseau virtuel et le
distribuer à vos clients. La configuration et la consommation à l’aide d’Azure Private Link
est cohérente entre le service Azure PaaS, les services appartenant au client et les
services de partenaires partagés.
） Important
Azure Private Link est maintenant en disponibilité générale. Le point de terminaison

privé et le service Private Link (service derrière l’équilibreur de charge standard)
sont tous les deux en disponibilité générale. Différentes versions d’Azure PaaS
seront intégrées à Azure Private Link à différentes échéances. Consultez
Disponibilité de Private Link pour obtenir l’état précis d’Azure PaaS sur Private
Link. Pour en savoir plus sur les limitations connues, consultez Point de terminaison
privé et Service Liaison privée.
Principaux avantages
Le service Liaison privée Azure offre les avantages suivants :
Accès privé aux services sur la plateforme Azure : connectez votre réseau virtuel à
l’aide de points de terminaison privés à tous les services qui peuvent être utilisés
en tant que composants d’application dans Azure. Les fournisseurs de services
peuvent afficher leurs services dans leur propre réseau virtuel et les
consommateurs peuvent accéder à ces services dans leur réseau virtuel local. La
plateforme Liaison privée gère la connectivité entre le consommateur et les
services sur le réseau principal Azure.
Réseaux locaux et appairés : Accédez aux services s’exécutant dans Azure en local
par le biais du peering privé ExpressRoute, de tunnels VPN et de réseaux virtuels
appairés à l’aide de points de terminaison privés. Il n’est pas nécessaire de
configurer le peering ExpressRoute Microsoft ni de transiter par Internet pour
atteindre le service. Private Link offre un moyen sécurisé de migrer des charges de
travail vers Azure.
Protection contre la fuite de données : Un point de terminaison privé est mappé à

une instance d’une ressource PaaS plutôt qu’au service entier. Les consommateurs
peuvent se connecter uniquement à la ressource spécifique. L’accès à toute autre
ressource du service est bloqué. Ce mécanisme offre une protection contre les
risques de fuite de données.
Global Reach : Connectez-vous en privé à des services s’exécutant dans d’autres

régions. Le réseau virtuel du consommateur peut se trouver dans la région A et se
connecter aux services qui se trouvent derrière Private Link dans la région B.
Extension à vos propres services : Activez les mêmes expériences et

fonctionnalités pour afficher votre service en privé aux consommateurs dans Azure.
En plaçant votre service derrière une instance Azure Load Balancer standard, vous
pouvez l’activer pour Private Link. Le consommateur peut alors se connecter
directement à votre service à l’aide d’un point de terminaison privé dans son
propre réseau virtuel. Vous pouvez gérer les demandes de connexion à l’aide d’un
flux d’appels d’approbation. Azure Private Link fonctionne pour les consommateurs
et services appartenant à différents locataires Azure Active Directory.
７ Notes
Azure Private Link avec le réseau virtuel Azure s’étendent sur les zones de
disponibilité Azure et sont par conséquent résilients aux zones. Pour assurer une
haute disponibilité pour la ressource Azure à l’aide d’un point de terminaison privé,
vérifiez que la ressource est résiliente aux zones.
Disponibilité
Pour plus d’informations sur les services Azure qui prennent en charge Private Link,
consultez Disponibilité d’Azure Private Link.
Pour obtenir les notifications les plus récentes, consultez la page relative aux mises à
jour d’Azure Private Link .
Enregistrement et surveillance
Azure Private Link offre une intégration à Azure Monitor. Cette combinaison permet les
opérations suivantes :
Archive de journaux dans un compte de stockage.
Transmission en continu d’événements vers votre Event Hubs.
Journalisation d’Azure Monitor.
Vous pouvez accéder aux informations suivantes sur Azure Monitor :
Point de terminaison privé :

Données traitées par le point de terminaison privé (entrée/sortie)
Service Liaison privée :
Données traitées par le service Liaison privée (entrée/sortie)
Disponibilité du port NAT
Tarifs
Pour plus d’informations sur les tarifs, consultez Tarification Liaison privée Azure .
FAQ
Pour examiner les questions fréquentes, consultez FAQ sur Liaison privée Azure.
limites
Pour connaître les limites, consultez Limites de Liaison privée Azure.
Contrat de niveau de service

Pour connaître les détails du SLA, consultez SLA pour Azure Private Link .
Étapes suivantes
Démarrage rapide : Créer un point de terminaison privé au moyen du portail Azure
Démarrage rapide : Créer un service Private Link avec le portail Azure
Module Learn : Introduction à Azure Private Link

Points de terminaison de service de
réseau virtuel
Article • 20/04/2023
Le point de terminaison de service de réseau virtuel fournit une connexion sécurisée et

directe aux services Azure sur un itinéraire optimisé du réseau principal Azure. Les points
de terminaison permettent de sécuriser vos ressources critiques du service Azure pour
vos réseaux virtuels uniquement. Les points de terminaison de service permettent aux
adresses IP privées du réseau virtuel d'atteindre le point de terminaison d'un service
Azure sans qu'une adresse IP publique soit nécessaire sur le réseau virtuel.
７ Notes
Microsoft recommande l’utilisation d’Azure Private Link pour un accès sécurisé et

privé aux services hébergés sur la plateforme Azure. Pour plus d’informations,
consultez Azure Private Link.
Des points de terminaison de service sont disponibles pour les services et régions Azure
suivants. La ressource Microsoft.* est entre parenthèses. Activez cette ressource depuis le
côté du sous-réseau lors de la configuration des points de terminaison de service pour
votre service :
Mise à la disposition générale
Stockage Azure (Microsoft.Storage) : mis à la disposition générale dans toutes les

régions Azure.
Points de terminaison de service entre régions du Stockage Azure
(Microsoft.Storage.Global) : Généralement disponible dans toutes les régions Azure.
Azure SQL Database (Microsoft.Sql) : mis à la disposition générale dans toutes les
régions Azure.
Azure Synapse Analytics (Microsoft.Sql) : Mis à la disposition générale dans toutes
les régions Azure pour les pools SQL dédiés (anciennement SQL DW).
Serveur Azure Database pour PostgreSQL (Microsoft.Sql) : mis à la disposition
générale dans les régions Azure où le service de base de données est disponible.
Serveur Azure Database pour MySQL (Microsoft.Sql) : mis à la disposition générale
dans les régions Azure où le service de base de données est disponible.
Azure Database for MariaDB (Microsoft.Sql) : mis à la disposition générale dans les
régions Azure où le service de base de données est disponible.
Azure Cosmos DB (Microsoft.AzureCosmosDB) : mis à la disposition générale dans
toutes les régions Azure.
Azure Key Vault (Microsoft.KeyVault) : mis à la disposition générale dans toutes les
régions Azure.
Azure Service Bus (Microsoft.ServiceBus) : mis à la disposition générale dans toutes
les régions Azure.
Azure Event Hubs (Microsoft.EventHub) : mis à la disposition générale dans toutes
les régions Azure.
Azure Data Lake Store Gen 1 (Microsoft.AzureActiveDirectory) : Disponibilité
générale dans toutes les régions Azure où ADLS Gen1 est disponible.
Azure App Service (Microsoft.Web) : En disponibilité générale dans toutes les
régions Azure où App Service est disponible.
Azure Cognitive Services (Microsoft.CognitiveServices) : En disponibilité générale
dans toutes les régions Azure où Cognitive Services est disponible.
Préversion publique
Azure Container Registry (Microsoft.ContainerRegistry) : préversion disponible dans

certaines régions Azure où Azure Container Registry est disponible.
Pour obtenir les notifications les plus récentes, vérifiez la page Mises à jour du réseau
virtuel Microsoft Azure .
Les points de terminaison de service fournissent les avantages suivants :
Sécurité améliorée de vos ressources de service Azure : Les espaces d’adressage

privé de réseau virtuel peuvent se chevaucher. Vous ne pouvez pas utiliser
d’espaces qui se chevauchent pour identifier de manière unique le trafic provenant
de votre réseau virtuel. Les points de terminaison de service permettent de
sécuriser les ressources de service Azure sur votre réseau virtuel en étendant
l’identité du réseau virtuel au service. Une fois que vous avez activé les points de
terminaison de service dans votre réseau virtuel, vous pouvez ajouter une règle de
réseau virtuel afin de sécuriser les ressources du service Azure pour votre réseau
virtuel. L’ajout de règles améliore la sécurité en supprimant totalement l’accès
Internet public aux ressources et en autorisant le trafic uniquement à partir de
Routage optimal pour le trafic de service Azure à partir de votre réseau virtuel :
Aujourd’hui, tous les itinéraires dans votre réseau virtuel qui forcent le trafic
Internet vers vos appliances locales et/ou virtuelles forcent également le trafic de
service Azure à prendre le même itinéraire que le trafic Internet. Les points de
terminaison de service fournissent un routage optimal pour le trafic Azure.
Les points de terminaison acheminent toujours le trafic de service directement à

partir de votre réseau virtuel vers le service sur le réseau principal de Microsoft
Azure. La conservation du trafic sur le réseau principal d’Azure vous permet de
continuer l’audit et la surveillance du trafic Internet sortant à partir de vos réseaux
virtuels, via le tunneling forcé, sans affecter le trafic de service. Pour plus
d’informations sur les itinéraires définis par l’utilisateur et le tunneling forcé,
consultez Routage du trafic de réseau virtuel Azure.
Une configuration simple et un temps de gestion réduit : les adresses IP

publiques réservées dans vos réseaux virtuels ne sont désormais plus nécessaires
pour sécuriser les ressources Azure via le pare-feu IP. Aucune traduction d’adresses
réseau (NAT) ni aucun appareil de passerelle n’est requis pour configurer les points
de terminaison de service. Vous pouvez configurer des points de terminaison de
service par une simple sélection d’un sous-réseau. La gestion des points de
terminaison n’entraîne pas de surcharge supplémentaire.
Limites
La fonctionnalité est disponible uniquement pour les réseaux virtuels déployés à
l’aide du modèle de déploiement Azure Resource Manager.
Les points de terminaison sont activés sur les sous-réseaux configurés dans les
réseaux virtuels Azure. Les points de terminaison ne peuvent pas servir pour le
trafic à partir de votre réseau local vers les services Azure. Pour plus d’informations,
consultez Sécuriser l’accès au service en local
Pour Azure SQL, un point de terminaison de service concerne uniquement le trafic
de service Azure dans la région d’un réseau virtuel.
Avec Azure Data Lake Storage (ADLS) Gen 1, la fonctionnalité d’intégration au
réseau virtuel est uniquement disponible pour les réseaux virtuels situés dans une
même région. Notez également que l’intégration au réseau virtuel dans ADLS
Gen1 utilise la sécurité des points de terminaison de service de réseau virtuel entre
votre réseau virtuel et Azure Active Directory (Azure AD) afin de générer d’autres
revendications de sécurité dans le jeton d’accès. Ces revendications permettent
ensuite d’authentifier votre réseau virtuel à votre compte Data Lake Storage Gen1
et d’y accéder. La balise Microsoft.AzureActiveDirectory répertoriée sous les services
prenant en charge les points de terminaison de service est uniquement utilisée
pour gérer ces derniers dans ADLS Gen 1. Azure AD ne prend pas en charge les
points de terminaison de service en mode natif. Pour plus d’informations sur
l’intégration au réseau virtuel d’Azure Data Lake Storage Gen1, consultez Sécurité
du réseau dans Azure Data Lake Storage Gen1.
Sécuriser les services Azure pour des réseaux

virtuels
Un point de terminaison de service de réseau virtuel fournit l’identité de votre
réseau virtuel au service Azure. Une fois que vous avez activé les points de
terminaison de service dans votre réseau virtuel, vous pouvez ajouter une règle de
réseau virtuel afin de sécuriser les ressources du service Azure pour votre réseau
virtuel.
Aujourd’hui, le trafic du service Azure à partir d’un réseau virtuel utilise des
adresses IP publiques en tant qu’adresses IP source. Avec les points de terminaison
de service, le trafic de service change pour utiliser des adresses privées de réseau
virtuel en tant qu’adresses IP source lors de l’accès au service Azure à partir d’un
réseau virtuel. Ce changement permet d’accéder aux services sans avoir besoin
d’adresses IP publiques réservées et utilisées dans les pare-feux IP.
７ Notes
Avec les points de terminaison de service, les adresses IP sources des

machines virtuelles dans le sous-réseau pour le trafic de service passe d’une
utilisation des adresses IPv4 publiques à une utilisation des adresses IPv4
privées. Les règles de pare-feu de service Azure existantes utilisant des
adresses IP publiques Azure cesseront de fonctionner avec ce changement.
Vérifiez que les règles de pare-feu de service Azure autorisent ce changement
avant de définir des points de terminaison de service. Vous pouvez également
rencontrer une interruption temporaire du trafic de service à partir de ce
sous-réseau lors de la configuration des points de terminaison de service.
Sécuriser l’accès au service Azure en local

Par défaut, les ressources du service Azure sécurisées pour des réseaux virtuels ne sont
pas accessibles à partir des réseaux locaux. Si vous souhaitez autoriser le trafic depuis un
réseau local, vous devez également autoriser les adresses IP publiques (généralement
NAT) à partir de vos circuits locaux ou ExpressRoute. Vous pouvez ajouter ces adresses
IP via la configuration du pare-feu IP des ressources du service Azure.
ExpressRoute : Si vous utilisez ExpressRoute pour le Peering public ou Microsoft en local,
vous devez identifier les adresses IP NAT utilisées. Pour le Peering public, chaque circuit
ExpressRoute utilise par défaut deux adresses IP NAT qui sont appliquées au trafic du
service Azure lorsque le trafic entre dans le réseau principal de Microsoft Azure. Pour le
Peering Microsoft, les adresses IP NAT sont fournies par le client ou par le fournisseur du
service. Pour autoriser l’accès à vos ressources de votre service, vous devez autoriser ces
adresses IP publiques dans le paramètre de pare-feu IP de ressource. Pour trouver les
adresses IP de votre circuit ExpressRoute de peering public, ouvrez un ticket de support
avec ExpressRoute via le portail Azure. Pour plus d’informations sur le Peering
Microsoft et public NAT pour ExpressRoute, consultez Configuration NAT requise pour
ExpressRoute.
Configuration
Configurez les points de terminaison de service sur un sous-réseau dans un réseau
virtuel. Les points de terminaison fonctionnent avec n’importe quel type
d’instances de calcul en cours d’exécution dans ce sous-réseau.
Vous pouvez configurer plusieurs points de terminaison de service pour tous les
services Azure pris en charge (par exemple, Stockage Azure ou Azure SQL
Database) sur un sous-réseau.
Pour Azure SQL Database, les réseaux virtuels doivent être dans la même région
que la ressource de service Azure. Pour tous les autres services, vous pouvez
sécuriser les ressources du service Azure pour les réseaux virtuels de n’importe
quelle région.
Le réseau virtuel dans lequel est configuré le point de terminaison peut être dans
le même abonnement ou dans un abonnement différent de celui de la ressource
du service Azure. Pour plus d’informations sur les autorisations requises pour la
configuration de points de terminaison et la sécurisation des services Azure,
consultez Approvisionnement.
Pour les services pris en charge, vous pouvez sécuriser des ressources nouvelles ou
existantes pour des réseaux virtuels à l’aide de points de terminaison de service.
Considérations
Après l’activation d’un point de terminaison de service, les adresses IP sources
basculent de l’utilisation des adresses IPv4 publiques à l’utilisation de leur adresse
IPv4 privée lors de la communication avec le service à partir de ce sous-réseau.
Toute connexion TCP ouverte existante pour le service sera fermée lors de ce
changement. Assurez-vous qu’aucune tâche critique n’est en cours d’exécution lors
de l’activation ou de la désactivation d’un point de terminaison de service à un
service pour un sous-réseau. En outre, assurez-vous que vos applications peuvent
se connecter automatiquement aux services Azure après le changement d’adresse
IP.
Le changement d’adresse IP affecte uniquement le trafic de service à partir de

votre réseau virtuel. L’impact sur tout autre trafic adressé vers ou depuis des
adresses IPv4 publiques attribuées à vos machines virtuelles est inexistant. Si vous
possédez des règles de pare-feu existantes à l’aide d’adresses IP publiques Azure
pour les services Azure, ces règles cessent de fonctionner avec le changement pour
les adresses privées de réseau virtuel.
Avec les points de terminaison de service, les entrées DNS pour les services Azure
ne sont pas modifiées et continuent de résoudre les adresses IP publiques
assignées au service Azure.
Groupes de sécurité réseau (NSG) avec points de terminaison de service :

Par défaut, les groupes de sécurité réseau autorisent le trafic Internet sortant,
ainsi que le trafic de votre réseau virtuel vers les services Azure. Ce trafic
continue de fonctionner avec les points de terminaison de service tels quels.
Si vous souhaitez refuser tout trafic Internet sortant et autoriser le trafic
uniquement vers des services Azure spécifiques, vous pouvez le faire à l’aide de
balises de service dans vos groupes de sécurité réseau. Vous pouvez spécifier
les services Azure pris en charge en tant que destination dans vos règles de
groupe de sécurité réseau, et Azure fournit également la maintenance des
adresses IP sous-tendant chaque balise. Pour plus d’informations, voir Balises de
Service Azure pour les groupes de sécurité réseau.
Scénarios
Réseaux virtuels appariés, connectés ou multiples : afin de sécuriser les services
Azure pour plusieurs sous-réseaux au sein d’un réseau virtuel ou sur plusieurs
réseaux virtuels, vous pouvez activer les points de terminaison de service sur
chacun des sous-réseaux indépendamment et sécuriser les ressources de service
Azure pour l’ensemble des sous-réseaux.
Filtrage du trafic sortant vers les services Azure à partir du réseau virtuel : Si
vous souhaitez inspecter ou filtrer le trafic envoyé à un service Azure à partir d’un
réseau virtuel, vous pouvez déployer une appliance virtuelle réseau au sein du
réseau virtuel. Vous pouvez ensuite appliquer des points de terminaison de service
au sous-réseau sur lequel est déployée l’appliance virtuelle réseau et sécuriser les
ressources de service Azure uniquement pour ce sous-réseau. Ce scénario peut
être utile si vous souhaitez utiliser le filtrage de l’appliance virtuelle réseau pour
restreindre l’accès aux services Azure à partir de votre réseau virtuel uniquement
pour des ressources Azure spécifiques. Pour plus d’informations, consultez la
section relative à la sortie avec les appliances virtuelles réseau.
Sécurisation des ressources Azure pour les services déployés directement dans
les réseaux virtuels : Vous pouvez déployer directement divers services Azure dans
des sous-réseaux spécifiques au sein d’un réseau virtuel. Vous pouvez sécuriser les
ressources du service Azure pour les sous-réseaux du service administré en
configurant un point de terminaison de service sur le sous-réseau de service
administré.
Trafic de disques à partir d’une machine virtuelle Azure : Le trafic des disques de
machine virtuelle pour les disques managés et non managés n’est pas perturbé par
la modification du routage des points de terminaison de service pour Stockage
Azure. Ce trafic comprend l’E/S disque ainsi que le montage et le démontage. Vous
pouvez limiter l’accès REST aux objets blob de page pour sélectionner les réseaux
via des points de terminaison de service et les règles de réseau de Stockage Azure.
Journalisation et résolution des problèmes

Une fois que vous avez configuré les points de terminaison de service pour un service
spécifique, vérifiez que l’itinéraire de point de terminaison de service est activé en
Validation de l’adresse IP source de toute demande de service dans les diagnostics

du service. Toutes les nouvelles demandes avec les points de terminaison de
service affichent l’adresse IP source de la demande en tant qu’adresse IP privée du
réseau virtuel, attribuée au client qui effectue la demande à partir de votre réseau
virtuel. Sans le point de terminaison, cette adresse est une adresse IP publique
Azure.
Affichage des itinéraires effectifs sur n’importe quelle interface réseau d’un sous-
réseau. L’itinéraire jusqu’au service :
affiche un itinéraire par défaut plus spécifique jusqu’aux plages de préfixes
d’adresses de chaque service ;
possède un type de tronçon VirtualNetworkServiceEndpoint ;
indique qu’une connexion plus directe pour le service est appliquée, par rapport
à n’importe quel tunneling forcé.
７ Notes
Les itinéraires de point de terminaison de service remplacent tout itinéraire BGP ou

UDR pour la correspondance de préfixe d’adresse d’un service Azure. Pour plus
d’informations, consultez Résolution des problèmes à l’aide d’itinéraires effectifs.
Approvisionnement
Les points de terminaison de service peuvent être configurés indépendamment sur les
réseaux virtuels par un utilisateur avec accès en écriture à un réseau virtuel. Pour
sécuriser les ressources du service Azure pour un réseau virtuel, l’utilisateur doit
disposer des autorisations sur
Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action pour les sous-
réseaux ajoutés. Les rôles Administrateur de service fédérés intégrés incluent cette
autorisation par défaut. Vous pouvez modifier l’autorisation en créant des rôles
personnalisés.
Pour plus d’informations sur les rôles intégrés, consultez Rôles intégrés Azure. Pour plus
d’informations sur l’attribution d’autorisations spécifiques à des rôles personnalisés,
consultez Rôles Azure personnalisés.
Les réseaux virtuels et les ressources du service Azure peuvent être dans des
abonnements identiques ou différents. Certains services Azure (pas tous), comme
Stockage Azure et Azure Key Vault, prennent également en charge les points de
terminaison de service sur plusieurs locataires Active Directory (AD). Cela signifie que le
réseau virtuel et la ressource de service Azure peuvent se trouver dans des locataires
Active Directory (AD) différents. Pour plus d’informations, consultez la documentation
des services individuels.
Tarification et limites
L’utilisation de points de terminaison de service n’engendre pas de frais
supplémentaires. Le modèle tarifaire actuel pour les services Azure (Stockage Azure,
Azure SQL Database, etc.) reste le même.
Il n’existe aucune limite sur le nombre total de points de terminaison de service dans un
réseau virtuel.
Certains services Azure, comme Comptes Stockage Azure, peuvent appliquer des limites
sur le nombre de sous-réseaux utilisés pour sécuriser la ressource. Pour en savoir plus,
reportez-vous à la documentation pour les différents services dans la section Étapes
suivantes.
Stratégies de points de terminaison de service

de réseau virtuel
Les stratégies de point de terminaison de service de réseau virtuel vous permettent de
filtrer le trafic de réseau virtuel vers les services Azure. Ce filtre autorise uniquement des
ressources de service Azure spécifiques sur les points de terminaison de service. Les
stratégies de points de terminaison de service fournissent un contrôle d’accès granulaire
pour le trafic de réseau virtuel vers les services Azure. Pour plus d’informations,
consultez Stratégies de points de terminaison de service de réseau virtuel.
FAQ
Pour consulter les Forums aux questions, consultez les FAQ sur les points de terminaison
de service de réseau virtuel.
Étapes suivantes
Configurer des points de terminaison de service de réseau virtuel
Sécuriser un compte de stockage Azure pour un réseau virtuel
Sécuriser une base de données Azure SQL Database pour un réseau virtuel
Sécuriser une instance Azure Synapse Analytics dans un réseau virtuel
Comparer des points de terminaison privés et des points de terminaison de service
Stratégies de points de terminaison de service de réseau virtuel
Modèle Azure Resource Manager
Balises de service du réseau virtuel
donné. Microsoft gère les préfixes d’adresses englobés par l’étiquette de service et met à jour
automatiquement l’étiquette de service quand les adresses changent, ce qui réduit la
complexité des mises à jour fréquentes relatives aux règles de sécurité réseau.
Vous pouvez utiliser des balises de service pour définir des contrôles d'accès au réseau sur les
groupes de sécurité du réseau, Pare-feu Azure et les routes définies par l'utilisateur. Utilisez
des balises de service à la place d'adresses IP spécifiques lorsque vous créez des règles de
sécurité et des routes. En spécifiant le nom de l’étiquette de service (par exemple,
ApiManagement dans le champ Source ou Destination d’une règle, vous pouvez autoriser ou
refuser le trafic pour le service correspondant. En spécifiant le nom de la balise de service
dans le préfixe d’adresse d’une route, vous pouvez acheminer le trafic destiné à l’un des
préfixes encapsulés par la balise de service vers un type de tronçon suivant souhaité.
７ Notes
À compter de mars 2022, l’utilisation de balises de service à la place de préfixes

d’adresses explicites dans les itinéraires définis par l’utilisateur est hors préversion et
généralement disponible.
Vous pouvez utiliser des étiquettes de service pour isoler le réseau et protéger vos ressources
Azure de l’accès Internet général tout en accédant aux services Azure qui ont des points de
terminaison publics. Créez des règles de groupe de sécurité de réseau entrant/sortant pour
refuser le trafic vers/depuis Internet et autoriser le trafic vers/depuis AzureCloud ou d’autres
balises de service disponibles de services Azure spécifiques.
Balises de service disponibles
Le tableau suivant répertorie les balises de service disponibles à utiliser dans les règles
Groupes de sécurité réseau.
Les colonnes indiquent si la balise :
Est adaptée aux règles couvrant le trafic entrant ou sortant.

Prend en charge l’étendue régionale .
Est utilisable dans les règles dePare-feu Azure en tant que règle de destination
uniquement pour le trafic entrant ou sortant.
Par défaut, les balises de service reflètent les plages pour l’ensemble du Cloud. Certaines
balises de service permettent également d’obtenir un contrôle plus précis en limitant les
plages d’adresses IP correspondantes à une région spécifiée. Par exemple, la balise de service
Storage représente le Stockage Azure pour l’ensemble du cloud, alors que Storage.WestUS
limite la sélection aux plages d’adresses IP de stockage de la région WestUS. Le tableau
suivant indique si chaque étiquette de service prend en charge une telle étendue régionale, et
la direction indiquée pour chaque balise est une recommandation. Par exemple, l’étiquette
AzureCloud peut être utilisée pour autoriser le trafic entrant. Dans la plupart des scénarios,
nous vous déconseillons d’autoriser le trafic à partir de toutes les adresses IP Azure, car les
adresses IP utilisées par d’autres clients Azure sont incluses dans le cadre de la balise de
service.
Tag Objectif Peut-elle Peut-elle Peut-
utiliser être elle
le trafic étendue à être
entrant une zone utilisée
ou régionale ? avec le
sortant ? Pare-
feu
Azure
?
ActionGroup Groupe d’actions. Trafic Non Oui

entrant
ApiManagement Trafic de gestion pour les Trafic Oui Oui

déploiements dédiés de Gestion entrant
des API.
Remarque : cette étiquette

représente le point de
terminaison du service Gestion
des API Azure pour le plan de
contrôle par région. La balise
permet aux clients d’effectuer
des opérations de gestion sur
les API, les opérations, les
stratégies et les valeurs
nommées configurées sur le
service Gestion des API.
ApplicationInsightsAvailability Disponibilité d’Application Trafic Non Oui

Insights. entrant
AppConfiguration App Configuration. Règle de Non Oui

trafic
sortant
AppService Azure App Service Cette balise Règle de Oui Oui

est recommandée pour les trafic
règles de sécurité sortantes vers sortant
les applications web et les
applications de fonction.
Remarque : Cette balise n’inclut

pas les adresses IP attribuées
quand le protocole SSL basé
sur IP (adresse attribuée par
l’application) est utilisé.
AppServiceManagement Trafic de gestion pour les Les deux Non Oui

déploiements dédiés vers App
Service Environment.
AutonomousDevelopmentPlatform Plateforme de développement Les deux Oui Oui
autonome
AzureActiveDirectory Azure Active Directory Règle de Non Oui

trafic
sortant
AzureActiveDirectoryDomainServices Trafic de gestion pour les Les deux Non Oui

déploiements dédiés vers Azure
Active Directory Domain
Services.
AzureAdvancedThreatProtection Azure Advanced Threat Règle de Non Oui

Protection. trafic
sortant
AzureArcInfrastructure Serveurs Azure Arc, Kubernetes Règle de Non Oui

avec Azure Arc et trafic Guest trafic
Configuration. sortant
Remarque : cette étiquette a

une dépendance vis-à-vis des
étiquettes
AzureActiveDirectory,
AzureTrafficManager et
AzureResourceManager.
AzureAttestation Azure Attestation. Règle de Non Oui

trafic
sortant
AzureBackup Sauvegarde Azure. Règle de Non Oui

trafic
Remarque : cette étiquette est sortant
dotée d’une dépendance par
rapport aux étiquettes Storage
et AzureActiveDirectory.
AzureBotService Service Azure Bot. Règle de Non Oui

trafic
sortant
AzureCloud Toutes les adresses IP publiques Les deux Oui Oui
du centre de données .
AzureCognitiveSearch Recherche cognitive Azure. Trafic Non Oui

entrant
Cette balise ou les adresses IP
qu’elle couvre permettent
d’accorder aux indexeurs un
accès sécurisé à des sources de
données. Pour plus
d’informations sur les indexeurs,
consultez la documentation de
connexion de l’indexeur.
Remarque : L’adresse IP du
service de recherche n’est pas
incluse dans la liste des plages
d’adresses IP pour cette
étiquette de service et doit
également être ajoutée au
pare-feu IP des sources de
données.
AzureConnectors Cette étiquette représente les Les deux Oui Oui

adresses IP utilisées pour les
connecteurs managés qui
effectuent des rappels de
webhook entrants vers le
service Azure Logic Apps et des
appels sortants vers leurs
services respectifs, par exemple,
Stockage Azure ou Azure Event
Hubs.
AzureContainerAppsService Service Azure Container Apps Les deux Oui Non
AzureContainerRegistry Azure Container Registry. Règle de Oui Oui

trafic
sortant
AzureCosmosDB Azure Cosmos DB. Règle de Oui Oui

trafic
sortant
AzureDatabricks Azure Databricks. Les deux Non Oui
AzureDataExplorerManagement Gestion d’Azure Data Explorer. Trafic Non Oui

entrant
AzureDataLake Azure Data Lake Storage Gen1. Règle de Non Oui

trafic
sortant
AzureDeviceUpdate Device Update pour IoT Hub. Les deux Non Oui
AzureDevSpaces Azure Dev Spaces. Règle de Non Oui

trafic
sortant
AzureDevOps Azure DevOps. Trafic Oui Oui

entrant
AzureDigitalTwins Azure Digital Twins. Trafic Non Oui

entrant
Remarque : Cette étiquette et
les adresses IP qu’elle couvre
peuvent être utilisées pour
restreindre l’accès aux points de
terminaison configurés pour des
routes d’événements.
AzureEventGrid Azure Event Grid. Les deux Non Oui
AzureFrontDoor.Frontend Azure Front Door. Les deux Oui Oui

AzureFrontDoor.Backend
AzureFrontDoor.FirstParty
AzureHealthcareAPIs Les adresses IP couvertes par Les deux Non Oui

cette étiquette peuvent être
utilisées pour restreindre l’accès
à Azure Health Data Services.
AzureInformationProtection Azure Information Protection. Règle de Non Oui
trafic
rapport aux étiquettes
AzureFrontDoor.Frontend et
AzureFrontDoor.FirstParty.
AzureIoTHub Azure IoT Hub. Règle de Oui Oui

trafic
sortant
AzureKeyVault Azure Key Vault. Règle de Oui Oui

trafic
rapport à l’étiquette
AzureActiveDirectory.
AzureLoadBalancer Équilibrage de charge de Les deux Non Non

l’infrastructure Azure. Elle est
translatée vers l’adresse IP
virtuelle de l’hôte
(168.63.129.16) d’où
proviennent les sondes
d’intégrité d’Azure. Cela
comprend uniquement le trafic
de sondes, et non le trafic réel
vers votre ressource principale.
Vous pouvez remplacer cette
règle si vous n’utilisez pas
l’équilibreur de charge Azure.
AzureLoadTestingInstanceManagement Cette étiquette de service est Trafic Non Oui
utilisée pour la connectivité entrant
entrante du service Test de
charge Azure vers les instances
de génération de charge
injectées dans votre réseau
virtuel dans le scénario de test
de charge privé.
Remarque : Cette étiquette est

destinée à être utilisée dans le
Pare-feu Azure, les groupes de
sécurité réseau, les itinéraires
définis par l’utilisateur et toutes
les autres passerelles pour la
connectivité entrante.
AzureMachineLearning Azure Machine Learning. Les deux Non Oui
AzureMonitor Métriques Log Analytics, Règle de Non Oui

Application Insights, AzMon et trafic
métriques personnalisées sortant
(points de terminaison GiG).
Remarque : pour Log Analytics,

l’étiquette Storage est
également nécessaire. Si des
agents Linux sont utilisés,
l’étiquette
GuestAndHybridManagement
est également nécessaire.
AzureOpenDatasets Azure Open Datasets. Règle de Non Oui

trafic
Storage.
AzurePlatformDNS Service DNS de l’infrastructure Règle de Non Non
de base (par défaut). trafic
sortant
Vous pouvez utiliser cette balise
pour désactiver le DNS par
défaut. Utilisez cette balise avec
prudence. Nous vous
recommandons de lire les
considérations sur la plateforme
Azure. Nous vous
recommandons également
d’effectuer des tests avant
d’utiliser cette balise.
AzurePlatformIMDS Azure Instance Metadata Règle de Non Non

Service (IMDS), qui est un trafic
service d’infrastructure de base. sortant

pour désactiver le point de
terminaison IMDS par défaut.
Utilisez cette balise avec
prudence. Nous vous
Azure. Nous vous
AzurePlatformLKM Gestionnaire de licences Règle de Non Non
Windows ou service de gestion trafic
de clés. sortant

pour désactiver les paramètres
par défaut des licences. Utilisez
cette balise avec prudence.
Nous vous recommandons de
lire les considérations sur la
plateforme Azure. Nous vous
AzureResourceManager Azure Resource Manager. Règle de Non Oui

trafic
sortant
AzureSentinel Microsoft Sentinel. Trafic Oui Oui

entrant
AzureSignalR Azure SignalR. Règle de Non Oui

trafic
sortant
AzureSiteRecovery Azure Site Recovery. Règle de Non Oui

trafic
AzureKeyVault, EventHub,
et Storage.
AzureSphere Cette étiquette et les adresses Les deux Non Oui

IP qu’elle couvre peuvent être
aux services de sécurité Azure
Sphere.
AzureSpringCloud Autoriser le trafic vers les Règle de Non Oui
applications hébergées dans trafic
Azure Spring Apps. sortant
AzureStack Services Azure Stack Bridge. Règle de Non Oui

Cette étiquette représente le trafic
point de terminaison de service sortant
Azure Stack Bridge par région.
AzureTrafficManager Adresses IP de sonde Azure Trafic Non Oui

Traffic Manager. entrant
Pour plus d’informations sur les

adresses IP de sondage Traffic
Manager, consultez les
Questions fréquentes (FAQ) sur
Azure Traffic Manager.
AzureUpdateDelivery Pour accéder aux mises à jour Règle de Non Oui

de Windows. trafic
sortant
permet d’accéder aux services
de métadonnées Windows
Update. Pour télécharger les
mises à jour avec succès, vous
devez également activer la
balise de service
AzureFrontDoor.FirstParty et
configurer les règles de sécurité
de trafic sortant avec le
protocole et le port définis,
comme suit :
AzureUpdateDelivery:
TCP, port 443
AzureFrontDoor.FirstParty:
TCP, port 80
AzureWebPubSub AzureWebPubSub Les deux Oui Oui

BatchNodeManagement Trafic de gestion pour les Les deux Oui Oui
déploiements dédiés d’Azure
Batch.
ChaosStudio Azure Chaos Studio. Les deux Oui Oui
Remarque : Si vous avez activé

l’intégration d’Application
Insights sur Chaos Agent, la
balise AzureMonitor est
également requise.
CognitiveServicesFrontend Les plages d’adresses pour le Les deux Non Oui

trafic destiné aux portails du
front-end Cognitive Services.
CognitiveServicesManagement Plages d’adresses du trafic pour Les deux Non Oui

Azure Cognitive Services.
DataFactory Azure Data Factory Les deux Non Oui
DataFactoryManagement Trafic de gestion pour Azure Règle de Non Oui

Data Factory. trafic
sortant
Dynamics365ForMarketingEmail Plages d’adresses pour le Les deux Oui Oui

service de messagerie
marketing de Dynamics 365.
Dynamics365BusinessCentral Cette étiquette et les adresses Les deux Non Oui

de/à Dynamics 365 Business
Central Services.
EOPExternalPublishedIPs Cette étiquette représente les Les deux Non Oui
adresses IP utilisées pour le
Centre de sécurité et de
conformité PowerShell. Pour
plus d’informations, consultez
Se connecter au Centre de
sécurité et de conformité
PowerShell à l’aide du module
EXO V2.
EventHub Azure Event Hubs. Règle de Oui Oui

trafic
sortant
GatewayManager Trafic de gestion pour les Trafic Non Non

déploiements dédiés à la entrant
passerelle VPN Azure et
Application Gateway.
GuestAndHybridManagement Azure Automation et Guest Règle de Non Oui

Configuration. trafic
sortant
HDInsight Azure HDInsight Trafic Oui Oui

entrant
Internet Espace d’adresse IP qui se Les deux Non Non

trouve en dehors du réseau
virtuel et est accessible sur les
réseaux Internet publics.
La plage d’adresse inclut

l’espace de l’adresse IP public
d’Azure .
LogicApps Logic Apps. Les deux Non Oui
LogicAppsManagement Trafic de gestion pour Logic Trafic Non Oui

Apps. entrant
Place de marché Représente la suite complète Les deux Non Oui
des services « Expériences de la
Place de marché commerciale »
Azure.
M365ManagementActivityApi L’API Activité de gestion Règle de Oui Oui

Office 365 fournit des trafic
informations sur différentes sortant
actions et événements
d’utilisateurs, d’administrateurs,
de système et de stratégies à
partir des journaux d’activités
Office 365 et Azure Active
Directory. Les clients et
partenaires peuvent utiliser ces
informations pour créer ou
améliorer des solutions de
monitoring de la conformité,
d’opérations et de sécurité
existantes.
Remarque : cette étiquette est

M365ManagementActivityApiWebhook Des notifications sont envoyées Trafic Oui Oui

au webhook configuré pour un entrant
abonnement lors de la mise à
disposition de nouveau
contenu.
MicrosoftAzureFluidRelay Cette étiquette représente les Règle de Non Oui

adresses IP utilisées pour Azure trafic
Microsoft Fluid Relay Server. sortant
MicrosoftCloudAppSecurity Applications Microsoft Defender Règle de Non Oui

pour le cloud. trafic
sortant
MicrosoftContainerRegistry Registre de conteneurs pour les Règle de Oui Oui
images de conteneur Microsoft. trafic
sortant
MicrosoftDefenderForEndpoint Microsoft Defender for Les deux Non Oui

Endpoint
Notez que cette étiquette de

service n’est actuellement pas
disponible et en cours de
développement. Nous
procéderons à la mise à jour
une fois qu’elle sera prête à
être utilisée.
PowerBI Power BI. Les deux Non Oui
PowerPlatformInfra Cette étiquette représente les Règle de Oui Oui

adresses IP utilisées par trafic
l’infrastructure pour héberger sortant
les services Power Platform.
PowerPlatformPlex Cette étiquette représente les Trafic Oui Oui

adresses IP utilisées par entrant
l’infrastructure pour héberger
l’exécution de l’extension Power
Platform pour le compte du
client.
PowerQueryOnline Power Query en ligne. Les deux Non Oui
ServiceBus Trafic Azure Service Bus qui Règle de Oui Oui

utilise le niveau de service trafic
Premium. sortant
ServiceFabric Azure Service Fabric. Les deux Non Oui

terminaison du service Service
Fabric pour le plan de contrôle
par région. Ceci permet aux
clients d’effectuer des
opérations de gestion pour
leurs clusters Service Fabric à
partir de leur réseau virtuel. (Par
exemple https://
westus.servicefabric.azure.com).
Sql Azure SQL Database, Azure Règle de Oui Oui

Database pour MySQL, Azure trafic
Database pour PostgreSQL, sortant
Azure Database for MariaDB et
Azure Synapse Analytics.

représente le service, mais pas
des instances spécifiques du
service. Par exemple, la balise
représente le service Azure SQL
Database, mais pas une base de
données ou un serveur SQL
spécifique. Cette balise ne
s’applique pas à l’Instance gérée
SQL.
SqlManagement Trafic de gestion pour les Les deux Non Oui

déploiements dédiés de SQL.
Stockage Stockage Azure. Règle de Oui Oui
trafic
Remarque : cette étiquette sortant
représente le service Azure
Storage, mais pas un compte
Azure Storage spécifique.
StorageSyncService Service de synchronisation du Les deux Non Oui

stockage.
WindowsAdminCenter Autoriser le service principal du Règle de Non Oui

Centre d’administration trafic
Windows à communiquer avec sortant
l’installation des clients du
Centre d’administration
Windows.
WindowsVirtualDesktop Azure Virtual Desktop Les deux Non Oui

(anciennement Microsoft Virtual
Desktop).
VirtualNetwork L’espace d’adressage du réseau Les deux Non Non

virtuel (toutes les plages
d’adresses IP définies pour le
réseau virtuel), tous les espaces
d’adressage locaux connectés,
les réseaux virtuels appairés ou
connectés à une passerelle de
réseau virtuel, l’adresse IP
virtuelle de l’hôte et les préfixes
d’adresse utilisés sur les routes
définies par l’utilisateur. Cette
balise peut également contenir
des itinéraires par défaut.
７ Notes
Lorsque vous utilisez des balises de service avec le Pare-feu Azure, vous pouvez
uniquement créer des règles de destination sur le trafic entrant et sortant. Les
règles sources ne sont pas prises en charge. Pour plus d’informations, consultez la
documentation Balises de service du Pare-feu Azure .
Les balises des services Azure indiquent les préfixes d’adresse du cloud spécifique
utilisé. Par exemple, les plages IP sous-jacentes qui correspondent à la valeur de
balise Sql sur le cloud public Azure seront différentes des plages sous-jacentes sur
le cloud Azure Chine.
Si vous implémentez un point de terminaison de service de réseau virtuel pour un

service, par exemple Stockage Azure ou Azure SQL Database, Azure ajoute un
itinéraire vers un sous-réseau de réseau virtuel pour le service. Les préfixes
d’adresse de l’itinéraire sont les mêmes préfixes d’adresse ou plages CIDR que pour
la balise de service correspondante.
Étiquettes prises en charge dans le modèle de déploiement

classique
Le modèle de déploiement classique (antérieur à Azure Resource Manager) prend en charge
un petit sous-ensemble des étiquettes répertoriées dans le tableau précédent. Les étiquettes
dans le modèle de déploiement classique sont orthographiées différemment, comme indiqué
dans le tableau suivant :
Étiquette Resource Manager Étiquette correspondante dans le modèle de déploiement classique
AzureLoadBalancer AZURE_LOADBALANCER
Internet INTERNET
VirtualNetwork VIRTUAL_NETWORK
Balises de service locales

Vous pouvez obtenir la balise de service et les informations de plage actuelles à inclure dans
le cadre de vos configurations du pare-feu local. Ces informations forment la liste actuelle des
plages d’adresses IP qui correspondent à chaque balise de service. Vous pouvez obtenir les
informations par programmation ou par le biais d’un téléchargement de fichier JSON, comme
décrit dans les sections suivantes.
Utiliser l’API Service Tag Discovery

Vous pouvez récupérer par programmation la liste actuelle des balises de service ainsi que les
informations relatives aux plages d’adresses IP :
REST
Azure PowerShell
Azure CLI
Par exemple, pour récupérer tous les préfixes de l’étiquette de service Stockage, vous pouvez
utiliser les applets de commande PowerShell suivantes :
Azure PowerShell
$serviceTags = Get-AzNetworkServiceTag -Location eastus2

$storage = $serviceTags.Values | Where-Object { $_.Name -eq "Storage" }
$storage.Properties.AddressPrefixes
７ Notes
Les données d’API représentent les étiquettes qui peuvent être utilisées avec les
règles de groupe de sécurité réseau dans votre région. Utilisez les données d’API
comme source de vérité pour les étiquettes de service disponibles, car elles peuvent
être différentes du fichier téléchargeable JSON.
La propagation des nouvelles données d’étiquette de service dans les résultats de
l’API de toutes les régions Azure prend jusqu’à 4 semaines. En raison de ce
processus, les résultats de vos données d’API peuvent ne pas être synchronisés avec
le fichier JSON téléchargeable, car les données d’API représentent un sous-
ensemble des étiquettes actuellement contenues dans le fichier JSON
téléchargeable.
Vous devez être authentifié et disposer d’un rôle avec des autorisations de lecture
pour votre abonnement actuel.
Détection de balises de service à l’aide de fichiers JSON

téléchargeables
Vous pouvez télécharger des fichiers JSON qui contiennent la liste actuelle des balises de
service avec les informations relatives aux plages d’adresses IP. Ces listes sont mises à jour et
publiées chaque semaine. Les emplacements de chaque Cloud sont :
Azure public
Azure US Government
Azure China 21Vianet
Azure Allemagne
Les plages d’adresses IP de ces fichiers sont en notation CIDR.
Les étiquettes AzureCloud suivantes n’ont pas de noms régionaux formatés selon le schéma
normal :
AzureCloud.centralfrance (FranceCentral)
AzureCloud.southfrance (FranceSouth)
AzureCloud.germanywc (GermanyWestCentral)
AzureCloud.germanyn (GermanyNorth)
AzureCloud.norwaye (NorwayEast)
AzureCloud.norwayw (NorwayWest)
AzureCloud.switzerlandn (SwitzerlandNorth)
AzureCloud.switzerlandw (SwitzerlandWest)
AzureCloud.usstagee (EastUSSTG)
AzureCloud.usstagec (SouthCentralUSSTG)
７ Notes
Un sous-ensemble de ces informations a été publié dans des fichiers XML pour Azure
public , Azure Chine et Azure Allemagne . Ces téléchargements XML seront
obsolètes à compter du 30 juin 2020 et ne seront plus disponibles après cette date. Vous
devez effectuer une migration à l’aide de l’API Discovery ou des téléchargements de
fichiers JSON, comme décrit dans les sections précédentes.
 Conseil
Vous pouvez détecter les mises à jour d’une publication à l’autre en notant les
valeurs changeNumber augmentées dans le fichier JSON. Chaque sous-section (par
exemple, Storage.WestUS) a sa propre valeur changeNumber qui est incrémentée
au fur et à mesure que des modifications sont effectuées. Le niveau supérieur de la
valeur changeNumber du fichier est incrémenté lorsque l’une des sous-sections est
modifiée.
Pour obtenir des exemples d’analyse des informations de balise de service (par
exemple, obtenir toutes les plages d’adresses pour le stockage dans la région
WestUS), reportez-vous à la documentation relative à l’API Service Tag Discovery
PowerShell.
Lorsque de nouvelles adresses IP sont ajoutées aux étiquettes de service, elles ne

sont pas utilisées dans Azure pendant au moins une semaine. Cela vous donne le
temps de mettre à jour les systèmes qui peuvent avoir besoin d’effectuer le suivi
des adresses IP associées aux balises de service.
Étapes suivantes
Découvrez comment créer des groupes de sécurité réseau.
Ligne de base de sécurité Azure pour les
réseaux virtuels
Cette base de référence de sécurité applique les conseils du benchmark de sécurité

cloud Microsoft version 1.0 à Réseau virtuel. Le benchmark de sécurité cloud Microsoft
fournit des recommandations sur la façon dont vous pouvez sécuriser vos solutions
cloud sur Azure. Le contenu est regroupé en fonction des contrôles de sécurité définis
par le benchmark de sécurité cloud Microsoft et des conseils associés applicables à
Réseau virtuel.
Vous pouvez surveiller cette base de référence de sécurité et ses recommandations à

l’aide de Microsoft Defender pour le cloud. Azure Policy définitions sont répertoriées
dans la section Conformité réglementaire du tableau de bord Microsoft Defender pour
le cloud.
Lorsqu’une fonctionnalité a des définitions de Azure Policy pertinentes, elles sont

répertoriées dans cette base de référence pour vous aider à mesurer la conformité aux
contrôles et recommandations du benchmark de sécurité cloud Microsoft. Certaines
recommandations peuvent nécessiter un plan de Microsoft Defender payant pour
activer certains scénarios de sécurité.
７ Notes
Les fonctionnalités non applicables à Réseau virtuel ont été exclues. Pour voir
comment Réseau virtuel est entièrement mappé au benchmark de sécurité cloud
Microsoft, consultez le fichier de mappage complet de la base de référence de
sécurité Réseau virtuel .
Profil de sécurité
Le profil de sécurité résume les comportements à fort impact de Réseau virtuel, ce qui
peut entraîner des considérations de sécurité accrues.
Attribut de comportement du service Valeur
Catégorie de produit Mise en réseau
Le client peut accéder à HOST/OS Aucun accès

Le service peut être déployé dans le réseau virtuel du client True
Stocke le contenu client au repos False
Sécurité du réseau
Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Sécurité
réseau.
NS-1 : Établir des limites de segmentation réseau
Fonctionnalités
Prise en charge des groupes de sécurité réseau
Description : Le trafic réseau de service respecte l’attribution de règles groupes de

sécurité réseau sur ses sous-réseaux. Plus d’informations
Prise en charge Activé par défaut Responsabilité de la configuration
True True Microsoft
Conseils de configuration : Aucune configuration supplémentaire n’est requise, car elle

est activée sur un déploiement par défaut.
Référence : Restreindre l’accès réseau aux ressources
Surveillance de Microsoft Defender pour le cloud
Définitions Azure Policy intégrées – Microsoft.Network :
Nom Description Effet(s) Version

(Portail Azure) (GitHub)
les sous- Protégez votre sous-réseau contre les menaces AuditIfNotExists, 3.0.0
réseaux potentielles en y limitant l’accès avec un groupe de Désactivé
doivent être sécurité réseau (NSG). Les NSG contiennent une
associés à un liste de règles de liste de contrôle d’accès (ACL) qui
groupe de autorisent ou refusent le trafic réseau vers votre
sécurité sous-réseau.
réseau
Gestion des identités
Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Gestion des
identités.
IM-1 : utiliser le système centralisé d’identité et

d’authentification
Fonctionnalités
Azure AD Authentication requis pour l’accès au plan de données
Description : Le service prend en charge l’utilisation de l’authentification Azure AD pour

l’accès au plan de données. Plus d’informations
False Non applicable Non applicable
Conseils de configuration : cette fonctionnalité n’est pas prise en charge pour sécuriser
ce service.
Accès privilégié
Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Accès
privilégié.
PA-7 : Suivre le principe JEA, Just Enough Administration

(privilège minimum)
Fonctionnalités
Azure RBAC pour le plan de données
Description : Azure Role-Based Access Control (Azure RBAC) peut être utilisé pour gérer
l’accès aux actions du plan de données du service. Plus d’informations

ce service.
Protection des données

Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Protection
des données.
DP-3 : chiffrer les données sensibles en transit
Fonctionnalités
Chiffrement des données en transit
Description : Le service prend en charge le chiffrement des données en transit pour le

plan de données. Plus d’informations
Pris en charge Activé par défaut Responsabilité de la configuration
ce service.
Gestion des ressources

ressources.
AM-2 : Utiliser uniquement des services approuvés
Fonctionnalités
Prise en charge d’Azure Policy

Description : Les configurations de service peuvent être surveillées et appliquées via
Azure Policy. Plus d’informations
True False Customer
Conseils de configuration : Utilisez Microsoft Defender pour le cloud pour configurer

Azure Policy afin d’auditer et d’appliquer des configurations de vos ressources Azure.
Utilisez Azure Monitor pour créer des alertes en cas d’écart de configuration détecté sur
les ressources. Utilisez les effets Azure Policy [refuser] et [déployer s’il n’existe pas] pour
appliquer une configuration sécurisée sur les ressources Azure.
Référence : Azure Policy définitions intégrées pour Azure Réseau virtuel
Journalisation et détection des menaces

Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft :
Journalisation et détection des menaces.
LT-4 : Activer la journalisation pour l’investigation de

sécurité
Fonctionnalités
Journaux des ressources Azure
Description : le service produit des journaux de ressources qui peuvent fournir des
métriques et une journalisation améliorées spécifiques au service. Le client peut
configurer ces journaux de ressources et les envoyer à son propre récepteur de
données, comme un compte de stockage ou un espace de travail Log Analytics. Plus
d’informations
True False Customer
Conseils de configuration : Activez les journaux de ressources pour le service. Par

exemple, Key Vault prend en charge des journaux de ressources supplémentaires pour
les actions qui obtiennent un secret à partir d’un coffre de clés ou Azure SQL a des
journaux de ressources qui effectuent le suivi des demandes adressées à une base de
données. Le contenu des journaux de ressources varie en fonction du service Azure et
du type de ressource.
Sauvegarde et récupération
Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Sauvegarde
et récupération.
BR-1 : Garantir des sauvegardes automatiques régulières
Fonctionnalités
Sauvegarde Azure
Description : le service peut être sauvegardé par le service Sauvegarde Azure. Plus
d’informations
Conseils de configuration : Cette fonctionnalité n’est pas prise en charge pour sécuriser
ce service.
Étapes suivantes
Consultez la vue d’ensemble du benchmark de sécurité cloud Microsoft
En savoir plus sur les bases de référence de la sécurité Azure
Base de référence de sécurité Azure
pour la passerelle NAT Azure
Article • 05/05/2023
Cette base de référence de sécurité applique les conseils du benchmark de sécurité

cloud Microsoft version 1.0 à Azure NAT Gateway. Le Benchmark de sécurité Microsoft
Cloud fournit des recommandations sur la façon dont vous pouvez sécuriser vos
solutions cloud sur Azure. Le contenu est regroupé en fonction des contrôles de sécurité
définis par le benchmark de sécurité cloud Microsoft et des conseils associés applicables
à la passerelle NAT Azure.
Vous pouvez superviser cette base de référence de la sécurité et ses recommandations

en utilisant Microsoft Defender pour le cloud. Azure Policy définitions sont répertoriées
dans la section Conformité réglementaire du tableau de bord Microsoft Defender pour
le cloud.
Lorsqu’une fonctionnalité a des définitions de Azure Policy pertinentes, elles sont

répertoriées dans cette base de référence pour vous aider à mesurer la conformité aux
contrôles et recommandations du benchmark de sécurité cloud Microsoft. Certaines
recommandations peuvent nécessiter un plan de Microsoft Defender payant pour
activer certains scénarios de sécurité.
７ Notes
Les fonctionnalités non applicables à la passerelle NAT Azure ont été exclues. Pour
voir comment Azure NAT Gateway est entièrement mappé au benchmark de
sécurité cloud Microsoft, consultez le fichier de mappage complet de la base de
référence de sécurité de la passerelle NAT Azure .
Profil de sécurité
Le profil de sécurité résume les comportements à impact élevé de la passerelle NAT
Azure, ce qui peut entraîner des considérations de sécurité accrues.
Catégorie de produit Mise en réseau
Le client peut accéder à HOST/OS Aucun accès

Le service peut être déployé dans le réseau virtuel du client True
Stocke le contenu client au repos Faux
Sécurité du réseau
Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Sécurité
réseau.
NS-1 : Établir des limites de segmentation réseau
Fonctionnalités
Intégration du réseau virtuel
Description : Le service prend en charge le déploiement dans le Réseau virtuel privé

(VNet) du client. Plus d’informations
True Faux Customer
Conseils de configuration : Déployez le service dans un réseau virtuel. Attribuez des

adresses IP privées à la ressource (le cas échéant), sauf s’il existe une raison forte
d’affecter des adresses IP publiques directement à la ressource.
Référence : Démarrage rapide : Créer une passerelle NAT à l’aide du Portail Azure
Surveillance de Microsoft Defender pour le cloud

Définitions Azure Policy intégrées – Microsoft.Network :

les sous- Protégez votre sous-réseau contre les menaces AuditIfNotExists, 3.0.0
réseaux potentielles en y limitant l’accès avec un groupe de Désactivé
doivent être sécurité réseau (NSG). Les NSG contiennent une
associés à un liste de règles de liste de contrôle d’accès (ACL) qui
groupe de autorisent ou refusent le trafic réseau vers votre
sécurité sous-réseau.
réseau
Gestion des identités

identités.
IM-1 : utiliser le système centralisé d’identité et

d’authentification
Fonctionnalités
Azure AD Authentication requis pour l’accès au plan de données
Description : Le service prend en charge l’utilisation de l’authentification Azure AD pour

l’accès au plan de données. Plus d’informations
Faux Non applicable Non applicable
ce service.
Gestion des ressources

ressources.
AM-2 : Utiliser uniquement des services approuvés

Fonctionnalités
Prise en charge d’Azure Policy
Description : les configurations de service peuvent être surveillées et appliquées via

Azure Policy. Plus d’informations
True Faux Customer
Conseils de configuration : Il n’existe aucune aide Microsoft actuelle pour cette

configuration de fonctionnalité. Vérifiez et déterminez si votre organization souhaite
configurer cette fonctionnalité de sécurité.
Référence : Stratégies intégrées - Réseau
Journalisation et détection des menaces

Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft :
journalisation et détection des menaces.
LT-4 : Activer la journalisation pour l’investigation de

sécurité
Fonctionnalités
Journaux des ressources Azure
Description : le service produit des journaux de ressources qui peuvent fournir des
métriques et une journalisation améliorées spécifiques au service. Le client peut
configurer ces journaux de ressources et les envoyer à son propre récepteur de
données, comme un compte de stockage ou un espace de travail Log Analytics. Plus
d’informations
Faux Non applicable Non applicable
Remarques sur les fonctionnalités : le service fournit d’autres fonctionnalités de

journalisation, telles que les journaux de métriques et d’insights.
Pour plus d’informations, consultez Métriques et alertes de la passerelle NAT Azure.
Conseils de configuration : Cette fonctionnalité n’est pas prise en charge pour sécuriser
ce service.
Étapes suivantes
Consultez la vue d’ensemble du benchmark de sécurité cloud Microsoft
En savoir plus sur les bases de référence de la sécurité Azure
Intégrer des services Azure à des
réseaux virtuels pour l’isolement réseau
Article • 15/05/2023
L’intégration d’un réseau virtuel pour un service Azure vous permet de verrouiller l’accès
au service à votre infrastructure de réseau virtuel uniquement. L’infrastructure de réseau
virtuel comprend également des réseaux virtuels appairés et des réseaux locaux.
L’intégration au réseau virtuel offre aux services Azure les avantages de l’isolement
réseau et peut être accomplie à l’aide d’une ou plusieurs des méthodes suivantes :

réseaux locaux.
Utilisation d’un point de terminaison privé qui vous permet de vous connecter de
façon privée et sécurisée à un service basé sur Azure Private Link. Le point de
terminaison privé utilise une adresse IP privée de votre réseau virtuel pour
apporter le service à votre réseau virtuel de façon effective.
Accès au service à l’aide de points de terminaison publics en étendant un réseau

virtuel au service par le biais de points de terminaison de service. Les points de
terminaison de service permettent de sécuriser les ressources de service au sein du
réseau virtuel.
Utilisation d’étiquettes de service pour autoriser ou refuser le trafic vers vos

ressources Azure vers et depuis des points de terminaison IP publics.
Déployer des services Azure dédiés dans des

réseaux virtuels
privées.
Le déploiement d’un service Azure dédié dans votre réseau virtuel offre les capacités
suivantes :
réseau virtuel.
ou ExpressRoute.
privées.
Le service Azure gère entièrement les instances de service dans un réseau virtuel.
Cette gestion inclut la surveillance de l’intégrité des ressources et la mise à
l’échelle avec une charge.
service.
Certains services imposent des restrictions sur le sous-réseau dans lequel ils sont
déployés. Ces restrictions limitent l’application de stratégies, d’itinéraires, ou la
peuvent changer au fil du temps. Azure NetApp Files, Dedicated HSM, Azure
Container Instances, App Service sont des exemples de ces services.

identificateur explicit qu’un sous-réseau peut héberger un service particulier. Les
services Azure reçoivent des autorisations explicites pour créer des ressources
propres au service dans le sous-réseau délégué.
disponibles).
Pour obtenir la liste des services qui peuvent être déployés dans un réseau virtuel,
consultez Déployer des services Azure dédiés dans des réseaux virtuels.
Liaison privée et points de terminaison privés

Les points de terminaison privés autorisent l’entrée de trafic à partir de votre réseau
virtuel vers une ressource Azure en toute sécurité. Cette liaison privée est établie sans
qu’il soit nécessaire d’utiliser des adresses IP publiques. Un point de terminaison privé
est une interface réseau spéciale pour un service Azure dans votre réseau virtuel.
Lorsque vous créez un point de terminaison privé pour votre ressource, il offre une
connectivité sécurisée entre les clients de votre réseau virtuel et votre ressource Azure.
Une adresse IP est attribuée au point de terminaison privé à partir de la plage
d’adresses IP de votre réseau virtuel. La connexion entre le point de terminaison privé et
le service Azure utilise une liaison privée.
La partie droite du diagramme affiche une base de données Azure SQL Database en tant
que service PaaS cible. La cible peut être n’importe quel service qui prend en charge les
points de terminaison privés. Il existe plusieurs instances de SQL Server logique pour
plusieurs clients, qui sont toutes accessibles via des adresses IP publiques.
Dans ce cas, une instance de SQL Server logique est exposée avec un point de
terminaison privé. Le point de terminaison rend SQL Server accessible via une adresse IP
privée dans le réseau virtuel du client. En raison de la modification de la configuration
DNS, l’application cliente envoie maintenant son trafic directement à ce point de
terminaison privé. Le service cible verra le trafic provenant d’une adresse IP privée du
réseau virtuel.
La flèche verte représente une liaison privée. Une adresse IP publique peut encore
exister pour la ressource cible en même temps que le point de terminaison privé.
L’adresse IP publique n’est plus utilisée par l’application cliente. Le pare-feu peut
désormais interdire tout accès à cette adresse IP publique, ce qui la rend accessible
uniquement via des points de terminaison privés. Les connexions à un serveur SQL sans
point de terminaison privé du réseau virtuel sont toujours issues d’une adresse IP
publique. La flèche bleue représente ce flux.
L’application cliente utilise généralement un nom d’hôte DNS pour atteindre le service
cible. Aucune modification n’est requise pour l’application. La résolution DNS dans le
réseau virtuel doit être configurée pour résoudre le même nom d’hôte à l’adresse IP
privée de la ressource cible au lieu de l’adresse IP publique d’origine. Avec un chemin
d’accès privé entre le client et le service cible, le client ne repose pas sur l’adresse IP
publique. Le service cible peut désactiver l’accès public.
Cette exposition d’instances individuelles vous permet d'éviter le vol de données. Un

acteur malveillant ne peut pas collecter des informations de la base de données ni les
charger dans une autre base de données publique ou un autre compte de stockage.
Vous pouvez empêcher l’accès aux adresses IP publiques de tous les services PaaS. Vous
pouvez toujours autoriser l’accès aux instances PaaS via leurs points de terminaison
privés.
Pour plus d’informations sur Private Link et pour obtenir la liste des services Azure pris
en charge, consultez Qu’est-ce que Private Link ?
Points de terminaison de service

Les points de terminaison de service fournissent une connectivité directe et sécurisée
aux services Azure via le réseau principal Azure. Les points de terminaison permettent
de sécuriser vos ressources Azure critiques pour vos réseaux virtuels uniquement. Les
points de terminaison de service permettent aux adresses IP privées dans le réseau
virtuel d’atteindre un service Azure sans avoir besoin d’une adresse IP publique sortante.
Sans point de terminaison de service, il peut être difficile de limiter l’accès à votre réseau
virtuel uniquement. L’adresse IP source peut être modifiée ou partagée avec d’autres
clients. Par exemple, les services PaaS avec des adresses IP sortantes partagées. Avec les
points de terminaison de service, l’adresse IP source que le service cible voit devient une
adresse IP privée de votre réseau virtuel. Cette modification du trafic entrant permet
d’identifier facilement l’origine et de l’utiliser pour configurer des règles de pare-feu
appropriées. Par exemple, en autorisant uniquement le trafic à partir d’un sous-réseau
spécifique au sein de ce réseau virtuel.
Avec les points de terminaison de service, les entrées DNS pour les services Azure ne
sont pas modifiées et continuent de résoudre les adresses IP publiques attribuées au
service Azure.
Dans le diagramme ci-dessous, le côté droit est le même service PaaS cible. Sur la
gauche se trouve un réseau virtuel client avec deux sous-réseaux : le sous-réseau A, qui
a un point de terminaison de service vers Microsoft.Sql , et le sous-réseau B, qui n’a
aucun point de terminaison de service défini.
Lorsqu’une ressource du sous-réseau B tente d’atteindre un serveur SQL Server, elle

utilise une adresse IP publique pour les communications sortantes. La flèche bleue
représente ce trafic. Le pare-feu SQL Server doit utiliser cette adresse IP publique pour
autoriser ou bloquer le trafic réseau.
Lorsqu’une ressource du sous-réseau A tente d’atteindre un serveur de base de

données, elle est considérée comme une adresse IP privée à partir du réseau virtuel. Les
flèches vertes représentent ce trafic. Le pare-feu SQL Server peut désormais autoriser ou
bloquer spécifiquement le sous-réseau A. Il n’est pas nécessaire de connaître l’adresse IP
publique du service source.
Les points de terminaison de service s’appliquent à toutes les instances du service cible.
Par exemple, toutes les instances de SQL Server de clients Azure, pas seulement
l’instance du client.
Pour plus d’informations, consultez Points de terminaison de service de réseau virtuel.
Balises de service
donné. Avec des étiquettes de service, vous pouvez définir des contrôles d’accès réseau
sur des groupes de sécurité réseau ou le Pare-feu Azure. Vous pouvez autoriser ou
refuser le trafic pour le service. Pour autoriser ou refuser le trafic, spécifiez l’étiquette de
service dans le champ source ou de destination d’une règle.
Isoler le réseau et protéger vos ressources Azure d’Internet lorsque vous accédez aux
services Azure qui ont des points de terminaison publics. Créez des règles de groupe de
sécurité réseau entrant/sortant pour refuser le trafic vers et depuis Internet et autoriser
le trafic vers/à partir d’AzureCloud. Pour en savoir plus sur les étiquettes de service,
consultez Étiquettes de service disponibles pour des services Azure spécifiques.
Pour plus d’informations sur les étiquettes de service et les services Azure qui les
prennent en charge, consultez Vue d’ensemble des étiquettes de service.
Comparer des points de terminaison privés et

des points de terminaison de service
７ Notes
Microsoft recommande l’utilisation de Azure Private Link. Private Link offre de

meilleures fonctionnalités en termes d’accès privé au PaaS à partir d’un site local,
dans un service de protection et de mappage d’exfiltration des données intégré à
une adresse IP privée dans votre propre réseau. Pour plus d’informations, consultez
Azure Private Link
Plutôt que d’examiner uniquement leurs différences, il convient de souligner que les
points de terminaison de service et les points de terminaison privés ont des
caractéristiques communes.
Ces deux fonctionnalités sont utilisées pour un contrôle plus granulaire du pare-feu sur
le service cible. Par exemple, pour limiter l’accès aux bases de données SQL Server ou
aux comptes de stockage. Toutefois, l’opération est différente pour les deux, comme
indiqué plus en détail dans les sections précédentes.
Les deux approches résolvent le problème d'Insuffisance de ports SNAT (Network

Address Translation) sources. Vous risquez une insuffisance lorsque vous tunnelisez le
trafic via une appliance virtuelle réseau ou un service avec des limitations de port SNAT.
Lorsque vous utilisez des points de terminaison de service ou des points de terminaison
privés, le trafic prend directement un chemin d’accès optimisé vers le service cible. Les
deux approches peuvent tirer parti des applications gourmandes en bande passante, car
la latence et le coût sont réduits.
Dans les deux cas, vous pouvez toujours vous assurer que le trafic dans le service cible
traverse un pare-feu réseau ou appliance virtuelle réseau. Cette procédure est différente
pour les deux approches. Lorsque vous utilisez des points de terminaison de service,
vous devez configurer le point de terminaison de service sur le sous-réseau du pare-feu,
plutôt que sur le sous-réseau où le service source est déployé. Lorsque vous utilisez des
points de terminaison privés, vous placez un itinéraire défini par l’utilisateur (UDR) pour
l’adresse IP du point de terminaison privé sur le sous-réseau source. Pas dans le sous-
réseau du point de terminaison privé.
Pour comparer les références SKU et comprendre leurs différences, consultez le tableau
ci-dessous.

terminaison
privés
Portée du service à Totalité du service (par exemple, tous les serveurs Instance
chaque niveau SQL ou les comptes de stockage de tous les individuelle (par
d’application de la clients) exemple, une
configuration instance de SQL
Server
spécifique ou
un compte de
stockage que
vous possédez)
terminaison
privés
Protection d’exfiltration Non Oui

de données intégrée :
possibilité de
déplacer/copier des
données à partir d’une
ressource PaaS protégée
vers une autre ressource
PaaS non protégée par
un Insider malveillant
Accès privé à la ressource Non Oui

PaaS localement
Configuration du groupe Oui (à l’aide d’étiquettes de service) No

requise pour l’accès au
service
Le service peut être Non Oui

atteint sans utiliser
d’adresse IP publique
Le trafic Azure vers Azure Oui Oui

reste sur le réseau
principal Azure
Le service peut désactiver Non Oui

son adresse IP publique
Vous pouvez facilement Oui (autoriser l’accès à partir de sous-réseaux Oui

limiter le trafic provenant spécifiques et ou utiliser des groupes de sécurité
d’un réseau virtuel Azure réseau)
Vous pouvez facilement N/A** Oui

limiter le trafic de
provenance locale
(VPN/ExpressRoute).
Requiert des Non Oui (consultez

modifications DNS Configuration
DNS)
Influence le coût de votre Non Oui (consultez

solution Tarification de
Private Link )
terminaison
privés
Influence le contrat SLA Non Oui (le service

composite de votre de liaison privée
solution dispose d’un
contrat SLA de
99,99 % )
Installation et Une configuration simple et un temps de gestion Des efforts

maintenance réduit supplémentaires
sont
nécessaires.
Limites Aucune limite sur le nombre total de points de Oui (consultez

terminaison de service dans un réseau virtuel. Les Limites de
services Azure peuvent appliquer des limites sur le Private Link)
nombre de sous-réseaux utilisés pour sécuriser la
ressource. (consultez [FAQ sur le réseau virtuel]
(virtual-networks-faq.md#are-there-any-limits-on-
how-many-virtual network-service-endpoints-i-
can-set-up-from-my-virtual network))
**Les ressources du service Azure sécurisées pour des réseaux virtuels ne sont pas
accessibles à partir des réseaux locaux. Si vous souhaitez autoriser le trafic depuis un
réseau local, autorisez également les adresses IP publiques (généralement NAT) à partir
de vos circuits locaux ou ExpressRoute. Ces adresses IP peuvent être ajoutées via la
configuration du pare-feu IP des ressources du service Azure. Pour plus d’informations,
consultez la FAQ sur le réseau virtuel.
Étapes suivantes
Découvrez comment intégrer votre application à un réseau Azure.
Découvrez comment restreindre l’accès aux ressources à l’aide d’étiquettes de

service.
Découvrez comment vous connecter en privé à un compte Azure Cosmos DB à

l’aide d’Azure Private Link.
Vous pouvez utiliser un groupe de sécurité réseau Azure pour filtrer le trafic réseau entre
des ressources Azure dans un réseau virtuel Azure. Un groupe de sécurité réseau
contient des règles de sécurité qui autorisent ou rejettent le trafic réseau entrant et
sortant vers différents types de ressources Azure. Pour chaque règle, vous pouvez
spécifier la source et la destination, le port et le protocole.
Cet article décrit les propriétés d’une règle de groupe de sécurité réseau, les règles de
sécurité par défaut appliquées et les propriétés de règle que vous pouvez modifier pour
créer une règle de sécurité augmentée.
Règles de sécurité
Un groupe de sécurité réseau contient le nombre des règles souhaité (ou aucune), dans
les limites de l’abonnement Azure. Chaque règle spécifie les propriétés suivantes :
Propriété Explication
Nom Nom unique au sein du groupe de sécurité réseau. Le nom peut contenir jusqu’à
80 caractères. Il doit commencer par un caractère alphabétique et se terminer par
un caractère alphabétique ou « _ ». Le nom peut contenir des caractères
alphabétiques ou « . », « - », « _ ».
Priorité Nombre compris entre 100 et 4096. Les règles sont traitées dans l’ordre croissant,
car les nombres les plus faibles sont prioritaires. Une fois que le trafic correspond à
une règle, le traitement s’arrête. Par conséquent, les règles avec des priorités plus
faibles (des nombres plus élevés) et ayant les mêmes attributs que les règles de
priorité supérieure ne sont pas traitées.
Propriété Explication
Source ou Une adresse IP, un bloc de routage CIDR (par exemple, 10.0.0.0/24), une balise de
destination service ou un groupe de sécurité d’application. Si vous spécifiez une adresse pour
une ressource Azure, spécifiez l’adresse IP privée assignée à la ressource. Les
groupes de sécurité réseau sont traités une fois qu’Azure a converti une adresse IP
publique en adresse IP privée pour le trafic entrant, et avant qu’Azure ne convertisse
une adresse IP privée en une adresse IP publique pour le trafic sortant. Moins de
règles de sécurité sont nécessaires lorsque vous spécifiez une plage, une étiquette
de service ou un groupe de sécurité d’application. La possibilité de spécifier
plusieurs adresses IP individuelles et plages (vous ne pouvez pas spécifier plusieurs
balises de service ou groupes d’applications) dans une règle est désignée sous le
nom de règles de sécurité augmentée. Les règles de sécurité augmentée peuvent
uniquement être créées dans des groupes de sécurité réseau créés par le biais du
modèle de déploiement du Gestionnaire de ressources. Vous ne pouvez pas
spécifier plusieurs adresses IP et plages d’adresses IP dans les groupes de sécurité
réseau créés par le biais du modèle de déploiement classique.
Protocol TCP, UDP, ICMP, ESP, AH ou n’importe lequel. Les protocoles ESP et AH ne sont pas
actuellement disponibles via le portail Azure, mais peuvent être utilisés via des
modèles ARM.
Sens Indique si la règle s’applique au trafic entrant ou sortant.
Plage de Vous pouvez spécifier un port individuel ou une plage de ports. Par exemple,
ports indiquez 80 ou 10000-10005. La spécification de plages vous permet de créer moins
de règles de sécurité. Les règles de sécurité augmentée peuvent uniquement être
créées dans des groupes de sécurité réseau créés par le biais du modèle de
déploiement du Gestionnaire de ressources. Vous ne pouvez pas spécifier plusieurs
ports ou plages de ports dans les groupes de sécurité réseau créés par le biais du
modèle de déploiement classique.
Action Autoriser ou refuser
Les règles de sécurité sont évaluées et appliquées en fonction des informations de cinq
tuples (source, port source, destination, port de destination et protocole). Vous ne
pouvez pas créer deux règles de sécurité avec les mêmes priorité et direction. Un
enregistrement de flux est créé pour les connexions existantes. La communication est
autorisée ou refusée en fonction de l’état de connexion de l’enregistrement de flux.
L’enregistrement de flux permet d’obtenir un groupe de sécurité réseau avec état. Si
vous spécifiez une règle de sécurité sortante vers n’importe quelle adresse sur le
port 80, par exemple, il n’est pas nécessaire d’indiquer une règle de sécurité entrante
pour la réponse au trafic sortant. Vous devez uniquement spécifier une règle de sécurité
entrante si la communication est établie en externe. Le contraire est également vrai. Si le
trafic entrant est autorisé sur un port, il n’est pas nécessaire de spécifier une règle de
sécurité sortante pour répondre au trafic sur ce port.
Les connexions existantes peuvent ne pas être interrompues lorsque vous supprimez
une règle de sécurité qui autorisait la connexion. La modification des règles du groupe
de sécurité réseau n’affecte que les nouvelles connexions. Quand une règle est créée ou
qu’une règle existante est mise à jour dans un groupe de sécurité réseau, elle s’applique
uniquement aux nouvelles connexions. Les connexions existantes ne sont pas réévaluées
en fonction des nouvelles règles.
Le nombre de règles de sécurité que vous pouvez créer dans un groupe de sécurité
réseau est limité. Pour plus d’informations, consultez limites Azure.
Règles de sécurité par défaut

Azure crée les règles par défaut suivantes dans chaque groupe de sécurité réseau que
vous créez :
Trafic entrant
AllowVNetInBound
Priority Source Ports Destination Ports de Protocol Accès

source destination
65 000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Quelconque Allow
AllowAzureLoadBalancerInBound

source destination
65 001 AzureLoadBalancer 0-65535 0.0.0.0/0 0-65535 Quelconque Allow
DenyAllInbound
Priority Source Ports source Destination Ports de destination Protocol Accès
65 500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Quelconque Deny
Règle de trafic sortant
AllowVnetOutBound
source destination
65 000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Quelconque Allow
AllowInternetOutBound
65 001 0.0.0.0/0 0-65535 Internet 0-65535 Quelconque Allow
DenyAllOutBound
65 500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Quelconque Deny
Dans les colonnes Source et Destination, VirtualNetwork, AzureLoadBalancer et Internet

sont des balises de service, non des adresses IP. Dans la colonne de protocole, Any
(N’importe lequel) englobe TCP, UDP et ICMP. Lorsque vous créez une règle, vous
pouvez spécifier TCP, UDP, ICMP ou Any (N’importe lequel). 0.0.0.0/0 dans les colonnes
Source et Destination représente toutes les adresses. Les clients comme le portail Azure,
Azure CLI ou PowerShell peuvent utiliser « * » ou « any » pour cette expression.
Vous ne pouvez pas supprimer les règles par défaut, mais vous pouvez les remplacer par
des règles de priorité plus élevée.
Règles de sécurité augmentée

Les règles de sécurité augmentée simplifient la définition de la sécurité pour les réseaux
virtuels, ce qui vous permet de définir des stratégies de sécurité réseau plus vastes et
plus complexes, avec moins de règles. Vous pouvez combiner plusieurs ports ainsi que
des adresses ou plages d’adresses IP explicites dans une seule règle de sécurité
facilement compréhensible. Utiliser des règles de sécurité augmentée dans les champs
de la source, de la destination et du port d’une règle. Pour simplifier la maintenance de
votre définition de règle de sécurité, combinez des règles de sécurité augmentée avec
des balises de service ou des groupes de sécurité d’application. Le nombre d’adresses,
les plages et les ports que vous pouvez spécifier dans une règle sont limités. Pour plus
d’informations, consultez limites Azure.
Balises de service
donné. Elle permet de minimiser la complexité des mises à jour fréquentes des règles de
sécurité réseau.
Pour plus d’informations, consultez Balises de Service Azure. Pour obtenir un exemple
d’utilisation de la balise de service de stockage pour limiter l’accès réseau, consultez
Limiter l’accès réseau aux ressources PaaS.

Les groupes de sécurité d’application permettent de configurer la sécurité réseau
comme un prolongement naturel de la structure de l’application, et donc de regrouper
les machines virtuelles et définir des stratégies de sécurité réseau basés sur ces groupes.
Vous pouvez réutiliser votre stratégie de sécurité à grande échelle sans maintenance
manuelle d’adresses IP explicites. Pour en savoir plus, consultez Groupes de sécurité
d’application.
Considérations relatives à la plateforme Azure

Adresse IP virtuelle du nœud hôte : Des services d’infrastructure de base tels que
DHCP, DNS, IMDS et l’analyse de l’intégrité sont fournis par le biais des adresses IP
d’hôte virtualisées 168.63.129.16 et 169.254.169.254. Ces adresses IP appartiennent
à Microsoft et sont les seules adresses IP virtualisées utilisées à cet effet dans
toutes les régions. Par défaut, ces services ne sont pas soumis aux groupes de
sécurité réseau configurés, sauf si les étiquettes de service spécifiques à chaque
service sont ciblées. Pour remplacer cette communication d’infrastructure de base,
vous pouvez créer une règle de sécurité pour refuser le trafic en utilisant les balises
de service suivantes sur vos règles de groupe de sécurité réseau :
AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM. Découvrez comment
diagnostiquer le filtrage de trafic réseau et diagnostiquer le routage réseau.
Gestion des licences (Service de gestion des clés) : Les images Windows en cours
d’exécution sur les machines virtuelles doivent être acquises sous licence. Pour
assurer la gestion des licences, une requête est envoyée aux serveurs hôtes du
Service de gestion de clés qui gèrent les requêtes de ce type. La requête est
effectuée en sortie par le biais du port 1688. Cette règle de plateforme est
désactivée pour les déploiements utilisant la configuration itinéraire par défaut
0.0.0.0/0.
Machines virtuelles dans des pools d’équilibrage de charge : Le port source et la

plage d’adresses appliquées proviennent de l’ordinateur d’origine, pas de
l’équilibreur de charge. La plage de ports et d’adresses de destination sont ceux de
l’ordinateur de destination, et non de l’équilibreur de charge.
Instances de service Azure : Les instances de plusieurs services Azure, tels que
HDInsight, les environnements de service d’application et Virtual Machine Scale
Sets, sont déployées dans des sous-réseaux du réseau virtuel. Pour obtenir la liste
complète des services que vous pouvez déployer sur des réseaux virtuels,
consultez Réseau virtuel pour les services Azure. Avant d’appliquer un groupe de
sécurité réseau au sous-réseau, familiarisez-vous avec les exigences de port pour
chaque service. Si vous refusez les ports requis par le service, ce dernier ne
fonctionnera pas correctement.
Envoi d’e-mail sortant : Microsoft vous recommande l’utilisation de services de

relais authentifiés SMTP (généralement connectés via le port TCP 587, mais parfois
via d’autres ports) pour envoyer un e-mail depuis des machines virtuelles Azure.
Les services de relais SMTP se spécialisent dans la réputation des expéditeurs, afin
de minimiser les risques de renvoi de messages de la part de fournisseurs de
messagerie tiers. Ce type de services de relais SMTP incluent, sans s’y limiter,
Exchange Online Protection et SendGrid. L’utilisation de services de relais SMTP
n’est en aucun cas limitée dans Azure et ne tient pas compte de votre type
d’abonnement.
Si vous avez créé votre abonnement Azure avant le 15 novembre 2017, vous
pouvez, en plus d’utiliser des services de relais SMTP, envoyer des messages
électroniques via le port TCP 25 directement. Si vous avez créé votre abonnement
après le 15 novembre 2017, vous ne serez peut-être pas en mesure d’envoyer des
messages électroniques via le port TCP 25 directement. Le comportement des
communications sortantes via le port 25 dépend de votre type d’abonnement :
Contrat Entreprise : Pour les machines virtuelles qui sont déployées dans des
abonnements Contrat Entreprise standard, les connexions SMTP sortantes sur le
port TCP 25 ne sont pas bloquées. Cependant, il n’y a aucune garantie que les
domaines externes accepteront les e-mails entrants en provenance des
machines virtuelles. Si vos e-mails sont rejetés ou filtrés par les domaines
externes, vous devez contacter les fournisseurs de services de messagerie des
domaines externes pour résoudre les problèmes. Ces problèmes ne sont pas
couverts par le support Azure.
Pour les abonnements Enterprise Dev/Test, le port 25 est bloqué par défaut. Il
est possible de faire sauter ce blocage. Pour demander la suppression du
blocage, accédez à la section Impossible d’envoyer un e-mail (SMTP/Port 25)
de la page de paramètres Diagnostiquer et résoudre pour la ressource Réseau
virtuel Azure sur le portail Azure, puis exécutez le diagnostic. Cela permet
d’exempter automatiquement les abonnements qualifiés Enterprise Dev/Test.
Une fois que l’abonnement est exempté de ce blocage et que les machines
virtuelles sont arrêtées et redémarrées, toutes les machines virtuelles de cet
abonnement sont exemptées. L’exemption s’applique uniquement à
l’abonnement demandé et au trafic de machine virtuelle acheminé directement
vers Internet.
Paiement à l’utilisation : Les communications sortantes via le port 25 sont

bloquées pour toutes les ressources. Aucune demande pour retirer la restriction
ne peut être faite. Elles ne sont pas autorisées. Si vous devez envoyer des
courriers électroniques depuis votre machine virtuelle, vous devez utiliser un
service de relais SMTP.
MSDN, Pass Azure, Azure dans Open, Éducation, BizSpark et Essai gratuit : Les
communications sortantes via le port 25 sont bloquées pour toutes les
ressources. Aucune demande pour retirer la restriction ne peut être faite. Elles
ne sont pas autorisées. Si vous devez envoyer des courriers électroniques
depuis votre machine virtuelle, vous devez utiliser un service de relais SMTP.
Fournisseur de services cloud : Les communications sortantes via le port 25

sont bloquées vers toutes les ressources. Aucune demande pour retirer la
restriction ne peut être faite. Elles ne sont pas autorisées. Si vous devez envoyer
des courriers électroniques depuis votre machine virtuelle, vous devez utiliser
un service de relais SMTP.
Étapes suivantes
Pour en savoir plus sur les ressources Azure pouvant être déployées dans un
réseau virtuel et auxquelles des groupes de sécurité réseau peuvent être associées,
consultez Intégration d’un réseau virtuel pour les services Azure.
Pour savoir comment le trafic est évalué avec les groupes de sécurité réseau,
consultez À propos des groupes de sécurité réseau.
Si vous n’avez jamais créé un groupe de sécurité réseau, vous pouvez suivre un
didacticiel rapide pour vous entraîner.
Si vous êtes familier avec les groupes de sécurité réseau et que vous devez en
gérer un, consultez Gérer un groupe de sécurité réseau.
Si vous rencontrez des problèmes de communication et que vous avez besoin
résoudre les problèmes de groupes de sécurité réseau, consultez Diagnostiquer un
problème de filtre de trafic réseau sur une machine virtuelle.
Découvrez comment activer les journaux de flux de groupe de sécurité réseau pour
analyser le trafic réseau vers et à partir des ressources auxquelles un groupe de
sécurité réseau est associé.
Façon dont les groupes de sécurité
réseau filtrent le trafic
Article • 07/05/2023
Vous pouvez utiliser un groupe de sécurité réseau Azure pour filtrer le trafic réseau à
destination et en provenance des ressources Azure dans un réseau virtuel Azure. Un
groupe de sécurité réseau contient des règles de sécurité qui autorisent ou rejettent le
trafic réseau entrant et sortant vers différents types de ressources Azure. Pour chaque
règle, vous pouvez spécifier la source et la destination, le port et le protocole.
Vous pouvez déployer des ressources à partir de plusieurs services Azure dans un réseau
virtuel Azure. Pour une liste complète, consultez Services pouvant être déployés dans un
réseau virtuel. Vous pouvez associer zéro ou un groupe de sécurité réseau à chaque
sous-réseau de réseau virtuel et interface réseau dans une machine virtuelle. Vous
pouvez associer le même groupe de sécurité réseau à autant d’interfaces réseau
individuelles et autant de sous-réseaux que vous le souhaitez.
L’image suivante illustre les différents scénarios de déploiement des groupes de sécurité
réseau afin d’autoriser le trafic réseau vers et à partir d’internet via le port TCP 80 :
Référez-vous à l’image précédente ainsi qu’au texte suivant pour comprendre comment
Azure traite les règles entrantes et sortantes pour les groupes de sécurité réseau :
Trafic entrant
Pour le trafic entrant, Azure traite d’abord les règles dans un groupe de sécurité réseau
associées à un sous-réseau, si elles existent, puis les règles dans un groupe de sécurité
réseau associées à l’interface réseau, si elles existent. Ce processus inclut également un
trafic intra-sous-réseau.
VM1 : les règles de la sécurité dans NSG1 sont traitées dans la mesure où elles sont
associées à Subnet1 et VM1 est dans Subnet1. À moins que vous n’ayez créé une
règle qui autorise le port 80 entrant, la règle de sécurité par défaut
DenyAllInbound refuse le trafic. Le trafic n’est pas évalué par NSG2, car il est
associé à l’interface réseau. Si NSG1 autorise le port 80 dans sa règle de sécurité,
NSG2 traite le trafic. Pour autoriser le port 80 vers la machine virtuelle, NSG1 et
NSG2 doivent disposer tous deux d’une règle autorisant l’accès au port 80 à partir
d’Internet.
VM2 : Les règles dans NSG1 sont traitées étant donné que VM2 se trouve
également dans Subnet1. Dans la mesure où VM2 ne dispose pas d’un groupe de
sécurité réseau associé à son interface réseau, elle reçoit tout le trafic autorisé via
NSG1 ou se voit refuser tout le trafic refusé par NSG1. Le trafic est soit autorisé,
soit refusé à toutes les ressources dans le même sous-réseau lorsqu’un groupe de
sécurité réseau est associé à un sous-réseau.
VM3 : dans la mesure où il n’existe aucun groupe de sécurité réseau associé à

Subnet2, le trafic est autorisé dans un sous-réseau et traité par NSG2, car NSG2 est
associé à l’interface réseau attachée à VM3.
VM4 : Le trafic est autorisé vers VM4, car aucun groupe de sécurité réseau n’est
associé à Subnet3 ou à l’interface réseau dans la machine virtuelle. L’intégralité du
trafic réseau est autorisée via une interface réseau et un sous-réseau si aucun
groupe de sécurité réseau leur est associé.
Trafic sortant
Pour le trafic sortant, Azure traite d’abord les règles dans un groupe de sécurité réseau
associées à une interface réseau, si elles existent, puis les règles dans un groupe de
sécurité réseau associées au sous-réseau, si elles existent. Ce processus inclut également
un trafic intra-sous-réseau.
VM1 : Les règles de sécurité dans NSG2 sont traitées. La règle de sécurité par
défaut AllowInternetOutbound à la fois de NSG1 et de NSG2 autorise le trafic, sauf
si vous avez créé une règle de sécurité qui refuse le port 80 sortant vers Internet. Si
NSG2 refuse le port 80 dans sa règle de sécurité, il refuse le trafic et NSG1 ne
l’évalue jamais. Pour refuser le port 80 à partir de la machine virtuelle, l’un au
moins des groupes de sécurité réseau doit disposer d’une règle qui refuse l’accès à
Internet par le port 80.
VM2 : tout le trafic est envoyé via l’interface réseau au sous-réseau, étant donné
que l’interface réseau attachée à VM2 ne dispose pas d’un groupe de sécurité
réseau associé. Les règles dans NSG1 sont traitées.
VM3 : si NSG2 refuse le port 80 dans sa règle de sécurité, il refuse le trafic. Si NSG2
ne refuse pas le port 80, la règle de sécurité par défaut AllowInternetOutbound de
NSG2 autorise le trafic, car aucun groupe de sécurité réseau n’est associé à
Subnet2.
VM4 : L’ensemble du trafic réseau est autorisé depuis VM4, car aucun groupe de
sécurité réseau n’est associé à Subnet3 ou à l’interface réseau associée à la
machine virtuelle.
Trafic intra-sous-réseau
Il est important de noter que les règles de sécurité dans un groupe de sécurité réseau
(NSG) associé à un sous-réseau peuvent perturber la connectivité entre les machines
virtuelles (VM) qui le composent. Par défaut, les machines virtuelles du même sous-
réseau peuvent communiquer en fonction d’une règle de groupe de sécurité réseau par
défaut autorisant le trafic intra-sous-réseau. Si vous ajoutez une règle NSG1 qui refuse
tout le trafic entrant et sortant, VM1 et VM2 ne peuvent pas communiquer entre elles.
Vous pouvez facilement afficher des règles d’agrégation appliquées à une interface
réseau en consultant les règles de sécurité efficaces relatives à une interface réseau.
Vous pouvez également utiliser la fonctionnalité de vérification du flux IP dans Azure
Network Watcher pour déterminer si la communication est autorisée vers ou à partir
d’une interface réseau. Vous pouvez utiliser la vérification de flux IP pour déterminer si
une communication est autorisée ou refusée. En outre, utilisez la vérification du flux IP
pour faire apparaître l’identité de la règle de sécurité réseau responsable de
l’autorisation ou du refus du trafic.
７ Notes
Les groupes de sécurité réseau sont associés à des sous-réseaux ou à des machines
virtuelles et services cloud déployés dans le modèle de déploiement classique, et à
des sous-réseaux ou des interfaces réseau dans le modèle de déploiement
Resource Manager. Pour en savoir plus sur les modèles de déploiement Azure,
consultez l’article Déploiement Azure Resource Manager et déploiement
classique : comprendre les modèles de déploiement et l’état de vos ressources.
 Conseil
Sauf si vous avez une raison particulière, nous vous recommandons d’associer un
groupe de sécurité réseau à un sous-réseau ou à une interface réseau, mais pas aux
deux. Dans la mesure où les règles d’un groupe de sécurité réseau associées à un
sous-réseau peut entrer en conflit avec des règles d’un groupe de sécurité réseau
associées à une interface réseau, vous pourrez subir des problèmes de
communication inattendus qui nécessiteront une intervention.
Étapes suivantes
Pour en savoir plus sur les ressources Azure pouvant être déployées dans un
réseau virtuel et auxquelles des groupes de sécurité réseau peuvent être associées,
consultez Intégration d’un réseau virtuel pour les services Azure.
Si vous n’avez jamais créé un groupe de sécurité réseau, vous pouvez suivre un
tutoriel rapide pour vous entraîner.
Si vous êtes familier avec les groupes de sécurité réseau et que vous devez en
gérer un, consultez Gérer un groupe de sécurité réseau.
Si vous rencontrez des problèmes de communication et que vous avez besoin

résoudre les problèmes de groupes de sécurité réseau, consultez Diagnostiquer un
problème de filtre de trafic réseau sur une machine virtuelle.
Découvrez comment activer les journaux de flux de groupe de sécurité réseau pour
analyser le trafic réseau vers et à partir des ressources auxquelles un groupe de
sécurité réseau est associé.
Article • 17/04/2023
Les groupes de sécurité d’application permettent de configurer la sécurité réseau

comme un prolongement naturel de la structure de l’application, et donc de regrouper
les machines virtuelles et définir des stratégies de sécurité réseau basés sur ces groupes.
Vous pouvez réutiliser votre stratégie de sécurité à grande échelle sans maintenance
manuelle d’adresses IP explicites. La plateforme gère la complexité des adresses IP
explicites et plusieurs ensembles de règles, ce qui vous permet de vous concentrer sur la
logique métier. Pour mieux comprendre les groupes de sécurité d’application, prenons
l’exemple suivant :
Dans l’image précédente, NIC1 et NIC2 sont membres du groupe de sécurité

d’application AsgWeb. NIC3 est un membre du groupe de sécurité d’application
AsgLogic. NIC4 est un membre du groupe de sécurité d’application AsgDb. Bien que
chaque interface réseau (NIC) dans cet exemple soit membre d’un seul groupe de
sécurité réseau, une interface réseau peut être membre de plusieurs groupes de sécurité
d’application, dans le respect des limites Azure. Aucune de ces interfaces réseau ne
dispose d’un groupe de sécurité réseau associé. NSG1 est associé aux deux sous-réseaux
et contient les règles suivantes :
Allow-HTTP-Inbound-Internet
Cette règle est nécessaire pour autoriser le trafic internet vers les serveurs web. Étant
donné que le trafic entrant à partir d’Internet est refusé par la règle de sécurité par
défaut DenyAllInbound, aucune règle supplémentaire n’est nécessaire pour les groupes
de sécurité d’application AsgLogic ou AsgDb.
100 Internet * AsgWeb 80 TCP Allow
Deny-Database-All
Étant donné que la règle de sécurité par défaut AllowVNetInBound autorise toutes les
communications entre les ressources dans le même réseau virtuel, cette règle est
nécessaire pour refuser le trafic à partir de toutes les ressources.
120 * * AsgDb 1433 Quelconque Deny
Allow-Database-BusinessLogic
Cette règle autorise le trafic du groupe de sécurité d’application AsgLogic vers le groupe
de sécurité d’application AsgDb. Cette règle est prioritaire par rapport à la règle Deny-
Database-All. Par conséquent, cette règle est traitée avant la règle Deny-Database-All,
c’est pourquoi le trafic en provenance du groupe de sécurité d’application AsgLogic est
autorisé, tandis que tout autre trafic est bloqué.
Priority Source Ports Destination Ports de destination Protocol Accès

source
110 AsgLogic * AsgDb 1433 TCP Autoriser
Les interfaces réseau membres du groupe de sécurité d’application appliquent les règles
qui les spécifient comme source ou destination. Les règles n’affectent pas les autres
interfaces réseau. Si l’interface réseau n’est pas membre d’un groupe de sécurité
d’application, la règle n’est pas appliquée à l’interface réseau, même si le groupe de
sécurité réseau est associé au sous-réseau.
Les groupes de sécurité d’application ont les contraintes suivantes :
Le nombre de groupes de sécurité d’application que vous pouvez avoir dans un

abonnement, ainsi que d’autres paramètres relatifs aux groupes de sécurité
d’application, sont limités. Pour plus d’informations, consultez limites Azure.
Toutes les interfaces réseau affectées à un groupe de sécurité d’application doivent

exister dans le même réseau virtuel que celui où se trouve la première interface
réseau affectée au groupe de sécurité d’application. Par exemple, si la première
interface réseau assignée à un groupe de sécurité d’application nommé AsgWeb se
trouve dans le réseau virtuel nommé VNet1, toutes les interfaces réseau suivantes
affectées àAsgWeb doivent exister dans VNet1. Vous ne pouvez pas ajouter
d’interfaces réseau à partir de différents réseaux virtuels au même groupe de
Si vous spécifiez un groupe de sécurité d’application en tant que source et

destination dans une règle de sécurité, les interfaces réseau dans les deux groupes
de sécurité d’application doivent se trouver dans le même réseau virtuel.
Exemple : AsgLogic a des interfaces réseau de VNet1 et AsgDb a des interfaces
réseau de VNet2. Dans ce cas, il serait impossible de désigner AsgLogic comme
source et AsgDb comme destination dans une règle. Toutes les interfaces réseau
pour les groupes de sécurité d’application source et destination doivent exister
dans le même réseau virtuel.
 Conseil
Pour réduire le nombre de règles de sécurité dont vous avez besoin et la nécessité
de modifier les règles, planifiez les groupes de sécurité d’application dont vous
avez besoin et créez des règles à l’aide de balises de service ou des groupes de
sécurité d’application, plutôt que des adresses IP individuelles ou des plages
d’adresses IP, chaque fois que c’est possible.
Étapes suivantes
Balises de service du réseau virtuel
donné. Microsoft gère les préfixes d’adresses englobés par l’étiquette de service et met à jour
automatiquement l’étiquette de service quand les adresses changent, ce qui réduit la
complexité des mises à jour fréquentes relatives aux règles de sécurité réseau.
Vous pouvez utiliser des balises de service pour définir des contrôles d'accès au réseau sur les
groupes de sécurité du réseau, Pare-feu Azure et les routes définies par l'utilisateur. Utilisez
des balises de service à la place d'adresses IP spécifiques lorsque vous créez des règles de
sécurité et des routes. En spécifiant le nom de l’étiquette de service (par exemple,
ApiManagement dans le champ Source ou Destination d’une règle, vous pouvez autoriser ou
refuser le trafic pour le service correspondant. En spécifiant le nom de la balise de service
dans le préfixe d’adresse d’une route, vous pouvez acheminer le trafic destiné à l’un des
préfixes encapsulés par la balise de service vers un type de tronçon suivant souhaité.
７ Notes
À compter de mars 2022, l’utilisation de balises de service à la place de préfixes

d’adresses explicites dans les itinéraires définis par l’utilisateur est hors préversion et
généralement disponible.
Vous pouvez utiliser des étiquettes de service pour isoler le réseau et protéger vos ressources
Azure de l’accès Internet général tout en accédant aux services Azure qui ont des points de
terminaison publics. Créez des règles de groupe de sécurité de réseau entrant/sortant pour
refuser le trafic vers/depuis Internet et autoriser le trafic vers/depuis AzureCloud ou d’autres
balises de service disponibles de services Azure spécifiques.
Balises de service disponibles
Le tableau suivant répertorie les balises de service disponibles à utiliser dans les règles
Groupes de sécurité réseau.
Les colonnes indiquent si la balise :
Est adaptée aux règles couvrant le trafic entrant ou sortant.

Prend en charge l’étendue régionale .
Est utilisable dans les règles dePare-feu Azure en tant que règle de destination
uniquement pour le trafic entrant ou sortant.
Par défaut, les balises de service reflètent les plages pour l’ensemble du Cloud. Certaines
balises de service permettent également d’obtenir un contrôle plus précis en limitant les
plages d’adresses IP correspondantes à une région spécifiée. Par exemple, la balise de service
Storage représente le Stockage Azure pour l’ensemble du cloud, alors que Storage.WestUS
limite la sélection aux plages d’adresses IP de stockage de la région WestUS. Le tableau
suivant indique si chaque étiquette de service prend en charge une telle étendue régionale, et
la direction indiquée pour chaque balise est une recommandation. Par exemple, l’étiquette
AzureCloud peut être utilisée pour autoriser le trafic entrant. Dans la plupart des scénarios,
nous vous déconseillons d’autoriser le trafic à partir de toutes les adresses IP Azure, car les
adresses IP utilisées par d’autres clients Azure sont incluses dans le cadre de la balise de
service.
Tag Objectif Peut-elle Peut-elle Peut-
utiliser être elle
le trafic étendue à être
entrant une zone utilisée
ou régionale ? avec le
sortant ? Pare-
feu
Azure
?
ActionGroup Groupe d’actions. Trafic Non Oui

entrant
ApiManagement Trafic de gestion pour les Trafic Oui Oui

déploiements dédiés de Gestion entrant
des API.

terminaison du service Gestion
des API Azure pour le plan de
contrôle par région. La balise
permet aux clients d’effectuer
des opérations de gestion sur
les API, les opérations, les
stratégies et les valeurs
nommées configurées sur le
service Gestion des API.
ApplicationInsightsAvailability Disponibilité d’Application Trafic Non Oui

Insights. entrant
AppConfiguration App Configuration. Règle de Non Oui

trafic
sortant
AppService Azure App Service Cette balise Règle de Oui Oui

est recommandée pour les trafic
règles de sécurité sortantes vers sortant
les applications web et les
applications de fonction.
Remarque : Cette balise n’inclut

pas les adresses IP attribuées
quand le protocole SSL basé
sur IP (adresse attribuée par
l’application) est utilisé.
AppServiceManagement Trafic de gestion pour les Les deux Non Oui

déploiements dédiés vers App
Service Environment.
AutonomousDevelopmentPlatform Plateforme de développement Les deux Oui Oui
autonome
AzureActiveDirectory Azure Active Directory Règle de Non Oui

trafic
sortant
AzureActiveDirectoryDomainServices Trafic de gestion pour les Les deux Non Oui

déploiements dédiés vers Azure
Active Directory Domain
Services.
AzureAdvancedThreatProtection Azure Advanced Threat Règle de Non Oui

Protection. trafic
sortant
AzureArcInfrastructure Serveurs Azure Arc, Kubernetes Règle de Non Oui

avec Azure Arc et trafic Guest trafic
Configuration. sortant
Remarque : cette étiquette a

une dépendance vis-à-vis des
étiquettes
AzureTrafficManager et
AzureResourceManager.
AzureAttestation Azure Attestation. Règle de Non Oui

trafic
sortant
AzureBackup Sauvegarde Azure. Règle de Non Oui

trafic
rapport aux étiquettes Storage
et AzureActiveDirectory.
AzureBotService Service Azure Bot. Règle de Non Oui

trafic
sortant
AzureCloud Toutes les adresses IP publiques Les deux Oui Oui
du centre de données .
AzureCognitiveSearch Recherche cognitive Azure. Trafic Non Oui

entrant
Cette balise ou les adresses IP
qu’elle couvre permettent
d’accorder aux indexeurs un
accès sécurisé à des sources de
données. Pour plus
d’informations sur les indexeurs,
consultez la documentation de
connexion de l’indexeur.
Remarque : L’adresse IP du
service de recherche n’est pas
incluse dans la liste des plages
d’adresses IP pour cette
étiquette de service et doit
également être ajoutée au
pare-feu IP des sources de
données.
AzureConnectors Cette étiquette représente les Les deux Oui Oui

adresses IP utilisées pour les
connecteurs managés qui
effectuent des rappels de
webhook entrants vers le
service Azure Logic Apps et des
appels sortants vers leurs
services respectifs, par exemple,
Stockage Azure ou Azure Event
Hubs.
AzureContainerAppsService Service Azure Container Apps Les deux Oui Non
AzureContainerRegistry Azure Container Registry. Règle de Oui Oui

trafic
sortant
AzureCosmosDB Azure Cosmos DB. Règle de Oui Oui

trafic
sortant
AzureDatabricks Azure Databricks. Les deux Non Oui
AzureDataExplorerManagement Gestion d’Azure Data Explorer. Trafic Non Oui

entrant
AzureDataLake Azure Data Lake Storage Gen1. Règle de Non Oui

trafic
sortant
AzureDeviceUpdate Device Update pour IoT Hub. Les deux Non Oui
AzureDevSpaces Azure Dev Spaces. Règle de Non Oui

trafic
sortant
AzureDevOps Azure DevOps. Trafic Oui Oui

entrant
AzureDigitalTwins Azure Digital Twins. Trafic Non Oui

entrant
Remarque : Cette étiquette et
les adresses IP qu’elle couvre
peuvent être utilisées pour
restreindre l’accès aux points de
terminaison configurés pour des
routes d’événements.
AzureEventGrid Azure Event Grid. Les deux Non Oui
AzureFrontDoor.Frontend Azure Front Door. Les deux Oui Oui

AzureFrontDoor.Backend
AzureFrontDoor.FirstParty
AzureHealthcareAPIs Les adresses IP couvertes par Les deux Non Oui

cette étiquette peuvent être
à Azure Health Data Services.
AzureInformationProtection Azure Information Protection. Règle de Non Oui
trafic
AzureIoTHub Azure IoT Hub. Règle de Oui Oui

trafic
sortant
AzureKeyVault Azure Key Vault. Règle de Oui Oui

trafic
AzureLoadBalancer Équilibrage de charge de Les deux Non Non

l’infrastructure Azure. Elle est
translatée vers l’adresse IP
virtuelle de l’hôte
(168.63.129.16) d’où
proviennent les sondes
d’intégrité d’Azure. Cela
comprend uniquement le trafic
de sondes, et non le trafic réel
vers votre ressource principale.
Vous pouvez remplacer cette
règle si vous n’utilisez pas
l’équilibreur de charge Azure.
AzureLoadTestingInstanceManagement Cette étiquette de service est Trafic Non Oui
utilisée pour la connectivité entrant
entrante du service Test de
charge Azure vers les instances
de génération de charge
injectées dans votre réseau
virtuel dans le scénario de test
de charge privé.
Remarque : Cette étiquette est

destinée à être utilisée dans le
Pare-feu Azure, les groupes de
sécurité réseau, les itinéraires
définis par l’utilisateur et toutes
les autres passerelles pour la
connectivité entrante.
AzureMachineLearning Azure Machine Learning. Les deux Non Oui
AzureMonitor Métriques Log Analytics, Règle de Non Oui

Application Insights, AzMon et trafic
métriques personnalisées sortant
(points de terminaison GiG).
Remarque : pour Log Analytics,

l’étiquette Storage est
également nécessaire. Si des
agents Linux sont utilisés,
l’étiquette
est également nécessaire.
AzureOpenDatasets Azure Open Datasets. Règle de Non Oui

trafic
Storage.
AzurePlatformDNS Service DNS de l’infrastructure Règle de Non Non
de base (par défaut). trafic
sortant
pour désactiver le DNS par
défaut. Utilisez cette balise avec
prudence. Nous vous
Azure. Nous vous
AzurePlatformIMDS Azure Instance Metadata Règle de Non Non

Service (IMDS), qui est un trafic
service d’infrastructure de base. sortant

pour désactiver le point de
terminaison IMDS par défaut.
Utilisez cette balise avec
prudence. Nous vous
Azure. Nous vous
AzurePlatformLKM Gestionnaire de licences Règle de Non Non
Windows ou service de gestion trafic
de clés. sortant

pour désactiver les paramètres
par défaut des licences. Utilisez
cette balise avec prudence.
Nous vous recommandons de
lire les considérations sur la
plateforme Azure. Nous vous
AzureResourceManager Azure Resource Manager. Règle de Non Oui

trafic
sortant
AzureSentinel Microsoft Sentinel. Trafic Oui Oui

entrant
AzureSignalR Azure SignalR. Règle de Non Oui

trafic
sortant
AzureSiteRecovery Azure Site Recovery. Règle de Non Oui

trafic
AzureKeyVault, EventHub,
et Storage.
AzureSphere Cette étiquette et les adresses Les deux Non Oui

aux services de sécurité Azure
Sphere.
AzureSpringCloud Autoriser le trafic vers les Règle de Non Oui
applications hébergées dans trafic
Azure Spring Apps. sortant
AzureStack Services Azure Stack Bridge. Règle de Non Oui

Cette étiquette représente le trafic
point de terminaison de service sortant
Azure Stack Bridge par région.
AzureTrafficManager Adresses IP de sonde Azure Trafic Non Oui

Traffic Manager. entrant
Pour plus d’informations sur les

adresses IP de sondage Traffic
Manager, consultez les
Questions fréquentes (FAQ) sur
Azure Traffic Manager.
AzureUpdateDelivery Pour accéder aux mises à jour Règle de Non Oui

de Windows. trafic
sortant
permet d’accéder aux services
de métadonnées Windows
Update. Pour télécharger les
mises à jour avec succès, vous
devez également activer la
balise de service
AzureFrontDoor.FirstParty et
configurer les règles de sécurité
de trafic sortant avec le
protocole et le port définis,
comme suit :
AzureUpdateDelivery:
TCP, port 443
AzureFrontDoor.FirstParty:
TCP, port 80
AzureWebPubSub AzureWebPubSub Les deux Oui Oui

BatchNodeManagement Trafic de gestion pour les Les deux Oui Oui
déploiements dédiés d’Azure
Batch.
ChaosStudio Azure Chaos Studio. Les deux Oui Oui
Remarque : Si vous avez activé

l’intégration d’Application
Insights sur Chaos Agent, la
balise AzureMonitor est
également requise.
CognitiveServicesFrontend Les plages d’adresses pour le Les deux Non Oui

trafic destiné aux portails du
front-end Cognitive Services.
CognitiveServicesManagement Plages d’adresses du trafic pour Les deux Non Oui

Azure Cognitive Services.
DataFactory Azure Data Factory Les deux Non Oui
DataFactoryManagement Trafic de gestion pour Azure Règle de Non Oui

Data Factory. trafic
sortant
Dynamics365ForMarketingEmail Plages d’adresses pour le Les deux Oui Oui

service de messagerie
marketing de Dynamics 365.
Dynamics365BusinessCentral Cette étiquette et les adresses Les deux Non Oui

de/à Dynamics 365 Business
Central Services.
EOPExternalPublishedIPs Cette étiquette représente les Les deux Non Oui
adresses IP utilisées pour le
Centre de sécurité et de
conformité PowerShell. Pour
plus d’informations, consultez
Se connecter au Centre de
sécurité et de conformité
PowerShell à l’aide du module
EXO V2.
EventHub Azure Event Hubs. Règle de Oui Oui

trafic
sortant
GatewayManager Trafic de gestion pour les Trafic Non Non

déploiements dédiés à la entrant
passerelle VPN Azure et
GuestAndHybridManagement Azure Automation et Guest Règle de Non Oui

Configuration. trafic
sortant
HDInsight Azure HDInsight Trafic Oui Oui

entrant
Internet Espace d’adresse IP qui se Les deux Non Non

trouve en dehors du réseau
virtuel et est accessible sur les
réseaux Internet publics.
La plage d’adresse inclut

l’espace de l’adresse IP public
d’Azure .
LogicApps Logic Apps. Les deux Non Oui
LogicAppsManagement Trafic de gestion pour Logic Trafic Non Oui

Apps. entrant
Place de marché Représente la suite complète Les deux Non Oui
des services « Expériences de la
Place de marché commerciale »
Azure.
M365ManagementActivityApi L’API Activité de gestion Règle de Oui Oui

Office 365 fournit des trafic
informations sur différentes sortant
actions et événements
d’utilisateurs, d’administrateurs,
de système et de stratégies à
partir des journaux d’activités
Office 365 et Azure Active
Directory. Les clients et
partenaires peuvent utiliser ces
informations pour créer ou
améliorer des solutions de
monitoring de la conformité,
d’opérations et de sécurité
existantes.

M365ManagementActivityApiWebhook Des notifications sont envoyées Trafic Oui Oui

au webhook configuré pour un entrant
abonnement lors de la mise à
disposition de nouveau
contenu.
MicrosoftAzureFluidRelay Cette étiquette représente les Règle de Non Oui

adresses IP utilisées pour Azure trafic
Microsoft Fluid Relay Server. sortant
MicrosoftCloudAppSecurity Applications Microsoft Defender Règle de Non Oui

pour le cloud. trafic
sortant
MicrosoftContainerRegistry Registre de conteneurs pour les Règle de Oui Oui
images de conteneur Microsoft. trafic
sortant
MicrosoftDefenderForEndpoint Microsoft Defender for Les deux Non Oui

Endpoint
Notez que cette étiquette de

service n’est actuellement pas
disponible et en cours de
développement. Nous
procéderons à la mise à jour
une fois qu’elle sera prête à
être utilisée.
PowerBI Power BI. Les deux Non Oui
PowerPlatformInfra Cette étiquette représente les Règle de Oui Oui

adresses IP utilisées par trafic
l’infrastructure pour héberger sortant
les services Power Platform.
PowerPlatformPlex Cette étiquette représente les Trafic Oui Oui

adresses IP utilisées par entrant
l’infrastructure pour héberger
l’exécution de l’extension Power
Platform pour le compte du
client.
PowerQueryOnline Power Query en ligne. Les deux Non Oui
ServiceBus Trafic Azure Service Bus qui Règle de Oui Oui

utilise le niveau de service trafic
Premium. sortant
ServiceFabric Azure Service Fabric. Les deux Non Oui

terminaison du service Service
Fabric pour le plan de contrôle
par région. Ceci permet aux
clients d’effectuer des
opérations de gestion pour
leurs clusters Service Fabric à
partir de leur réseau virtuel. (Par
exemple https://
westus.servicefabric.azure.com).
Sql Azure SQL Database, Azure Règle de Oui Oui

Database pour MySQL, Azure trafic
Database pour PostgreSQL, sortant
Azure Database for MariaDB et
Azure Synapse Analytics.

représente le service Azure SQL
Database, mais pas une base de
données ou un serveur SQL
spécifique. Cette balise ne
s’applique pas à l’Instance gérée
SQL.
SqlManagement Trafic de gestion pour les Les deux Non Oui

déploiements dédiés de SQL.
Stockage Stockage Azure. Règle de Oui Oui
trafic
Remarque : cette étiquette sortant
représente le service Azure
Storage, mais pas un compte
Azure Storage spécifique.
StorageSyncService Service de synchronisation du Les deux Non Oui

stockage.
WindowsAdminCenter Autoriser le service principal du Règle de Non Oui

Centre d’administration trafic
Windows à communiquer avec sortant
l’installation des clients du
Centre d’administration
Windows.
WindowsVirtualDesktop Azure Virtual Desktop Les deux Non Oui

(anciennement Microsoft Virtual
Desktop).
VirtualNetwork L’espace d’adressage du réseau Les deux Non Non

virtuel (toutes les plages
d’adresses IP définies pour le
réseau virtuel), tous les espaces
d’adressage locaux connectés,
les réseaux virtuels appairés ou
connectés à une passerelle de
réseau virtuel, l’adresse IP
virtuelle de l’hôte et les préfixes
d’adresse utilisés sur les routes
définies par l’utilisateur. Cette
balise peut également contenir
des itinéraires par défaut.
７ Notes
Lorsque vous utilisez des balises de service avec le Pare-feu Azure, vous pouvez
uniquement créer des règles de destination sur le trafic entrant et sortant. Les
règles sources ne sont pas prises en charge. Pour plus d’informations, consultez la
documentation Balises de service du Pare-feu Azure .
Les balises des services Azure indiquent les préfixes d’adresse du cloud spécifique
utilisé. Par exemple, les plages IP sous-jacentes qui correspondent à la valeur de
balise Sql sur le cloud public Azure seront différentes des plages sous-jacentes sur
le cloud Azure Chine.
Si vous implémentez un point de terminaison de service de réseau virtuel pour un

service, par exemple Stockage Azure ou Azure SQL Database, Azure ajoute un
itinéraire vers un sous-réseau de réseau virtuel pour le service. Les préfixes
d’adresse de l’itinéraire sont les mêmes préfixes d’adresse ou plages CIDR que pour
la balise de service correspondante.
Étiquettes prises en charge dans le modèle de déploiement

classique
Le modèle de déploiement classique (antérieur à Azure Resource Manager) prend en charge
un petit sous-ensemble des étiquettes répertoriées dans le tableau précédent. Les étiquettes
dans le modèle de déploiement classique sont orthographiées différemment, comme indiqué
dans le tableau suivant :
Étiquette Resource Manager Étiquette correspondante dans le modèle de déploiement classique
AzureLoadBalancer AZURE_LOADBALANCER
Internet INTERNET
VirtualNetwork VIRTUAL_NETWORK
Balises de service locales

Vous pouvez obtenir la balise de service et les informations de plage actuelles à inclure dans
le cadre de vos configurations du pare-feu local. Ces informations forment la liste actuelle des
plages d’adresses IP qui correspondent à chaque balise de service. Vous pouvez obtenir les
informations par programmation ou par le biais d’un téléchargement de fichier JSON, comme
décrit dans les sections suivantes.
Utiliser l’API Service Tag Discovery

Vous pouvez récupérer par programmation la liste actuelle des balises de service ainsi que les
informations relatives aux plages d’adresses IP :
REST
Azure PowerShell
Azure CLI
Par exemple, pour récupérer tous les préfixes de l’étiquette de service Stockage, vous pouvez
utiliser les applets de commande PowerShell suivantes :
Azure PowerShell
$serviceTags = Get-AzNetworkServiceTag -Location eastus2

$storage = $serviceTags.Values | Where-Object { $_.Name -eq "Storage" }
$storage.Properties.AddressPrefixes
７ Notes
Les données d’API représentent les étiquettes qui peuvent être utilisées avec les
règles de groupe de sécurité réseau dans votre région. Utilisez les données d’API
comme source de vérité pour les étiquettes de service disponibles, car elles peuvent
être différentes du fichier téléchargeable JSON.
La propagation des nouvelles données d’étiquette de service dans les résultats de
l’API de toutes les régions Azure prend jusqu’à 4 semaines. En raison de ce
processus, les résultats de vos données d’API peuvent ne pas être synchronisés avec
le fichier JSON téléchargeable, car les données d’API représentent un sous-
ensemble des étiquettes actuellement contenues dans le fichier JSON
téléchargeable.
Vous devez être authentifié et disposer d’un rôle avec des autorisations de lecture
pour votre abonnement actuel.
Détection de balises de service à l’aide de fichiers JSON

téléchargeables
Vous pouvez télécharger des fichiers JSON qui contiennent la liste actuelle des balises de
service avec les informations relatives aux plages d’adresses IP. Ces listes sont mises à jour et
publiées chaque semaine. Les emplacements de chaque Cloud sont :
Azure public
Azure US Government
Azure China 21Vianet
Azure Allemagne
Les plages d’adresses IP de ces fichiers sont en notation CIDR.
Les étiquettes AzureCloud suivantes n’ont pas de noms régionaux formatés selon le schéma
normal :
AzureCloud.centralfrance (FranceCentral)
AzureCloud.southfrance (FranceSouth)
AzureCloud.germanywc (GermanyWestCentral)
AzureCloud.germanyn (GermanyNorth)
AzureCloud.norwaye (NorwayEast)
AzureCloud.norwayw (NorwayWest)
AzureCloud.switzerlandn (SwitzerlandNorth)
AzureCloud.switzerlandw (SwitzerlandWest)
AzureCloud.usstagee (EastUSSTG)
AzureCloud.usstagec (SouthCentralUSSTG)
７ Notes
Un sous-ensemble de ces informations a été publié dans des fichiers XML pour Azure
public , Azure Chine et Azure Allemagne . Ces téléchargements XML seront
obsolètes à compter du 30 juin 2020 et ne seront plus disponibles après cette date. Vous
devez effectuer une migration à l’aide de l’API Discovery ou des téléchargements de
fichiers JSON, comme décrit dans les sections précédentes.
 Conseil
Vous pouvez détecter les mises à jour d’une publication à l’autre en notant les
valeurs changeNumber augmentées dans le fichier JSON. Chaque sous-section (par
exemple, Storage.WestUS) a sa propre valeur changeNumber qui est incrémentée
au fur et à mesure que des modifications sont effectuées. Le niveau supérieur de la
valeur changeNumber du fichier est incrémenté lorsque l’une des sous-sections est
modifiée.
Pour obtenir des exemples d’analyse des informations de balise de service (par
exemple, obtenir toutes les plages d’adresses pour le stockage dans la région
WestUS), reportez-vous à la documentation relative à l’API Service Tag Discovery
PowerShell.
Lorsque de nouvelles adresses IP sont ajoutées aux étiquettes de service, elles ne

sont pas utilisées dans Azure pendant au moins une semaine. Cela vous donne le
temps de mettre à jour les systèmes qui peuvent avoir besoin d’effectuer le suivi
des adresses IP associées aux balises de service.
Étapes suivantes
Stratégies de points de terminaison de
service de réseau virtuel pour le
stockage Azure
Article • 17/04/2023
Les stratégies de points de terminaison de service de réseau virtuel permettent de filtrer

le trafic de réseau virtuel sortant vers les comptes de stockage Azure sur le point de
terminaison de service et d’exfiltrer des données uniquement vers des comptes de
stockage Azure spécifiques. Les stratégies de points de terminaison fournissent un
contrôle d’accès précis pour le trafic de réseau virtuel vers Stockage Azure lors de la
connexion via le point de terminaison de service.
Cette fonctionnalité est généralement disponible pour le stockage Azure dans toutes
les régions Azure à l’échelle internationale.
Les stratégies de point de terminaison de service de réseau virtuel offrent les avantages
suivants :
Sécurité renforcée pour votre trafic de réseau virtuel vers Stockage Azure
Les étiquettes de service Azure pour les groupes de sécurité réseau vous
permettent de restreindre le trafic sortant du réseau virtuel vers des régions de
stockage Azure spécifiques. Toutefois, ce processus autorise le trafic vers n’importe
quel compte au sein de la région de stockage Azure sélectionnée.
Les stratégies de points de terminaison vous permettent de spécifier les comptes

de stockage Azure qui bénéficient d’un accès sortant du réseau virtuel et limitent
l’accès à tous les autres comptes de stockage. Il apporte un contrôle de sécurité
beaucoup plus précis pour la protection de l’exfiltration de données à partir de
Stratégies évolutives et hautement disponibles pour filtrer le trafic de service

Azure
Les stratégies de point de terminaison fournissent une solution évolutive

horizontalement et hautement disponible pour filtrer le trafic de service Azure à
partir de réseaux virtuels, sur les points de terminaison de service. Aucun temps
système supplémentaire n’est nécessaire afin de maintenir les appliances réseau
centrales pour ce trafic sur vos réseaux virtuels.
Objet JSON pour les stratégies de points de

terminaison de service
Examinons rapidement l’objet de stratégie de point de terminaison de service.
JSON
"serviceEndpointPolicyDefinitions": [
{
"description": null,
"name": "MySEP-Definition",
"resourceGroup": "MySEPDeployment",
"service": "Microsoft.Storage",
"serviceResources": [
"/subscriptions/subscriptionID/resourceGroups/MySEPDeployment/providers/Micr
osoft.Storage/storageAccounts/mystgacc"
],
"type":
"Microsoft.Network/serviceEndpointPolicies/serviceEndpointPolicyDefinitions"
}
]
Configuration
Vous pouvez configurer les stratégies de points de terminaison pour limiter le
trafic de réseau virtuel à des comptes de stockage Azure spécifiques.
La stratégie de point de terminaison de service est configurée sur un sous-réseau

dans un réseau virtuel. Les points de terminaison de service pour le stockage Azure
doivent être activés sur le sous-réseau afin d’appliquer la stratégie.
La règle des points de terminaison vous permet d’ajouter des comptes de stockage
Azure spécifiques à la liste d’autorisation à l’aide du format resourceId. Vous
pouvez restreindre l'accès à :
Tous les comptes de stockage d’un abonnement

E.g. /subscriptions/subscriptionId
Tous les comptes de stockage d’un groupe de ressources

E.g. subscriptions/subscriptionId/resourceGroups/resourceGroupName
Un compte de stockage individuel (en listant le resourceId Azure Resource

Manager correspondant). Cela concerne le trafic vers les objets blob, les tables,
les files d’attente, les fichiers et Azure Data Lake Storage Gen2.
E.g.
/subscriptions/subscriptionId/resourceGroups/resourceGroupName/providers/Mi
crosoft.Storage/storageAccounts/storageAccountName
Par défaut, si aucune stratégie n’est attachée à un sous-réseau avec des points de
terminaison, vous pouvez accéder à tous les comptes de stockage du service. Une
fois qu’une stratégie est configurée sur ce sous-réseau, seules les ressources
spécifiées dans la stratégie sont accessibles à partir d’instances de calcul dans ce
sous-réseau. L’accès à tous les autres comptes de stockage est refusé.
Lorsque vous appliquez des stratégies de points de terminaison de service à un

sous-réseau, l’étendue du point de terminaison de service de stockage Azure est
mise à niveau de régionale vers mondiale. Ce processus signifie que tout le trafic
vers le stockage Azure est sécurisé par la suite sur le point de terminaison de
service. Les stratégies de points de terminaison de service sont également
applicables à l’échelle mondiale. Tous les comptes de stockage qui ne sont pas
explicitement autorisés se voient refuser l’accès.
Vous pouvez appliquer plusieurs stratégies à un sous-réseau. Lorsque plusieurs

stratégies sont associées au sous-réseau, le trafic de réseau virtuel vers les
ressources spécifiées dans toutes ces stratégies est autorisé. L’accès à toutes les
autres ressources de service, qui ne sont pas spécifiées dans ces stratégies, est
refusé.
７ Notes
Les stratégies de points de terminaison de service étant des stratégies

d’autorisation, à part les ressources spécifiées, toutes les autres ressources sont
limitées. Vérifiez que toutes les dépendances de ressource de service pour vos
applications sont identifiées et listées dans la stratégie.
Seuls les comptes de stockage utilisant le modèle de ressource Azure peuvent être
spécifiés dans la stratégie de point de terminaison. Les comptes de stockage Azure
classiques ne prennent pas en charge les stratégies de points de terminaison de
service Azure.
L’accès secondaire RA-GRS est automatiquement autorisé si le compte principal

est répertorié.
Les comptes de stockage peuvent se trouver dans le même abonnement, dans un

autre abonnement ou dans le locataire Azure Active Directory en tant que réseau
virtuel.
Scénarios
Réseaux virtuels appairés, connectés ou multiples : Pour filtrer le trafic dans des
réseaux virtuels appairés, les stratégies de point de terminaison doivent leur être
appliquées individuellement.
Filtrage du trafic Internet avec des appliances réseau ou le Pare-feu Azure :

Filtrez le trafic du service Azure avec des stratégies, sur les points de terminaison
de service et filtrez le reste du trafic Internet ou Azure par le biais d’appliances ou
du pare-feu Azure.
Filtrage du trafic sur les services Azure déployés dans les réseaux virtuels : pour
l'instant, les stratégies de points de terminaison du service Azure ne sont pas prises
en charge pour les services Azure gérés qui sont déployés dans votre réseau
virtuel.
Filtrage du trafic local vers les services Azure : Les stratégies de point de
terminaison de service s’appliquent uniquement au trafic en provenance des sous-
réseaux associés aux stratégies. Pour autoriser l’accès à des ressources de service
Azure spécifiques en local, le trafic doit être filtré à l’aide d’appliances de réseau
virtuel ou de pare-feu.
Journalisation et résolution des problèmes
Aucun enregistrement centralisé n’est disponible pour les stratégies de point de
terminaison de service. Pour les journaux de ressources de service, consultez
Journalisation des points de terminaison de service.
Scénarios de résolution des problèmes

Accès refusé aux comptes de stockage qui fonctionnaient dans la préversion (et
non dans la région géographiquement associée)
Avec la mise à niveau du stockage Azure pour utiliser des balises de service
global, l’étendue du point de terminaison de service et, par conséquent, les
stratégies de points de terminaison de service sont désormais globales. Ainsi,
tout le trafic vers le stockage Azure est chiffré sur les points de terminaison de
service et l’accès est autorisé uniquement aux comptes de stockage qui sont
explicitement listés dans la stratégie.
Établissez explicitement une liste d’autorisation de tous les comptes de

stockage requis pour restaurer l’accès.
Contactez le support Azure.
L’accès est refusé aux comptes répertoriés dans les stratégies de point de
terminaison
Le filtrage des groupes de sécurité réseau ou du pare-feu peut bloquer l’accès
Si la suppression/nouvelle application de la stratégie entraîne la perte de la

connectivité :
Vérifiez que le service Azure est configuré pour autoriser l’accès à partir du
réseau virtuel sur les points de terminaison, ou que la stratégie par défaut
pour la ressource est définie sur Allow All (Tout autoriser).
Vérifiez que les diagnostics de service affichent le trafic sur les points de
terminaison.
Vérifiez si les journaux de flux de groupe de sécurité réseau affichent l’accès

et si les journaux d’activité de stockage affichent l’accès, comme prévu, sur
les points de terminaison de service.
Contactez le support Azure.

L’accès est refusé aux comptes non répertoriés dans les stratégies de point de
terminaison de service
Vérifiez que le stockage Azure est configuré pour autoriser l’accès à partir du
réseau virtuel sur les points de terminaison, ou que la stratégie par défaut pour
la ressource est définie sur Allow All (Tout autoriser).
Vérifiez que les comptes ne sont pas des comptes de stockage classiques avec
les stratégies de points de terminaison de service sur le sous-réseau.
Un service Azure managé a cessé de fonctionner après l’application d’une stratégie

de point de terminaison de service sur le sous-réseau
Les services gérés autres qu’Azure SQL Managed Instance ne sont actuellement
pas pris en charge avec les points de terminaison de service.
L’accès aux comptes de stockage gérés a cessé de fonctionner après l’application

d’une stratégie de point de terminaison de service sur le sous-réseau
Les comptes de stockage gérés ne sont pas pris en charge avec les stratégies de
points de terminaison de service. Si les stratégies sont configurées, l’accès à
tous les comptes de stockage gérés est refusé par défaut. Si votre application
doit accéder à des comptes de stockage gérés, les stratégies de point de
terminaison ne doivent pas être utilisées pour ce trafic.
Approvisionnement
Un utilisateur avec accès en écriture à un réseau virtuel configure les stratégies de point
de terminaison de service sur les sous-réseaux. En savoir plus sur les rôles intégrés Azure
et l’assignation d’autorisations spécifiques aux rôles personnalisés.
Les réseaux virtuels et les comptes de stockage Azure peuvent se trouver dans des
abonnements identiques ou différents, ou dans des locataires Azure Active Directory.
Limites
Vous pouvez uniquement déployer des stratégies de point de terminaison de
service sur des réseaux virtuels déployés à l’aide du modèle de déploiement Azure
Resource Manager.
Les réseaux virtuels doivent se trouver dans la même région que la stratégie de
point de terminaison de service.
Vous pouvez uniquement appliquer la stratégie de point de terminaison de service
sur un sous-réseau si les points de terminaison de service sont configurés pour les
services Azure répertoriés dans la stratégie.
Vous ne pouvez pas utiliser les stratégies de points de terminaison de service pour
le trafic allant de votre réseau local aux services Azure.
Les services gérés Azure autres qu’Azure SQL Managed Instance ne prennent
actuellement pas en charge les stratégies de points de terminaison. Cette limite
concerne les services gérés déployés dans des sous-réseaux partagés (tels que
Azure Batch, Azure AD DS, Azure Application Gateway, la passerelle VPN Azure, le
pare-feu Firewall) ou dans des sous-réseaux dédiés (tels que Azure App Service
Environment, Azure Cache pour Redis, Azure API Management, les services gérés
classiques).
２ Avertissement
Les services Azure déployés dans votre réseau virtuel, comme Azure HDInsight,
accèdent aux autres services Azure, comme Stockage Azure, pour les besoins de
l’infrastructure. La restriction de stratégie de point de terminaison à des ressources
spécifiques peut bloquer l’accès à ces ressources d’infrastructure pour les services
Azure déployés dans votre réseau virtuel.
Les comptes de stockage classiques ne sont pas pris en charge dans les stratégies
de points de terminaison. Par défaut, les stratégies refusent l’accès à tous les
comptes de stockage classiques. Si votre application doit accéder à Azure Resource
Manager et à des comptes de stockage classiques, les stratégies de points de
terminaison ne doivent pas être utilisées pour ce trafic.
Tarification et limites
L’utilisation des points de terminaison de service n’engendre pas de frais
supplémentaires. Le modèle de tarification actuel pour les services Azure (comme
Stockage Azure) reste le même que celui utilisé actuellement, sur les points de
terminaison de service.
Les limites suivantes sont appliquées sur les stratégies de point de terminaison de
service :
Ressource Limite par défaut

Ressource Limite par défaut
ServiceEndpointPoliciesPerSubscription 500
ServiceEndpointPoliciesPerSubnet 100
ServiceEndpointPoliciesPerVirtualNetwork 100
ServiceResourcesPerServiceEndpointPolicyDefinition 200
Étapes suivantes
Découvrez comment configurer des stratégies de point de terminaison de service
de réseau virtuel
En savoir plus sur les points de terminaison de service de réseau virtuel

Stratégies réseau Azure Kubernetes
Les stratégies réseau permettent une micro-segmentation des pods tout comme les
groupes de sécurité réseau (NSG) fournissent une micro-segmentation des machines
virtuelles. L’implémentation du Gestionnaire de stratégies réseau Azure prend en charge la
spécification d’une stratégie réseau Kubernetes standard. Vous pouvez utiliser des
étiquettes pour sélectionner un groupe de pods et définir une liste de règles d’entrée et
de sortie pour filtrer le trafic vers et depuis ces pods. Découvrez plus en détail les
stratégies réseau Kubernetes dans la documentation Kubernetes .
L’implémentation de la gestion des stratégies réseau Azure fonctionne avec Azure CNI qui
fournit l’intégration de réseau virtuel pour les conteneurs. Le Gestionnaire de stratégies
réseau est pris en charge sur Linux et Windows Server. L’implémentation applique le
filtrage du trafic en configurant des règles d’autorisation et de refus d’IP basées sur les
stratégies définies dans les IPTables Linux ou les ACLPolicies du service de réseau hôte
(HNS) pour Windows Server.
Planification de la sécurité pour votre cluster

Kubernetes
Quand vous implémentez la sécurité de votre cluster, utilisez des groupes de sécurité
réseau (NSG) pour filtrer le trafic entrant et sortant de votre sous-réseau de cluster (trafic
Nord-Sud). Utilisez le Gestionnaire de stratégies réseau Azure pour le trafic entre les pods
de votre cluster (trafic Est-Ouest).
Utilisation du Gestionnaire de stratégies réseau

Azure
Le Gestionnaire de stratégies réseau Azure peut être utilisé des manières suivantes pour
permettre la micro-segmentation des pods.
Azure Kubernetes Service (AKS)

Le Gestionnaire de stratégies réseau est disponible en mode natif dans AKS et peut être
activé au moment de la création du cluster.
Pour plus d’informations, consultez Sécuriser le trafic entre les pods avec des stratégies
réseau dans Azure Kubernetes Service (AKS).
Clusters Kubernetes DIY (à déployer soi-même) dans Azure

Pour les clusters DIY, installez d’abord le plug-in CNI et activez-le sur chaque machine
virtuelle d’un cluster. Pour obtenir des instructions détaillées, consultez Déployer le plug-
in pour un cluster Kubernetes que vous déployez vous-même.
Une fois le cluster déployé, exécutez la commande suivante kubectl pour télécharger et
appliquer le daemon set du Gestionnaire de stratégies réseau Azure au cluster.
Pour Linux :
kubectl apply -f https://github.com/Azure/azure-container-

networking/blob/master/npm/azure-npm.yaml
Pour Windows :
kubectl apply -f https://github.com/Azure/azure-container-

networking/blob/master/npm/examples/windows/azure-npm.yaml
La solution est également open source et le code est disponible dans le dépôt Azure
Container Networking .
Monitorer et visualiser les configurations réseau
avec Azure NPM
Le Gestionnaire de stratégies réseau Azure comprend des métriques Prometheus
informatives qui vous permettent de monitorer et de mieux comprendre vos
configurations. Il fournit des visualisations intégrées dans le portail Azure ou les
laboratoires Grafana. Vous pouvez commencer à collecter ces métriques en utilisant Azure
Monitor ou un serveur Prometheus.
Avantages des métriques du Gestionnaire de stratégies

réseau Azure
Auparavant, les utilisateurs pouvaient uniquement découvrir leur configuration réseau
avec les commandes iptables et ipset exécutées à l’intérieur d’un nœud de cluster, ce
qui génère une sortie détaillée et difficile à comprendre.
Globalement, les métriques fournissent ce qui suit :
Nombre de stratégies, de règles ACL, d’ipsets, d’entrées ipset et d’entrées dans

n’importe quel ipset donné
Temps d’exécution pour les appels de système d’exploitation individuels et la gestion

des événements de ressources Kubernetes (médiane, 90e centile et 99e centile)
Informations sur les échecs pour la gestion des événements de ressources

Kubernetes (ces événements échouent quand un appel de système d’exploitation
échoue)
Exemples de cas d’usage des métriques
Alertes via Prometheus AlertManager
Consultez une configuration pour ces alertes dans l’exemple suivant.
1. Alerte en cas d’échec du Gestionnaire de stratégies réseau avec un appel de système

d’exploitation ou pendant la traduction d’une stratégie réseau.
2. Alerte lorsque la durée médiane d’application des modifications pour un événement

de création est supérieure à 100 millisecondes.
Visualisations et débogage via notre tableau de bord Grafana ou

workbook Azure Monitor
1. Découvrez le nombre de règles IPTables créées par vos stratégies (un nombre
important de règles IPTables peut légèrement augmenter la latence).
2. Mettez en corrélation le nombre de clusters (par exemple, les listes de contrôle

d’accès) aux temps d’exécution.
3. Obtenez le nom convivial d’un ipset dans une règle IPTables donnée (par exemple,
azure-npm-487392 représente podlabel-role:database ).
Métriques prises en charge

Voici la liste des métriques prises en charge. Toute étiquette quantile présente les valeurs
possibles 0.5 , 0.9 et 0.99 . Toute étiquette had_error présente les valeurs possibles
false et true , indiquant si l’opération a réussi ou échoué.
Nom de métrique Description Type de Étiquettes

métrique
Prometheus
npm_num_policies nombre de Jauge -

stratégies réseau
npm_num_iptables_rules nombre de Jauge -

règles IPTables
npm_num_ipsets nombre d’IPSets Jauge -
npm_num_ipset_entries nombre Jauge -

d’entrées
d’adresse IP
dans tous les
IPSets
npm_add_iptables_rule_exec_time runtime pour Résumé quantile

l’ajout d’une
règle IPTables
npm_add_ipset_exec_time runtime pour Résumé quantile

l’ajout d’un IPSet
npm_ipset_counts (avancé) nombre GaugeVec set_name & set_hash

d’entrées dans
chaque IPSet
individuel
npm_add_policy_exec_time runtime pour Résumé quantile & had_error

l’ajout d’une
stratégie réseau
Nom de métrique Description Type de Étiquettes
métrique
Prometheus
npm_controller_policy_exec_time runtime pour la Résumé quantile & had_error & operation

mise à (avec des valeurs update ou
jour/suppression delete )
d’une stratégie
réseau
npm_controller_namespace_exec_time runtime pour la Résumé quantile & had_error & operation

création/mise à (avec des valeurs create , update
jour/suppression ou delete )
d’un espace de
noms
npm_controller_pod_exec_time runtime pour la Résumé quantile & had_error & operation

création/mise à (avec des valeurs create , update
jour/suppression ou delete )
d’un pod
Il existe également des métriques « exec_time_count » et « exec_time_sum » pour chaque

métrique récapitulative « exec_time ».
Les métriques peuvent être scrapées via Azure Monitor pour conteneurs ou via
Prometheus.
Configurer pour Azure Monitor

La première étape consiste à activer Azure Monitor pour conteneurs sur votre cluster
Kubernetes. Les étapes sont accessibles dans Vue d’ensemble d’Azure Monitor pour
conteneurs. Une fois que vous avez activé Azure Monitor pour conteneurs, configurez
ConfigMap Azure Monitor pour conteneurs pour activer l’intégration du Gestionnaire
de stratégies réseau et la collecte des métriques Prometheus du Gestionnaire de
stratégies réseau.
ConfigMap Azure Monitor pour conteneurs a une section integrations avec des
paramètres permettant de collecter les métriques du Gestionnaire de stratégies réseau.
Ces paramètres sont désactivés par défaut dans l’objet ConfigMap. Activez le paramètre
de base collect_basic_metrics = true pour collecter les métriques de base du
Gestionnaire de stratégies réseau. Activez le paramètre avancé collect_advanced_metrics
= true pour collecter les métriques avancées en plus des métriques de base.
Après avoir modifié l’objet ConfigMap, enregistrez-le localement et appliquez-le à votre

cluster comme suit.
kubectl apply -f container-azm-ms-agentconfig.yaml
L’extrait de code suivant est tiré du ConfigMap Azure Monitor pour conteneurs et
montre l’intégration du Gestionnaire de stratégies réseau activée avec la collecte des
métriques avancées.
integrations: |-
[integrations.azure_network_policy_manager]
collect_basic_metrics = false
collect_advanced_metrics = true
Les métriques avancées sont facultatives et leur activation active automatiquement la

collecte des métriques de base. Les métriques avancées comprennent actuellement
uniquement Network Policy Manager_ipset_counts .
En savoir plus sur les paramètres de collecte Azure Monitor pour conteneurs dans
ConfigMap.
Options de visualisation pour Azure Monitor

Une fois la collecte des métriques du Gestionnaire de stratégies réseau activée, vous
pouvez voir les métriques dans le portail Azure en utilisant les insights de conteneur ou
dans Grafana.
Consultation dans le portail Azure sous les insights du cluster

Ouvrez le portail Azure. Une fois que vous êtes dans la section Insights de votre cluster,
accédez à Workbooks et ouvrez Configuration du Gestionnaire de stratégies réseau.
En plus de voir le workbook, vous pouvez également interroger directement les métriques
Prometheus dans « Journaux » sous la section Insights. Par exemple, cette requête renvoie
toutes les métriques collectées.
query
| where TimeGenerated > ago(5h)

| where Name contains "npm_"
Vous pouvez également interroger directement les métriques dans Log Analytics. Pour
plus d’informations, consultez Bien démarrer avec les requêtes Log Analytics.
Consultation dans le tableau de bord Grafana
Configurez votre serveur Grafana et configurez une source de données Log Analytics
comme décrit ici . Ensuite, importez le tableau de bord Grafana avec un serveur principal
Log Analytics dans vos laboratoires Grafana.
Le tableau de bord comporte des objets visuels similaires à ceux du classeur Azure. Vous
pouvez ajouter des panneaux au graphique et visualiser les métriques du Gestionnaire de
stratégies réseau à partir du tableau InsightsMetrics.
Configurer le serveur Prometheus

Certains utilisateurs peuvent choisir de collecter les métriques avec un serveur
Prometheus au lieu d’Azure Monitor pour conteneurs. Il vous suffit d’ajouter deux travaux
à votre configuration de scrapage pour collecter les métriques du Gestionnaire de
stratégies réseau.
Pour installer un serveur Prometheus, ajoutez ce dépôt Helm sur votre cluster :
helm repo add stable https://kubernetes-charts.storage.googleapis.com

helm repo update
Ajoutez ensuite un serveur :
helm install prometheus stable/prometheus -n monitoring \

--set pushgateway.enabled=false,alertmanager.enabled=false, \
--set-file extraScrapeConfigs=prometheus-server-scrape-config.yaml
où prometheus-server-scrape-config.yaml se compose de :
- job_name: "azure-npm-node-metrics"
metrics_path: /node-metrics
kubernetes_sd_configs:
- role: node
relabel_configs:
- source_labels: [__address__]
action: replace
regex: ([^:]+)(?::\d+)?
replacement: "$1:10091"
target_label: __address__
- job_name: "azure-npm-cluster-metrics"
metrics_path: /cluster-metrics
- role: service
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
regex: kube-system
action: keep
- source_labels: [__meta_kubernetes_service_name]
regex: npm-metrics-cluster-service
action: keep
# Comment from here to the end to collect advanced metrics: number of entries
for each IPSet
metric_relabel_configs:
- source_labels: [__name__]
regex: npm_ipset_counts
action: drop
Vous pouvez également remplacer le travail azure-npm-node-metrics par le contenu

suivant ou l’incorporer dans un travail préexistant pour les pods Kubernetes :
- job_name: "azure-npm-node-metrics-from-pod-config"
metrics_path: /node-metrics
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
regex: kube-system
action: keep
- source_labels: [__meta_kubernetes_pod_annotationpresent_azure_Network
Policy Manager_scrapeable]
action: keep
- source_labels: [__address__]
action: replace
regex: ([^:]+)(?::\d+)?
replacement: "$1:10091"
target_label: __address__
Configurer des alertes pour AlertManager

Si vous utilisez un serveur Prometheus, vous pouvez configurer AlertManager de la façon
suivante. Voici un exemple de configuration des deux règles d’alerte décrites
précédemment :
groups:
- name: npm.rules
rules:
# fire when Network Policy Manager has a new failure with an OS call or when
translating a Network Policy (suppose there's a scraping interval of 5m)
- alert: AzureNetwork Policy ManagerFailureCreatePolicy
# this expression says to grab the current count minus the count 5 minutes
ago, or grab the current count if there was no data 5 minutes ago
expr: (npm_add_policy_exec_time_count{had_error='true'} -
(npm_add_policy_exec_time_count{had_error='true'} offset 5m)) or
npm_add_policy_exec_time_count{had_error='true'}
labels:
severity: warning
addon: azure-npm
annotations:
summary: "Azure Network Policy Manager failed to handle a policy create
event"
description: "Current failure count since Network Policy Manager
started: {{ $value }}"
# fire when the median time to apply changes for a pod create event is more
than 100 milliseconds.
- alert: AzurenpmHighControllerPodCreateTimeMedian
expr: topk(1,
npm_controller_pod_exec_time{operation="create",quantile="0.5",had_error="fals
e"}) > 100.0
labels:
severity: warning
addon: azure-Network Policy Manager
annotations:
summary: "Azure Network Policy Manager controller pod create time median
> 100.0 ms"
# could have a simpler description like the one for the alert above,
# but this description includes the number of pod creates that were
handled in the past 10 minutes,
# which is the retention period for observations when calculating
quantiles for a Prometheus Summary metric
description: "value: [{{ $value }}] and observation count: [{{ printf
`(npm_controller_pod_exec_time_count{operation='create',pod='%s',had_error='fa
lse'} -
(npm_controller_pod_exec_time_count{operation='create',pod='%s',had_error='fal
se'} offset 10m)) or
npm_controller_pod_exec_time_count{operation='create',pod='%s',had_error='fals
e'}` $labels.pod $labels.pod $labels.pod | query | first | value }}] for pod:
[{{ $labels.pod }}]"
Options de visualisation pour Prometheus

Quand vous utilisez un serveur Prometheus, seul le tableau de bord Grafana est pris en
charge.
Si vous ne l’avez pas déjà fait, configurez votre serveur Grafana et configurez une source
de données Prometheus. Ensuite, importez notre tableau de bord Grafana avec un serveur
principal Prometheus dans vos laboratoires Grafana.
Les visuels de ce tableau de bord sont identiques à ceux du tableau de bord avec un
back-end Container Insights/Log Analytics.
Exemples de tableaux de bord

Voici quelques exemples de tableau de bord pour les métriques du Gestionnaire de
stratégies réseau dans Container Insights (CI) et Grafana.
Nombre de récapitulatifs CI
Nombres CI dans le temps
Entrées IPSet CI

Quantiles du runtime CI
Nombre de récapitulatifs du tableau de bord Grafana

Nombres du tableau de bord Grafana dans le temps
Entrées IPSet du tableau de bord Grafana
Quantiles de runtime du tableau de bord Grafana


Étapes suivantes
Découvrez en détail Azure Kubernetes Service.
Découvrez en détail la mise en réseau de conteneurs.
Déployez le plug-in pour des clusters Kubernetes ou des conteneurs Docker.

Qu’est-ce qu’Azure DDoS Protection ?
Les attaques par déni de service distribué (DDoS) représentent certains des problèmes
de disponibilité et de sécurité majeurs auxquels sont confrontés les clients qui déplacent
leurs applications vers le cloud. Une attaque DDoS tente d’épuiser les ressources d’une
application afin de la rendre indisponible aux utilisateurs légitimes. Les attaques DDoS
peuvent être ciblées sur n’importe quel point de terminaison qui est publiquement
accessible via Internet.
Azure DDoS Protection, combiné aux meilleures pratiques de conception d’applications,

offre des fonctionnalités d’atténuation DDoS améliorées pour lutter contre les attaques
DDoS. Cette solution s’adapte automatiquement pour protéger vos ressources Azure
spécifiques dans un réseau virtuel. La protection est simple à activer sur n’importe quel
réseau virtuel, nouveau ou existant, et ne nécessite aucun changement au niveau de
l’application ou des ressources.
Analyse permanente du trafic

Vos modèles de trafic d’application sont surveillés 24h/24 et 7j/7, à la recherche
d’indicateurs d’attaques DDoS. Le service Azure DDoS Protection atténue de façon
instantanée et automatique l’attaque une fois que celle-ci est détectée.
Réglage adaptatif en temps réel

Le profilage intelligent du trafic étudie le trafic de votre application au fil du temps pour
sélectionner et mettre à jour le profil le plus adapté pour votre service. Le profil s’ajuste
en fonction des modifications du trafic au fil du temps.
Protection DDoS : télémétrie, monitoring et génération

d’alertes
Azure DDoS Protection applique trois stratégies d’atténuation réglées automatiquement
(TCP SYN, TCP et UDP) pour chaque adresse IP publique de la ressource protégée, dans
le réseau virtuel sur lequel la protection DDoS est activée. Les seuils de stratégie sont
configurés automatiquement par le biais du système de profilage du trafic réseau basé
sur l’apprentissage automatique. L’atténuation des risques liés à DDoS pour une adresse
IP n’a lieu que si le seuil de stratégie est dépassé.
Réponse rapide Azure DDoS

Lors d’une attaque active, les clients Azure DDoS Protection ont accès à l’équipe de
réponse rapide DDoS (DRR), qui peut les aider à investiguer l’attaque lorsqu’elle survient
et à en faire l’analyse après. Pour plus d’informations, consultez le service Réponse
rapide Azure DDoS.
SKU
Azure DDoS Protection est proposé dans deux références SKU disponibles, la Protection
IP DDoS (préversion) et la Protection réseau DDoS. Pour plus d’informations sur les
références SKU, consultez Comparaison des références SKU.
Intégration de la plateforme native

Intégré en natif dans Azure. Inclut la configuration par le biais du portail Azure. Le
service Azure DDoS Protection comprend vos ressources et leur configuration.
Protection clé en main

La configuration simplifiée protège immédiatement toutes les ressources situées sur un
réseau virtuel dès que la Protection réseau DDoS est activée. Aucune définition ou
intervention de l’utilisateur n’est nécessaire. De même, la configuration simplifiée
protège immédiatement une ressource IP publique lorsque la Protection IP DDoS est
activée pour celle-ci.
Protection multi-couches
Lorsqu’il est déployé avec un pare-feu d’applications web (WAF), le service Azure DDoS
Protection offre une protection à la fois au niveau de la couche réseau (couche 3 et 4,
assurée par Azure DDoS Protection) et au niveau de la couche d’application (couche 7,
assurée par un pare-feu WAF). Les offres WAF incluent la référence SKU du pare-feu
d’applications web Azure Application Gateway, et des offres tierces de pare-feu
d’applications web disponibles sur Place de marché Azure .
Échelle d’atténuation des risques étendue

L’ensemble des vecteurs d’attaque L3/L4 peuvent être atténués avec une protection
globale contre les attaques DDoS les plus connues.
Analytique des attaques

Recevez des rapports détaillés toutes les cinq minutes pendant une attaque, et un
résumé complet une fois l’attaque terminée. Transmettez en continu les journaux de flux
de prévention des attaques à Microsoft Sentinel ou un système hors ligne de gestion
des informations et des événements de sécurité (SIEM) pour une supervision en temps
quasi-réel pendant une attaque. Pour en savoir plus, consultez Afficher et configurer la
journalisation des diagnostics DDoS.
Métriques des attaques

Des métriques récapitulatives de chaque attaque sont accessibles via Azure Monitor.
Pour en savoir plus, consultez Afficher et configurer la télémétrie de la protection DDoS.
Alertes d’attaque
Vous pouvez configurer des alertes pour le début et la fin d’une attaque, ainsi que
pendant qu’elle se produit, avec des métriques d’attaque intégrées. Les alertes
s’intègrent à vos logiciels opérationnels, comme les journaux d’activité Microsoft Azure
Monitor, Splunk, Stockage Azure, votre messagerie électronique et le portail Azure. Pour
en savoir plus, consultez Afficher et configurer les alertes de protection DDoS.
Garantie des coûts

Recevez un crédit de service de transfert de données et de mise à l’échelle des
applications pour les coûts de ressources résultant d’attaques DDoS documentées.
Architecture
Azure DDoS Protection est conçu pour les services déployés dans un réseau virtuel. Pour
les autres services, la protection DDoS par défaut au niveau de l’infrastructure
s’applique. Elle offre une protection contre les attaques courantes de la couche réseau.
Pour en savoir plus sur les architectures prises en charge, consultez Architectures de
référence de la protection DDoS.
Tarifs
Pour la Protection réseau DDoS, sous un locataire, un même plan de protection DDoS
peut être utilisé sur plusieurs abonnements. Il n’est donc pas nécessaire de créer
plusieurs plans de protection DDoS. Pour la Protection IP DDoS, il n’est pas nécessaire
de créer un plan de protection DDoS. Les clients peuvent activer la protection IP DDoS
sur n’importe quelle ressource IP publique.
Pour en savoir plus sur la tarification d’Azure DDoS Protection, consultez Tarification
d’Azure DDoS Protection .
FAQ sur la protection DDoS

Pour accéder aux questions fréquentes (FAQ), consultez la FAQ sur la protection DDos.
Étapes suivantes
Démarrage rapide : Créer un plan de protection DDoS
Module Learn : Présentation d’Azure DDoS Protection
 Documentation
Foire aux questions sur le service Azure DDoS Protection

Forum aux questions sur Azure DDoS Protection, qui contribue à assurer la défense contre les
attaques par déni de service.
Bonnes pratiques de base Azure DDoS Protection

Découvrez les bonnes pratiques de sécurité à l’aide d’Azure DDoS Protection.
À propos de la comparaison des références SKU Azure DDoS Protection

Découvrez les références SKU disponibles pour Azure DDoS Protection.
Démarrage rapide : Créer et configurer la protection réseau DDoS Azure à l’aide du

Portail Azure
Découvrez comment utiliser Azure DDoS Network Protection pour atténuer une attaque.
Types d’attaques atténuées par Azure DDoS Protection

Découvrez les types d’attaques contre lesquels Azure DDoS Protection agit.
Fonctionnalités d’Azure DDoS Protection

Découvrir les fonctionnalités d’Azure DDoS Protection
Architectures de référence Azure DDoS Protection

Découvrez les architectures de référence Azure DDoS Protection.
Tutoriel : Afficher et configurer la télémétrie de la protection DDoS pour Azure DDoS

Protection
Découvrez comment afficher et configurer la télémétrie de la protection DDoS pour Azure DDoS
Protection.
Afficher 5 de plus
 Entrainement
Module
Présentation de Azure DDoS Protection - Training
Découvrez comment protéger vos services Azure contre une attaque par déni de service avec Azure
DDoS Protection.
TAP de réseau virtuel
Article • 10/04/2023
） Important
La préversion du TAP de réseau virtuel est actuellement en attente dans toutes les
régions Azure. Vous pouvez nous envoyer un e-mail à l’adresse
azurevnettap@microsoft.com avec votre ID d’abonnement et nous vous
informerons des futures mises à jour concernant la préversion. En attendant, vous
pouvez utiliser des solutions NVA ou basées sur agent qui fournissent des
fonctionnalités de visibilité du TAP/réseau via nos solutions de partenaire Packet
Broker disponibles dans les offres de la Place de marché Azure .
Le TAP (point d’accès terminal) de réseau virtuel Azure vous permet de diffuser en
continu votre trafic réseau de machine virtuelle vers un collecteur de paquets réseau ou
un outil analytique. Le collecteur ou l’outil analytique est fourni par une appliance
virtuelle réseau partenaire. Pour obtenir la liste des solutions de partenaires qui
fonctionnent avec un TAP de réseau virtuel, consultez les solutions de partenaires.
Le diagramme suivant illustre le fonctionnement d’un TAP de réseau virtuel. Vous

pouvez ajouter une configuration TAP sur une interface réseau attachée à une machine
virtuelle déployée dans votre réseau virtuel. La destination est une adresse IP de réseau
virtuel dans le même réseau virtuel que l’interface réseau supervisée ou un réseau virtuel
appairé. La solution du collecteur pour le TAP de réseau virtuel peut être déployée
derrière un équilibreur de charge interne Azure pour une haute disponibilité.
Conditions préalables requises
Avant de pouvoir créer un TAP de réseau virtuel, vérifiez que vous avez reçu l’e-mail de
confirmation indiquant que vous êtes inscrit à la préversion. Vous devez disposer d’une
machine virtuelle, ou plus, créée avec Azure Resource Manager et une solution
partenaire pour agréger le trafic TAP dans la même région Azure. Si vous n’avez pas de
solution de partenaire dans votre réseau virtuel, consultez les solutions de partenaires
pour en déployer une.
Vous pouvez utiliser la même ressource TAP de réseau virtuel pour agréger le trafic de
plusieurs interfaces réseau dans le même abonnement ou des abonnements différents.
Si les interfaces réseau supervisées sont dans des abonnements différents, les
abonnements doivent être associés au même locataire Azure Active Directory. Par
ailleurs, les interfaces réseau supervisées et le point de terminaison de destination pour
l’agrégation du trafic TAP peuvent être dans des réseaux virtuels appairés dans la même
région. Si vous utilisez ce modèle de déploiement, vérifiez que le appairage de réseaux
virtuels est activé avant de configurer le TAP de réseau virtuel.
Autorisations
Les comptes que vous utilisez pour appliquer une configuration TAP sur des interfaces
réseau doivent être attribués au rôle contributeur de réseaux ou à un rôle personnalisé
avec les autorisations appropriées listées dans le tableau suivant :
Action Nom
Microsoft.Network/virtualNetworkTaps/* Nécessaire pour créer, mettre à jour, lire et

supprimer une ressource TAP de réseau virtuel
Microsoft.Network/networkInterfaces/read Nécessaire pour lire la ressource d’interface réseau

sur laquelle configurer le TAP
Microsoft.Network/tapConfigurations/* Nécessaire pour créer, mettre à jour, lire et

supprimer la configuration TAP sur une interface
réseau
Solutions de partenaires pour le TAP de réseau

virtuel
Répartiteurs de paquets réseau

GigaVUE Cloud Suite pour Azure
Ixia CloudLens
Nubeva Prisms
Big Switch Big Monitoring Fabric
Analytique de la sécurité, gestion des performances des

applications/du réseau
Awake Security
Cisco Stealthwatch Cloud
Darktrace
ExtraHop Reveal(x)
Fidelis Cybersecurity
Flowmon
NetFort LANGuardian
NetScout vSTREAM
Noname Security
Riverbed SteelCentral AppResponse
RSA NetWitness® Platform
Vectra Cognito
Étapes suivantes
Découvrez comment créer un TAP de réseau virtuel.
Contrôles de conformité réglementaire
d’Azure Policy pour les réseaux virtuels
Azure
Article • 01/06/2023
La Conformité réglementaire d’Azure Policy fournit des définitions d’initiatives créées et

gérées par Microsoft, qui sont dites intégrées, pour les domaines de conformité et les
contrôles de sécurité associés à différents standards de conformité. Cette page liste les
domaines de conformité et les contrôles de sécurité pour les réseaux virtuels Azure. Vous
pouvez affecter les composants intégrés pour un contrôle de sécurité individuellement, afin
de rendre vos ressources Azure conformes au standard spécifique.
Le titre de chaque définition de stratégie intégrée est un lien vers la définition de la

stratégie dans le portail Azure. Utilisez le lien de la colonne Version de la stratégie pour
voir la source dans le dépôt GitHub Azure Policy .
） Important
Chaque contrôle est associé à une ou plusieurs définitions Azure Policy. Ces stratégies
peuvent vous aider à évaluer la conformité avec le contrôle. Toutefois, il n’existe pas
souvent de correspondance un-à-un ou parfaite entre un contrôle et une ou plusieurs
stratégies. En tant que tel, Conforme dans Azure Policy fait seulement référence aux
stratégies elles-même. Cela ne garantit pas que vous êtes entièrement conforme à
toutes les exigences d’un contrôle. En outre, la norme de conformité comprend des
contrôles qui ne sont traités par aucune définition Azure Policy pour l’instant. Par
conséquent, la conformité dans Azure Policy n’est qu’une vue partielle de l’état de
conformité global. Les associations entre les contrôles et les définitions de conformité
réglementaire Azure Policy pour ces normes de conformité peuvent changer au fil du
temps.
Australian Government ISM PROTECTED

Pour voir comment les composants intégrés Azure Policy disponibles pour tous les services
Azure correspondent à ce standard de conformité, consultez Conformité réglementaire
d’Azure Policy – Australian Government ISM PROTECTED. Pour plus d’informations sur cette
norme de conformité, consultez Australian Government ISM PROTECTED .
Domain ID du Titre du Policy Version
contrôle contrôle (Portail Azure) de la
stratégie
(GitHub)
Instructions pour le réseau - 1431 Stratégies de Azure DDoS 3.0.0

Continuité de service pour les déni de service Protection Standard
services en ligne - 1431 doit être activé
Benchmark de sécurité Azure

Le benchmark de sécurité Azure fournit des recommandations sur la façon dont vous
pouvez sécuriser vos solutions cloud sur Azure. Pour voir comment ce service est
entièrement mappé au benchmark de sécurité Azure, consultez les fichiers de mappage du
benchmark de sécurité Azure .
Pour passer en revue la façon dont les composants intégrés Azure Policy disponibles pour
tous les services Azure sont mappés à ce standard de conformité, consultez Conformité
réglementaire Azure Policy - Benchmark de sécurité Azure.
Domain ID du Titre du contrôle Policy Version

contrôle (Portail Azure) de la
stratégie
(GitHub)
Sécurité NS-1 Établir des limites de les sous-réseaux doivent être associés 3.0.0
réseau segmentation réseau à un groupe de sécurité réseau
Sécurité NS-3 Déployer le pare-feu à [Préversion] : L’ensemble du trafic 3.0.0-

réseau la périphérie du réseau Internet doit transiter par votre Pare- preview
d’entreprise feu Azure déployé
Sécurité NS-5 Déployer la protection Azure DDoS Protection Standard doit 3.0.0
réseau DDOS être activé
Sécurité NS-6 Déployer le pare-feu Azure Web Application Firewall doit 1.0.2
réseau d’applications web être activé pour les points d’entrée
Azure Front Door
Sécurité NS-6 Déployer le pare-feu Le pare-feu d’applications web (WAF) 2.0.0

réseau d’applications web doit être activé pour Application
Gateway
Réponse IR-4 Détection et analyse – Network Watcher doit être activé 3.0.0
aux enquêter sur un
incidents incident
Azure Security Benchmark v1
Le benchmark de sécurité Azure fournit des recommandations sur la façon dont vous
pouvez sécuriser vos solutions cloud sur Azure. Pour voir comment ce service est
entièrement mappé au benchmark de sécurité Azure, consultez les fichiers de mappage du
benchmark de sécurité Azure .
Pour passer en revue la façon dont les composants intégrés Azure Policy disponibles pour
tous les services Azure sont mappés à ce standard de conformité, consultez Conformité
réglementaire Azure Policy - Benchmark de sécurité Azure.

stratégie
(GitHub)
Sécurité 1.1 Protéger les ressources à l'aide de [Préversion] : L’ensemble du 3.0.0-

réseau groupes de sécurité réseau ou du trafic Internet doit transiter preview
Pare-feu Azure sur votre réseau par votre Pare-feu Azure
virtuel déployé
Sécurité 1.1 Protéger les ressources à l'aide de les sous-réseaux doivent être 3.0.0
réseau groupes de sécurité réseau ou du associés à un groupe de
Pare-feu Azure sur votre réseau sécurité réseau
virtuel
Sécurité 1.1 Protéger les ressources à l'aide de Les machines virtuelles 1.0.0
réseau groupes de sécurité réseau ou du doivent être connectées à un
Pare-feu Azure sur votre réseau réseau virtuel approuvé
virtuel
Sécurité 1.1 Protéger les ressources à l'aide de Les réseaux virtuels doivent 1.0.0
réseau groupes de sécurité réseau ou du utiliser la passerelle de
Pare-feu Azure sur votre réseau réseau virtuel spécifiée
virtuel
Sécurité 1.2 Surveiller et consigner la Network Watcher doit être 3.0.0

réseau configuration et le trafic des activé
réseaux virtuels, des sous-réseaux
et des cartes réseau
Sécurité 1.4 Refuser les communications [Préversion] : L’ensemble du 3.0.0-

réseau présentant des adresses IP trafic Internet doit transiter preview
connues comme étant par votre Pare-feu Azure
malveillantes déployé
Sécurité 1.4 Refuser les communications Azure DDoS Protection 3.0.0

réseau présentant des adresses IP Standard doit être activé
connues comme étant
malveillantes
stratégie
(GitHub)
Sécurité 1.5 Consigner les paquets réseau et Network Watcher doit être 3.0.0
réseau les journaux de flux activé
PBMM fédéral du Canada

Pour voir comment les composants intégrés Azure Policy de tous les services Azure
répondent à ce standard de conformité, consultez Conformité réglementaire Azure Policy –
Canada Federal PBMM. Pour plus d’informations sur cette norme de conformité, consultez
Canada Federal PBMM .
Domain ID du Titre du contrôle Policy Version de

contrôle (Portail Azure) la stratégie
(GitHub)
Protection du système et SC-5 Protection contre Azure DDoS Protection 3.0.0

des communications le déni de service Standard doit être activé
CIS Microsoft Azure Foundations Benchmark 1.1.0

Azure Policy – CIS Microsoft Azure Foundations Benchmark 1.1.0. Pour plus d’informations
sur cette norme de conformité, consultez CIS Microsoft Azure Foundations Benchmark .
Domain ID du contrôle Titre du contrôle Policy Version

(Portail Azure) de la
stratégie
(GitHub)
2 recommandation Vérifier que le paramètre de stratégie les sous-réseaux 3.0.0

Security du CIS Microsoft par défaut ASC « Activer la doivent être
Center Azure supervision du pare-feu de nouvelle associés à un
Foundations génération » n’est pas défini sur groupe de
Benchmark 2.9 « Disabled » sécurité réseau
6 Mise recommandation Vérifier que Network Watcher est Network Watcher 3.0.0
en du CIS Microsoft défini sur « Enabled » doit être activé
réseau Azure
Foundations
Benchmark 6.5
CIS Microsoft Azure Foundations
Benchmark 1.3.0
Azure Policy – CIS Microsoft Azure Foundations Benchmark 1.3.0. Pour plus d’informations
sur cette norme de conformité, consultez CIS Microsoft Azure Foundations Benchmark .

stratégie
(GitHub)
6 Mise recommandation du CIS Vérifier que Network Network 3.0.0

en Microsoft Azure Foundations Watcher est défini sur Watcher doit
réseau Benchmark 6.5 « Enabled » être activé
CIS Microsoft Azure Foundations

Benchmark 1.4.0
Pour voir comment les composants intégrés Azure Policy disponibles de tous les services
Azure répondent à cette norme de conformité, consultez Détails de l’initiative intégrée de
conformité réglementaire pour CIS Microsoft Azure Foundations Benchmark 1.4.0. Pour plus
d’informations sur cette norme de conformité, consultez CIS Microsoft Azure Foundations
Benchmark .

stratégie
(GitHub)
6 Mise recommandation du CIS Vérifier que Network Network 3.0.0

en Microsoft Azure Foundations Watcher est défini sur Watcher doit
réseau Benchmark 6.5 « Enabled » être activé
CMMC niveau 3
Pour voir comment les composants intégrés Azure Policy de tous les services Azure
répondent à ce standard de conformité, consultez Conformité réglementaire Azure Policy –
CMMC niveau 3. Pour plus d’informations sur ce standard de conformité, consultez
Cybersecurity Maturity Model Certification (CMMC) .
stratégie
(GitHub)
Contrôle d’accès AC.1.003 Vérifier et contrôler/limiter les [Préversion] : 3.0.0-

connexions aux systèmes L’ensemble du preview
d’information externes, ainsi que leur trafic Internet
utilisation. doit transiter par
votre Pare-feu
Azure déployé
Contrôle d’accès AC.2.013 Superviser et contrôler les sessions Network Watcher 3.0.0
d’accès à distance. doit être activé
Contrôle d’accès AC.2.016 Contrôler le flux de CUI [Préversion] : 3.0.0-

conformément aux autorisations L’ensemble du preview
approuvées. trafic Internet
doit transiter par
votre Pare-feu
Azure déployé
Gestion de la CM.2.064 Établir et appliquer des paramètres [Préversion] : 3.0.0-

configuration de configuration de sécurité pour les L’ensemble du preview
produits informatiques utilisés dans trafic Internet
les systèmes d’entreprise. doit transiter par
votre Pare-feu
Azure déployé
Gestion de la CM.2.064 Établir et appliquer des paramètres Azure Web 1.0.2

configuration de configuration de sécurité pour les Application
produits informatiques utilisés dans Firewall doit être
les systèmes d’entreprise. activé pour les
points d’entrée
Azure Front
Door
Gestion de la CM.2.064 Établir et appliquer des paramètres Le pare-feu 2.0.0

configuration de configuration de sécurité pour les d’applications
produits informatiques utilisés dans web (WAF) doit
les systèmes d’entreprise. être activé pour
Application
Gateway

les systèmes d’entreprise. utiliser le mode
spécifié pour
Application
Gateway
stratégie
(GitHub)

les systèmes d’entreprise. utiliser le mode
spécifié pour
Azure Front Door
Service
Gestion de la CM.3.068 Limiter, désactiver ou empêcher les sous-réseaux 3.0.0

configuration l’utilisation de programmes, doivent être
fonctions, ports, protocoles et associés à un
services non essentiels. groupe de
sécurité réseau
Réponse aux IR.2.093 Détecter et signaler des événements. [Préversion] : 3.0.0-

incidents L’ensemble du preview
trafic Internet
doit transiter par
votre Pare-feu
Azure déployé
Réponse aux IR.2.093 Détecter et signaler des événements. Azure Web 1.0.2
incidents Application
Firewall doit être
activé pour les
points d’entrée
Azure Front
Door
Réponse aux IR.2.093 Détecter et signaler des événements. Les journaux de 1.1.0
incidents flux doivent être
configurés pour
chaque groupe
de sécurité
réseau
Réponse aux IR.2.093 Détecter et signaler des événements. Le pare-feu 2.0.0

incidents d’applications
web (WAF) doit
être activé pour
Application
Gateway
stratégie
(GitHub)

web (WAF) doit
utiliser le mode
spécifié pour
Application
Gateway

web (WAF) doit
utiliser le mode
spécifié pour
Azure Front Door
Service
Protection du SC.1.175 Superviser, contrôler et protéger les Azure Web 1.0.2

système et des communications (c’est-à-dire les Application
communications informations transmises ou reçues Firewall doit être
par les systèmes de l’organisation) activé pour les
aux limites externes et aux limites points d’entrée
internes clés des systèmes de Azure Front
l’organisation. Door
Protection du SC.1.175 Superviser, contrôler et protéger les Les journaux de 1.1.0

système et des communications (c’est-à-dire les flux doivent être
communications informations transmises ou reçues configurés pour
par les systèmes de l’organisation) chaque groupe
aux limites externes et aux limites de sécurité
internes clés des systèmes de réseau
l’organisation.
Protection du SC.1.175 Superviser, contrôler et protéger les Network Watcher 3.0.0

système et des communications (c’est-à-dire les doit être activé
communications informations transmises ou reçues
par les systèmes de l’organisation)
aux limites externes et aux limites
internes clés des systèmes de
l’organisation.
stratégie
(GitHub)
Protection du SC.1.175 Superviser, contrôler et protéger les Le pare-feu 2.0.0

système et des communications (c’est-à-dire les d’applications
communications informations transmises ou reçues web (WAF) doit
par les systèmes de l’organisation) être activé pour
aux limites externes et aux limites Application
internes clés des systèmes de Gateway
l’organisation.

par les systèmes de l’organisation) utiliser le mode
aux limites externes et aux limites spécifié pour
internes clés des systèmes de Application
l’organisation. Gateway

par les systèmes de l’organisation) utiliser le mode
aux limites externes et aux limites spécifié pour
internes clés des systèmes de Azure Front Door
l’organisation. Service
Protection du SC.1.176 Implémenter des sous-réseaux pour les sous-réseaux 3.0.0

système et des les composants système accessibles doivent être
communications publiquement qui sont associés à un
physiquement ou logiquement groupe de
séparés des réseaux internes. sécurité réseau
Protection du SC.3.180 Utiliser les conceptions les sous-réseaux 3.0.0

système et des architecturales, les techniques de doivent être
communications développement de logiciels et les associés à un
principes d’ingénierie des systèmes groupe de
qui favorisent la sécurité des sécurité réseau
informations au sein des systèmes
d’entreprise.
Protection du SC.3.183 Refuser le trafic des communications [Préversion] : 3.0.0-

système et des réseau par défaut et autoriser le trafic L’ensemble du preview
communications des communications réseau par trafic Internet
exception (c’est-à-dire, tout refuser, doit transiter par
autoriser par exception). votre Pare-feu
Azure déployé
stratégie
(GitHub)
Protection du SC.3.183 Refuser le trafic des communications Azure Web 1.0.2

système et des réseau par défaut et autoriser le trafic Application
communications des communications réseau par Firewall doit être
exception (c’est-à-dire, tout refuser, activé pour les
autoriser par exception). points d’entrée
Azure Front
Door
Protection du SC.3.183 Refuser le trafic des communications Les journaux de 1.1.0

système et des réseau par défaut et autoriser le trafic flux doivent être
communications des communications réseau par configurés pour
exception (c’est-à-dire, tout refuser, chaque groupe
autoriser par exception). de sécurité
réseau
Protection du SC.3.183 Refuser le trafic des communications Network Watcher 3.0.0

système et des réseau par défaut et autoriser le trafic doit être activé
communications des communications réseau par
exception (c’est-à-dire, tout refuser,
autoriser par exception).
Protection du SC.3.183 Refuser le trafic des communications les sous-réseaux 3.0.0

système et des réseau par défaut et autoriser le trafic doivent être
communications des communications réseau par associés à un
exception (c’est-à-dire, tout refuser, groupe de
autoriser par exception). sécurité réseau
Protection du SC.3.183 Refuser le trafic des communications Le pare-feu 2.0.0

système et des réseau par défaut et autoriser le trafic d’applications
communications des communications réseau par web (WAF) doit
exception (c’est-à-dire, tout refuser, être activé pour
autoriser par exception). Application
Gateway

exception (c’est-à-dire, tout refuser, utiliser le mode
autoriser par exception). spécifié pour
Application
Gateway
stratégie
(GitHub)

exception (c’est-à-dire, tout refuser, utiliser le mode
autoriser par exception). spécifié pour
Azure Front Door
Service
Intégrité du SI.2.216 Superviser les systèmes de [Préversion] : 3.0.0-

système et des l’organisation, notamment le trafic L’ensemble du preview
informations des communications entrantes et trafic Internet
sortantes, pour détecter les attaques doit transiter par
et les indicateurs d’attaques votre Pare-feu
potentielles. Azure déployé
Intégrité du SI.2.216 Superviser les systèmes de Azure Web 1.0.2

système et des l’organisation, notamment le trafic Application
informations des communications entrantes et Firewall doit être
sortantes, pour détecter les attaques activé pour les
et les indicateurs d’attaques points d’entrée
potentielles. Azure Front
Door
Intégrité du SI.2.216 Superviser les systèmes de Les journaux de 1.1.0

système et des l’organisation, notamment le trafic flux doivent être
informations des communications entrantes et configurés pour
sortantes, pour détecter les attaques chaque groupe
et les indicateurs d’attaques de sécurité
potentielles. réseau
Intégrité du SI.2.216 Superviser les systèmes de Network Watcher 3.0.0

système et des l’organisation, notamment le trafic doit être activé
informations des communications entrantes et
sortantes, pour détecter les attaques
et les indicateurs d’attaques
potentielles.
Intégrité du SI.2.216 Superviser les systèmes de Le pare-feu 2.0.0

système et des l’organisation, notamment le trafic d’applications
informations des communications entrantes et web (WAF) doit
sortantes, pour détecter les attaques être activé pour
et les indicateurs d’attaques Application
potentielles. Gateway
stratégie
(GitHub)

sortantes, pour détecter les attaques utiliser le mode
et les indicateurs d’attaques spécifié pour
potentielles. Application
Gateway

sortantes, pour détecter les attaques utiliser le mode
et les indicateurs d’attaques spécifié pour
potentielles. Azure Front Door
Service
Intégrité du SI.2.217 Identifier les utilisations non Network Watcher 3.0.0

système et des autorisées des systèmes d’entreprise. doit être activé
informations
FedRAMP Niveau élevé

Pour voir le mappage entre les composants intégrés Azure Policy disponibles pour tous les
services Azure et cette norme de conformité, consultez Conformité réglementaire
d’Azure Policy – FedRAMP High. Pour plus d’informations sur cette norme de conformité,
consultez FedRAMP High .

stratégie
(GitHub)
Contrôle d’accès AC-4 Application du flux [Préversion] : L’ensemble du 3.0.0-

d’informations trafic Internet doit transiter par preview
votre Pare-feu Azure déployé
Contrôle d’accès AC-4 Application du flux les sous-réseaux doivent être 3.0.0
d’informations associés à un groupe de sécurité
réseau
Audit et AU-6 Révision, analyse et Network Watcher doit être 3.0.0

responsabilité rapports d’audit activé
stratégie
(GitHub)
Audit et AU-6 (4) Évaluation et analyse Network Watcher doit être 3.0.0
responsabilité centralisées activé
Audit et AU-6 (5) Fonctionnalités Network Watcher doit être 3.0.0

responsabilité d’intégration/analyse activé
et supervision
Audit et AU-12 Génération de l’audit Network Watcher doit être 3.0.0

responsabilité activé
Audit et AU-12 Piste d’audit corrélée Network Watcher doit être 3.0.0
responsabilité (1) au temps/à l’échelle activé
du système
Protection du SC-5 Protection contre le Azure DDoS Protection Standard 3.0.0

système et des déni de service doit être activé
communications
Protection du SC-5 Protection contre le Azure Web Application Firewall 1.0.2

système et des déni de service doit être activé pour les points
communications d’entrée Azure Front Door
Protection du SC-5 Protection contre le Le pare-feu d’applications web 2.0.0

système et des déni de service (WAF) doit être activé pour
communications Application Gateway
Protection du SC-7 Protection de la [Préversion] : L’ensemble du 3.0.0-

système et des limite trafic Internet doit transiter par preview
communications votre Pare-feu Azure déployé
Protection du SC-7 Protection de la Azure Web Application Firewall 1.0.2

système et des limite doit être activé pour les points
Protection du SC-7 Protection de la les sous-réseaux doivent être 3.0.0

système et des limite associés à un groupe de sécurité
communications réseau
Protection du SC-7 Protection de la Le pare-feu d’applications web 2.0.0

système et des limite (WAF) doit être activé pour
Protection du SC-7 (3) Points d’accès [Préversion] : L’ensemble du 3.0.0-

système et des trafic Internet doit transiter par preview
communications votre Pare-feu Azure déployé
stratégie
(GitHub)
Protection du SC-7 (3) Points d’accès Azure Web Application Firewall 1.0.2
système et des doit être activé pour les points
Protection du SC-7 (3) Points d’accès les sous-réseaux doivent être 3.0.0
système et des associés à un groupe de sécurité
Protection du SC-7 (3) Points d’accès Le pare-feu d’applications web 2.0.0

système et des (WAF) doit être activé pour
Intégrité du SI-4 Surveillance du [Préversion] : L’ensemble du 3.0.0-

système et des système trafic Internet doit transiter par preview
informations d’information votre Pare-feu Azure déployé
Intégrité du SI-4 Surveillance du Network Watcher doit être 3.0.0

système et des système activé
informations d’information
FedRAMP Niveau modéré

d’Azure Policy – FedRAMP Moderate. Pour plus d’informations sur cette norme de
conformité, consultez FedRAMP Moderate .

stratégie
(GitHub)
Contrôle d’accès AC-4 Application du [Préversion] : L’ensemble du trafic 3.0.0-

flux Internet doit transiter par votre Pare- preview
d’informations feu Azure déployé
Contrôle d’accès AC-4 Application du les sous-réseaux doivent être associés 3.0.0
flux à un groupe de sécurité réseau
d’informations
Audit et AU-6 Révision, Network Watcher doit être activé 3.0.0

responsabilité analyse et
rapports
d’audit
stratégie
(GitHub)
Audit et AU-12 Génération de Network Watcher doit être activé 3.0.0

responsabilité l’audit
Protection du SC-5 Protection Azure DDoS Protection Standard doit 3.0.0

système et des contre le déni être activé
communications de service
Protection du SC-5 Protection Azure Web Application Firewall doit 1.0.2

système et des contre le déni être activé pour les points d’entrée
communications de service Azure Front Door
Protection du SC-5 Protection Le pare-feu d’applications web (WAF) 2.0.0

système et des contre le déni doit être activé pour Application
communications de service Gateway
Protection du SC-7 Protection de [Préversion] : L’ensemble du trafic 3.0.0-

système et des la limite Internet doit transiter par votre Pare- preview
communications feu Azure déployé
Protection du SC-7 Protection de Azure Web Application Firewall doit 1.0.2

système et des la limite être activé pour les points d’entrée
communications Azure Front Door
Protection du SC-7 Protection de les sous-réseaux doivent être associés 3.0.0

système et des la limite à un groupe de sécurité réseau
communications
Protection du SC-7 Protection de Le pare-feu d’applications web (WAF) 2.0.0

système et des la limite doit être activé pour Application
communications Gateway
Protection du SC-7 (3) Points d’accès [Préversion] : L’ensemble du trafic 3.0.0-

système et des Internet doit transiter par votre Pare- preview
communications feu Azure déployé
Protection du SC-7 (3) Points d’accès Azure Web Application Firewall doit 1.0.2
système et des être activé pour les points d’entrée
communications Azure Front Door
Protection du SC-7 (3) Points d’accès les sous-réseaux doivent être associés 3.0.0
système et des à un groupe de sécurité réseau
communications
Protection du SC-7 (3) Points d’accès Le pare-feu d’applications web (WAF) 2.0.0
système et des doit être activé pour Application
communications Gateway
stratégie
(GitHub)
Intégrité du SI-4 Surveillance du [Préversion] : L’ensemble du trafic 3.0.0-

système et des système Internet doit transiter par votre Pare- preview
informations d’information feu Azure déployé
Intégrité du SI-4 Surveillance du Network Watcher doit être activé 3.0.0

système et des système
informations d’information
HIPAA HITRUST 9.2

Azure Policy – HIPAA HITRUST 9.2. Pour plus d’informations sur cette norme de conformité,
consultez HIPAA HITRUST 9.2 .

stratégie
(GitHub)
08 0805.01m1Organizational.12- 0805.01m1Organisationnel.12- Les sous- 1.0.0

Protection 01.m 01.m 01.04 Access Control réseau réseaux de
réseau passerelle
ne doivent
pas être
configurés
avec un
groupe de
sécurité
réseau
08 0805.01m1Organizational.12- 0805.01m1Organisationnel.12- les sous- 3.0.0

Protection 01.m 01.m 01.04 Access Control réseau réseaux
réseau doivent
être
associés à
un groupe
de sécurité
réseau
stratégie
(GitHub)
08 0805.01m1Organizational.12- 0805.01m1Organisationnel.12- Les 1.0.0

Protection 01.m 01.m 01.04 Access Control réseau machines
réseau virtuelles
doivent
être
connectées
à un réseau
virtuel
approuvé
08 0806.01m2Organizational.12356- 0806.01m2Organisationnel.12356- Les sous- 1.0.0

Protection 01.m 01.m 01.04 Access Control réseau réseaux de
réseau passerelle
ne doivent
pas être
configurés
avec un
groupe de
sécurité
réseau
08 0806.01m2Organizational.12356- 0806.01m2Organisationnel.12356- les sous- 3.0.0

Protection 01.m 01.m 01.04 Access Control réseau réseaux
réseau doivent
être
associés à
un groupe
de sécurité
réseau
08 0806.01m2Organizational.12356- 0806.01m2Organisationnel.12356- Les 1.0.0

Protection 01.m 01.m 01.04 Access Control réseau machines
réseau virtuelles
doivent
être
connectées
à un réseau
virtuel
approuvé
stratégie
(GitHub)
08 0809.01n2Organizational.1234- 0809.01n2Organisationnel.1234- les sous- 3.0.0

Protection 01.n 01.n 01.04 Access Control réseau réseaux
réseau doivent
être
associés à
un groupe
de sécurité
réseau
08 0809.01n2Organizational.1234- 0809.01n2Organisationnel.1234- Les 1.0.0

Protection 01.n 01.n 01.04 Access Control réseau machines
réseau virtuelles
doivent
être
connectées
à un réseau
virtuel
approuvé
08 0810.01n2Organizational.5-01.n 0810.01n2Organisationnel.5-01.n les sous- 3.0.0

Protection 01.04 Access Control réseau réseaux
réseau doivent
être
associés à
un groupe
de sécurité
réseau
08 0810.01n2Organizational.5-01.n 0810.01n2Organisationnel.5-01.n Les 1.0.0

Protection 01.04 Access Control réseau machines
réseau virtuelles
doivent
être
connectées
à un réseau
virtuel
approuvé

réseau doivent
être
associés à
un groupe
de sécurité
réseau
stratégie
(GitHub)

réseau virtuelles
doivent
être
connectées
à un réseau
virtuel
approuvé

réseau doivent
être
associés à
un groupe
de sécurité
réseau

réseau virtuelles
doivent
être
connectées
à un réseau
virtuel
approuvé

réseau doivent
être
associés à
un groupe
de sécurité
réseau
stratégie
(GitHub)

réseau virtuelles
doivent
être
connectées
à un réseau
virtuel
approuvé
08 0837.09.n2Organizational.2-09.n 0837.09.n2Organisationnel.2-09.n Network 3.0.0

Protection 09.06 Gestion de la sécurité Watcher
réseau réseau doit être
activé
08 0860.09m1Organizational.9-09.m 0860.09m1Organisationnel.9-09.m Déployer 2.0.1

Protection 09.06 Gestion de la sécurité des
réseau réseau paramètres
de
diagnostic
pour les
groupes de
sécurité
réseau
08 0886.09n2Organizational.4-09.n 0886.09n2Organisationnel.4-09.n Network 3.0.0

activé
08 0888.09n2Organizational.6-09.n 0888.09n2Organisationnel.6-09.n Network 3.0.0

activé
08 0894.01m2Organizational.7-01.m 0894.01m2Organisationnel.7-01.m Déployer 1.0.0

Protection 01.04 Access Control réseau Network
réseau Watcher
lors de la
création de
réseaux
virtuels
stratégie
(GitHub)
08 0894.01m2Organizational.7-01.m 0894.01m2Organisationnel.7-01.m Les sous- 1.0.0

Protection 01.04 Access Control réseau réseaux de
réseau passerelle
ne doivent
pas être
configurés
avec un
groupe de
sécurité
réseau
08 0894.01m2Organizational.7-01.m 0894.01m2Organisationnel.7-01.m les sous- 3.0.0

réseau doivent
être
associés à
un groupe
de sécurité
réseau
08 0894.01m2Organizational.7-01.m 0894.01m2Organisationnel.7-01.m Les 1.0.0

réseau virtuelles
doivent
être
connectées
à un réseau
virtuel
approuvé
IRS 1075 septembre 2016

Azure répondent à cette norme de conformité, consultez Conformité réglementaire Azure
Policy – IRS 1075 septembre 2016. Pour plus d’informations sur cette norme de conformité,
consultez IRS 1075 septembre 2016 .

contrôle (Portail Azure) la
stratégie
(GitHub)
contrôle (Portail Azure) la
stratégie
(GitHub)
Protection du système 9.3.16.4 Protection contre le Azure DDoS Protection 3.0.0

et des communications déni de service (SC- Standard doit être
5) activé
New Zealand ISM Restricted

Azure correspondent à cette norme de conformité, consultez Conformité réglementaire
Azure Policy – New Zealand ISM Restricted. Pour plus d’informations sur cette norme de
conformité, consultez New Zealand ISM Restricted .

stratégie
(GitHub)
Sécurité NS-5 18.3.19 Contenu d’un plan Azure DDoS Protection Standard 3.0.0
du réseau de réponse aux attaques doit être activé
par déni de service (DoS)
Sécurité NS-7 18.4.8 IDS/IPS sur les Le pare-feu d’applications web 2.0.0
du réseau passerelles (WAF) doit être activé pour
Application Gateway
du réseau passerelles (WAF) doit utiliser le mode spécifié
pour Application Gateway
du réseau passerelles (WAF) doit utiliser le mode spécifié
pour Azure Front Door Service
Sécurité GS-3 19.1.12 Configuration des les sous-réseaux doivent être 3.0.0
de passerelles associés à un groupe de sécurité
passerelle réseau
NIST SP 800-53 Rev. 5

d’Azure Policy – NIST SP 800-53 Rev. 5. Pour plus d’informations sur cette norme de
conformité, consultez NIST SP 800-53 Rev. 5 .
stratégie
(GitHub)
Contrôle d’accès AC-4 Application du flux [Préversion] : L’ensemble du trafic 3.0.0-

d’informations Internet doit transiter par votre preview
Pare-feu Azure déployé
Contrôle d’accès AC-4 Application du flux les sous-réseaux doivent être 3.0.0
d’informations associés à un groupe de sécurité
réseau
Audit et AU-6 Révision, analyse et Network Watcher doit être 3.0.0

responsabilité rapports activé
d’enregistrements
d’audit
Audit et AU-6 (4) Évaluation et Network Watcher doit être 3.0.0

responsabilité analyse centralisées activé
Audit et AU-6 (5) Analyse intégrée des Network Watcher doit être 3.0.0
responsabilité enregistrements activé
d’audit
Audit et AU-12 Génération Network Watcher doit être 3.0.0

responsabilité d’enregistrements activé
d’audit
Audit et AU-12 Piste d’audit Network Watcher doit être 3.0.0

responsabilité (1) corrélée au temps et activé
à l’échelle du
système
Protection du SC-5 Protection contre le Azure DDoS Protection Standard 3.0.0

système et des déni de service doit être activé
communications
Protection du SC-5 Protection contre le Azure Web Application Firewall 1.0.2

système et des déni de service doit être activé pour les points
Protection du SC-5 Protection contre le Le pare-feu d’applications web 2.0.0

système et des déni de service (WAF) doit être activé pour
Protection du SC-7 Protection de la [Préversion] : L’ensemble du trafic 3.0.0-

système et des limite Internet doit transiter par votre preview
communications Pare-feu Azure déployé
Protection du SC-7 Protection de la Azure Web Application Firewall 1.0.2

système et des limite doit être activé pour les points
stratégie
(GitHub)
Protection du SC-7 Protection de la les sous-réseaux doivent être 3.0.0

système et des limite associés à un groupe de sécurité
Protection du SC-7 Protection de la Le pare-feu d’applications web 2.0.0

système et des limite (WAF) doit être activé pour
Protection du SC-7 (3) Points d’accès [Préversion] : L’ensemble du trafic 3.0.0-

système et des Internet doit transiter par votre preview
communications Pare-feu Azure déployé
Protection du SC-7 (3) Points d’accès Azure Web Application Firewall 1.0.2
système et des doit être activé pour les points
Protection du SC-7 (3) Points d’accès les sous-réseaux doivent être 3.0.0
système et des associés à un groupe de sécurité
Protection du SC-7 (3) Points d’accès Le pare-feu d’applications web 2.0.0

système et des (WAF) doit être activé pour
Intégrité du SI-4 Supervision du [Préversion] : L’ensemble du trafic 3.0.0-

système et des système Internet doit transiter par votre preview
informations Pare-feu Azure déployé
Intégrité du SI-4 Supervision du Network Watcher doit être 3.0.0

système et des système activé
informations
NZ ISM Restricted v3.5

Pour évaluer comment les éléments intégrés Azure Policy disponibles pour tous les services
Azure correspondent à cette norme de conformité, consultez Conformité réglementaire
Azure Policy – NZ ISM Restreint v3.5. Pour plus d’informations sur cette norme de
conformité, consultez NZ ISM Restricted v3.5 .

stratégie
(GitHub)
stratégie
(GitHub)
Sécurité Point de 19.1.12 Configuration les sous-réseaux doivent être 3.0.0

de référence de des passerelles associés à un groupe de sécurité
passerelle la sécurité réseau
NZISM GS-3
Sécurité Point de 18.3.19 Contenu d’un Azure DDoS Protection Standard 3.0.0
du réseau référence de plan de réponse aux doit être activé
la sécurité attaques par déni de
NZISM NS-5 service (DoS)
Sécurité Point de 18.4.8 IDS/IPS sur les Azure Web Application Firewall 1.0.2
du réseau référence de passerelles doit être activé pour les points
la sécurité d’entrée Azure Front Door
NZISM NS-8
Sécurité Point de 18.4.8 IDS/IPS sur les Le pare-feu d’applications web 2.0.0
du réseau référence de passerelles (WAF) doit être activé pour
la sécurité Application Gateway
NZISM NS-8
du réseau référence de passerelles (WAF) doit utiliser le mode
la sécurité spécifié pour Application
NZISM NS-8 Gateway
du réseau référence de passerelles (WAF) doit utiliser le mode
la sécurité spécifié pour Azure Front Door
NZISM NS-8 Service
Reserve Bank of India – Infrastructure

informatique pour NBFC
Pour évaluer comment les composants intégrés Azure Policy disponibles de tous les
services Azure répondent à cette norme de conformité, consultez Conformité réglementaire
Azure Policy - Reserve Bank of India - Infrastructure informatique pour NBFC. Pour plus
d’informations sur cette norme de conformité, consultez Reserve Bank of India -
Infrastructure informatique pour NBFC .

stratégie
(GitHub)
stratégie
(GitHub)
Gouvernance Infrastructure Gouvernance [Préversion] : L’ensemble du trafic 3.0.0-

informatique informatique informatique-1.1 Internet doit transiter par votre preview
RBI 1.1 Pare-feu Azure déployé
Informations RBI IT Traçages-3.1 Les journaux de flux doivent être 1.1.0

et Framework configurés pour chaque groupe
cybersécurité 3.1.g de sécurité réseau
Informations RBI IT Traçages-3.1 Les journaux de flux doivent être 1.0.0

et Framework activés pour chaque groupe de
cybersécurité 3.1.g sécurité réseau
Informations RBI IT Traçages-3.1 Traffic Analytics doit être activé 1.0.0

et Framework pour les journaux de flux Network
cybersécurité 3.1.g Watcher
Audit IS Infrastructure Stratégie pour [Préversion] : L’ensemble du trafic 3.0.0-

informatique l’audit du système Internet doit transiter par votre preview
RBI 5 d’information (audit Pare-feu Azure déployé
IS)-5
Audit IS Infrastructure Stratégie pour Azure Web Application Firewall 1.0.2

informatique l’audit du système doit être activé pour les points
RBI 5 d’information (audit d’entrée Azure Front Door
IS)-5
Audit IS Infrastructure Stratégie pour Les journaux de flux doivent être 1.1.0
informatique l’audit du système configurés pour chaque groupe
RBI 5 d’information (audit de sécurité réseau
IS)-5
Audit IS Infrastructure Stratégie pour Les journaux de flux doivent être 1.0.0
informatique l’audit du système activés pour chaque groupe de
RBI 5 d’information (audit sécurité réseau
IS)-5
Audit IS Infrastructure Stratégie pour les sous-réseaux doivent être 3.0.0

informatique l’audit du système associés à un groupe de sécurité
RBI 5 d’information (audit réseau
IS)-5
Audit IS Infrastructure Stratégie pour Le pare-feu d’applications web 2.0.0

informatique l’audit du système (WAF) doit être activé pour
RBI 5 d’information (audit Application Gateway
IS)-5
stratégie
(GitHub)

informatique l’audit du système (WAF) doit utiliser le mode
RBI 5 d’information (audit spécifié pour Application
IS)-5 Gateway

informatique l’audit du système (WAF) doit utiliser le mode
RBI 5 d’information (audit spécifié pour Azure Front Door
IS)-5 Service
Banque de réserve de l’Inde – Infrastructure

informatique pour les banques v2016
Policy - RBI ITF Banks v2016. Pour plus d’informations sur cette norme de conformité,
consultez RBI ITF Banks v2016 (PDF) .

stratégie
(GitHub)
Gestion et sécurité Inventaire réseau- [Préversion] : L’ensemble du 3.0.0-

du réseau 4.2 trafic Internet doit transiter par preview
Gestion et sécurité Protection et [Préversion] : L’ensemble du 3.0.0-

du réseau détection de trafic Internet doit transiter par preview
périmètre-4.10 votre Pare-feu Azure déployé
Défense et gestion Advanced Real- [Préversion] : L’ensemble du 3.0.0-

des menaces en Timethreat trafic Internet doit transiter par preview
temps réel Defenceand votre Pare-feu Azure déployé
avancées Management-13.3
Défense et gestion Advanced Real- [Préversion] : L’ensemble du 3.0.0-

des menaces en Timethreat trafic Internet doit transiter par preview
temps réel Defenceand votre Pare-feu Azure déployé
stratégie
(GitHub)
Gestion et sécurité Détection [Préversion] : L’ensemble du 3.0.0-

du réseau d’anomalie-4.7 trafic Internet doit transiter par preview
Gestion et sécurité Gestion de la [Préversion] : L’ensemble du 3.0.0-

du réseau configuration des trafic Internet doit transiter par preview
appareils réseau-4.3 votre Pare-feu Azure déployé
Gestion des Récupération à Azure DDoS Protection Standard 3.0.0

incidents & partir de cyber - doit être activé
réponses aux Incidents-19.6b
incidents
Exploration Forensique-22.1 Azure DDoS Protection Standard 3.0.0

doit être activé
Gestion et sécurité Gestion de la La stratégie de pare-feu Azure 1.0.0

du réseau configuration des doit activer l’inspection TLS dans
appareils réseau-4.3 les règles d’application
Défense et gestion Advanced Real- Azure Web Application Firewall 1.0.2

des menaces en Timethreat doit être activé pour les points
temps réel Defenceand d’entrée Azure Front Door
Gestion et sécurité Détection Azure Web Application Firewall 1.0.2

du réseau d’anomalie-4.7 doit être activé pour les points
d’entrée Azure Front Door
Gestion et sécurité Protection et Azure Web Application Firewall 1.0.2

du réseau détection de doit être activé pour les points
périmètre-4.10 d’entrée Azure Front Door
Gestion et sécurité Gestion de la Azure Web Application Firewall 1.0.2

du réseau configuration des doit être activé pour les points
appareils réseau-4.3 d’entrée Azure Front Door
Maintenance, Maintenance, Les journaux de flux doivent être 1.1.0

surveillance et surveillance et configurés pour chaque groupe
analyse des analyse des de sécurité réseau
journaux d’audit journaux d’audit-
16.1
stratégie
(GitHub)

16.1

16.1

surveillance et surveillance et activés pour chaque groupe de
analyse des analyse des sécurité réseau
16.1
Stratégie de Stratégie de Les journaux de flux doivent être 1.0.0

prévention des prévention des activés pour chaque groupe de
fuites de données fuites de données- sécurité réseau
15.1

16.1
Stratégie de Stratégie de Les journaux de flux doivent être 1.0.0

prévention des prévention des activés pour chaque groupe de
fuites de données fuites de données- sécurité réseau
15.1

16.1
Gestion et sécurité Inventaire réseau- Traffic Analytics doit être activé 1.0.0
du réseau 4.2 pour les journaux de flux
Network Watcher
stratégie
(GitHub)
Maintenance, Maintenance, Traffic Analytics doit être activé 1.0.0

surveillance et surveillance et pour les journaux de flux
analyse des analyse des Network Watcher
16.1

16.1

16.1
Gestion et sécurité Centre d’opérations Network Watcher doit être 3.0.0

du réseau de sécurité-4.9 activé
Systèmes de Systèmes de les sous-réseaux doivent être 3.0.0

messagerie et de messagerie et de associés à un groupe de sécurité
messagerie messagerie réseau
sécurisés sécurisés-10.1
Gestion et sécurité Gestion de la les sous-réseaux doivent être 3.0.0

du réseau configuration des associés à un groupe de sécurité
appareils réseau-4.3 réseau
Gestion et sécurité Détection les sous-réseaux doivent être 3.0.0

du réseau d’anomalie-4.7 associés à un groupe de sécurité
réseau
Systèmes de Systèmes de les sous-réseaux doivent être 3.0.0

messagerie et de messagerie et de associés à un groupe de sécurité
messagerie messagerie réseau
sécurisés sécurisés-10.2
Advanced Real- Advanced Real- les sous-réseaux doivent être 3.0.0

Timethreat Timethreat associés à un groupe de sécurité
Defenceand Defenceand réseau
Management Management-13.4
stratégie
(GitHub)
Advanced Real- Advanced Real- les sous-réseaux doivent être 3.0.0

Timethreat Timethreat associés à un groupe de sécurité
Defenceand Defenceand réseau
Management Management-13.3
Gestion et sécurité Protection et les sous-réseaux doivent être 3.0.0

du réseau détection de associés à un groupe de sécurité
périmètre-4.10 réseau
Défense et gestion Advanced Real- Le pare-feu d’applications web 2.0.0

des menaces en Timethreat (WAF) doit être activé pour
temps réel Defenceand Application Gateway
Cycle de vie de Cycle de vie de Le pare-feu d’applications web 2.0.0

sécurité des sécurité des (WAF) doit être activé pour
applications (Aslc) applications Application Gateway
(Aslc)-6.7
Gestion et sécurité Gestion de la Le pare-feu d’applications web 2.0.0

du réseau configuration des (WAF) doit être activé pour
appareils réseau-4.3 Application Gateway

sécurité des sécurité des (WAF) doit être activé pour
applications (Aslc) applications Application Gateway
(Aslc)-6.7
Gestion et sécurité Protection et Le pare-feu d’applications web 2.0.0

du réseau détection de (WAF) doit être activé pour
périmètre-4.10 Application Gateway
Gestion et sécurité Détection Le pare-feu d’applications web 2.0.0

du réseau d’anomalie-4.7 (WAF) doit être activé pour
Application Gateway
Cycle de vie de Cycle de vie de Web Application Firewall (WAF) 1.0.1

sécurité des sécurité des doit activer toutes les règles de
applications (Aslc) applications pare-feu pour Application
(Aslc)-6.7 Gateway
Gestion et sécurité Gestion de la Web Application Firewall (WAF) 1.0.1

du réseau configuration des doit activer toutes les règles de
appareils réseau-4.3 pare-feu pour Application
Gateway
stratégie
(GitHub)
Cycle de vie de Cycle de vie de Web Application Firewall (WAF) 1.0.1

sécurité des sécurité des doit activer toutes les règles de
applications (Aslc) applications pare-feu pour Application
(Aslc)-6.7 Gateway

sécurité des sécurité des (WAF) doit utiliser le mode
applications (Aslc) applications spécifié pour Application
(Aslc)-6.7 Gateway

sécurité des sécurité des (WAF) doit utiliser le mode
applications (Aslc) applications spécifié pour Application
(Aslc)-6.7 Gateway
RMIT Malaysia
Policy – RMIT Malaysia. Pour plus d’informations sur cette norme de conformité, consultez
RMIT Malaysia .

stratégie
(GitHub)
Résilience RMiT 10.33 Résilience réseau Les passerelles VPN Azure ne doivent 1.0.0
réseau - 10.33 pas utiliser la référence SKU « de
base »
Résilience RMiT 10.33 Résilience réseau Les journaux de flux doivent être 1.1.0
réseau - 10.33 configurés pour chaque groupe de
sécurité réseau
Résilience RMiT 10.33 Résilience réseau Les journaux de flux doivent être activés 1.0.0
réseau - 10.33 pour chaque groupe de sécurité
réseau
Résilience RMiT 10.33 Résilience réseau les sous-réseaux doivent être associés à 3.0.0
réseau - 10.33 un groupe de sécurité réseau
stratégie
(GitHub)
Résilience RMiT 10.33 Résilience réseau Les machines virtuelles doivent être 1.0.0
réseau - 10.33 connectées à un réseau virtuel
approuvé
Résilience RMiT 10.33 Résilience réseau Les réseaux virtuels doivent utiliser la 1.0.0
réseau - 10.33 passerelle de réseau virtuel spécifiée
Résilience RMiT 10.35 Résilience réseau Network Watcher doit être activé 3.0.0
réseau - 10.35
Résilience RMiT 10.39 Résilience réseau Une stratégie IPsec/IKE personnalisée 1.0.0
réseau - 10.39 doit être appliquée à toutes les
connexions de passerelle de réseau
virtuel Azure
Déni de RMiT 11.13 Attaque par déni Azure Web Application Firewall doit 1.0.2
service de service être activé pour les points d’entrée
distribué distribué (DDoS) Azure Front Door
(DDoS) - 11.13
Centre des RMiT 11.18 Centre des Azure DDoS Protection Standard doit 3.0.0
opérations opérations de être activé
de sécurité sécurité (SOC) -
(SOC) 11.18
Centre des RMiT 11.18 Centre des Azure DDoS Protection Standard doit 3.0.0
opérations opérations de être activé
de sécurité sécurité (SOC) -
(SOC) 11.18
Mesures de RMiT Mesures de Une stratégie IPsec/IKE personnalisée 1.0.0

contrôle de Annexe 5.5 contrôle de la doit être appliquée à toutes les
la cybersécurité - connexions de passerelle de réseau
cybersécurité Annexe 5.5 virtuel Azure
Mesures de RMiT - Mesures de Le pare-feu d’applications web (WAF) 2.0.0

contrôle de Annexe 5.6 contrôle de la doit être activé pour Application
la cybersécurité - Gateway
cybersécurité Annexe 5.6

contrôle de Annexe 5.6 contrôle de la doit utiliser le mode spécifié pour
la cybersécurité - Application Gateway
stratégie
(GitHub)

contrôle de Annexe 5.6 contrôle de la doit utiliser le mode spécifié pour Azure
la cybersécurité - Front Door Service
Mesures de RMiT Mesures de Azure DDoS Protection Standard doit 3.0.0

contrôle de Annexe 5.7 contrôle de la être activé
la cybersécurité -
Mesures de RMiT Mesures de Les journaux de flux doivent être 1.1.0

contrôle de Annexe 5.7 contrôle de la configurés pour chaque groupe de
la cybersécurité - sécurité réseau
Mesures de RMiT Mesures de Les journaux de flux doivent être activés 1.0.0
contrôle de Annexe 5.7 contrôle de la pour chaque groupe de sécurité
la cybersécurité - réseau
Mesures de RMiT Mesures de les sous-réseaux doivent être associés à 3.0.0

contrôle de Annexe 5.7 contrôle de la un groupe de sécurité réseau
la cybersécurité -
UK OFFICIAL et UK NHS
Policy – UK OFFICIAL et UK NHS. Pour plus d’informations sur cette norme de conformité,
consultez UK OFFICIAL .
Domain ID du Titre du contrôle Policy Version de la

contrôle (Portail Azure) stratégie
(GitHub)
Sécurité 5.3 Surveillance à des fins Azure DDoS Protection 3.0.0

opérationnelle de protection Standard doit être activé
Étapes suivantes
Apprenez-en davantage sur la Conformité réglementaire d’Azure Policy.
Consultez les définitions intégrées dans le dépôt Azure Policy de GitHub .
Extension de sous-réseau
Article • 06/04/2023
La migration des charges de travail vers le cloud public requiert une planification et une
coordination rigoureuses. L’une des principales considérations à prendre en compte est
la possibilité de conserver vos adresses IP. Ce qui peut être important surtout si vos
applications ont une dépendance d’adresse IP ou si vous avez des exigences de
conformité pour utiliser des adresses IP spécifiques. Le réseau virtuel Azure résout ce
problème pour vous en vous permettant de créer des réseaux virtuels et des sous-
réseaux avec une plage d’adresses IP de votre choix.
Les migrations peuvent être délicates lorsque la condition requise ci-dessus est couplée
à une exigence supplémentaire pour conserver certaines applications localement. Dans
ce type de situation, vous devez fractionner les applications entre Azure et en local, sans
renuméroter les adresses IP de chaque côté. En outre, vous devez autoriser les
applications à communiquer comme si elles se trouvaient sur le même réseau.
Une solution au problème ci-dessus est l’extension de sous-réseau. L’extension d’un

réseau permet aux applications de communiquer sur le même domaine de diffusion
lorsqu’elles se trouvent à des emplacements physiques différents, ce qui évite de devoir
remanier la topologie de votre réseau.
Bien que l’extension de votre réseau ne soit généralement pas une bonne pratique, les
cas d’usage suivants peuvent être nécessaires.
Migration échelonnée : Le scénario le plus courant est que vous souhaitez

échelonner votre migration. Vous souhaitez placer quelques applications en
premier et au fil du temps migrer les autres applications vers Azure.
Latence : Les exigences de faible latence peuvent être une autre raison pour
laquelle vous souhaitez conserver certaines applications localement, afin de vous
assurer qu’elles sont aussi proches que possible de votre centre de données.
Conformité : Dans un autre cas d’utilisation, vous pouvez avoir des exigences de
conformité et souhaiter conserver certaines de vos applications localement.
７ Notes
Vous ne devez pas étendre vos sous-réseaux, sauf si cela est nécessaire. Dans les
cas où vous étendez vos sous-réseaux, vous devez essayer d’en faire une étape
intermédiaire. Avec le temps, vous devez essayer de renuméroter les applications
sur votre réseau local et de les migrer vers Azure.
Dans la section suivante, nous allons aborder la façon dont vous pouvez étendre vos
sous-réseaux dans Azure.
Étendre votre sous-réseau à Azure

Vous pouvez étendre vos sous-réseaux locaux à Azure à l’aide d’une solution basée sur
un réseau de superposition de couche 3. La plupart des solutions utilisent une
technologie de superposition telle que VXLAN pour étendre le réseau de couche 2 à
l’aide d’un réseau de superposition de couche 3. Le diagramme suivant illustre une
solution généralisée. Dans cette solution, le même sous-réseau existe des deux côtés,
côté Azure et en local.
Les adresses IP du sous-réseau sont attribuées aux machines virtuelles sur Azure et en
local. La solution Azure et la solution locale ont une appliance virtuelle réseau insérée
dans leurs réseaux. Quand une machine virtuelle dans Azure tente de communiquer
avec une machine virtuelle dans un réseau local, l’appliance virtuelle réseau Azure
capture le paquet, l’encapsule et l’envoie via un routage VPN/Express vers le réseau
local. L’appliance virtuelle réseau locale reçoit le paquet, le désencapsule et le transmet
au destinataire prévu dans son réseau. Le trafic de retour utilise un chemin d’accès et
une logique similaires.
Dans l’exemple ci-dessus, l’appliance virtuelle réseau Azure et l’appliance virtuelle réseau
locale communiquent et apprennent les adresses IP les unes après les autres. Des
réseaux plus complexes peuvent également avoir un service de mappage, qui gère le
mappage entre les appliances virtuelles réseau et les adresses IP qui se trouvent derrière
elles. Lorsqu’une appliance virtuelle réseau reçoit un paquet, elle interroge le service de
mappage pour connaître l’adresse de l’appliance virtuelle réseau qui possède l’adresse
IP de destination en arrière-plan.
Dans la section suivante, vous trouverez des informations sur les solutions d’extension
de sous-réseau que nous avons testées sur Azure.
Étapes suivantes
Étendez vos sous-réseaux locaux dans Azure à l’aide du réseau étendu Azure.
Qu’est-ce que la délégation de sous-
réseau ?
Article • 15/05/2023
La délégation de sous-réseau vous permet de désigner un sous-réseau spécifique pour

un service PaaS Azure de votre choix qui doit être injecté dans votre réseau virtuel. La
délégation de sous-réseau offre un contrôle total au client sur la gestion de l’intégration
des services Azure à ses réseaux virtuels.
Lorsque vous déléguez un sous-réseau à un service Azure, vous permettez à ce service

d’établir des règles de configuration de réseau de base pour ce sous-réseau, ce qui
permet au service Azure de faire fonctionner ses instances de manière stable. Par
conséquent, le service Azure peut établir certaines des conditions pré- ou post-
déploiement suivantes :
Déployer le service dans un sous-réseau partagé versus dédié.
Ajouter au service, après le déploiement, un ensemble de stratégies d’intention de

réseau requis pour que le service fonctionne correctement.
Avantages de la délégation de sous-réseau

La délégation d’un sous-réseau à des services spécifiques offre les avantages suivants :
Cela permet de désigner un sous-réseau pour un ou plusieurs services Azure et de

gérer les instances dans le sous-réseau conformément aux exigences. Par exemple,
le propriétaire du réseau virtuel peut définir les stratégies et options suivantes
pour un sous-réseau délégué afin d’améliorer la gestion des ressources :
Stratégies de filtrage du trafic réseau avec les groupes de sécurité réseau.
Stratégies de routage avec des itinéraires définis par l’utilisateur.
Intégration de services aux configurations des points de terminaison de service.
Cela permet aux services injectés de mieux intégrer le réseau virtuel en définissant
les conditions préalables aux déploiements sous la forme de stratégies d’intention
de réseau. Cette stratégie garantit que toutes les actions susceptibles d’affecter le
fonctionnement du service injecté peuvent être bloquées au moment de
l’opération PUT.
Qui peut déléguer ?
La délégation de sous-réseau est un exercice que les propriétaires de réseau virtuel
doivent effectuer pour désigner un des sous-réseaux pour un service Azure spécifique.
Le service Azure déploie ensuite les instances dans ce sous-réseau à des fins de
consommation par les charges de travail des clients.
Effet de la délégation de sous-réseau sur votre

sous-réseau
Chaque service Azure définit son propre modèle de déploiement, dans lequel il peut
définir les propriétés qu’il prend ou ne prend pas en charge dans un sous-réseau
délégué à des fins d’injection, comme suit :
Il prend en charge un sous-réseau partagé avec d’autres services ou machines

virtuelles/groupes de machines virtuelles identiques Azure dans le même sous-
réseau, ou uniquement un sous-réseau dédié avec uniquement des instances de ce
service.
Il prend en charge l’association NSG avec le sous-réseau délégué.
Il prend en charge le fait que le NSG associé au sous-réseau délégué peut

également être associé à n’importe quel autre sous-réseau.
Il assure l’association de tables de routage avec le sous-réseau délégué.
Il permet à la table de routage associée au sous-réseau délégué d’être associée à

n’importe quel autre sous-réseau.
Il détermine le nombre minimal d’adresses IP dans le sous-réseau délégué.
Il indique que l’espace d’adressage IP dans le sous-réseau délégué doit provenir de

l’espace d’adressage IP privé (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12).
Il exige que la configuration DNS personnalisée dispose d’une entrée Azure DNS.
Il exige que la délégation soit supprimée avant que le sous-réseau ou le réseau

virtuel puisse être supprimé.
Il ne peut pas être utilisé avec un point de terminaison privé si le sous-réseau est
délégué.
Les services injectés peuvent également ajouter leurs propres stratégies comme suit :
Stratégies de sécurité : Collection de règles de sécurité requises pour le
fonctionnement d’un service donné.
Stratégies de routage : Collection d’itinéraires requis pour le fonctionnement d’un

service donné.
Actions que la délégation de sous-réseau ne

réalise pas
Les services Azure qui sont injectés dans un sous-réseau délégué disposent toujours de
l’ensemble de propriétés de base qui sont disponibles pour les sous-réseaux non
délégués, par exemple :
Les services Azure peuvent injecter des instances dans les sous-réseaux des clients,
mais ils ne peuvent pas affecter les charges de travail existantes.
Les stratégies ou itinéraires que ces services appliquent sont flexibles et peuvent
être remplacés par le client.
Étapes suivantes
Déléguer un sous-réseau
Réseaux virtuels et machines virtuelles
dans Azure
Article • 25/05/2023
Lorsque vous créez une machine virtuelle Azure, vous créez un réseau virtuel ou en
utilisez un existant. Déterminez la façon dont vos machines virtuelles doivent être
accessibles sur le réseau virtuel. Il est essentiel de planifier les choses avant de créer des
ressources et de vous assurer que vous connaissez les limites des ressources réseau.
Dans l’illustration suivante, les machines virtuelles sont représentées en tant que
serveurs web et serveurs d’applications. Chaque ensemble de machines virtuelles est
affecté à des sous-réseaux distincts dans le réseau virtuel.
Vous pouvez créer un réseau virtuel avant de créer une machine virtuelle, ou vous
pouvez créer le réseau virtuel lors de la création d’une machine virtuelle.
Vous créez ces ressources pour prendre en charge la communication avec une machine
virtuelle :
Interfaces réseau
Adresses IP
Réseau virtuel et sous-réseaux

Tenez également compte des ressources facultatives suivantes :
Équilibreurs de charge
Interfaces réseau
Une carte d’interface réseau (NIC) est l’interconnexion entre une machine virtuelle et un
réseau virtuel. Une machine virtuelle doit posséder au moins une carte d’interface
réseau. Une machine virtuelle peut avoir plusieurs cartes d’interface réseau, en fonction
de la taille de la machine virtuelle que vous créez. Pour en savoir plus sur le nombre de
cartes réseau prises en charge par chaque taille de machine virtuelle, consultez tailles de
machine virtuelle.
Vous pouvez créer une machine virtuelle avec plusieurs cartes réseau et ajouter ou
supprimer des cartes réseau tout au long du cycle de vie d’une machine virtuelle.
Plusieurs cartes réseau permettent à une machine virtuelle de se connecter à différents
sous-réseaux.
Chaque carte d’interface réseau attachée à une machine virtuelle doit se trouver dans le
même emplacement et abonnement que la machine virtuelle. Chaque carte d’interface
réseau doit être connectée à un réseau virtuel existant dans les mêmes emplacement et
abonnement Azure que la carte d’interface réseau. Vous pouvez modifier le sous-réseau
auquel la carte réseau est connectée après sa création. Vous ne pouvez pas modifier le
réseau virtuel. Chaque carte d’interface réseau attachée à une machine virtuelle est
attribuée à une adresse MAC qui ne change pas jusqu’à ce que la machine virtuelle soit
supprimée.
Ce tableau répertorie les méthodes que vous pouvez utiliser pour créer une interface
réseau.
Méthode Description
Azure Lorsque vous créez une machine virtuelle dans le Portail Azure, une interface réseau
portal est automatiquement créée pour vous. Le portail crée une machine virtuelle avec
une seule carte d’interface réseau. Si vous souhaitez créer une machine virtuelle avec
plusieurs cartes d’interface réseau, vous devez la créer en suivant une autre
méthode.
Azure Utilisez New-AzNetworkInterface avec le paramètre -PublicIpAddressId pour fournir

PowerShell l’identificateur de l’adresse IP publique que vous avez créée précédemment.
Azure CLI Pour fournir l’identificateur de l’adresse IP publique que vous avez créée
précédemment, utilisez az network nic create avec le paramètre --public-ip-
address .
Modèle Pour plus d’informations sur le déploiement d’une interface réseau à l’aide d’un
modèle, consultez Interface de réseau dans un Réseau virtuel avec une Adresse IP
publique .
Adresses IP
Vous pouvez attribuer ces types d’adresses IP à une interface réseau dans Azure :
Adresses IP publiques : utilisées pour la communication entrante et sortante (sans

traduction d’adresses réseau [NAT]) avec Internet et d’autres ressources Azure non
connectées à un réseau virtuel. L’attribution d’une adresse IP publique à une carte
d’interface réseau est facultative. Les adresses IP publiques ont un coût nominal et
il existe une limite maximum d’adresses IP publiques pouvant être utilisées par
abonnement.
Adresses IP privées : utilisées pour la communication au sein d’un réseau virtuel,

avec votre réseau local et Internet (sans NAT). Au moins une adresse IP privée doit
être affectée à une machine virtuelle. Pour en savoir plus sur la traduction
d’adresses réseau dans Azure, consultez Understanding outbound connections in
Azure (Comprendre les connexions sortantes dans Azure).
Vous pouvez affecter des adresses IP publiques aux :
Machines virtuelles
Équilibreurs de charge publics
Vous pouvez affecter des adresses IP privées aux :
Machines virtuelles
Équilibreurs de charge interne
Vous attribuez des adresses IP à une machine virtuelle à l’aide d’une interface réseau.
L’allocation d’une adresse IP à une ressource est possible à l’aide de deux méthodes :
dynamique ou statique. La méthode par défaut qui permet à Azure d’attribuer des
adresses IP est dynamique. Une adresse IP n’est pas spécifiée lors de sa création. Au lieu
de cela, l’adresse IP est allouée lorsque vous créez une machine virtuelle ou lorsque
vous démarrez une machine virtuelle arrêtée. L’adresse IP est libérée lorsque vous
arrêtez ou supprimez la machine virtuelle.
Pour vous assurer que l’adresse IP de la machine virtuelle ne change pas, vous pouvez
définir explicitement la méthode d’allocation sur statique. Dans ce cas, une adresse IP
est attribuée immédiatement. L’adresse est libérée uniquement quand vous supprimez
la machine virtuelle ou que vous définissez sa méthode d’allocation sur Dynamique.
Ce tableau répertorie les méthodes que vous pouvez utiliser pour créer une adresse IP.
Azure Par défaut, les adresses IP publiques sont dynamiques. L’adresse IP peut changer
portal lorsque la machine virtuelle est arrêtée ou supprimée. Pour vous assurer que la
machine virtuelle utilise toujours la même adresse IP publique, créez une adresse IP
publique statique. Par défaut, le portail attribue une adresse IP privée dynamique à
une carte d’interface réseau lors de la création d’une machine virtuelle. Vous pouvez
modifier cette adresse IP statique après la création de la machine virtuelle.
Azure Vous utilisez New-AzPublicIpAddress avec le paramètre -AllocationMethod défini sur

PowerShell la valeur Dynamique ou Statique.
Azure CLI Vous utilisez az network public-ip create avec le paramètre --allocation-method
défini sur la valeur Dynamique ou Statique.
Modèle Pour plus d’informations sur le déploiement d’une adresse IP publique à l’aide d’un
modèle, consultez Interface réseau dans un Réseau virtuel avec une Adresse IP
publique .
Après avoir créé une adresse IP publique, vous pouvez l’associer à une machine virtuelle
en l’attribuant à une carte d’interface réseau.
７ Notes
Réseau virtuel et sous-réseaux

Un sous-réseau est une plage d’adresses IP dans votre réseau virtuel. Vous pouvez
diviser un réseau virtuel en plusieurs sous-réseaux pour plus de sécurité et une meilleure
organisation. Chaque carte d’interface réseau dans une machine virtuelle est connectée
à un sous-réseau dans un réseau virtuel. Les cartes d’interface réseau connectées aux
sous-réseaux (identiques ou différents) au sein d’un réseau virtuel peuvent
communiquer entre elles sans aucun besoin de configuration supplémentaire.
Lorsque vous configurez un réseau virtuel, vous spécifiez la topologie, y compris les
sous-réseaux et les espaces d’adressage disponibles. Sélectionnez des plages d’adresses
qui ne se chevauchent pas si le réseau virtuel est connecté à d’autres réseaux virtuels ou
à des réseaux locaux. Les adresses IP sont privées et ne sont pas accessibles à partir
d’Internet. Azure traite toute plage d’adresses dans le cadre de l’espace d’adressage IP
du réseau virtuel privé. La plage d’adresses est accessible uniquement au sein du réseau
virtuel, au sein de réseaux virtuels interconnectés et à partir de votre emplacement local.
Si vous travaillez au sein d’une organisation dans laquelle une autre personne est
responsable des réseaux internes, vous devez discuter avec elle avant de sélectionner
votre espace d’adressage. Assurez-vous qu’il n’y a pas de chevauchement dans l’espace
d’adressage. Indiquez-lui l’espace que vous souhaitez utiliser afin qu’elle n’essaie pas
d’utiliser la même plage d’adresses IP que vous.
Il n’existe pas de limites de sécurité par défaut entre les sous-réseaux. Les machines
virtuelles de chacun de ces sous-réseaux peuvent communiquer. Si votre déploiement
requiert des limites de sécurité, utilisez des Groupes de sécurité réseau (NSG) , qui
contrôlent le flux du trafic vers et depuis les sous-réseaux et les machines virtuelles.
Ce tableau répertorie les méthodes que vous pouvez utiliser pour créer un réseau virtuel
et des sous-réseaux.
Azure Si vous autorisez Azure à créer un réseau virtuel lors de la création d’une machine
portal virtuelle, le nom attribué sera une combinaison du nom du groupe de ressources qui
contient le réseau virtuel et de -vnet . L’espace d’adressage est 10.0.0.0/24, le nom
du sous-réseau nécessaire est default, et la plage d’adresses de sous-réseau est
10.0.0.0/24.
Azure Vous utilisez New-AzVirtualNetworkSubnetConfig et New-AzVirtualNetwork pour

PowerShell créer un sous-réseau et un réseau virtuel. Vous pouvez également utiliser Add-
AzVirtualNetworkSubnetConfig pour ajouter un sous-réseau à un réseau virtuel
existant.
Azure CLI Le sous-réseau et le réseau virtuel sont créés en même temps. Fournissez un
paramètre --subnet-name à az network vnet create avec le nom du sous-réseau.
Modèle Pour plus d’informations sur l’utilisation d’un modèle pour créer un réseau virtuel et
des sous-réseaux, consultez Réseau virtuel avec deux sous-réseaux .

Un groupe de sécurité réseau contient une liste des règles de liste de contrôle d’accès
qui autorise ou rejette le trafic réseau vers les sous-réseaux, les cartes d’interface réseau
ou les deux. Des groupes de sécurité réseau peuvent être associés à des sous-réseaux
ou à des cartes d’interface réseau connectées à un sous-réseau. Lorsqu’un groupe de
sécurité réseau est associé à un sous-réseau, les règles de liste de contrôle d’accès
s’appliquent à toutes les machines virtuelles présentes dans ce sous-réseau. Le trafic
vers une carte d’interface réseau peut être limité par l’association directe d’un groupe de
sécurité réseau à une carte d’interface réseau.
Les NSG contiennent deux ensembles de règles : les règles de trafic entrant et les règles
de trafic sortant. La priorité d’une règle doit être unique dans chaque ensemble.
Chaque règle a des propriétés de :
Protocol
Plages de ports source et de destination
Préfixes d’adresse
Direction du trafic
Priority
Type d’accès
Tous les groupes de ressources réseau contiennent un ensemble de règles par défaut.
Vous ne pouvez pas supprimer ou remplacer ces règles par défaut, car elles ont la
priorité la plus faible et les règles que vous créez ne peuvent pas les remplacer.
Lorsque vous associez un groupe de sécurité réseau à une carte réseau, les règles
d’accès réseau du groupe de sécurité réseau sont appliquées uniquement à cette carte
d’interface réseau. Si un groupe de sécurité réseau est appliqué à une seule carte
d’interface réseau sur une machine virtuelle comprenant plusieurs cartes d’interface
réseau, celui-ci n’affecte pas le trafic lié aux autres cartes d’interface réseau. Vous
pouvez associer différents groupes de sécurité réseau à une carte d’interface réseau (ou
une machine virtuelle, selon le modèle de déploiement) et au sous-réseau auquel une
carte d’interface réseau ou une machine virtuelle est liée. La priorité est donnée en
fonction de la direction du trafic.
Veillez à planifier vos Groupes de sécurité réseau quand vous planifiez vos machines
virtuelles et le réseau virtuel.
Ce tableau répertorie les méthodes que vous pouvez utiliser pour créer un groupe de
sécurité réseau.
Azure Lorsque vous créez une machine virtuelle dans le portail Azure, un groupe de
portal sécurité réseau est automatiquement créé et associé à la carte d’interface réseau
créée par le portail. Le nom du groupe de sécurité réseau est une combinaison du
nom de la machine virtuelle et de -nsg .
Ce groupe de sécurité réseau contient une règle de trafic entrant :
avec priorité de 1 000.
Le service est défini sur RDP.
Le protocole est défini sur TCP.
Le port est défini sur 3 389.
L’action est définie sur Autoriser.
Si vous souhaitez autoriser tout autre trafic entrant vers la machine virtuelle, créez
une ou plusieurs règles.
Azure Utilisez New-AzNetworkSecurityRuleConfig et fournissez les informations de la règle

PowerShell requise. Utilisez New-AzNetworkSecurityGroup pour créer le groupe de sécurité
réseau. Utilisez Set-AzVirtualNetworkSubnetConfig pour configurer le groupe de
sécurité réseau du sous-réseau. Utilisez Set-AzVirtualNetwork pour ajouter le groupe
de sécurité réseau au réseau virtuel.
Azure CLI Utilisez az network nsg create pour créer initialement le groupe de sécurité réseau.
Utilisez az network nsg rule create pour ajouter des règles à un groupe de sécurité
réseau. Utilisez az network vnet subnet update pour ajouter le groupe de sécurité
réseau au sous-réseau.
Modèle Utilisez Create a Network Security Group comme guide pour le déploiement d’un
groupe de sécurité réseau à l’aide d’un modèle.
Équilibreurs de charge
Azure Load Balancer offre une haute disponibilité et des performances réseau élevées
pour vos applications. Un équilibrage de charge peut être configuré pour équilibrer le
trafic Internet entrant vers les machines virtuelles ou pour équilibrer le trafic entre les
machines virtuelles d’un réseau virtuel. Un équilibrage de charge peut également
équilibrer le trafic entre les machines virtuelles et les ordinateurs locaux d’un réseau
intersite ou transférer le trafic externe vers une machine virtuelle spécifique.
L’équilibreur de charge mappe le trafic entrant et sortant entre :
L’adresse IP publique et le port publics sur l’équilibreur de charge.
L’adresse IP privée et le port de la machine virtuelle.
Lorsque vous créez un équilibrage de charge, vous devez également prendre en compte
les éléments de configuration suivants :
Configuration d’une adresse IP frontale : un équilibrage de charge peut inclure

une ou plusieurs adresses IP frontales. Ces adresses IP servent d'entrée pour le
trafic.
Pool d’adresses principal : adresses IP qui sont associées à la carte d’interface

réseau vers laquelle la charge est distribuée.
Réacheminement de port : définit la manière dont le trafic entrant transite via

l’adresse IP frontale et est distribué à l’adresse IP principale en utilisant des règles
NAT de trafic entrant.
Règles d’équilibrage de charge : mappent une combinaison donnée d’adresses IP

et de ports frontaux vers un ensemble de combinaisons d’adresses IP et de port
principaux. Un même équilibreur de charge peut avoir plusieurs règles
d’équilibrage de charge. Chaque règle est une combinaison d’une adresse IP et
d’un port frontaux et d’une adresse IP et d’un port principaux associés aux
Sondes : surveillent l’intégrité des machines virtuelles. Lorsqu’une sonde ne répond

pas, l’équilibrage de charge n’envoie plus de nouvelles connexions aux machines
virtuelles défaillantes. Les connexions existantes ne sont pas affectées et les
nouvelles connexions sont envoyées aux machines virtuelles saines.
Règles de trafic sortant - Une règle de trafic sortant configure la traduction

d’adresses réseau (NAT) du trafic sortant pour que toutes les machines virtuelles
ou instances identifiées par le pool de back-ends de votre équilibreur de charge
De base soient traduites en front-end.
Ce tableau répertorie les méthodes que vous pouvez utiliser pour créer un équilibrage
de charge accessible sur Internet.
Portail Vous pouvez équilibrer la charge du trafic Internet sur les machines virtuelles avec le
Azure portail Azure.
Azure Utilisez New-AzLoadBalancerFrontendIpConfig avec le paramètre -PublicIpAddress

PowerShell pour fournir l’identificateur de l’adresse IP publique que vous avez créée
précédemment. Utilisez New-AzLoadBalancerBackendAddressPoolConfig pour créer
la configuration du pool d’adresses principal. Utilisez New-
AzLoadBalancerInboundNatRuleConfig pour créer des règles NAT de trafic entrant
associées à la configuration IP frontale que vous avez créée. Utilisez New-
AzLoadBalancerProbeConfig pour créer les sondes dont vous avez besoin. Utilisez
New-AzLoadBalancerRuleConfig pour créer la configuration d’équilibrage de charge.
Utilisez New-AzLoadBalancer pour créer l’équilibrage de charge.
Azure CLI Utilisez az network lb create pour créer la configuration d’équilibrage de charge
initiale. Utilisez az network lb frontend-ip create pour ajouter l’adresse IP publique
que vous avez créée précédemment. Utilisez az network lb address-pool create pour
ajouter la configuration du pool d’adresses principal. Utilisez az network lb inbound-
nat-rule create pour ajouter des règles de traduction d’adresses réseau. Utilisez az
network lb rule create pour ajouter les règles d’équilibrage de charge. Utilisez az
network lb probe create pour ajouter les sondes.
Modèle Utilisez 3 machines virtuelles dans un équilibreur de charge comme guide pour le
déploiement d’un équilibrage de charge à l’aide d’un modèle.
Ce tableau répertorie les méthodes que vous pouvez utiliser pour créer un équilibrage
de charge interne.
Portail Vous pouvez équilibrer la charge du trafic interne avec un équilibreur de charge sur
Azure le portail Azure.
Azure Pour fournir une adresse IP privée dans le sous-réseau du réseau, utilisez New-
PowerShell AzLoadBalancerFrontendIpConfig avec le paramètre -PrivateIpAddress . Utilisez
New-AzLoadBalancerBackendAddressPoolConfig pour créer la configuration du pool
d’adresses principal. Utilisez New-AzLoadBalancerInboundNatRuleConfig pour créer
des règles NAT de trafic entrant associées à la configuration IP frontale que vous
avez créée. Utilisez New-AzLoadBalancerProbeConfig pour créer les sondes dont
vous avez besoin. Utilisez New-AzLoadBalancerRuleConfig pour créer la
configuration d’équilibrage de charge. Utilisez New-AzLoadBalancer pour créer
l’équilibrage de charge.
Azure CLI Utilisez la commande az network lb create pour créer la configuration d’équilibrage
de charge initiale. Pour définir l’adresse IP privée, utilisez az network lb frontend-ip
create avec le paramètre --private-ip-address . Utilisez az network lb address-pool
create pour ajouter la configuration du pool d’adresses principal. Utilisez az network
lb inbound-nat-rule create pour ajouter des règles de traduction d’adresses réseau.
Utilisez az network lb rule create pour ajouter les règles d’équilibrage de charge.
Utilisez az network lb probe create pour ajouter les sondes.
Modèle Utilisez 2 machines virtuelles dans un équilibreur de charge comme guide pour le
déploiement d’un équilibrage de charge à l’aide d’un modèle.
Machines virtuelles
Les machines virtuelles peuvent être créées dans le même réseau virtuel et se connecter
les unes aux autres à l’aide d’adresses IP privées. Les machines virtuelles peuvent se
connecter si elles se trouvent dans des sous-réseaux différents. Elles se connectent sans
avoir besoin de configurer de passerelle ou d’utiliser d’adresses IP publiques. Pour
placer des machines virtuelles dans un réseau virtuel, vous devez créer le réseau virtuel.
Lorsque vous créez chaque machine virtuelle, vous l’affectez au réseau virtuel et au
sous-réseau. Les machines virtuelles acquièrent leurs paramètres réseau lors du
déploiement ou du démarrage.
Une adresse IP est affectée aux machines virtuelles lorsqu’elles sont déployées. Lorsque
vous déployez plusieurs machines virtuelles dans un réseau virtuel ou un sous-réseau,
des adresses IP leur sont attribuées lorsqu’elles démarrent. Vous pouvez également
allouer une adresse IP statique à une machine virtuelle. Si vous allouez une adresse IP
dynamique statique, vous devez envisager d’utiliser un sous-réseau spécifique afin
d’éviter de réutiliser accidentellement l’adresse IP statique pour une autre machine
virtuelle.
Si vous créez une machine virtuelle et que vous voulez la migrer plus tard vers un réseau
virtuel, il ne s’agit pas d’une modification de configuration simple. Redéployez la
machine virtuelle dans le réseau virtuel. Pour la redéployer, le plus simple consiste à
supprimer la machine virtuelle (mais pas les disques attachés à celle-ci), puis à recréer la
machine virtuelle à l’aide des disques d’origine dans le réseau virtuel.
Ce tableau répertorie les méthodes que vous pouvez utiliser pour créer une machine
virtuelle dans un réseau virtuel.
Azure Utilise les paramètres de réseau par défaut qui ont été mentionnés précédemment
portal pour créer une machine virtuelle avec une seule carte d’interface réseau. Pour créer
une machine virtuelle avec plusieurs cartes d’interface réseau, vous devez utiliser
une autre méthode.
Azure Inclut l’utilisation de Add-AzVMNetworkInterface pour ajouter la carte d’interface

PowerShell réseau que vous avez créée précédemment pour la configuration de la machine
virtuelle.
Azure CLI Créez et connectez une machine virtuelle à un réseau virtuel, un sous-réseau et une
carte d’interface réseau qui sont générés en tant qu’étapes individuelles.
Modèle Utilisez Very simple deployment of a Windows VM comme guide pour le

déploiement d’une machine virtuelle à l’aide d’un modèle.
NAT Gateway
Azure NAT Gateway simplifie la connectivité Internet sortante uniquement pour les
réseaux virtuels. Quand il est configuré sur un sous-réseau, toute la connectivité
sortante utilise vos adresses IP publiques statiques spécifiées. Une connectivité sortante
est possible sans équilibreur de charge ni adresses IP publiques directement attachées
aux machines virtuelles. NAT est complètement managé et hautement résilient.
Une connectivité sortante peut être définie pour chaque sous-réseau avec NAT.
Plusieurs sous-réseaux au sein du même réseau virtuel peuvent avoir différents services
NAT. Un sous-réseau est configuré en spécifiant la ressource de passerelle NAT à utiliser.
Tous les flux sortants UDP et TCP en provenance de toute instance de machine virtuelle
utilisent une passerelle NAT. NAT est compatible avec les ressources d’adresses IP
publiques ou les ressources de préfixes d’adresses IP publiques de la référence SKU
standard, ou avec une combinaison des deux. Vous pouvez utiliser directement un
préfixe d’adresse IP publique ou distribuer les adresses IP publiques du préfixe entre
plusieurs ressources de passerelle NAT. NAT nettoie tout le trafic vers la plage d’adresses
IP du préfixe. Le filtrage de toute adresse IP de vos déploiements est simple.
La passerelle NAT traite automatiquement tout le trafic sortant sans configuration client.
Les routes définies par l’utilisateur ne sont pas nécessaires. NAT est prioritaire sur les
autres scénarios de trafic sortant et remplace la destination Internet par défaut d’un
sous-réseau.
Les groupes de machines virtuelles identiques qui créent des machines virtuelles en
mode d’orchestration flexible n’ont pas d’accès sortant par défaut. La passerelle NAT
Azure est la méthode d’accès sortant recommandée pour les groupes de machines
virtuelles identiques en mode d’orchestration flexible.
Pour plus d’informations sur Azure NAT Gateway, consultez Qu’est-ce qu’Azure NAT
Gateway ?.
Ce tableau répertorie les méthodes que vous pouvez utiliser pour créer une ressource
de passerelle NAT.
Azure Crée un réseau virtuel, un sous-réseau, une adresse IP publique, une passerelle NAT
portal et une machine virtuelle pour tester la ressource de passerelle NAT.
Azure Inclut l’utilisation de New-AzNatGatewaypour créer une ressource de passerelle

PowerShell NAT. Crée un réseau virtuel, un sous-réseau, une adresse IP publique, une passerelle
NAT et une machine virtuelle pour tester la ressource de passerelle NAT.
Azure CLI Inclut l’utilisation de az network nat gateway createpour créer une ressource de
passerelle NAT. Crée un réseau virtuel, un sous-réseau, une adresse IP publique, une
passerelle NAT et une machine virtuelle pour tester la ressource de passerelle NAT.
Modèle Crée un réseau virtuel, un sous-réseau, une adresse IP publique et une ressource de
passerelle NAT.
Azure Bastion
Azure Bastion est déployé pour fournir une connectivité de gestion sécurisée aux
machines virtuelles dans un réseau virtuel. Le service Azure Bastion vous permet
d’établir une connexion RDP et SSH sécurisée et fluide aux machines virtuelles de votre
réseau virtuel. Azure Bastion active les connexions sans exposer d’adresse IP publique
sur la machine virtuelle. Les connexions sont établies directement à partir du portail
Azure, sans qu’un client/agent ou logiciel supplémentaire ne soit nécessaire. Azure
Bastion prend en charge les adresses IP publiques de référence SKU Standard.
Pour plus d’informations sur Azure Bastion, consultez Présentation d’Azure Bastion.
Ce tableau répertorie les méthodes que vous pouvez utiliser pour créer le déploiement
d’un Bastion Azure.
Azure Crée un réseau virtuel, des sous-réseaux, une adresse IP publique, un hôte bastion et
portal des machines virtuelles.
Azure Crée un réseau virtuel, des sous-réseaux, une adresse IP publique et un hôte bastion.
PowerShell Inclut l’utilisation de New-AzBastion pour créer l’hôte bastion.
Azure CLI Crée un réseau virtuel, des sous-réseaux, une adresse IP publique et un hôte bastion.
Inclut l’utilisation de az network bastion create pour créer l’hôte bastion.
Modèle Pour obtenir un exemple de déploiement de modèles qui intègrent un hôte Azure
Bastion avec un exemple de déploiement, consultez Démarrage rapide : créer un
équilibreur de charge public pour équilibrer la charge des machines virtuelles à
l’aide d’un modèle ARM.
Étapes suivantes
Pour connaître les étapes spécifiques aux machines virtuelles concernant la gestion des
réseaux virtuels Azure pour les machines virtuelles, consultez les didacticiels Windows
ou Linux.
Il existe également des démarrages rapides sur l’équilibrage de charge des machines
virtuelles et la création d’applications à haute disponibilité utilisant le CLI ou le
PowerShell
Découvrez comment configurer les connexions de réseau virtuel à réseau virtuel.
Découvrez comment résoudre les problèmes relatifs aux itinéraires.
En savoir plus sur la bande passante réseau des machines virtuelles

Planifier des réseaux virtuels
La création d’un réseau virtuel à titre d’essai est assez facile, mais vous risquez de
déployer plusieurs réseaux virtuels au fil du temps pour prendre en charge les besoins
en production de votre organisation. La planification vous permet de déployer des
réseaux virtuels et de vous connecter aux ressources dont vous avez besoin plus
efficacement. Les informations contenues dans cet article sont particulièrement utiles si
vous êtes déjà familiarisé avec les réseaux virtuels et que vous disposez d’expérience
dans leur utilisation. Si vous n’êtes pas familiarisé avec les réseaux virtuels, il vous est
recommandé de lire Virtual network overview (Vue d’ensemble du réseau virtuel).
Dénomination
Toutes les ressources Azure ont un nom. Le nom doit être unique au sein d’une étendue,
qui peut varier pour chaque type de ressource. Par exemple, le nom d’un réseau virtuel
doit être unique au sein d’un groupe de ressources, mais peut être dupliqué dans un
abonnement ou une région Azure. La définition d’une convention d’affectation de
noms que vous pouvez utiliser régulièrement lorsque vous nommez des ressources est
utile lors de la gestion de plusieurs ressources réseau au fil du temps. Pour des
suggestions, consultez Conventions d’affectation de noms.
Régions
Toutes les ressources Azure sont créées dans une région Azure et un abonnement. Une
ressource peut être connectée uniquement dans un réseau virtuel qui existe dans les
mêmes région et abonnement que la ressource. Toutefois, vous pouvez connecter des
réseaux virtuels qui existent dans différents abonnements et différentes régions. Pour
plus d’informations, consultez Connectivité. Lorsque vous choisissez les régions dans
lesquelles déployer des ressources, prenez en compte l’emplacement physique des
consommateurs des ressources :
Les consommateurs de ressources souhaitent généralement la latence du réseau la

plus faible possibles sur leurs ressources. Pour déterminer les latences relatives
entre un emplacement spécifié et des régions Azure, consultez View relative
latencies (Afficher les latences relatives).
Avez-vous des exigences en matière de résidence, souveraineté, conformité ou
résilience des données ? Dans c’est le cas, il est essentiel de choisir la région qui
correspond à la configuration requise. Pour plus d’informations, consultez Azure
geographies (Zones géographiques Azure).
Avez-vous besoin de résilience entre Zones de disponibilité Azure d’une même
région Azure pour les ressources que vous déployez ? Vous pouvez déployer des
ressources, comme des machines virtuelles, dans différentes zones de disponibilité
au sein du même réseau virtuel. Toutefois, toutes les régions Azure ne prennent
pas en charge les zones de disponibilité. Pour en savoir plus sur les zones de la
disponibilité et les régions qui les prennent en charge, consultez Zones de
disponibilité.
Abonnements
Vous pouvez déployer autant de réseaux virtuels que nécessaire dans chaque
abonnement, jusqu’à la limite. Par exemple, certaines organisations disposent
d’abonnements distincts pour différents services. Pour plus d’informations et des
remarques relatives aux abonnements, consultez Subscription governance (Gouvernance
de l’abonnement).
Segmentation
Vous pouvez créer plusieurs réseaux virtuels par abonnement et par région. Vous
pouvez créer plusieurs sous-réseaux au sein de chaque réseau virtuel. Les remarques qui
suivent vous aident à déterminer le nombre de réseaux virtuels et sous-réseaux dont
vous avez besoin :
Réseaux virtuels
Un réseau virtuel est une partie virtuelle isolée du réseau public Azure. Chaque réseau
virtuel est dédié à votre abonnement. Éléments à prendre en compte lorsque vous
choisissez de créer un réseau virtuel ou plusieurs réseaux virtuels dans un abonnement :
Avez-vous des exigences de sécurité d’organisation pour isoler le trafic dans des
réseaux virtuels distincts ? Vous pouvez choisir de connecter des réseaux virtuels
ou non. Si vous connectez des réseaux virtuels, vous pouvez implémenter une
appliance virtuelle réseau, comme un pare-feu, pour contrôler le flux de trafic entre
les réseaux virtuels. Pour plus d’informations, consultez Sécurité et Connectivité.
Avez-vous des exigences d’organisation pour isoler les réseaux virtuels dans des
abonnements ou régions distincts ?
Une interface réseau permet à un machine virtuelle de communiquer avec d’autres
ressources. Une ou plusieurs adresses IP privées sont affectées à chaque interface
réseau. De combien d’interfaces réseau et d’adresses IP privées avez-vous besoin
dans un réseau virtuel ? Des limites s’appliquent quant au nombre d’interfaces
réseau et d’adresses IP privées que vous pouvez avoir dans un réseau virtuel.
Voulez-vous connecter le réseau virtuel à un autre réseau virtuel ou au réseau local
? Vous pouvez choisir de connecter certains réseaux virtuels entre eux ou des
réseaux locaux, mais pas d’autres. Pour plus d’informations, consultez Connectivité.
Chaque réseau virtuel que vous connectez à un autre réseau virtuel, ou au réseau
local, doit avoir un espace d’adresses unique. Chaque réseau virtuel comprend une
ou plusieurs plages d’adresses publiques ou privées affectées à son espace
d’adresses. Une plage d’adresses est spécifiée dans un format de routage de
domaine Interne sans classe (CIDR), par exemple, 10.0.0.0/16. En savoir plus sur
plages d’adresses pour les réseaux virtuels.
Avez-vous des exigences d’administration d’organisation pour les ressources dans
différents réseaux virtuels ? Si c’est le cas, vous pouvez séparer des ressources dans
un réseau virtuel distinct afin de simplifier l’affectation d’autorisations à des
personnes de votre organisation ou pour assigner différentes stratégies à
différents réseaux virtuels.
Lorsque vous déployez des ressources de service Azure dans un réseau virtuel,
elles créent leur propre réseau virtuel. Pour déterminer si un service Azure crée son
propre réseau virtuel, consultez les informations de chaque service Azure pouvant
être déployé dans un réseau virtuel.
Sous-réseaux
Un réseau virtuel peut être segmenté en un ou plusieurs sous-réseaux, jusqu’aux limites.
Éléments à prendre en compte lorsque vous choisissez de créer un sous-réseau ou
plusieurs réseaux virtuels dans un abonnement :
Chaque sous-réseau doit avoir une plage d’adresses unique, spécifiée au format
CIDR, dans l’espace d’adresses du réseau virtuel. La plage d’adresses ne peut pas
chevaucher d’autres sous-réseaux au sein du réseau virtuel.
Si vous envisagez de déployer des ressources de service Azure dans un réseau
virtuel, elles peuvent avoir besoin de créer leur propre sous-réseau. De l’espace
non alloué doit être suffisant pour le faire. Pour déterminer si un service Azure crée
son propre sous-réseau, consultez les informations de chaque service Azure
pouvant être déployé dans un réseau virtuel. Par exemple, si vous connectez un
réseau virtuel à un réseau local à l’aide d’une passerelle VPN Azure, le réseau
virtuel doit avoir un sous-réseau dédié pour la passerelle. En savoir plus sur les
sous-réseaux de passerelle.
Par défaut, Azure achemine le trafic réseau entre tous les sous-réseaux dans un
réseau virtuel. Par exemple, vous pouvez remplacer le routage par défaut d’Azure
pour empêcher le routage Azure entre des sous-réseaux ou pour acheminer le
trafic entre des sous-réseaux via une appliance virtuelle réseau. Si vous avez besoin
que le trafic entre des ressources d’un même réseau virtuel circulent via une
appliance virtuelle réseau (NVA), déployez les ressources sur des sous-réseaux
différents. En savoir plus la sécurité.
Vous pouvez limiter l’accès aux ressources Azure, un compte de stockage Azure ou
une base de données Azure SQL par exemple, à des sous-réseaux spécifiques avec
un point de terminaison de service de réseau virtuel. Vous pouvez également
refuser l’accès aux ressources à partir d’Internet. Vous pouvez créer plusieurs sous-
réseaux et activer un point de terminaison de service pour certains sous-réseaux,
mais pas pour d’autres. En savoir plus sur les points de terminaison de service, et
les ressources Azure pour lesquelles vous pouvez les activer.
Vous pouvez associer zéro ou un groupe de sécurité réseau à chaque sous-réseau
dans un réseau virtuel. Vous pouvez associer le même groupe de sécurité réseau,
ou un autre, à chaque sous-réseau. Chaque groupe de sécurité réseau contient des
règles, qui autorisent ou refusent le trafic vers et depuis des sources et des
destinations. En savoir plus sur les groupes de sécurité réseau.
Sécurité
Vous pouvez filtrer le trafic réseau vers et depuis des ressources dans un réseau virtuel à
l’aide de groupes de sécurité réseau et d’appliances virtuelles réseau. Vous pouvez
contrôler la façon selon laquelle Azure achemine le trafic à partir des sous-réseaux. Vous
pouvez également limiter qui dans votre organisation peut utiliser des ressources dans
des réseaux virtuels.
Filtrage du trafic
Vous pouvez filtrer le trafic réseau entre des ressources dans un réseau virtuel à
l’aide d’un groupe de sécurité réseau, d’une NVA qui filtre le trafic réseau, ou des
deux. Pour déployer une NVA, comme un pare-feu, pour filtrer le trafic réseau,
consultez la Place de marché Azure . Lorsque vous utilisez une NVA, vous créez
également des itinéraires personnalisés pour acheminer le trafic entre les sous-
réseaux et la NVA. En savoir plus sur le routage du trafic.
Un groupe de sécurité réseau contient plusieurs règles de sécurité par défaut qui
autorisent ou refusent le trafic vers ou depuis des ressources. Un groupe de
sécurité réseau peut être associé à une interface réseau, au sous-réseau où se
trouve l’interface réseau, ou aux deux. Pour simplifier la gestion des règles de
sécurité, il vous est recommandé d’associer, chaque fois que cela est possible, un
groupe de sécurité réseau à des sous-réseaux, plutôt qu’à des interfaces réseau du
sous-réseau.
Si différentes machines virtuelles au sein d’un sous-réseau ont besoin de règles de
sécurité différentes, vous pouvez associer l’interface réseau de la machine virtuelle
à un ou plusieurs groupes de sécurité d’application. Une règle de sécurité peut
spécifier un groupe de sécurité d’application dans sa source, sa destination, ou les
deux. Cette règle ne s’applique alors qu’aux interfaces réseau qui sont membres du
groupe de sécurité d’application. En savoir plus sur les groupes de sécurité réseau
et les groupes de sécurité d’application.
Lorsqu’un groupe de sécurité réseau est associé au niveau du sous-réseau, il
s’applique à toutes les cartes réseau du sous-réseau, et pas uniquement au trafic
provenant de l’extérieur du sous-réseau. Cela signifie que le trafic entre les
machines virtuelles contenues dans le sous-réseau peut également être affecté.
Azure crée plusieurs règles de sécurité par défaut dans chaque groupe de sécurité
réseau. Une règle par défaut autorise l’ensemble du trafic entre toutes les
ressources dans un réseau virtuel. Pour remplacer ce comportement, utilisez des
groupes de sécurité réseau, un routage personnaliser pour acheminer le trafic vers
une NVA, ou les deux. Il vous est recommandé de vous familiariser avec toutes les
règles de sécurité par défaut d’Azure et de comprendre comment les règles de
groupe de sécurité réseau s’appliquent à une ressource.
Vous pouvez consulter des exemples de conception pour l’implémentation d’un réseau
de périmètre (ou DMZ) entre Azure et Internet, à l’aide d’une appliance virtuelle réseau.
Routage du trafic
Azure crée plusieurs itinéraires par défaut pour le trafic sortant à partir d’un sous-réseau.
Vous pouvez remplacer le routage par défaut d’Azure en créant une table de routage et
en l’associant à un sous-réseau. Les raisons courantes du remplacement du routage par
défaut d’Azure sont les suivantes :
Car vous souhaitez que le trafic entre des sous-réseaux circule via une NVA. Pour
en savoir plus sur la configuration de tables de routage et forcer le trafic via une
NVA.
Car vous souhaitez forcer l’ensemble du trafic Internet via une NVA, ou en local, via
une passerelle VPN Azure. Le fait de forcer le trafic Internet en local pour
inspection et la journalisation sont souvent appelés le tunneling forcé. En savoir
plus sur la configuration du tunneling forcé.
Si vous avez besoin d’implémenter un routage personnalisé, il vous est recommandé de

vous familiariser avec le routage dans Azure.
Connectivité
Vous pouvez connecter un réseau virtuel à d’autres réseaux virtuels à l’aide du peering
de réseau virtuel, ou à votre réseau local, à l’aide d’une passerelle VPN Azure.
Peering
Lorsque vous utilisez le peering de réseau virtuel, les réseaux virtuels peuvent se trouver
dans la même région, ou dans différentes régions Azure prises en charge. Les réseaux
virtuels peuvent se trouver dans le même abonnement ou dans des abonnements Azure
différents (voire dans des abonnements appartenant à des locataires Azure Active
Directory différents). Avant de créer un peering, il est recommandé de vous familiariser
avec toutes les exigences et contraintes du peering. La bande passante entre des
ressources figurant dans des réseaux virtuels homologués dans la même région est la
même que si ces ressources se trouvaient dans le même réseau virtuel.
passerelle VPN
Vous pouvez utiliser une passerelle VPN Azure pour connecter un réseau virtuel à votre
réseau local à l’aide un VPN site à site, ou à l’aide d’une connexion dédiée à Azure
ExpressRoute.
Vous pouvez combiner le peering avec une passerelle VPN pour créer des réseaux Hub
and Spoke, dans lesquels les réseaux virtuels Spoke se connectent à un réseau virtuel
Hub, et où le Hub se connecte à un réseau local, par exemple.
Résolution de noms
Les ressources dans un réseau virtuel ne peuvent pas résoudre les noms de ressources
dans un réseau virtuel homologué à l’aide du DNS intégré d’Azure. Pour résoudre les
noms dans un réseau virtuel homologué, déployez votre propre serveur DNS ou utilisez
des domaines privés Azure DNS. La résolution des noms entre des ressources dans un
réseau virtuel et des réseaux locaux requiert également que vous déployiez votre propre
serveur DNS.
Autorisations
Azure utilise le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour gérer
l’accès aux ressources. Des autorisations sont affectées à une étendue dans la hiérarchie
suivante : groupe d’administration, abonnement, groupe de ressources et ressource
individuelle. Pour en savoir plus sur la hiérarchie, consultez Organize your resources
(Organiser vos ressources). Pour utiliser des réseaux virtuels Azure et toutes leurs
fonctionnalités associées, comme le peering, les groupes de sécurité réseau, les points
de terminaison de service et les tables de routage, vous pouvez assigner à des membres
de votre organisation le rôle Propriétaire, Contributeur ou Contributeur réseau intégré,
puis assigner le rôle à l’étendue appropriée. Si vous souhaitez assigner des autorisations
spécifiques pour un sous-ensemble de fonctionnalités de réseau virtuel, créez un rôle
personnalisé et assignez les autorisations spécifiques nécessaires pour les réseaux
virtuels, sous-réseaux et points de terminaison de service, interfaces réseau, peering,
groupes de sécurité réseau et d’application ou les tables de routage au rôle.
Policy
Azure Policy vous permet de créer, d’assigner et de gérer des définitions de stratégie.
Les définitions de stratégie appliquent différentes règles sur vos ressources, qui restent
donc conformes aux normes et aux contrats de niveau de service de l’organisation.
Azure Policy exécute une évaluation de vos ressources, en analysant les ressources qui
ne sont pas conformes avec les définitions de stratégie dont vous disposez. Par exemple,
vous pouvez définir et appliquer une stratégie qui autorise la création de réseaux
virtuels dans seulement une région ou un groupe de ressources spécifique. Une autre
stratégie peut exiger qu’un groupe de sécurité réseau soit associé à chaque sous-réseau.
Les stratégies sont alors évaluées lors de la création et de la mise à jour des ressources.
Les stratégies sont appliquées à la hiérarchie suivante : groupe d’administration,

abonnement et groupe de ressources. Apprenez-en plus sur Azure Policy ou déployez
des définitions Azure Policy de réseau virtuel.
Étapes suivantes
En savoir plus sur les tâches, paramètres et options d’un réseau virtuel, d’un point de
terminaison de service et de sous-réseau, d’une interface réseau, d’un Peering, d’un
groupe de sécurité réseau et d’application ou d’une table de routage.
Résolution de noms des ressources dans
les réseaux virtuels Azure
Article • 05/05/2023
Vous pouvez utiliser Azure pour héberger des solutions IaaS, PaaS et hybrides. Pour
faciliter la communication entre les machines virtuelles et les autres ressources
déployées dans un réseau virtuel, il peut être nécessaire de les autoriser à communiquer
entre elles. L’utilisation de noms facilement mémorisables et immuables simplifie le
processus de communication, plutôt que de s’appuyer sur des adresses IP.
Quand des ressources déployées sur des réseaux virtuels doivent résoudre des noms de
domaine en adresses IP internes, elles peuvent utiliser l’une des quatre méthodes
suivantes :
Azure DNS Private Zones
Résolution de noms dans Azure
Résolution de noms à l’aide de votre propre serveur DNS (qui peut rediriger les
requêtes vers les serveurs DNS fournis par Azure)
Programme de résolution privé Azure DNS
Le type de résolution de noms que vous utilisez dépend de la manière dont vos
ressources doivent communiquer entre elles. Le tableau suivant montre des scénarios et
les solutions de résolution de noms correspondantes :
７ Notes
Azure DNS Private Zones constitue la solution par défaut et vous offre la flexibilité
nécessaire pour gérer vos enregistrements et zones DNS. Pour plus d’informations,
consultez Utilisation d’Azure DNS pour les domaines privés.
７ Notes
Si vous utilisez le service DNS fourni par Azure, le suffixe DNS approprié est
appliqué automatiquement à vos machines virtuelles. Pour toutes les autres
options, vous devez utiliser des noms de domaine complets (FQDN) ou appliquer
manuellement le suffixe DNS approprié à vos machines virtuelles.
Scénario Solution Suffixe
DNS
Résolution de noms entre des Zones privées Azure DNS ou résolution de Nom d’hôte
machines virtuelles situées dans noms fournie par Azure ou nom de
le même réseau virtuel, ou entre domaine
des instances de rôle Azure complet
Cloud Services situées dans le
même service cloud.
Résolution de noms entre des Zones privées Azure DNS, Azure DNS Private Nom de
machines virtuelles situées dans Resolver ou serveurs DNS gérés par le client qui domaine
différents réseaux virtuels ou transfèrent les requêtes entre les réseaux complet
entre des instances de rôle virtuels pour une résolution par Azure (proxy uniquement
situées dans différents services DNS). Consultez Résolution de noms à l’aide de
cloud. votre propre serveur DNS.
Résolution de noms à partir Azure DNS Private Resolver ou serveurs DNS Nom de
d’Azure App Service (application gérés par le client qui transfèrent les requêtes domaine
web, fonction ou Bot) à l’aide de entre les réseaux virtuels pour une résolution complet
l’intégration au réseau virtuel par Azure (proxy DNS). Consultez Résolution de uniquement
pour les instances de rôle ou noms à l’aide de votre propre serveur DNS.
machines virtuelles dans le
même réseau virtuel.
d’App Service Web Apps vers gérés par le client qui transfèrent les requêtes domaine
des machines virtuelles dans le entre les réseaux virtuels pour une résolution complet
même réseau virtuel. par Azure (proxy DNS). Consultez Résolution de uniquement
noms à l’aide de votre propre serveur DNS.
d’App Service Web Apps dans gérés par le client qui transfèrent les requêtes domaine
un réseau virtuel vers des entre les réseaux virtuels pour une résolution complet
machines virtuelles situées dans par Azure (proxy DNS). Consultez Résolution de uniquement
un réseau virtuel différent. noms à l’aide de votre propre serveur DNS.
Résolution des noms de service Azure DNS Private Resolver ou serveurs DNS Nom de
et d’ordinateur locaux à partir gérés par le client (par exemple, contrôleur de domaine
des machines virtuelles ou des domaine local, contrôleur de domaine en complet
instances de rôle dans Azure. lecture seule local ou serveur DNS secondaire uniquement
synchronisé via des transferts de zone).
Consultez Résolution de noms à l’aide de votre
propre serveur DNS.
Scénario Solution Suffixe
DNS
Résolution de noms d’hôte Transférer les requêtes vers un serveur proxy Nom de
Azure à partir d’ordinateurs DNS géré par le client dans le réseau virtuel domaine
locaux. correspondant ; le serveur proxy transfère les complet
requêtes vers Azure en vue de la résolution. uniquement
Consultez Résolution de noms à l’aide de votre
propre serveur DNS.
DNS inversé pour les adresses IP Zones privées Azure DNS, résolution de noms Non
internes. fournie par Azure, Azure DNS Private Resolver applicable
ou résolution de noms à l’aide de votre propre
serveur DNS.
Résolution de noms entre des Non applicable. La connectivité entre des Non
machines virtuelles ou instances machines virtuelles et des instances de rôle de applicable
de rôle situées dans différents différents services cloud n’est pas prise en
services cloud, et non dans un charge en dehors d’un réseau virtuel.
réseau virtuel.
Résolution de noms dans Azure

La résolution de noms fournie par Azure fournit uniquement les fonctionnalités DNS de
base faisant autorité. Azure gère les noms et enregistrements de zone DNS si vous
utilisez le DNS fourni par Azure. Vous ne pouvez pas contrôler les noms de zone DNS ou
le cycle de vie des enregistrements DNS. Si vous avez besoin d’une solution DNS
complète pour vos réseaux virtuels, vous pouvez utiliser des zones privées Azure DNS
avec des serveurs DNS gérés par le client ou une instance d’Azure DNS Private Resolver.
Avec la résolution des noms DNS publics, Azure fournit la résolution de noms interne
pour les machines virtuelles et les instances de rôle qui résident dans le même réseau
virtuel ou service cloud. Les machines virtuelles et les instances d’un service cloud
partagent le même suffixe DNS ; le nom d’hôte est donc suffisant. Toutefois, dans les
réseaux virtuels déployés à l’aide du modèle de déploiement classique, les différents
services cloud n’ont pas le même suffixe DNS. Dans ce cas, vous avez besoin du nom de
domaine complet pour résoudre les noms des différents services cloud. Dans les réseaux
virtuels déployés à l’aide du modèle de déploiement Azure Resource Manager, le suffixe
DNS est le même sur toutes les machines virtuelles d’un réseau virtuel, si bien que le
nom de domaine complet n’est pas nécessaire. Vous pouvez affecter des noms DNS aux
machines virtuelles et aux interfaces réseau. Bien que la résolution de noms fournie par
Azure ne nécessite aucune configuration, elle ne convient pas à certains scénarios de
déploiement, comme expliqué dans le tableau précédent.
７ Notes
Quand vous utilisez des rôles de travail et web de services cloud, vous pouvez
également accéder aux adresses IP internes des instances de rôle à l’aide de l’API
REST de gestion des services Azure. Pour plus d’informations, consultez Référence
de l’API REST de gestion des services. L’adresse est basée sur le nom de rôle et le
numéro d’instance.
Fonctionnalités
La résolution de noms fournie par Azure présente les avantages suivants :
Simplicité d’utilisation. Aucune configuration n'est requise.
Haute disponibilité : Vous n’avez pas besoin de créer et de gérer les clusters de vos
propres serveurs DNS.
Vous pouvez utiliser le service avec vos propres serveurs DNS pour résoudre des
noms d’hôte locaux et Azure.
Vous pouvez utiliser la résolution de noms entre les machines virtuelles et les
instances de rôle du même service cloud, sans qu’un nom de domaine complet
soit nécessaire.
Vous pouvez utiliser la résolution de noms entre les machines virtuelles des
réseaux virtuels qui utilisent le modèle de déploiement Azure Resource Manager,
sans qu’un nom de domaine complet ne soit nécessaire. Les réseaux virtuels du
modèle de déploiement classique nécessitent un nom de domaine complet lors de
la résolution de noms dans des services cloud différents.
Vous pouvez utiliser des noms d’hôte qui décrivent vos déploiements de façon
plus appropriée, au lieu d’utiliser des noms générés automatiquement.
Considérations
Éléments à prendre en compte lorsque vous utilisez la résolution de noms fournie par
Azure :
Le suffixe DNS créé par Azure ne peut pas être modifié.
La recherche DNS est étendue à un réseau virtuel. Les noms DNS créés pour un
réseau virtuel ne peuvent pas être résolus à partir d’autres réseaux virtuels.
Vous ne pouvez pas inscrire manuellement vos propres enregistrements.
WINS et NetBIOS ne sont pas pris en charge. Vous ne pouvez pas voir vos
machines virtuelles dans l’Explorateur Windows.
Les noms d’hôte doivent être compatibles avec DNS. Les noms ne peuvent
comporter que les caractères 0-9, a-z et « - », et ils ne peuvent pas commencer ou
se terminer par « - ».
Le trafic de requêtes DNS est limité pour chaque machine virtuelle. La limitation ne
doit pas affecter la plupart des applications. Si la limitation de requêtes est
respectée, assurez-vous que la mise en cache côté client est activée. Pour plus
d’informations, consultez Configuration du client DNS.
Utilisez un nom différent pour chaque machine virtuelle dans un réseau virtuel afin
d’éviter les problèmes de résolution DNS.
Seules les machines virtuelles des 180 premiers services cloud sont inscrites pour
chaque réseau virtuel dans un modèle de déploiement classique. Cette limite ne
s’applique pas aux réseaux virtuels d’Azure Resource Manager.
Adresse IP d’Azure DNS : 168.63.129.16. Il s’agit d’une adresse IP statique qui ne

change pas.
Considérations relatives au DNS inversé

Le DNS inversé destiné aux machines virtuelles est pris en charge dans tous les réseaux
virtuels basés sur Azure Resource Manager. Les enregistrements DNS inversés (PTR)
gérés par Azure au format [vmname].internal.cloudapp.net sont automatiquement
ajoutés lorsque vous démarrez une machine virtuelle, et supprimés lorsque la machine
virtuelle est arrêtée (libérée). Voir l’exemple suivant :
C:\>nslookup -type=ptr 10.11.0.4

Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
4.0.11.10.in-addr.arpa name = myeastspokevm1.internal.cloudapp.net
La zone de DNS inversé internal.cloudapp.net est gérée par Azure, et ne peut pas être
directement consultée ou modifiée. La recherche directe sur un nom de domaine
complet au format [vmname].internal.cloudapp.net se résout sur l’adresse IP attribuée
à la machine virtuelle.
Si une zone privée Azure DNS est liée au réseau virtuel à l’aide d’un lien de réseau
virtuel et que l’inscription automatique est activée sur ce lien, les requêtes de DNS
inversé renvoient alors deux enregistrements. L’un des enregistrements se présente sous
la forme [vmname].[privatednszonename], et l’autre sous la forme
[vmname].internal.cloudapp.net. Voir l’exemple suivant :
C:\>nslookup -type=ptr 10.20.2.4

Server: UnKnown
Address: 168.63.129.16
4.2.20.10.in-addr.arpa name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa name = mywestvm1.azure.contoso.com
Lorsque deux enregistrements PTR sont renvoyés comme illustré ci-dessus, la recherche
directe de l’un ou l’autre des noms de domaine complets renvoie alors l’adresse IP de la
machine virtuelle.
Les recherches DNS inversées sont limitées à un réseau virtuel donné, même s’il est
appairé à d’autres réseaux virtuels. Des requêtes de DNS inversé relatives aux
adresses IP des machines virtuelles situées dans des réseaux virtuels appairés renvoient
NXDOMAIN.
７ Notes
Les enregistrements DNS inversés (PTR) ne sont pas stockés dans une zone DNS
privée directe. Les enregistrements DNS inversés sont stockés dans une zone DNS
inversée (in-addr.arpa). La zone DNS inversée par défaut associée à un réseau
virtuel n’est ni visible ni modifiable.
Vous pouvez désactiver la fonction de DNS inversé dans un réseau virtuel en créant
votre propre zone de recherche inversée à l’aide de zones privées Azure DNS, puis en
liant cette zone à votre réseau virtuel. Par exemple, si l’espace d’adressage IP de votre
réseau virtuel est 10.20.0.0/16, vous pouvez créer la zone DNS privée vide 20.10.in-
addr.arpa et la lier au réseau virtuel. Cette zone remplace les zones de recherche
inversée par défaut pour le réseau virtuel. Cette zone est vide. Le DNS inversé retourne
NXDOMAIN , sauf si vous créez ces entrées manuellement.
L’inscription automatique des enregistrements PTR n’est pas prise en charge. Si vous
souhaitez créer des entrées, entrez-les manuellement. Vous devez désactiver l’inscription
automatique dans le réseau virtuel si elle est activée pour d’autres zones. Cette
limitation est due aux restrictions qui permettent de lier une seule zone privée si
l’inscription automatique est activée. Pour plus d’informations sur la création d’une zone
DNS privée et sa liaison à un réseau virtuel, consultez notre guide de démarrage rapide
consacré au DNS privé.
７ Notes
Étant donné que les zones privées Azure DNS sont globales, vous pouvez créer une
recherche DNS inversée pour couvrir plusieurs réseaux virtuels. Pour ce faire, créez
une zone privée Azure DNS destinée aux recherches inversées (zone in-addr.arpa)
et liez-la aux réseaux virtuels. Vous devez gérer manuellement les enregistrements
DNS inversés pour les machines virtuelles.
Configuration du client DNS

Cette section aborde la mise en cache côté client et les nouvelles tentatives côté client.
Mise en cache côté client

Les requêtes DNS n’ont pas toutes besoin d’être envoyées sur le réseau. La mise en
cache côté client permet de réduire la latence et d’améliorer la résilience aux problèmes
réseau en résolvant les requêtes DNS récurrentes à partir d’un cache local. Les
enregistrements DNS ont une durée de vie qui permet au cache de les stocker aussi
longtemps que possible sans impacter leur fraîcheur. Pour cette raison, la mise en cache
côté client convient à la plupart des situations.
Le client DNS Windows par défaut comprend un cache DNS intégré. Certaines
distributions Linux n’incluent pas la mise en cache par défaut. Si vous ne disposez pas
déjà d’un cache local, ajoutez un cache DNS à chaque machine virtuelle Linux.
Il existe de nombreux packages de mise en cache DNS différents (par exemple,

dnsmasq). Voici les étapes nécessaires à l’installation de dnsmasq sur les distributions les
plus courantes :
RHEL, CentOS
RHEL/CentOS (utilise NetworkManager) :

1. Installez le package dnsmasq à l’aide commande suivante :
Bash
sudo yum install dnsmasq
2. Activez le service dnsmasq à l’aide de la commande suivante :
Bash
systemctl enable dnsmasq.service
3. Démarrez le service dnsmasq à l’aide de la commande suivante :
Bash
systemctl start dnsmasq.service
4. Utilisez un éditeur de texte pour ajouter prepend domain-name-servers

127.0.0.1; à /etc/dhclient-eth0.conf :
5. Utilisez la commande suivante pour redémarrer le service réseau :
Bash
service network restart
７ Notes
Le package dnsmasq constitue l’un des nombreux caches DNS disponibles pour
Linux. Avant de l’utiliser, vérifiez son adéquation à vos besoins et vérifiez qu’aucun
autre cache n’est installé.
Nouvelles tentatives côté client

DNS est principalement un protocole UDP. Comme le protocole UDP ne garantit pas la
remise des messages, la logique de nouvelle tentative est gérée dans le protocole DNS.
Chaque client DNS (système d’exploitation) peut appliquer une logique de nouvelle
tentative différente selon la préférence de son créateur :
Les systèmes d’exploitation Windows effectuent une nouvelle tentative après une
seconde, puis à nouveau après deux secondes, quatre secondes et encore quatre
secondes.
La configuration Linux par défaut effectue une nouvelle tentative après
cinq secondes. Il est recommandé de configurer cinq nouvelles tentatives
effectuées à une seconde d’intervalle.
Vérifiez les paramètres actuels sur une machine virtuelle Linux avec cat
/etc/resolv.conf . Examinez la ligne options, par exemple :
Sortie
options timeout:1 attempts:5
Le fichier resolv.conf est généré automatiquement et ne doit pas être modifié. Les
étapes spécifiques pour l’ajout de la ligne options varient selon la distribution :
RHEL, CentOS
RHEL/CentOS (utilise NetworkManager) :
1. Utilisez un éditeur de texte pour ajouter la ligne RES_OPTIONS="options

timeout:1 attempts:5" au fichier /etc/sysconfig/network-scripts/ifcfg-eth0.
2. Utilisez la commande suivante pour redémarrer le service NetworkManager :
Bash
systemctl restart NetworkManager.service
Résolution de noms utilisant votre propre

serveur DNS
Cette section traite des machines virtuelles, des instances de rôle et des applications
web.
７ Notes
Azure DNS Private Resolver remplace la nécessité d’utiliser des serveurs DNS basés
sur des machines virtuelles dans un réseau virtuel. Vous pouvez consulter la section
suivante si vous souhaitez utiliser une solution DNS basée sur des machines
virtuelles, mais il existe de nombreux avantages à l’utilisation d’Azure DNS Private
Resolver, notamment la réduction des coûts, la haute disponibilité intégrée, la
scalabilité et la flexibilité.
Machines virtuelles et instances de rôle

Il peut arriver que vous ayez besoin d’autres fonctionnalités que celles fournies par
Azure pour la résolution de noms. Par exemple, vous devrez peut-être utiliser des
domaines Microsoft Windows Server Active Directory pour résoudre les noms DNS entre
des réseaux virtuels. Dans le cadre de ces scénarios, Azure vous permet d’utiliser vos
propres serveurs DNS.
Les serveurs DNS d’un réseau virtuel peuvent transférer des requêtes DNS vers le
programme de résolution récursive dans Azure. Cette procédure vous permet de
résoudre des noms d’hôte au sein de ce réseau virtuel. Par exemple, un contrôleur de
domaine exécuté dans Azure peut répondre aux requêtes DNS concernant ses domaines
et transférer toutes les autres requêtes vers Azure. Le transfert des requêtes permet aux
machines virtuelles de voir vos ressources locales (par le biais du contrôleur de
domaine) et les noms d’hôte fournis par Azure (par le biais du redirecteur). Les
programmes de résolution récursive d’Azure sont accessibles via l’adresse IP virtuelle
168.63.129.16.
Le transfert DNS permet aussi la résolution DNS entre réseaux virtuels et permet à vos
machines locales de résoudre les noms d’hôte fournis par Azure. Pour résoudre le nom
d’hôte d’une machine virtuelle, la machine virtuelle du serveur DNS doit résider dans le
même réseau virtuel et être configurée pour rediriger les requêtes de nom d’hôte vers
Azure. Comme le suffixe DNS est différent dans chaque réseau virtuel, vous pouvez
utiliser des règles de redirection conditionnelles pour envoyer les requêtes DNS au
réseau virtuel approprié en vue de la résolution. L’image suivante montre deux réseaux
virtuels et un réseau local effectuant une résolution DNS entre réseaux virtuels à l’aide
de cette méthode. Un exemple de redirecteur DNS est disponible dans la Galerie de
modèles de démarrage rapide Azure et sur GitHub .
７ Notes
Une instance de rôle peut résoudre les noms des machines virtuelles appartenant
au même réseau virtuel. Pour cela, elle utilise le nom de domaine complet, qui est
constitué du nom d’hôte de la machine virtuelle et du suffixe DNS
internal.cloudapp.net. Toutefois, dans ce cas, la résolution de noms réussit
uniquement si l’instance de rôle a le nom de la machine virtuelle défini dans le
Schéma Rôle (fichier .cscfg). <Role name="<role-name>" vmName="<vm-name>">
Les instances de rôle qui doivent effectuer une résolution de noms des machines
virtuelles dans un autre réseau virtuel (nom de domaine complet utilisant le suffixe
internal.cloudapp.net) doivent le faire à l’aide de la méthode décrite dans cette
section, c’est-à-dire, en transférant les serveurs DNS personnalisés entre les deux
réseaux virtuels.
Lorsque vous utilisez la résolution de noms fournie par Azure, le protocole DHCP
d’Azure fournit un suffixe DNS interne (.internal.cloudapp.net) à chaque machine
virtuelle. Ce suffixe permet d’effectuer la résolution des noms d’hôte, car les
enregistrements de noms d’hôte se trouvent dans la zone internal.cloudapp.net.
Lorsque vous utilisez votre propre solution de résolution de noms, ce suffixe n’est pas
fourni aux machines virtuelles, car il interfère avec d’autres architectures DNS (comme
dans les scénarios avec jointure de domaine). Au lieu de cela, Azure fournit un espace
réservé non fonctionnel (reddog.microsoft.com).
Si nécessaire, vous pouvez déterminer le suffixe DNS interne à l’aide de PowerShell ou

de l’API :
Pour les réseaux virtuels des modèles de déploiement Azure Resource Manager, le
suffixe est disponible via l’API REST d’interface réseau, la cmdlet PowerShell Get-
AzNetworkInterface et la commande az network nic show Azure CLI.
Si le transfert de requêtes vers Azure ne répond pas à vos besoins, fournissez votre
propre solution DNS ou déployez une instance d’Azure DNS Private Resolver.
Si vous fournissez votre propre solution DNS, celle-ci doit :
Fournir la résolution de noms d’hôte appropriée, via DDNS par exemple. Si vous
utilisez DDNS, il peut être nécessaire de désactiver le nettoyage des
enregistrements DNS. Les baux DHCP d’Azure sont longs et le nettoyage peut
supprimer prématurément des enregistrements DNS.
Fournir la résolution récursive appropriée pour permettre la résolution de noms de

domaines externes.
Être accessible (TCP et UDP sur le port 53) à partir des clients dont elle traite les
demandes et être en mesure d’accéder à Internet.
Être protégée contre tout accès à partir d’Internet, pour atténuer les menaces
posées par les agents externes.
７ Notes
Pour des performances optimales, lorsque vous utilisez des machines

virtuelles Azure en tant que serveurs DNS, le protocole IPv6 doit être
désactivé.
Les groupes de sécurité réseau agissent comme des pare-feux pour vos points
de terminaison d’outil de résolution DNS. Vous devez modifier ou remplacer
vos règles de sécurité de groupe de sécurité réseau pour autoriser l’accès au
port UDP 53 (et éventuellement au port TCP 53) aux points de terminaison de
l’écouteur DNS. Une fois les serveurs DNS personnalisés définis sur un réseau,
le trafic via le port 53 contourne les groupes de sécurité réseau du sous-
réseau.
les applications web

Supposons que vous ayez besoin d’effectuer la résolution des noms entre votre
application web créée à l’aide d’App Service, et liée à un réseau virtuel, et les machines
virtuelles du même réseau virtuel. Après avoir configuré un serveur DNS personnalisé
comprenant un redirecteur DNS qui transfère les requêtes vers Azure (adresse IP
virtuelle : 168.63.129.16), procédez aux étapes suivantes :
1. Activez l’intégration de réseau virtuel pour votre application web, si ce n’est pas
déjà fait, comme décrit dans Intégrer une application à un réseau virtuel Azure.
2. Dans le portail Azure, pour le plan App Service qui héberge l’application web,
sélectionnez Synchroniser le réseau sous Mise en réseau, Intégration du réseau
virtuel.
Si vous devez effectuer une résolution de noms à partir de votre application web liée à
un réseau virtuel (créée à l’aide d’App Service) vers des machines virtuelles situées dans
un autre réseau virtuel qui n’est pas lié à la même zone privée, utilisez des serveurs DNS
personnalisés ou des instances d’Azure DNS Private Resolver sur les deux réseaux
virtuels.
Pour utiliser des serveurs DNS personnalisés :
Configurez un serveur DNS dans votre réseau virtuel cible, sur une machine
virtuelle qui peut également transférer les requêtes vers le programme de
résolution récursive d’Azure (adresse IP virtuelle : 168.63.129.16). Un exemple de
redirecteur DNS est disponible dans la Galerie de modèles de démarrage rapide
Azure et sur GitHub .
Configurez un redirecteur DNS dans le réseau virtuel source sur une machine
virtuelle. Configurez ce redirecteur DNS pour transférer les requêtes au serveur
DNS dans votre réseau virtuel cible.
Configurez votre serveur DNS source dans les paramètres de votre réseau virtuel
source.
Activez l’intégration de réseau virtuel pour votre application web afin de créer un
lien vers le réseau virtuel source, en suivant les instructions de l’article Intégrer une
application à un réseau virtuel Azure.
Dans le portail Azure, pour le plan App Service qui héberge l’application web,
sélectionnez Synchroniser le réseau sous Mise en réseau, Intégration du réseau
virtuel.
Pour utiliser une instance d’Azure DNS Private Resolver, consultez Liens de l’ensemble
de règles.
Spécifier les serveurs DNS

Lorsque vous utilisez vos propres serveurs DNS, Azure vous permet de spécifier
plusieurs serveurs DNS par réseau virtuel. Vous pouvez également spécifier plusieurs
serveurs DNS par interface réseau (pour Azure Resource Manager) ou par service cloud
(pour le modèle de déploiement classique). Les serveurs DNS spécifiés pour une
interface réseau ou un service cloud ont la priorité sur les serveurs DNS spécifiés pour le
réseau virtuel.
７ Notes
Les propriétés d’une connexion réseau, telles que les adresses IP des serveurs DNS,
ne doivent pas être modifiées directement dans les machines virtuelles. En effet, ces
propriétés risquent d’être effacées pendant la réparation du service, lors du
remplacement de la carte réseau virtuelle. Cela s’applique pour les machines
virtuelles Windows et Linux.
Lorsque vous utilisez le modèle de déploiement Azure Resource Manager, vous pouvez
spécifier des serveurs DNS pour un réseau virtuel et une interface réseau. Pour plus
d’informations, consultez Gérer un réseau virtuel et Gérer une interface réseau.
７ Notes
Si vous choisissez un serveur DNS personnalisé pour votre réseau virtuel, vous
devez spécifier au moins une adresse d’IP de serveur DNS, à défaut de quoi, le
réseau virtuel ignorera la configuration et utilisera le DNS fourni par Azure.
７ Notes
Si vous modifiez les paramètres DNS d’un réseau virtuel ou d’une machine virtuelle
déjà déployée, pour que les nouveaux paramètres DNS prennent effet, vous devez
effectuer un renouvellement de bail DHCP sur toutes les machines virtuelles
affectées dans le réseau virtuel. Pour les machines virtuelles exécutant le système
d’exploitation Windows, vous pouvez taper ipconfig /renew directement sur la
machine virtuelle. Les étapes varient selon le système d’exploitation. Consultez la
documentation relative à votre type de système d’exploitation.
Étapes suivantes
Modèle de déploiement Azure Resource Manager :
Gérer un réseau virtuel
Gérer une interface réseau

Utiliser un DNS dynamique pour inscrire
les noms d’hôte sur votre propre
serveur DNS
Article • 04/05/2023
Azure fournit la résolution de noms pour les machines virtuelles et les instances de rôle.
Quand vous avez besoin d’autres fonctionnalités que celles fournies par le DNS par
défaut d’Azure pour la résolution de noms, vous pouvez fournir vos propres serveurs
DNS. Utiliser vos propres serveurs DNS vous permet de personnaliser votre solution
DNS pour l’adapter à vos propres besoins. Par exemple, vous pouvez avoir besoin
d’accéder à des ressources locales avec votre contrôleur de domaine Active Directory.
Quand vos serveurs DNS personnalisés sont hébergés en tant que machines virtuelles
Azure, vous pouvez transférer les requêtes de nom d’hôte (pour le même réseau virtuel)
vers Azure pour résoudre les noms d’hôte. Si vous ne souhaitez pas utiliser cette option,
vous pouvez inscrire les noms d’hôte de votre machine virtuelle sur votre serveur DNS à
l’aide du DNS dynamique (DDNS, Dynamic DNS). Comme Azure ne dispose pas des
informations d’identification permettant de créer directement des enregistrements sur
vos serveurs DNS, d’autres mécanismes sont souvent nécessaires. Nous présentons ci-
après quelques scénarios courants avec des solutions alternatives :
Clients Windows
Les clients Windows non joints à un domaine tentent des mises à jour DDNS non
sécurisées pendant le démarrage ou la modification de leurs adresses IP. Le nom DNS se
compose du nom d’hôte et du suffixe DNS principal. Azure laisse le suffixe DNS principal
vide, mais vous pouvez définir le suffixe dans la machine virtuelle, par le biais de
l’interface utilisateur ou de PowerShell.
Les clients Windows joints à un domaine inscrivent leurs adresses IP auprès du

contrôleur de domaine à l’aide de la mise à jour DDNS sécurisée. Le processus de
jonction de domaine définit le suffixe DNS principal sur le client, puis crée et gère la
relation d’approbation.
Clients Linux
En général, les clients Linux ne s’inscrivent pas eux-mêmes auprès du serveur DNS au
démarrage et présument que ce dernier le fait à leur place. Les serveurs DHCP d’Azure
ne disposent pas des informations d’identification permettant de stocker des
enregistrements sur votre serveur DNS. Vous pouvez utiliser un outil appelé nsupdate ,
qui est inclus dans le package Bind, pour envoyer des mises à jour DDNS. Comme le
protocole DDNS est normalisé, vous pouvez utiliser nsupdate même quand vous
n’utilisez pas Bind sur le serveur DNS.
Vous pouvez utiliser les raccordements fournis par le client DHCP pour créer et gérer
l’entrée du nom d’hôte sur le serveur DNS. Au cours du cycle DHCP, le client exécute les
scripts dans /etc/dhcp/dhclient-exit-hooks.d/ . Vous pouvez utiliser les raccordements
pour inscrire la nouvelle adresse IP à l’aide nsupdate . Par exemple :
Bash
#!/bin/sh
requireddomain=mydomain.local
# only execute on the primary nic

if [ "$interface" != "eth0" ]
then
return
fi
# When you have a new IP, perform nsupdate

if [ "$reason" = BOUND ] || [ "$reason" = RENEW ] ||
[ "$reason" = REBIND ] || [ "$reason" = REBOOT ]
then
host=`hostname`
nsupdatecmds=/var/tmp/nsupdatecmds
echo "update delete $host.$requireddomain a" > $nsupdatecmds
echo "update add $host.$requireddomain 3600 a $new_ip_address" >>
$nsupdatecmds
echo "send" >> $nsupdatecmds
nsupdate $nsupdatecmds
fi
Vous pouvez également utiliser la commande nsupdate pour effectuer des mises à jour
DDNS sécurisées. Par exemple, quand vous utilisez un serveur DNS Bind, une paire de
clés publique-privée est générée ( http://linux.yyz.us/nsupdate/ ). Le serveur DNS est
configuré ( http://linux.yyz.us/dns/ddns-server.html ) avec la partie publique de la clé,
ce qui lui permet de vérifier la signature sur la demande. Pour fournir la paire de clés à
nsupdate , utilisez l’option -k , afin que la demande de mise à jour DDNS soit signée.
Quand vous utilisez un serveur DNS Windows, vous pouvez utiliser l’authentification
Kerberos avec le paramètre -g dans nsupdate (mais elle n’est pas disponible dans la
version Windows de nsupdate ). Pour utiliser Kerberos, utilisez kinit afin de charger les
informations d’identification. Par exemple, vous pouvez charger les informations
d’identification à partir d’un fichier keytab , puis nsupdate -g récupère les informations
d’identification à partir du cache.
Si nécessaire, vous pouvez ajouter un suffixe de recherche DNS à vos machines

virtuelles. Le suffixe DNS est spécifié dans le fichier /etc/resolv.conf . Comme la plupart
des distributions Linux gèrent automatiquement le contenu de ce fichier, il ne peut
généralement pas être modifié. Toutefois, vous pouvez remplacer le suffixe à l’aide de la
commande supersede du client DHCP. Pour remplacer le suffixe, ajoutez la ligne
suivante au fichier /etc/dhcp/dhclient.conf :
supersede domain-name <required-dns-suffix>;

Optimiser le débit du réseau des
machines virtuelles Azure
Les machines virtuelles Azure disposent de paramètres réseau par défaut qui peuvent
être davantage optimisés pour le débit du réseau. Cet article décrit comment optimiser
le débit du réseau pour les machines virtuelles Microsoft Azure Windows et Linux,
notamment les distributions majeures telles que Ubuntu, CentOS et Red Hat.
Machines virtuelles Windows

Si votre machine virtuelle Windows prend en charge les performances réseau accélérées,
activez cette fonctionnalité pour un débit optimal. Pour plus d’informations, consultez
l’article Créer une machine virtuelle avec les performances réseau accélérées.
Pour toutes les autres machines virtuelles Windows, l’utilisation de la mise à l’échelle
côté réception (RSS) peut permettre d’atteindre un débit maximal supérieur à celui
d’une machine virtuelle sans RSS. La mise à l’échelle côté réception (RSS) peut être
désactivée par défaut sur une machine virtuelle Windows. Pour déterminer si la mise à
l’échelle côté réception (RSS) est activée et, si elle ne l’est pas, l’activer, effectuez les
étapes suivantes :
1. Utilisez la commande PowerShell Get-NetAdapterRss pour déterminer si la mise à

l’échelle côté réception (RSS) est activée sur une carte réseau. Dans l’exemple de
sortie suivant retourné par Get-NetAdapterRss , la mise à l’échelle côté réception
(RSS) n’est pas activée.
PowerShell
Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : False
2. Pour activer la mise à l’échelle côté réception (RSS), entrez la commande suivante :
PowerShell
Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}

Cette commande n’a pas de sortie. La commande modifie les paramètres de carte
réseau. Elle provoque une perte de connectivité temporaire pendant environ une
minute. Une boîte de dialogue de reconnexion s’affiche lors de la perte de
connectivité. En général, la connectivité est rétablie après la troisième tentative.
3. Vérifiez que la mise à l’échelle côté réception (RSS) est activée sur la machine
virtuelle en entrant de nouveau la commande Get-NetAdapterRss . Si l’opération
réussit, l’exemple de sortie suivant est retourné :
PowerShell
Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : True
Machines virtuelles Linux

La mise à l’échelle côté réception (RSS) est toujours activée par défaut sur une machine
virtuelle Azure Linux. Les noyaux Linux publiés depuis octobre 2017 incluent de
nouvelles options d’optimisation du réseau qui permettent à une machine virtuelle Linux
d’obtenir un débit réseau plus élevé.
Ubuntu pour les nouveaux déploiements

Le noyau Ubuntu Azure est le plus optimisé pour les performances réseau sur Azure.
Pour obtenir les dernières optimisations, installez d’abord la version la plus récente de
18.04-LTS, comme suit :
JSON
"Publisher": "Canonical",
"Offer": "UbuntuServer",
"Sku": "18.04-LTS",
"Version": "latest"
Une fois la création terminée, entrez les commandes suivantes pour obtenir les mises à
jour les plus récentes. Ces étapes fonctionnent aussi pour les machines virtuelles qui
s’exécutent actuellement sur le noyau Ubuntu Azure.
Bash
#run as root or preface with sudo

sudo apt-get -y update
sudo apt-get -y upgrade
sudo apt-get -y dist-upgrade
En cas d’échec de la mise à jour avec erreurs sur un déploiement Ubuntu existant ayant
déjà le noyau Azure, ce jeu de commandes facultatif peut être utile.
Bash
#optional steps might be helpful in existing deployments with the Azure

kernel
sudo apt-get -f install
sudo apt-get --fix-missing install
sudo apt-get clean
sudo apt-get -y upgrade
sudo apt-get -y dist-upgrade
Mise à niveau du noyau Ubuntu Azure pour les machines virtuelles

existantes
Vous pouvez obtenir des performances significatives en termes de débit en effectuant

une mise à niveau vers le noyau Azure Linux. Pour vérifier si vous avez ce noyau, vérifiez
la version de votre noyau. Elle doit être identique ou ultérieure à l’exemple.
Bash
#Azure kernel name ends with "-azure"

uname -r
#sample output on Azure kernel:

#4.13.0-1007-azure
Si votre machine virtuelle ne dispose pas du noyau Azure, le numéro de version

commence en général par « 4.4 ». Si la machine virtuelle n’a pas le noyau Azure,
exécutez les commandes suivantes à la racine :
Bash

sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get dist-upgrade -y
sudo apt-get install "linux-azure"
sudo reboot
CentOS
Pour bénéficier des dernières optimisations, nous vous recommandons de créer une
machine virtuelle avec la version la plus récente prise en charge en spécifiant les
paramètres suivants :
JSON
"Publisher": "OpenLogic",
"Offer": "CentOS",
"Sku": "7.7",
"Version": "latest"
Il peut être bénéfique pour les machines virtuelles nouvelles ou existantes d’installer la
dernière version de Linux Integration Services (LIS). L’optimisation du débit est incluse
dans les LIS, à partir de la version 4.2.2-2. Les versions ultérieures contiennent d’autres
améliorations. Entrez les commandes suivantes pour installer la dernière version de LIS :
Bash
sudo yum update

sudo reboot
sudo yum install microsoft-hyper-v
Red Hat
Pour bénéficier des optimisations, nous vous recommandons de créer une machine
virtuelle avec la version la plus récente prise en charge en spécifiant les paramètres
suivants :
JSON
"Publisher": "RedHat"
"Offer": "RHEL"
"Sku": "7-RAW"
"Version": "latest"
Les machines virtuelles nouvelles et existantes peuvent tirer parti de l’installation de la

dernière version de LIS. L’optimisation du débit est incluse dans les LIS, à partir de la
version 4.2. Entrez les commandes suivantes pour télécharger et installer les LIS :
Bash
wget https://aka.ms/lis
tar xvf lis
cd LISISO
sudo ./install.sh #or upgrade.sh if prior LIS was previously installed
Pour en savoir plus sur Linux Integration Services version 4.3 pour Hyper-V, consultez la
page de téléchargement .
Étapes suivantes
Déployer des machines virtuelles proches les unes des autres pour une faible
latence avec des groupes de placement de proximité.
Découvrir le résultat optimisé avec le test de bande passante/débit pour votre
scénario.
Découvrir comment la bande passante est allouée aux machines virtuelles.
En savoir plus avec le FAQ sur les réseaux virtuels Azure.
Afficher et modifier les noms d’hôte
Le nom d’hôte identifie votre machine virtuelle (MV) dans l’interface utilisateur et les
opérations Azure. Vous devez d’abord attribuer le nom d’hôte d’une MV dans le champ
Nom de la machine virtuelle pendant le processus de création dans le portail Azure.
Après avoir créé une MV, vous pouvez afficher et modifier le nom d’hôte via une
connexion à distance ou dans le portail Azure.
Afficher les noms d’hôte

Vous pouvez afficher le nom d’hôte de votre MV dans un service cloud à l’aide de l’un
des outils suivants.
Portail Azure
Dans le portail Azure, accédez à votre MV, puis sélectionnez Propriétés dans le volet de
navigation de gauche. Dans la page Propriétés, vous pouvez afficher le nom d’hôte sous
Nom de l’ordinateur.
Bureau à distance
Vous pouvez vous connecter à votre MV à l’aide d’un outil de bureau à distance tel que
Bureau à distance (Windows), la communication à distance Windows PowerShell
(Windows), SSH (Linux et Windows) ou Bastion (portail Azure). Vous pouvez ensuite
afficher le nom d’hôte de plusieurs façons :
Tapez le nom d’hôte dans PowerShell, l’invite de commande ou le terminal SSH.

Tapez ipconfig /all dans l’invite de commande (uniquement dans Windows).
Affichez le nom d’ordinateur dans les paramètres système.
API Azure
À partir d’un client REST. suivez ces instructions :
1. Vérifiez que vous disposez d’une connexion authentifiée au portail Azure. Suivez
les étapes présentées dans Créer une application et un principal du service Azure
Active Directory pouvant accéder aux ressources.
2. Envoyez une demande au format suivant :
HTTP
GET
https://management.azure.com/subscriptions/{subscriptionId}/resourceGro
ups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{vm
Name}?api-version=2022-11-01`.
Pour plus d’informations sur les demandes GET pour les machines virtuelles,
consultez Machines virtuelles - Get.
3. Recherchez osProfile, puis l’élément computerName pour trouver le nom d’hôte.
２ Avertissement
Vous pouvez également afficher le suffixe de domaine interne de votre service

cloud en exécutant ipconfig /all à partir d'une invite de commandes dans une
session de bureau à distance (Windows), ou en exécutant cat /etc/resolv.conf à
partir d'un terminal SSH (Linux).
Modifier un nom d’hôte

Vous pouvez modifier le nom d’hôte de n’importe quelle MV en renommant l’ordinateur
à partir d’une session de bureau à distance ou en utilisant Exécuter la commande dans
le portail Azure.
À partir d’une session à distance :
Pour Windows, vous pouvez modifier le nom d’hôte à partir de PowerShell à l’aide
de la commande Renommer-ordinateur.
Pour Linux, vous pouvez modifier le nom d’hôte à l’aide de hostnamectl .
Vous pouvez également utiliser exécuter ces commandes pour rechercher le nom d’hôte
de votre MV à partir du portail Azure en utilisant Exécuter la commande. Dans le portail
Azure, accédez à votre MV, puis sélectionnez Exécuter la commande dans le volet de
navigation de gauche. Sur la page Exécuter la commande dans le portail Azure :
Pour Windows, sélectionnez RunPowerShellScript et utilisez Rename-Computer dans

le volet Exécuter le script de commande.
Pour Linux, sélectionnez RunShellScript et utilisez hostnamectl dans le volet
Exécuter le script de commande.
L’image suivante montre la page Exécuter la commande dans le portail Azure pour une
MV Windows.
Après avoir exécuté Rename-Computer ou hostnamectl sur votre MV, vous devez
redémarrer votre MV pour changer le nom d’hôte.
Modèle de déploiement classique Azure

Le modèle de déploiement Azure Classic utilise un fichier config que vous pouvez
télécharger et charger pour modifier le nom d’hôte. Pour permettre à votre nom d’hôte
de référencer vos instances de rôle, vous devez définir la valeur du nom d’hôte dans le
fichier de configuration de service associé à chaque rôle. Pour ce faire, ajoutez le nom
d’hôte souhaité à l’attribut vmName de l’élément Role. La valeur de l’attribut vmName
est utilisée comme base de nom d’hôte pour chaque instance de rôle.
Par exemple, si vmName est webrole et qu’il existe trois instances de ce rôle, les noms
d’hôte des instances s’intitulent webrole0, webrole1 et webrole2. Il n’est pas nécessaire
de définir un nom d’hôte pour les machines virtuelles dans le fichier config, car le nom
d’hôte d’une MV est renseigné en fonction du nom de la machine virtuelle. Pour en
savoir plus sur la configuration d’un service Microsoft Azure, consultez la section
Schéma de configuration du service Azure (fichier .cscfg)
Fichier de configuration de service

Pour un modèle de déploiement Azure Classic, vous pouvez télécharger le fichier de
configuration de service d’un service déployé à partir du volet Configurer du service
dans le portail Azure. Pour connaître le nom d’hôte, il vous suffit de rechercher l’attribut
vmName associé à l’élément Nom de rôle. Gardez à l’esprit que ce nom d’hôte est
utilisé comme base pour le nom d’hôte de chaque instance de rôle. Par exemple, si
vmName est webrole et qu’il existe trois instances de ce rôle, les noms d’hôte des
instances s’intitulent webrole0, webrole1 et webrole2. Pour plus d'informations, consultez
Schéma de configuration d’un Réseau virtuel Azure
Étapes suivantes
Résolution de noms pour les machines virtuelles et les instances de rôle
Définir les paramètres DNS à l'aide de fichiers de configuration réseau
Journalisation des ressources pour un groupe
Un groupe de sécurité réseau (NSG) comprend les règles qui autorisent ou refusent le trafic vers un
sous-réseau de réseau virtuel, une interface réseau, ou les deux à la fois.
Quand vous activez la journalisation pour un groupe de sécurité réseau, vous pouvez collecter les
types suivants d’informations sur le journal de ressources :
Événement : Entrées enregistrées pour lesquelles des règles NSG sont appliquées aux machines
virtuelles, en fonction de l’adresse MAC.
Compteur de règle : contient des entrées correspondant au nombre de fois où chaque règle
NSG est appliquée pour autoriser ou refuser le trafic. L’état de ces règles est collecté toutes les
300 secondes.
Les journaux de ressources ne sont disponibles que pour les groupes de sécurité réseau déployés via
le modèle de déploiement Azure Resource Manager. Vous ne pouvez pas activer la journalisation des
ressources pour des groupes de sécurité réseau déployés via le modèle de déploiement classique.
Pour plus d’informations, consultez Comprendre les modèles de déploiement.
La journalisation des ressources est activée séparément pour chaque groupe de sécurité réseau sur
lequel des données de diagnostic sont collectées. Si vous êtes plutôt intéressé par les journaux
d’activité ou opérationnels, consultez Vue d’ensemble des journaux de la plateforme Azure. Si vous
êtes intéressé par le trafic IP passant via les groupes de sécurité réseau, consultez les Journaux de
flux des groupes de sécurité réseau.
Activation de la journalisation
Vous pouvez utiliser le portail Azure, Azure PowerShell ou Azure CLI pour activer la journalisation des
ressources.
Portail Azure
1. Connectez-vous au portail Azure .
2. Dans la zone de recherche située en haut du portail Azure, entrez des groupes de sécurité
réseau. Dans les résultats de la recherche, sélectionnez Groupe de sécurité réseau.
3. Sélectionnez le groupe de sécurité réseau pour lequel activer la journalisation.
4. Sous Supervision, sélectionnez Paramètres de diagnostic, puis sélectionnez Ajouter un

paramètre de diagnostic :

5. Dans Paramètre de diagnostic, entrez un nom, tel que myNsgDiagnostic.
6. Pour Journaux, sélectionnez allLogs ou des catégories individuelles de journaux. Pour plus
d’informations sur chaque catégorie, consultez Catégories de journaux.
7. Sous Détails de la destination, sélectionnez une ou plusieurs destinations :
Envoyer à l’espace de travail Log Analytics

Archiver dans un compte de stockage
Diffuser vers un hub d’événements
Envoyer à une solution de partenaire
Pour plus d’informations, consultez Destinations de journaux.
8. Sélectionnez Enregistrer.
9. Consultez et analysez les journaux d’activité. Pour plus d’informations, voir Afficher et analyser
les journaux d’activité.
Azure PowerShell
７ Notes
Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure.
Pour commencer, 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 contenues dans cette section 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 pour rechercher la version
installée. Si vous devez effectuer une mise à niveau, consultez Installer le module Azure PowerShell.
Si vous exécutez PowerShell localement, vous devez aussi exécuter la cmdlet Connect-AzAccount
pour vous connecter à Azure avec un compte disposant des autorisations nécessaires.
Pour activer la journalisation des ressources, vous avez besoin de l’ID d’un groupe de sécurité réseau
existant. Si vous n’avez pas de groupe de sécurité réseau, créez-en un à l’aide de la cmdlet New-
AzNetworkSecurityGroup.
Obtenez le groupe de sécurité réseau sur lequel vous souhaitez activer la journalisation des
ressources à l’aide de la cmdlet Get-AzNetworkSecurityGroup. Stockez le groupe de sécurité réseau
dans une variable pour une utilisation ultérieure. Par exemple, pour récupérer un groupe de sécurité
réseau nommé myNsg, qui existe dans un groupe de ressources appelé myResourceGroup, entrez la
commande suivante :
Azure PowerShell
$Nsg=Get-AzNetworkSecurityGroup `
-Name myNsg `
-ResourceGroupName myResourceGroup
Vous pouvez écrire des journaux de ressources sur différents types de destination. Pour plus
d’informations, consultez Destinations de journaux. Dans cet article, les journaux sont envoyés vers
une destination d’espace de travail Log Analytics. Si vous n’avez pas d’espace de travail, vous pouvez
en créer un à l’aide de la cmdlet New-AzOperationalInsightsWorkspace.
Récupérez un espace de travail Log Analytics existant à l’aide la cmdlet Get-

AzOperationalInsightsWorkspace. Par exemple, pour obtenir et stocker un espace de travail existant
appelé myWorkspace dans un groupe de ressources appelé myWorkspaces, entrez la commande
suivante :
Azure PowerShell
$Oms=Get-AzOperationalInsightsWorkspace `
-ResourceGroupName myWorkspaces `
-Name myWorkspace
Il existe deux catégories de journalisation que vous pouvez activer. Pour plus d’informations,
consultez Catégories de journal. Activez la journalisation des ressources du groupe de sécurité
réseau à l’aide de la cmdlet New-AzDiagnosticSetting. L’exemple suivant journalise des données de
catégorie événements et compteur dans l’espace de travail d’un groupe de sécurité réseau. Il utilise
les ID du groupe de sécurité réseau et de l’espace de travail que vous avez obtenus avec les
commandes précédentes :
Azure PowerShell
New-AzDiagnosticSetting `
-Name myDiagnosticSetting `
-ResourceId $Nsg.Id `
-WorkspaceId $Oms.ResourceId
Si vous voulez journaliser les données dans une autre destination que celle d’un espace de travail
Log Analytics, utilisez un paramètre approprié dans la commande. Pour plus d’informations,
consultez la page Journaux de ressources dans Azure.
Pour plus d’informations sur les paramètres, consultez New-AzDiagnosticSetting.
Consultez et analysez les journaux d’activité. Pour plus d’informations, voir Afficher et analyser les
journaux d’activité.
Azure CLI
Vous pouvez exécuter les commandes contenues dans cette section dans Azure Cloud Shell , ou en
exécutant Azure CLI à 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 l’interface CLI à partir de votre ordinateur, vous avez besoin de la version 2.0.38 ou
ultérieure. Exécutez az --version sur votre ordinateur pour trouver la version installée. Si vous devez
mettre à niveau, consultez Installation d’Azure CLI. Si vous exécutez l’interface CLI localement, vous
devez aussi exécuter az login pour vous connecter à Azure avec un compte disposant des
autorisations nécessaires.
Pour activer la journalisation des ressources, vous avez besoin de l’ID d’un groupe de sécurité réseau
existant. Si vous n’avez pas de groupe de sécurité réseau, créez-en un à l’aide de az network nsg
create.
Obtenez et stockez le groupe de sécurité réseau pour lequel vous souhaitez activer la journalisation
des ressources avec az network nsg show. Par exemple, pour récupérer un groupe de sécurité réseau
nommé myNsg, qui existe dans un groupe de ressources appelé myResourceGroup, entrez la
commande suivante :
Azure CLI
nsgId=$(az network nsg show \

--name myNsg \
--resource-group myResourceGroup \
--query id \
--output tsv)
Vous pouvez écrire des journaux de ressources sur différents types de destination. Pour plus
d’informations, consultez Destinations de journaux. Dans cet article, des journaux sont envoyés vers
une destination d’espace de travail Log Analytics, par exemple. Pour plus d’informations, consultez
Catégories de journal.
Activez la journalisation des ressources pour le groupe de sécurité réseau avec az monitor
diagnostic-settings create. L’exemple suivant journalise les données de catégorie événements et
compteur dans un espace de travail existant appelé myWorkspace, qui se trouve dans un groupe de
ressources appelé myWorkspaces. Il utilise l’ID du groupe de sécurité réseau que vous avez
enregistré à l’aide de la commande précédente.
Azure CLI
az monitor diagnostic-settings create \

--name myNsgDiagnostics \
--resource $nsgId \
--logs '[ { "category": "NetworkSecurityGroupEvent", "enabled": true,
"retentionPolicy": { "days": 30, "enabled": true } }, { "category":
"NetworkSecurityGroupRuleCounter", "enabled": true, "retentionPolicy": { "days": 30,
"enabled": true } } ]' \
--workspace myWorkspace \
--resource-group myWorkspaces
Si vous n’avez pas d’espace de travail, créez-en un à l’aide du portail Azure ou de PowerShell. Il existe
deux catégories de journalisation pour lesquelles vous pouvez activer les journaux d’activité.
Si vous souhaitez journaliser les données d’une seule des deux catégories, supprimez l’autre
catégorie de la commande précédente. Si vous voulez journaliser les données dans une autre
destination que celle d’un espace de travail Log Analytics, utilisez un paramètre approprié. Pour plus
d’informations, consultez la page Journaux de ressources dans Azure.
Consultez et analysez les journaux d’activité. Pour plus d’informations, voir Afficher et analyser les
journaux d’activité.
Destinations des journaux

Vous pouvez envoyer des données de diagnostics aux options suivantes :
Espace de travail Log Analytics

Azure Event Hubs
Stockage Azure
Intégrations partenaires d’Azure Monitor
Catégories de journal
Les données au format JSON sont écrites pour les catégories de journaux suivantes : événements et
compteur de règle.
Événement
Le journal des événements contient des informations sur les règles des groupes de sécurité réseau
qui sont appliquées aux machines virtuelles, en fonction de l’adresse MAC. Les données suivantes
sont enregistrées pour chaque événement. Dans l’exemple suivant, les données sont enregistrées
pour une machine virtuelle avec l’adresse IP 192.168.1.4 et l’adresse MAC 00-0D-3A-92-6A-7C :
JSON
{
"time": "[DATE-TIME]",
"systemId": "[ID]",
"category": "NetworkSecurityGroupEvent",
"resourceId": "/SUBSCRIPTIONS/[SUBSCRIPTION-ID]/RESOURCEGROUPS/[RESOURCE-GROUP-
NAME]/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/[NSG-NAME]",
"operationName": "NetworkSecurityGroupEvents",
"properties": {
"vnetResourceGuid":"[ID]",
"subnetPrefix":"192.168.1.0/24",
"macAddress":"00-0D-3A-92-6A-7C",
"primaryIPv4Address":"192.168.1.4",
"ruleName":"[SECURITY-RULE-NAME]",
"direction":"[DIRECTION-SPECIFIED-IN-RULE]",
"priority":"[PRIORITY-SPECIFIED-IN-RULE]",
"type":"[ALLOW-OR-DENY-AS-SPECIFIED-IN-RULE]",
"conditions":{
"protocols":"[PROTOCOLS-SPECIFIED-IN-RULE]",
"destinationPortRange":"[PORT-RANGE-SPECIFIED-IN-RULE]",
"sourcePortRange":"[PORT-RANGE-SPECIFIED-IN-RULE]",
"sourceIP":"[SOURCE-IP-OR-RANGE-SPECIFIED-IN-RULE]",
"destinationIP":"[DESTINATION-IP-OR-RANGE-SPECIFIED-IN-RULE]"
}
}
}
Compteur de règles
Le journal du compteur de règles contient des informations sur chacune des règles appliquées aux
ressources. Les données de l’exemple suivant sont enregistrées chaque fois qu’une règle est
appliquée. Dans l’exemple suivant, les données sont enregistrées pour une machine virtuelle avec
l’adresse IP 192.168.1.4 et l’adresse MAC 00-0D-3A-92-6A-7C :
JSON
{
"time": "[DATE-TIME]",
"systemId": "[ID]",
"category": "NetworkSecurityGroupRuleCounter",
"resourceId": "/SUBSCRIPTIONS/[SUBSCRIPTION ID]/RESOURCEGROUPS/[RESOURCE-GROUP-
NAME]/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/[NSG-NAME]",
"operationName": "NetworkSecurityGroupCounters",
"properties": {
"vnetResourceGuid":"[ID]",
"subnetPrefix":"192.168.1.0/24",
"macAddress":"00-0D-3A-92-6A-7C",
"primaryIPv4Address":"192.168.1.4",
"ruleName":"[SECURITY-RULE-NAME]",
"direction":"[DIRECTION-SPECIFIED-IN-RULE]",
"type":"[ALLOW-OR-DENY-AS-SPECIFIED-IN-RULE]",
"matchedConnections":125
}
}
７ Notes
L’adresse IP source pour la communication n’est pas enregistrée. Vous pouvez activer la
journalisation des flux NSG d’un groupe de sécurité réseau ; il journalise toutes les informations
du compteur de règle et l’adresse IP source qui a initié la communication. Les données du
journal de flux NSG sont écrites dans un compte Stockage Azure. Vous pouvez analyser les
données avec la fonctionnalité d’analytique du trafic d’Azure Network Watcher.
Afficher et analyser les journaux d’activité

Si vous envoyez des données de diagnostic à :
Journaux d’activité Azure Monitor : vous pouvez utiliser la solution d’analytique de groupe de
sécurité réseau pour obtenir des insights plus poussés. La solution offre des visualisations pour
les règles NSG qui autorisent ou refusent le trafic, par adresse MAC, de l’interface réseau sur
une machine virtuelle.
Compte de stockage Azure : les données sont écrites dans un fichier PT1H.json. Vous pouvez
trouver le :
Journal des événements qui se trouve dans le chemin suivant : insights-logs-
networksecuritygroupevent/resourceId=/SUBSCRIPTIONS/[ID]/RESOURCEGROUPS/[RESOURCE-
GROUP-NAME-FOR-NSG]/PROVIDERS/MICROSOFT.
NETWORK/NETWORKSECURITYGROUPS/[NSG NAME]/y=[YEAR]/m=[MONTH/d=[DAY]/h=
[HOUR]/m=[MINUTE]
Journal du compteur de règle qui se trouve dans le chemin suivant : insights-logs-
networksecuritygrouprulecounter/resourceId=/SUBSCRIPTIONS/[ID]/RESOURCEGROUPS/[RESOURCE-
GROUP-NAME-FOR-NSG]/PROVIDERS/MICROSOFT.
NETWORK/NETWORKSECURITYGROUPS/[NSG NAME]/y=[YEAR]/m=[MONTH/d=[DAY]/h=
[HOUR]/m=[MINUTE]
Pour savoir comment afficher les données des journaux de ressources, consultez Vue d’ensemble des
journaux de la plateforme Azure.
Étapes suivantes
Pour plus d’informations sur la journalisation d’activité, consultez Vue d’ensemble des journaux
d’une plateforme Azure.
La journalisation des activités est activée par défaut pour les groupes de sécurité réseau créés
au moyen d’un modèle de déploiement Azure. Pour déterminer les opérations qui ont été
effectuées sur les groupes de sécurité réseau dans le journal d’activité, recherchez les entrées
qui contiennent les types de ressources suivants :
Microsoft.ClassicNetwork/networkSecurityGroups
Microsoft.ClassicNetwork/networkSecurityGroups/securityRules
Microsoft.Network/networkSecurityGroups
Microsoft.Network/networkSecurityGroups/securityRules
Pour savoir comment journaliser des informations de diagnostic, consultez Journaliser le trafic
réseau vers et depuis une machine virtuelle à l'aide du portail Azure.
Tutoriel : Acheminer le trafic réseau avec
une table de routage à l’aide du portail
Azure
Article • 14/04/2023
Azure achemine le trafic entre tous les sous-réseaux au sein d’un réseau virtuel par
défaut. Vous pouvez créer vos propres itinéraires pour remplacer le routage par défaut
d’Azure. Les itinéraires personnalisés sont utiles, par exemple, quand vous souhaitez
router le trafic entre des sous-réseaux via une appliance virtuelle réseau (NVA).
＂ Créer un réseau virtuel et des sous-réseaux

＂ Créer une appliance NVA qui route le trafic
＂ Déployer des machines virtuelles sur différents sous-réseaux
＂ Créer une table de routage
＂ Créer un itinéraire
＂ Associer une table de routage à un sous-réseau
＂ Router le trafic d’un sous-réseau vers un autre via une NVA
CLI ou PowerShell.

commencer.
Vue d’ensemble
Ce diagramme montre les ressources créées dans ce tutoriel ainsi que les routes réseau
attendues.
Prérequis
Un abonnement Azure
Connexion à Azure

Dans cette section, vous allez créer un réseau virtuel, trois sous-réseaux et un hôte
bastion. Vous utiliserez l’hôte bastion pour vous connecter de manière sécurisée aux

réseau>Réseau virtuel, ou recherchez Réseau virtuel dans la zone de recherche du
portail.

Paramètre Valeur

Sélectionnez OK.
4. Sélectionnez l’onglet Adresses IP, ou sélectionnez le bouton Suivant : Adresses IP

au bas de la page.
5. Dans Espace d’adressage IPv4, sélectionnez l’espace d’adressage existant, puis

remplacez-le par 10.0.0.0/16.
6. Sélectionnez + Ajouter un sous-réseau, puis entrez Public comme Nom du sous-

8. Sélectionnez + Ajouter un sous-réseau, puis entrez Privé comme Nom du sous-

10. Sélectionnez + Ajouter un sous-réseau, puis entrez DMZ comme Nom du sous-
12. Sélectionnez l’onglet Sécurité, ou sélectionnez le bouton Suivant : Sécurité situé

au bas de la page.
Paramètre Valeur
Nom du bastion Entrez myBastionHost.

Paramètre Valeur

Dans le champ Nom, entrez myBastionIP.
Sélectionnez OK.
Créer une machine virtuelle NVA

Les appliances virtuelles réseau (NVA) sont des machines virtuelles qui facilitent les
fonctions réseau, telles que le routage et l’optimisation du pare-feu. Dans cette section,
vous allez créer une NVA à l’aide d’une machine virtuelle Windows Server 2019
Datacenter. Si vous le souhaitez, vous pouvez sélectionner un autre système
d’exploitation.

ressource>Calcul>Machine virtuelle, ou recherchez Machine virtuelle dans la zone
de recherche du portail.
Paramètre Valeur
Détails du
projet

ressources
Détails de
l’instance
Nom de la Entrez myVMNVA.

machine
virtuelle

Paramètre Valeur

disponibilité

sécurité

Spot

défaut.
Compte
administrateur

d’utilisateur

mot de passe
Règles des
ports d’entrée

d’entrée public

Paramètre Valeur
Interface réseau
Subnet Sélectionnez DMZ
Adresse IP publique Sélectionnez Aucun
Groupe de sécurité réseau de la carte réseau Sélectionnez De base

Paramètre Valeur
6. Sélectionnez l’onglet Vérifier + créer ou sélectionnez le bouton Vérifier + créer en

bas de la page.
Créer des machines virtuelles publique et

privée
Vous allez créer deux machines virtuelles dans le réseau virtuel myVirtualNetwork, puis
vous autoriserez le protocole ICMP (Internet Control Message Protocol) sur celles-ci afin
de pouvoir utiliser l’outil tracet pour suivre le trafic.
７ Notes
Pour les environnements de production, nous ne recommandons pas d’autoriser le

protocole ICMP (Internet Control Message Protocol) via le pare-feu Windows.
Créer une machine virtuelle publique

virtuelle.

Paramètre Valeur
Détails du
projet

ressources
Détails de
l’instance
Paramètre Valeur
Nom de la Entrez myVMPublic.

machine
virtuelle

disponibilité

sécurité

Spot

défaut.
Compte
administrateur

d’utilisateur

mot de passe
Règles des
ports d’entrée

d’entrée public

Paramètre Valeur
Interface réseau

Paramètre Valeur

Créer une machine virtuelle privée

virtuelle.

Paramètre Valeur
Détails du
projet

ressources
Détails de
l’instance
Nom de la Entrez myVMPrivate.

machine
virtuelle

disponibilité

sécurité

Paramètre Valeur

Spot

défaut.
Compte
administrateur

d’utilisateur

mot de passe
Règles des
ports d’entrée

d’entrée public

Paramètre Valeur
Interface réseau
Subnet Sélectionnez Privé.


Autoriser ICMP dans le pare-feu Windows
1. Sélectionnez Accéder à la ressource ou rechercher myVMPrivate dans la zone de
2. Sur la page de présentation de myVMPrivate, sélectionnez Se connecter, puis

Bastion.
3. Entrez le nom d’utilisateur et le mot de passe que vous avez précédemment créés
pour la machine virtuelle myVMPrivate.
4. Sélectionnez le bouton Connecter.
5. Ouvrez Windows PowerShell après vous être connecté.
6. Entrez cette commande :
PowerShell
7. À partir de PowerShell, établissez une connexion Bureau à distance avec la machine

virtuelle myVMPublic :
PowerShell
mstsc /v:myvmpublic

PowerShell et entrez la même commande qu’à l’étape 6.
Activer le transfert IP
Pour acheminer le trafic via l’appliance virtuelle réseau (NVA), activez le transfert IP dans
Azure et dans le système d’exploitation de la machine virtuelle myVMNVA. Une fois le
transfert IP activé, tout trafic reçu par la machine virtuelle myVMNVA et destiné à une
autre adresse IP ne fait l’objet d’aucune suppression et est transféré vers la bonne
destination.
Activer le transfert IP dans Azure

Dans cette section, vous allez activer le transfert IP pour l’interface réseau de la machine
virtuelle myVMNVA dans Azure.
1. Recherchez myVMNVA dans la zone de recherche du portail.
2. Sur la page de présentation de myVMNVA, accédez à la section Paramètres et

sélectionnez Mise en réseau.
3. Sur la page Mise en réseau de myVMNVA, sélectionnez l’interface réseau située en

regard de Interface réseau :. Le nom de l’interface commence par myvmnva.
4. Sur la page de présentation de l’interface réseau, accédez à la section Paramètres

et sélectionnez Configurations IP.
5. Dans la page Configurations IP, définissez Transfert IP sur Activé, puis

Activer le transfert IP dans le système d’exploitation
Dans cette section, vous allez activer le transfert IP pour le système d’exploitation de la
machine virtuelle myVMNVA afin de rediriger le trafic réseau. Vous utiliserez la
connexion bastion à la machine virtuelle myVMPrivate que vous avez lancée
précédemment pour établir une connexion Bureau à distance avec la machine virtuelle
myVMNVA.

connexion Bureau à distance avec la machine virtuelle myVMNVA :
PowerShell
mstsc /v:myvmnva
2. Après vous être connecté à la machine virtuelle myVMNVA, ouvrez Windows

PowerShell et entrez la commande suivante pour activer le transfert IP :
PowerShell
3. Redémarrez la machine virtuelle myVMNVA.
PowerShell
Restart-Computer
Dans cette section, vous allez créer une table de routage.

réseau>Table de routage, ou recherchez Table de routage dans la zone de
3. Sous l’onglet Informations de base de la page Créer une table de routage, entrez
Paramètre Valeur
Détails du projet
Name Entrez myRouteTablePublic.
Propager des itinéraires de passerelle Sélectionnez Oui.

Dans cette section, vous allez créer un itinéraire dans la table de routage que vous avez
créée précédemment.
1. Sélectionnez Accéder à la ressource ou rechercher myRouteTablePublic dans la

zone de recherche du portail.
2. Sur la page myRouteTablePublic, accédez à la section Paramètres et sélectionnez

Itinéraires.
3. Sur la page Itinéraires, sélectionnez le bouton + Ajouter.
4. Dans Ajouter un itinéraire, entrez ou sélectionnez ces informations :
Paramètre Valeur
Nom de l’itinéraire Entrez ToPrivateSubnet.

Paramètre Valeur
Destination du préfixe Sélectionnez Adresses IP.

d’adresse
Plages d’adresses Entrez 10.0.1.0/24 (plage d’adresses du sous-réseau Privé créé

IP/CIDR de destination précédemment).
Type de tronçon Sélectionnez Appliance virtuelle.

suivant
adresse de tronçon Entrez 10.0.2.4 (adresse de la machine virtuelle myVMNVA créée

suivant précédemment dans le sous-réseau DMZ).

Dans cette section, vous allez associer la table de routage que vous avez créée
précédemment à un sous-réseau.
1. Recherchez myVirtualNetwork dans la zone de recherche du portail.

2. Sur la page myVirtualNetwork, accédez à la section Paramètres et sélectionnez
Sous-réseaux.
3. Dans la liste de sous-réseaux du réseau virtuel, sélectionnez Public.
4. Dans Table de routage, sélectionnez la ressource myRouteTablePublic que vous

avez créée précédemment.
5. Sélectionnez Enregistrer pour associer votre table de route au sous-réseau Public.
Tester le routage du trafic réseau

À l’aide de l’outil tracet, vous allez tester le routage du trafic réseau de la machine
virtuelle myVMPublic vers la machine virtuelle myVMPrivate, puis vous le testerez dans
l’autre sens.
Tester le trafic réseau de la machine virtuelle myVMPublic

vers la machine virtuelle myVMPrivate
connexion Bureau à distance avec la machine virtuelle myVMPublic :
PowerShell
mstsc /v:myvmpublic

PowerShell et entrez la commande tracert suivante pour suivre le routage du trafic
réseau de la machine virtuelle myVMPublic vers la machine virtuelle myVMPrivate.
PowerShell
tracert myvmprivate
PowerShell
Tracing route to
myvmprivate.q04q2hv50taerlrtdyjz5nza1f.bx.internal.cloudapp.net
[10.0.1.4]
1 1 ms * 2 ms myvmnva.internal.cloudapp.net
[10.0.2.4]
2 2 ms 1 ms 1 ms myvmprivate.internal.cloudapp.net
[10.0.1.4]
Trace complete.
Vous pouvez voir qu’il existe deux tronçons dans la réponse ci-dessus pour le suivi
tracert du trafic ICMP de la machine virtuelle myVMPublic vers la machine virtuelle
myVMPrivate. Le premier tronçon correspond à la machine virtuelle myVMNVA et
le deuxième à la machine virtuelle myVMPrivate de destination.
Azure a envoyé le trafic du sous-réseau Public à travers la NVA et non directement
vers le sous-réseau Privé parce que vous avez précédemment ajouté l’itinéraire
ToPrivateSubnet à la table de routage myRouteTablePublic et l'avez associée au
sous-réseau Public.
Tester le trafic réseau de la machine virtuelle

myVMPrivate vers la machine virtuelle myVMPublic
1. À partir de PowerShell sur la machine virtuelle myVMPrivate, entrez cette
commande tracet pour suivre le routage du trafic réseau de la machine virtuelle
myVmPrivate vers la machine virtuelle myVmPublic.
PowerShell
tracert myvmpublic
PowerShell
Tracing route to
myvmpublic.q04q2hv50taerlrtdyjz5nza1f.bx.internal.cloudapp.net
[10.0.0.4]
1 1 ms 1 ms 1 ms myvmpublic.internal.cloudapp.net
[10.0.0.4]
Trace complete.
Vous pouvez voir qu’il n’existe qu’un seul tronçon dans la réponse ci-dessus. Celui-
ci correspond à la machine virtuelle myVMPublic de destination.
Azure a envoyé le trafic directement du sous-réseau Privé au sous-réseau Public.

Par défaut, Azure achemine directement le trafic entre les sous-réseaux.
2. Fermez la session bastion.

Quand vous n’avez plus besoin du groupe de ressources, supprimez myResourceGroup
et toutes les ressources qu’il contient :
sélectionnez-le.

Étapes suivantes
Créé une table de route que vous avez associée à un sous-réseau.

Créé une appliance virtuelle réseau (NVA) simple qui a routé le trafic d’un sous-
réseau public vers un sous-réseau privé.
Vous pouvez déployer, à partir de la Place de marché Azure , différentes appliances

virtuelles réseau préconfigurées qui fournissent de nombreuses fonctions réseau utiles.
Pour en savoir plus sur le routage, consultez Routage du trafic de réseau virtuel et Créer,
Pour apprendre à restreindre l’accès réseau aux ressources PaaS avec des points de
terminaison de service de réseau virtuel, passez au tutoriel suivant.

Acheminer le trafic réseau avec une
table de routage à l’aide de PowerShell
Article • 11/05/2023
Par défaut, Azure achemine automatiquement le trafic entre tous les sous-réseaux au
sein d’un réseau virtuel. Vous pouvez créer vos propres itinéraires pour remplacer le
routage par défaut d’Azure. La possibilité de créer des itinéraires personnalisés est utile
si, par exemple, vous souhaitez router le trafic entre des sous-réseaux via une appliance
virtuelle réseau (NVA). Dans cet article, vous apprendrez comment :

Créer un réseau virtuel comprenant plusieurs sous-réseaux
Créer une appliance NVA qui route le trafic
Déployer des machines virtuelles sur différents sous-réseaux
Router le trafic d’un sous-réseau vers un autre via une NVA

commencer.
Azure Cloud Shell

Azure héberge Azure Cloud Shell, un environnement d’interpréteur de commandes
interactif que vous pouvez utiliser dans votre navigateur. Vous pouvez utiliser Bash ou
PowerShell avec Cloud Shell pour utiliser les services Azure. Vous pouvez utiliser les
commandes préinstallées Cloud Shell pour exécuter le code de cet article sans avoir à
installer quoi que ce soit dans votre environnement local.
Pour démarrer Azure Cloud Shell :
Option Exemple/Lien
Sélectionnez Essayer dans le coin supérieur droite d’un bloc de codes ou

de commandes. La sélection de Essayer ne copie pas automatiquement le
code ni la commande dans Cloud Shell.
Accédez à https://shell.azure.com ou sélectionnez le bouton Lancer

Cloud Shell pour ouvrir Cloud Shell dans votre navigateur.
Sélectionnez le bouton Cloud Shell dans la barre de menus en haut à

droite du portail Azure .
Pour utiliser Azure Cloud Shell :
1. Démarrez Cloud Shell.
2. Sélectionnez le bouton Copier sur un bloc de codes (ou un bloc de commandes)

pour copier le code ou la commande.
3. Collez le code ou la commande dans la session Cloud Shell en sélectionnant

Ctrl+Maj+V sur Windows et Linux ou en sélectionnant Cmd+Maj+V sur macOS.
4. Sélectionnez Entrée pour exécuter le code ou la commande.
Si vous choisissez d’installer et d’utiliser PowerShell en local, vous devez exécuter le

module Azure PowerShell version 1.0.0 ou ultérieure pour les besoins de cet article.
Exécutez Get-Module -ListAvailable Az pour rechercher la version installée. Si vous
devez effectuer une mise à niveau, consultez Installer le module Azure PowerShell. Si
vous exécutez PowerShell en local, vous devez également lancer Connect-AzAccount
pour créer une connexion avec Azure.

Avant de pouvoir créer une table de routage, créez un groupe de ressources avec New-
AzResourceGroup. L’exemple suivant crée un groupe de ressources nommé
myResourceGroup pour toutes les ressources créées dans cet article.
Azure PowerShell
New-AzResourceGroup -ResourceGroupName myResourceGroup -Location EastUS
Créez une table de routage avec New-AzRouteTable. L’exemple suivant crée une table
de routage nommée myRouteTablePublic.
Azure PowerShell
$routeTablePublic = New-AzRouteTable `
-Name 'myRouteTablePublic' `
-ResourceGroupName myResourceGroup `
-location EastUS
Créez un itinéraire en récupérant l’objet de table de routage avec Get-AzRouteTable,
créez un itinéraire avec Add-AzRouteConfig, puis écrivez la configuration de l’itinéraire
dans la table de routage avec Set-AzRouteTable.
Azure PowerShell
Get-AzRouteTable `
-ResourceGroupName "myResourceGroup" `
-Name "myRouteTablePublic" `
| Add-AzRouteConfig `
-Name "ToPrivateSubnet" `
-AddressPrefix 10.0.1.0/24 `
-NextHopType "VirtualAppliance" `
-NextHopIpAddress 10.0.2.4 `
| Set-AzRouteTable

Avant de pouvoir associer une table de routage à un sous-réseau, vous devez créer un
réseau virtuel et un sous-réseau. Créez un réseau virtuel avec New-AzVirtualNetwork.
L’exemple suivant permet de créer un réseau virtuel nommé myVirtualNetwork avec le
préfixe d’adresse 10.0.0.0/16.
Azure PowerShell
$virtualNetwork = New-AzVirtualNetwork `
-Location EastUS `
-Name myVirtualNetwork `
-AddressPrefix 10.0.0.0/16
Créez trois sous-réseaux en créant trois configurations de sous-réseau avec New-

AzVirtualNetworkSubnetConfig. L’exemple suivant crée trois configurations de sous-
réseau pour les sous-réseaux Public, Private et DMZ :
Azure PowerShell
$subnetConfigPublic = Add-AzVirtualNetworkSubnetConfig `
-Name Public `
-VirtualNetwork $virtualNetwork
$subnetConfigPrivate = Add-AzVirtualNetworkSubnetConfig `
-Name Private `
$subnetConfigDmz = Add-AzVirtualNetworkSubnetConfig `
-Name DMZ `
Écrivez les configurations de sous-réseaux dans le réseau virtuel à l’aide de la

commande Set-AzVirtualNetwork, ce qui crée les sous-réseaux dans le réseau virtuel :
Azure PowerShell
Associez la table de routage myRouteTablePublic au sous-réseau Public avec Set-

AzVirtualNetworkSubnetConfig, puis écrivez la configuration du sous-réseau dans le
réseau virtuel avec Set-AzVirtualNetwork.
Azure PowerShell
Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $virtualNetwork `
-Name 'Public' `
-RouteTable $myRouteTablePublic | `
Set-AzVirtualNetwork
Créer une NVA

Une NVA est une machine virtuelle qui exécute une fonction réseau, telle que le routage,
la fonction de pare-feu ou l’optimisation WAN.
Avant de créer une machine virtuelle, créez une interface réseau.
Créer une interface réseau

Avant de créer une interface réseau, vous devez récupérer l’ID de réseau virtuel avec
Get-AzVirtualNetwork, puis l’ID de sous-réseau avec Get-
AzVirtualNetworkSubnetConfig. Créez une interface réseau avec New-
AzNetworkInterface dans le sous-réseau DMZ avec le transfert IP activé :
Azure PowerShell
# Retrieve the virtual network object into a variable.

$virtualNetwork=Get-AzVirtualNetwork `
# Retrieve the subnet configuration into a variable.
$subnetConfigDmz = Get-AzVirtualNetworkSubnetConfig `
-Name DMZ `
# Create the network interface.

$nic = New-AzNetworkInterface `
-Location EastUS `
-Name 'myVmNva' `
-SubnetId $subnetConfigDmz.Id `
-EnableIPForwarding
Créer une machine virtuelle

Pour créer une machine virtuelle et lui attacher une interface réseau existante, vous
devez d’abord créer une configuration de machine virtuelle avec New-AzVMConfig. La
configuration inclut l’interface réseau créée à l’étape précédente. Quand vous êtes invité
à indiquer un nom d’utilisateur et un mot de passe, sélectionnez ceux qui vous
permettront de vous connecter à la machine virtuelle.
Azure PowerShell
# Create a credential object.

$cred = Get-Credential -Message "Enter a username and password for the VM."
# Create a VM configuration.
$vmConfig = New-AzVMConfig `
-VMName 'myVmNva' `
-VMSize Standard_DS2 | `
Set-AzVMOperatingSystem -Windows `
-ComputerName 'myVmNva' `
-Credential $cred | `
Set-AzVMSourceImage `
-PublisherName MicrosoftWindowsServer `
-Offer WindowsServer `
-Skus 2016-Datacenter `
-Version latest | `
Add-AzVMNetworkInterface -Id $nic.Id
Créez la machine virtuelle avec la configuration de la machine virtuelle et New-AzVM.

L’exemple suivant crée une machine virtuelle nommée myVmNva.
Azure PowerShell
$vmNva = New-AzVM `
-Location EastUS `
-VM $vmConfig `
-AsJob
L’option -AsJob crée la machine virtuelle en arrière-plan. Vous pouvez donc passer à
l’étape suivante.

Créez deux machines virtuelles dans le réseau virtuel pour vérifier que le trafic provenant
du sous-réseau Public est acheminé vers le sous-réseau Private via l’appliance virtuelle
réseau lors d’une étape ultérieure.
Créez une machine virtuelle dans le sous-réseau Public avec New-AzVM. L’exemple
suivant crée une machine virtuelle nommée myVmPublic dans le sous-réseau Public du
réseau virtuel myVirtualNetwork.
Azure PowerShell
New-AzVm `
-Location "East US" `
-VirtualNetworkName "myVirtualNetwork" `
-SubnetName "Public" `
-ImageName "Win2016Datacenter" `
-Name "myVmPublic" `
-AsJob
Créez une machine virtuelle dans le sous-réseau Private.
Azure PowerShell
New-AzVm `
-SubnetName "Private" `
-Name "myVmPrivate"
La création de la machine virtuelle ne nécessite que quelques minutes. Attendez que la

machine virtuelle ait été créée et qu’Azure ait retourné la sortie à PowerShell pour
passer à l’étape suivante.
Router le trafic via une NVA

Utilisez Get-AzPublicIpAddress pour retourner l’adresse IP publique de la machine
virtuelle myVmPrivate. L’exemple suivant retourne l’adresse IP publique de la machine
virtuelle myVmPrivate :
Azure PowerShell
Get-AzPublicIpAddress `
-Name myVmPrivate `
| Select IpAddress
Utilisez la commande suivante pour créer une session Bureau à distance avec la machine
virtuelle myVmPrivate à partir de votre ordinateur local. Remplacez <publicIpAddress>
par l’adresse IP retournée par la commande précédente.
mstsc /v:<publicIpAddress>
Ouvrez le fichier .rdp téléchargé. Si vous y êtes invité, sélectionnez Connexion.
Entrez le nom d’utilisateur et le mot de passe spécifiés lors de la création de la machine

virtuelle (il se peut que vous deviez choisir Plus de choix, puis Utiliser un compte
différent pour spécifier les informations d’identification que vous avez entrées lors de la
création de la machine virtuelle), puis sélectionnez OK. Un avertissement de certificat
peut s’afficher pendant le processus de connexion. SélectionnezOui pour poursuivre le
processus de connexion.
À une étape ultérieure, la commande tracert.exe est utilisée pour tester le routage.
Tracert utilise le protocole ICMP (Internet Control Message Protocol), qui est refusé via
le Pare-feu Windows. Autorisez le protocole ICMP dans le pare-feu Windows en entrant
la commande suivante de PowerShell sur la machine virtuelle myVmPrivate :
PowerShell
New-NetFirewallRule -DisplayName "Allow ICMPv4-In" -Protocol ICMPv4
Bien que tracert soit utilisé pour tester le routage dans cet article, il n’est pas
recommandé d’autoriser le protocole IMCP dans le pare-feu Windows lors de
déploiements en production.
Vous avez activé le transfert d’IP dans Azure pour l’interface réseau de la machine
virtuelle dans Activer le transfert IP. Sur la machine virtuelle, le système d’exploitation ou
une application exécutée dans la machine virtuelle, doit également pouvoir transférer le
trafic réseau. Activez le transfert IP au sein du système d’exploitation de la machine
virtuelle myVmNva.
À partir d’une invite de commandes sur la machine virtuelle myVmPrivate, connectez le

Bureau à distance à la machine virtuelle myVmNva :
mstsc /v:myvmnva
Pour activer le transfert d’adresse IP au sein du système d’exploitation, entrez la

commande suivante dans PowerShell à partir de la machine virtuelle myVmNva :
PowerShell
Redémarrez la machine virtuelle myVmNva, ce qui va également déconnecter la session

Bureau à distance.
Tout en conservant la connexion à la machine virtuelle myVmPrivate, créez une session

Bureau à distance sur la machine virtuelle myVmPublic, une fois la machine virtuelle
myVmNva redémarrée :
mstsc /v:myVmPublic
Autorisez le protocole ICMP dans le pare-feu Windows en entrant la commande

suivante de PowerShell sur la machine virtuelle myVmPublic :
PowerShell
Pour tester le routage du trafic réseau vers la machine virtuelle myVmPrivate à partir de
la machine virtuelle myVmPublic, entrez la commande suivante de PowerShell sur la
machine virtuelle myVmPublic :
tracert myVmPrivate
La réponse ressemble à ce qui suit :
Tracing route to
myVmPrivate.vpgub4nqnocezhjgurw44dnxrc.bx.internal.cloudapp.net [10.0.1.4]
1 <1 ms * 1 ms 10.0.2.4
2 1 ms 1 ms 1 ms 10.0.1.4
Trace complete.
Vous voyez que le premier tronçon est 10.0.2.4, ce qui correspond à l’adresse IP privée
de l’appliance virtuelle réseau (NVA). Le second tronçon est 10.0.1.4, ce qui correspond à
l’adresse IP privée de la machine virtuelle myVmPrivate. L’itinéraire ajouté à la table de
routage myRouteTablePublic et associé au sous-réseau Public a contraint Azure à
acheminer le trafic via l’appliance virtuelle réseau et non directement au sous-réseau
Private.
Fermez la session Bureau à distance sur la machine virtuelle myVmPublic. Cela

n’interrompt pas la connexion à la machine virtuelle myVmPrivate.
Pour tester le routage du trafic réseau vers la machine virtuelle myVmPublic à partir de
la machine virtuelle myVmPrivate, entrez la commande suivante à l’invite de commandes
sur la machine virtuelle myVmPrivate :
tracert myVmPublic
Tracing route to
myVmPublic.vpgub4nqnocezhjgurw44dnxrc.bx.internal.cloudapp.net [10.0.0.4]
1 1 ms 1 ms 1 ms 10.0.0.4
Trace complete.
Vous pouvez voir que le trafic est routé directement de la machine virtuelle
myVmPrivate vers la machine virtuelle myVmPublic. Par défaut, Azure achemine
directement le trafic entre les sous-réseaux.
Fermez les sessions Bureau à distance sur la machine virtuelle myVmPrivate.

Lorsque vous n’avez plus besoin d’un groupe de ressources, utilisez Remove-
AzResourcegroup pour le supprimer, ainsi que toutes les ressources qu’il contient.
Azure PowerShell
Remove-AzResourceGroup -Name myResourceGroup -Force
Étapes suivantes
Dans cet article, vous avez créé une table de routage que vous avez associée à un sous-
réseau. Vous avez créé une appliance virtuelle réseau qui a acheminé le trafic d’un sous-
réseau public vers un sous-réseau privé. Vous pouvez déployer différentes appliances
virtuelles réseau préconfigurées ayant des fonctions de réseau, telles que la fonction de
pare-feu ou l’optimisation WAN, à partir de la Place de marché Microsoft Azure . Pour
en savoir plus sur le routage, consultez Routage du trafic de réseau virtuel et Créer,
Alors que vous pouvez déployer de nombreuses ressources Azure dans un réseau
virtuel, les ressources pour certains services Azure PaaS ne peuvent pas être déployées
dans un réseau virtuel. Cependant, vous pouvez toujours restreindre l’accès aux
ressources de certains services Azure PaaS au trafic provenant uniquement d’un sous-
réseau de réseau virtuel. Pour connaître la marche à suivre, consultez Restreindre l’accès
réseau aux ressources PaaS.
Acheminer le trafic réseau avec une
table de routage à l’aide de l’interface
de ligne de commande Azure
Article • 30/04/2023
Par défaut, Azure achemine automatiquement le trafic entre tous les sous-réseaux au
sein d’un réseau virtuel. Vous pouvez créer vos propres itinéraires pour remplacer le
routage par défaut d’Azure. La possibilité de créer des itinéraires personnalisés est utile
si, par exemple, vous souhaitez router le trafic entre des sous-réseaux via une appliance
virtuelle réseau (NVA). Dans cet article, vous apprendrez comment :

Créer un réseau virtuel comprenant plusieurs sous-réseaux
Créer une appliance virtuelle réseau (NVA) de base qui achemine le trafic à partir
d’une machine virtuelle Ubuntu
Déployer des machines virtuelles sur différents sous-réseaux
Router le trafic d’un sous-réseau vers un autre via une NVA
commencer.
Prérequis



upgrade.
Cet article nécessite la version 2.0.28 ou ultérieure d’Azure CLI. Si vous utilisez
Azure Cloud Shell, la version la plus récente est déjà installée.

Avant de pouvoir créer une table de routage, créez un groupe de ressources avec az
group create pour toutes les ressources créées dans cet article.
Azure CLI
# Create a resource group.

az group create \
--name myResourceGroup \
--location eastus
Créez une table de routage avec az network route-table create. L’exemple suivant crée
une table de routage nommée myRouteTablePublic.
Azure CLI
# Create a route table

az network route-table create \
--name myRouteTablePublic
Créez un itinéraire dans la table de routage avec az network route-table route create.
Azure CLI
az network route-table route create \

--name ToPrivateSubnet \
--route-table-name myRouteTablePublic \
--next-hop-type VirtualAppliance \
--next-hop-ip-address 10.0.2.4

Avant de pouvoir associer une table de routage à un sous-réseau, vous devez créer un
réseau virtuel et un sous-réseau. Créez un réseau virtuel avec un sous-réseau en utilisant
la commande az network vnet create.
Azure CLI

--name myVirtualNetwork \
--subnet-name Public \
--subnet-prefix 10.0.0.0/24
Créez deux sous-réseaux supplémentaires avec az network vnet subnet create.
Azure CLI
# Create a private subnet.

--vnet-name myVirtualNetwork \
--name Private \
# Create a DMZ subnet.

--name DMZ \
Associez la table de routage myRouteTablePublic au sous-réseau Public avec az network

vnet subnet update.
Azure CLI
az network vnet subnet update \

--name Public \
--route-table myRouteTablePublic
Créer une NVA

Une NVA est une machine virtuelle qui exécute une fonction réseau, telle que le routage,
la fonction de pare-feu ou l’optimisation WAN. Nous allons créer une appliance virtuelle
réseau de base à partir d’une machine virtuelle Ubuntu d’usage général, à des fins de
démonstration.
Créez une machine virtuelle à utiliser comme appliance virtuelle réseau dans le sous-
réseau DMZ avec az vm create. Par défaut, quand vous créez une machine virtuelle,
Azure crée et affecte une interface réseau myVmNvaVMNic et une adresse IP publique à
l’affecte à la machine virtuelle. Le paramètre --public-ip-address "" indique à Azure de
ne pas créer d’adresse IP publique et de ne pas l’affecter à la machine virtuelle, car celle-
ci n’a pas besoin de se connecter à Internet. 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 .
Azure CLI
az vm create \
--name myVmNva \
--image UbuntuLTS \
--public-ip-address "" \
--subnet DMZ \
--generate-ssh-keys
La création de la machine virtuelle ne nécessite que quelques minutes. Ne passez pas à

l’étape suivante tant qu’Azure n’a pas terminé la création de la machine virtuelle et
retourné de sortie concernant la machine virtuelle.
Pour qu’une interface réseau myVmNvaVMNic soit en mesure de transférer le trafic

réseau qui lui est envoyé, mais qui n’est pas destiné à sa propre adresse IP, le transfert
IP doit être activé pour l’interface réseau. Activez le transfert IP pour l’interface réseau
avec az network nic update.
Azure CLI
az network nic update \

--name myVmNvaVMNic \
--ip-forwarding true
Sur la machine virtuelle, le système d’exploitation ou une application exécutée dans la

machine virtuelle, doit également pouvoir transférer le trafic réseau. Nous allons utiliser
la commande sysctl pour permettre au noyau Linux de transférer des paquets. Pour
exécuter cette commande sans vous connecter à la machine virtuelle, nous allons utiliser
l’extension de script personnaliséaz vm extension set :
Azure CLI
az vm extension set \
--vm-name myVmNva \
--name customScript \
--publisher Microsoft.Azure.Extensions \
--settings '{"commandToExecute":"sudo sysctl -w net.ipv4.ip_forward=1"}'
L’exécution de la commande peut prendre jusqu’à une minute. Notez que cette
modification ne sera pas conservée après un redémarrage de machine virtuelle. Par
conséquent, si la machine virtuelle réseau est redémarrée pour une raison quelconque,
vous devez répéter le script.

Créez deux machines virtuelles dans le réseau virtuel de manière à pouvoir vérifier, lors
d’une étape ultérieure, que le trafic provenant du sous-réseau Public est acheminé vers
le sous-réseau Private via l’appliance virtuelle réseau.
Créez une machine virtuelle dans le sous-réseau Public avec az vm create. Le paramètre
--no-wait permet à Azure d’exécuter la commande en arrière-plan de façon que vous
puissiez continuer jusqu’à la commande suivante. Pour simplifier cet article, un mot de
passe est utilisé. Les clés sont généralement utilisées dans les déploiements en
production. Si vous utilisez des clés, vous devez également configurer le transfert de
l’agent SSH. Pour plus d’informations, consultez la documentation associée à votre client
SSH. Remplacez <replace-with-your-password> dans la commande suivante par un mot
de passe de votre choix.
Azure CLI
adminPassword="<replace-with-your-password>"
az vm create \
--name myVmPublic \
--image UbuntuLTS \
--subnet Public \
--admin-password $adminPassword \
--no-wait
Créez une machine virtuelle dans le sous-réseau Private.
Azure CLI
az vm create \
--name myVmPrivate \
--image UbuntuLTS \
--subnet Private \
--admin-password $adminPassword
La création de la machine virtuelle ne nécessite que quelques minutes. Une fois la

machine virtuelle créée, l’interface CLI Azure affiche des informations similaires à celles
de l’exemple suivant :
Sortie
{
"fqdns": "",
000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virt
ualMachines/myVmPrivate",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"publicIpAddress": "13.90.242.231",
"resourceGroup": "myResourceGroup"
}
Veuillez noter publicIpAddress. Cette adresse sera utilisée pour accéder à la machine
virtuelle à partir d’Internet dans une prochaine étape.
Router le trafic via une NVA

En tirant parti d’un client SSH de votre choix, connectez-vous aux machines virtuelles
créées ci-dessus. Par exemple, la commande suivante peut être utilisée à partir d’une
interface de ligne de commande telle que WSL pour créer une session SSH avec la
machine virtuelle myVmPrivate. Remplacez <publicIpAddress> par l’adresse IP publique
de votre machine virtuelle. Dans l’exemple ci-dessus, l’adresse IP est 13.90.242.231.
Bash
ssh azureuser@<publicIpAddress>
Quand vous êtes invité à indiquer un mot de passe, entrez celui que vous avez
sélectionné dans Créer des machines virtuelles.
Utilisez la commande suivante pour installer la détermination d’itinéraire sur la machine

virtuelle myVmPrivate :
Bash
sudo apt update

sudo apt install traceroute
Utilisez la commande suivante pour tester le routage du trafic réseau vers la machine
virtuelle myVmPublic à partir de la machine virtuelle myVmPrivate.
Bash
traceroute myVmPublic
Sortie
traceroute to myVmPublic (10.0.0.4), 30 hops max, 60 byte packets

1 10.0.0.4 (10.0.0.4) 1.404 ms 1.403 ms 1.398 ms
Vous pouvez voir que le trafic est routé directement de la machine virtuelle
myVmPrivate vers la machine virtuelle myVmPublic. Les itinéraires par défaut d’Azure
acheminent directement le trafic entre les sous-réseaux.
Utilisez la commande suivante pour établir une connexion SSH avec la machine virtuelle
myVmPublic à partir de la machine virtuelle myVmPrivate :
Bash
ssh azureuser@myVmPublic
Utilisez la commande suivante pour installer la détermination d’itinéraire sur la machine
virtuelle myVmPublic :
Bash
sudo apt-get install traceroute
Utilisez la commande suivante pour tester le routage du trafic réseau vers la machine
virtuelle myVmPrivate à partir de la machine virtuelle myVmPublic.
Bash
traceroute myVmPrivate
Sortie
traceroute to myVmPrivate (10.0.1.4), 30 hops max, 60 byte packets

1 10.0.2.4 (10.0.2.4) 0.781 ms 0.780 ms 0.775 ms
2 10.0.1.4 (10.0.0.4) 1.404 ms 1.403 ms 1.398 ms
Vous voyez que le premier tronçon est 10.0.2.4, ce qui correspond à l’adresse IP privée
de l’appliance virtuelle réseau (NVA). Le second tronçon est 10.0.1.4, ce qui correspond à
l’adresse IP privée de la machine virtuelle myVmPrivate. L’itinéraire ajouté à la table de
routage myRouteTablePublic et associé au sous-réseau Public a contraint Azure à
acheminer le trafic via l’appliance virtuelle réseau et non directement au sous-réseau
Private.
Fermez les sessions SSH sur les machines virtuelles myVmPublic et myVmPrivate.

Quand vous n’avez plus besoin d’un groupe de ressources, utilisez az group delete pour
le supprimer, ainsi que toutes les ressources qu’il contient.
Azure CLI
az group delete --name myResourceGroup --yes
Étapes suivantes
Dans cet article, vous avez créé une table de routage que vous avez associée à un sous-
réseau. Vous avez créé une appliance virtuelle réseau (NVA) simple qui a routé le trafic
d’un sous-réseau public vers un sous-réseau privé. Déployez différentes NVA
préconfigurées exécutant des fonctions de réseau, telles que la fonction de pare-feu ou
l’optimisation WAN, à partir de la Place de marché Azure . Pour en savoir plus sur le
routage, consultez Routage du trafic de réseau virtuel et Créer, modifier ou supprimer
une table de routage.
Alors que vous pouvez déployer de nombreuses ressources Azure dans un réseau
virtuel, les ressources pour certains services Azure PaaS ne peuvent pas être déployées
dans un réseau virtuel. Cependant, vous pouvez toujours restreindre l’accès aux
ressources de certains services Azure PaaS au trafic provenant uniquement d’un sous-
réseau de réseau virtuel. Pour connaître la marche à suivre, consultez Restreindre l’accès
réseau aux ressources PaaS.
Tutoriel : Configurer des tables de
routage Azure avec Ansible
Article • 08/06/2023
） Important
Ansible 2.8 (ou version ultérieure) est nécessaire pour exécuter les exemples de
playbooks dans cet article.
Azure achemine automatiquement le trafic entre les sous-réseaux, les réseaux virtuels et
les réseaux locaux Azure. Si vous avez besoin d’une maîtrise plus stricte du routage de
votre environnement, vous pouvez créer une table de routage.
Dans cet article, vous apprendrez comment :
Créer une table de routage Créer un réseau virtuel et un sous-réseau Associer une table
de routage à un sous-réseau Dissocier une table de routage d’un sous-réseau Créer et
supprimer des itinéraires Interroger une table de routage Supprimer une table de
routage
Prérequis
Abonnement Azure : Si vous n’avez pas d’abonnement Azure, créez un compte
gratuit avant de commencer.
Installer Ansible. Pour cela, choisissez l’une des options suivantes :

Installez et configurez Ansible sur une machine virtuelle Linux
Configurez Azure Cloud Shell et, si vous n’avez pas accès à une machine
virtuelle Linux, créez une machine virtuelle avec Ansible.

Le code du playbook de cette section crée une table de routage. Pour plus
d’informations sur les limites des tables de routage, voir Limites Azure.
Enregistrez le playbook suivant en tant que route_table_create.yml :
yml
- hosts: localhost
vars:
route_table_name: myRouteTable
resource_group: myResourceGroup
tasks:
- name: Create a route table
azure_rm_routetable:
name: "{{ route_table_name }}"
resource_group: "{{ resource_group }}"
Exécutez le playbook en utilisant ansible-playbook
Bash
ansible-playbook route_table_create.yml

Le code du playbook de cette section :
Crée un réseau virtuel

Crée un sous-réseau au sein du réseau virtuel
Associe une table de routage au sous-réseau
Les tables de routage ne sont pas associées à des réseaux virtuels, mais au sous-réseau
d’un réseau virtuel.
Le réseau virtuel et la table de routage doivent se trouver dans le même abonnement et

au même emplacement Azure.
Les sous-réseaux et les tables de routage entretiennent une relation un-à-plusieurs. Il

est possible de définir un sous-réseau en y associant zéro ou une seule table de routage.
Les tables de routage peuvent être associés à zéro, un ou plusieurs sous-réseaux.
Le trafic provenant du sous-réseau est acheminé selon :
les itinéraires définis dans les tables de routage ;

les itinéraires par défaut ;
les itinéraires propagés à partir d’un réseau local.
Le réseau virtuel doit être connecté à une passerelle de réseau virtuel Azure, qui peut
être ExpressRoute ou un VPN si vous utilisez BGP avec une passerelle VPN.
Enregistrez le playbook suivant en tant que route_table_associate.yml :

yml
- hosts: localhost
vars:
subnet_name: mySubnet
virtual_network_name: myVirtualNetwork
tasks:
- name: Create virtual network
azure_rm_virtualnetwork:
name: "{{ virtual_network_name }}"
address_prefixes_cidr:
- 10.1.0.0/16
- 172.100.0.0/16
dns_servers:
- 127.0.0.1
- 127.0.0.3
- name: Create a subnet with route table
azure_rm_subnet:
name: "{{ subnet_name }}"
virtual_network_name: "{{ virtual_network_name }}"
address_prefix_cidr: "10.1.0.0/24"
route_table: "{{ route_table_name }}"
Bash
ansible-playbook route_table_associate.yml
Dissocier une table de routage d’un sous-

réseau
Le code du playbook de cette section dissocie une table de routage d’un sous-réseau.
Pour dissocier une table de routage d’un sous-réseau, définissez route_table sur None .
Enregistrez le playbook suivant en tant que route_table_dissociate.yml :
yml
- hosts: localhost
vars:
subnet_name: mySubnet
virtual_network_name: myVirtualNetwork
tasks:
- name: Dissociate a route table
azure_rm_subnet:
name: "{{ subnet_name }}"
virtual_network_name: "{{ virtual_network_name }}"
address_prefix_cidr: "10.1.0.0/24"
Bash
ansible-playbook route_table_dissociate.yml
Le code du playbook de cette section crée un itinéraire dans une table de routage.
Enregistrez le playbook suivant en tant que route_create.yml :
yml
- hosts: localhost
vars:
route_name: myRoute
tasks:
- name: Create route
azure_rm_route:
name: "{{ route_name }}"
next_hop_type: virtual_network_gateway
address_prefix: "10.1.0.0/16"
route_table_name: "{{ route_table_name }}"
Avant d’exécuter le playbook, consultez les notes suivantes :
virtual_network_gateway est défini comme next_hop_type . Pour plus

d’informations sur la façon dont Azure sélectionne les itinéraires, voir Vue
d’ensemble du routage.
address_prefix est défini comme 10.1.0.0/16 . Le préfixe ne peut pas être
dupliqué dans la table de routage.

Bash
ansible-playbook route_create.yml
Supprimer un itinéraire
Le code du playbook de cette section supprime un itinéraire d’une table de routage.
Enregistrez le playbook suivant en tant que route_delete.yml :
yml
- hosts: localhost
vars:
route_name: myRoute
tasks:
- name: Remove route
azure_rm_route:
name: "{{ route_name }}"
route_table_name: "{{ route_table_name }}"
state: absent
Bash
ansible-playbook route_delete.yml
Récupérer les informations de la table de

routage
Le code du playbook de cette section utilise le module Ansible
azure_rm_routetable_facts pour récupérer les informations de la table de routage.
Enregistrez le playbook suivant en tant que route_table_facts.yml :
yml
- hosts: localhost
vars:
tasks:
- name: Get route table information
azure_rm_routetable_facts:
register: query
- debug:
var: query.route_tables[0]
Bash
ansible-playbook route_table_facts.yml
Supprimer une table de routage

Le code du playbook de cette section supprime une table de routage.
Lorsqu’une table de routage est supprimée, tous ses itinéraires le sont également.
Il n’est pas possible de supprimer une table de routage associée à un sous-réseau.

Dissociez la table de routage de tous les sous-réseaux avant de tenter de la supprimer.
Enregistrez le playbook suivant en tant que route_table_delete.yml :
yml
- hosts: localhost
vars:
tasks:
- name: Create a route table
azure_rm_routetable:
state: absent
Bash
ansible-playbook route_table_delete.yml
Étapes suivantes
Ansible sur Azure
Créer, modifier ou supprimer une table
de routage
Article • 01/05/2023
Azure achemine automatiquement le trafic entre les sous-réseaux, les réseaux virtuels et
les réseaux locaux Azure. Si vous souhaitez modifier le routage par défaut de Azure,
vous pouvez le faire en créant une table de routage. Si vous ne maîtrisez pas encore le
routage des réseaux virtuels, vous trouverez plus d’informations à ce sujet dans Routage
du trafic de réseau virtuel ou en suivant un tutoriel.
Avant de commencer
Si vous n’en avez pas, configurez un compte Azure avec un abonnement actif. Créez un
compte gratuitement . Accomplissez ensuite l’une des tâches suivantes avant
d’exécuter les étapes décrites dans les sections de cet article :
Utilisateurs du portail : Connectez-vous au portail Azure avec votre compte

Azure.
Utilisateurs de PowerShell : exécutez les commandes dans Azure Cloud Shell ou

exécutez PowerShell à partir de votre ordinateur. Azure Cloud Shell est un
interpréteur de commandes interactif et gratuit que vous pouvez utiliser pour
exécuter les étapes de cet article. Il contient des outils Azure courants préinstallés
et configurés pour être utilisés avec votre compte. Dans l’onglet de navigateur
Azure Cloud Shell, ouvrez la liste déroulante Sélectionner un environnement, puis
choisissez PowerShell si ce n’est pas déjà fait.
Si vous exécutez PowerShell en local, utilisez le module Azure PowerShell

version 1.0.0 ou ultérieure. Exécutez Get-Module -ListAvailable Az.Network pour
rechercher la version installée. Si vous devez effectuer une mise à niveau, consultez
Installer le module Azure PowerShell. Exécutez également Connect-AzAccount pour
créer une connexion avec Azure.
Utilisateurs d’Azure CLI : exécutez les commandes via Azure Cloud Shell ou
Azure CLI en local. Si vous exécutez l’interface Azure CLI localement, utilisez Azure
CLI version 2.0.31 ou ultérieure. Exécutez az --version pour rechercher la version
installée. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
Exécutez également az login pour créer une connexion avec Azure.
Attribuez le rôle Contributeur réseau ou un rôle Personnalisé avec les autorisations
appropriées.

Le nombre de tables de routes que vous pouvez créer par abonnement et par
emplacement Azure est limité. Pour plus d’informations, consultez Limites de mise en
réseau – Azure Resource Manager.
1. Dans le menu du Portail Azure ou dans la page Accueil, sélectionnez Créer une
ressource.
2. Dans la zone de recherche, entrez table de route. Quand le terme table de route
s’affiche dans les résultats de recherche, sélectionnez-le.
3. Dans la page table de route, sélectionnez Créer.
4. Dans la boîte de dialogue Créer une table de routage :
Paramètre Valeur
Nom Entrez un nom pour la table de route.
Abonnement Sélectionnez l’abonnement dans lequel la table de route sera déployée.

Paramètre Valeur
Groupe de Choisissez un groupe de ressources existant ou sélectionnez Créer

ressources nouveau pour en créer un nouveau.
Emplacement Sélectionnez une région dans laquelle la table de route sera déployée.
Propager des Si vous envisagez d’associer la table de routes à un sous-réseau d’un réseau
itinéraires de virtuel connecté à votre réseau local via une passerelle VPN et que vous ne
passerelle voulez pas propager vos routes locales aux interfaces réseau dans le sous-
réseau, définissez Propagation de la route de la passerelle de réseau
virtuel sur Désactivé.
5. Sélectionnez Vérifier + créer, puis Créer pour créer votre table de route.
Créer une table de routage (commandes)
Outil Commande
Azure CLI az network route-table create
PowerShell New-AzRouteTable
Afficher les tables de routage

Accédez au portail Azure pour gérer votre réseau virtuel. Recherchez et sélectionnez
Tables de routage. Les tables de routage présentes dans votre abonnement sont
répertoriées.
Afficher une table de routage (commandes)
Outil Commande
Outil Commande
Azure CLI az network route-table list
PowerShell Get-AzRouteTable
Afficher les détails d’une table de routage

1. Accédez au portail Azure pour gérer votre réseau virtuel. Recherchez et
sélectionnez Tables de routage.
2. Dans la liste des tables de routes, choisissez la table de routes dont vous souhaitez
afficher les détails.
3. Dans la page de la table de routes, sous Paramètres, visualisez les routes dans la
table de routes ou les sous-réseaux auxquels la table de routes est associée.
Pour en savoir plus sur les paramètres Azure communs, consultez les informations
suivantes :
Journal d’activité
Contrôle d’accès (IAM)
Balises
Verrous
Script Automation
Afficher les détails d’une table de routage (commandes)

Outil Commande
Azure CLI az network route-table show
PowerShell Get-AzRouteTable
Modifier une table de routage

2. Dans la liste des tables de routes, choisissez la table de routes que vous souhaitez
modifier.
Les modifications les plus courantes consistent à ajouter des routes, supprimer des
routes, associer des tables de routes à des sous-réseaux ou dissocier des tables de
routes des sous-réseaux.
Modifier une table de routage (commandes)
Outil Commande
Azure CLI az network route-table update
PowerShell Set-AzRouteTable

Vous pouvez éventuellement associer une table de routes à un sous-réseau. Une table
de routes peut être associée à aucun, à un ou à plusieurs sous-réseaux. Les tables de
routage ne sont pas associées à des réseaux virtuels, Vous devez associer une table de
routage à chaque sous-réseau auquel vous voulez associer une table de routage.
Azure achemine tout le trafic sortant du sous-réseau en fonction des itinéraires que
vous avez créés :
Dans les tables de routage
Itinéraires par défaut
Itinéraires propagés à partir d’un réseau local, si le réseau virtuel est connecté à
une passerelle de réseau virtuel Azure (ExpressRoute ou VPN).
Vous pouvez uniquement associer une table de routage à des sous-réseaux de réseaux
virtuels qui se trouvent au même emplacement et dans le même abonnement Azure que
la table de routage.

sélectionnez Réseaux virtuels.
2. Dans la liste des réseaux virtuels, choisissez le réseau virtuel qui contient le sous-
réseau auquel vous souhaitez associer une table de routes.
3. Dans la barre de menus du réseau virtuel, choisissez Sous-réseaux.
4. Sélectionnez le sous-réseau auquel associer la table de routage.
5. Dans Table de routage, choisissez la table de routes que vous voulez associer au
sous-réseau.
Si votre réseau virtuel est connecté à une passerelle VPN Azure, n’associez pas de table
de routes au sous-réseau de passerelle qui inclut une route avec la destination 0.0.0.0/0.
Cela peut empêcher la passerelle de fonctionner correctement. Pour plus d’informations
sur l’utilisation de 0.0.0.0/0 dans une route, consultez Routage du trafic de réseau
virtuel.
Associer une table de routage (commandes)

Outil Commande
Azure CLI az network vnet subnet update
PowerShell Set-AzVirtualNetworkSubnetConfig
Dissocier une table de routage d’un sous-

réseau
Quand vous dissociez une table de routage d’un sous-réseau, Azure achemine le trafic
en fonction de ses itinéraires par défaut.

sélectionnez Réseaux virtuels.
2. Dans la liste des réseaux virtuels, choisissez le réseau virtuel qui contient le sous-
réseau duquel vous souhaitez dissocier une table de routes.
3. Dans la barre de menus du réseau virtuel, choisissez Sous-réseaux.
4. Sélectionnez le sous-réseau duquel dissocier la table de routage.
5. Dans Table de routage, choisissez Aucun.

Dissocier une table de routage (commandes)
Outil Commande
Azure CLI az network vnet subnet update
PowerShell Set-AzVirtualNetworkSubnetConfig
Supprimer une table de routage
Vous ne pouvez pas supprimer une table de routes qui est associée à des sous-réseaux.
Dissociez la table de routage de tous les sous-réseaux avant de tenter de la supprimer.
1. Accédez au portail Azure pour gérer vos tables de routes. Recherchez et

2. Dans la liste des tables de routes, choisissez la table de routes que vous souhaitez
supprimer.
3. Sélectionnez Supprimer, puis Oui dans la boîte de dialogue de confirmation.
Supprimer une table de routage (commandes)
Outil Commande
Azure CLI az network route-table delete
PowerShell Remove-AzRouteTable
Le nombre de routes par table de routes que vous pouvez créer par abonnement et par
emplacement Azure est limité. Pour plus d’informations, consultez Limites de mise en
réseau – Azure Resource Manager.
2. Dans la liste des tables de routes, choisissez la table de routes à laquelle vous
souhaitez ajouter une route.
3. Dans la barre de menus de la table de route, choisissez Itinéraires, puis

sélectionnez + Ajouter.
4. Entrez un nom unique pour la route dans la table de routes.
5. Entrez le préfixe d’adresse dans la notation CIDR (routage interdomaine sans

classe) vers lequel vous souhaitez router le trafic. Ce préfixe ne peut pas être
dupliqué dans plusieurs routes de la table de routes, bien qu’il puisse se trouver
dans un autre préfixe. Par exemple, si vous avez défini 10.0.0.0/16 comme préfixe
pour une route, vous pouvez toujours définir une autre route avec le préfixe
d’adresse 10.0.0.0/22. Azure sélectionne un itinéraire pour le trafic en fonction de
la correspondance de préfixe la plus longue. Pour en apprendre plus, consultez
Comment Azure choisit un itinéraire.
6. Choisissez un type de tronçon suivant. Pour en savoir plus sur les types de tronçon
suivants, consultez Routage du trafic de réseau virtuel.
7. Si vous avez choisi pour Type de tronçon suivant une Appliance virtuelle, entrez
une adresse IP pour Adresse du tronçon suivant.
Créer un itinéraire (commandes)
Outil Commande
Azure CLI az network route-table route create
PowerShell New-AzRouteConfig
Afficher des itinéraires

Une table de routage peut contenir plusieurs itinéraires ou aucun. Pour en savoir plus
sur les informations listées lors de l’affichage des routes, consultez Routage du trafic de
réseau virtuel.

2. Dans la liste des tables de routes, choisissez la table de routes dont vous souhaitez
afficher les routes.
3. Dans la barre de menus de la table de routes, choisissez Routes pour afficher la

liste des routes.
Afficher les itinéraires (commandes)
Outil Commande
Azure CLI az network route-table route list

Outil Commande
PowerShell Get-AzRouteConfig
Afficher les détails d’un itinéraire

2. Dans la liste des tables de routes, choisissez la table de routes contenant la route
dont vous souhaitez afficher les détails.

liste des routes.
4. Sélectionnez l’itinéraire dont vous souhaitez afficher les détails.
Afficher les détails d’un itinéraire (commandes)
Outil Commande
Azure CLI az network route-table route show
PowerShell Get-AzRouteConfig
Modifier un itinéraire
que vous souhaitez modifier.

liste des routes.
4. Choisissez la route à modifier.
5. Modifiez les paramètres souhaités, puis cliquez sur Enregistrer.
Modifier un itinéraire (commandes)
Outil Commande
Azure CLI az network route-table route update
PowerShell Set-AzRouteConfig
Supprimer un itinéraire
que vous souhaitez supprimer.

liste des routes.
4. Choisissez la route à supprimer.
5. Sélectionnez …, puis Supprimer. Cliquez sur Oui dans la boîte de dialogue de

confirmation.
Supprimer un itinéraire (commandes)
Outil Commande
Azure CLI az network route-table route delete
PowerShell Remove-AzRouteConfig
Afficher les itinéraires effectifs

Les routes effectives de chaque interface réseau attachée à une machine virtuelle sont
une combinaison des tables de routes que vous avez créées, des routes par défaut
d’Azure et de toutes les routes propagées à partir de réseaux locaux via le protocole
BGP (Border Gateway Protocol) et via une passerelle de réseau virtuel Azure. Il est
important de comprendre ce que représentent les itinéraires effectifs pour une interface
réseau pour pouvoir résoudre les éventuels problèmes de routage. Vous pouvez afficher
les routes effectives pour toute interface réseau attachée à une machine virtuelle en
cours d’exécution.
1. Accédez au portail Azure pour gérer vos machines virtuelles. Recherchez et

sélectionnez Machines virtuelles.
2. Dans la liste des machines virtuelles, choisissez la machine virtuelle pour laquelle
vous souhaitez afficher les routes effectives.
3. Dans la barre de menus de la machine virtuelle, choisissez Mise en réseau.
4. Sélectionnez le nom d’une interface réseau.

5. Dans la barre de menus de l’interface réseau, sélectionnez Routages effectifs.
6. Passez en revue la liste des routes effectives pour déterminer si la route correcte
existe pour l’emplacement vers lequel vous souhaitez router le trafic. Pour en
savoir plus sur les types de tronçon suivants qui apparaissent dans cette liste,
consultez Routage du trafic de réseau virtuel.
Afficher les itinéraires effectifs (commandes)
Outil Commande
Azure CLI az network nic show-effective-route-table
PowerShell Get-AzEffectiveRouteTable
Valider le routage entre deux points de

terminaison
Vous pouvez déterminer le type de tronçon suivant entre une machine virtuelle et
l’adresse IP d’une autre ressource Azure, une ressource locale ou une ressource sur
Internet. La détermination du routage d’Azure est utile pour pouvoir résoudre les
éventuels problèmes de routage. Pour exécuter cette tâche, vous devez disposer d’un
observateur réseau existant. Si vous n’avez pas d’observateur réseau existant, créez-en
un en procédant comme indiqué dans Créer une instance de Network Watcher.
1. Accédez au portail Azure pour gérer vos observateurs réseau. Recherchez et

sélectionnez Network Watcher.
2. Dans la barre de menus de Network Watcher, choisissez Tronçon suivant.
3. Dans la page Network Watcher | Tronçon suivant :
Paramètre Valeur
Abonnement Sélectionnez l’abonnement dans lequel se trouve la machine virtuelle

source.
Groupe de Sélectionnez le groupe de ressources contenant la machine virtuelle.

ressources
Machine Sélectionnez la machine virtuelle sur laquelle vous souhaitez effectuer le

virtuelle test.
interface Sélectionnez l’interface réseau sur laquelle vous souhaitez tester le tronçon
réseau suivant.
Paramètre Valeur
Adresse IP L’adresse IP source par défaut est sélectionnée automatiquement. Vous

source pouvez modifier l’adresse IP source si l’interface réseau en comporte
plusieurs.
Adresse IP Entrez l’adresse IP de destination afin d’afficher le tronçon suivant pour la

de machine virtuelle.
destination
4. Sélectionnez Tronçon suivant.
Après un court délai d’attente, Azure vous indique le type de tronçon suivant et l’ID de
la route qui a routé le trafic. Pour en savoir plus sur les types de tronçon suivants
retournés, consultez Routage du trafic de réseau virtuel.
Valider le routage entre deux points de terminaison

(commandes)
Outil Commande
Azure CLI az network watcher show-next-hop
PowerShell Get-AzNetworkWatcherNextHop
Autorisations
Pour que vous puissiez exécuter des tâches sur des tables de routes et des routes, votre
compte doit être doté du rôle Contributeur de réseaux ou d’un rôle personnalisé affecté
des actions appropriées listées dans le tableau suivant :
Action Nom
Microsoft.Network/routeTables/read Lire une table de routage
Microsoft.Network/routeTables/write Créer ou mettre à jour une

table de routage
Microsoft.Network/routeTables/delete Supprimer une table de

routage
Microsoft.Network/routeTables/join/action Associer une table de routage

à un sous-réseau
Microsoft.Network/routeTables/routes/read Lire un itinéraire

Action Nom
Microsoft.Network/routeTables/routes/write Créer ou mettre à jour un

itinéraire
Microsoft.Network/routeTables/routes/delete Supprimer un itinéraire
Microsoft.Network/networkInterfaces/effectiveRouteTable/action Obtenir la table de routage

effective d’une interface
réseau
Microsoft.Network/networkWatchers/nextHop/action Obtenir le tronçon suivant à

partir d’une machine virtuelle
Étapes suivantes
Créer une table de routes avec les exemples de scripts PowerShell ou Azure CLI, ou
les modèles Azure Resource Manager
Créer et attribuer des définitions Azure Policy pour les réseaux virtuels
Créer, modifier ou supprimer une
interface réseau
Une interface réseau permet à une machine virtuelle Azure de communiquer avec des
ressources sur Internet, sur Azure et locales. Cet article explique comment créer une
carte réseau, l’afficher, modifier ses paramètres et la supprimer.
Une machine virtuelle que vous créez dans le portail Azure possède une carte réseau
avec les paramètres par défaut. Vous pouvez créer des cartes réseau avec des
paramètres personnalisés à la place et ajouter une ou plusieurs cartes réseau à une
machine virtuelle quand vous la créez ou ultérieurement. Vous pouvez également
modifier les paramètres d’une carte réseau existante.
Prérequis
Portail
Vous devez respecter les prérequis suivants :
Compte Azure avec un abonnement actif. Créez un compte gratuitement .

Réseau virtuel Azure existant. Pour en créer un, consultez Démarrage rapide :
créer un réseau virtuel à l’aide du portail Azure.
Pour réaliser les procédures décrites dans cet article, connectez-vous au Portail
Azure avec votre compte Azure. Vous pouvez remplacer les espaces réservés dans
les exemples par vos propres valeurs.
Autorisations
Pour utiliser des cartes réseau, votre compte doit avoir le rôle de contributeur de réseau
ou un rôle personnalisé assigné aux actions appropriées de la liste suivante :
Action Nom
Microsoft.Network/networkInterfaces/read Obtenir l’interface

réseau
Action Nom
Microsoft.Network/networkInterfaces/write Création ou mise

à jour d’une
interface réseau
Microsoft.Network/networkInterfaces/join/action Joindre une

interface réseau à
une machine
virtuelle
Microsoft.Network/networkInterfaces/delete Supprimer une

interface réseau
Microsoft.Network/networkInterfaces/joinViaPrivateIp/action Joindre une

ressource à une
interface réseau
via une adresse IP
privée
Microsoft.Network/networkInterfaces/effectiveRouteTable/action Obtenir une table

de routage
effective
d’interface réseau
Microsoft.Network/networkInterfaces/effectiveNetworkSecurityGroups/action Obtenir des

groupes de
sécurité avec une
règle effective sur
les interfaces
réseau
Microsoft.Network/networkInterfaces/loadBalancers/read Obtenir des

équilibreurs de
charge d’interface
réseau
Microsoft.Network/networkInterfaces/serviceAssociations/read Obtenir une

association de
service
Microsoft.Network/networkInterfaces/serviceAssociations/write Créer ou mettre à

jour d’une
association de
service
Microsoft.Network/networkInterfaces/serviceAssociations/delete Supprimer une

association de
service
Action Nom
Microsoft.Network/networkInterfaces/serviceAssociations/validate/action Valider
l’association de
service
Microsoft.Network/networkInterfaces/ipconfigurations/read Obtenir la
configuration IP
de l’interface
réseau
Créer une interface réseau

Vous pouvez créer une carte réseau dans le portail Azure ou à l’aide d’Azure CLI ou
d’Azure PowerShell.
Le portail ne permet pas d’attribuer une adresse IP publique à une carte réseau
quand vous la créez. Si vous souhaitez créer une carte réseau avec une adresse IP
publique, utilisez l’interface de ligne de commande ou PowerShell pour la créer.
Pour ajouter une adresse IP publique à une carte réseau après l’avoir créée,
consultez Configurer des adresses IP pour une interface réseau Azure.
Le portail crée une carte réseau avec des paramètres par défaut et une adresse IP
publique lorsque vous créez une machine virtuelle. Pour créer une carte réseau
avec des paramètres personnalisés et l’attacher à une machine virtuelle, ou pour
ajouter une carte réseau à une machine virtuelle existante, utilisez PowerShell ou
Azure CLI.
Le portail ne permet pas d’attribuer une carte réseau aux groupes de sécurité
d’application lorsque vous créez la carte réseau, contrairement à l’interface de
ligne de commande Azure et à PowerShell. Toutefois, si une carte réseau existante
est attachée à une machine virtuelle, vous pouvez utiliser le portail pour attribuer
cette carte réseau à un groupe de sécurité d’application. Pour plus d’informations,
consultez Ajouter ou supprimer des groupes de sécurité d’application.
Pour créer une carte réseau, utilisez la procédure suivante.
Portail
1. Dans le Portail Azure , recherchez et sélectionnez Interfaces réseau.
2. Dans la page Interfaces réseau, sélectionnez Créer.

3. Dans l’écran Créer une interface réseau, entrez ou sélectionnez des valeurs
pour les paramètres de la carte réseau.
4. Sélectionnez Vérifier + créer, puis quand la validation réussit, sélectionnez

Créer.
Vous pouvez configurer les paramètres suivants pour une carte réseau :
Paramètre Valeur Détails
Abonnement Sélectionnez Vous pouvez attribuer une carte réseau uniquement à un réseau
votre virtuel dans le même abonnement et le même emplacement.
abonnement.
Groupe de Sélectionnez Un groupe de ressources est un conteneur logique pour

ressources votre groupe regrouper des ressources Azure. Une carte réseau peut se trouver
de ou non dans le même groupe de ressources que celui de la
ressources machine virtuelle à laquelle vous l’attachez ou du réseau virtuel
ou créez-en auquel vous la connectez.
un.
Nom Entrez un Le nom doit être unique au sein du groupe de ressources. Pour
nom pour la plus d’informations sur la création d’une convention d’affectation
carte réseau. de noms pour faciliter la gestion de plusieurs cartes réseau,
consultez Nommage des ressources. Vous ne pouvez pas modifier
le nom après avoir créé la carte réseau.
Région Sélectionnez Région Azure dans laquelle vous créez la carte réseau.
votre région.
Réseau Sélectionnez Vous pouvez attribuer une carte réseau uniquement à un réseau
virtuel votre réseau virtuel dans le même abonnement et le même emplacement que
virtuel. celle-ci. Une fois que vous avez créé une carte réseau, vous ne
pouvez plus modifier le réseau virtuel auquel elle est attribuée. La
machine virtuelle à laquelle vous ajoutez la carte réseau doit
également se trouver dans les mêmes emplacement et
abonnement que la carte réseau.
Sous-réseau Sélectionnez Vous pouvez modifier le sous-réseau auquel la carte réseau est
un sous- attribuée après avoir créé la carte réseau.
réseau dans
le réseau
virtuel que
vous avez
sélectionné.
Version IP Sélectionnez Vous pouvez choisir de créer la carte réseau avec une adresse
IPv4 ou IPv4 ou des adresses IPv4 et IPv6. Pour attribuer une adresse IPv6,
IPv4 et IPv6. le réseau et le sous-réseau que vous utilisez pour la carte réseau
doivent également disposer d’un espace d’adressage IPv6. Une
configuration IPv6 est attribuée à une configuration IP secondaire
pour la carte réseau.
Affectation Sélectionnez Le serveur DHCP Azure attribue l’adresse IP privée à la carte

d’adresses IP Dynamique réseau dans le système d’exploitation de la machine virtuelle.
privées ou Statique.
- Si vous sélectionnez Dynamique, Azure attribue
automatiquement une adresse disponible de l’espace d’adressage
du sous-réseau sélectionné.
- Si vous sélectionnez Statique, vous devez attribuer

manuellement une adresse IP disponible de l’espace d’adressage
du sous-réseau sélectionné.
Les adresses statiques et dynamiques ne changent que si vous les

modifiez ou si vous supprimez la carte réseau. Vous pouvez
modifier la méthode d’affectation après la création de la carte
d’interface réseau.
７ Notes
Azure attribue une adresse MAC à la carte réseau uniquement lorsque la carte
réseau est attachée à une machine virtuelle et lorsque la machine virtuelle démarre
pour la première fois. Vous ne pouvez pas spécifier l’adresse MAC qu’Azure attribue
à la carte réseau.
L’adresse MAC reste attribuée à la carte réseau jusqu’à ce que la carte réseau soit
supprimée ou que l’adresse IP privée attribuée à la configuration IP principale de la
carte réseau principale soit modifiée. Pour en savoir plus, consultez Configurer des
adresses IP pour une interface réseau Azure.
７ Notes
Afficher les paramètres d’interface réseau

Vous pouvez afficher la plupart des paramètres d’une carte réseau après l’avoir créée. Le
portail n’affiche pas le suffixe DNS ou l’appartenance aux groupes de sécurité
d’application pour la carte réseau. Pour voir le suffixe DNS et l’appartenance aux
groupes de sécurité d’application, utilisez Azure PowerShell ou Azure CLI.
Portail
2. Dans la page Interfaces réseau, sélectionnez la carte réseau que vous

souhaitez afficher.
3. Dans la page Vue d’ensemble de la carte réseau, affichez les informations

essentielles telles que les adresses IP IPv4 et IPv6 et l’appartenance au groupe
de sécurité réseau (NSG).
Vous pouvez sélectionner Modifier la mise en réseau accélérée pour définir la

mise en réseau accélérée des cartes réseau. Pour plus d’informations sur
l’accélération réseau, consultez Qu’est-ce que l’accélération réseau ?.
4. Sélectionnez Configurations IP dans le volet de navigation gauche, puis, dans

la page Configurations IP, affichez les configurations de transfert d’adresses
IP, de sous-réseau et d’adresses IP publiques et privées IPv4 et IPv6. Pour en
savoir plus sur les configurations IP et pour apprendre à ajouter et supprimer
des adresses IP, consultez l’article Configurer des adresses IP pour une
interface réseau Azure.
5. Sélectionnez Serveurs DNS dans le volet de navigation gauche, puis, sur la
page Serveurs DNS, affichez tous les serveurs DNS auxquels Azure DHCP
attribue la carte réseau. Notez également si la carte réseau hérite du
paramètre du réseau virtuel ou a un paramètre personnalisé qui remplace le
paramètre de réseau virtuel.
6. Sélectionnez Groupe de sécurité réseau dans le volet de navigation gauche.

Sur la page Groupe de sécurité réseau, consultez tout groupe de sécurité
réseau associé à la carte réseau. Un groupe de sécurité réseau contient des
règles entrantes et sortantes pour filtrer le trafic réseau transitant par la carte
réseau.
7. Sélectionnez Propriétés dans le volet de navigation gauche. Sur la page
Propriétés, affichez les paramètres de la carte réseau, tels que l’adresse MAC
et les informations d’abonnement. L’adresse MAC est vierge si la carte réseau
n’est pas attachée à une machine virtuelle.
8. Sélectionnez Règles de sécurité effectives dans le volet de navigation de
gauche. La page Règles de sécurité effectives répertorie les règles de sécurité
si la carte réseau est attachée à une machine virtuelle en cours d’exécution et
associée à un groupe de sécurité réseau. Pour plus d’informations sur les
groupes de sécurité réseau, consultez Groupes de sécurité réseau.
9. Sélectionnez Itinéraires effectifs dans le volet de navigation gauche. La page
Itinéraires effectifs répertorie les itinéraires si la carte réseau est attachée à
une machine virtuelle en cours d’exécution.
Les itinéraires sont une combinaison d’itinéraires par défaut d’Azure,

d’itinéraires définis par l’utilisateur et de tous les itinéraires BGP (Border
Gateway Protocol) existants pour le sous-réseau auquel la carte réseau est
attribuée. Pour plus d’informations sur les itinéraires pat défaut d’Azure et sur
ceux définis par l’utilisateur, consultez Routage du trafic de réseau virtuel.
Modifier les paramètres de l’interface réseau
Vous pouvez modifier la plupart des paramètres d’une carte réseau après l’avoir créée.
Ajouter ou modifier des serveurs DNS

Azure DHCP attribue le serveur DNS à la carte réseau au sein du système d’exploitation
de la machine virtuelle. La carte réseau peut hériter les paramètres du réseau virtuel ou
utiliser ses propres paramètres uniques qui remplacent le paramètre pour le réseau
virtuel. Pour en savoir plus sur les paramètres de résolution de noms d’une carte réseau,
consultez Résolution de noms pour les machines virtuelles.
Portail
2. Sur la page Interfaces réseau, sélectionnez la carte réseau que vous souhaitez
modifier dans la liste.
3. Sur la page de la carte réseau, sélectionnez Serveurs DNS dans le volet de

navigation de gauche.
4. Sur la page Serveurs DNS, sélectionnez l’un des paramètres suivants :
Hériter de VNet : choisissez cette option pour hériter le paramètre de

serveur DNS défini pour le réseau virtuel auquel la carte réseau est
attribuée. Un serveur DNS personnalisé ou le serveur DNS fourni par
Azure est défini au niveau du réseau virtuel.
Le serveur DNS fourni par Azure peut résoudre les noms d’hôtes pour les
ressources assignées au même réseau virtuel. Le nom de domaine
complet (FQDN) doit être utilisé pour les ressources attribuées à
différents réseaux virtuels.
７ Notes
Si une machine virtuelle utilise une carte réseau faisant partie d’un
groupe à haute disponibilité, les serveurs DNS de toutes les
machines virtuelles qui font partie du groupe à haute disponibilité
sont hérités.
Personnalisé : vous pouvez configurer votre propre serveur DNS pour

résoudre les noms sur plusieurs réseaux virtuels. Entrez l’adresse IP du
serveur que vous souhaitez utiliser comme serveur DNS. L’adresse de
serveur DNS que vous spécifiez est attribuée uniquement à cette carte
réseau et remplace tous les paramètres DNS du réseau virtuel auquel la
carte réseau est connectée.
Activer et désactiver le transfert IP

Le transfert IP permet à une carte réseau attachée à une machine virtuelle de :
Recevoir le trafic réseau qui n’est pas destiné à l’une des adresses IP attribuées à
l’une des configurations IP de la carte réseau.
Envoyer le trafic réseau avec une adresse IP source différente de celle attribuée à
n’importe laquelle des configurations IP d’une carte réseau.
Vous devez activer le transfert IP pour chaque carte réseau attachée à la machine
virtuelle qui doit transférer le trafic. Une machine virtuelle peut transférer le trafic,
qu’une ou plusieurs cartes réseau lui soient attachées.
Le transfert IP est généralement utilisé avec les routages définis par l’utilisateur. Pour
plus d’informations, consultez Itinéraires définis par l’utilisateur.
Bien que le transfert IP soit un paramètre Azure, la machine virtuelle doit également
exécuter une application capable de transférer le trafic, comme une application de pare-
feu, d’optimisation WAN ou d’équilibrage de charge. Une machine virtuelle qui exécute
des applications réseau est souvent appelée appliance virtuelle réseau (NVA). Vous
pouvez afficher la liste des NVA prêtes au déploiement sur la Place de marché Microsoft
Azure .
Portail
1. Dans la page de la carte réseau, sélectionnez Configurations IP dans le volet

de navigation de gauche.
2. Dans la page Configurations IP, sous Paramètres de transfert IP, sélectionnez
Activé ou Désactivé, la valeur par défaut, pour modifier le paramètre.
Modifier l’affectation de sous-réseau

Vous pouvez modifier le sous-réseau, mais pas le réseau virtuel auquel une carte réseau
est attribuée.
Portail
1. Dans la page de la carte réseau, sélectionnez Configurations IP dans le volet

de navigation de gauche.
2. Dans la page Configurations IP, sous Configurations IP, si des adresses IP

privées répertoriées sont assorties de la mention (Statique), remplacez la
méthode d’attribution d’adresses IP par dynamique. Toutes les adresses IP
privées doivent être affectées à l’aide de la méthode d’affectation dynamique
pour modifier l’affectation de sous-réseau pour la carte réseau.
Pour définir la méthode d’attribution sur Dynamique :

a. Sélectionnez la configuration IP que vous souhaitez modifier dans la liste
des configurations IP.
b. Dans la page Configuration IP, sélectionnez Dynamique sous Affectation.
c. Sélectionnez Enregistrer.
3. Lorsque toutes les adresses IP privées sont définies sur Dynamique, sous
Sous-réseau, sélectionnez le sous-réseau vers lequel vous souhaitez déplacer
la carte réseau.
4. Sélectionnez Enregistrer. De nouvelles adresses dynamiques sont attribuées à

partir de la plage d’adresses du nouveau sous-réseau.
Après avoir attribué la carte réseau à un nouveau sous-réseau, vous pouvez

attribuer une adresse IPv4 statique à partir de la nouvelle plage d’adresses de sous-
réseau si vous le souhaitez. Pour plus d’informations sur l’ajout, la modification et la
suppression d’adresses IP pour une carte réseau, consultez Configurer des adresses
IP pour une interface réseau Azure.
Ajouter une interface aux groupes de sécurité

d’application ou la supprimer de ces derniers
Vous pouvez ajouter des cartes réseau uniquement à des groupes de sécurité
d’application dans le même réseau virtuel et le même emplacement que la carte réseau.
Vous pouvez utiliser le portail pour ajouter ou supprimer une carte réseau pour un
groupe de sécurité d’application uniquement si la carte réseau est attachée à une
machine virtuelle. Sinon, utilisez PowerShell ou Azure CLI. Pour en savoir plus, consultez
Groupes de sécurité d’application et Guide pratique de création d’un groupe de sécurité
d’application.
Portail
Pour ajouter ou supprimer une carte réseau pour un groupe de sécurité

d’application sur une machine virtuelle, procédez comme suit :
1. Dans le portail Azure , recherchez et sélectionnez machines virtuelles.
2. Dans la page Machines virtuelles, sélectionnez la machine virtuelle que vous

souhaitez configurer dans la liste.
3. Dans la page de la machine virtuelle, sélectionnez Mise en réseau dans le

volet de navigation de gauche.
4. Dans la page Mise en réseau, sous l’onglet Groupes de sécurité d’application,

sélectionnez Configurer les groupes de sécurité d’application.
5. Sélectionnez les groupes de sécurité d’application auxquels vous souhaitez

ajouter la carte réseau ou désélectionnez les groupes de sécurité d’application
desquels vous souhaitez supprimer la carte réseau.
Associer ou dissocier un groupe de sécurité réseau
Portail
1. Dans la page de la carte réseau, sélectionnez Groupe de sécurité réseau dans

le volet de navigation de gauche.
2. Dans la page Groupe de sécurité réseau, sélectionnez le groupe de sécurité
réseau que vous souhaitez associer, ou sélectionnez Aucun pour dissocier le
groupe de sécurité réseau.
Supprimer une interface réseau

Vous pouvez supprimer une carte réseau si elle n’est pas attachée à une machine
virtuelle. Si la carte réseau est attachée à une machine virtuelle, vous devez d’abord
arrêter et libérer la machine virtuelle, puis détacher la carte réseau.
Pour détacher la carte réseau de la machine virtuelle, effectuez les étapes décrites dans
Supprimer une interface réseau d’une machine virtuelle. Une machine virtuelle doit
toujours avoir au moins une carte réseau attachée à celle-ci, de sorte que vous ne
pouvez pas supprimer la seule carte réseau d’une machine virtuelle.
Portail
Pour supprimer une carte réseau, dans la page Vue d’ensemble de la carte réseau
que vous souhaitez supprimer, sélectionnez Supprimer dans la barre de menus
supérieure, puis sélectionnez Oui.
Résoudre les problèmes de connectivité

Si vous rencontrez des problèmes de communication avec une machine virtuelle, ils
peuvent être dus à des règles de groupe de sécurité réseau ou à des itinéraires effectifs.
Utilisez les options suivantes pour essayer de résoudre le problème.
Voir les règles de sécurité effectives

Les règles de sécurité effectives pour chaque carte réseau attachée à une machine
virtuelle sont une combinaison des règles que vous avez créées dans un groupe de
sécurité réseau et des règles de sécurité par défaut. Comprendre les règles de sécurité
effectives liées à une carte réseau peut vous aider à déterminer la raison pour laquelle
vous ne parvenez pas à communiquer vers ou à partir d’une machine virtuelle. Vous
pouvez afficher les règles effectives pour toute carte réseau attachée à une machine
virtuelle en cours d’exécution.
Portail

2. Dans la page Machines virtuelles, sélectionnez la machine virtuelle dont vous
souhaitez afficher les paramètres.
3. Dans la page de la machine virtuelle, sélectionnez Mise en réseau dans le
volet de navigation de gauche.
4. Sur la page Mise en réseau, sélectionnez Interface réseau.
5. Dans la page de la carte réseau, sélectionnez Règles de sécurité effectives
sous Aide dans le volet de navigation gauche.
6. Passez en revue la liste des règles de sécurité effectives pour déterminer si les
règles sont appropriées pour vos communications entrante et sortante
requises. Pour plus d’informations concernant les règles de sécurité, consultez
Vue d’ensemble des groupes de sécurité réseau.
Afficher les itinéraires effectifs

Les itinéraires effectifs de la ou des cartes réseau attachées à une machine virtuelle sont
une combinaison des éléments suivants :
Itinéraires par défaut

Itinéraires définis par l’utilisateur
Routes propagées à partir de réseaux locaux via BGP par le biais d’une passerelle
de réseau virtuel Azure.
Comprendre les itinéraires effectifs d’une carte réseau peut vous aider à déterminer
pourquoi vous ne pouvez pas communiquer avec une machine virtuelle. Vous pouvez
afficher les itinéraires effectifs pour toute interface réseau attachée à une machine
virtuelle en cours d’exécution.
Portail
1. Dans la page de la carte réseau attachée à la machine virtuelle, sélectionnez
Itinéraires effectifs sous Aide dans le volet de navigation gauche.
2. Passez en revue la liste des itinéraires effectifs pour déterminer si les itinéraires
sont appropriés pour vos communications entrante et sortante requises. Pour
plus d’informations sur le routage, consultez Routage du trafic de réseau
virtuel.
La fonctionnalité de tronçon suivant d’Azure Network Watcher peut également vous

aider à déterminer si des itinéraires empêchent la communication entre une machine
virtuelle et un point de terminaison. Pour plus d’informations, consultez Tutoriel :
diagnostiquer un problème de routage réseau de machine virtuelle à l’aide du portail
Azure.
Étapes suivantes
Pour d’autres tâches d’interface réseau, consultez les articles suivants :
Tâche Article
Ajouter, modifier ou supprimer des adresses IP Configurer des adresses IP pour une interface
pour les interfaces réseau Azure. réseau Azure
Ajouter ou supprimer des interfaces réseau pour Ajouter ou supprimer des interfaces réseau
les machines virtuelles. pour des machines virtuelles
Créer une machine virtuelle avec plusieurs cartes - Guide de création d’une machine virtuelle
d’interface réseau Linux dans Azure avec plusieurs cartes
- Créer et gérer une machine virtuelle
Windows équipée de plusieurs cartes
Créez une machine virtuelle à carte réseau - Attribuer plusieurs adresses IP à des
unique avec plusieurs adresses IPv4. machines virtuelles à l’aide d’Azure CLI
- Attribuer plusieurs adresses IP aux machines
virtuelles à l’aide d’Azure PowerShell
Créer une machine virtuelle à carte réseau unique - Créer un équilibreur de charge public avec
avec une adresse IPv6 privée derrière Azure Load IPv6 à l’aide d’Azure CLI
Balancer. - Créer un équilibrage de charge Internet
avec IPv6 à l’aide de PowerShell
- Déployer une solution d’équilibrage de
charge sur Internet avec IPv6, à l’aide d’un
modèle
Créer, modifier ou supprimer un réseau
virtuel
Découvrez comment créer et supprimer un réseau virtuel, ainsi que modifier des
paramètres tels que les serveurs DNS et les espaces d’adressage IP, pour un réseau
virtuel existant. Si vous découvrez les réseaux virtuels, vous trouverez plus
d’informations à leur sujet dans l’article Vue d’ensemble des réseaux virtuels ou en
suivant un tutoriel. Un réseau virtuel contient des sous-réseaux. Pour savoir comment
créer, modifier et supprimer des sous-réseaux, voir Gérer des sous-réseaux.
Prérequis
Si vous n’avez pas de compte Azure avec un abonnement actif, créez-en un
gratuitement . Effectuez une des tâches suivantes avant de commencer les étapes
décrites dans la suite de cet article :

Azure.
Utilisateurs de PowerShell : Exécutez les commandes dans Azure Cloud Shell ou

exécutez PowerShell localement à partir de votre ordinateur. Azure Cloud Shell est
un interpréteur de commandes interactif et gratuit que vous pouvez utiliser pour
et configurés pour être utilisés avec votre compte. Sous l’onglet de navigateur
Si vous exécutez PowerShell localement, utilisez le module Azure PowerShell

rechercher la version installée. Si vous devez installer ou mettre à niveau, consultez
Installer le module Azure PowerShell. Exécutez Connect-AzAccount pour vous
connecter à Azure.
Utilisateurs de Azure CLI : exécutez les commandes dans Azure Cloud Shell ou
exécutez Azure CLI à partir de votre ordinateur. Azure Cloud Shell est un
choisissez Bash si ce n’est pas déjà fait.
Si vous exécutez Azure CLI localement, utilisez Azure CLI version 2.0.31 ou
ultérieure. Exécutez az --version pour rechercher la version installée. Si vous
devez installer ou mettre à niveau, voir Installer Azure CLI. Exécutez az login pour
vous connecter à Azure.
Le compte auquel vous vous connectez, ou avec lequel vous vous connectez à Azure,
doit avoir le rôle contributeur réseau ou un rôle personnalisé disposant des
autorisations appropriées, listées dans Autorisations.
Créer un réseau virtuel au moyen du portail Azure

1. Dans la zone de recherche située en haut du portail, entrez Réseaux virtuels.
Sélectionnez Réseaux virtuels dans les résultats de la recherche.
2. Sélectionnez + Créer.
3. Dans l’onglet De base de l’option Créer un réseau virtuel, entrez ou sélectionnez

les valeurs pour les paramètres suivants :
Détails du
projet
Abonnement Sélectionnez Vous ne pouvez pas utiliser un même réseau virtuel dans
votre plus d’un abonnement Azure. En revanche, vous pouvez
abonnement. connecter un réseau virtuel se trouvant dans un
abonnement à des réseaux virtuels dans d’autres
abonnements à l’aide de l’appairage de réseaux virtuels.
Toute ressource Azure que vous connectez au réseau
virtuel doit figurer dans le même abonnement que le
réseau virtuel.
Resource Sélectionnez un Une ressource Azure que vous connectez au réseau

group groupe de virtuel peut figurer dans le même groupe de ressources
ressources que le réseau virtuel ou dans un autre groupe de
existant ou ressources.
créez-en un en
sélectionnant
Créer.
Détails de
l’instance
Nom Entrez un nom le nom doit être unique dans le groupe de ressources
pour le réseau dans lequel vous choisissez de créer le réseau virtuel.
virtuel que vous Vous ne pouvez pas modifier le nom une fois le réseau
créez. virtuel créé.
Pour des suggestions de dénomination, voir Conventions
d’affectation de noms. Le respect d’une convention
d’affectation de noms peut simplifier la gestion de
plusieurs réseaux virtuels.
Région Sélectionnez Un réseau virtuel peut figurer que dans une seule région
une région Azure. En revanche, vous pouvez connecter un réseau
Azure dans le virtuel se trouvant dans une région à un réseau virtuel
champ dans une autre région à l’aide de l’appairage de réseaux
Region virtuels.
(Région). Toute ressource Azure que vous connectez au réseau
virtuel doit figurer dans la même région que le réseau
virtuel.
4. Sélectionnez l’onglet Adresses IP ou Suivant : Adresses IP >, puis entrez les

informations d’adresse IP suivantes :
Espace d’adressage IPv4 : l’espace d’adressage d’un réseau virtuel se

compose d’une ou de plusieurs plages d’adresses ne se chevauchant pas et
spécifiées dans la notation CIDR. La plage d’adresses que vous définissez
peut être publique ou privée (RFC 1918). Que vous définissiez la plage
d’adresses comme publique ou privée, celle-ci est uniquement accessible à
partir du réseau virtuel, à partir de réseaux virtuels interconnectés et à partir
de tout réseau local que vous avez connecté au réseau virtuel.
Vous ne pouvez pas ajouter les plages d’adresses suivantes :

224.0.0.0/4 (multidiffusion)
255.255.255.255/32 (diffusion)
127.0.0.0/8 (bouclage)
169.254.0.0/16 (lien-local)
168.63.129.16/32 (sonde d’intégrité Azure Load Balancer, DHCP et DNS
interne)
Le portail nécessite la définition d’au moins une plage d’adresses IPv4 quand
vous créez un réseau virtuel. Vous pouvez modifier l’espace d’adressage
après la création du réseau virtuel sous certaines conditions.
２ Avertissement
Si un réseau virtuel comporte des plages d’adresses qui chevauchent

celles d’un autre réseau virtuel ou local, il est impossible de connecter
les deux réseaux. Avant de définir une plage d’adresses, demandez-vous
si vous souhaiteriez peut-être connecter le réseau virtuel à d’autres
réseaux virtuels ou locaux par la suite. Microsoft recommande de
configurer des plages d’adresses de réseau virtuel avec un espace
d’adressage privé ou public appartenant à votre organisation.
Ajouter un espace d’adressage IPv6 : l’espace d’adressage IPv6 d’un réseau

virtuel Azure vous permet d’héberger des applications dans Azure avec une
connectivité IPv6 et IPv4 au sein d’un réseau virtuel, ainsi qu’à destination et
en provenance d’Internet.
Nom du sous-réseau : Le nom du sous-réseau doit être unique au sein du

réseau virtuel. Vous ne pouvez pas modifier le nom du sous-réseau une fois
celui-ci créé. Lorsque vous créez un réseau virtuel, le portail exige que vous
définissiez un sous-réseau, même si un réseau virtuel ne doit pas
obligatoirement comprendre des sous-réseaux. Dans le portail, vous pouvez
définir un ou plusieurs sous-réseaux lorsque vous créez un réseau virtuel.
Vous pouvez ajouter des sous-réseaux au réseau virtuel une fois celui-ci créé.
Pour ajouter un sous-réseau à un réseau virtuel, consultez Gérer des sous-
réseaux.
 Conseil
Les administrateurs créent parfois des sous-réseaux distincts pour filtrer

ou contrôler le routage du trafic entre ceux-ci. Avant de définir des sous-
réseaux, réfléchissez à la manière dont vous pourriez vouloir filtrer et
router le trafic entre ceux-ci. Pour en savoir plus sur le filtrage du trafic
entre des sous-réseaux, voir Filtrer le trafic réseau avec les groupes de
sécurité réseau. Azure route automatiquement le trafic entre sous-
réseaux, mais vous pouvez remplacer les itinéraires par défaut d’Azure.
Pour en savoir plus sur le routage du trafic de sous-réseau par défaut
Azure, consultez Vue d’ensemble du routage.
Plage d’adresses de sous-réseau : la plage d’adresses doit s’inscrire dans

l’espace d’adressage que vous avez entré pour le réseau virtuel. La plus petite
plage que vous puissiez spécifier est /29. Celle-ci fournit huit adresses IP pour
le sous-réseau. Azure réserve la première et la dernière adresses dans chaque
sous-réseau pour la conformité du protocole. Trois adresses supplémentaires
sont réservées à l’usage du service Azure. Par conséquent, un réseau virtuel
dont la plage d’adresses de sous-réseau est /29 ne comprend que trois
adresses IP utilisables. Si vous envisagez de connecter un réseau virtuel à une
passerelle VPN, vous devez créer un sous-réseau de passerelle. Pour en savoir
plus, voir Sous-réseau de passerelle. Vous pouvez modifier la plage
d’adresses après la création du sous-réseau sous certaines conditions. Pour
savoir comment modifier une plage d’adresses de sous-réseau, consultez
Gérer des sous-réseaux.
Créer un réseau virtuel à l’aide de PowerShell

Créez un réseau virtuel à l’aide de la commande New-AzVirtualNetwork.
Azure PowerShell
## Create myVNet virtual network. ##

New-AzVirtualNetwork -ResourceGroupName myResourceGroup -Name myVNet -
Location eastus -AddressPrefix 10.0.0.0/16
Créer un réseau virtuel à l’aide d’Azure CLI

Utilisez la commande az network vnet create pour créer un réseau virtuel.
Azure CLI
## Create myVNet virtual network with the default address space:

10.0.0.0/16. ##
az network vnet create --resource-group myResourceGroup --name myVNet
Afficher des réseaux virtuels et des paramètres
Afficher les réseaux virtuels et les paramètres à l’aide du

portail Azure
2. Dans la liste des réseaux virtuels, sélectionnez le réseau dont vous souhaitez
afficher les paramètres.
3. Les paramètres répertoriés pour le réseau virtuel que vous avez sélectionné sont
les suivants :
Vue d’ensemble : fournit des informations sur le réseau virtuel, dont l’espace
d’adressage et les serveurs DNS. La capture d’écran suivante présente les
paramètres de vue d’ensemble pour un réseau virtuel nommé MyVNet :
Vous pouvez déplacer un réseau virtuel vers un autre abonnement ou un

autre groupe de ressources en sélectionnant l’option Déplacer en regard de
Groupe de ressources, Emplacement ou Abonnement. Pour savoir comment
déplacer un réseau virtuel, voir Déplacer des ressources vers un nouveau
groupe de ressource ou un nouvel abonnement. Cet article répertorie les
conditions préalables et explique comment déplacer des ressources à l’aide
du portail Azure, de PowerShell ou d’Azure CLI. Toutes les ressources
connectées au réseau virtuel doivent être déplacées avec celui-ci.
Espace d’adressage : les espaces d’adressage affectés au réseau virtuel sont

listés. Pour savoir comment ajouter et supprimer une plage d’adresses,
procédez comme indiqué dans la section Ajouter ou supprimer une plage
d’adresses.
Appareils connectés : toutes les ressources connectées au réseau virtuel sont

listées. Toutes les ressources que vous créez et connectez au réseau virtuel
sont ajoutées à la liste. Si vous supprimez une ressource connectée au réseau
virtuel, elle n’apparaît plus dans la liste.
Sous-réseaux : la liste des sous-réseaux présents dans le réseau virtuel est

affichée. Pour savoir comment ajouter et supprimer un sous-réseau, consultez
Gérer des sous-réseaux.
Serveurs DNS : vous pouvez spécifier le serveur chargé d’assurer la résolution

de noms pour les appareils connectés au réseau virtuel : le serveur DNS
interne Azure ou le serveur DNS personnalisé. Lorsque vous créez un réseau
virtuel via le portail Azure, par défaut, les serveurs DNS d’Azure sont utilisés
pour la résolution de noms au sein du réseau virtuel. Pour découvrir
comment modifier les serveurs DNS, consultez la procédure de la section
Modifier les serveurs DNS de cet article.
Peerings : s’il existe des peerings dans l’abonnement, ils sont répertoriés ici.
Vous pouvez afficher les paramètres des peerings existants, ou créer, modifier
ou supprimer des peerings. Pour en savoir plus sur l’appairage (Peering),
consultez Appairage de réseaux virtuels et Gérer les appairages de réseaux
virtuels.
Propriétés : affiche les paramètres du réseau virtuel, dont l’ID de la ressource

et l’abonnement Azure.
Diagramme : offre une représentation visuelle de l’ensemble des appareils

connectés au réseau virtuel. Il comporte des informations clés sur les
appareils. Pour gérer un appareil affiché dans le diagramme, sélectionnez-le.
Paramètres Azure courants : Pour en savoir plus sur les paramètres Azure
communs, consultez les informations suivantes :
Balises
Verrous
Script Automation
Afficher les réseaux virtuels et les paramètres à l’aide de

PowerShell
Utilisez Get-AzVirtualNetwork pour répertorier l’ensemble des réseaux virtuels dans un
groupe de ressources.
Azure PowerShell
Get-AzVirtualNetwork -ResourceGroupName myResourceGroup | format-table Name,

ResourceGroupName, Location
Utilisez Get-AzVirtualNetwork pour afficher les paramètres d’un réseau virtuel.
Azure PowerShell
Get-AzVirtualNetwork -ResourceGroupName myResourceGroup -Name myVNet
Afficher les réseaux virtuels et les paramètres à l’aide de

l’interface Azure CLI
Utilisez az network vnet list pour répertorier l’ensemble des réseaux virtuels dans un
Azure CLI
az network vnet list --resource-group myResourceGroup
Utilisez az network vnet show pour afficher les paramètres d’un réseau virtuel.
Azure CLI
az network vnet show --resource-group myResourceGroup --name myVNet
Ajouter ou supprimer une plage d’adresses

Vous pouvez ajouter et supprimer des plages d’adresses pour un réseau virtuel. Une
plage d’adresses doit être spécifiée dans une notation CIDR. Elle ne peut pas chevaucher
d’autres plages d’adresses au sein du même réseau virtuel. Les plages d’adresses que
vous définissez peuvent être publiques ou privées (RFC 1918). Que vous définissiez la
plage d’adresses comme publique ou privée, celle-ci est uniquement accessible à partir
du réseau virtuel, à partir de réseaux virtuels interconnectés et à partir de tout réseau
local que vous avez connecté au réseau virtuel.
Vous pouvez réduire la plage d’adresses d’un réseau virtuel tant qu’il comprend toujours
les plages de tous les sous-réseaux associés. En outre, vous pouvez étendre la plage
d’adresses, par exemple en remplaçant /16 par /8.
Vous ne pouvez pas ajouter les plages d’adresses suivantes :
255.255.255.255/32 (diffusion)
127.0.0.0/8 (bouclage)
169.254.0.0/16 (lien-local)
168.63.129.16/32 (sonde d’intégrité Azure Load Balancer, DHCP et DNS interne)
７ Notes
Si le réseau virtuel est appairé à un autre réseau virtuel ou connecté à un réseau

local, la nouvelle plage d’adresses ne peut pas chevaucher l’espace d’adressage des
réseaux virtuels appairés ni du réseau local. Pour plus d’informations, consultez
Mettre à jour l’espace d’adressage d’un réseau virtuel appairé.
Ajouter ou supprimer une plage d’adresses à l’aide du

portail Azure
2. Dans la liste des réseaux virtuels, sélectionnez le réseau pour lequel vous souhaitez
ajouter ou supprimer une plage d’adresses.
3. Sous Paramètres, sélectionnez Espace d’adressage.
4. Choisissez l'une des options suivantes :
Ajouter une plage d’adresses : entrez la nouvelle plage d’adresses. La plage

d’adresses ne peut pas chevaucher une plage d’adresses existante définie
pour le réseau virtuel.
Modifier une plage d’adresses : modifiez une plage d’adresses existante.

Vous pouvez modifier le préfixe de plage d’adresses pour diminuer ou
augmenter la plage d’adresses. Vous pouvez réduire la plage d’adresses à
condition qu’elle comprenne toujours les plages de tous les sous-réseaux
associés. En outre, vous pouvez étendre la plage d’adresses à condition
qu’elle ne chevauche pas une plage d’adresses existante définie pour le
réseau virtuel.
Supprimer une plage d’adresses : à droite de la plage d’adresses à

supprimer, sélectionnez Supprimer. S’il existe déjà un sous-réseau dans la
plage d’adresses, vous ne pouvez pas supprimer la plage. Avant de supprimer
une plage d’adresses, vous devez supprimer tous les sous-réseaux (et toutes
les ressources des sous-réseaux) existant dans celle-ci.
Ajouter ou supprimer une plage d’adresses à l’aide de

PowerShell
Utilisez Set-AzVirtualNetwork pour mettre à jour l’espace d’adressage d’un réseau
virtuel.
Azure PowerShell
## Place the virtual network configuration into a variable. ##

$virtualNetwork = Get-AzVirtualNetwork -ResourceGroupName myResourceGroup -
Name myVNet
## Remove the old address range. ##
$virtualNetwork.AddressSpace.AddressPrefixes.Remove("10.0.0.0/16")
## Add the new address range. ##
$virtualNetwork.AddressSpace.AddressPrefixes.Add("10.1.0.0/16")
## Update the virtual network. ##
Set-AzVirtualNetwork -VirtualNetwork $virtualNetwork
Ajouter ou supprimer une plage d’adresses à l’aide de

Utilisez az network vnet update pour mettre à jour l’espace d’adressage d’un réseau
virtuel.
Azure CLI
## Update the address space of myVNet virtual network with 10.1.0.0/16
address range (10.1.0.0/16 overrides any previous address ranges set in this
virtual network). ##
az network vnet update --resource-group myResourceGroup --name myVNet --
address-prefixes 10.1.0.0/16
Modifier les serveurs DNS

Toutes les machines virtuelles connectées au réseau virtuel s’inscrivent auprès des
serveurs DNS que vous spécifiez pour le réseau virtuel. Elles utilisent également le
serveur DNS spécifié pour la résolution de noms. Chaque carte réseau (NIC) sur un
ordinateur virtuel peut avoir ses propres paramètres de serveur DNS. Si une carte réseau
a ses propres paramètres de serveur DNS, ceux-ci remplacent les paramètres du serveur
DNS pour le réseau virtuel. Pour en savoir plus sur les paramètres DNS de carte réseau,
voir Interfaces réseau (cartes d’interface réseau). Pour en savoir plus sur la résolution de
noms pour des machines virtuelles et des instances de rôle dans Azure Cloud Services,
voir Résolution de noms pour les machines virtuelles et les instances de rôle. Pour
ajouter, modifier ou supprimer un serveur DNS :
Modifier les serveurs DNS d’un réseau virtuel à l’aide du

portail Azure
2. Dans la liste des réseaux virtuels, sélectionnez le réseau dont vous souhaitez
modifier les serveurs DNS.
3. Sélectionnez Serveurs DNS sous Paramètres.
4. Sélectionnez l’une des options suivantes :
Par défaut (fournie par Azure) : les noms de ressources et adresses IP privées
sont tous inscrits automatiquement sur les serveurs Azure DNS. Vous pouvez
résoudre les noms parmi toutes les ressources connectées à un même réseau
virtuel. Vous ne pouvez pas utiliser cette option pour résoudre les noms dans
plusieurs réseaux virtuels. Pour résoudre les noms dans plusieurs réseaux
virtuels, vous devez utiliser un serveur DNS personnalisé.
Personnalisé : vous pouvez ajouter un ou plusieurs serveurs, jusqu’à la limite

autorisée par Azure pour un réseau virtuel. Pour en savoir plus sur les limites
du serveur DNS, voir Limites d’Azure. Vous disposez des options suivantes :
Ajouter une adresse : ajoute le serveur à la liste des serveurs DNS de votre
réseau virtuel. Cette option inscrit également le serveur DNS auprès
d’Azure. Si vous avez déjà inscrit un serveur DNS auprès d’Azure, vous
pouvez sélectionner ce serveur dans la liste.
Supprimer une adresse : à côté du serveur à supprimer, sélectionnez

Supprimer. La suppression du serveur ne supprime que le serveur de cette
liste de réseaux virtuels. Le serveur DNS reste enregistré dans Azure pour
être utilisé par vos autres réseaux virtuels.
Réorganiser les adresses des serveurs DNS : il est important de vérifier

que les serveurs DNS sont listés dans l’ordre approprié pour votre
environnement. Les serveurs DNS sont utilisés dans l’ordre où ils sont
spécifiés dans la liste. Elles ne fonctionnent pas comme un tourniquet
(round robin). Si le premier serveur DNS de la liste est accessible, le client
utilise celui-ci, qu’il fonctionne correctement ou non. Supprimez tous les
serveurs DNS répertoriés, puis rajoutez-les dans l’ordre souhaité.
Changer une adresse : mettez en surbrillance le serveur DNS dans la liste,

puis entrez la nouvelle adresse.
6. Redémarrez les machines virtuelles connectées au réseau virtuel, afin que les
nouveaux paramètres de serveur DNS leur soient attribués. Les machines virtuelles
continuent d’utiliser leurs paramètres DNS actuels jusqu’à ce qu’elles soient
redémarrées.
Modifier les serveurs DNS d’un réseau virtuel à l’aide de

PowerShell
Utilisez Set-AzVirtualNetwork pour mettre à jour un réseau virtuel avec un nouvel
espace d’adressage.
Azure PowerShell
## Place the virtual network configuration into a variable. ##

$virtualNetwork = Get-AzVirtualNetwork -ResourceGroupName myResourceGroup -
Name myVNet
## Add the IP address of the DNS server. ##
$virtualNetwork.DhcpOptions.DnsServers.Add("10.0.0.10")
## Update the virtual network. ##
Set-AzVirtualNetwork -VirtualNetwork $virtualNetwork
Modifier les serveurs DNS d’un réseau virtuel à l’aide de
Utilisez az network vnet update pour mettre à jour l’espace d’adressage d’un réseau
virtuel.
Azure CLI
## Update the virtual network with IP address of the DNS server. ##

az network vnet update --resource-group myResourceGroup --name myVNet --dns-
servers 10.0.0.10
Supprimer un réseau virtuel

Vous pouvez supprimer un réseau virtuel uniquement si aucune ressource n’est
connectée à celui-ci. Si des ressources sont connectées à un sous-réseau du réseau
virtuel, vous devez commencer par supprimer les ressources connectées à tous les sous-
réseaux du réseau virtuel. La procédure à suivre pour supprimer une ressource varient
en fonction de celle-ci. Pour savoir comment supprimer des ressources connectées à des
sous-réseaux, lisez la documentation relative à chaque type de ressource que vous
souhaitez supprimer. Pour supprimer un réseau virtuel :
Supprimer un réseau virtuel à l’aide du portail Azure

2. Dans la liste des réseaux virtuels, sélectionnez le réseau à supprimer.
3. Vérifiez qu’aucun appareil n’est connecté au réseau virtuel en sélectionnant

Appareils connectés sous Paramètres. Si des appareils sont connectés, vous devez
les supprimer avant de supprimer le réseau virtuel. Si aucun appareil n’est
connecté, sélectionnez Vue d’ensemble.
4. Sélectionnez Supprimer.
5. Pour confirmer la suppression du réseau virtuel, cliquez sur Oui.
Supprimer un réseau virtuel à l’aide de PowerShell

Utilisez Remove-AzVirtualNetwork pour supprimer un réseau virtuel.
Azure PowerShell
Remove-AzVirtualNetwork -ResourceGroupName myResourceGroup -Name myVNet
Supprimer un réseau virtuel à l’aide de l’interface Azure

CLI
Utilisez az network vnet delete pour supprimer un réseau virtuel.
Azure CLI
az network vnet delete --resource-group myResourceGroup --name myVNet
Autorisations
Pour effectuer des tâches sur des réseaux virtuels, votre compte doit posséder le rôle de
contributeur de réseaux ou un rôle personnalisé disposant des actions appropriées qui
sont répertoriées dans le tableau suivant :
Action Nom
Microsoft.Network/virtualNetworks/read Lire un réseau virtuel
Microsoft.Network/virtualNetworks/write Création ou mise à jour d’un réseau virtuel
Microsoft.Network/virtualNetworks/delete Supprimer un réseau virtuel
Étapes suivantes
Créez un réseau virtuel avec les exemples de scripts PowerShell ou Azure CLI, ou à
l’aide desmodèles Azure Resource Manager
Ajouter, modifier ou supprimer un sous-réseau de réseau virtuel
Créez et attribuez des définitions Azure Policy pour les réseaux virtuels
 Documentation
Créer, changer ou supprimer une adresse IP publique Azure - Azure Virtual Network
Gérer les adresses IP publiques. Découvrez comment une adresse IP publique constitue une
ressource disposant de paramètres configurables.
Adresses IP privées dans Azure

Découvrez les adresses IP privées dans Azure.
Questions fréquentes (FAQ) sur le réseau virtuel Azure

Réponses aux questions les plus fréquemment posées sur les réseaux virtuels Microsoft Azure.
Adresses IP publiques dans Azure - Azure Virtual Network

En savoir plus sur les adresses IP publiques dans Azure.
Créer, modifier ou supprimer une table de routage Azure

Découvrez où trouver des informations sur le routage du trafic de réseau virtuel et comment créer,
modifier ou supprimer une table de route.
Résoudre les problèmes d’appairage de réseaux virtuels

Étapes permettant de résoudre la plupart des problèmes d’appairage de réseaux virtuels.
Connecter un réseau virtuel à un réseau virtuel avec une connexion de réseau virtuel
à réseau virtuel : Azure CLI - Azure VPN Gateway
Apprenez à connecter des réseaux virtuels avec une connexion de réseau virtuel à réseau virtuel et
Azure CLI.
Mettre à jour l’espace d’adressage d’un réseau virtuel appairé - Portail Azure
Découvrez comment ajouter, modifier ou supprimer les plages d’adresses d’un réseau virtuel appairé
sans temps d’arrêt.
Afficher 5 de plus
 Entrainement
Module
Distribuer vos services sur des réseaux virtuels Azure et les intégrer avec le peering de
réseaux virtuels - Training
Utilisez le peering de réseaux virtuels pour activer la communication entre des réseaux virtuels de
façon sécurisée et peu complexe.
Certification
Ajouter, modifier ou supprimer un sous-
réseau de réseau virtuel
Toutes les ressources Azure d’un réseau virtuel sont déployées en sous-réseaux au sein
de ce réseau virtuel. Cet article explique comment ajouter, modifier ou supprimer des
sous-réseaux de réseau virtuel à l’aide du portail Azure, d’Azure CLI ou d’Azure
PowerShell.
Prérequis
Portail

Réseau virtuel Azure existant. Pour en créer un, consultez Démarrage rapide :
créer un réseau virtuel à l’aide du portail Azure.
Pour exécuter les procédures, connectez-vous au portail Azure avec votre
compte Azure.
Autorisations
Pour effectuer des tâches sur des sous-réseaux, votre compte doit disposer du rôle de
contributeur de réseaux ou d’un rôle personnalisé auquel sont assignées les actions
appropriées de la liste suivante :
Action Nom
Microsoft.Network/virtualNetworks/subnets/read Lire un sous-réseau

de réseau virtuel.
Microsoft.Network/virtualNetworks/subnets/write Créer ou mettre à

jour un sous-réseau
de réseau virtuel.
Microsoft.Network/virtualNetworks/subnets/delete Supprimer un sous-

réseau de réseau
virtuel.
Microsoft.Network/virtualNetworks/subnets/join/action Joindre un réseau

virtuel.
Action Nom
Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action Activer un point de

terminaison de
service sur un sous-
réseau.
Microsoft.Network/virtualNetworks/subnets/virtualMachines/read Obtenir les

machines virtuelles
d’un sous-réseau.
Ajouter un sous-réseau
Portail
1. Dans le portail Azure , recherchez et sélectionnez Réseaux virtuels.

2. Dans la page Réseaux virtuels, sélectionnez le réseau virtuel auquel vous
souhaitez ajouter un sous-réseau.
3. Dans la page du réseau virtuel, sélectionnez Sous-réseaux depuis la barre de
navigation gauche.
4. Dans la page Sous-réseaux, sélectionnez + Sous-réseau.
5. Dans l’écran Ajouter un sous-réseau, entrez ou sélectionnez les valeurs des
paramètres du sous-réseau.
Vous pouvez configurer les paramètres suivants pour un sous-réseau :
Paramètre Description
Nom Le nom doit être unique au sein du réseau virtuel. Pour une compatibilité maximale
avec d’autres services Azure, utilisez une lettre comme premier caractère du nom.
Par exemple, Azure Application Gateway ne peut pas se déployer dans un sous-
réseau dont le nom commence par un nombre.
Plage La plage doit être unique au sein de l’espace d’adressage et ne peut pas
d’adresses chevaucher d’autres plages d’adresses de sous-réseaux dans le réseau virtuel. Vous
de sous- devez spécifiez l’espace d’adressage à l’aide de la notation de routage CIDR
réseau (Classless InterDomain Routing).
Par exemple, dans un réseau virtuel avec l’espace d’adressage 10.0.0.0/16 , vous
pouvez définir l’espace d’adressage de sous-réseau 10.0.0.0/22 . La plus petite
plage que vous pouvez spécifier est /29 . Celle-ci fournit huit adresses IP au sous-
réseau. Azure réserve la première et la dernière adresse de chaque sous-réseau
pour la conformité du protocole et trois adresses supplémentaires pour l’utilisation
du service Azure. Ainsi, la définition d’un sous-réseau ayant une plage d’adresses
/29 donne trois adresses IP utilisables dans le sous-réseau.
Si vous envisagez de connecter un réseau virtuel à la passerelle d’un réseau privé

virtuel (VPN), vous devez créer un sous-réseau de passerelles. Pour plus
d'informations, consultez Sous-réseau de passerelles.
Ajouter un Vous pouvez créer un réseau virtuel à double pile qui prend en charge IPv4 et IPv6
espace en ajoutant un espace d’adressage IPv6 existant. Actuellement, IPv6 n’est pas
d'adressage entièrement pris en charge pour tous les services d’Azure. Pour plus d’informations,
IPv6 consultez Vue d’ensemble du protocole IPv6 pour un réseau virtuel Azure
Passerelle Pour fournir une traduction d’adresses réseau (NAT) aux ressources d’un sous-
NAT réseau, vous pouvez associer une passerelle NAT existante à un sous-réseau. La
passerelle NAT doit être associée au même abonnement et se trouver au même
emplacement que le réseau virtuel. Pour plus d’informations, consultez Réseau
virtuel NAT et Démarrage rapide : créer une passerelle NAT à l’aide du portail
Azure.
Groupe de Vous pouvez associer un groupe de sécurité réseau (NSG) existant à un sous-
sécurité réseau pour filtrer le trafic réseau entrant et sortant du sous-réseau. Le NSG doit
réseau exister dans le même abonnement et au même emplacement que le réseau virtuel.
Pour plus d’informations, consultez Groupes de sécurité réseau et Tutoriel : Filtrer
le trafic réseau avec un groupe de sécurité réseau à l’aide du portail Azure.
Table de Vous pouvez éventuellement associer une table de route existante à un sous-
routage réseau pour contrôler le routage du trafic réseau vers d’autres réseaux. La table de
routage doit exister dans le même abonnement et au même emplacement que le
réseau virtuel. Pour plus d’informations, consultez Routage du trafic d’un réseau
virtuel et Tutoriel : Acheminer le trafic réseau avec une table de routage à l’aide du
portail Azure.
Points de Vous pouvez éventuellement activer un ou plusieurs points de terminaison de

terminaison service sur un sous-réseau. Pour activer un point de terminaison de service sur un
de service service pendant la configuration du sous-réseau du portail, sélectionnez le ou les
services sur lesquels vous souhaitez activer des points de terminaison de service
dans la liste conceptuelle sousServices. Azure configure automatiquement
l’emplacement d’un point de terminaison. Pour supprimer un point de terminaison
de service, désélectionnez le service dont vous souhaitez supprimer le point de
terminaison de service. Pour plus d’informations, consultez Points de terminaison
de service de réseau virtuel.
Par défaut, Azure configure les points de terminaison de service dans la région du
réseau virtuel. Pour le Stockage Azure, Azure configure automatiquement les points
de terminaison dans des régions appairées Azure pour permettre la prise en
charge de scénarios de basculement régionaux.
Une fois que vous avez activé un point de terminaison de service, vous devez
également activer l’accès au sous-réseau des ressources créées par le service. Par
exemple, si vous activez le point de terminaison de service Microsoft.Storage, vous
devez également activer l’accès réseau à tous les comptes de stockage Azure
auxquels vous souhaitez accorder l’accès réseau. Pour activer l’accès du réseau à
des sous-réseaux sur lesquels un point de terminaison de service est activé,
consultez la documentation relative au service particulier.
Pour vérifier qu’un point de terminaison de service est activé pour un sous-réseau,
affichez les routages effectifs sur les interfaces réseau dans le sous-réseau. Quand
vous configurez un point de terminaison, vous voyez un itinéraire par défaut avec
les préfixes d’adresse du service et le type de tronçon suivant
VirtualNetworkServiceEndpoint. Pour plus d’informations, consultez Routage du
trafic de réseau virtuel.
Délégation Vous pouvez éventuellement activer une ou plusieurs délégations sur un sous-
de sous- réseau. La délégation de sous-réseau donne les autorisations explicites au service
réseau de créer des ressources spécifiques au service dans le sous-réseau à l’aide d’un
identificateur unique pendant le déploiement du service. Pour déléguer à un
service pendant la configuration du sous-réseau du portail, sélectionnez le service
souhaité dans la liste conceptuelle.
Stratégie Pour contrôler le trafic à destination d’un point de terminaison privé, vous pouvez
réseau pour utiliser des groupes de sécurité réseau ou des tables de routage. Pendant la
les points configuration du sous-réseau du portail, sélectionnez l’une de ces options sous
de Stratégie réseau d’un point de terminaison privé pour utiliser ces contrôles sur un
terminaison sous-réseau. Une fois activée, la stratégie réseau s’applique à tous les points de
privés terminaison privés du sous-réseau. Pour en savoir plus, consultez Gestion des
stratégies réseau pour les points de terminaison privés.
Modifier les paramètres de sous-réseau

Portail

2. Dans la page Réseaux virtuels, sélectionnez le réseau virtuel dont vous
souhaitez modifier les paramètres du sous-réseau.
navigation gauche.
4. Dans la page Sous-réseaux, sélectionnez le sous-réseau dont vous souhaitez
modifier les paramètres.
5. Dans l’écran du sous-réseau, modifiez les paramètres du sous-réseau, puis
Vous pouvez modifier les paramètres de sous-réseau suivants après avoir créé le sous-
réseau :
Plage Si aucune ressource n’a été déployée dans le sous-réseau, vous pouvez changer la
d’adresses plage d’adresses. Si des ressources existent dans le sous-réseau, vous devez
de sous- d’abord déplacer les ressources vers un autre sous-réseau ou les supprimer du
réseau sous-réseau. La procédure à suivre pour supprimer ou déplacer une ressource
varie en fonction de celle-ci. Pour savoir comment supprimer ou déplacer des
ressources existantes dans des sous-réseaux, lire la documentation relative à
chaque type de ressource.
Ajouter un Vous pouvez ajouter la prise en charge d’un protocole IPv6, d’une passerelle NAT,
espace d’un groupe de sécurité réseau (NSG) ou d’une table de routage après avoir créé
d’adressage le sous-réseau.
IPv6,
passerelle
NAT,
Groupe de
sécurité
réseau et
Table de
routage
Points de Pour activer le point de terminaison de service d’un sous-réseau existant, vérifiez
terminaison qu’aucune tâche critique n’est en cours d’exécution sur l’une des ressources du
de service sous-réseau. Les points de terminaison de service changent d’itinéraire sur chaque
interface réseau dans le sous-réseau. Dans les points de terminaison de service,
l’itinéraire par défaut contenant le préfixe d’adresse 0.0.0.0/0 et le type de
tronçon suivant Internet est remplacé par un nouvel itinéraire contenant le
préfixe d’adresse du service et le type de tronçon suivant
VirtualNetworkServiceEndpoint .
Le changement de routage peut entraîner l’arrêt des connexions TCP ouvertes. Le

point de terminaison de service est activé après que le trafic vers le service de
toutes les interfaces réseau a été mis à jour avec le nouvel itinéraire. Pour plus
d’informations, consultez Routage du trafic de réseau virtuel.
Délégation Vous pouvez modifier la délégation du sous-réseau pour activer zéro ou plusieurs
de sous- délégations. Si la ressource d’un service est déjà déployée dans le sous-réseau,
réseau vous pouvez ajouter ou supprimer des délégations de sous-réseau après avoir
supprimé toutes les ressources du services. Pour déléguer à un autre service du
portail, sélectionnez le service souhaité dans la liste contextuelle.
Stratégie Vous pouvez modifier la stratégie du réseau d’un point de terminaison privé après
réseau pour la création du sous-réseau.
les points
de
terminaison
privés
Supprimer un sous-réseau
Portail
Vous pouvez supprimer un sous-réseau uniquement si aucune ressource ne s’y

trouve. Si le sous-réseau contient des ressources, vous devez les supprimer pour
pouvoir supprimer le sous-réseau. La procédure à suivre pour supprimer une
ressource varient en fonction de celle-ci. Pour savoir comment supprimer les
ressources, consultez la documentation de chaque type de ressource.

2. Dans la page Réseaux virtuels, sélectionnez le réseau virtuel dont vous voulez
supprimer un sous-réseau.
navigation gauche.
4. Dans la page Sous-réseaux, sélectionnez le sous-réseau que vous souhaitez
supprimer.
Étapes suivantes
Créer, modifier ou supprimer un réseau virtuel.
Exemples de scripts PowerShell
Exemples de scripts CLI Azure
Exemples de modèles Azure Resource Manager
Définitions intégrées d’Azure Policy pour Réseau virtuel Azure
Ajouter ou supprimer une délégation de
sous-réseau
Article • 11/05/2023
La délégation de sous-réseau donne des autorisations explicites au service pour créer

des ressources propres au service dans le sous-réseau à l’aide d’un identificateur unique
pendant le déploiement du service. Cet article explique comment ajouter un sous-
réseau délégué à un service Azure et comment l’en supprimer.
Prérequis
Si vous n’avez pas créé le sous-réseau que vous souhaitez déléguer à un service
Azure, vous devez disposer de l’autorisation suivante :
Microsoft.Network/virtualNetworks/subnets/write . Le rôle intégré Contributeur
réseau inclut également les autorisations nécessaires.



upgrade.
Cet article pratique nécessite la version 2.31.0 ou ultérieure d’Azure CLI. Si vous
utilisez Azure Cloud Shell, la version la plus récente est déjà installée.
Azure PowerShell installé localement ou Azure Cloud Shell.
Connectez-vous à Azure PowerShell et vérifiez que vous avez sélectionné

l’abonnement avec lequel vous souhaitez utiliser cette fonctionnalité. Pour plus
d’informations, consultez Se connecter avec Azure PowerShell.
Vérifiez que la version du module Az.Network est 4.3.0 ou ultérieure. Pour vérifier le
module installé, utilisez la commande Get-InstalledModule -Name "Az.Network" . Si
le module nécessite une mise à jour, utilisez la commande Update-Module -Name
Az.Network , si nécessaire.

vous exécutez PowerShell en local, vous devez également exécuter Connect-AzAccount

Dans le cadre de cette section, vous allez créer un réseau virtuel et le sous-réseau que
vous déléguerez plus tard à un service Azure.
Portail
2. Dans la zone de recherche située en haut du portail, entrez Réseau virtuel.

4. Sous l’onglet Informations de base dans Créer un réseau virtuel, entrez ou

Paramètre Valeur
Détails du projet

Paramètre Valeur

Entrez myResourceGroup dans Nom.
Sélectionnez OK.
Nom Entrez myVNet.
Région Sélectionnez USA Est 2
5. Sélectionnez Suivant : Sécurité, puis Suivant : Adresses IP.
6. Sélectionnez Ajouter un espace d’adressage IP, dans le volet Ajouter un

espace d’adressage IP, entrez ou sélectionnez les informations suivantes, puis
sélectionnez Ajouter.
Paramètre Valeur
Type d’espace d'adressage Laissez la valeur par défaut IPV6.
Adresse de début Entrez 10.1.0.0.
Taille de l’espace d’adressage Sélectionnez /16.
7. Sélectionnez + Ajouter un sous-réseau dans le nouvel espace d’adressage IP.
8. Dans Ajouter un sous-réseau, saisissez ou sélectionnez les informations

suivantes : Sélectionnez ensuite Ajouter.
Paramètre Valeur
Nom Entrez mySubnet.
Adresse de début Entrez 10.1.0.0.
Taille du sous-réseau Sélectionnez /16.
9. Sélectionnez Vérifier + créer, puis sélectionnez Créer.
Déléguer un sous-réseau à un service Azure

Dans le cadre de cette section, vous allez déléguer le sous-réseau que vous avez créé à
la section précédente à un service Azure.
Portail

3. Sélectionnez myVNet.
4. Sélectionnez Sous-réseaux dans Paramètres.
5. Sélectionnez mySubnet.
Paramètre Valeur
DÉLÉGATION DE
SOUS-RÉSEAU
Déléguer un sous- Sélectionnez le service auquel vous souhaitez déléguer le sous-

réseau à un service réseau. Par exemple, Microsoft. Sql/managedInstances.
Supprimer une délégation de sous-réseau d’un

service Azure
Dans cette section, vous allez supprimer une délégation de sous-réseau pour un service
Azure.
Portail

3. Sélectionnez myVNet.
4. Sélectionnez Sous-réseaux dans Paramètres.

5. Sélectionnez mySubnet.
Paramètre Valeur
DÉLÉGATION DE SOUS-RÉSEAU
Déléguer un sous-réseau à un service Sélectionnez Aucun.


sélectionnez-le.

Étapes suivantes
Découvrez comment gérer les sous-réseaux dans Azure.
Connecter des réseaux virtuels à l’aide
du peering de réseaux virtuels en
utilisant PowerShell
Article • 11/05/2023
virtuels. Une fois que les deux réseaux virtuels sont appairés, leurs ressources peuvent
communiquer entre elles avec les mêmes bande passante et latence, comme si elles se
trouvaient sur le même réseau virtuel. Dans cet article, vous apprendrez comment :
Créer deux réseaux virtuels

Connecter deux réseaux virtuels à l’aide du peering de réseaux virtuels
Déployer une machine virtuelle sur chaque réseau virtuel
Établir une communication entre les machines virtuelles

commencer.
Azure Cloud Shell

Option Exemple/Lien








Avant de créer un réseau virtuel, vous devez créer un groupe de ressources pour le
réseau virtuel et toutes les autres ressources créées dans cet article. Créez un groupe de
ressources avec New-AzResourceGroup. L’exemple suivant crée un groupe de
ressources nommé myResourceGroup à l’emplacement eastus.
Azure PowerShell
Créez un réseau virtuel avec New-AzVirtualNetwork. L’exemple suivant permet de créer

un réseau virtuel nommé myVirtualNetwork1 avec le préfixe d’adresse 10.0.0.0/16.
Azure PowerShell
$virtualNetwork1 = New-AzVirtualNetwork `
-Location EastUS `
-Name myVirtualNetwork1 `
Créez une configuration de sous-réseau à l’aide de la commande Add-

AzVirtualNetworkSubnetConfig. L’exemple suivant crée une configuration de sous-
réseau avec un préfixe d’adresse 10.0.0.0/24 :
Azure PowerShell
$subnetConfig = Add-AzVirtualNetworkSubnetConfig `
-Name Subnet1 `
-VirtualNetwork $virtualNetwork1
Écrivez la configuration du sous-réseau dans le réseau virtuel à l’aide de la commande

Set-AzVirtualNetwork, ce qui crée le sous-réseau :
Azure PowerShell
$virtualNetwork1 | Set-AzVirtualNetwork
Créez un réseau virtuel avec un préfixe d’adresse 10.1.0.0/16 et un sous-réseau :
Azure PowerShell
# Create the virtual network.

$virtualNetwork2 = New-AzVirtualNetwork `
-Location EastUS `
-Name myVirtualNetwork2 `
# Create the subnet configuration.

$subnetConfig = Add-AzVirtualNetworkSubnetConfig `
-Name Subnet1 `
-VirtualNetwork $virtualNetwork2
# Write the subnet configuration to the virtual network.

$virtualNetwork2 | Set-AzVirtualNetwork

Créez un Peering Add-AzVirtualNetworkPeering. L’exemple suivant appaire
myVirtualNetwork1 avec myVirtualNetwork2.
Azure PowerShell
Add-AzVirtualNetworkPeering `
-Name myVirtualNetwork1-myVirtualNetwork2 `
-VirtualNetwork $virtualNetwork1 `
-RemoteVirtualNetworkId $virtualNetwork2.Id
Dans la sortie obtenue après l’exécution de la commande ci-dessus, vous constatez que
la valeur de PeeringState (état de l’appairage) est Initiated. Le peering reste dans l’état
Initiated jusqu’à ce que vous créiez le peering entre myVirtualNetwork2 et
myVirtualNetwork1. Créez un peering entre myVirtualNetwork2 et myVirtualNetwork1.
Azure PowerShell
-Name myVirtualNetwork2-myVirtualNetwork1 `
-VirtualNetwork $virtualNetwork2 `
-RemoteVirtualNetworkId $virtualNetwork1.Id
Dans la sortie obtenue après l’exécution de la commande ci-dessus, vous constatez que
PeeringState (état de l’appairage) est Connected. Azure a également changé l’état du
peering myVirtualNetwork1-myVirtualNetwork2 en Connected. Vérifiez que l’état du
Peering myVirtualNetwork1-myVirtualNetwork2 a été remplacé par Connected à l’aide
de Get-AzVirtualNetworkPeering.
Azure PowerShell
Get-AzVirtualNetworkPeering `
-VirtualNetworkName myVirtualNetwork1 `
| Select PeeringState
Les ressources d’un réseau virtuel ne peuvent pas communiquer avec les ressources
d’un autre réseau virtuel tant que la valeur de PeeringState pour les appairages dans les
deux réseaux virtuels soit Connected.

Créez une machine virtuelle sur chaque réseau virtuel afin de pouvoir établir une
communication entre elles dans une étape ultérieure.

Créez une machine virtuelle avec New-AzVM. L’exemple suivant crée une machine
virtuelle nommée myVm1 dans le réseau virtuel myVirtualNetwork1. L’option -AsJob
crée la machine virtuelle en arrière-plan. Vous pouvez donc passer à l’étape suivante.
Lorsque vous y êtes invité, entrez le nom d’utilisateur et le mot de passe pour vous
connecter à la machine virtuelle.
Azure PowerShell
New-AzVm `
-VirtualNetworkName "myVirtualNetwork1" `
-SubnetName "Subnet1" `
-Name "myVm1" `
-AsJob

Azure PowerShell
New-AzVm `
-VirtualNetworkName "myVirtualNetwork2" `
-SubnetName "Subnet1" `
-Name "myVm2"
La création de la machine virtuelle ne nécessite que quelques minutes. Attendez

qu’Azure ait créé la machine virtuelle et renvoyé une sortie à PowerShell pour passer aux
étapes suivantes.
７ Notes
virtuelles
Vous pouvez vous connecter à l’adresse IP publique d’une machine virtuelle depuis
Internet. Utilisez Get-AzPublicIpAddress pour retourner l’adresse IP publique d’une
machine virtuelle. L’exemple suivant retourne l’adresse IP publique de la machine
virtuelle myVm1 :
Azure PowerShell
-Name myVm1 `
-ResourceGroupName myResourceGroup | Select IpAddress
virtuelle myVm1 à partir de votre ordinateur local. Remplacez <publicIpAddress> par
l’adresse IP retournée par la commande précédente.
Un fichier .rdp (Remote Desktop Protocol) est créé, téléchargé sur votre ordinateur, puis
ouvert. Entrez le nom d’utilisateur et le mot de passe (il se peut que vous deviez choisir
Plus de choix, puis Utiliser un compte différent pour spécifier les informations
d’identification que vous avez entrées lors de la création de la machine virtuelle), puis
cliquez sur OK. Un avertissement de certificat peut s’afficher pendant le processus de
connexion. Cliquez sur Oui ou Continuer pour continuer le processus de connexion.
Sur la machine virtuelle myVm1, autorisez le protocole ICMP (Internet Control Message
Protocol) à travers le pare-feu Windows afin d’effectuer un test ping pour cette machine
virtuelle à partir de myVm2 lors d’une étape ultérieure, en utilisant PowerShell :
PowerShell
Bien que ce test ping soit utilisé pour établir une communication entre les machines
virtuelles, il n’est pas recommandé d’autoriser le protocole IMCP via le pare-feu
Windows lors de déploiements de production.
Pour établir une connexion avec la machine virtuelle myVm2, entrez la commande
suivante à partir d’une invite de commandes sur la machine virtuelle myVm1 :
mstsc /v:10.1.0.4
Étant donné que vous avez activé la commande ping sur myVm1, vous pouvez
maintenant effectuer un test ping par adresse IP à partir d’une invite de commandes sur
la machine virtuelle myVm2 :
ping 10.0.0.4
Vous recevez quatre réponses. Déconnectez vos sessions RDP sur myVm1 et myVm2.

Lorsque vous n’avez plus besoin d’un groupe de ressources, utilisez Remove-
AzResourcegroup pour le supprimer, ainsi que toutes les ressources qu’il contient.
Azure PowerShell
Étapes suivantes
Dans cet article, vous avez appris à connecter deux réseaux situés dans la même région
Azure à l’aide du peering de réseaux virtuels. Vous pouvez également appairer des
réseaux virtuels situés dans des régions différentes et dans des abonnements Azure
différents. Vous pouvez aussi créer des conceptions réseau hub-and-spoke avec le
peering. Pour en savoir plus sur le peering de réseaux virtuels, consultez Aperçu de
présentation du peering de réseaux virtuels et Gérer les peerings de réseau virtuels.
Vous pouvez connecter votre propre ordinateur à un réseau virtuel via un VPN et
interagir avec les ressources dans un réseau virtuel, ou dans des réseaux virtuels
appairés. Consultez les exemples de script pour obtenir des scripts réutilisables
permettant d’accomplir un grand nombre des tâches présentées dans les articles sur les
réseaux virtuels.
Connecter des réseaux virtuels à l’aide
du peering de réseaux virtuels en
utilisant Azure CLI
Article • 01/06/2023
virtuels. Une fois que les deux réseaux virtuels sont appairés, leurs ressources peuvent
communiquer entre elles avec les mêmes bande passante et latence, comme si elles se
trouvaient sur le même réseau virtuel. Dans cet article, vous apprendrez comment :
Créer deux réseaux virtuels

Connecter deux réseaux virtuels à l’aide du peering de réseaux virtuels
Déployer une machine virtuelle sur chaque réseau virtuel
Établir une communication entre les machines virtuelles
commencer.
Prérequis


upgrade.

ressources avec la commande az group create. L’exemple suivant crée un groupe de
Azure CLI
az group create --name myResourceGroup --location eastus
Créez un réseau virtuel avec la commande az network vnet create. L’exemple suivant
permet de créer un réseau virtuel nommé myVirtualNetwork1 avec le préfixe d’adresse
10.0.0.0/16.
Azure CLI

--name myVirtualNetwork1 \
--address-prefixes 10.0.0.0/16 \
--subnet-name Subnet1 \
Créez un réseau virtuel nommé myVirtualNetwork2 avec le préfixe d’adresse 10.1.0.0/16

:
Azure CLI

--subnet-name Subnet1 \
Les peerings sont établis entre les ID des réseaux virtuels, vous devez donc d’abord
obtenir l’ID de chaque réseau virtuel à l’aide d’az network vnet show et stocker l’ID dans
une variable.
Azure CLI
# Get the id for myVirtualNetwork1.

vNet1Id=$(az network vnet show \
--query id --out tsv)
# Get the id for myVirtualNetwork2.

vNet2Id=$(az network vnet show \
--query id \
--out tsv)
Créez un appairage entre myVirtualNetwork1 et myVirtualNetwork2 à l’aide d’az

network vnet peering create. Si le paramètre --allow-vnet-access n’est pas spécifié, un
peering est établi, mais aucune communication ne peut passer.
Azure CLI
az network vnet peering create \

--name myVirtualNetwork1-myVirtualNetwork2 \
--vnet-name myVirtualNetwork1 \
--remote-vnet $vNet2Id \
--allow-vnet-access
Dans la sortie obtenue après l’exécution de la commande précédente, vous constatez

que le peeringState (état de l’appairage) est Initiated. Le peering reste dans l’état
Initiated jusqu’à ce que vous créiez le peering entre myVirtualNetwork2 et
myVirtualNetwork1. Créez un peering entre myVirtualNetwork2 et myVirtualNetwork1.
Azure CLI

--remote-vnet $vNet1Id \
--allow-vnet-access
Dans la sortie obtenue après l’exécution de la commande précédente, vous constatez
que le peeringState (état de l’appairage) est Connected. Azure a également changé l’état
du peering myVirtualNetwork1-myVirtualNetwork2 en Connected. Confirmez que l’état
de l’appairage de l’appairage myVirtualNetwork1-myVirtualNetwork2 a été changé en
Connected à l’aide de az network vnet peering show.
Azure CLI
az network vnet peering show \

--query peeringState
Les ressources dans un réseau virtuel ne peuvent pas communiquer avec les ressources
dans un autre réseau virtuel avant que le peeringState pour les appairages dans les
deux réseaux virtuels soit Connected.

Créez une machine virtuelle sur chaque réseau virtuel afin de pouvoir établir une
communication entre elles dans une étape ultérieure.

Créez une machine virtuelle avec la commande az vm create. L’exemple suivant crée une
machine virtuelle nommée myVm1 dans le réseau virtuel myVirtualNetwork1. 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’option
--no-wait crée la machine virtuelle en arrière-plan. Vous pouvez donc passer à l’étape
suivante.
Azure CLI
az vm create \
--name myVm1 \
--image UbuntuLTS \
--subnet Subnet1 \
--generate-ssh-keys \
--no-wait
Créez une machine virtuelle dans le réseau virtuel myVirtualNetwork2.
Azure CLI
az vm create \
--name myVm2 \
--image UbuntuLTS \
--subnet Subnet1 \
--generate-ssh-keys

Sortie
{
"fqdns": "",
ualMachines/myVm2",
"macAddress": "00-0D-3A-23-9A-49",
}
virtuelle à partir d’Internet dans une prochaine étape.
７ Notes

virtuelles
Utilisez la commande suivante pour créer une session SSH avec la machine virtuelle
myVm2. Remplacez <publicIpAddress> par l’adresse IP publique de votre machine
virtuelle. Dans l’exemple précédent, l’adresse IP publique est 13.90.242.231.
Bash
ssh <publicIpAddress>
Effectuez un test ping pour la machine virtuelle située dans le réseau

myVirtualNetwork1.
Bash
ping 10.0.0.4 -c 4
Vous recevez quatre réponses.
Fermez la session SSH sur la machine virtuelle myVm2.

Azure CLI

Étapes suivantes
Dans cet article, vous avez appris à connecter deux réseaux situés dans la même région
Azure à l’aide du peering de réseaux virtuels. Vous pouvez également appairer des
réseaux virtuels situés dans des régions différentes et dans des abonnements Azure
différents. Vous pouvez aussi créer des conceptions réseau hub-and-spoke avec le
peering. Pour en savoir plus sur le peering de réseaux virtuels, consultez Aperçu de
présentation du peering de réseaux virtuels et Gérer les peerings de réseau virtuels.
Vous pouvez connecter votre propre ordinateur à un réseau virtuel via un VPN et
interagir avec les ressources dans un réseau virtuel, ou dans des réseaux virtuels
appairés. Consultez les exemples de script pour obtenir des scripts réutilisables
permettant d’accomplir un grand nombre des tâches présentées dans les articles sur les
réseaux virtuels.
Créer un appairage de réseau virtuel –
Gestionnaire des ressources,
abonnements et locataires Azure Active
Directory différents
Article • 21/04/2023
Dans ce didacticiel, vous apprendrez à créer un peering de réseaux virtuels entre des
réseaux virtuels créés via Resource Manager. Les réseaux virtuels existent dans des
abonnements différents qui peuvent appartenir à différents locataires Azure Active
Directory (Azure AD). Effectuer le peering de deux réseaux virtuels permet aux
ressources de différents réseaux virtuels de communiquer entre elles avec la même
bande passante et latence, comme si les ressources se trouvaient sur le même réseau
virtuel. En savoir plus sur le peering de réseaux virtuels.
Selon si les réseaux virtuels se trouvent dans le même, ou dans des abonnements
différents, les étapes de création d’un appairage de réseaux virtuels sont différentes. Les
étapes pour homologuer les réseaux créés avec le modèle de déploiement classique
sont différentes. Pour plus d'informations sur les modèles de déploiement, consultez
Modèle de déploiement Azure.
Découvrez comment créer un peering de réseaux virtuels dans d’autres scénarios en

sélectionnant le scénario souhaité dans le tableau suivant :
Modèle de déploiement Azure Abonnement Azure
Tous deux Resource Manager Identique
Un modèle Resource Manager, un modèle classique Différent
Vous ne pouvez pas créer de peering de réseaux virtuels entre deux réseaux virtuels
déployés via le modèle de déploiement classique. Si vous avez besoin de connecter des
réseaux virtuels tous deux créés par le biais du modèle de déploiement classique, vous
pouvez utiliser une passerelle VPN Azure.
Ce didacticiel permet d’homologuer des réseaux virtuels situés dans la même région.
Vous pouvez également homologuer des réseaux virtuels dans différentes régions prise
en charge. Il est recommandé de vous familiariser avec les exigences et contraintes du
peering avant d’effectuer le peering des réseaux virtuels.
Prérequis
Portail
Un ou plusieurs comptes Azure avec deux abonnements actifs. Créez un

compte gratuitement .
Un compte Azure avec des autorisations dans les deux abonnements ou un

compte dans chaque abonnement avec les autorisations appropriées pour
créer un appairage de réseaux virtuels. Pour obtenir une liste d’autorisations,
consultez Autorisations de peering de réseau virtuel.
Pour séparer la responsabilité de la gestion du réseau appartenant à

chaque locataire, ajoutez l’utilisateur de chaque locataire en tant qu’invité
dans le locataire opposé et attribuez-lui un rôle de lecteur au réseau virtuel.
Cette procédure s’applique si les réseaux virtuels se trouvent dans des
abonnements et des locataires Active Directory différents.
Pour établir un peering de réseau quand vous n’avez pas l’intention de

séparer l’obligation de gérer le réseau appartenant à chaque locataire,
ajoutez l’utilisateur du locataire A en tant qu’invité dans le locataire opposé.
Ensuite, attribuez-lui les autorisations appropriées pour lancer et connecter
le peering de réseau à partir de chaque abonnement. Avec ces
autorisations, l’utilisateur est en mesure d’établir le peering de réseau à
partir de chaque abonnement.
Pour plus d’informations sur les utilisateurs invités, consultez Ajouter des
utilisateurs de Collaboration Azure Active Directory B2B dans le portail
Azure.
Chaque utilisateur doit accepter l’invitation d’utilisateur invité du locataire

Azure Active Directory opposé.
Dans les étapes suivantes, apprenez à appairer des réseaux virtuels dans différents
abonnements et locataires Azure Active Directory.
Vous pouvez utiliser le même compte qui dispose d’autorisations dans les deux
abonnements ou vous pouvez utiliser des comptes distincts pour chaque abonnement
pour configurer l’appairage. Un compte disposant d’autorisations dans les deux
abonnements peut effectuer toutes les étapes sans se déconnecter, se connecter au
portail et attribuer des autorisations.
Les ressources et exemples de compte suivants sont utilisés dans les étapes de cet
article :
Compte d’utilisateur Resource group Abonnement Réseau virtuel
UserA myResourceGroupA SubscriptionA myVNetA
UserB myResourceGroupB SubscriptionB myVNetB
Créer un réseau virtuel - myVNetA
７ Notes
Si vous utilisez un seul compte pour effectuer les étapes, vous pouvez ignorer les
étapes de déconnexion du portail et d’attribution d’autres autorisations utilisateur
aux réseaux virtuels.
Portail
1. Connectez-vous au portail Azure en tant que UserA.

4. Sous l’onglet Informations de base de la page Créer un réseau virtuel, entrez

Paramètre Valeur
Détails du projet
Abonnement Sélectionnez votre abonnementA.

Sélectionnez
.
Nom Entrez myVNet.

Paramètre Valeur
Région Sélectionnez une région.
5. Sélectionnez Suivant : Adresses IP.
6. Dans Espace d’adressage IPv4, entrez 10.1.0.0/16.
Paramètre Valeur
Nom du sous-réseau Entrez mySubnet.
10. Sélectionnez Revoir + créer.
Attribuer des autorisations pour UserB

Un compte d’utilisateur dans l’autre abonnement que vous souhaitez appairer doit être
ajouté au réseau que vous avez créé précédemment. Si vous utilisez un seul compte
pour les deux abonnements, vous pouvez ignorer cette section.
Portail
1. Restez connecté au portail en tant que UserA.

3. Sélectionnez myVNetA.
4. Sélectionnez Contrôle d’accès (IAM) .
5. Sélectionner + Ajouter ->Ajouter une attribution de rôle.

6. Dans Ajouter une attribution de rôle sous l’onglet Rôle, sélectionnez
Contributeur réseau.
7. Sélectionnez Suivant.
8. Sous l’onglet Membres, sélectionnez Sélectionner des membres.
9. Dans Sélectionner des membres dans la zone de recherche, entrez UserB.
10. Sélectionnez Sélectionner.
11. Sélectionnez Vérifier + attribuer.
Obtenir l’ID de ressource de myVNetA

Portail
1. Restez connecté au portail en tant que UserA.

4. Dans Paramètres, sélectionnez Propriétés.
5. Copiez les informations dans le champ ID de ressource et enregistrez-les pour

les étapes suivantes. L’ID de la ressource ressemble à celui de l’exemple qui
suit : /subscriptions/<Subscription
Id>/resourceGroups/myResourceGroupA/providers/Microsoft.Network/virtualNet
works/myVnetA .
6. Déconnectez-vous du portail en tant que UserA.
Créer un réseau virtuel - myVNetB

Dans cette section, vous vous connectez en tant que UserB et créez un réseau virtuel
pour la connexion de peering à myVNetA.
Portail
1. Connectez-vous au portail en tant que UserB. Si vous utilisez un compte pour

les deux abonnements, remplacez par SubscriptionB dans le portail.

4. Sous l’onglet Informations de base de la page Créer un réseau virtuel, entrez

Paramètre Valeur
Détails du projet
Abonnement Sélectionnez votre AbonnementB.

Entrez myResourceGroupB dans Nom.
Sélectionnez
.
Nom Entrez myVNetB.
Paramètre Valeur
Plage d’adresses de sous-réseau Saisissez 10.2.0.0/24.

Attribuer des autorisations pour UserA

Un compte d’utilisateur dans l’autre abonnement que vous souhaitez appairer doit être
ajouté au réseau que vous avez créé précédemment. Si vous utilisez un seul compte
pour les deux abonnements, vous pouvez ignorer cette section.
Portail
1. Restez connecté au portail en tant que UserB.

3. Sélectionnez myVNetB.
4. Sélectionnez Contrôle d’accès (IAM) .
5. Sélectionner + Ajouter ->Ajouter une attribution de rôle.
6. Dans Ajouter une attribution de rôle sous l’onglet Rôle, sélectionnez

Contributeur réseau.
7. Sélectionnez Suivant.
8. Sous l’onglet Membres, sélectionnez Sélectionner des membres.
9. Dans Sélectionner des membres dans la zone de recherche, entrez UserA.
10. Sélectionnez Sélectionner.
Obtenir l’ID de ressource de myVNetB

L’ID de ressource de myVNetB est requis pour configurer la connexion homologue de
myVNetA à myVNetB. Utilisez les étapes suivantes pour obtenir les ID de la ressource
myVNetB.
Portail
1. Restez connecté au portail en tant que UserB.

4. Dans Paramètres, sélectionnez Propriétés.
5. Copiez les informations dans le champ ID de ressource et enregistrez-les pour

les étapes suivantes. L’ID de la ressource ressemble à celui de l’exemple qui
suit : /subscriptions/<Subscription
Id>/resourceGroups/myResourceGroupB/providers/Microsoft.Network/virtualNet
works/myVnetB .
6. Déconnectez-vous du portail en tant que UserB.
Créer une connexion de peering - myVNetA à

myVNetB
Vous avez besoin de l’ID de ressource pour myVNetB des étapes précédentes pour
configurer la connexion de peering.
Portail
1. Connectez-vous au portail Azure en tant que UserA. Si vous utilisez un

compte pour les deux abonnements, remplacez par SubscriptionA dans le
portail.

4. Sélectionnez Peerings.
6. Dans Ajouter peering, entrez ou sélectionnez les informations suivantes :

Paramètre Valeur
Ce réseau virtuel
Nom du lien de peering Entrez myVNetAToMyVNetB.
Trafic vers le réseau virtuel distant Conservez la valeur par défaut Autoriser
(par défaut).
Trafic transféré à partir du réseau Conservez la valeur par défaut Autoriser

virtuel distant (par défaut).
Passerelle ou serveur de routes de Conservez la valeur par défaut Aucun (par

réseau virtuel défaut).
Réseau virtuel distant
Nom du lien de peering Laisser vide.
Modèle de déploiement de réseau Sélectionnez Resource Manager.

virtuel
Cochez la case je connais mon ID de

ressource.
ID de ressource Entrez ou collez l’ID de ressource pour

myVNetB.
7. Dans la zone déroulante, sélectionnez le répertoire qui correspond à

myVNetB et UserB.
8. Sélectionnez Authentifier.
10. Déconnectez-vous du portail en tant que UserA.
La connexion de peering s’affiche dans Peerings dans un état Initié. Pour terminer
l’homologue, une connexion correspondante doit être configurée dans myVNetB.
Créer une connexion de peering - myVNetB à

myVNetA
Vous avez besoin de l’ID de ressource pour myVNetA des étapes précédentes pour
configurer la connexion de peering.
Portail
1. Connectez-vous au Portail Azure en tant que UserB. Si vous utilisez un

compte pour les deux abonnements, remplacez par SubscriptionB dans le
portail.

4. Sélectionnez Peerings.
6. Dans Ajouter peering, entrez ou sélectionnez les informations suivantes :
Paramètre Valeur
Ce réseau virtuel
Nom du lien de peering Entrez myVNetBToMyVNetA.
Trafic vers le réseau virtuel distant Conservez la valeur par défaut Autoriser
(par défaut).
Trafic transféré à partir du réseau Conservez la valeur par défaut Autoriser

virtuel distant (par défaut).
Passerelle ou serveur de routes de Conservez la valeur par défaut Aucun (par

réseau virtuel défaut).
Réseau virtuel distant
Nom du lien de peering Laisser vide.
Modèle de déploiement de réseau Sélectionnez Resource Manager.

virtuel
Cochez la case je connais mon ID de

ressource.
ID de ressource Entrez ou collez l’ID de ressource pour

myVNetA.
7. Dans la zone déroulante, sélectionnez le répertoire qui correspond à

myVNetA et UserA.
8. Sélectionnez Authentifier.
Le peering est établi avec succès une fois que vous voyez Connecté dans la colonne État
de peering pour les deux réseaux virtuels du peering. Les ressources Azure que vous
créez dans un réseau virtuel sont désormais en mesure de communiquer entre elles via
leurs adresses IP. Si vous utilisez la résolution de noms Azure par défaut pour les
réseaux virtuels, les ressources des réseaux virtuels ne peuvent pas résoudre les noms
dans les réseaux virtuels. Si vous souhaitez résoudre les noms dans les réseaux virtuels
d’un peering, vous devez créer votre propre serveur DNS ou utiliser Azure DNS.
Pour obtenir plus d’informations sur l'utilisation de votre propre DNS pur la résolution
de noms, voir Résolution de noms à l'aide de votre propre serveur DNS.
Pour plus d’informations sur Azure DNS, consultez Qu’est-ce qu’Azure DNS ?.
Étapes suivantes
Familiarisez-vous bien avec les comportements et contraintes importants du
peering de réseaux virtuels avant d’en créer un pour une utilisation en production.
Apprenez-en davantage sur tous les paramètres de peering de réseaux virtuels.
Découvrez comment créer une topologie de réseau de type hub et spoke avec le
peering de réseaux virtuels.
Créer un peering de réseaux virtuels
Azure - Modèles de déploiement
différents, même abonnement
Dans ce didacticiel, vous allez découvrir comment créer un peering de réseaux virtuels
entre des réseaux virtuels créés par le biais de modèles de déploiement différents. Les
deux réseaux virtuels doivent se trouver dans le même abonnement. Effectuer le peering
de deux réseaux virtuels permet aux ressources de différents réseaux virtuels de
communiquer entre elles avec la même bande passante et latence, comme si les
ressources se trouvaient sur le même réseau virtuel. En savoir plus sur le peering de
réseaux virtuels.
Les étapes de création d’un peering de réseaux virtuels sont différentes, selon que les
réseaux virtuels sont dans le même abonnement ou dans des abonnements différents,
et selon le modèle de déploiement Azure utilisé pour les créer. Découvrez comment
créer un peering de réseaux virtuels dans d’autres scénarios en cliquant sur le scénario
souhaité dans le tableau suivant :
Tous deux Resource Manager Différent
Un modèle Resource Manager, un modèle classique Différent
déployés via le modèle de déploiement classique. Si vous avez besoin de connecter des
réseaux virtuels tous deux créés par le biais du modèle de déploiement classique, vous
pouvez utiliser une passerelle VPN Azure.
Ce didacticiel permet d’homologuer des réseaux virtuels situés dans la même région.
Vous pouvez également homologuer des réseaux virtuels dans différentes régions prise
en charge. Il est recommandé de vous familiariser avec les exigences et contraintes du
peering avant d’effectuer le peering des réseaux virtuels.
Pour créer un appairage de réseaux virtuels, vous pouvez utiliser le portail Azure, Azure
CLI, Azure PowerShell ou un modèle Azure Resource Manager. Cliquez sur les liens des
outils précédents pour accéder directement à la procédure permettant de créer un
peering de réseaux virtuels à l’aide de l’outil de votre choix.
Créer un peering - portail Azure
1. Connectez-vous au portail Azure . Le compte auquel vous vous connectez doit
avoir les autorisations nécessaires pour créer un peering de réseaux virtuels. Pour
obtenir une liste d’autorisations, consultez Autorisations de peering de réseau
virtuel.
2. Cliquez sur + Nouveau, puis sur Mise en réseau et Réseau virtuel.
3. Dans le panneau Créer un réseau virtuel, entrez ou sélectionnez les valeurs des
paramètres suivants, puis cliquez sur Créer :
Nom : myVnet1
Espace d’adressage : 10.0.0.0/16
Nom du sous-réseau : par défaut
Plage d’adresses de sous-réseau : 10.0.0.0/24
Abonnement: Sélectionnez votre abonnement
Groupe de ressources : Sélectionnez Créer et entrez myResourceGroup.
Emplacement : USA Est
4. Cliquez sur + Nouveau. Dans le champ Rechercher dans le marketplace, tapez

Réseau virtuel. Quand la mention Réseau virtuel apparaît dans les résultats de la
recherche, cliquez dessus.
5. Dans le panneau Réseau virtuel, sélectionnez Classique dans la zone Sélectionnez

un modèle de déploiement, puis cliquez sur Créer.
Nom : myVnet2
Groupe de ressources : Sélectionnez Utiliser l'existant, puis
myResourceGroup
7. Dans le champ Rechercher des ressources située en haut du portail, tapez

myResourceGroup. Cliquez sur myResourceGroup quand il apparaît dans les
résultats de la recherche. Un panneau s’affiche pour le groupe de ressources
myresourcegroup. Le groupe de ressources garde les deux réseaux virtuels créés
dans les étapes précédentes.
8. Cliquez sur myVNet1.
9. Dans le panneau myVnet1 qui s’affiche, cliquez sur Peerings dans la liste verticale
des options sur le côté gauche du panneau.
10. Dans le panneau myVnet1 - Peerings qui s’est affiché, cliquez sur + Ajouter.
11. Dans le panneau Ajouter le peering qui s’affiche, entrez ou sélectionnez les
options suivantes et cliquez sur OK :
Nom : myVnet1ToMyVnet2
Modèle de déploiement de réseau virtuel : sélectionnez Classique.
Réseau virtuel : cliquez sur Choisir un réseau virtuel, puis sur myVnet2.
Autoriser l’accès au réseau virtuel : vérifiez que Activé est sélectionné. Il n’y
aucun autre paramètre utilisé dans ce didacticiel. Pour en savoir plus sur tous
les paramètres d’homologation, consultez Create, change, or delete a virtual
network peering (Créer, modifier ou supprimer une homologation de réseaux
virtuels).
12. Après avoir cliqué sur OK à l’étape précédente, le panneau Ajouter le peering se
ferme et vous pouvez à nouveau voir le panneau myVnet1 - Peerings. Après
quelques secondes, le peering que vous avez créé apparaît dans le panneau.
Connecté est indiqué dans la colonne ÉTAT DE PEERING pour le peering
myVnet1ToMyVnet2 que vous avez créé.
Le peering est maintenant établi. Les ressources Azure que vous créez dans un
réseau virtuel sont désormais en mesure de communiquer entre elles via leurs
adresses IP. Si vous utilisez la résolution de noms Azure par défaut pour les
réseaux virtuels, les ressources des réseaux virtuels ne peuvent pas résoudre les
noms dans les réseaux virtuels. Si vous souhaitez résoudre les noms dans les
réseaux virtuels d’un peering, vous devez créer votre propre serveur DNS.
Apprenez à configurer la résolution de noms à l’aide de votre propre serveur DNS.
13. Facultatif : bien que la création de machines virtuelles ne soit pas abordée dans ce
tutoriel, vous pouvez créer une machine virtuelle sur chaque réseau virtuel et vous
connecter d'une machine virtuelle à l'autre pour valider la connectivité.
14. Facultatif : pour supprimer les ressources créées dans ce tutoriel, effectuez les
étapes décrites dans la section Supprimer des ressources de cet article.
Créer un peering - interface de ligne de
commande Azure
Effectuez les étapes suivantes à l’aide de l’interface Azure Classic CLI et de l’interface
Azure CLI. Vous pouvez effectuer les étapes à partir d’Azure Cloud Shell, en
sélectionnant simplement le bouton Essayer dans toutes les étapes suivantes, ou en
installant l’interface Azure Classic CLI et Azure CLI, puis en exécutant les commandes sur
votre ordinateur local.
1. Si vous utilisez Cloud Shell, passez à l’étape 2, car Cloud Shell vous connecte
automatiquement à Azure. Ouvrez une session de commande et connectez-vous à
Azure à l’aide de la commande azure login .
2. Exécutez l’interface CLI en mode Gestion des services en entrant la commande

azure config mode asm .
3. Entrez la commande suivante pour créer le réseau virtuel (classique) :
Azure CLI
azure network vnet create --vnet myVnet2 --address-space 10.1.0.0 --

cidr 16 --location "East US"
4. Exécutez le script CLI bash suivant à l’aide d’Azure CLI, et non d’Azure Classic CLI.
Pour connaître les options d’exécution de scripts CLI bash sur un ordinateur
Windows, consultez Installer Azure CLI sur Windows.
Azure CLI
#!/bin/bash

az group create \
--location eastus
# Create the virtual network (Resource Manager).

--name myVnet1 \
--location eastus \
5. Créez un peering entre les deux réseaux virtuels créés par le biais des différents
modèles de déploiement à l’aide de l’interface CLI. Copiez le script suivant dans un
éditeur de texte sur votre PC. Remplacez <subscription id> par votre ID
d’abonnement. Si vous ne connaissez pas votre ID d’abonnement, entrez la
commande az account show . La valeur de id dans la sortie est votre ID
d’abonnement. Collez le script modifié dans votre session CLI, puis appuyez sur
Enter .
Azure CLI
# Get the ID for VNet1.

vnet1Id=$(az network vnet show \
--name myVnet1 \
# Peer VNet1 to VNet2.

--name myVnet1ToMyVnet2 \
--vnet-name myVnet1 \
--remote-vnet-id /subscriptions/<subscription
id>/resourceGroups/Default-
Networking/providers/Microsoft.ClassicNetwork/virtualNetworks/myVnet2 \
--allow-vnet-access
6. Après l’exécution du script, passez en revue le peering pour le réseau virtuel

(Resource Manager). Copiez la commande suivante, collez-la dans votre session
CLI, puis appuyez sur Enter :
Azure CLI
az network vnet peering list \

--vnet-name myVnet1 \
--output table
La sortie indique Connecté dans la colonne État de peering.
Les ressources Azure que vous créez dans un réseau virtuel sont désormais en
mesure de communiquer entre elles via leurs adresses IP. Si vous utilisez la
résolution de noms Azure par défaut pour les réseaux virtuels, les ressources des
réseaux virtuels ne peuvent pas résoudre les noms dans les réseaux virtuels. Si
vous souhaitez résoudre les noms dans les réseaux virtuels d’un peering, vous
devez créer votre propre serveur DNS. Apprenez à configurer la résolution de
Créer un peering - PowerShell

1. Installez la dernière version des modules PowerShell Azure et Az . Si vous
débutez dans l’utilisation d’Azure PowerShell, voir Vue d’ensemble d’Azure
PowerShell.
2. Démarrez une session PowerShell.
3. Dans PowerShell, connectez-vous à Azure en entrant la commande Add-

AzureAccount . Le compte auquel vous vous connectez doit avoir les autorisations
nécessaires pour créer un peering de réseaux virtuels. Pour obtenir une liste
d’autorisations, consultez Autorisations de peering de réseau virtuel.
4. Pour créer un réseau virtuel (classique) avec PowerShell, vous devez créer un fichier
de configuration réseau ou en modifier un existant. Pour découvrir comment
exporter, mettre à jour et importer des fichiers de configuration réseau, consultez
cet article. Le fichier doit inclure l’élément VirtualNetworkSite suivant pour le
réseau virtuel utilisé dans ce didacticiel :
XML
<VirtualNetworkSite name="myVnet2" Location="East US">

<AddressSpace>
<AddressPrefix>10.1.0.0/16</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="default">
</Subnet>
</Subnets>
</VirtualNetworkSite>
２ Avertissement
L’importation d’un fichier de configuration réseau modifié peut entraîner des

modifications des réseaux virtuels (classiques) existants dans votre
abonnement. Assurez-vous de n’ajouter que le réseau virtuel précédent et de
ne modifier ou supprimer aucun réseau virtuel existant de votre abonnement.
5. Connectez-vous à Azure pour créer le réseau virtuel (Resource Manager) en

entrant la commande Connect-AzAccount . Le compte auquel vous vous connectez
doit avoir les autorisations nécessaires pour créer un peering de réseaux virtuels.
Pour obtenir une liste d’autorisations, consultez Autorisations de peering de réseau
virtuel.
6. Créez un groupe de ressources et un réseau virtuel (Resource Manager). Copiez le

script, collez-le dans PowerShell, puis appuyez sur Enter .
PowerShell

New-AzResourceGroup -Name myResourceGroup -Location eastus
# Create the virtual network (Resource Manager).

$vnet1 = New-AzVirtualNetwork `
-Name 'myVnet1' `
-AddressPrefix '10.0.0.0/16' `
-Location eastus
7. Créez un peering de réseaux virtuels entre les deux réseaux virtuels créés par le
biais des modèles de déploiement différents. Copiez le script suivant dans un
éditeur de texte sur votre PC. Remplacez <subscription id> par votre ID
commande Get-AzSubscription pour l’afficher. La valeur de id dans la sortie
retournée est votre ID d’abonnement. Pour exécuter le script, copiez le script
modifié à partir de votre éditeur de texte, cliquez avec le bouton droit dans votre
session PowerShell, puis appuyez sur Enter .
PowerShell

-Name myVnet1ToMyVnet2 `
-VirtualNetwork $vnet1 `
-RemoteVirtualNetworkId /subscriptions/<subscription
Id>/resourceGroups/Default-
Networking/providers/Microsoft.ClassicNetwork/virtualNetworks/myVnet2

(Resource Manager). Copiez la commande suivante, collez-la dans votre session
PowerShell, puis appuyez sur Enter :
PowerShell
-VirtualNetworkName myVnet1 `
| Format-Table VirtualNetworkName, PeeringState
résolution de noms Azure par défaut pour les réseaux virtuels, les ressources des
réseaux virtuels ne peuvent pas résoudre les noms dans les réseaux virtuels. Si
vous souhaitez résoudre les noms dans les réseaux virtuels d’un peering, vous
devez créer votre propre serveur DNS. Apprenez à configurer la résolution de
Supprimer des ressources

Lorsque vous aurez terminé ce didacticiel, vous souhaiterez peut-être supprimer les
ressources que vous avez créées, afin que leur utilisation ne soit pas facturée. La
suppression d’un groupe de ressources supprime également toutes les ressources qu’il
contient.
Portail Azure
1. Dans le champ de recherche du portail, entrez myResourceGroup. Dans les
résultats de la recherche, cliquez sur myResourceGroup.
2. Dans le panneau myResourceGroup, cliquez sur l’icône Supprimer.
3. Pour confirmer la suppression, dans le champ TAPEZ LE NOM DU GROUPE DE
RESSOURCES : , entrez myResourceGroup, puis cliquez sur Supprimer.
Azure CLI
1. Utilisez Azure CLI pour supprimer le réseau virtuel (Resource Manager) avec la
commande suivante :
Azure CLI
2. Utilisez l’interface CLI classique pour supprimer le réseau virtuel (classique) avec les
commandes suivantes :
Azure CLI
azure config mode asm
azure network vnet delete --vnet myVnet2 --quiet
PowerShell
1. Entrez la commande suivante pour supprimer le réseau virtuel (Resource
Manager) :
PowerShell
2. Pour supprimer le réseau virtuel (classique) avec PowerShell, vous devez modifier
un fichier de configuration réseau existant. Pour découvrir comment exporter,
mettre à jour et importer des fichiers de configuration réseau, consultez cet article.
Supprimez l’élément VirtualNetworkSite suivant pour le réseau virtuel utilisé dans
ce didacticiel :
XML
<VirtualNetworkSite name="myVnet2" Location="East US">

<AddressSpace>
</AddressSpace>
<Subnets>
</Subnet>
</Subnets>
２ Avertissement

abonnement. Assurez-vous de ne supprimer que le réseau virtuel précédent
et de ne modifier ou supprimer aucun réseau virtuel existant de votre
abonnement.
Étapes suivantes
Créer un peering de réseaux virtuels
Azure - Modèles de déploiement et
abonnements différents
Dans ce didacticiel, vous allez découvrir comment créer un peering de réseaux virtuels
entre des réseaux virtuels créés par le biais de modèles de déploiement différents. Les
réseaux virtuels existent dans des abonnements différents. Effectuer le peering de deux
réseaux virtuels permet aux ressources de différents réseaux virtuels de communiquer
entre elles avec la même bande passante et latence, comme si les ressources se
trouvaient sur le même réseau virtuel. En savoir plus sur le peering de réseaux virtuels.
Les étapes de création d’un peering de réseaux virtuels sont différentes, selon que les
réseaux virtuels sont dans le même abonnement ou dans des abonnements différents,
et selon le modèle de déploiement Azure utilisé pour les créer. Découvrez comment
créer un peering de réseaux virtuels dans d’autres scénarios en cliquant sur le scénario
souhaité dans le tableau suivant :
Tous deux Resource Manager Différent
déployés via le modèle de déploiement classique. Ce didacticiel utilise des réseaux
virtuels situés dans la même région. Ce didacticiel permet d’homologuer des réseaux
virtuels situés dans la même région. Vous pouvez également homologuer des réseaux
virtuels dans différentes régions prise en charge. Il est recommandé de vous familiariser
avec les exigences et contraintes du peering avant d’effectuer le peering des réseaux
virtuels.
Lors de la création d’un appairage de réseaux virtuels entre des réseaux virtuels dans
différents abonnements, ceux-ci peuvent être associés au même locataire Azure Active
Directory. Si vous n’avez pas encore de locataire Azure Active Directory, vous pouvez
rapidement en créer un.
Vous pouvez utiliser le portail Azure, Azure CLI ou Azure PowerShell pour créer un
appairage de réseaux virtuels. Cliquez sur les liens des outils précédents pour accéder
directement à la procédure permettant de créer un peering de réseaux virtuels à l’aide
de l’outil de votre choix.
Créer un peering - portail Azure

Ce didacticiel utilise des comptes différents pour chaque abonnement. Si vous utilisez
un compte qui a des autorisations pour les deux abonnements, vous pouvez utiliser le
même compte pour toutes les étapes, ignorer les étapes de déconnexion du portail et
ignorer les étapes d’affectation d’autorisations d’accès aux réseaux virtuels à un autre
utilisateur.
1. Connectez-vous au portail Azure en tant que UserA. Le compte auquel vous

vous connectez doit avoir les autorisations nécessaires pour créer un peering de
réseaux virtuels. Pour obtenir une liste d’autorisations, consultez Autorisations de
peering de réseau virtuel.
2. Cliquez sur + Nouveau, puis sur Mise en réseau et Réseau virtuel.
Nom : myVnetA
Abonnement: sélectionnez l’abonnement A.
Groupe de ressources : sélectionnez Créer et entrez myResourceGroupA.

myVnetA. Quand la mention myVnetA apparaît dans les résultats de recherche,
cliquez dessus. Un panneau apparaît pour le réseau virtuel myVnetA.
5. Dans le panneau myVnetA qui apparaît, cliquez sur Contrôle d’accès (IAM) dans la
liste verticale des options sur le côté gauche du panneau.
6. Dans le panneau myVnetA - Contrôle d’accès (IAM) qui apparaît, cliquez sur +
Ajouter une attribution de rôle.
7. Dans le panneau Ajouter une attribution de rôle qui s’affiche, sélectionnez

Contributeur de réseaux dans le champ Rôle.
8. Dans la zone Sélectionner, sélectionnez UserB ou tapez l’adresse e-mail de UserB

pour le rechercher. La liste des utilisateurs affichée provient du même locataire
Azure Active Directory que le réseau virtuel pour lequel vous configurez le peering.
Cliquez sur UserB quand il apparaît dans la liste.
9. Cliquez sur Enregistrer.
10. Déconnectez-vous du portail en tant que UserA, puis connectez-vous en tant que
UserB.
11. Cliquez sur + Nouveau, tapez réseau virtuel dans la zone Rechercher dans le
marketplace, puis cliquez sur Réseau virtuel dans les résultats de recherche.
12. Dans le panneau Réseau virtuel qui s’affiche, sélectionnez Classique dans la zone
Sélectionnez un modèle de déploiement, puis cliquez sur Créer.
13. Dans la zone Créer un réseau virtuel (classique) qui s’affiche, entrez les valeurs
suivantes :
Nom : myVnetB
Abonnement: sélectionnez l’abonnement B.
Groupe de ressources : sélectionnez Créer et entrez myResourceGroupB.
myVnetB. Quand la mention myVnetB apparaît dans les résultats de recherche,
cliquez dessus. Un panneau apparaît pour le réseau virtuel myVnetB.
15. Dans le panneau myVnetB qui s’affiche, cliquez sur Propriétés dans la liste
verticale des options sur le côté gauche du panneau. Copiez l’ID de ressource, qui
vous servira lors d’une étape ultérieure. L’ID de la ressource ressemble à celui de
l’exemple qui suit : /subscriptions/<Subscription
ID>/resourceGroups/myResourceGroupB/providers/Microsoft.ClassicNetwork/virtual
Networks/myVnetB
16. Effectuez les étapes 5 à 9 pour myVnetB, en entrant UserA à l’étape 8.
17. Déconnectez-vous du portail en tant que UserB, puis connectez-vous en tant que
UserA.
myVnetA. Quand la mention myVnetA apparaît dans les résultats de recherche,
cliquez dessus. Un panneau apparaît pour le réseau virtuel myVnet.
19. Cliquez sur myVnetA.
20. Dans le panneau myVnetA qui s’affiche, cliquez sur Peerings dans la liste verticale
des options sur le côté gauche du panneau.
21. Dans le panneau myVnetA - Peerings qui s’est affiché, cliquez sur + Ajouter.
22. Dans le panneau Ajouter le peering qui s’affiche, entrez ou sélectionnez les
options suivantes et cliquez sur OK :
Nom : myVnetAToMyVnetB
Modèle de déploiement de réseau virtuel : sélectionnez Classique.
Je connais mon ID de ressource : cochez cette case.
ID de ressource : entrez l’ID de ressource de myVnetB noté à l’étape 15.
Autoriser l’accès au réseau virtuel : vérifiez que Activé est sélectionné. Il n’y
aucun autre paramètre utilisé dans ce didacticiel. Pour en savoir plus sur tous
les paramètres d’homologation, consultez Create, change, or delete a virtual
network peering (Créer, modifier ou supprimer une homologation de réseaux
virtuels).
23. Après avoir cliqué sur OK à l’étape précédente, le panneau Ajouter le peering se
ferme et vous pouvez à nouveau voir le panneau myVnetA - Peerings. Après
quelques secondes, le peering que vous avez créé apparaît dans le panneau.
Connecté est indiqué dans la colonne ÉTAT DE PEERING pour le peering
myVnetAToMyVnetB que vous avez créé. Le peering est maintenant établi. Il n’est
pas nécessaire d’homologuer le réseau virtuel (classique) au réseau virtuel
(Resource Manager).
résolution de noms Azure par défaut pour les réseaux virtuels, les ressources dans
les réseaux virtuels ne sont pas en mesure de résoudre les noms dans les réseaux
virtuels. Si vous souhaitez résoudre les noms dans les réseaux virtuels d’un peering,
vous devez créer votre propre serveur DNS. Apprenez à configurer la résolution de
connecter d’une machine virtuelle à l’autre pour valider la connectivité.
Créer un peering - interface de ligne de
commande Azure
même compte pour toutes les étapes, ignorer les étapes de déconnexion d’Azure et
supprimer les lignes de script qui créent les affectations de rôle utilisateur. Remplacez
UserA@azure.com et UserB@azure.com dans tous les scripts suivants par les noms
d’utilisateurs que vous utilisez pour UserA et UserB. Effectuez les étapes suivantes à
l’aide de l’interface Azure Classic CLI et de l’interface Azure CLI. Vous pouvez effectuer
les étapes à partir d’Azure Cloud Shell, en sélectionnant simplement le bouton Essayer
dans toutes les étapes suivantes, ou en installant l’interface Azure Classic CLI et Azure
CLI, puis en exécutant les commandes sur votre ordinateur local.
1. Si vous utilisez Cloud Shell, passez à l’étape 2, car Cloud Shell vous connecte
automatiquement à Azure. Ouvrez une session de commande et connectez-vous à
Azure à l’aide de la commande azure login .
2. Exécutez l’interface CLI classique en mode Gestion des services en entrant la

commande azure config mode asm .
3. Entrez la commande CLI classique suivante pour créer le réseau virtuel (classique) :
Console
azure network vnet create --vnet myVnetB --address-space 10.1.0.0 --

cidr 16 --location "East US"
4. Les étapes restantes doivent être effectuées à l’aide d’un interpréteur de

commandes Bash avec l’interface Azure CLI (pas la classique).
5. Copiez le script suivant dans un éditeur de texte sur votre PC. Remplacez
<SubscriptionB-Id> par votre ID d’abonnement. Si vous ne connaissez pas votre ID
d’abonnement, entrez la commande az account show . La valeur de id dans la sortie

est votre ID d’abonnement. Copiez le script modifié, collez-le dans votre session
CLI, puis appuyez sur Enter .
Azure CLI
az role assignment create \

--assignee UserA@azure.com \
--role "Classic Network Contributor" \
--scope /subscriptions/<SubscriptionB-Id>/resourceGroups/Default-
Networking/providers/Microsoft.ClassicNetwork/virtualNetworks/myVnetB
Quand vous avez créé le réseau virtuel (classique) à l’étape 4, Azure a créé le
réseau virtuel dans le groupe de ressources Default-Networking.
6. Déconnectez UserB d’Azure et connectez-vous en tant que UserA dans l’interface

CLI.
7. Créez un groupe de ressources et un réseau virtuel (Resource Manager). Copiez le

script suivant, collez-le dans votre session CLI, puis appuyez sur Enter .
Azure CLI
#!/bin/bash
# Variables for common values used throughout the script.

rgName="myResourceGroupA"
location="eastus"

az group create \
--name $rgName \
--location $location
# Create virtual network A (Resource Manager).

--name myVnetA \
--resource-group $rgName \
--location $location \
# Get the id for myVnetA.

vNetAId=$(az network vnet show \
--name myVnetA \
# Assign UserB permissions to myVnetA.

az role assignment create \
--assignee UserB@azure.com \
--role "Network Contributor" \
--scope $vNetAId
8. Créez un peering de réseaux virtuels entre les deux réseaux virtuels créés par le
biais des modèles de déploiement différents. Copiez le script suivant dans un
éditeur de texte sur votre PC. Remplacez <SubscriptionB-id> par votre ID
commande az account show . La valeur de id dans la sortie est votre ID
d’abonnement. Azure a créé le réseau virtuel (classique) que vous avez créé à
l’étape 4 dans un groupe de ressources nommé Default-Networking. Collez le
script modifié dans votre session CLI, puis appuyez sur Enter .
Azure CLI

--name myVnetAToMyVnetB \
--vnet-name myVnetA \
--remote-vnet /subscriptions/<SubscriptionB-
Networking/providers/Microsoft.ClassicNetwork/virtualNetworks/myVnetB \
--allow-vnet-access

(Resource Manager). Copiez le script suivant et collez-le dans votre session CLI :
Azure CLI
az network vnet peering list \

--vnet-name myVnetA \
--output table
Créer un peering - PowerShell

même compte pour toutes les étapes, ignorer les étapes de déconnexion d’Azure et
supprimer les lignes de script qui créent les affectations de rôle utilisateur. Remplacez
UserA@azure.com et UserB@azure.com dans tous les scripts suivants par les noms
d’utilisateurs que vous utilisez pour UserA et UserB.
1. Installez la dernière version des modules PowerShell Azure et Az . Si vous

débutez dans l’utilisation d’Azure PowerShell, voir Vue d’ensemble d’Azure
PowerShell.
2. Démarrez une session PowerShell.
3. Dans PowerShell, connectez-vous à l’abonnement de UserB en tant que UserB en

entrant la commande Add-AzureAccount . Le compte auquel vous vous connectez
doit avoir les autorisations nécessaires pour créer un peering de réseaux virtuels.
Pour obtenir une liste d’autorisations, consultez Autorisations de peering de réseau
virtuel.
4. Pour créer un réseau virtuel (classique) avec PowerShell, vous devez créer un fichier
de configuration réseau ou en modifier un existant. Pour découvrir comment
exporter, mettre à jour et importer des fichiers de configuration réseau, consultez
cet article. Le fichier doit inclure l’élément VirtualNetworkSite suivant pour le
réseau virtuel utilisé dans ce didacticiel :
XML
<VirtualNetworkSite name="myVnetB" Location="East US">

<AddressSpace>
</AddressSpace>
<Subnets>
</Subnet>
</Subnets>
２ Avertissement

abonnement. Assurez-vous de n’ajouter que le réseau virtuel précédent et de
ne modifier ou supprimer aucun réseau virtuel existant de votre abonnement.
5. Connectez-vous à l’abonnement de UserB en tant que UserB pour utiliser les
commandes de Resource Manager en entrant la commande Connect-AzAccount .
6. Affectez à UserA des autorisations sur le réseau virtuel B. Copiez le script suivant
dans un éditeur de texte sur votre PC et remplacez <SubscriptionB-id> par l’ID de
l’abonnement B. Si vous ne connaissez pas l’ID d’abonnement, entrez la
retournée est votre ID d’abonnement. Azure a créé le réseau virtuel (classique) que
vous avez créé à l’étape 4 dans un groupe de ressources nommé Default-
Networking. Pour exécuter le script, copiez le script modifié, collez-le dans
PowerShell, puis appuyez sur Enter .
PowerShell
New-AzRoleAssignment `
-SignInName UserA@azure.com `
-RoleDefinitionName "Classic Network Contributor" `
-Scope /subscriptions/<SubscriptionB-id>/resourceGroups/Default-
7. Déconnectez-vous d’Azure en tant que UserB et connectez-vous à l’abonnement

de UserA en tant que UserA en entrant la commande Connect-AzAccount . Le
compte auquel vous vous connectez doit avoir les autorisations nécessaires pour
créer un peering de réseaux virtuels. Pour obtenir une liste d’autorisations,
consultez Autorisations de peering de réseau virtuel.
8. Créez le réseau virtuel (Resource Manager) en copiant le script suivant, en le

collant dans PowerShell, puis en appuyant sur Enter :
PowerShell
# Variables for common values

$rgName='MyResourceGroupA'
$location='eastus'

New-AzResourceGroup `
-Name $rgName `
-Location $location
# Create virtual network A.

$vnetA = New-AzVirtualNetwork `
-ResourceGroupName $rgName `
-Name 'myVnetA' `
-AddressPrefix '10.0.0.0/16' `
-Location $location
9. Affectez à UserB des autorisations sur myVnetA. Copiez le script suivant dans un
éditeur de texte sur votre PC et remplacez <SubscriptionA-Id> par l’ID de
l’abonnement A. Si vous ne connaissez pas l’ID d’abonnement, entrez la
retournée est votre ID d’abonnement. Collez la version modifiée du script
PowerShell, puis appuyez sur Enter pour l’exécuter.
PowerShell
New-AzRoleAssignment `
-SignInName UserB@azure.com `
-RoleDefinitionName "Network Contributor" `
-Scope /subscriptions/<SubscriptionA-
Id>/resourceGroups/myResourceGroupA/providers/Microsoft.Network/Virtual
Networks/myVnetA
10. Copiez le script suivant dans un éditeur de texte sur votre ordinateur, puis
remplacez <SubscriptionB-id> par l’ID de l’abonnement B. Pour homologuer
myVnetA à myVNetB, copiez le script modifié, collez-le dans PowerShell, puis
appuyez sur Enter .
PowerShell
-Name 'myVnetAToMyVnetB' `
-VirtualNetwork $vnetA `
-RemoteVirtualNetworkId /subscriptions/<SubscriptionB-
11. Affichez l’état de peering de myVnetA en copiant le script suivant, en le collant

dans PowerShell et en appuyant sur Enter .
PowerShell
-ResourceGroupName $rgName `
-VirtualNetworkName myVnetA `
| Format-Table VirtualNetworkName, PeeringState
L’état est Connecté. Il devient Connecté une fois que vous avez configuré le
peering à myVnetA à partir de myVnetB.
Supprimer des ressources

Lorsque vous aurez terminé ce didacticiel, vous souhaiterez peut-être supprimer les
ressources que vous avez créées, afin que leur utilisation ne soit pas facturée. La
suppression d’un groupe de ressources supprime également toutes les ressources qu’il
contient.
Portail Azure
1. Dans le champ de recherche du portail, entrez myResourceGroupA. Dans les
résultats de la recherche, cliquez sur myResourceGroupA.
2. Dans le panneau myResourceGroupA, cliquez sur l’icône Supprimer.
3. Pour confirmer la suppression, dans le champ Tapez le nom du groupe de
ressources, entrez myResourceGroupA, puis cliquez sur Supprimer.
myVnetB. Quand la mention myVnetB apparaît dans les résultats de recherche,
cliquez dessus. Un panneau apparaît pour le réseau virtuel myVnetB.
5. Dans le panneau myVnetB, cliquez sur Supprimer.
6. Pour confirmer la suppression, cliquez sur Oui dans la zone Supprimer le réseau
virtuel.
Azure CLI
1. Connectez-vous à Azure à l’aide de l’interface CLI pour supprimer le réseau virtuel
(Resource Manager) avec la commande suivante :
Azure CLI
az group delete --name myResourceGroupA --yes
2. Connectez-vous à Azure à l’aide de l’interface Azure classique pour supprimer le

réseau virtuel (classique) avec les commandes suivantes :
Console
azure config mode asm
azure network vnet delete --vnet myVnetB --quiet
PowerShell
1. À l’invite de commandes PowerShell, entrez la commande suivante pour supprimer
le réseau virtuel (Resource Manager) :
PowerShell
Remove-AzResourceGroup -Name myResourceGroupA -Force
2. Pour supprimer le réseau virtuel (classique) avec PowerShell, vous devez modifier
un fichier de configuration réseau existant. Pour découvrir comment exporter,
mettre à jour et importer des fichiers de configuration réseau, consultez cet article.
Supprimez l’élément VirtualNetworkSite suivant pour le réseau virtuel utilisé dans
ce didacticiel :
XML
<VirtualNetworkSite name="myVnetB" Location="East US">

<AddressSpace>
</AddressSpace>
<Subnets>
</Subnet>
</Subnets>
２ Avertissement

abonnement. Assurez-vous de ne supprimer que le réseau virtuel précédent
et de ne modifier ou supprimer aucun réseau virtuel existant de votre
abonnement.
Étapes suivantes
 Documentation
Routage du trafic de réseau virtuel Azure

Découvrez comment Azure achemine le trafic de réseau virtuel, et comment vous pouvez
personnaliser le routage d’Azure.
Créer un appairage de réseaux virtuels entres des abonnements différents - Azure

Virtual Network
Découvrez comment créer un appairage de réseaux virtuels entre des réseaux virtuels créés via
Resource Manager dans des abonnements Azure différents, dans le même locataire Azure Active
Directory ou dans un locataire différent.
Déployer un pare-feu Azure avec plusieurs adresses IP publiques à l’aide de

PowerShell
Dans cet article, vous allez apprendre à déployer un pare-feu Azure avec plusieurs adresses IP
publiques à l’aide d’Azure PowerShell.
Questions fréquentes (FAQ) sur le réseau virtuel Azure

Réponses aux questions les plus fréquemment posées sur les réseaux virtuels Microsoft Azure.
Diagnostiquez un problème de routage sur une machine virtuelle Azure

Découvrez comment diagnostiquer un problème de routage de machine virtuelle en consultant les
itinéraires effectifs d’une machine virtuelle.
Créer, modifier ou supprimer une table de routage Azure

Découvrez où trouver des informations sur le routage du trafic de réseau virtuel et comment créer,
modifier ou supprimer une table de route.
Configurer le transit par passerelle VPN pour le peering de réseaux virtuels - Azure
VPN Gateway
Découvrez comment configurer le transit par passerelle pour le peering de réseaux virtuels, afin de
connecter en toute transparence deux réseaux virtuels Azure en un seul à des fins de connectivité.
Tutoriel : Acheminer le trafic réseau avec une table de routage - Portail Azure
Dans ce didacticiel, découvrez comment acheminer le trafic réseau avec une table de routage à l’aide
du portail Azure.
Afficher 5 de plus
 Entrainement
Module
Créer, modifier ou supprimer un peering
de réseau virtuel
Découvrez comment créer, modifier ou supprimer un peering de réseau virtuel. Le

Peering de réseaux virtuels vous permet de connecter des réseaux virtuels situés dans la
même région ou dans des régions différentes (on parle alors également de Global VNet
Peering) à l’aide du réseau principal Azure. Une fois appairés, les réseaux virtuels
continuent d’être gérés comme des ressources distinctes. Si vous découvrez le peering
de réseaux virtuels, vous trouverez plus d’informations à ce sujet dans l’article Vue
d’ensemble du peering de réseaux virtuels ou en suivant le tutoriel d’appairage de
réseaux virtuels.
Prérequis
Utilisateurs du portail : Connectez-vous au portail Azure avec un compte Azure

qui possède les autorisations nécessaires pour utiliser des appairages.


connecter à Azure avec un compte disposant des autorisations nécessaires pour
utiliser des appairages de réseaux virtuels.
Utilisateurs Azure CLI : Exécutez les commandes dans Azure Cloud Shell ou
exécutez Azure CLI localement à partir de votre ordinateur. Azure Cloud Shell est
vous connecter à Azure avec un compte disposant des autorisations nécessaires
pour utiliser des appairages de réseaux virtuels.
Le compte auquel vous vous connectez ou avec lequel vous vous connectez à Azure doit
disposer du rôle Contributeur de réseaux ou d’un rôle personnalisé dispose des actions
appropriées listées dans Autorisations.
Créer un peering
Avant de créer un peering, familiarisez-vous avec les exigences et contraintes ainsi
qu’avec les autorisations nécessaires.
Portail
1. Dans la zone de recherche située en haut du Portail Azure, entrez Réseaux

virtuels. Quand la mention Réseaux virtuels apparaît dans les résultats de
recherche, sélectionnez-la. Ne sélectionnez pas Réseaux virtuels (classiques) ,
car vous ne pouvez pas créer un peering à partir d’un réseau virtuel déployé
via le modèle de déploiement classique.
2. Sélectionnez dans la liste le réseau virtuel pour lequel vous souhaitez créer un
peering.
3. Sélectionnez Peerings sous le menu Paramètres, puis sélectionnez + Ajouter.
4. Entrez ou sélectionnez des valeurs pour les paramètres suivants, puis

sélectionnez Ajouter.
Paramètres Description
Ce réseau
virtuel
Nom du lien Nom du peering sur ce réseau virtuel. Le nom doit être unique au sein
de peering du réseau virtuel.
Trafic vers le - Sélectionnez Autoriser (par défaut) pour activer la communication

réseau entre les deux réseaux virtuels par le biais du flux VirtualNetwork par
virtuel défaut. L’activation de la communication entre les réseaux virtuels
distant permet aux ressources connectées à l’un ou l’autre des réseaux virtuels
de communiquer entre elles par le biais du réseau privé Azure.
L’étiquette de service VirtualNetwork pour les groupes de sécurité
réseau englobe le réseau virtuel et le réseau virtuel appairé quand ce
paramètre a la valeur Autoriser. Pour en savoir plus sur les étiquettes
de service, consultez Étiquettes de service Azure.
- Sélectionnez Bloquer tout le trafic vers le réseau virtuel distant si
vous ne voulez pas que le trafic soit dirigé vers le réseau virtuel appairé
par défaut. Vous pouvez sélectionner ce paramètre si vous avez un
peering entre deux réseaux virtuels, mais que vous souhaitez parfois
désactiver le flux de trafic par défaut entre les deux. Il se peut que vous
trouviez plus pratique d’activer ou de désactiver les peerings que de
les supprimer et recréer. Quand ce paramètre est sélectionné, le trafic
n’est pas transmis entre les réseaux virtuels appairés par défaut ;
toutefois, le trafic peut quand même continuer à circuler s’il est
explicitement autorisé par le biais d’une règle de groupe de sécurité
réseau incluant les adresses IP ou groupes de sécurité d’application
appropriés.
Remarque :La sélection du paramètre Bloquer tout le trafic vers le

réseau virtuel distant modifie uniquement la définition de l’étiquette de
service VirtualNetwork. Il n’empêche pas complètement le trafic sur la
connexion du pair, comme expliqué dans la description de ce paramètre.
Trafic Sélectionnez Autoriser (par défaut) si vous voulez que le trafic soit
transféré à transféré par une appliance virtuelle réseau d’un réseau virtuel distant
partir du (ne provenant pas du réseau virtuel distant) vers ce réseau virtuel par
réseau le biais d’un peering. Par exemple, considérez trois réseaux virtuels
virtuel nommés Spoke1, Spoke2 et Hub. Un peering existe entre chaque
distant réseau virtuel spoke et le réseau virtuel Hub, mais les peerings
n’existent pas entre les réseaux virtuels spoke. Une appliance virtuelle
réseau est déployée dans le réseau virtuel Hub et des itinéraires définis
par l’utilisateur sont appliqués à chaque réseau virtuel spoke
acheminant le trafic entre les sous-réseaux via l’appliance virtuelle
réseau. Si ce paramètre n’est pas sélectionné pour le peering entre
chaque réseau virtuel spoke et le réseau virtuel Hub, le trafic ne passe
pas entre les réseaux virtuels spoke, car le Hub transfère le trafic entre
les réseaux virtuels. Si l’activation de cette fonctionnalité autorise le
transfert du trafic via le peering, elle n’a pas pour effet de créer des
itinéraires définis par l’utilisateur ou des appliances virtuelles. Les
itinéraires définis par l’utilisateur et les appliances virtuelles sont créés
séparément. Pour en savoir plus, voir Itinéraires définis par l’utilisateur.
REMARQUE :Il est inutile de sélectionner ce paramètre si le trafic est

transféré entre les réseaux virtuels par le biais d’une passerelle VPN
Azure.
Passerelle ou Sélectionnez Utiliser la passerelle ou le serveur de routes de ce

serveur de réseau virtuel :
routes de - Si une passerelle de réseau virtuel est déployée dans ce réseau
réseau virtuel, et si vous souhaitez autoriser le trafic en provenance du réseau
virtuel virtuel appairé via la passerelle. Par exemple, ce réseau virtuel peut être
attaché à un réseau local via une passerelle de réseau virtuel. La
passerelle peut être une passerelle ExpressRoute ou VPN. La sélection
de ce paramètre a pour effet d’autoriser le trafic en provenance du
réseau virtuel appairé à passer par la passerelle déployée dans ce
réseau virtuel pour atteindre le réseau local.
- Si vous avez un serveur de routage déployé dans ce réseau virtuel et
que vous souhaitez que le réseau virtuel homologué communique
avec le serveur de routage pour échanger des itinéraires. Pour plus
d’informations, consultez Serveur de routes Azure.
Si vous sélectionnez Utiliser la passerelle ou le serveur de routes de

ce réseau virtuel, le réseau virtuel appairé ne peut pas avoir de
passerelle configurée. Le paramètre Utiliser la passerelle ou le serveur
de routes du réseau virtuel distant doit être sélectionné pour le
réseau virtuel appairé lors de la configuration du peering de l’autre
réseau virtuel avec ce réseau virtuel. Si vous laissez ce paramètre sur
Aucun (par défaut), le trafic en provenance du réseau virtuel appairé
continue de passer par ce réseau virtuel, mais il ne peut pas passer par
une passerelle de réseau virtuel déployée dans ce réseau virtuel. Si le
peering est entre un réseau virtuel (Resource Manager) et un réseau

virtuel (classique), la passerelle doit se trouver dans le réseau virtuel
(Resource Manager).
En plus de transférer le trafic vers un réseau local, une passerelle VPN

peut transférer le trafic réseau entre les réseaux virtuels qui sont
homologués avec le réseau virtuel dans lequel la passerelle se trouve,
sans que les réseaux virtuels n’aient besoin d’être homologués entre
eux. L’utilisation d’une passerelle VPN pour le transfert du trafic est
utile lorsque vous souhaitez utiliser une passerelle VPN dans un réseau
virtuel Hub (consultez l’exemple de hub-and-spoke décrit pour
Autoriser le trafic transféré) afin d’acheminer le trafic entre des
réseaux virtuels spoke qui ne sont pas appairés. Pour en savoir plus sur
l’autorisation d’utilisation d’une passerelle pour le transit, consultez
Configurer une passerelle VPN pour le transit dans un peering de
réseaux virtuels. Ce scénario nécessite l’implémentation d’itinéraires
définis par l’utilisateur qui spécifient la passerelle de réseau virtuel en
tant que type de tronçon suivant. Pour en savoir plus, voir Itinéraires
définis par l’utilisateur. Vous ne pouvez spécifier une passerelle VPN en
tant que type de tronçon suivant uniquement dans un itinéraire défini
par l’utilisateur, vous ne pouvez pas spécifier une passerelle
ExpressRoute en tant que type de tronçon suivant dans un itinéraire
défini par l’utilisateur.
Sélectionnez Utiliser la passerelle ou le serveur de routes du réseau

virtuel distant :
- Si vous voulez autoriser le trafic en provenance de ce réseau virtuel à
passer par une passerelle de réseau virtuel déployée dans le réseau
virtuel avec lequel vous effectuez l’appairage. Par exemple, le réseau
virtuel avec lequel vous effectuez l’appairage a une passerelle VPN qui
permet la communication avec un réseau local. La sélection de ce
paramètre a pour effet d’autoriser le trafic en provenance de ce réseau
virtuel à passer par la passerelle VPN dans le réseau virtuel appairé.
- Si vous souhaitez que ce réseau virtuel utilise le serveur de routage
distant pour échanger des itinéraires. Pour plus d’informations,
consultez Serveur de routes Azure.
Si vous sélectionnez ce paramètre, une passerelle de réseau virtuel doit

être déployée dans le réseau virtuel appairé et le paramètre Utiliser la
passerelle ou le serveur de routes de ce réseau virtuel doit être
sélectionné. Si vous laissez ce paramètre configuré sur Aucun (par
défaut), le trafic en provenance de ce réseau virtuel peut quand même
parvenir au réseau virtuel appairé, mais il ne peut pas passer par une
passerelle de réseau virtuel dans le réseau virtuel appairé. Un seul
peering pour ce réseau virtuel peut avoir ce paramètre activé.
REMARQUE : Vous ne pouvez pas utiliser de passerelles distantes si une

passerelle est déjà configurée dans votre réseau virtuel. Pour en savoir
plus sur l’utilisation d’une passerelle pour le transit, consultez Configurer

une passerelle VPN pour le transit dans un appairage de réseaux
virtuels.
Réseau
virtuel
distant
Nom du lien Nom du peering sur le réseau virtuel distant. Le nom doit être unique
de peering au sein du réseau virtuel.
Modèle de Sélectionnez le modèle de déploiement utilisé pour déployer le réseau

déploiement virtuel avec lequel vous souhaitez effectuer le peering.
de réseau
virtuel
Je connais Si vous avez accès en lecture au réseau virtuel avec lequel vous
mon ID de souhaitez effectuer le peering, laissez cette case décochée. Si vous
ressource n’avez pas accès en lecture au réseau virtuel ou à l’abonnement avec
lequel vous voulez effectuer l’appairage, cochez cette case. Dans la
zone ID de ressource qui s’affiche lorsque vous cochez la case, entrez
l’ID de ressource complet du réseau virtuel avec lequel vous voulez
effectuer l’appairage. L’ID de ressource que vous entrez doit être celui
d’un réseau virtuel existant dans la même région Azure que ce
réseau virtuel ou dans une autre région Azure prise en charge. L’ID
complet de la ressource ressemble à
/subscriptions/<Id>/resourceGroups/<resource-group-
name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-
name> . Vous pouvez obtenir l’ID de ressource d’un réseau virtuel en
affichant les propriétés de celui-ci. Pour savoir comment afficher les
propriétés d’un réseau virtuel, consultez Gérer des réseaux virtuels. Si
le locataire Azure Active Directory de l’abonnement est différent de
celui de l’abonnement qui a le réseau virtuel à partir duquel vous créez
le peering, ajoutez d’abord un utilisateur de chaque locataire comme
utilisateur invité dans le locataire opposé.
ID de Ce champ apparaît quand vous cochez la case Je connais mon ID de

ressource ressource. L’ID de ressource que vous entrez doit être celui d’un
réseau virtuel existant dans la même région Azure que ce réseau
virtuel ou dans une autre région Azure prise en charge. L’ID complet
de la ressource ressemble à
/subscriptions/<Id>/resourceGroups/<resource-group-
name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-
name> . Vous pouvez obtenir l’ID de ressource d’un réseau virtuel en
affichant les propriétés de celui-ci. Pour savoir comment afficher les
propriétés d’un réseau virtuel, consultez Gérer des réseaux virtuels. Si
le locataire Azure Active Directory de l’abonnement est différent de
celui de l’abonnement qui a le réseau virtuel à partir duquel vous créez
le peering, ajoutez d’abord un utilisateur de chaque locataire comme
utilisateur invité dans le locataire opposé.
Abonnement Sélectionnez l’abonnement du réseau virtuel avec lequel vous

souhaitez effectuer le peering. Un ou plusieurs abonnements sont
répertoriés, selon le nombre d’abonnements auxquels votre compte a
accès en lecture. Si vous avez coché la case Je connais mon ID de
ressource, ce paramètre n’est pas disponible.
Réseau Sélectionnez le réseau virtuel avec lequel vous souhaitez effectuer le

virtuel peering. Vous pouvez sélectionner un réseau virtuel créé à l’aide d’un
modèle de déploiement d’Azure. Si vous souhaitez sélectionner un
réseau virtuel dans une autre région, vous devez le choisir dans une
région prise en charge. Pour que le réseau virtuel apparaisse dans la
liste, vous devez disposer de l’accès en lecture à celui-ci. Si un réseau
virtuel est répertorié, mais grisé, ce peut être parce que l’espace
d’adressage du réseau virtuel chevauche l’espace d’adressage de ce
réseau. Si les espaces d’adressage de réseaux virtuels se chevauchent, il
n’est pas possible de les appairer. Si vous avez coché la case Je
connais mon ID de ressource, ce paramètre n’est pas disponible.
Trafic vers le - Sélectionnez Autoriser (par défaut) pour activer la communication

réseau entre les deux réseaux virtuels par le biais du flux VirtualNetwork par
virtuel défaut. L’activation de la communication entre les réseaux virtuels
distant permet aux ressources connectées à l’un ou l’autre des réseaux virtuels
de communiquer entre elles par le biais du réseau privé Azure.
L’étiquette de service VirtualNetwork pour les groupes de sécurité
réseau englobe le réseau virtuel et le réseau virtuel appairé quand ce
paramètre a la valeur Autoriser. Pour en savoir plus sur les étiquettes
de service, consultez Étiquettes de service Azure.
- Sélectionnez Bloquer tout le trafic vers le réseau virtuel distant si
vous ne voulez pas que le trafic soit dirigé vers le réseau virtuel appairé
par défaut. Vous pouvez sélectionner ce paramètre si vous avez un
peering entre deux réseaux virtuels, mais que vous souhaitez parfois
désactiver le flux de trafic par défaut entre les deux. Il se peut que vous
trouviez plus pratique d’activer ou de désactiver les peerings que de
les supprimer et recréer. Quand ce paramètre est sélectionné, le trafic
n’est pas transmis entre les réseaux virtuels appairés par défaut ;
toutefois, le trafic peut quand même continuer à circuler s’il est
explicitement autorisé par le biais d’une règle de groupe de sécurité
réseau incluant les adresses IP ou groupes de sécurité d’application
appropriés.
Remarque :La sélection du paramètre Bloquer tout le trafic vers le

réseau virtuel distant modifie uniquement la définition de l’étiquette de
service VirtualNetwork. Il n’empêche pas complètement le trafic sur la
connexion du pair, comme expliqué dans la description de ce paramètre.
Trafic Sélectionnez Autoriser (par défaut) si vous voulez que le trafic soit
transféré à transféré par une appliance virtuelle réseau d’un réseau virtuel distant
partir du (ne provenant pas du réseau virtuel distant) vers ce réseau virtuel par
réseau le biais d’un peering. Par exemple, considérez trois réseaux virtuels
virtuel nommés Spoke1, Spoke2 et Hub. Un peering existe entre chaque
distant réseau virtuel spoke et le réseau virtuel Hub, mais les peerings
n’existent pas entre les réseaux virtuels spoke. Une appliance virtuelle
réseau est déployée dans le réseau virtuel Hub et des itinéraires définis
par l’utilisateur sont appliqués à chaque réseau virtuel spoke
acheminant le trafic entre les sous-réseaux via l’appliance virtuelle
réseau. Si ce paramètre n’est pas sélectionné pour le peering entre
chaque réseau virtuel spoke et le réseau virtuel Hub, le trafic ne passe
pas entre les réseaux virtuels spoke, car le Hub transfère le trafic entre
les réseaux virtuels. Si l’activation de cette fonctionnalité autorise le
transfert du trafic via le peering, elle n’a pas pour effet de créer des
itinéraires définis par l’utilisateur ou des appliances virtuelles. Les
itinéraires définis par l’utilisateur et les appliances virtuelles sont créés
séparément. Pour en savoir plus, voir Itinéraires définis par l’utilisateur.
REMARQUE :Il est inutile de sélectionner ce paramètre si le trafic est

transféré entre les réseaux virtuels par le biais d’une passerelle VPN
Azure.
Passerelle ou Sélectionnez Utiliser la passerelle ou le serveur de routes de ce

serveur de réseau virtuel :
routes de - Si une passerelle de réseau virtuel est déployée dans ce réseau
réseau virtuel, et si vous souhaitez autoriser le trafic en provenance du réseau
virtuel virtuel appairé via la passerelle. Par exemple, ce réseau virtuel peut être
attaché à un réseau local via une passerelle de réseau virtuel. La
passerelle peut être une passerelle ExpressRoute ou VPN. La sélection
de ce paramètre a pour effet d’autoriser le trafic en provenance du
réseau virtuel appairé à passer par la passerelle déployée dans ce
réseau virtuel pour atteindre le réseau local.
-Si vous avez un serveur de routage déployé dans ce réseau virtuel et
que vous souhaitez que le réseau virtuel homologué communique
avec le serveur de routage pour échanger des itinéraires. Pour plus
d’informations, consultez Serveur de routes Azure.
Si vous sélectionnez Utiliser la passerelle ou le serveur de routes de

ce réseau virtuel, le réseau virtuel appairé ne peut pas avoir de
passerelle configurée. Le paramètre Utiliser la passerelle ou le serveur
de routes du réseau virtuel distant doit être sélectionné pour le
réseau virtuel appairé lors de la configuration du peering de l’autre
réseau virtuel avec ce réseau virtuel. Si vous laissez ce paramètre sur
Aucun (par défaut), le trafic en provenance du réseau virtuel appairé
continue de passer par ce réseau virtuel, mais il ne peut pas passer par
une passerelle de réseau virtuel déployée dans ce réseau virtuel. Si le
peering est entre un réseau virtuel (Resource Manager) et un réseau

virtuel (classique), la passerelle doit se trouver dans le réseau virtuel
(Resource Manager).
En plus de transférer le trafic vers un réseau local, une passerelle VPN

peut transférer le trafic réseau entre les réseaux virtuels qui sont
homologués avec le réseau virtuel dans lequel la passerelle se trouve,
sans que les réseaux virtuels n’aient besoin d’être homologués entre
eux. L’utilisation d’une passerelle VPN pour le transfert du trafic est
utile lorsque vous souhaitez utiliser une passerelle VPN dans un réseau
virtuel Hub (consultez l’exemple de hub-and-spoke décrit pour
Autoriser le trafic transféré) afin d’acheminer le trafic entre des
réseaux virtuels spoke qui ne sont pas appairés. Pour en savoir plus sur
l’autorisation d’utilisation d’une passerelle pour le transit, consultez
Configurer une passerelle VPN pour le transit dans un peering de
réseaux virtuels. Ce scénario nécessite l’implémentation d’itinéraires
définis par l’utilisateur qui spécifient la passerelle de réseau virtuel en
tant que type de tronçon suivant. Pour en savoir plus, voir Itinéraires
définis par l’utilisateur. Vous ne pouvez spécifier une passerelle VPN en
tant que type de tronçon suivant uniquement dans un itinéraire défini
par l’utilisateur, vous ne pouvez pas spécifier une passerelle
ExpressRoute en tant que type de tronçon suivant dans un itinéraire
défini par l’utilisateur.
Sélectionnez Utiliser la passerelle ou le serveur de routes du réseau

virtuel distant :
- Si vous voulez autoriser le trafic en provenance de ce réseau virtuel à
passer par une passerelle de réseau virtuel déployée dans le réseau
virtuel avec lequel vous effectuez l’appairage. Par exemple, le réseau
virtuel avec lequel vous effectuez l’appairage a une passerelle VPN qui
permet la communication avec un réseau local. La sélection de ce
paramètre a pour effet d’autoriser le trafic en provenance de ce réseau
virtuel à passer par la passerelle VPN dans le réseau virtuel appairé.
- Si vous souhaitez que ce réseau virtuel utilise le serveur de routage
distant pour échanger des itinéraires. Pour plus d’informations,
consultez Serveur de routes Azure.
Si vous sélectionnez ce paramètre, une passerelle de réseau virtuel doit

être déployée dans le réseau virtuel appairé et le paramètre Utiliser la
passerelle ou le serveur de routes de ce réseau virtuel doit être
sélectionné. Si vous laissez ce paramètre configuré sur Aucun (par
défaut), le trafic en provenance de ce réseau virtuel peut quand même
parvenir au réseau virtuel appairé, mais il ne peut pas passer par une
passerelle de réseau virtuel dans le réseau virtuel appairé. Un seul
peering pour ce réseau virtuel peut avoir ce paramètre activé.
REMARQUE : Vous ne pouvez pas utiliser de passerelles distantes si une

passerelle est déjà configurée dans votre réseau virtuel. Pour en savoir
plus sur l’utilisation d’une passerelle pour le transit, consultez Configurer

une passerelle VPN pour le transit dans un appairage de réseaux
virtuels.
７ Notes
Si vous utilisez une passerelle Réseau virtuel Microsoft Azure pour

envoyer le trafic local de manière transitive vers un réseau virtuel
homologué, la plage d’adresses IP du réseau virtuel homologué doit
concerner le trafic « intéressant » pour le périphérique VPN local. Vous
devrez peut-être ajouter toutes les adresses CIDR du réseau virtuel Azure
à la configuration du tunnel VPN IPSec de site à site sur le périphérique
VPN local. Les adresses CIDR incluent des ressources telles que des pools
d’adresses IP de point à site, un hub et des spokes. Dans le cas contraire,
vos ressources locales ne seront pas en mesure de communiquer avec les
ressources du réseau virtuel homologué. Le trafic intéressant est
communiqué par le biais d’associations de sécurité de phase 2.
L’association de sécurité crée un tunnel VPN dédié pour chaque sous-
réseau spécifié. Les niveaux de passerelle VPN locale et Azure doivent
prendre en charge le même nombre de tunnels VPN de site à site et de
sous-réseaux de réseau virtuel Azure. Dans le cas contraire, vos
ressources locales ne seront pas en mesure de communiquer avec les
ressources du réseau virtuel homologué. Consultez la documentation de
votre VPN local afin d’obtenir des instructions sur la création
d’associations de sécurité de phase 2 pour chaque sous-réseau de réseau
virtuel Azure spécifié.
5. Sélectionnez le bouton Actualiser au bout de quelques secondes pour que

l’état de l’appairage passe de Mise à jour à Connecté.
Pour obtenir des instructions pas à pas sur l’implémentation du peering entre des
réseaux virtuels dans différents abonnements et modèles de déploiement, consultez
la section Étapes suivantes.
Afficher ou modifier les paramètres de peering
Avant de modifier un peering, familiarisez-vous avec les exigences et contraintes ainsi
qu’avec les autorisations nécessaires.
Portail
1. Sélectionnez le réseau virtuel que vous voulez afficher ou modifiez ses

paramètres d’appairage.
2. Sélectionnez Peerings sous Paramètres, puis sélectionnez l’homologation que

vous souhaitez afficher ou dont vous souhaitez modifier les paramètres.
3. Modifiez le paramètre approprié. Lisez les options de chaque paramètre de

l’étape 4 de création d’un peering. Sélectionnez ensuite Enregistrer pour
terminer les modifications de configuration.
Supprimer un peering
Avant de supprimer un appairage, familiarisez-vous avec les exigences et contraintes
ainsi qu’avec les autorisations nécessaires.
Portail
Quand vous supprimez un appairage entre deux réseaux virtuels, le trafic ne peut
plus circuler entre ces réseaux virtuels. Si vous souhaitez que les réseaux virtuels
communiquent occasionnellement, au lieu de supprimer un peering, vous pouvez
définir le paramètre Trafic vers le réseau virtuel distant sur Bloquer tout le trafic
vers le réseau virtuel distant. Il se peut que vous trouviez plus facile de désactiver
et activer l’accès réseau que de supprimer et recréer des peerings.
1. Sélectionnez dans la liste le réseau virtuel pour lequel vous souhaitez

supprimer un peering.
2. Sélectionnez Peerings sous Paramètres.
3. Sur le côté droit du peering que vous souhaitez supprimer, sélectionnez ... ,
puis sélectionnez Supprimer.
4. Sélectionnez Oui pour confirmer que vous souhaitez supprimer le peering et
le pair correspondant.
７ Notes
Quand vous supprimez d’un réseau virtuel un appairage de réseaux

virtuels, l’appairage du réseau virtuel distant est également supprimé.
Exigences et contraintes
Vous pouvez appairer des réseaux virtuels dans la même région ou dans
différentes régions. L’appairage de réseaux virtuels dans des régions différentes est
également appelé Global VNet Peering.
Lors de la création d’un Peering mondial, les réseaux virtuels appairés peuvent se
trouver dans n’importe quelle région de clouds publics Azure, dans des régions de
clouds Azure Chine ou Azure Government. Vous ne pouvez pas appairer entre
plusieurs clouds. Par exemple, un réseau virtuel dans le cloud public Azure ne peut
pas être appairé avec un réseau virtuel du cloud Azure Chine.
Les ressources dans un réseau virtuel ne peuvent pas communiquer avec

l’adresse IP front-end d’un équilibreur de charge de base (interne ou public) dans
un réseau virtuel globalement appairé. La prise en charge d’un équilibreur de
charge de base n’est proposée que dans la même région. La prise en charge d’un
Standard Load Balancer existe pour VNet Peering et Global VNet Peering. Certains
services qui utilisent un équilibreur de charge De base ne fonctionnent pas sur
l’appairage de réseaux virtuels mondiaux. Pour plus d’informations, consultez les
contraintes liées aux équilibreurs de charge et à l’appairage de réseaux virtuels
mondiaux.
Vous pouvez utiliser des passerelles distantes ou autoriser un transit par passerelle
dans des réseaux virtuels appairés à l’échelle mondiale et en local.
Les réseaux virtuels peuvent être dans des abonnements identiques ou différents.
Quand vous appairez des réseaux virtuels de différents abonnements, les deux
abonnements peuvent être associés au même locataire Azure Active Directory ou à
un locataire différent. Si vous n’avez pas encore de locataire AD, vous pouvez
rapidement en créer un.
Les réseaux virtuels que vous homologuez doivent avoir des espaces d’adressage
IP qui ne se chevauchent pas.
Vous pouvez homologuer deux réseaux virtuels déployés via le Gestionnaire de

ressources, ou homologuer un réseau virtuel déployé via le Gestionnaire de
ressources avec un réseau virtuel déployé via le modèle de déploiement classique.
Vous ne pouvez pas homologuer deux réseaux virtuels créés via le modèle de
déploiement classique. Si vous n’êtes pas familiarisé avec les modèles de
déploiement Azure, lisez l’article Comprendre les modèles de déploiement Azure.
Vous pouvez utiliser une passerelle VPN pour connecter deux réseaux virtuels créés
via le modèle de déploiement classique.
Lors du peering de deux réseaux virtuels créés via le Gestionnaire de ressources, un
peering doit être configuré pour chaque réseau virtuel dans le peering. L’un des
états suivants s’affiche pour le peering :
Démarré : Quand vous créez le premier appairage, son état est Démarré.
Connecté : Quand vous créez le deuxième appairage, l’état passe à Connecté
pour les deux appairages. L’appairage n’est pas correctement établi tant que
l’état d’appairage des deux appairages de réseaux virtuels est Connecté.
Lors du peering d’un réseau virtuel créé via le Gestionnaire de ressources avec un
réseau virtuel créé via le modèle de déploiement classique, vous configurez un
peering uniquement pour le réseau virtuel est déployé via le Gestionnaire de
ressources. Vous ne pouvez pas configurer d’appairage pour un réseau virtuel
(classique), ni entre deux réseaux virtuels déployés par le biais du modèle de
déploiement classique. Lorsque vous créez le peering à partir du réseau virtuel
(Gestionnaire des ressources) au réseau virtuel (classique), l’état de peering est Mis
à jour, puis passe rapidement à Connecté.
Un peering est établi entre deux réseaux virtuels. Les appairages en eux-mêmes ne
sont pas transitifs. Imaginons que vous créez des peerings entre :
VirtualNetwork1 et VirtualNetwork2
VirtualNetwork2 et VirtualNetwork3
Il n’existe aucune connectivité entre VirtualNetwork1 et VirtualNetwork3 par le

biais de VirtualNetwork2. Si vous voulez que VirtualNetwork1 et
VirtualNetwork3 communiquent directement, vous devez créer un appairage
explicite entre VirtualNetwork1 et VirtualNetwork3 ou passer par une appliance
virtuelle réseau dans le réseau hub. Pour plus d’informations, consultez
Topologie réseau hub-and-spoke dans Azure.
Vous ne pouvez pas résoudre des noms dans des réseaux virtuels homologués en
utilisant une résolution de noms Azure par défaut. Pour résoudre des noms dans
d’autres réseaux virtuels, vous devez utiliser le service DNS privé Azure ou un
serveur DNS personnalisé. Pour savoir comment configurer votre propre serveur
DNS, consultez Résolution de noms à l’aide de votre propre serveur DNS.
Les ressources situées dans des réseaux virtuels appairés et dans la même région
peuvent communiquer entre elles avec la même latence que si elles se trouvaient
au sein du même réseau virtuel. Le débit du réseau repose sur la bande passante
autorisée pour la machine virtuelle proportionnellement à sa taille. Aucune
restriction de bande passante supplémentaire n’est appliquée au sein du peering.
Chaque taille de machine virtuelle a sa propre bande passante réseau maximale.
Pour en savoir plus sur la bande passante réseau maximale des différentes tailles
de machine virtuelle, consultez Tailles des machines virtuelles dans Azure.
Un réseau virtuel peut être homologué ainsi qu’être connecté à un autre réseau
virtuel avec une passerelle de réseau virtuel Azure. Lorsque des réseaux virtuels
sont connectés via un peering et une passerelle, le trafic entre les réseaux virtuels
passe par le peering plutôt que par la passerelle.
Les clients VPN point à site doivent être retéléchargés une fois que le peering de
réseaux virtuels a été configuré avec succès pour garantir le téléchargement des
nouvelles routes sur le client.
Un coût nominal s’applique pour le trafic d’entrée et de sortie qui utilise un

appairage de réseaux virtuels. Pour plus d’informations, consultez la page relative
aux prix appliqués .
Autorisations
Les comptes pouvant être utilisés avec le peering de réseaux virtuels doivent avoir les
rôles suivants :
Contributeur de réseaux : pour un réseau virtuel déployé via Resource Manager.

Contributeur de réseaux classiques : pour un réseau virtuel déployé via le modèle
de déploiement classique.
Si votre compte n’a pas l’un des rôles ci-dessus, il doit avoir un rôle personnalisé auquel
sont affectées les actions nécessaires listées dans le tableau suivant :
Action Nom
Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write Action requise pour créer un

peering entre un réseau
virtuel A et un réseau virtuel
B. Le réseau virtuel A doit
être un réseau virtuel
(Resource Manager)
Microsoft.Network/virtualNetworks/peer/action Action requise pour créer un

virtuel B (Resource Manager)
et un réseau virtuel A
Action Nom
Microsoft.ClassicNetwork/virtualNetworks/peer/action Action requise pour créer un

virtuel B (classique) et un
réseau virtuel A
Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read Action requise pour lire un

peering de réseaux virtuels
Microsoft.Network/virtualNetworks/virtualNetworkPeerings/delete Action requise pour

supprimer un peering de
réseaux virtuels
Étapes suivantes
Un appairage de réseaux virtuels peut être configuré entre des réseaux virtuels
créés par le biais de modèles de déploiement identiques ou différents qui existent
dans des abonnements identiques ou différents. Suivez un didacticiel pour l’un des
scénarios suivants :
Modèle de déploiement Azure Abonnement
Les deux modèles Resource Manager Identique
Différent
Différent
Découvrez comment créer une topologie de réseau Hub and Spoke.
Créez un peering de réseaux virtuels avec les exemples de scripts PowerShell ou

Azure CLI, ou à l’aide des modèles Azure Resource Manager
Créer et attribuer des définitions Azure Policy pour les réseaux virtuels
 Documentation
Configurer le transit par passerelle VPN pour le peering de réseaux virtuels - Azure
VPN Gateway
Découvrez comment configurer le transit par passerelle pour le peering de réseaux virtuels, afin de
connecter en toute transparence deux réseaux virtuels Azure en un seul à des fins de connectivité.
Tutoriel : Acheminer le trafic réseau avec une table de routage - Portail Azure
Dans ce didacticiel, découvrez comment acheminer le trafic réseau avec une table de routage à l’aide
du portail Azure.
Présentation de la résolution des problèmes de connexion d’Azure Network Watcher

Cette page fournit une vue d’ensemble de la fonctionnalité de résolution des problèmes de
connexion de Network Watcher
Gérer les règles NAT de trafic entrant pour Azure Load Balancer
Dans cet article, vous allez apprendre à ajouter et supprimer une règle NAT de trafic entrant dans le
Portail Azure.
Connecter un réseau virtuel à un autre réseau virtuel à l’aide d’une connexion de

réseau virtuel à réseau virtuel avec passerelle VPN : PowerShell - Azure VPN Gateway
Découvrez comment connecter des réseaux virtuels à l’aide d’une connexion de réseau virtuel à
réseau virtuel et de PowerShell.
Peering de réseaux virtuels Azure

Découvrez l’appairage de réseaux virtuels dans Azure, notamment la façon dont il vous permet de
connecter des réseaux dans Réseau virtuel Microsoft Azure.
Routage du trafic de réseau virtuel Azure

Découvrez comment Azure achemine le trafic de réseau virtuel, et comment vous pouvez
personnaliser le routage d’Azure.
Créer un peering de réseaux virtuels Azure - Modèles de déploiement différents -

même abonnement
Découvrez comment créer un peering de réseaux virtuels entre des réseaux virtuels créés via des
modèles de déploiement Azure différents qui existent dans le même abonnement.
Afficher 5 de plus
 Entrainement
Module
Mettre à jour l’espace d’adressage d’un
réseau virtuel appairé à l’aide du portail
Azure
Dans cet article, vous apprendrez à mettre à jour un réseau virtuel en modifiant, ajoutant
ou supprimant un espace d’adressage à l’aide du portail Azure. Ces mises à jour
n’entraînent pas d’interruptions de temps d’arrêt. Cette fonctionnalité est utile lorsque
vous devez agrandir ou redimensionner les réseaux virtuels dans Azure après avoir mis à
l’échelle vos charges de travail.
Prérequis
Un réseau virtuel appairé existant avec deux réseaux virtuels
Si vous ajoutez un espace d’adressage, assurez-vous qu’il ne chevauche pas
d’autres espaces d’adressage
Modifier le préfixe de plage d’adresses d’une

plage d’adresses existante
Dans cette section, vous modifiez le préfixe de plage d’adresses d’une plage d’adresses
existante au sein de votre réseau virtuel appairé.
1. Dans la zone de recherche située en haut du portail Azure, entrez réseaux virtuels.
2. Dans la liste des réseaux virtuels, sélectionnez le réseau virtuel à modifier.
4. Dans la page Espace d’adressage, changez le préfixe de plage d’adresses en

fonction de vos besoins, puis sélectionnez Enregistrer.

5. Sous Paramètres, sélectionnez Peerings, puis cochez la case correspondant au

peering que vous souhaitez synchroniser.
6. Sélectionnez Synchroniser dans la barre des tâches.
7. Sélectionnez le nom de l’autre réseau virtuel appairé sous Pair.
8. Sous Paramètres du réseau virtuel appairé, sélectionnez Espace d’adressage et

vérifiez que l’espace d’adressage listé a été mis à jour.

７ Notes
Lorsque vous mettez à jour l’espace d’adressage d’un réseau virtuel, vous devez
synchroniser l’homologue du réseau virtuel pour chaque réseau virtuel à distance.
Nous vous recommandons d’effectuer la synchronisation après chaque nouvelle
opération de redimensionnement de l’espace d’adressage au lieu de le faire après
plusieurs opérations de redimensionnement consécutives.
Les actions suivantes nécessitent une synchronisation :
Modification du préfixe de plage d’adresses d’une plage d’adresses existante,

par exemple, changement de 10.1.0.0/16 en 10.1.0.0/18
Ajout de plages d’adresses à un réseau virtuel
Suppression de plages d’adresses d’un réseau virtuel
Ajouter une plage d’adresses

Dans cette section, vous ajoutez une plage d’adresses IP à l’espace d’adressage IP d’un
réseau virtuel appairé.
2. Dans la liste des réseaux virtuels, sélectionnez le réseau où vous ajoutez une plage
d’adresses.
4. Dans la page Espace d’adressage, ajoutez la plage d’adresses en fonction de vos

besoins, puis sélectionnez Enregistrer quand vous avez terminé.
5. Sous Paramètres, sélectionnez Peeringet synchronisez la connexion de peering.

Supprimer une plage d’adresses

Dans cette tâche, vous supprimez une plage d’adresses IP d’un espace d’adressage. Tout
d’abord, supprimez tous les sous-réseaux existants, puis supprimez la plage d’adresses
IP.
） Important
Avant de pouvoir supprimer un espace d’adressage, il doit être vide. S’il existe déjà
un sous-réseau dans la plage d’adresses, vous ne pouvez pas supprimer la plage.
Avant de supprimer une plage d’adresses, vous devez supprimer tous les sous-
réseaux et toutes les ressources des sous-réseaux existant dans celle-ci.
2. Dans la liste des réseaux virtuels, sélectionnez le réseau virtuel à partir duquel vous
souhaitez supprimer la plage d’adresses.
3. Sous Paramètres, sélectionnez Sous-réseaux.
4. À droite de la plage d’adresses à supprimer, sélectionnez ... et sélectionnez

Supprimer dans la liste déroulante. Choisissez Oui pour confirmer la suppression.
5. Sélectionnez Enregistrer une fois que vous avez terminé vos modifications.
6. Sous Paramètres, sélectionnez Peeringet synchronisez la connexion de peering.

Étapes suivantes
Créer, modifier ou supprimer un peering de réseau virtuel
Créer, modifier ou supprimer un réseau virtuel
Configurer une connexion de passerelle
VPN de réseau virtuel à réseau virtuel à
l’aide de PowerShell
Article • 11/05/2023
Cet article vous explique comment connecter des réseaux virtuels avec une connexion
de réseau virtuel à réseau virtuel. Les réseaux virtuels peuvent être situés dans des
régions identiques ou différentes et appartenir à des abonnements identiques ou
différents. Lors de la connexion de réseaux virtuels provenant de différents
abonnements, les abonnements ne sont pas tenus d’être associés au même locataire
Active Directory.
Les étapes mentionnées dans cet article s’appliquent au modèle de déploiement

Resource Manager et utilisent PowerShell. Vous pouvez également créer cette
configuration à l’aide d’un autre outil ou modèle de déploiement en sélectionnant une
option différente dans la liste suivante :
À propos de la connexion de réseaux virtuels

Il existe plusieurs manières de se connecter à des réseaux virtuels. Les sections ci-
dessous décrivent les différentes manières de se connecter à des réseaux virtuels.
Connexion entre deux réseaux virtuels

La configuration d’une connexion de réseau virtuel à réseau virtuel est un bon moyen de
se connecter facilement à des réseaux virtuels. La connexion entre deux réseaux virtuels
est semblable à la création d’une connexion IPsec de site à site dans un emplacement
local. Ces deux types de connectivité font appel à une passerelle VPN pour offrir un
tunnel sécurisé utilisant Ipsec/IKE et communiquent de la même façon. La différence
entre ces types de connexion se trouve dans la configuration de la passerelle réseau
locale. Lorsque vous créez une connexion de réseau virtuel à réseau virtuel, vous ne
voyez pas l’espace d’adressage de la passerelle réseau locale. L’espace est créé et rempli
automatiquement. Si vous mettez à jour l’espace d’adressage pour un réseau virtuel,
l’autre réseau virtuel achemine automatiquement le trafic vers le nouvel espace
d’adressage. La création d’une connexion de réseau virtuel à réseau virtuel est
généralement plus rapide et plus simple que la création d’une connexion de site à site
entre des réseaux virtuels.
Site à site (IPsec)
Si vous travaillez avec une configuration réseau complexe, vous pouvez connecter vos
réseaux virtuels à l’aide des étapes site à site, à la place des étapes de réseau virtuel à
réseau virtuel. Lorsque vous utilisez les étapes de site à site, vous créez et configurez
manuellement les passerelles réseau locales. La passerelle de réseau local pour chaque
réseau virtuel traite l’autre réseau virtuel comme un site local. Ainsi, vous pourrez
spécifier un espace d’adressage supplémentaire pour la passerelle réseau locale afin
d’acheminer le trafic. Si l’espace d’adressage pour un réseau virtuel est modifié, vous
devez mettre à jour la passerelle réseau locale correspondante pour le refléter. Elle n’est
pas automatiquement mise à jour.
Peering de réseaux virtuels

Vous envisagerez probablement de connecter vos réseaux virtuels à l’aide de VNet
Peering. VNet Peering n’utilise pas une passerelle VPN et possède d’autres contraintes.
En outre, la tarification de VNet Peering est différente de la tarification de la passerelle
VPN de réseau virtuel à réseau virtuel . Pour plus d’informations, consultez l’article
Peering de réseaux virtuels.
Pourquoi créer une connexion de réseau virtuel

à réseau virtuel ?
Vous pouvez décider de connecter des réseaux virtuels à l’aide d’une connexion de
réseau virtuel à réseau virtuel pour les raisons suivantes :
Géo-redondance et présence géographique dans plusieurs régions

Vous pouvez configurer la géo-réplication ou la synchronisation avec une
connectivité sécurisée sans passer par les points de terminaison accessibles sur
Internet.
Avec Traffic Manager et l’équilibreur de charge Azure, vous pouvez configurer
une charge de travail hautement disponible avec la géo-redondance dans
plusieurs régions Azure. Vous pouvez par exemple configurer SQL Always On
avec des groupes de disponibilité répartis dans différentes régions Azure.
Applications multiniveaux régionales avec une limite d’isolement ou

administrative
Dans la même région, vous pouvez configurer des applications multiniveaux
avec plusieurs réseaux virtuels interconnectés pour des besoins d’isolement ou
d’administration.
Vous pouvez combiner une communication de réseau virtuel à réseau virtuel avec des
configurations multisites. Vous établissez ainsi des topologies réseau qui combinent une
connectivité entre différents locaux et une connectivité entre différents réseaux virtuels.
Quelles étapes de réseau virtuel à réseau

virtuel dois-je utiliser ?
Cet article inclut deux ensembles d’étapes distincts. L’un des ensembles est destiné aux
réseaux virtuels qui se trouvent dans le même abonnement, et l’autre aux réseaux
virtuels qui se trouvent dans des abonnements différents. La différence essentielle entre
ces deux ensembles est que vous devez utiliser des sessions PowerShell distinctes quand
vous configurez les connexions pour des réseaux virtuels qui se trouvent dans des
abonnements différents.
Pour cet exercice, vous pouvez combiner des configurations ou choisir simplement celle
que vous voulez utiliser. Toutes les configurations utilisent la connexion de réseau virtuel
à réseau virtuel. Le trafic circule entre les réseaux virtuels connectés directement entre
eux. Dans cet exercice, le trafic du réseau TestVNet4 n’est pas acheminé jusqu’au réseau
TestVNet5.
Réseaux virtuels situés dans le même abonnement : Les étapes à suivre pour cette
configuration utilisent les réseaux virtuels TestVNet1 et TestVNet4.
Réseaux virtuels situés dans des abonnements différents : Les étapes à suivre pour
cette configuration utilisent les réseaux virtuels TestVNet1 et TestVNet5.
Connexion de réseaux virtuels situés dans le

même abonnement
Avant de commencer
７ Notes
Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir

avec Azure. Pour commencer, consultez Installer Azure PowerShell. Pour savoir
comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell
depuis AzureRM vers Az.
La création d’une passerelle peut prendre 45 minutes ou plus. C’est pourquoi

Azure Cloud Shell expire périodiquement au cours de cet exercice. Pour redémarrer
Cloud Shell, cliquez dans le coin supérieur gauche du terminal. Veillez à redéclarer
les éventuelles variables au redémarrage du terminal.
Si vous préférez installer localement la dernière version du module Azure

PowerShell, consultez Guide pratique pour installer et configurer Azure PowerShell.
Étape 1 : planifier vos plages d’adresses IP

Dans les étapes suivantes, vous allez créer deux réseaux virtuels avec leurs sous-réseaux
de passerelle respectifs et leur configuration. Vous allez ensuite créer une connexion
VPN entre les deux réseaux virtuels. Il est important de planifier les plages d’adresses IP
pour votre configuration réseau. N’oubliez pas que vous devez vous assurer qu’aucune
plage de réseaux virtuels ou de réseaux locaux ne se chevauche. Dans ces exemples,
nous n’incluons pas de serveur DNS. Si vous souhaitez une résolution de noms pour vos
réseaux virtuels, consultez la page Résolution de noms.
Nous utilisons les valeurs suivantes dans les exemples :
Valeurs pour TestVNet1 :
Nom du réseau virtuel : TestVNet1

Groupe de ressources : TestRG1
Localisation : USA Est
TestVNet1 : 10.11.0.0/16 & 10.12.0.0/16
Front-end : 10.11.0.0/24
BackEnd : 10.12.0.0/24
GatewaySubnet : 10.12.255.0/27
GatewayName : VNet1GW
Adresse IP publique : VNet1GWIP
VPNType : RouteBased
Connection(1to4) : VNet1toVNet4
Connection(1to5) : VNet1toVNet5 (pour les réseaux virtuels se trouvant dans des
abonnements différents)
ConnectionType : VNet2VNet

TestVNet2 : 10.41.0.0/16 & 10.42.0.0/16
Front-end : 10.41.0.0/24
BackEnd : 10.42.0.0/24
GatewaySubnet : 10.42.255.0/27
Localisation : USA Ouest
Connexion : VNet4toVNet1
Étape 2 : créez et configurez TestVNet1

1. Vérifiez vos paramètres d’abonnement.
Connectez-vous à votre compte si vous exécutez PowerShell en local sur votre

ordinateur. Si vous utilisez Azure Cloud Shell, la connexion est établie
automatiquement.
Azure PowerShell
Connect-AzAccount
Vérifiez les abonnements associés au compte.
Azure PowerShell
Get-AzSubscription
Si vous avez plusieurs abonnements, spécifiez celui que vous souhaitez utiliser.
Azure PowerShell
Select-AzSubscription -SubscriptionName nameofsubscription

2. Déclarez vos variables. Cet exemple déclare les variables avec les valeurs de cet
exercice. Dans la plupart des cas, vous devez remplacer les valeurs par les vôtres.
Cependant, vous pouvez utiliser ces variables si vous exécutez la procédure pour
vous familiariser avec ce type de configuration. Si besoin, modifiez les variables,
puis copiez et collez-les dans la console PowerShell.
Azure PowerShell
$RG1 = "TestRG1"
$Location1 = "East US"
$VNetName1 = "TestVNet1"
$FESubName1 = "FrontEnd"
$BESubName1 = "Backend"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$GWName1 = "VNet1GW"
$GWIPName1 = "VNet1GWIP"
$GWIPconfName1 = "gwipconf1"
$Connection14 = "VNet1toVNet4"
3. Créez un groupe de ressources.
Azure PowerShell
New-AzResourceGroup -Name $RG1 -Location $Location1
4. Créez les configurations de sous-réseau pour TestVNet1. Cet exemple crée un

réseau virtuel nommé TestVNet1 et trois sous-réseaux nommés GatewaySubnet,
FrontEnd et Backend. Lorsque vous remplacez les valeurs, pensez à toujours
nommer votre sous-réseau de passerelle « GatewaySubnet ». Si vous le nommez
autrement, la création de votre passerelle échoue. Pour cette raison, il n’est pas
attribué via une variable ci-dessous.
L’exemple suivant utilise les variables définies précédemment. Dans cet exemple, le
sous-réseau de passerelle utilise /27. Bien qu’il soit possible de créer un sous-
réseau de passerelle aussi petit que /29, nous vous recommandons de créer un
sous-réseau plus vaste qui inclut un plus grand nombre d’adresses en
sélectionnant au moins /28 ou /27. Cela permettra à un nombre suffisant
d’adresses de s’adapter à de possibles configurations supplémentaires possibles
que vous êtes susceptible de souhaiter par la suite.
Azure PowerShell
$fesub1 = New-AzVirtualNetworkSubnetConfig -Name $FESubName1 -

AddressPrefix $FESubPrefix1
$besub1 = New-AzVirtualNetworkSubnetConfig -Name $BESubName1 -
AddressPrefix $BESubPrefix1
$gwsub1 = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -
AddressPrefix $GWSubPrefix1
5. Créez TestVNet1.
Azure PowerShell
New-AzVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1 `

-Location $Location1 -AddressPrefix $VNetPrefix11,$VNetPrefix12 -Subnet
$fesub1,$besub1,$gwsub1
6. Demandez l’allocation d’une adresse IP publique à la passerelle que vous allez

créer pour votre réseau virtuel. Notez que la valeur AllocationMethod est
dynamique. Vous ne pouvez pas spécifier l’adresse IP que vous souhaitez utiliser.
Elle est allouée à votre passerelle de façon dynamique.
Azure PowerShell
$gwpip1 = New-AzPublicIpAddress -Name $GWIPName1 -ResourceGroupName

$RG1 `
-Location $Location1 -AllocationMethod Dynamic
7. Créez la configuration de la passerelle. La configuration de la passerelle définit le

sous-réseau et l’adresse IP publique à utiliser. Utilisez l’exemple pour créer la
configuration de votre passerelle.
Azure PowerShell
$vnet1 = Get-AzVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1

$subnet1 = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -
VirtualNetwork $vnet1
$gwipconf1 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName1 `
-Subnet $subnet1 -PublicIpAddress $gwpip1
8. Créez la passerelle pour TestVNet1. Dans cette étape, vous créez la passerelle de
réseau virtuel de votre TestVNet1. Les configurations de réseau virtuel à réseau
virtuel requièrent un VPN de type RouteBased. La création d’une passerelle
nécessite généralement au moins 45 minutes, selon la référence SKU de passerelle
sélectionnée.
Azure PowerShell
New-AzVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 `

-Location $Location1 -IpConfigurations $gwipconf1 -GatewayType Vpn `
-VpnType RouteBased -GatewaySku VpnGw1
Une fois les commandes terminées, la création de cette passerelle prendra 45 minutes
ou plus. Si vous utilisez Azure Cloud Shell, vous pouvez redémarrer votre session Cloud
Shell en cliquant dans le coin supérieur gauche du terminal Cloud Shell, puis configurer
TestVNet4. Il n’est pas nécessaire d’attendre la fin de la passerelle TestVNet1.

Une fois que vous avez configuré TestVNet1, créez TestVNet4. Suivez les étapes ci-
dessous, en remplaçant les valeurs par les vôtres si nécessaire.
1. Connectez et déclarez vos variables. Veillez à remplacer les valeurs par celles que
vous souhaitez utiliser pour votre configuration.
Azure PowerShell
$RG4 = "TestRG4"
$Location4 = "West US"
$VnetName4 = "TestVNet4"
$VnetPrefix41 = "10.41.0.0/16"
$VnetPrefix42 = "10.42.0.0/16"
$FESubPrefix4 = "10.41.0.0/24"
$BESubPrefix4 = "10.42.0.0/24"
$GWSubPrefix4 = "10.42.255.0/27"
Azure PowerShell
3. Créez les configurations de sous-réseau pour TestVNet4.
Azure PowerShell
$gwsub4 = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -
Azure PowerShell
New-AzVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4 `

-Location $Location4 -AddressPrefix $VnetPrefix41,$VnetPrefix42 -Subnet
5. Demandez une adresse IP publique
Azure PowerShell

$RG4 `
6. Créez la configuration de la passerelle.
Azure PowerShell
$vnet4 = Get-AzVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4

$gwipconf4 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName4 -
Subnet $subnet4 -PublicIpAddress $gwpip4
7. Créer la passerelle TestVNet4. La création d’une passerelle nécessite généralement

au moins 45 minutes, selon la référence SKU de passerelle sélectionnée.
Azure PowerShell
New-AzVirtualNetworkGateway -Name $GWName4 -ResourceGroupName $RG4 `

-Location $Location4 -IpConfigurations $gwipconf4 -GatewayType Vpn `
-VpnType RouteBased -GatewaySku VpnGw1
Étape 4 - créez les connexions

Attendez que les deux passerelles soient terminées. Redémarrez votre session Azure
Cloud Shell et copiez-collez les variables du début des étapes 2 et 3 dans la console
pour redéclarer les valeurs.
1. Obtenez les passerelles de réseau virtuel.
Azure PowerShell
$vnet1gw = Get-AzVirtualNetworkGateway -Name $GWName1 -

ResourceGroupName $RG1
2. Créez la connexion de TestVNet1 à TestVNet4. Lors de cette étape, vous créez la

connexion de TestVNet1 à TestVNet4. Une clé partagée est référencée dans les
exemples. Vous pouvez utiliser vos propres valeurs pour cette clé partagée. Il est
important que la clé partagée corresponde aux deux connexions. La création d’une
connexion peut prendre quelques instants.
Azure PowerShell
New-AzVirtualNetworkGatewayConnection -Name $Connection14 -

ResourceGroupName $RG1 `
-VirtualNetworkGateway1 $vnet1gw -VirtualNetworkGateway2 $vnet4gw -
Location $Location1 `
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
3. Créez la connexion de TestVNet4 à TestVNet1. Cette étape est similaire à celle

présentée ci-dessus, sauf que vous créez la connexion de TestVNet4 à TestVNet1.
Vérifiez que les clés partagées correspondent. Après quelques minutes, la
connexion est établie.
Azure PowerShell

ResourceGroupName $RG4 `
-VirtualNetworkGateway1 $vnet4gw -VirtualNetworkGateway2 $vnet1gw -
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
4. Vérifiez votre connexion. Consultez la section Vérification de votre connexion.
Connexion de réseaux virtuels situés dans

différents abonnements
Dans ce scénario, vous connectez TestVNet1 et TestVNet5. TestVNet1 et TestVNet5 se
trouvent dans des abonnements différents. Les abonnements ne sont pas tenus d’être
associés au même locataire Active Directory.
La différence entre ce processus et le précédent réside dans le fait qu’une partie des
étapes de configuration doit être exécutée dans une session PowerShell distincte dans le
contexte d’un deuxième abonnement. notamment lorsque les deux abonnements
appartiennent à différentes organisations.
En raison de la modification du contexte d’abonnement dans cet exercice, il peut se

révéler plus facile d’utiliser PowerShell en local sur un ordinateur qu’Azure Cloud Shell,
une fois à l’étape 8.

Vous devez terminer les étapes 1 et 2 de la section précédente pour créer et configurer
TestVNet1 et la passerelle VPN pour TestVNet1. Pour cette configuration, il n’est pas
nécessaire de créer TestVNet4 à partir de la section précédente. Néanmoins, si vous la
créez, elle n’entrera pas en conflit avec ces étapes. Une fois les étapes 1 et 2 effectuées,
passez à l’étape 6 pour créer TestVNet5.
Étape 6 : vérifiez les plages d’adresses IP

Il est important de s’assurer que l’espace d’adressage IP du nouveau réseau virtuel
TestVNet5 ne chevauche aucune de vos plages de réseaux virtuels ou de passerelles de
réseau locales. Dans cet exemple, les réseaux virtuels peuvent appartenir à différentes
organisations. Pour cet exercice, vous pouvez utiliser les valeurs suivantes pour
TestVNet5 :

Localisation : Japon Est
TestVNet5 : 10.51.0.0/16 & 10.52.0.0/16
Front-end : 10.51.0.0/24
BackEnd : 10.52.0.0/24
GatewaySubnet : 10.52.255.0.0/27
Connexion : VNet5toVNet1

Cette étape doit être effectuée dans le cadre du nouvel abonnement. Cette partie peut
être effectuée par l’administrateur dans une organisation différente qui possède
l’abonnement.
1. Déclarez vos variables. Veillez à remplacer les valeurs par celles que vous souhaitez
utiliser pour votre configuration.
Azure PowerShell
$Sub5 = "Replace_With_the_New_Subscription_Name"
$RG5 = "TestRG5"
$Location5 = "Japan East"
$VnetName5 = "TestVNet5"
$GWSubName5 = "GatewaySubnet"
$VnetPrefix51 = "10.51.0.0/16"
$VnetPrefix52 = "10.52.0.0/16"
$FESubPrefix5 = "10.51.0.0/24"
$BESubPrefix5 = "10.52.0.0/24"
$GWSubPrefix5 = "10.52.255.0/27"
2. Connectez-vous à l’abonnement 5. Ouvrez la console PowerShell et connectez-

vous à votre compte. Utilisez l’exemple suivant pour faciliter votre connexion :
Azure PowerShell
Connect-AzAccount
Vérifiez les abonnements associés au compte.
Azure PowerShell
Get-AzSubscription
Spécifiez l’abonnement à utiliser.
Azure PowerShell
Select-AzSubscription -SubscriptionName $Sub5
Azure PowerShell
4. Créez les configurations de sous-réseau pour TestVNet5.
Azure PowerShell

$gwsub5 = New-AzVirtualNetworkSubnetConfig -Name $GWSubName5 -
Azure PowerShell
New-AzVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5 -Location

$Location5 `
-AddressPrefix $VnetPrefix51,$VnetPrefix52 -Subnet
6. Demandez une adresse IP publique
Azure PowerShell

$RG5 `
7. Créez la configuration de la passerelle.
Azure PowerShell
$vnet5 = Get-AzVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5

$gwipconf5 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName5 -
Subnet $subnet5 -PublicIpAddress $gwpip5
8. Créez la passerelle TestVNet5.
Azure PowerShell
New-AzVirtualNetworkGateway -Name $GWName5 -ResourceGroupName $RG5 -

-IpConfigurations $gwipconf5 -GatewayType Vpn -VpnType RouteBased -
GatewaySku VpnGw1
Étape 8 : créez les connexions

Dans cet exemple, étant donné que les passerelles se trouvent dans différents
abonnements, nous avons divisé cette étape en deux sessions PowerShell notées
[Abonnement 1] et [Abonnement 5].
1. [Abonnement 1] Obtenez la passerelle de réseau virtuel pour Abonnement 1.

Connectez-vous à Abonnement 1 avant d’exécuter l’exemple suivant :
Azure PowerShell

Copiez la sortie des éléments suivants et envoyez-la à l’administrateur

d’Abonnement 5 par message électronique ou une autre méthode.
Azure PowerShell
$vnet1gw.Name
$vnet1gw.Id
Ces deux éléments ont des valeurs similaires à l’exemple de sortie suivant :
PS D:\> $vnet1gw.Name
VNet1GW
PS D:\> $vnet1gw.Id
/subscriptions/b636ca99-6f88-4df4-a7c3-
2f8dc4545509/resourceGroupsTestRG1/providers/Microsoft.Network/virtualN
etworkGateways/VNet1GW
2. [Abonnement 5] Obtenez la passerelle de réseau virtuel pour Abonnement 5.

Connectez-vous à Abonnement 5 avant d’exécuter l’exemple suivant :
Azure PowerShell

Copiez la sortie des éléments suivants et envoyez-la à l’administrateur

d’Abonnement 1 par message électronique ou une autre méthode.
Azure PowerShell
$vnet5gw.Name
$vnet5gw.Id
Ces deux éléments ont des valeurs similaires à l’exemple de sortie suivant :
PS C:\> $vnet5gw.Name
VNet5GW
PS C:\> $vnet5gw.Id
/subscriptions/66c8e4f1-ecd6-47ed-9de7-
7e530de23994/resourceGroups/TestRG5/providers/Microsoft.Network/virtual
NetworkGateways/VNet5GW
3. [Abonnement 1] Créez la connexion TestVNet1 à TestVNet5. Dans cette étape, vous

créez la connexion de TestVNet1 à TestVNet5. La différence réside dans le fait que
$vnet5gw ne peut pas être obtenu directement, car il se trouve dans un
abonnement différent. Vous devez créer un objet PowerShell avec les valeurs
communiquées par Abonnement 1 dans les étapes précédentes. Utilisez l’exemple
ci-dessous. Remplacez le nom, l'ID et la clé partagée par vos propres valeurs. Il est
important que la clé partagée corresponde aux deux connexions. La création d’une
connexion peut prendre quelques instants.
Se connecter à Abonnement 1 avant d’exécuter l’exemple suivant :
Azure PowerShell
$vnet5gw = New-Object -TypeName

Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway
$vnet5gw.Name = "VNet5GW"
$vnet5gw.Id = "/subscriptions/66c8e4f1-ecd6-47ed-9de7-
7e530de23994/resourceGroups/TestRG5/providers/Microsoft.Network/virtual
NetworkGateways/VNet5GW"
ResourceGroupName $RG1 -VirtualNetworkGateway1 $vnet1gw -
VirtualNetworkGateway2 $vnet5gw -Location $Location1 -ConnectionType
Vnet2Vnet -SharedKey 'AzureA1b2C3'
4. [Abonnement 5] Créez la connexion TestVNet5 à TestVNet1. Cette étape est

similaire à celle présentée ci-dessus, sauf que vous créez la connexion de
TestVNet5 à TestVNet1. La procédure de création d’un objet PowerShell basé sur
les valeurs obtenues à partir d’Abonnement 1 s’applique également ici. Dans cette
étape, vérifiez que les clés partagées correspondent.
Se connecter à Abonnement 5 avant d’exécuter l’exemple suivant :
Azure PowerShell
$vnet1gw = New-Object -TypeName

Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway
$vnet1gw.Name = "VNet1GW"
$vnet1gw.Id = "/subscriptions/b636ca99-6f88-4df4-a7c3-
2f8dc4545509/resourceGroups/TestRG1/providers/Microsoft.Network/virtual
NetworkGateways/VNet1GW "
ResourceGroupName $RG5 -VirtualNetworkGateway1 $vnet5gw -
VirtualNetworkGateway2 $vnet1gw -Location $Location5 -ConnectionType
Vnet2Vnet -SharedKey 'AzureA1b2C3'
Vérification d’une connexion
） Important
Lorsque vous travaillez avec des sous-réseaux de passerelle, évitez d’associer un

groupe de sécurité réseau (NSG) au sous-réseau de passerelle. Associer un groupe
de sécurité réseau à ce sous-réseau peut empêcher votre passerelle de réseau
virtuel (passerelles VPN et ExpressRoute) de fonctionner comme prévu. Pour plus
d’informations sur les groupes de sécurité réseau, consultez Présentation du
groupe de sécurité réseau ?.
Vous pouvez vérifier que votre connexion a réussi via l’applet de commande « Get-
AzVirtualNetworkGatewayConnection » avec ou sans « -Debug ».
1. Utilisez l’exemple d’applet de commande suivant, en configurant les valeurs sur les
vôtres. Si vous y êtes invité, sélectionnez A pour exécuter tout. Dans l’exemple, « -
Name » fait référence au nom de la connexion que vous voulez tester.
Azure PowerShell
Get-AzVirtualNetworkGatewayConnection -Name VNet1toSite1 -

ResourceGroupName TestRG1
2. Une fois l’applet de commande exécutée, affichez les valeurs. Dans l’exemple ci-
dessous, l’état de la connexion indique « Connecté » et vous pouvez voir les octets
d’entrée et de sortie.
"connectionStatus": "Connected",
"ingressBytesTransferred": 33509044,
"egressBytesTransferred": 4142431
Forum Aux Questions sur l’interconnexion de

réseaux virtuels
Le FAQ relatif aux connexions de réseau virtuel à réseau virtuel s’applique aux
connexions de passerelle VPN. Pour plus d’informations sur le peering de réseaux
virtuels, voir Peering de réseaux virtuels.
Le trafic entre réseaux virtuels est-il facturé par Azure ?

Lorsque vous utilisez une connexion de passerelle VPN, le trafic de réseau virtuel à
réseau virtuel au sein d’une même région est gratuit dans les deux sens. Le trafic de
réseau virtuel à réseau virtuel de sortie entre différentes régions est facturé au tarif du
transfert de données sortantes entre réseaux virtuels en fonction des régions sources.
Pour plus d’informations, consultez la page Tarification Passerelle VPN . Si vous vous
connectez vos réseaux virtuels à l’aide du peering de réseaux virtuels, plutôt qu’à l’aide
d’une passerelle VPN, consultez la tarification de réseau virtuel .
Le trafic de réseau virtuel à réseau virtuel transite-t-il sur

Internet ?
Non. Le trafic de réseau virtuel à réseau virtuel transite sur la dorsale principale de
Microsoft Azure, et non sur Internet.
Puis-je établir une connexion de réseau virtuel à réseau

virtuel sur des locataires Azure Active Directory ?
Oui, les connexions de réseau virtuel à réseau virtuel avec des passerelles VPN Azure
fonctionnent sur des locataires Azure AD.
Le trafic de réseau virtuel à réseau virtuel est-il sécurisé ?

Oui, il est protégé par le chiffrement IPsec/IKE.
Ai-je besoin d’un périphérique VPN pour interconnecter

des réseaux virtuels ?
Non. L’interconnexion de plusieurs réseaux virtuels Azure ne requiert pas de
périphérique VPN, sauf si une connectivité intersite est nécessaire.
Mes réseaux virtuels doivent-ils se trouver dans la même

région ?
Non. Les réseaux virtuels peuvent être situés dans des régions (emplacements)
identiques ou différentes.
Si les réseaux virtuels ne figurent pas dans le même

abonnement, les abonnements doivent-ils être associés
au même locataire Active Directory ?
Non.
Puis-je utiliser la connexion de réseau virtuel à réseau

virtuel pour connecter des réseaux virtuels dans des
instances Azure séparées ?
Non. La connexion de réseau virtuel à réseau virtuel prend en charge la connexion de
réseaux virtuels au sein de la même instance Azure. Par exemple, vous ne pouvez pas
créer une connexion entre une instance Azure mondiale et des instances Azure du
gouvernement chinois, allemand ou américain. Pour ces scénarios, envisagez l’utilisation
d’une connexion VPN de site à site.
Puis-je utiliser une connexion de réseau virtuel à réseau

virtuel en plus de connexions multisites ?
Oui. Une connectivité réseau virtuelle peut être utilisée en même temps que des VPN
multisites.
À combien de sites locaux et de réseaux virtuels peut se

connecter un réseau virtuel ?
Consultez le tableau Conditions requises de la passerelle.
Puis-je utiliser une connexion de réseau virtuel à réseau

virtuel pour connecter des machines virtuelles ou des
services cloud en dehors d’un réseau virtuel ?
Non. La connexion de réseau virtuel à réseau virtuel prend en charge la connexion de
réseaux virtuels. Elle ne prend pas en charge la connexion de machines virtuelles ou de
services cloud qui ne se trouvent pas dans un réseau virtuel.
Un service cloud ou un point de terminaison

d’équilibrage de charge peut-il s’étendre sur différents
réseaux virtuels ?
Non. Un service cloud ou un point de terminaison d’équilibrage de charge ne peut pas
s’étendre sur différents réseaux virtuels, même si ces derniers sont interconnectés.
Puis-je utiliser un type de réseau VPN basé sur des

stratégies pour les connexions de réseau virtuel à réseau
virtuel ou multisites ?
Non. Les connexions de réseau virtuel à réseau virtuel et multisites nécessitent des
passerelles VPN Azure avec des types de VPN basés sur des itinéraires (dits auparavant
de routage dynamique).
Puis-je connecter un réseau virtuel avec un type de

réseau VPN basé sur des itinéraires à un autre réseau
virtuel avec un type de réseau VPN basé sur des
stratégies ?
Non, les deux réseaux virtuels DOIVENT utiliser des réseaux VPN basés sur des
itinéraires (dits auparavant de routage dynamique).
Les tunnels VPN se partagent-ils la bande passante ?
Oui. Tous les tunnels VPN du réseau virtuel partagent la bande passante disponible sur
la passerelle VPN Azure, ainsi que le même contrat SLA concernant le temps d’activité
des passerelles VPN dans Azure.
Les tunnels redondants sont pris en charge ?

Les tunnels redondants entre deux réseaux virtuels sont pris en charge lorsqu’une
passerelle de réseau virtuel est configurée comme active/active.
Des espaces d’adressage peuvent-ils se chevaucher pour

les configurations de réseau virtuel à réseau virtuel ?
Non. Il ne peut pas y avoir de chevauchement entre des plages d’adresses IP.
Des espaces d’adressage peuvent-ils se chevaucher entre

les réseaux virtuels connectés et les sites locaux ?
Non. Il ne peut pas y avoir de chevauchement entre des plages d’adresses IP.
Étapes suivantes
Une fois la connexion achevée, vous pouvez ajouter des machines virtuelles à vos
réseaux virtuels. Pour plus d’informations, consultez la documentation relative aux
machines virtuelles .
Pour plus d’informations sur le protocole BGP, consultez les articles Vue
d’ensemble du protocole BGP et Comment configurer BGP.
Connecter des réseaux virtuels utilisant
des modèles de déploiement différents
dans le portail
Article • 01/06/2023
Cet article vous explique comment connecter des réseaux virtuels classiques à des
réseaux virtuels Resource Manager afin de permettre aux ressources situées dans les
modèles de déploiement distincts de communiquer entre elles. Les étapes décrites dans
cet article utilisent principalement le portail Azure, mais vous pouvez également créer
cette configuration à l’aide de PowerShell en sélectionnant l’article dans cette liste.
Cet article est destiné aux clients qui disposent déjà d’un réseau virtuel créé à l’aide du
modèle de déploiement classique (hérité), et souhaitent connecter ce réseau virtuel
classique à un autre réseau virtuel créé à l’aide du modèle de déploiement le plus
récent. Si vous n’avez pas de réseau virtuel hérité, utilisez plutôt l’article Créer une
connexion de réseau virtuel à réseau virtuel.
Architecture
La connexion d’un réseau virtuel classique à un réseau virtuel Resource Manager est
semblable à la connexion d’un réseau virtuel à un emplacement de site local. Les deux
types de connectivité font appel à une passerelle VPN pour offrir un tunnel sécurisé
utilisant Ipsec/IKE. Vous pouvez créer une connexion entre des réseaux virtuels situés
dans des abonnements différents et des régions différentes. Vous pouvez également
connecter des réseaux virtuels qui disposent déjà de connexions à des réseaux locaux, à
condition que la passerelle soit dynamique ou basée sur un itinéraire. Pour plus
d’informations sur les connexions de réseau virtuel à réseau virtuel, consultez le Forum
Aux Questions sur l’interconnexion de réseaux virtuels.
Pour cette configuration, vous créez une connexion de passerelle VPN via un tunnel VPN
IPsec/IKE entre les réseaux virtuels. Assurez-vous que vos plages de réseau virtuel ne se
chevauchent pas entre elles ou avec un réseau local auquel elles se connectent.
Le tableau suivant montre comment les réseaux virtuels et les sites locaux sont définis :
Réseau virtuel Espace d’adressage Région Se connecte au site de réseau local
ClassicVNet (10.1.0.0/16) USA Ouest RMVNetSite (192.168.0.0/16)
RMVNet (192.168.0.0/16) USA Est ClassicVNetSite (10.1.0.0/16)

Prérequis
Ces étapes supposent que les deux réseaux virtuels ont déjà été créés. Si vous utilisez
cet article en guise d’exercice et que vous n’avez pas de réseaux virtuels, suivez les liens
disponibles dans les étapes pour vous aider à les créer.
Vérifiez que les plages d’adresses des réseaux virtuels ne se chevauchent pas ou ne
chevauchent aucune des plages des autres connexions susceptibles d’être utilisées
par les passerelles.
Dans cet article, nous utilisons le portail Azure et PowerShell. PowerShell est requis
pour créer la connexion à partir du réseau virtuel classique vers le réseau virtuel
Resource Manager. Installez les dernières cmdlets PowerShell de Resource
Manager et Gestion des services.
Bien qu’il soit possible d’exécuter certaines commandes PowerShell à l’aide de

l’environnement Azure Cloud Shell, vous devez installer les deux versions des
cmdlets pour créer correctement les connexions.
Applets de commande PowerShell de management des services (classique)

Lorsque vous installerez les applets de commande de management des services,
vous devrez peut-être modifier la stratégie d’exécution afin d’installer la version
classique du module Azure.
Applets de commande PowerShell AZ pour Resource Manager
Pour plus d’informations, consultez Installer et configurer Azure PowerShell.
Exemples de paramètres
Vous pouvez utiliser ces valeurs pour créer un environnement de test ou vous y référer
pour mieux comprendre les exemples de cet article.
Réseau virtuel classique
Nom du réseau virtuel = ClassicVNet

Espace d’adressage = 10.1.0.0/16
Nom du sous-réseau = Subnet1
Plage d’adresses du sous-réseau = 10.1.0.0/24
Abonnement = abonnement à utiliser
Groupe de ressources = ClassicRG
Emplacement = USA Ouest
Plage d’adresses du GatewaySubnet = 10.1.255.0/27
Nom du site local = RMVNetSite
Taille de la passerelle = Standard
Réseau virtuel Resource Manager
Nom du réseau virtuel = RMVNet

Groupe de ressources = RMRG
Emplacement = USA Est
Plage d’adresses = 192.168.1.0/24
GatewaySubnet = 192.168.255.0/27
Nom de passerelle de réseau virtuel = RMGateway
Type de passerelle = VPN
Type de VPN = Route-based
Référence (SKU) = VpnGw1
Emplacement = USA Est
Réseau virtuel = RMVNet (associer la passerelle VPN à ce réseau virtuel)
Première configuration IP = rmgwpip (adresse IP publique de la passerelle)
Passerelle de réseau local = ClassicVNetSite
Nom de la connexion = RM-Classic
Configurer le réseau virtuel classique

Dans cette section, vous créez le réseau virtuel classique, le réseau local (site local) et la
passerelle de réseau virtuel. Les captures d’écran sont fournies à titre d’exemple.
Assurez-vous de remplacer ces valeurs par les vôtres,ou utilisez les valeurs d’exemple.
Si vous disposez déjà d’un réseau virtuel avec une passerelle VPN, vérifiez que la
passerelle est dynamique. Si elle est statique, vous devez d’abord supprimer la
passerelle VPN avant de passer à Configurer le site et la passerelle.
1. Créer un réseau virtuel classique

Si vous n’avez pas de réseau virtuel classique et que vous utilisez ces étapes en guise
d’exercice, vous pouvez créer un réseau virtuel à l’aide des exemples de valeurs. Suivez
les étapes ci-dessous, en veillant à utiliser la méthode de navigation fournie pour créer
Exemples de valeurs
Détails du projet
Groupe de ressources = ClassicRG
Nom = ClassicVNet
Plage d’adresses du sous-réseau = 10.1.0.0/24
Emplacement = USA Ouest
1. Ouvrez le portail Azure et connectez-vous avec votre compte Azure.
） Important
Pour accéder à la page contenant l’option de création d’un réseau virtuel

classique, vous devez suivre les étapes ci-dessous.
2. Cliquez sur + Créer une ressource en haut de la page pour accéder à la page
Service Search et marketplace.
3. Dans le champ Services Search et marketplace, entrez « Réseau virtuel ».
4. Localisez Réseau virtuel dans la liste renvoyée et cliquez dessus pour ouvrir la
page Réseau virtuel.
5. Sur la page Réseau virtuel, dans le texte situé sous le bouton « Créer », cliquez sur
(basculer vers Classique) pour basculer vers le libellé Déployer avec Classique. Si
vous ne le faites pas, vous vous retrouverez avec un réseau virtuel Resource
Manager à la place.
6. Cliquez sur Créer pour ouvrir la page Créer un réseau virtuel (classique).
7. Renseignez les valeurs, puis cliquez sur Vérifier + créer et Créer pour créer votre
réseau virtuel classique.
2. Configurer le site classique et la passerelle de réseau

virtuel
1. Accédez à votre réseau virtuel classique.
2. Dans la liste du menu de gauche, cliquez sur Passerelle, puis cliquez sur la
bannière pour ouvrir la page de configuration d’une passerelle.
3. Sur la page Configurer une connexion VPN et une passerelle, accédez à l’onglet
Connexion et renseignez les valeurs, en utilisant les exemples de valeurs de
l’exercice si nécessaire.
Type de connexion = de site à site

Nom du site local = RMVNetSite
Adresse IP de la passerelle VPN = utilisez une valeur d’espace réservé si vous
ne connaissez pas l’adresse IP publique de la passerelle VPN Resource
Manager ou si vous n’en avez pas encore créé. Vous pourrez mettre à jour ce
paramètre ultérieurement.
Adresses des clients du site local = Plage d’adresses du réseau virtuel RM. Par
exemple, 192.168.0.0/16.
4. En bas de la page, cliquez sur Suivant : Passerelle pour passer à l’onglet Passerelle.
5. Sous l’onglet Passerelle, configurez les paramètres suivants :
Taille = Standard
Type de routage = Dynamique
6. Cliquez sur Vérifier + créer pour valider les paramètres.
7. Cliquez sur Créer pour créer la passerelle. La création de la passerelle peut prendre
jusqu’à 45 minutes. Pendant la configuration de la passerelle, vous pouvez passer
aux étapes suivantes.
Configurer le réseau virtuel Resource Manager

Dans cette section, vous allez créer le réseau virtuel RM et la passerelle VPN RM. Si vous
disposez déjà d’un réseau virtuel et d’une passerelle VPN Resource Manager, vérifiez
que la passerelle est basée sur un itinéraire.
1. Créer un réseau virtuel RM

Créez un réseau virtuel Resource Manager.
Pour connaître les différentes étapes, consultez Créer un réseau virtuel.
Exemples de valeurs :
Détails du projet
Nom du réseau virtuel = RMVNet
Région = USA Est
Adresses IP
Plage d’adresses = 192.168.1.0/24
2. Créer une passerelle de réseau virtuel RM

Créez ensuite l’objet de passerelle de réseau virtuel (passerelle VPN) de votre réseau
virtuel. La création d’une passerelle nécessite généralement au moins 45 minutes, selon
la référence SKU de passerelle sélectionnée.
Pour connaître les différentes étapes, consultez Créer une passerelle VPN.
Exemples de valeurs :
Nom = RMGateway
Région = USA Est
Type de passerelle = VPN
Type de VPN = Route-based
Référence SKU = VpnGw2
Génération = Génération 2
Réseau virtuel = RMVNet
Type d’adresse IP publique = De base
Adresse IP publique
Adresse IP publique = Créer
Nom de l’adresse IP publique = RMGWpip
3. Créer une passerelle de réseau local RM

Dans cette étape, vous allez créer la passerelle de réseau local. La passerelle de réseau
local est un objet qui spécifie la plage d’adresses et le point de terminaison d’adresse IP
publique associés à votre réseau virtuel classique et à la passerelle de réseau virtuel.
Pour connaître les étapes à suivre, consultez Créer une passerelle de réseau local.
Exemples de valeurs
Détails du projet
Région = USA Est
Nom = ClassicVNetSite
Point de terminaison = Adresse IP
Adresse IP = adresse IP publique de la passerelle de réseau virtuel classique Si
nécessaire, vous pouvez utiliser une adresse IP fictive, puis revenir en arrière et la
modifier ultérieurement.
Espace d’adressage = 10.1.0.0/16 (espace d’adressage du réseau virtuel classique)
Modifier les paramètres du site et de la

passerelle de réseau local
Une fois le déploiement des deux passerelles terminé, vous pouvez passer aux étapes
suivantes. Les étapes suivantes requièrent l’adresse IP publique attribuée à chaque
passerelle.
Modifier les paramètres du site local du réseau virtuel

classique
Dans cette section, vous allez modifier le site réseau local du réseau virtuel classique en
mettant à jour le champ de l’adresse IP publique avec l’adresse de la passerelle de
réseau virtuel Resource Manager.
1. Pour ces étapes, vous devez vous procurer l’adresse IP publique de la passerelle de
réseau virtuel Resource Manager. Vous trouverez l’adresse IP de la passerelle sur
la page Vue d’ensemble de la passerelle de réseau virtuel RM. Copiez l’adresse IP.
2. Accédez ensuite au réseau virtuel classique.
3. Dans le menu de gauche, cliquez sur Connexions de site à site pour ouvrir la page
correspondante.
4. Sous Nom, cliquez sur le nom du site RM que vous avez créé. Par exemple,
RMVNetSite. La page Propriétés de votre site local s’ouvre.
5. Sur la page Propriétés, cliquez sur Modifier le site local.
6. Remplacez l’adresse IP de la passerelle VPN par l’adresse IP publique attribuée à
la passerelle RMVNet (passerelle à laquelle vous souhaitez vous connecter).
7. Cliquez sur OK pour enregistrer les paramètres.
Modifier les paramètres de la passerelle de réseau local

du réseau virtuel RM
Dans cette section, vous allez modifier les paramètres de la passerelle de réseau local de
l’objet de passerelle de réseau local Resource Manager en mettant à jour le champ de
l’adresse IP publique avec l’adresse de la passerelle de réseau virtuel classique.
1. Pour ces étapes, vous devez vous procurer l’adresse IP publique de la passerelle de
réseau virtuel classique. Vous trouverez l’adresse IP de la passerelle sur la page
Vue d’ensemble du réseau virtuel classique.
2. Dans Toutes les ressources, recherchez la passerelle de réseau local. Dans notre
exemple, la passerelle de réseau local est ClassicVNetSite.
3. Dans le menu de gauche, cliquez sur Configuration et mettez à jour l’adresse IP.
Fermez la page.
Pour connaître les différentes étapes, consultez Modifier les paramètres de la passerelle
de réseau local.
Configurer des connexions

Cette section vous aide à connecter votre réseau virtuel classique à votre réseau virtuel
RM. À ce stade, toute tentative de connexion du réseau virtuel classique à partir du
portail échouera. Pour suivre les instructions de cette section, PowerShell doit être
installé localement sur votre ordinateur, comme indiqué dans les Prérequis.
Obtenir les valeurs du réseau virtuel classique

Lorsque vous créez un réseau virtuel sur le portail Azure, les valeurs complètes du nom
et du site ne sont pas visibles sur le portail. Par exemple, un réseau virtuel qui semble
être nommé « ClassicVNet1 » dans le portail Azure peut avoir un nom beaucoup plus
long dans le fichier de configuration réseau. Le nom peut ressembler à ceci : « Group
ClassicRG1 ClassicVNet1 ». Le nom du site réseau local peut également être beaucoup
plus long que celui qui apparaît sur le portail.
Au cours de ces étapes, vous allez télécharger le fichier de configuration du réseau et

vous procurer les valeurs à utiliser dans les sections suivantes.
1. Se connecter au compte Azure
Ouvrez la console PowerShell avec des droits élevés et connectez-vous à votre compte
Azure. Une fois que vous êtes connecté, vos paramètres de compte sont téléchargés
pour être reconnus par Azure PowerShell. Les cmdlets suivantes vous invitent à entrer
les informations de connexion de votre compte Azure pour le modèle de déploiement
Resource Manager :
1. Tout d’abord, connectez-vous à RM.

Connectez-vous pour utiliser les cmdlets RM.
PowerShell
Connect-AzAccount
2. Procurez-vous la liste de vos abonnements Azure (facultatif).
PowerShell
Get-AzSubscription
3. Si vous avez plusieurs abonnements, spécifiez celui que vous souhaitez utiliser.
PowerShell
Select-AzSubscription -SubscriptionName "Name of subscription"
4. Vous devez ensuite vous connecter aux cmdlets PowerShell du modèle de

déploiement classique.
Utilisez la commande suivante pour ajouter votre compte Azure pour le modèle de
déploiement classique :
PowerShell
Add-AzureAccount
5. Procurez-vous la liste de vos abonnements (facultatif).
PowerShell
Get-AzureSubscription
6. Si vous avez plusieurs abonnements, spécifiez celui que vous souhaitez utiliser.
PowerShell
Select-AzureSubscription -SubscriptionName "Name of subscription"
2. Afficher le fichier de configuration réseau

1. Créez un annuaire sur votre ordinateur. Pour notre exemple, nous avons créé un
répertoire appelé « AzureNet ».
2. Exportez le fichier de configuration réseau dans le répertoire. Dans cet exemple, le

fichier de configuration réseau est exporté vers C:\AzureNet.
PowerShell
Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml
3. Dans un éditeur de texte, ouvrez le fichier, puis affichez le nom de votre réseau
virtuel classique. Utilisez les noms indiqués dans le fichier de configuration réseau
lors de l’exécution de vos applets de commande PowerShell.
Les noms des réseaux virtuels sont répertoriés comme suit :

VirtualNetworkSite name =
Les noms de site sont répertoriés comme suit : LocalNetworkSite name=
3. Créer la connexion
Configurez la clé partagée et créez la connexion à partir du réseau virtuel classique vers
le réseau virtuel Resource Manager. Les connexions doivent être créées à l’aide de
PowerShell, et non du portail Azure.
En cas d’erreur, vérifiez que le site et les noms de réseau virtuel sont corrects. Assurez-
vous également que vous vous êtes authentifié pour les deux versions de PowerShell,
sinon vous ne pourrez pas définir la clé partagée.
Dans cet exemple, -VNetName est le nom du réseau virtuel classique, comme
indiqué dans votre fichier de configuration réseau.
-LocalNetworkSiteName est le nom que vous avez spécifié pour le site local,
comme indiqué dans votre fichier de configuration réseau. Utilisez le nom complet
du site, chiffres compris.
-SharedKey est une valeur que vous pouvez générer et spécifier. Pour cet exemple,
nous avons utilisé abc123, mais vous devez générer et utiliser une valeur plus
complexe. La valeur que vous spécifiez ici doit être identique à celle spécifiée lors
de la création de la connexion entre Resource Manager et le réseau classique.
1. Définissez la clé.
PowerShell
Set-AzureVNetGatewayKey -VNetName "Group ClassicRG ClassicVNet" `

-LocalNetworkSiteName "172B916_RMVNetSite" -SharedKey abc123
2. Créez la connexion VPN en exécutant les commandes suivantes. Veillez à modifier
les commandes pour les adapter à votre environnement.
Définissez les variables.
PowerShell
$vnet01gateway = Get-AzLocalNetworkGateway -Name ClassicVNetSite -

ResourceGroupName RMRG
$vnet02gateway = Get-AzVirtualNetworkGateway -Name RMGateway -
ResourceGroupName RMRG
Créez la connexion. Notez que le type de connexion -ConnectionType est IPsec et

pas Vnet2Vnet.
PowerShell
New-AzVirtualNetworkGatewayConnection -Name RM-Classic -

ResourceGroupName RMRG `
-Location "East US" -VirtualNetworkGateway1 `
$vnet02gateway -LocalNetworkGateway2 `
$vnet01gateway -ConnectionType IPsec -RoutingWeight 10 -SharedKey
'abc123'
Vérifiez vos connexions

Vous pouvez vérifier vos connexions à l’aide du portail Azure ou de PowerShell. Lors de
la vérification, vous devrez peut-être patienter quelques minutes, le temps que la
connexion soit créée. Lorsqu’une connexion est réussie, l’état de connectivité passe de
« Connexion » à « Connecté ».
Vérifier la connexion entre le réseau virtuel classique et

RM
Dans le portail Azure, vous pouvez afficher l’état de la connexion pour une passerelle
VPN de réseau virtuel classique en accédant à cette dernière. Les étapes suivantes
montrent un moyen d’accéder à votre connexion pour la vérifier.
1. Sur le portail Azure , accédez à votre réseau virtuel classique .

2. Sur la page Réseau virtuel, cliquez sur le type de connexion que vous souhaitez
afficher. Par exemple, les Connexions site à site.
3. Dans la page Connexions de site à site, sous Nom, sélectionnez la connexion au
site que vous souhaitez afficher.
4. Dans la page Propriétés, affichez les informations relatives à la connexion.
Vérifier la connexion entre les réseaux virtuels RM et

classique
Dans le Portail Azure, vous pouvez afficher l’état de la connexion d’une passerelle VPN
en accédant à cette connexion. Les étapes suivantes montrent un moyen d’accéder à
votre connexion pour la vérifier.
1. Sur le portail Azure , accédez à votre passerelle de réseau virtuel.

2. Sur la page de votre passerelle de réseau virtuel, cliquez sur Connexions. Vous
pouvez voir l’état de chaque connexion.
3. Cliquez sur le nom de la connexion que vous souhaitez vérifier. Dans Essentials,
vous pouvez afficher plus d’informations sur la connexion. Les valeurs Statut
indiquent « Opération réussie » et « Connecté » lorsqu’une connexion a été
établie.
Étapes suivantes
Pour plus d’informations sur les connexions de réseau virtuel à réseau virtuel, consultez
le Forum Aux Questions sur la passerelle VPN.
Tutoriel : Créer une connexion VPN site
à site dans le portail Azure
Article • 26/04/2023
Ce tutoriel vous explique comment utiliser le portail Azure pour créer une connexion de
passerelle VPN de site à site entre votre réseau local et un réseau virtuel. Vous pouvez
également créer cette configuration en utilisant Azure PowerShell ou Azure CLI.
＂ Créez un réseau virtuel

＂ Créer une passerelle VPN
＂ Créer une passerelle de réseau local
＂ Créer une connexion VPN
＂ Vérifier la connexion
＂ Connexion à une machine virtuelle
Prérequis
Compte Azure avec un abonnement actif. Si vous n’en avez pas, créez-en une
gratuitement .
Veillez à disposer d’un périphérique VPN compatible et à être entouré d’une
personne en mesure de le configurer. Pour plus d’informations sur les
périphériques VPN compatibles et la configuration de votre périphérique,
consultez l’article À propos des périphériques VPN.
Vérifiez que vous disposez d’une adresse IPv4 publique exposée en externe pour
votre périphérique VPN.
Si vous ne maîtrisez pas les plages d’adresses IP situées dans votre configuration
de réseau local, vous devez contacter une personne en mesure de vous aider.
Lorsque vous créez cette configuration, vous devez spécifier les préfixes des plages
d’adresses IP qu’Azure acheminera vers votre emplacement local. Aucun des sous-
réseaux de votre réseau local ne peut chevaucher les sous-réseaux du réseau
virtuel auquel vous souhaitez vous connecter.

Dans cette section, vous allez créer un réseau virtuel en utilisant les valeurs suivantes :

Nom : VNet1
Région : (États-Unis) USA Est
Espace d’adressage IPv4 : 10.1.0.0/16
Nom du sous-réseau : FrontEnd
Espace d’adressage du sous-réseau : 10.1.0.0/24
７ Notes
Quand vous utilisez un réseau virtuel dans le cadre d’une architecture incluant
différents locaux, veillez à prendre contact avec votre administrateur de réseau
local pour définir une plage d’adresses IP à utiliser spécifiquement pour ce réseau
virtuel. Si une plage d’adresses en double existe des deux côtés de la connexion
VPN, le trafic sera acheminé de manière inattendue. En outre, si vous souhaitez
connecter ce réseau à un autre réseau virtuel, l’espace d’adressage ne peut pas
chevaucher celui de l’autre réseau virtuel. Planifiez votre configuration réseau en
conséquence.
2. Dans Rechercher dans les ressources, services et documents (G+/), saisissez

réseau virtuel. Sélectionnez Réseau virtuel dans les résultats de Place de marché
pour ouvrir la page Réseau virtuel.
3. Dans la page Réseau virtuel, sélectionnez Créer. La page Créer un réseau virtuel
s’ouvre.
4. Sous l’onglet Informations de base, configurez les paramètres de réseau virtuel
pour Détails du projet et Détails de l’instance. Une coche verte apparaît lorsque
les valeurs entrées sont validées. Les valeurs affichées dans l’exemple peuvent être
ajustées en fonction des paramètres dont vous avez besoin.
Abonnement: vérifiez que l’abonnement listé est approprié. Vous pouvez

modifier des abonnements à l’aide de la liste déroulante.
Groupe de ressources : sélectionnez un groupe de ressources existant ou
sélectionnez Créer nouveau pour en créer un. Pour plus d’informations sur
les groupes de ressources, consultez Vue d’ensemble d’Azure Resource
Manager.
Name : entrez le nom du réseau virtuel.
Région : sélectionnez l’emplacement du réseau virtuel. L’emplacement
détermine où se trouveront les ressources que vous déployez sur ce réseau
virtuel.
5. Sélectionnez Adresses IP pour passer à l’onglet Adresses IP. Sous l’onglet

Adresses IP, configurez les paramètres.
Espace d’adressage IPv4 : Un espace d’adressage est créé automatiquement

par défaut. Vous pouvez sélectionner l’espace d’adressage et le définir selon
vos propres valeurs. Vous pouvez également ajouter d’autres espaces
d’adressage en sélectionnant la boîte sous l’espace d’adressage existant et en
spécifiant les valeurs de l’espace d’adressage supplémentaire. Par exemple,
vous pouvez modifier le champ d’adresse IPv4 en 10.1.0.0/16 à partir des
valeurs par défaut qui sont automatiquement renseignées.
+ Ajouter un sous-réseau : si vous utilisez l’espace d’adressage par défaut,
un sous-réseau par défaut est créé automatiquement. Si vous modifiez
l’espace d’adressage, vous devez ajouter un sous-réseau. Sélectionnez +
Ajouter un sous-réseau pour ouvrir la fenêtre Ajouter un sous-réseau.
Configurez les paramètres suivants, puis sélectionnez Ajouter en bas de la
page pour ajouter les valeurs.
Nom du sous-réseau : Exemple : FrontEnd.
Plage d’adresses de sous-réseau : plage d’adresses de ce sous-réseau. Par
exemple : 10.1.0.0/24.
6. Sélectionnez Sécurité pour accéder à l’onglet Sécurité. Conservez les valeurs par
défaut pour cet exercice.
BastionHost : Désactiver
Protection DDoS Standard : Désactiver
Pare-feu : Désactiver
7. Sélectionnez Vérifier + créer pour vérifier les paramètres de réseau virtuel.
8. Une fois les paramètres validés, sélectionnez Créer pour créer le réseau virtuel.
Créer une passerelle VPN

Dans cette étape, vous créez la passerelle de réseau virtuel de votre réseau virtuel. La
création d’une passerelle nécessite généralement au moins 45 minutes, selon la
référence SKU de passerelle sélectionnée.
À propos du sous-réseau de passerelle

La passerelle de réseau virtuel utilise un sous-réseau spécifique, appelé sous-réseau de
passerelle. Le sous-réseau de passerelle fait partie de la plage d’adresses IP du réseau
virtuel que vous spécifiez lors de la configuration de votre réseau virtuel. Il contient les
adresses IP utilisées par les ressources et les services de passerelle de réseau virtuel.
Lorsque vous créez le sous-réseau de passerelle, vous spécifiez le nombre d’adresses IP

que contient le sous-réseau. Le nombre d’adresses IP requises varie selon la
configuration de la passerelle VPN que vous souhaitez créer. Certaines configurations
nécessitent plus d’adresses IP que d’autres. Nous vous recommandons de créer un sous-
réseau de passerelle dont la taille est définie sur /27 ou /28.
Si une erreur s’affiche indiquant que l’espace d’adressage chevauche un sous-réseau ou

que le sous-réseau n’est pas contenu dans l’espace d’adressage de votre réseau virtuel,
vérifiez la plage d’adresses de votre réseau virtuel. Vous n’avez peut-être pas
suffisamment d’adresses IP disponibles dans la plage d’adresses que vous avez créée
pour votre réseau virtuel. Par exemple, si votre sous-réseau par défaut englobe la plage
d’adresses complète, il n’y a plus d’adresses IP disponibles pour créer des sous-réseaux
supplémentaires. Vous pouvez ajuster vos sous-réseaux au sein de l’espace d’adressage
existant pour libérer des adresses IP, ou spécifier une plage d’adresses supplémentaire
pour y créer le sous-réseau de passerelle.
Créer la passerelle
Créez une passerelle de réseau virtuel (passerelle VPN) en utilisant les valeurs suivantes :
Nom : VNet1GW
Région : USA Est
Type de passerelle : VPN
Type de VPN : basé sur la route
Référence SKU : VpnGw2
Génération : Génération 2
Réseau virtuel : VNet1
Plage d’adresses du sous-réseau de passerelle : 10.1.255.0/27
Adresse IP publique : Création
Nom de l'adresse IP publique : VNet1GWpip
Activer le mode actif/actif : Désactivé
Configurer BGP : Désactivé
1. Dans Rechercher dans les ressources, services et documents (G+/) , tapez

passerelle de réseau virtuel. Recherchez la passerelle réseau virtuel dans les
résultats de la recherche de la Place de marché et sélectionnez-la pour ouvrir la
page Créer une passerelle réseau virtuel.
2. Sous l’onglet Général, renseignez les valeurs pour Détails du projet et Détails de
l’instance.

Abonnement: Sélectionnez l’abonnement à utiliser dans la liste déroulante.

Groupe de ressources : Ce paramètre est renseigné automatiquement quand
vous sélectionnez votre réseau virtuel sur cette page.
Name : Nommez votre passerelle. Le nommage de votre passerelle n’est pas
identique au nommage d’un sous-réseau de passerelle. Il s’agit du nom de
l’objet passerelle que vous créez.
Région : Sélectionnez la région où vous voulez créer cette ressource. La
région de la passerelle doit être la même que celle du réseau virtuel.
Type de passerelle : Sélectionnez VPN. Les passerelles VPN utilisent le type
de passerelle de réseau virtuel VPN.
Type de VPN : sélectionnez le type de VPN spécifié pour votre configuration.
La plupart des configurations requièrent un type de VPN basé sur un
itinéraire.
Niveau tarifaire : sélectionnez le niveau tarifaire (SKU) de la passerelle que
vous voulez utiliser dans la liste déroulante. Les références répertoriées dans
la liste déroulante dépendent du type de VPN que vous sélectionnez. Veillez à
sélectionner une référence (SKU) qui prend en charge les fonctionnalités que
vous voulez utiliser. Par exemple, si vous sélectionnez une référence SKU « AZ
» comme « VPNGw2AZ », vous sélectionnez une référence SKU de zone de
disponibilité avec des paramètres différents de ceux indiqués dans cet
exemple. Pour en savoir plus, voir Passerelle de réseau virtuel redondante
interzone dans les zones de disponibilité Azure. Pour plus d’informations sur
les références de passerelle, consultez Références (SKU) de passerelle.
Génération : sélectionnez la génération que vous voulez utiliser. Pour plus
d’informations, consultez l’article Références (SKU) de passerelle.
Réseau virtuel : sélectionnez le réseau virtuel auquel vous souhaitez ajouter
cette passerelle dans la liste déroulante. Si vous ne voyez pas le VNet pour
lequel vous voulez créer une passerelle, assurez-vous que vous avez
sélectionné l’abonnement et la région corrects dans les paramètres
précédents.
Plage d’adresses de sous-réseau de la passerelle : Ce champ apparaît
uniquement si votre réseau virtuel n’a pas de sous-réseau de passerelle. Il est
préférable de spécifier /27 ou plus grand (/26, /25, etc.). Ceci permet
d’obtenir suffisamment d’adresses IP pour les modifications futures, comme
l’ajout d’une passerelle ExpressRoute. Nous vous déconseillons de créer une
plage inférieure à /28. Si vous disposez déjà d’un sous-réseau de passerelle,
vous pouvez en voir les détails en accédant à votre réseau virtuel.
Sélectionnez Sous-réseaux pour afficher la plage. Si vous souhaitez modifier
la plage, vous pouvez supprimer et recréer le sous-réseau de passerelle.
3. Spécifiez les valeurs pour Adresse IP publique. Ces paramètres spécifient l’objet
d’adresse IP publique associé à la passerelle VPN. L’adresse IP publique est
attribuée à cet objet pendant la création de la passerelle VPN. L’adresse IP
publique primaire change uniquement lorsque la passerelle est supprimée, puis
recréée. Elle n’est pas modifiée lors du redimensionnement, de la réinitialisation ou
des autres opérations de maintenance/mise à niveau internes de votre passerelle
VPN.

Type d’adresse IP publique : vous pouvez choisir De base ou Standard.

Adresse IP publique : Laissez l’option Créer sélectionnée.
Nom de l’adresse IP publique : Dans la zone de texte, tapez un nom pour
votre instance d’adresse IP publique.
Référence SKU d’adresse IP publique : ce champ est contrôlé par la valeur
Type d’adresse IP publique.
Affectation : ce paramètre est basé sur la valeur Type d’adresse IP publique .
Activer le mode actif/actif : sélectionnez uniquement Activer le mode
actif/actif si vous créez une configuration de passerelle active/active. Sinon,
laissez ce paramètre Désactivé.
Laissez l’option Configurer BGP définie sur Désactivé, sauf si votre
configuration exige spécifiquement ce paramètre. Si vous avez besoin de ce
paramètre, la valeur par défaut ASN est 65515, même si vous pouvez la
changer.
4. Sélectionnez Vérifier + créer pour exécuter la validation.
5. Une fois la validation réussie, sélectionnez Créer pour déployer la passerelle VPN.
Vous pouvez voir l’état du déploiement dans la page Vue d’ensemble pour votre
passerelle. La création et le déploiement complets d’une passerelle peuvent prendre
jusqu’à 45 minutes. Une fois la passerelle créée, examinez le réseau virtuel dans le
portail pour obtenir l’adresse IP affectée à la passerelle. Cette dernière apparaît sous la
forme d’un appareil connecté.
） Important
Lorsque vous travaillez avec des sous-réseaux de passerelle, évitez d’associer un
groupe de sécurité réseau (NSG) au sous-réseau de passerelle. Associer un groupe
de sécurité réseau à ce sous-réseau peut empêcher votre passerelle de réseau
virtuel (passerelles VPN et ExpressRoute) de fonctionner comme prévu. Pour plus
d’informations sur les groupes de sécurité réseau, consultez Présentation du
groupe de sécurité réseau ?.
Afficher l’adresse IP publique

Vous pouvez voir l’adresse IP publique de la passerelle dans la page Vue d’ensemble de
votre passerelle.
Pour voir d’autres informations sur l’objet d’adresse IP publique, sélectionnez le lien de
nom/adresse IP à côté de Adresse IP publique.
Créer une passerelle de réseau local

La passerelle réseau locale est un objet spécifique qui représente votre emplacement
local (le site) à des fins de routage. Donnez au site un nom auquel Azure pourra se
référer, puis spécifiez l’adresse IP du périphérique VPN local vers lequel vous allez créer
une connexion. Spécifiez également les préfixes d’adresses IP qui seront acheminés via
la passerelle VPN vers le périphérique VPN. Les préfixes d’adresses que vous spécifiez
sont les préfixes situés sur votre réseau local. En cas de modification du réseau ou si
vous devez modifier l’adresse IP publique de l’appareil VPN, il est simple de mettre à
jour les valeurs ultérieurement.
Créez une passerelle de réseau local à l’aide des valeurs suivantes :
Nom : Site1
1. À partir du portail Azure , dans Rechercher dans les ressources, services et
documents (G+/) , saisissez Passerelle de réseau local. Recherchez la Passerelle de
réseau local sous Place de marché dans les résultats de la recherche, puis
sélectionnez-la. La page Créer une passerelle de réseau local s’ouvre.
2. Dans la page Créer une passerelle réseau locale, sous l’onglet De base, spécifiez
les valeurs de votre passerelle réseau locale.
Abonnement : Vérifiez que l’abonnement approprié s’affiche.

Groupe de ressources : Sélectionnez le groupe de ressources à utiliser. Vous
pouvez créer un groupe de ressources ou en sélectionner un déjà créé.
Région : sélectionnez la région dans laquelle cet objet sera créé. Vous pouvez
sélectionner l’emplacement dans lequel se trouve votre réseau virtuel, mais
vous n’êtes pas obligé de le faire.
Nom : Spécifiez un nom pour votre objet de passerelle de réseau local.
Point de terminaison : sélectionnez le type de point de terminaison du
périphérique VPN local, à savoir Adresse IP ou Nom de domaine complet
(FQDN) .
Adresse IP : si une adresse IP publique statique vous a été allouée à partir
de votre fournisseur de services Internet pour votre périphérique VPN,
sélectionnez l’option Adresse IP et précisez l’adresse IP comme indiqué
dans l’exemple. Il s’agit de l’adresse IP publique du périphérique VPN
auquel vous souhaitez que la passerelle Azure VPN se connecte. Si vous ne
disposez pas de l’adresse IP actuellement, vous pouvez utiliser les valeurs
indiquées dans l’exemple. Toutefois, vous devrez revenir en arrière et
remplacer votre adresse IP d’espace réservé par l’adresse IP publique de
votre périphérique VPN. Dans le cas contraire, Azure ne sera pas en
mesure de se connecter.
FQDN : si vous disposez d’une adresse IP publique dynamique qui peut
changer après un certain laps de temps, souvent déterminé par votre
fournisseur de services Internet, vous pouvez utiliser un nom DNS constant
avec un service DNS dynamique qui pointe vers l’adresse IP publique
actuelle de votre périphérique VPN. Votre passerelle VPN Azure résoudra
le nom FQDN pour savoir à quelle adresse IP publique se connecter.
Espace d’adressage fait référence aux plages d’adresses du réseau qui
représente ce réseau local. Vous pouvez ajouter plusieurs plages d’espaces
d’adressage. Assurez-vous que les plages que vous spécifiez ici ne se
chevauchent pas avec les plages d’autres réseaux auxquels vous souhaitez
vous connecter. Azure achemine la plage d’adresses que vous spécifiez vers
l’adresse IP du périphérique VPN local. Utilisez ici vos propres valeurs (et non
les valeurs indiquées dans l’exemple) si vous voulez vous connecter à votre site
local.
７ Notes
Le VPN Azure ne prend en charge qu’une seule adresse IPv4 par nom
FQDN. Si le nom de domaine est résolu en plusieurs adresses IP, la
passerelle VPN Azure utilise la première adresse IP retournée par les
serveurs DNS. Pour éliminer toute incertitude, nous vous recommandons
que le nom FQDN soit toujours résolu en une seule adresse IPv4. IPv6
n’est pas pris en charge.
La passerelle VPN Azure actualise un cache DNS toutes les 5 minutes.
Elle ne tente de résoudre les noms FQDN que pour les tunnels
déconnectés. La réinitialisation de la passerelle déclenche également la
résolution des noms FQDN.
3. Sous l’onglet Avancé, vous pouvez configurer les paramètres BGP si nécessaire.
4. Quand vous avez terminé de spécifier les valeurs, sélectionnez Vérifier + créer au
bas de la page pour valider la page.
5. Sélectionnez Créer pour créer l’objet de passerelle de réseau local.
Configuration de votre périphérique VPN

Les connexions de site à site vers un réseau local nécessitent un appareil VPN. Dans
cette étape, vous configurez votre périphérique VPN. Lorsque vous configurez votre
périphérique VPN, vous avez besoin des valeurs suivantes :
Une clé partagée. Il s’agit de la clé partagée spécifiée lors de la création de la

connexion VPN de site à site. Dans nos exemples, nous utilisons une clé partagée
basique. Nous vous conseillons de générer une clé plus complexe.
L’adresse IP publique de votre passerelle de réseau virtuel. Vous pouvez afficher
l’adresse IP publique à l’aide du portail Azure, de PowerShell ou de l’interface de
ligne de commande. Pour rechercher l’adresse IP publique de votre passerelle VPN
à l’aide du Portail Azure, accédez à Passerelles de réseau virtuel, puis sélectionnez
le nom de votre passerelle.
Pour télécharger des script de configuration de périphérique VPN :
En fonction du périphérique VPN dont vous disposez, vous pourrez peut-être

télécharger un script de configuration de périphérique VPN. Pour plus d’informations,
consultez la page Télécharger des script de configuration de périphérique VPN.
Pour plus d’informations sur la configuration, consultez les liens suivants :
Pour plus d’informations sur les périphériques VPN compatibles, consultez la page
Périphériques VPN.
Avant de configurer votre périphérique VPN, identifiez également les éventuels

Problèmes de compatibilité connus avec le matériel pour le périphérique VPN que
vous souhaitez utiliser.
Vous trouverez des liens vers les paramètres de configuration des périphériques
sur la page Périphériques VPN validés. Les liens de configuration des périphériques
sont fournis dans la mesure du possible. Il est toujours préférable de vérifier les
dernières informations de configuration auprès du fabricant du périphérique. La
liste répertorie les versions que nous avons testées. L’absence de votre système
d’exploitation de cette liste n’exclut pas sa compatibilité. Pour savoir si la version
du système d’exploitation de votre périphérique VPN est compatible, renseignez-
vous auprès du fabricant de ce périphérique.
Pour une vue d’ensemble de la configuration du périphérique VPN, consultez Vue

d’ensemble des configurations de périphériques VPN tiers.
Pour plus d’informations sur la modification des exemples de configuration des

périphériques, consultez la page Modifier les exemples.
Pour les exigences de chiffrement, consultez sur les exigences de chiffrement et les
passerelles VPN Azure.
Pour en savoir plus sur les paramètres IPsec/IKE, consultez À propos des
périphériques VPN et des paramètres IPsec/IKE pour les connexions de passerelle
VPN site à site. Cette section contient des informations sur la version IKE version, le
groupe Diffie-Hellman, la méthode d’authentification, les algorithmes de
chiffrement et de hachage, la durée de vie de l’association de sécurité, le
paramètre PFS et la détection d’homologue mort, ainsi que des informations sur
les autres paramètres dont vous avez besoin pour effectuer votre configuration.
Pour les étapes de configuration de stratégie IPsec/IKE, consultez Configure

IPsec/IKE policy for S2S VPN or VNet-to-VNet connections (Configurer la stratégie
IPsec/IKE pour les connexions VNet-à-VNet ou VPN S2S.
Pour connecter plusieurs périphériques VPN basés sur des stratégies, consultez
Connecter des passerelles VPN à plusieurs périphériques VPN basés sur des
stratégies via PowerShell.
Créer des connexions VPN

Créez une connexion VPN site à site entre votre passerelle de réseau virtuel et votre
périphérique VPN local.
Créez une connexion à l’aide des valeurs suivantes :
Nom de passerelle de réseau local : Site1

Nom de la connexion : VNet1toSite1
Clé partagée : pour cet exemple, nous utilisons abc123. Toutefois, vous pouvez
utiliser n’importe quelle valeur compatible avec votre matériel VPN. L’important est
que les valeurs soient les mêmes de part et d’autre de la connexion.
1. Accédez à votre réseau virtuel. Sur la page de votre réseau virtuel, sélectionnez
Appareils connectés à gauche. Recherchez votre passerelle VPN et cliquez dessus
pour l’ouvrir.
2. Dans la page de votre passerelle, sélectionnez Connexions. En haut du panneau
Connexions, sélectionnez +Ajouter pour ouvrir la page Ajouter une connexion.
3. Sur la page Ajouter une connexion, configurez les valeurs de votre connexion.
Nom : Nommez votre connexion.

Type de connexion : Sélectionnez Site à site (IPsec) .
Passerelle de réseau virtuel : la valeur est fixe, car vous vous connectez à
partir de cette passerelle.
Passerelle de réseau local : Sélectionnez Choisir une passerelle de réseau
local, puis sélectionnez la passerelle de réseau local à utiliser.
Clé partagée : la valeur doit correspondre à celle que vous utilisez pour votre
périphérique VPN local. Dans cet exemple, nous avons utilisé « abc123 »,
mais vous pouvez (et devriez) utiliser une valeur plus complexe. Il est
important que la valeur que vous spécifiez ici soit identique à celle spécifiée
lors de la configuration de votre périphérique VPN.
Laissez l’option Utiliser une adresse IP privée Azure décochée.
Laissez l’option Activer BGP décochée.
Sélectionnez IKEv2.
4. Sélectionnez OK pour créer votre connexion. Le message Création de la connexion

clignote à l'écran.
5. Vous pouvez afficher la connexion dans la page Connexions de la passerelle de

réseau virtuel. L’état passe de Inconnu à Connexion, puis à Réussi.
Pour configurer des paramètres de connexion
supplémentaires (facultatif)
Si nécessaire, vous pouvez configurer des paramètres supplémentaires pour votre
connexion. Sinon, ignorez cette section et laissez les valeurs par défaut en place. Pour
plus d’informations, consultez Configurer des stratégies de connexion IPsec/IKE
personnalisées.
1. Accédez à votre passerelle de réseau virtuel et sélectionnez Connexions pour

ouvrir la page Connexions.
2. Sélectionnez le nom de la connexion que vous souhaitez configurer pour ouvrir la

page Connexion .
3. Sur la page Connexion à gauche, sélectionnez Configuration pour ouvrir la page

Configuration. Apportez les modifications nécessaires, puis Enregistrez.
Dans la capture d’écran suivante, nous avons activé tous les paramètres pour
afficher les paramètres de configuration disponibles dans le portail. Cliquez sur la
capture d’écran pour afficher la vue développée. Lorsque vous configurez vos
connexions, configurez uniquement les paramètres dont vous avez besoin. Sinon,
conservez le paramètre par défaut.
Vérifier la connexion VPN

Dans le portail Azure, vous pouvez afficher l’état de la connexion d’une passerelle VPN
en accédant à cette connexion. Les étapes suivantes montrent un moyen d’accéder à
votre connexion pour la vérifier.
1. Dans le menu du portail Azure , sélectionnez Toutes les ressources ou recherchez
et sélectionnez Toutes les ressources dans n’importe quelle page.
2. Sélectionnez votre passerelle de réseau virtuel.
3. Dans le panneau de votre passerelle de réseau virtuel, cliquez sur Connexions.
Vous pouvez voir l’état de chaque connexion.
4. Cliquez sur le nom de la connexion que vous souhaitez vérifier pour ouvrir
Essentials. Dans Essentials, vous pouvez afficher plus d’informations sur la
connexion. Ce champ indique « Opération réussie » et « Connecté » lorsqu’une
connexion a été établie.

Vous pouvez vous connecter à une machine virtuelle déployée sur votre réseau virtuel
en créant une connexion Bureau à distance à votre machine virtuelle. La meilleure
méthode pour vérifier initialement que vous pouvez vous connecter à votre machine
virtuelle consiste à vous connecter à l’aide de son adresse IP privée, plutôt qu’avec le
nom d’ordinateur. Vous testez ainsi si vous pouvez vous connecter, que la résolution de
nom soit configurée correctement ou non.
1. Recherchez l’adresse IP privée. L’adresse IP privée d’une machine virtuelle peut être
trouvée en étudiant les propriétés de la machine virtuelle dans le portail Azure ou
à l’aide de PowerShell.
Portail Azure : recherchez votre machine virtuelle dans le portail Azure.

Affichez les propriétés de la machine virtuelle. L’adresse IP privée est
répertoriée.
PowerShell : utilisez l’exemple pour afficher la liste des machines virtuelles et

adresses IP privées de vos groupes de ressources. Vous n’avez pas besoin de
modifier cet exemple pour pouvoir l’utiliser.
Azure PowerShell
$VMs = Get-AzVM
$Nics = Get-AzNetworkInterface | Where-Object VirtualMachine -ne
$null
foreach ($Nic in $Nics) {

$VM = $VMs | Where-Object -Property Id -eq $Nic.VirtualMachine.Id
$Prv = $Nic.IpConfigurations | Select-Object -ExpandProperty
PrivateIpAddress
$Alloc = $Nic.IpConfigurations | Select-Object -ExpandProperty
PrivateIpAllocationMethod
Write-Output "$($VM.Name): $Prv,$Alloc"
}
2. Vérifiez que vous êtes connecté à votre VNet.
3. Ouvrez une connexion Bureau à distance en saisissant « RDP » ou « Connexion

Bureau à distance » dans la zone de recherche de la barre des tâches, puis
sélectionnez la connexion Bureau à distance. Vous pouvez également ouvrir une
connexion Bureau à distance à l’aide de la commande « mstsc » dans PowerShell.
4. Dans Connexion Bureau à distance, entrez l’adresse IP privée de la machine

virtuelle. Vous pouvez sélectionner « Afficher les options » pour définir des
paramètres supplémentaires, puis connectez-vous.
Résoudre les problèmes d’une connexion
Si vous rencontrez des problèmes de connexion à une machine virtuelle sur votre
connexion VPN, vérifiez les points suivants :
Vérifiez que votre connexion VPN aboutit.
Vérifiez que vous vous connectez à l’adresse IP privée de la machine virtuelle.
Si vous pouvez vous connecter à la machine virtuelle à l’aide de l’adresse IP privée,

mais pas à l’aide du nom d’ordinateur, vérifiez que vous avez correctement
configuré DNS. Pour plus d’informations sur le fonctionnement de la résolution de
noms pour les machines virtuelles, consultez Résolution de noms pour les
Pour plus d’informations sur les connexions RDP, consultez Résoudre des
problèmes de connexion Bureau à distance à une machine virtuelle.
Étapes facultatives
Redimensionner une référence SKU de passerelle

Il existe des règles spécifiques relatives au redimensionnement et à la modification
d’une référence SKU de passerelle. Dans cette section, nous allons redimensionner la
référence SKU. Pour plus d’informations, consultez Paramètres de la passerelle :
Redimensionnement ou modification d’une référence SKU.
1. Accédez à la page Configuration pour votre passerelle de réseau virtuel.
2. Sur le côté droit de la page, cliquez sur la flèche déroulante pour afficher les
références SKU de passerelle disponibles.

3. Sélectionnez la référence SKU dans la liste déroulante.
Réinitialiser une passerelle

La réinitialisation d’une passerelle VPN Azure est utile si vous perdez la connectivité VPN
entre différents locaux sur un ou plusieurs tunnels VPN site à site. Dans ce cas, vos
périphériques VPN locaux fonctionnent tous correctement, mais ils ne sont pas en
mesure d’établir des tunnels IPsec avec les passerelles VPN Azure.
1. Dans le portail, accédez à la passerelle de réseau virtuel que vous souhaitez

réinitialiser.
2. Dans la page Passerelle réseau virtuelle, dans le volet gauche, faites défiler jusqu’à
la section Support + Résolution des problèmes, puis sélectionnez Réinitialiser.
3. Dans la page Réinitialiser, cliquez sur Réinitialiser. Une fois la commande émise,
l’instance de la passerelle VPN Azure active actuelle est immédiatement
redémarrée. La réinitialisation de la passerelle provoque un défaut de connectivité
VPN et peut limiter l’analyse de la cause racine du problème par la suite.
Ajouter une autre connexion

Vous pouvez créer une connexion à plusieurs sites locaux à partir de la même passerelle
VPN. Si vous souhaitez configurer plusieurs connexions, les espaces d’adressage ne
peuvent pas se chevaucher entre elles.
1. Pour ajouter une connexion, accédez à la passerelle VPN, puis sélectionnez

Connexions pour ouvrir la page homonyme.
2. Cliquez sur +Ajouter pour ajouter votre connexion. Définissez le type de
connexion sur Réseau virtuel à réseau virtuel (pour une connexion à une autre
passerelle de réseau virtuel) ou sur Site à site, selon vos besoins.
3. Si vous voulez ajouter une connexion Site à site et que vous n’avez pas encore créé
de passerelle de réseau local pour le site auquel vous souhaitez vous connecter,
vous pouvez en créer une.
4. Spécifiez la clé partagée à utiliser, puis cliquez sur OK pour créer la connexion.
Considérations importantes relatives à la configuration
Les configurations S2S peuvent être personnalisées de différentes façons. Pour plus
d’informations, consultez les articles suivants :
Pour plus d’informations sur le protocole BGP, consultez les articles Vue
d’ensemble du protocole BGP et Comment configurer BGP.
Pour plus d’informations sur le tunneling forcé, consultez À propos du tunneling
forcé.
Pour plus d’informations sur les connexions haut actif-actif, consultez
Configuration haute disponibilité pour la connectivité entre les réseaux locaux et la
connectivité entre deux réseaux virtuels.
Pour savoir comment limiter le trafic réseau aux ressources d’un réseau virtuel,
consultez Sécurité du réseau.
Pour plus d’informations sur la façon dont Azure achemine le trafic entre les
ressources Azure, locales et Internet, consultez Routage du trafic de réseau virtuel.

Si vous n’envisagez pas de continuer à utiliser cette application ni de passer au tutoriel
suivant, supprimez ces ressources en effectuant les étapes suivantes :
1. Entrez le nom de votre groupe de ressources dans la zone Rechercher en haut du

portail et sélectionnez-le dans les résultats de la recherche.
3. Entrez votre groupe de ressources dans TAPER LE NOM DU GROUPE DE
RESSOURCES, puis sélectionnez Supprimer.
Étapes suivantes
Une fois que vous avez configuré une connexion S2S, vous pouvez ajouter une
connexion P2S à la même passerelle.
Connexions VPN de point à site

Tutoriel : Connecter un réseau virtuel à
un circuit ExpressRoute en utilisant le
portail Azure
Ce tutoriel vous aide à créer une connexion pour lier un réseau virtuel à un circuit Azure
ExpressRoute en utilisant le portail Azure. Les réseaux virtuels que vous connectez à
votre circuit Azure ExpressRoute peuvent être dans le même abonnement ou faire partie
d’un autre abonnement.
＂ Connecter un réseau virtuel à un circuit dans le même abonnement.

＂ Connecter un réseau virtuel à un circuit dans un autre abonnement.
＂ Configurez ExpressRoute FastPath.
＂ supprimer le lien entre le réseau virtuel et le circuit ExpressRoute.
Prérequis
Avant de commencer la configuration, examinez les conditions préalables, la
configuration requise pour le routage et les flux de travail.
Vous devez disposer d’un circuit ExpressRoute actif.

Suivez les instructions permettant de créer un circuit ExpressRoute et faites-le
activer par votre fournisseur de service de connectivité.
Vérifiez que le peering privé Azure est configuré pour votre circuit. Consultez
l’article Créer et modifier le Peering pour un circuit ExpressRoute pour obtenir
des instructions sur le Peering et le routage.
Assurez-vous que l’homologation privée Azure est configurée et établit une
homologation BGP entre votre réseau et Microsoft pour une connectivité de
bout en bout.
Vérifiez qu’un réseau virtuel et une passerelle de réseau virtuel ont été créés et
entièrement approvisionnés. Suivez les instructions pour créer une passerelle de
réseau virtuel pour ExpressRoute. Une passerelle de réseau virtuel pour
ExpressRoute utilise le type de passerelle « ExpressRoute », pas de VPN.
Vous pouvez lier jusqu’à 10 réseaux virtuels à un circuit ExpressRoute standard.

Tous les réseaux virtuels doivent figurer dans la même région géopolitique lors de
l’utilisation d’un circuit ExpressRoute standard.
Un réseau virtuel unique peut être lié à 16 circuits ExpressRoute maximum. Pour
créer un objet connexion pour chaque circuit ExpressRoute auquel vous vous
connectez, procédez comme suit. Les circuits ExpressRoute peuvent être dans le
même abonnement, dans des abonnements différents ou dans une combinaison
des deux.
Si vous activez le module complémentaire ExpressRoute Premium, vous pouvez lier

des réseaux virtuels à l’extérieur de la région géopolitique du circuit ExpressRoute.
Le module complémentaire Premium vous permet également de connecter plus de
10 réseaux virtuels à votre circuit ExpressRoute en fonction de la bande passante
choisie. Pour plus d’informations sur le module complémentaire Premium,
consultez le FAQ .
Pour créer la connexion entre le circuit ExpressRoute et la passerelle de réseau

virtuel ExpressRoute cible, le nombre d’espaces d’adressage publiés à partir des
réseaux virtuels locaux ou appairés doit être inférieur ou égal à 200. Une fois la
connexion établie, vous pouvez ajouter des espaces d’adressage supplémentaires
(jusqu’à 1 000) aux réseaux virtuels locaux ou appairés.
Passez en revue les recommandations pour la connectivité entre réseaux virtuels

sur ExpressRoute.
Connecter un réseau virtuel à un circuit - même

abonnement
７ Notes
Les informations de configuration BGP ne s’affichent pas si le fournisseur de la

couche 3 a configuré vos homologations. Si votre circuit est dans l’état
Approvisionné, vous pouvez créer des connexions.
Pour créer une connexion

1. Assurez-vous que votre circuit ExpressRoute et le peering privé Azure ont été
correctement configurés. Suivez les instructions fournies dans Création d’un circuit
ExpressRoute et Créer et modifier le peering pour un circuit ExpressRoute. Votre
circuit ExpressRoute doit être similaire à l’image suivante :
2. Vous pouvez maintenant commencer à approvisionner une connexion pour lier
votre passerelle de réseau virtuel à votre circuit ExpressRoute. Sélectionnez
Connexion>Ajouter pour ouvrir la page Ajouter une connexion.
3. Entrez un nom pour la connexion, puis sélectionnez Suivant : Paramètres >.

4. Sélectionnez la passerelle appartenant au réseau virtuel que vous voulez lier au
circuit, puis sélectionnez Vérifier + créer. Ensuite, une fois la validation terminée,
5. Une fois votre connexion correctement configurée, votre objet de connexion
affiche les informations de la connexion.
Connecter un réseau virtuel à un circuit - autre

abonnement
Vous pouvez partager un circuit ExpressRoute entre plusieurs abonnements. La figure
suivante montre un schéma simple sur le fonctionnement du partage de circuits
ExpressRoute entre plusieurs abonnements.
７ Notes
La connexion de réseaux virtuels entre des clouds souverains Azure et le cloud

Azure public n’est pas prise en charge. Vous pouvez uniquement lier des réseaux
virtuels provenant de différents abonnements dans le même cloud.
Chacun des petits clouds dans le cloud principal est utilisé pour représenter les
abonnements appartenant à différents services au sein d’une organisation. Les
départements au sein de l’organisation utilisent leur propre abonnement pour déployer
leurs services, mais ils peuvent partager un même circuit ExpressRoute pour se
reconnecter à votre réseau local. Un seul service (dans cet exemple : le service
informatique) peut détenir le circuit ExpressRoute. D’autres abonnements au sein de
l’organisation peuvent utiliser le circuit ExpressRoute.
７ Notes
Les frais de connectivité et de bande passante pour le circuit dédié s’appliquent au

propriétaire du circuit ExpressRoute. Tous les réseaux virtuels partagent la même
bande passante.
Administration : à propos des propriétaires du circuit et

des utilisateurs du circuit
Le « propriétaire du circuit » est l’utilisateur avec pouvoir autorisé de la ressource de
circuit ExpressRoute. Le propriétaire du circuit peut créer des autorisations utilisables par
les « utilisateurs du circuit ». Les utilisateurs du circuit sont propriétaires de passerelles
de réseau virtuel qui ne figurent pas dans le même abonnement que le circuit
ExpressRoute. Les utilisateurs du circuit peuvent échanger des autorisations (une seule
autorisation par réseau virtuel).
Le propriétaire du circuit a le pouvoir de modifier et de révoquer les autorisations à tout

moment. La révocation d’une autorisation entraîne la suppression de toutes les
connexions de l’abonnement dont l’accès a été révoqué.
７ Notes
Le propriétaire du circuit n’est pas un rôle RBAC intégré ou défini sur la ressource
ExpressRoute. La définition du propriétaire du circuit correspond aux rôles
disposant de l’accès suivant :
Microsoft.Network/expressRouteCircuits/authorizations/write
Microsoft.Network/expressRouteCircuits/authorizations/read
Microsoft.Network/expressRouteCircuits/authorizations/delete
Cela inclut les rôles intégrés tels que Contributeur, Propriétaire et Contributeur
réseau. Description détaillée des différents rôles intégrés.
Opérations du propriétaire du circuit
Création d’une autorisation de connexion
Le propriétaire du circuit crée une autorisation, ce qui entraîne la création d’une clé
d’autorisation dont un utilisateur du circuit peut se servir pour connecter ses passerelles
de réseau virtuel au circuit ExpressRoute. Une autorisation n’est valide que pour une
seule connexion.
７ Notes
Chaque connexion nécessite une autorisation distincte.
1. Dans la page ExpressRoute, sélectionnez Autorisations, tapez un nom pour

l’autorisation, puis sélectionnez Enregistrer.
2. Une fois la configuration enregistrée, copiez l’ID de ressource et la clé

d’autorisation.
Suppression d’une autorisation de connexion

Vous pouvez supprimer une connexion en sélectionnant l’icône Supprimer pour la clé
d’autorisation de votre connexion.
Si vous voulez supprimer la connexion tout en conservant la clé d’autorisation, vous

pouvez supprimer la connexion de la page connexion du circuit.
７ Notes
Les connexions échangées dans des abonnements différents ne s’affichent pas dans
la page de connexion du circuit. Accédez à l’abonnement dans lequel l’autorisation
a été échangée, puis supprimez la ressource de connexion de niveau supérieur.
Opérations de l’utilisateur du circuit

L’utilisateur du circuit a besoin de l’ID de ressource et d’une clé d’autorisation du
propriétaire du circuit.
Réclamation d’une autorisation de connexion

1. Sélectionnez le bouton + Créer une ressource. Recherchez Connexion, puis
2. Vérifiez que l’option Type de connexion est définie sur ExpressRoute. Sélectionnez
le Groupe de ressources et l’Emplacement, puis sélectionnez OK dans la page des
informations de base.
７ Notes
L’emplacement doit correspondre à l’emplacement de la passerelle de réseau

virtuel pour lequel vous créez la connexion.
3. Dans la page Paramètres, sélectionnez Passerelle de réseau virtuel, puis cochez la
case Utiliser l’autorisation. Entrez la clé d’autorisation et l’URI du circuit appairé,
puis donnez un nom à la connexion. Sélectionnez OK.
７ Notes
L'URI du circuit homologue est l’ID de ressource du circuit ExpressRoute (que

vous pouvez trouver dans le volet des paramètres des propriétés du circuit
ExpressRoute).
4. Passez en revue les informations contenues dans la page Résumé, puis
sélectionnez OK.
Configurer ExpressRoute FastPath
Vous pouvez activer ExpressRoute FastPath si votre passerelle de réseau virtuel est Très
hautes performances ou ErGw3AZ. FastPath améliore le niveau de performance de
chemin d’accès de données comme le nombre de paquets et de connexions par
seconde entre votre réseau local et votre réseau virtuel.
Configurer FastPath sur une nouvelle connexion
Lorsque vous ajoutez une nouvelle connexion pour votre passerelle ExpressRoute,
cochez la case FastPath.
７ Notes
L’activation de FastPath pour une nouvelle connexion est disponible uniquement

via la création d’une connexion à partir de la ressource de passerelle. Les nouvelles
connexions créées à partir du circuit ExpressRoute ou de la page des ressources de
connexion ne sont pas prises en charge.
Configurer FastPath sur une connexion existante
1. Accédez à la ressource de connexion existante à partir de la passerelle

ExpressRoute, du circuit ExpressRoute ou de la page Ressource de connexion.
2. Sélectionnez Configuration sous Paramètres puis sélectionnez FastPath.
Sélectionnez Enregistrer pour activer la fonctionnalité.
７ Notes
Vous pouvez utiliser Moniteur de connexion pour vérifier que votre trafic atteint la
destination à l’aide de FastPath.
S’inscrire aux fonctionnalités d’ExpressRoute

FastPath (préversion)
La prise en charge de FastPath pour le peering de réseaux virtuels est désormais en
préversion publique. L’inscription est disponible uniquement par le biais d’Azure
PowerShell. Pour obtenir des instructions sur l’inscription, consultez Fonctionnalités
d’évaluation de FastPath.
７ Notes
Toutes les connexions configurées pour FastPath dans l’abonnement cible sont
inscrites à cette préversion. Nous ne recommandons pas l’activation de cette
préversion dans les abonnements de production. Si vous avez déjà configuré
FastPath et que vous souhaitez vous inscrire à la fonctionnalité en préversion, vous
devez effectuer les opérations suivantes :
1. Inscrivez-vous à la fonctionnalité en préversion FastPath avec la commande

Azure PowerShell ci-dessus.
2. Désactivez, puis réactivez FastPath sur la connexion cible.
Vous pouvez supprimer une connexion et annuler la liaison de votre réseau virtuel à un
circuit ExpressRoute en sélectionnant l’icône Supprimer dans la page de votre
connexion.
Étapes suivantes
Ce tutoriel vous a montré comment connecter un réseau virtuel à un circuit dans le
même abonnement et dans un autre abonnement. Pour plus d’informations sur les
passerelles ExpressRoute, consultez :Passerelles de réseau virtuel ExpressRoute.
Pour savoir comment configurer des filtres de routage pour le peering Microsoft en
utilisant le portail Azure, passez au tutoriel suivant.
Configurer des filtres de routage pour le peering Microsoft

à l’aide d’ExpressRoute
ExpressRoute Réseau virtuel Passerelle VPN
Cette architecture de référence montre comment connecter un réseau local à un réseau

virtuel Azure en utilisant Azure ExpressRoute, avec un réseau privé virtuel (VPN) de site à
site comme connexion de basculement.
Architecture
On-premises network
Local edge Microsoft

Gateway subnet
routers edge routers
ExpressRoute
Gateway
gateway
ExpressRoute
circuit
VPN gateway
Virtual network
Téléchargez un fichier Visio de cette architecture.
Workflow
L’architecture est constituée des composants suivants.
Réseau local. Un réseau local privé qui s’exécute au sein d’une organisation.
Appliance VPN. Périphérique ou service qui assure la connectivité externe au
réseau local. L’appliance VPN peut être un périphérique matériel ou bien une
solution logicielle telle que le service RRAS (Routing and Remote Access Service)
dans Windows Server 2012. Pour obtenir la liste des périphériques VPN pris en
charge et des informations sur la configuration de certains périphériques VPN pour
la connexion à Azure, consultez À propos des périphériques VPN pour les
connexions de la passerelle VPN de site à site.
Circuit ExpressRoute. Un circuit de couche 2 ou 3 fourni par le fournisseur de
connectivité et qui relie le réseau local à Azure via les routeurs de périphérie. Le
circuit utilise l’infrastructure matérielle gérée par le fournisseur de connectivité.
Passerelle de réseau virtuel ExpressRoute. La passerelle de réseau virtuel
ExpressRoute permet au réseau virtuel Azure de se connecter au circuit
ExpressRoute qui assure la connectivité avec votre réseau local.
Passerelle de réseau virtuel VPN. La passerelle de réseau virtuel VPN permet au
réseau virtuel Azure de se connecter à l’appliance VPN dans le réseau local. La
passerelle de réseau virtuel VPN est configurée pour accepter les requêtes
provenant du réseau local uniquement via l’appliance VPN. Pour plus
d'informations, consultez Connecter un réseau local à réseau virtuel Microsoft
Azure.
Connexion VPN. La connexion a des propriétés qui spécifient le type de connexion
(IPSec) et la clé partagée avec l’appliance VPN locale pour chiffrer le trafic.
Réseau virtuel Azure Chaque réseau virtuel se trouve dans une seule région Azure
et peut héberger plusieurs couches Application. Les couches Application peuvent
être segmentées en sous-réseaux dans chaque réseau virtuel.
Sous-réseau de passerelle. Les passerelles de réseau virtuel sont conservées dans
le même sous-réseau.
Composants
Azure ExpressRoute
Passerelle VPN Azure
Réseau virtuel Azure
Détails du scénario
Cette architecture de référence montre comment connecter un réseau local à un réseau
virtuel Azure en utilisant ExpressRoute, avec un réseau privé virtuel (VPN) de site à site
comme connexion de basculement. Le trafic circule entre le réseau local et le réseau
virtuel Azure via une connexion ExpressRoute. En cas de perte de connectivité au niveau
du circuit ExpressRoute, le trafic est acheminé via un tunnel VPN IPSec. Déployez cette
solution.
Notez que si le circuit ExpressRoute n’est pas disponible, la route VPN gérera
uniquement les connexions de peering privé. Les connexions de peering public et les
connexions de peering Microsoft se font via Internet.
Recommandations
Les recommandations suivantes s’appliquent à la plupart des scénarios. Suivez ces
recommandations, sauf si vous avez un besoin spécifique qui vous oblige à les ignorer.
Le réseau virtuel et GatewaySubnet

Créez la connexion de passerelle de réseau virtuel ExpressRoute et la connexion de
passerelle de réseau virtuel VPN dans le même réseau virtuel où il y a déjà un objet
Gateway (passerelle) en place. Ils partagent tous les deux le même sous-réseau nommé
GatewaySubnet.
Si le réseau virtuel contient déjà un sous-réseau nommé GatewaySubnet, vérifiez qu’il

possède un espace d’adressage défini sur /27 ou plus. Si le sous-réseau existant est trop
petit, utilisez la commande PowerShell suivante pour supprimer le sous-réseau :
PowerShell
$vnet = Get-AzVirtualNetwork -Name <your-vnet-name> -ResourceGroupName

<your-resource-group>
Remove-AzVirtualNetworkSubnetConfig -Name GatewaySubnet -VirtualNetwork
$vnet
Si le réseau virtuel ne contient pas de sous-réseau nommé GatewaySubnet, créez-en un

à l’aide de la commande PowerShell suivante :
PowerShell
$vnet = Get-AzVirtualNetwork -Name <your-vnet-name> -ResourceGroupName

Add-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet
-AddressPrefix "10.200.255.224/27"
$vnet = Set-AzVirtualNetwork -VirtualNetwork $vnet
Passerelles VPN et ExpressRoute

Vérifiez que votre organisation répond à la configuration requise d’ExpressRoute pour se
connecter à Azure.
S’il y a déjà une passerelle de réseau virtuel VPN dans votre réseau virtuel Azure, utilisez
la commande PowerShell suivante pour la supprimer :
PowerShell
Remove-AzVirtualNetworkGateway -Name <your-gateway-name> -ResourceGroupName
Suivez les instructions de l’article Configurer une architecture réseau hybride avec Azure
ExpressRoute pour établir votre connexion ExpressRoute.
Suivez les instructions de l’article Configurer une architecture réseau hybride avec Azure
et un VPN local pour établir votre connexion de passerelle de réseau virtuel VPN.
Après avoir établi les connexions de passerelle de réseau virtuel, testez l’environnement
comme suit :
1. Vérifiez que vous pouvez vous connecter au réseau virtuel Azure à partir de votre
réseau local.
2. Contactez votre fournisseur pour arrêter la connectivité ExpressRoute à des fins de
test.
3. Vérifiez que vous pouvez toujours vous connecter au réseau virtuel Azure à partir
de votre réseau local en utilisant la connexion de passerelle de réseau virtuel VPN.
4. Contactez votre fournisseur pour rétablir la connectivité ExpressRoute.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est
un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge
de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected
Framework.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation
abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue
d’ensemble du pilier Sécurité.
Pour connaître les considérations de sécurité générales relatives à Azure, consultez

l’article Services de cloud computing et sécurité réseau Microsoft.
Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles
et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue
d’ensemble du pilier d’optimisation des coûts.
Pour plus d’informations sur les coûts du service ExpressRoute, consultez les articles
suivants :
Considérations relatives au coût de la configuration d’une architecture réseau

hybride avec Azure ExpressRoute.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une
application et maintiennent son fonctionnement en production. Pour plus
d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.
Pour connaître les considérations DevOps relatives à ExpressRoute, consultez l’article

Configurer une architecture réseau hybride avec Azure ExpressRoute.
Pour connaître les considérations DevOps relatives au VPN de site à site, consultez
l’article Configurer une architecture réseau hybride avec Azure et un VPN local.
Déployer ce scénario
Conditions préalables. Vous devez disposer d’une infrastructure locale existante déjà
configurée avec une appliance réseau appropriée.
Pour déployer la solution, procédez comme suit :
1. Sélectionnez le lien ci-dessous.
2. Attendez que le lien s’ouvre dans le Portail Azure, puis sélectionnez le Groupe de
ressources dans lequel vous souhaitez déployer ces ressources ou créez un groupe
de ressources. La région et l’emplacement changent automatiquement pour
correspondre au groupe de ressources.
3. Mettez à jour les champs restants si vous souhaitez modifier les noms de
ressources, les fournisseurs, la référence SKU ou les adresses IP réseau de votre
environnement.
4. Sélectionnez Vérifier + créer, puis Créer* pour déployer ces ressources.
5. Attendez la fin du déploiement.
７ Notes
Ce déploiement de modèle déploie uniquement les ressources suivantes :
Un groupe de ressources (si vous en créez un)

Un circuit ExpressRoute
Un réseau virtuel Azure.
Une passerelle de réseau virtuel ExpressRoute
Pour que vous établissiez correctement la connectivité de peering privé à

partir d’un emplacement local vers le circuit ExpressRoute, vous devez
impliquer votre fournisseur de services avec la clé de service du circuit. La clé
de service se trouve sur la page de vue d’ensemble de la ressource de circuit
ExpressRoute. Pour plus d’informations sur la configuration de votre circuit
ExpressRoute, consultez Créer ou modifier la configuration du peering. Une
fois que vous avez configuré le peering privé, vous pouvez connecter la
passerelle de réseau virtuel ExpressRoute au circuit. Pour plus d’informations,
consultez Tutoriel : Connecter un réseau virtuel à un circuit ExpressRoute en
utilisant le portail Azure.
6. Pour terminer le déploiement d’un VPN de site à site en tant que sauvegarde sur
ExpressRoute, consultez Créer une connexion VPN de site à site.
7. Une fois que vous avez correctement configuré une connexion VPN au même
réseau local que celui sur lequel vous avez configuré ExpressRoute, vous aurez
terminé la configuration pour sauvegarder votre connexion ExpressRoute en cas
d’échec total à l’emplacement de peering.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
Sarah Parkes | Architecte de solution cloud
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
Documentation ExpressRoute
Ligne de base de la sécurité Azure pour ExpressRoute
Création d’un circuit ExpressRoute
Blog Azure Networking
Configurer ExpressRoute des connexions coexistantes de site à site en utilisant
PowerShell
Ressources associées
Conception d’une architecture hybride
Options hybrides Azure
Topologie réseau hub-and-spoke dans Azure
Mise en réseau spoke-to-spoke
Étendre un réseau local à l’aide d’ExpressRoute
Implémenter un réseau hybride sécurisé
Intégrer un environnement AD local avec Azure
Utiliser un TAP de réseau virtuel à l’aide
d’Azure CLI
Article • 01/06/2023
） Important
La préversion du TAP de réseau virtuel est actuellement en attente dans toutes les
régions Azure. Vous pouvez nous envoyer un e-mail à l’adresse
azurevnettap@microsoft.com avec votre ID d’abonnement et nous vous
informerons des futures mises à jour concernant la préversion. En attendant, vous
pouvez utiliser des solutions NVA ou basées sur agent qui fournissent des
fonctionnalités de visibilité du TAP/réseau via nos solutions de partenaire Packet
Broker disponibles dans les offres de la Place de marché Azure .
Le TAP (point d’accès terminal) de réseau virtuel Azure vous permet de diffuser en
continu votre trafic réseau de machine virtuelle vers un collecteur de paquets réseau ou
un outil analytique. Le collecteur ou l’outil analytique est fourni par une appliance
virtuelle réseau partenaire. Pour obtenir la liste des solutions de partenaires qui
fonctionnent avec un TAP de réseau virtuel, consultez les solutions de partenaires.
Créer une ressource TAP de réseau virtuel

Lisez les prérequis avant de créer une ressource TAP de réseau virtuel. Vous pouvez
exécuter les commandes qui suivent dans Azure Cloud Shell , ou en exécutant Azure
CLI à partir de votre ordinateur. Azure Cloud Shell est un interpréteur de commandes
interactif et gratuit qui ne nécessite pas l’installation d’Azure CLI sur votre ordinateur.
Vous devez vous connecter à Azure avec un compte qui a les autorisations appropriées.
Cet article nécessite la version 2.0.46 ou ultérieure d’Azure CLI. Exécutez az --version
pour rechercher la version installée. Si vous devez installer ou mettre à niveau, consultez
Installation d’Azure CLI 2.0. Le point d’accès terminal (TAP) de réseau virtuel est
actuellement disponible sous forme d’extension. Pour installer l’extension, vous devez
exécuter az extension add -n virtual-network-tap . Si vous exécutez Azure CLI
localement, vous devez également exécuter az login pour créer une connexion avec
Azure.
1. Récupérer l’ID de votre abonnement dans une variable, utilisée dans une étape
ultérieure :
Azure CLI
subscriptionId=$(az account show \

--query id \
--out tsv)
2. Définissez l’ID d’abonnement à utiliser pour créer une ressource TAP de réseau
virtuel.
Azure CLI
az account set --subscription $subscriptionId
3. Réinscrivez l’ID d’abonnement à utiliser pour créer une ressource TAP de réseau
virtuel. Si vous obtenez une erreur d’inscription quand vous créez une ressource
TAP, exécutez la commande suivante :
Azure CLI
az provider register --namespace Microsoft.Network --subscription

$subscriptionId
4. Si la destination du TAP de réseau virtuel est l’interface réseau sur l’appliance

virtuelle réseau d’un collecteur ou d’un outil analytique :
Récupérez la configuration IP de l’interface réseau de l’appliance virtuelle

réseau dans une variable, utilisée dans une étape ultérieure. L’ID est le point
de terminaison qui va agréger le trafic TAP. L’exemple suivant récupère l’ID de
la configuration IP ipconfig1 pour une interface réseau nommée
myNetworkInterface, dans un groupe de ressources nommé myResourceGroup
:
Azure CLI
IpConfigId=$(az network nic ip-config show \

--name ipconfig1 \
--nic-name myNetworkInterface \
--query id \
--out tsv)
Créez le TAP de réseau virtuel dans la région Azure westcentralus à l’aide de

l’ID de la configuration IP comme destination et d’une propriété de port
facultative. Le port spécifie le port de destination du trafic TAP sur la
configuration IP d’interface réseau :
Azure CLI
az network vnet tap create \

--name myTap \
--destination $IpConfigId \
--port 4789 \
--location westcentralus
5. Si la destination du TAP de réseau virtuel est un équilibreur de charge interne

Azure :
Récupérez la configuration IP frontend de l’équilibreur de charge interne

Azure dans une variable, utilisée dans une étape ultérieure. L’ID est le point
de terminaison qui va agréger le trafic TAP. L’exemple suivant récupère l’ID de
la configuration IP frontend frontendipconfig1 pour un équilibreur de charge
nommé myInternalLoadBalancer, dans un groupe de ressources nommé
myResourceGroup :
Azure CLI
FrontendIpConfigId=$(az network lb frontend-ip show \

--name frontendipconfig1 \
--lb-name myInternalLoadBalancer \
--query id \
--out tsv)
Créez le TAP de réseau virtuel à l’aide de l’ID de la configuration IP de

destination et d’une propriété de port facultative. Le port spécifie le port de
destination du trafic TAP sur la configuration IP frontend :
Azure CLI
az network vnet tap create \

--name myTap \
--destination $FrontendIpConfigId \
--port 4789 \
--location westcentralus
6. Confirmez la création du TAP de réseau virtuel :

Azure CLI
az network vnet tap show \

--resource-group myResourceGroup
--name myTap
Ajouter une configuration TAP à une interface

réseau
1. Récupérez l’ID d’une ressource TAP de réseau virtuel existante. L’exemple suivant
récupère un TAP de réseau virtuel nommé myTap dans un groupe de ressources
nommé myResourceGroup :
Azure CLI
tapId=$(az network vnet tap show \

--name myTap \
--query id \
--out tsv)
2. Créez une configuration TAP sur l’interface réseau de la machine virtuelle

supervisée. L’exemple suivant crée une configuration TAP pour une interface
réseau nommée myNetworkInterface :
Azure CLI
az network nic vtap-config create \

--nic myNetworkInterface \
--vnet-tap $tapId \
--name mytapconfig \
--subscription subscriptionId
3. Confirmez la création de la configuration TAP :
Azure CLI
az network nic vtap-config show \

--nic-name myNetworkInterface \
--name mytapconfig \
Supprimer la configuration TAP sur une
interface réseau
Azure CLI
az network nic vtap-config delete \

--nic myNetworkInterface \
--name myTapConfig \
Lister les TAP de réseau virtuel dans un

abonnement
Azure CLI
az network vnet tap list
Supprimer un TAP de réseau virtuel dans un

groupe de ressources
Azure CLI
az network vnet tap delete \

--name myTap
Déployer la mise en réseau de
conteneurs pour un hôte Docker Linux
autonome
Article • 01/06/2023
Le plug-in Azure CNI active la mise en réseau par conteneur/pod pour les hôtes Docker
autonomes et les clusters Kubernetes. Dans cet article, vous allez apprendre à installer et
à configurer le plug-in CNI pour un hôte Docker Linux autonome.
Prérequis

Un réseau virtuel contient la machine virtuelle utilisée dans cet article. Dans cette
section, vous allez créer un réseau virtuel et un sous-réseau. Vous allez activer Azure
Bastion pendant le déploiement du réseau virtuel. L’hôte Azure Bastion est utilisé pour
se connecter de façon sécurisée à la machine virtuelle afin d’effectuer les étapes décrites
dans cet article.


Paramètre Valeur
Détails du projet

Sélectionnez OK.
Paramètre Valeur
Nom Entrez myVNet.
Paramètre Valeur
10. Sélectionnez Suivant : Sécurité.
11. Sélectionnez Activer dans BastionHost.
Paramètre Valeur
Nom du bastion Saisissez myBastion.

Entrez myBastionIP dans Nom.
Sélectionnez OK.
Le déploiement de l’hôte bastion peut prendre quelques minutes. Vous pouvez

poursuivre les étapes pendant le déploiement de l’hôte Bastion.

Dans cette section, vous allez créer une machine virtuelle Ubuntu pour l’hôte Docker
autonome. Ubuntu est utilisé pour l’exemple de cet article. Le plug-in CNI prend en
charge Windows et d’autres distributions Linux.
1. Dans la zone de recherche située en haut du portail, entrez Machine virtuelle.

Sélectionnez Machines virtuelles dans les résultats de la recherche.
2. Sélectionnez + Créer>une machine virtuelle Azure.
3. Sous l’onglet Informations de base dans Créer une machine virtuelle, entrez ou
Paramètre Valeur
Détails du projet
Nom de la machine virtuelle Entrez myVM.
Options de disponibilité Sélectionnez Aucune infrastructure requise.
Type de sécurité Sélectionnez Standard.
Image Sélectionnez Ubuntu Server 20.04 LTS - x64 Gen 2.
Architecture de machine virtuelle Laissez la valeur par défaut x64.
Exécuter avec la remise Azure Spot Conservez la valeur par défaut (case non cochée).
Confirmer le mot de passe Retapez le mot de passe.

4. Sélectionnez Suivant : Disques, puis Suivant : Réseaux.
Paramètre Valeur
Interface réseau
Subnet Sélectionnez mySubnet (10.1.0.0/24) .
7. Sélectionnez Créer
Ajouter une configuration IP

Le plug-in Azure CNI alloue des adresses IP aux conteneurs en fonction d’un pool
d’adresses IP que vous créez sur l’interface réseau virtuelle de la machine virtuelle. Pour
chaque conteneur sur l’hôte, une configuration IP doit exister sur l’interface réseau
virtuelle. Si le nombre de conteneurs sur le serveur dépasse le nombre de configurations
IP sur l’interface réseau virtuelle, le conteneur démarre mais n’a pas d’adresse IP.
Dans cette section, vous allez ajouter une configuration IP à l’interface réseau virtuelle
de la machine virtuelle que vous avez créée précédemment.

2. Sélectionnez myVM.
3. Sous Paramètres, sélectionnez Mise en réseau.
4. Sélectionnez le nom de l’interface réseau à côté d’Interface réseau. L’interface

réseau est nommée myvm avec un nombre aléatoire. Dans cet exemple, il s’agit de
myvm27.
5. Dans les Paramètres de l’interface réseau, sélectionnez Configurations IP.
6. Dans Configurations IP, sélectionnez ipconfig1 dans Nom.
7. Dans les paramètres ipconfig1, modifiez l’affectation de l’adresse IP privée de

Dynamique à Statique.
9. Revenez à Configurations IP.
11. Entrez ou sélectionnez les informations suivantes pour Ajouter une

configuration IP :
Paramètre Valeur
Nom Entrez ipconfig2.
Paramètres d’adresse IP privée
Allocation Sélectionnez Statique.
Adresse IP Entrez 10.1.0.5.
13. Vérifiez qu’ipconfig2 a été ajoutée en tant que configuration IP secondaire.
Répétez les étapes 1 à 13 pour ajouter autant de configurations que de conteneurs que
vous souhaitez déployer sur l’hôte de conteneur.
Installation de Docker
Le moteur de conteneur Docker doit être installé et configuré sur la machine virtuelle
que vous avez créée précédemment.
Connectez-vous à la machine virtuelle que vous avez créée précédemment avec l’hôte
Azure Bastion que vous avez déployé avec le réseau virtuel.

3. Dans la Vue d’ensemble de myVM, sélectionnez Se connecter, puis Bastion.
4. Entrez le nom d’utilisateur et le mot de passe que vous avez créés lors du
déploiement de la machine virtuelle au cours des étapes précédentes.
5. Sélectionnez Connecter.
Pour obtenir des instructions d’installation de Docker sur un hôte de conteneur Ubuntu,
consultez Installer le moteur Docker sur Ubuntu .
Une fois Docker installé sur la machine virtuelle, suivez les instructions pour la post-
installation Linux. Pour obtenir des instructions sur la post-installation Linux, consultez
Étapes post-installation du moteur Docker .
Une fois Docker installé sur votre machine virtuelle, suivez les étapes décrites dans cet
article.
Installer le plug-in CNI et créer un conteneur

de test
Le plug-in Azure CNI est géré en tant que projet GitHub et peut être téléchargé à partir
de la page GitHub du projet. Pour cet article, vous allez utiliser git dans la machine
virtuelle pour cloner le référentiel du plug-in, puis installer et configurer le plug-in.
Pour plus d’informations sur le plug-in Azure CNI, consultez Microsoft Azure Container
Networking .

6. L’application jq est requise pour le script d’installation du plug-in CNI. Utilisez

l’exemple suivant pour installer l’application :
Bash
sudo apt-get update

sudo apt-get install jq
7. Ensuite, vous allez cloner le référentiel pour le plug-in CNI. Utilisez l’exemple
suivant pour cloner le référentiel :
Bash
git clone https://github.com/Azure/azure-container-networking.git
8. Configurez les autorisations et installez le plug-in CNI. La commande de script

d’installation nécessite un numéro de version pour le plug-in CNI. À l’heure de la
rédaction de cet article, la version la plus récente est v1.4.39 . Pour obtenir le
numéro de version le plus récent du plug-in ou des versions antérieures, consultez
Versions .
Bash
cd ./azure-container-networking/scripts
chmod u+x install-cni-plugin.sh
sudo ./install-cni-plugin.sh v1.4.39
chmod u+x docker-run.sh
9. Pour démarrer un conteneur avec le plug-in CNI, vous devez utiliser un script
spécial fourni avec le plug-in pour créer et démarrer le conteneur. L’exemple
suivant crée un conteneur Alpine avec le script de plug-in CNI :
Bash
sudo ./docker-run.sh vnetdocker1 default alpine
10. Pour vérifier que le conteneur a reçu l’adresse IP que vous avez configurée
précédemment, connectez-vous au conteneur et affichez l’adresse IP :
Bash
sudo docker exec -it vnetdocker1 /bin/sh
11. Utilisez la commande ifconfig dans l’exemple suivant pour vérifier que l’adresse
IP a été affectée au conteneur :
Bash
ifconfig
Si vous ne comptez pas continuer à utiliser cette application, supprimez le réseau virtuel
et la machine virtuelle en effectuant les étapes suivantes :
1. Dans la zone de recherche située en haut du portail, entrez Groupe de ressources.

Sélectionnez Groupes de ressources dans les résultats de la recherche.
2. Sélectionnez myResourceGroup.
3. Dans la Vue d’ensemble de myResourceGroup, sélectionnez Supprimer le groupe

de ressources.
4. Dans TAPEZ LE NOM DU GROUPE DE RESSOURCES :, entrez myResourceGroup.
Étapes suivantes
Dans cet article, vous avez appris à installer le plug-in Azure CNI et à créer un conteneur
test.
Pour plus d’informations sur la mise en réseau de conteneurs Azure et le service Azure
Kubernetes, consultez :
Qu’est-ce qu’Azure Kubernetes Service ?
Mise en réseau de conteneurs Microsoft Azure
Versions du plug-in Azure CNI

Déployer le plug-in CLI Réseau virtuel Azure
Déployer la mise en réseau de
conteneurs pour un hôte Docker
Windows autonome
Article • 01/06/2023
Le plug-in Azure CNI active la mise en réseau par conteneur/pod pour les hôtes Docker
autonomes et les clusters Kubernetes. Dans cet article, vous allez apprendre à installer et
à configurer le plug-in CNI pour un hôte Docker Windows autonome.
Prérequis

Un réseau virtuel contient la machine virtuelle utilisée dans cet article. Dans cette
section, vous allez créer un réseau virtuel et un sous-réseau. Vous allez activer Azure
Bastion pendant le déploiement du réseau virtuel. L’hôte Azure Bastion est utilisé pour
se connecter de façon sécurisée à la machine virtuelle afin d’effectuer les étapes décrites
dans cet article.


Paramètre Valeur
Détails du projet

Sélectionnez OK.
Paramètre Valeur
Nom Entrez myVNet.
Paramètre Valeur
11. Sélectionnez Activer dans BastionHost.
Paramètre Valeur
Nom du bastion Saisissez myBastion.

Entrez myBastionIP dans Nom.
Sélectionnez OK.
Le déploiement de l’hôte Bastion et du réseau peut prendre quelques minutes. Passez

aux étapes suivantes lorsque le déploiement est terminé ou que la création du réseau
virtuel est terminée.
Dans cette section, vous allez créer une machine virtuelle Windows Server 2022 pour
l’hôte Docker autonome. Le plug-in CNI prend en charge Windows et Linux.

2. Sélectionnez + Créer>une machine virtuelle Azure.
3. Sous l’onglet Informations de base dans Créer une machine virtuelle, entrez ou
Paramètre Valeur
Détails du projet
Nom de la machine virtuelle Entrez myVM.
Options de disponibilité Sélectionnez Aucune infrastructure requise.
Image Sélectionnez Windows Server 2022 Datacenter - x64

Gen2.
Architecture de machine Laissez la valeur par défaut x64.

virtuelle
Exécuter avec la remise Azure Conservez la valeur par défaut (case non cochée).
Spot
Confirmer le mot de passe Retapez le mot de passe.

Paramètre Valeur
4. Sélectionnez Suivant : Disques, puis Suivant : Réseaux.
Paramètre Valeur
Interface réseau
7. Sélectionnez Créer
Ajouter une configuration IP

Le plug-in Azure CNI alloue des adresses IP aux conteneurs en fonction d’un pool
d’adresses IP que vous créez sur l’interface réseau virtuelle de la machine virtuelle. Pour
chaque conteneur sur l’hôte, une configuration IP doit exister sur l’interface réseau
virtuelle. Si le nombre de conteneurs sur le serveur dépasse le nombre de configurations
IP sur l’interface réseau virtuelle, le conteneur démarre mais n’a pas d’adresse IP.
Dans cette section, vous allez ajouter une configuration IP à l’interface réseau virtuelle
de la machine virtuelle que vous avez créée précédemment.

3. Sous Paramètres, sélectionnez Mise en réseau.
4. Sélectionnez le nom de l’interface réseau à côté d’Interface réseau. L’interface

réseau est nommée myvm avec un nombre aléatoire. Dans cet exemple, il s’agit de
myvm418.
5. Dans les Paramètres de l’interface réseau, sélectionnez Configurations IP.
6. Dans Configurations IP, sélectionnez ipconfig1 dans Nom.
7. Dans les paramètres ipconfig1, remplacez l’affectation de l’adresse IP privée

Dynamique par Statique.
9. Revenez à Configurations IP.
11. Entrez ou sélectionnez les informations suivantes pour Ajouter une

configuration IP :
Paramètre Valeur
Nom Entrez ipconfig2.

Paramètre Valeur
Paramètres d’adresse IP privée
Allocation Sélectionnez Statique.
Adresse IP Entrez 10.1.0.5.
13. Vérifiez qu’ipconfig2 a été ajoutée en tant que configuration IP secondaire.
Répétez les étapes 1 à 13 pour ajouter autant de configurations que de conteneurs que
vous souhaitez déployer sur l’hôte de conteneur.
Configurer des adresses IP dans Windows

Pour affecter plusieurs adresses IP à une machine virtuelle Windows, les adresses IP
doivent être ajoutées à l’interface réseau dans Windows. Dans cette section, vous allez
vous connecter à la machine virtuelle et configurer les configurations IP que vous avez
créées dans la section précédente.

6. Ouvrez la configuration des connexions réseau sur la machine virtuelle.

Sélectionnez Démarrer ->Exécuter et entrez ncpa.cpl .
8. Sélectionnez l’interface réseau de la machine virtuelle, puis Propriétés :
9. Dans Propriétés Ethernet, sélectionnez Protocole Internet version 4 (TCP/IPv4),

puis Propriétés.
10. Sous l’onglet Général, entrez ou sélectionnez les informations suivantes :

Paramètre Valeur
Sélectionnez Utiliser l’adresse IP

suivante :
Adresse IP : Entrez 10.1.0.4
Masque de sous-réseau : Entrez 255.255.255.0
Passerelle par défaut Entrez 10.1.0.1
Sélectionnez Utiliser les adresses

de serveur DNS suivantes :
Serveur DNS préféré : Entrez 168.63.129.16Cette IP est l’adresse IP affectée

par DHCP pour le DNS Azure par défaut
11. Sélectionnez Avancé....
12. Dans Adresses IP, sélectionnez Ajouter....
Paramètre Valeur
Adresse TCP/IP
Adresse IP : Entrez 10.1.0.5
Masque de sous-réseau : Entrez 255.255.255.0

15. Pour ajouter d’autres adresses IP qui correspondent aux configurations IP

supplémentaires créées précédemment, sélectionnez Ajouter.
La connexion Bastion s’arrête quelques secondes pendant que la configuration réseau

est appliquée. Attendez quelques secondes, puis essayez de vous reconnecter.
Continuez quand une reconnexion réussit.
Installation de Docker
Le moteur de conteneur Docker doit être installé et configuré sur la machine virtuelle
que vous avez créée précédemment.
Connectez-vous à la machine virtuelle que vous avez créée précédemment avec l’hôte
Azure Bastion que vous avez déployé avec le réseau virtuel.

6. Ouvrez Windows PowerShell sur myVM.
7. L’exemple suivant installe Docker CE/Moby :
PowerShell
Invoke-WebRequest -UseBasicParsing
"https://raw.githubusercontent.com/microsoft/Windows-
Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -
o install-docker-ce.ps1
.\install-docker-ce.ps1
La machine virtuelle redémarre pour installer la prise en charge de conteneur dans

Windows. Reconnectez-vous à la machine virtuelle et l’installation de Docker continuera.
Pour plus d’informations sur les conteneurs Windows, consultez Prise en main : Préparer
Windows pour les conteneurs.
Une fois Docker installé sur votre machine virtuelle, suivez les étapes décrites dans cet
article.
Installer le plug-in CNI et jq

Le plug-in Azure CNI est géré en tant que projet GitHub et peut être téléchargé à partir
de la page GitHub du projet. Pour cet article, vous allez télécharger le dépôt du plug-in
CNI dans la machine virtuelle, puis installer et configurer le plug-in.
Pour plus d’informations sur le plug-in Azure CNI, consultez Mise en réseau de
conteneurs Microsoft Azure .

6. Utilisez l’exemple suivant pour télécharger et extraire le plug-in CNI dans un

dossier temporaire de la machine virtuelle :
PowerShell
Invoke-WebRequest -Uri https://github.com/Azure/azure-container-

networking/archive/refs/heads/master.zip -OutFile azure-container-
networking.zip
Expand-Archive azure-container-networking.zip -DestinationPath azure-

container-networking
7. Pour installer le plug-in CNI, accédez au répertoire scripts du dossier du plug-in

CNI que vous avez téléchargé à l’étape précédente. La commande install script
nécessite un numéro de version pour le plug-in CNI. À l’heure de la rédaction de
cet article, la version la plus récente est v1.4.39 . Pour obtenir le numéro de
version le plus récent du plug-in ou des versions antérieures, consultez Versions .
PowerShell
cd .\azure-container-networking\azure-container-networking-
master\scripts\
.\Install-CniPlugin.ps1 v1.4.39
8. Le plug-in CNI est fourni avec un fichier de configuration réseau intégré pour le
plug-in. Utilisez l’exemple suivant pour copier le fichier dans le répertoire de la
configuration réseau :
PowerShell
Copy-Item -Path "c:\k\azurecni\bin\10-azure.conflist" -Destination

"c:\k\azurecni\netconf"
Installer jq
Le script qui crée les conteneurs avec le plug-in Azure CNI nécessite l’application jq.
Pour plus d’informations et pour connaître l’emplacement de téléchargement, consultez
Télécharger jq .
1. Ouvrez un navigateur web dans la machine virtuelle et téléchargez l’application jq.
2. Le téléchargement est un exécutable autonome pour l’application. Copiez

l’exécutable jq-win64.exe dans le répertoire C:\Windows .
Créer un conteneur test

1. Pour démarrer un conteneur avec le plug-in CNI, vous devez utiliser un script
spécial fourni avec le plug-in pour créer et démarrer le conteneur. L’exemple
suivant crée un conteneur Windows Server avec le script de plug-in CNI :
PowerShell
cd .\azure-container-networking\azure-container-networking-
master\scripts\
.\docker-exec.ps1 vnetdocker1 default
mcr.microsoft.com/windows/servercore/iis add
Le premier téléchargement de l’image du conteneur peut prendre quelques

minutes. Lorsque le conteneur démarre et initialise le réseau, la connexion Bastion
se déconnecte. Attendez quelques secondes que la connexion soit rétablie.
2. Pour vérifier que le conteneur a reçu l’adresse IP que vous avez configurée
précédemment, connectez-vous au conteneur et affichez l’adresse IP :
PowerShell
docker exec -it vnetdocker1 powershell
3. Utilisez la commande ipconfig dans l’exemple suivant pour vérifier que l’adresse
IP a été affectée au conteneur :
PowerShell
ipconfig
4. Quittez le conteneur et fermez la connexion Bastion à myVM.

Si vous ne comptez pas continuer à utiliser cette application, supprimez le réseau virtuel
et la machine virtuelle en effectuant les étapes suivantes :
1. Dans la zone de recherche située en haut du portail, entrez Groupe de ressources.

Sélectionnez Groupes de ressources dans les résultats de la recherche.
2. Sélectionnez myResourceGroup.
3. Dans la Vue d’ensemble de myResourceGroup, sélectionnez Supprimer le groupe

de ressources.
4. Dans TAPEZ LE NOM DU GROUPE DE RESSOURCES :, entrez myResourceGroup.
Étapes suivantes
Dans cet article, vous avez appris à installer le plug-in Azure CNI et à créer un conteneur
test.
Pour plus d’informations sur la mise en réseau de conteneurs Azure et le service Azure
Kubernetes, consultez :
Qu’est-ce qu’Azure Kubernetes Service ?
Mise en réseau de conteneurs Microsoft Azure
Versions du plug-in Azure CNI
Déployer le plug-in CLI Réseau virtuel Azure

Déployer le plug-in CLI Réseau virtuel
Azure
Le plug-in CLI Réseau virtuel Azure s’installe sur une machine virtuelle Azure et apporte
des fonctionnalités de réseau virtuel au pods Kubernetes et aux conteneurs Docker. Pour
en savoir plus sur ce plug-in, consultez Permettre aux conteneurs d’utiliser les
fonctionnalités Réseau virtuel Azure. Ce plug-in peut de plus être utilisé avec Azure
Kubernetes Service (AKS) en choisissant l’option Réseau avancé, ce qui place
automatiquement les conteneurs AKS dans un réseau virtuel.
Déployer le plug-in pour le cluster Kubernetes

ACS-Engine
ACS-Engine déploie un cluster Kubernetes avec un modèle Azure Resource Manager. La
configuration du cluster est spécifiée dans un fichier JSON qui est passé à l’outil lors de
la génération du modèle. Pour en savoir plus sur la liste complète des paramètres de
cluster pris en charge et leur description, consultez Moteur de Microsoft Azure
Container Service - Définition du cluster . Ce plug-in est le plug-in du réseau par
défaut des clusters créés à l’aide d’ACS-Engine. Les paramètres de configuration réseau
suivants sont importants lors de la configuration du plug-in :
firstConsecutiveStaticIP L’adresse IP qui est allouée au nœud principal. Ce paramètre est

obligatoire.
clusterSubnet under CIDR du sous-réseau de réseau virtuel sur lequel le cluster est déployé
kubernetesConfig et à partir duquel les adresses IP sont allouées aux pods
vnetSubnetId sous Spécifie l’ID de ressource Azure Resource Manager du sous-réseau sur
masterProfile lequel le cluster doit être déployé.
vnetCidr CIDR du réseau virtuel sur lequel le cluster est déployé.
max-Pods sous Nombre maximal de pods sur chaque machine virtuelle agent. Pour le
kubeletConfig plug-in, la valeur par défaut est 30. Vous pouvez spécifier jusqu’à
250 pods
Exemple de configuration
L’exemple de fichier json ci-dessous s’applique à un cluster présentant les propriétés
suivantes :
Un nœud main et deux nœuds d’agent
Déployé sur un sous-réseau nommé KubeClusterSubnet (10.0.0.0/20) et sur lequel

résident le nœud principal et les nœuds agent.
JSON
{
"apiVersion": "vlabs",
"properties": {
"orchestratorProfile": {
"orchestratorType": "Kubernetes",
"kubernetesConfig": {
"clusterSubnet": "10.0.0.0/20" --> Subnet allocated for the cluster
}
},
"masterProfile": {
"count": 1,
"dnsPrefix": "ACSKubeMaster",
"vmSize": "Standard_A2",
"vnetSubnetId": "/subscriptions/<subscription
ID>/resourceGroups/<Resource Group
Name>/providers/Microsoft.Network/virtualNetworks/<Vnet
Name>/subnets/KubeClusterSubnet",
"firstConsecutiveStaticIP": "10.0.1.50", --> IP address allocated to
the Master node
"vnetCidr": "10.0.0.0/16" --> Virtual network address space
},
"agentPoolProfiles": [
{
"name": "k8sagentpoo1",
"count": 2,
"vmSize": "Standard_A2_v2",
"vnetSubnetId": "/subscriptions/<subscription ID>/resourceGroups/<Resource
Group Name>/providers/Microsoft.Network/virtualNetworks/<VNet
Name>/subnets/KubeClusterSubnet",
"availabilityProfile": "AvailabilitySet"
}
],
"linuxProfile": {
"adminUsername": "KubeServerAdmin",
"ssh": {
"publicKeys": [
{…}
]
}
},
"servicePrincipalProfile": {
"clientId": "dd438987-aa12-4754-b47d-375811889714",
"secret": "azure123"
}
}
}
Déployer le plug-in pour un cluster Kubernetes

Procédez comme suit pour installer le plug-in sur chaque machine virtuelle Azure dans
un cluster Kubernetes :
1. Téléchargez et installez le plug-in.
2. Préallouez un pool d’adresses IP de réseau virtuel sur chaque machine virtuelle à

partir duquel des adresses IP sont attribuées aux Pods. Chaque machine virtuelle
Azure est fournie avec une adresse IP privée de réseau virtuel principale sur chaque
interface réseau. Le pool d’adresses IP pour les pods est ajouté en tant qu’adresses
secondaires (ipconfigs) sur l’interface réseau de machine virtuelle, à l’aide d’une des
options suivantes :
CLI : attribuer plusieurs adresses IP à l’aide d’Azure CLI
PowerShell : attribuer plusieurs adresses IP à l’aide de PowerShell
Portail : attribuer plusieurs adresses IP à l’aide du portail Azure
Modèle Azure Resource Manager : attribuer plusieurs adresses IP à l’aide de

modèles
Veillez à ajouter suffisamment d’adresses IP pour tous les pods que vous envisagez
d’ajouter à la machine virtuelle.
3. Sélectionnez le plug-in qui fournit le réseau de votre cluster en passant à Kubelet

l’option de ligne de commande –network-plugin=cni lors de la création du cluster.
Par défaut, Kubernetes recherche le plug-in et le fichier de configuration dans les
répertoires où ils sont déjà installés.
4. Si vous souhaitez que vos pods accèdent à internet, ajoutez la règle iptables
suivante sur vos machines virtuelles Linux afin de traduire les adresses sources du
trafic internet. Dans l’exemple suivant, la plage IP spécifiée est 10.0.0.0/8.
Bash
iptables -t nat -A POSTROUTING -m iprange ! --dst-range 168.63.129.16 -

m
addrtype ! --dst-type local ! -d 10.0.0.0/8 -j MASQUERADE
Les règles traduisent les adresses du trafic qui n’est pas destiné aux plages
d’adresses IP spécifiées. Il est supposé que tout le trafic en dehors des plages
précédentes correspond à du trafic internet. Vous pouvez choisir de spécifier les
plages IP du réseau virtuel de la machine virtuelle, celles des réseaux virtuels
appairés et celles des réseaux locaux.
Les machines virtuelles Windows traduisent automatiquement les adresses sources

du trafic dont la destination se trouve en dehors du sous-réseau auquel appartient
la machine virtuelle. Il n’est pas possible de spécifier des plages d’adresses IP
personnalisées.
Une fois les étapes précédentes effectuées, les Pods ajoutés aux machines virtuelles
agent Kubernetes reçoivent automatiquement des adresses IP privées à partir du réseau
virtuel.
Déployer le plug-in pour les conteneurs Docker

1. Téléchargez et installez le plug-in.
2. Créez les conteneurs Docker en utilisant la commande suivante :
./docker-run.sh \<container-name\> \<container-namespace\> \<image\>
Les conteneurs commencent automatiquement à recevoir des adresses IP provenant du

pool alloué. Les conteneurs Docker doivent être placé derrière un logiciel d’équilibration
de charge avec un sonde d’intégrité d’équilibration de charge si vous voulez équilibrer
la charge de trafic aux conteneurs Docker.
Fichier de configuration réseau CNI

Le fichier de configuration réseau CNI est décrit au format JSON. Par défaut, il est
présent dans /etc/cni/net.d pour Linux et dans c:\cni\netconf pour Windows. Ce
fichier spécifie la configuration du plug-in et il est différent pour Windows et Linux. Le
fichier json qui suit est un exemple de fichier de configuration Linux et est suivi d’une
explication pour certains paramètres clés. Aucune modification de ce fichier n’est
nécessaire :
JSON
{
"cniVersion":"0.3.0",
"name":"azure",
"plugins":[
{
"type":"azure-vnet",
"mode":"bridge",
"bridge":"azure0",
"ipam":{
"type":"azure-vnet-ipam"
}
},
{
"type":"portmap",
"capabilities":{
"portMappings":true
},
"snat":true
}
]
}
Explication des paramètres

« cniVersion » : les plug-ins CNI Réseau virtuel Azure prennent en charge les
versions 0.3.0 et 0.3.1 de la spécification CNI .
« name » : nom du réseau. Cette propriété peut être définie sur une valeur unique.
« type » : nom du plug-in réseau. Définissez-le sur azure-vnet.
« mode » : mode de fonctionnement. Ce champ est facultatif. Le seul mode pris en

charge est « bridge ». Pour plus d’informations, consultez Modes de
fonctionnement .
« bridge » : nom du pont qui est utilisé pour connecter les conteneurs à un réseau
virtuel. Ce champ est facultatif. Si ce paramètres est omis, le plug-in choisit
automatiquement un nom unique, en fonction de l’index d’interface principal.
« ipam » - « type » : nom du plug-in IPAM. Définissez-le toujours sur azure-vnet-

ipam.
Télécharger et installer le plug-in

Téléchargez le plug-in depuis GitHub . Téléchargez la dernière version pour la
plateforme que vous utilisez :
Linux : azure-vnet-cni-linux-amd64-<n° version>.tgz
Windows: azure-vnet-cni-windows-amd64-<n° version>.zip
Copiez le script d’installation pour Linux ou Windows sur votre ordinateur.

Enregistrez le script dans un répertoire scripts sur votre ordinateur et nommez le
fichier install-cni-plugin.sh pour Linux, ou install-cni-plugin.ps1 pour Windows.
Pour installer le plug-in, exécutez le script approprié pour votre plateforme, en spécifiant
la version du plug-in que vous utilisez. Par exemple, vous pouvez spécifier v1.4.20. Pour
l’installation Linux, fournir une version de plug-in CNI appropriée, par exemple v1.0.1 :
Bash
scripts/install-cni-plugin.sh [azure-cni-plugin-version] [cni-plugin-

version]
PowerShell
scripts\\ install-cni-plugin.ps1 [azure-cni-plugin-version]
Le script installe le plug-in sous /opt/cni/bin pour Linux et c:\cni\bin pour Windows.
Le plug-in installé est fourni avec un fichier de configuration réseau simple qui
fonctionne après l’installation. Il n’a pas besoin d’être mis à jour. Pour en savoir plus sur
les paramètres du fichier, consultez Fichier de configuration réseau CNI.
Tutoriel : Filtrer le trafic réseau avec un
groupe de sécurité réseau à l’aide du
portail Azure
Article • 01/06/2023
Vous pouvez utiliser un groupe de sécurité réseau pour filtrer le trafic réseau sortant et
entrant respectivement à destination et en provenance de ressources Azure dans un
Les groupes de sécurité réseau contiennent des règles de sécurité qui filtrent le trafic
réseau par adresse IP, port et protocole. Quand un groupe de sécurité réseau est associé
à un sous-réseau, des règles de sécurité sont appliquées aux ressources déployées dans
ce sous-réseau.
＂ Créer un groupe de sécurité réseau et les règles associées

＂ Créer des groupes de sécurité d’application
＂ Créer un réseau virtuel et associer un groupe de sécurité réseau à un sous-réseau
＂ Déployer des machines virtuelles et associer leurs interfaces réseau aux groupes de
＂ Tester les filtres de trafic

commencer.
Prérequis
Un abonnement Azure
Connexion à Azure

réseau>Réseau virtuel ou, dans la zone de recherche du portail, recherchez Réseau
virtuel.

Paramètre Valeur
Détails du projet

Sélectionnez OK.
Nom Entrez myVNet.


Un groupe de sécurité d’application vous permet de regrouper des serveurs dont les
fonctions sont similaires, comme des serveurs Web.

réseau>Groupe de sécurité d’application ou, dans la zone de recherche du portail,
recherchez Groupe de sécurité d’application.
3. Dans Créer un groupe de sécurité d’application, sous l’onglet De base, entrez ou

Paramètre Valeur
Détails du projet

Paramètre Valeur
Nom Entrez myAsgWebServers.

6. Répétez les étapes précédentes en spécifiant les valeurs suivantes :
Paramètre Valeur
Détails du projet
Nom Entrez myAsgMgmtServers.


Un groupe de sécurité réseau (NSG) sécurise le trafic réseau dans votre réseau virtuel.

réseau>Groupe de sécurité réseau ou, dans la zone de recherche du portail,
recherchez Groupe de sécurité réseau.
3. Dans Créer un groupe de sécurité réseau, sous l’onglet De base, entrez ou

Paramètre Valeur
Détails du projet
Nom Entrez myNSG.

Associer le groupe de sécurité réseau au sous-

réseau
Dans cette section, vous allons associer le groupe de sécurité réseau au sous-réseau du
réseau virtuel que vous avez créé.
1. Dans la zone de recherche du portail, recherchez myVMNVA.
2. Dans la section Paramètres de myNSG, sélectionnez Sous-réseaux.
3. Dans la page Sous-réseaux, sélectionnez + Associer :

4. Sous Associer un sous-réseau, pour Réseau virtuel, sélectionnez myVNet.
5. Pour Sous-réseau, sélectionnez Par défaut, puis OK.

1. Dans la section Paramètres de myNSG, sélectionnez Règles de sécurité de trafic
entrant.
2. Dans la page Règles de sécurité de trafic entrant, sélectionnez + Ajouter :
3. Créez une règle de sécurité qui autorise les ports 80 et 443 dans le groupe de
sécurité d’application myAsgWebServers. Dans la page Ajouter une règle de
sécurité de trafic entrant, entrez ou sélectionnez les informations suivantes :
Paramètre Valeur
Paramètre Valeur

d’application.
Groupes de sécurité d’application de Sélectionnez myAsgWebServers.

destination
Plages de ports de destination Entrez 80,443.
Protocol Sélectionnez TCP.
Nom Entrez Allow-Web-All.


5. Répétez les étapes 3 à 4 à l’aide des informations suivantes :

Paramètre Valeur

d’application.
Groupe de sécurité d’application de Sélectionnez myAsgMgmtServers.

destination
Plages de ports de destination Entrez 3389.
Protocol sélectionnez N'importe laquelle.
Nom Entrez Allow-RDP-All.
Ｕ Attention
Dans cet article, le protocole RDP (port 3389) est exposé à Internet pour la
machine virtuelle affectée au groupe de sécurité d’application
myAsgMgmtServers.
Pour les environnements de production, au lieu d’exposer le port 3389 sur

Internet, il est recommandé de vous connecter aux ressources Azure à gérer
via un réseau VPN ou Azure Bastion.
Pour plus d'informations sur Azure Bastion, consultez Présentation d'Azure

Bastion.
Une fois que vous avez terminé les étapes 1 à 3, passez en revue les règles que vous
avez créées. Votre liste doit ressembler à la liste de l’exemple suivant :
Créez deux machines virtuelles dans le réseau virtuel.

ressource>Calcul>Machine virtuelle ou, dans la zone de recherche du portail,
recherchez Machine virtuelle.

Paramètre Valeur
Détails du projet
Nom de la machine Entrez myVMWeb.

virtuelle
Options de disponibilité Conservez la valeur par défaut Aucune redondance

d’infrastructure requise.

Paramètre Valeur
Instance Azure Spot Conservez la valeur par défaut (case non cochée).
Taille Sélectionnez Standard_D2s_V3.
Confirmer le mot de Retapez le mot de passe.

passe
Règles des ports

d’entrée
Sélectionner des ports Sélectionnez Aucun.

d’entrée
Paramètre Valeur
Interface réseau
Subnet Sélectionnez par défaut (10.0.0.0/24) .
Adresse IP publique Conservez la valeur par défaut indiquant une

nouvelle IP publique.
Groupe de sécurité réseau de la Sélectionnez Aucun.

carte réseau

6. Sélectionnez Create (Créer). Le déploiement de la machine virtuelle peut prendre

quelques minutes.

Répétez les étapes 1 à 6 mais, à l’étape 2, pour le nom de la machine virtuelle, entrez
myVMMgmt.
Attendez que le déploiement des machines virtuelles soit terminé avant de passer à la
section suivante.
Associer des interfaces réseau à un groupe de

Quand vous avez créé les machines virtuelles, Azure a créé une interface réseau pour
chacune d’elles et l’a attachée à celle-ci.
Ajoutez l’interface réseau de chaque machine virtuelle à l’un des groupes de sécurité
d’application que vous avez créés précédemment :
2. Dans la section Paramètres de la machine virtuelle myVMWeb, sélectionnez Mise

en réseau.
3. Sélectionnez l’onglet Groupes de sécurité d’application, puis sélectionnez

Configurer les groupes de sécurité d’application.
4. Dans Configurer les groupes de sécurité d’application, sélectionnez

myAsgWebServers. Sélectionnez Enregistrer.

5. Répétez les étapes 1 et 2, en recherchant la machine virtuelle myVMMgmt et en

sélectionnant le groupe de sécurité d’application (ASG) myAsgMgmtServers.

1. Dans la zone de recherche du portail, recherchez myVMMgmt.
2. Dans la page Vue d’ensemble, sélectionnez le bouton Se connecter, puis RDP.
3. Sélectionnez Télécharger le fichier RDP.
4. Ouvrez le fichier RDP téléchargé et sélectionnez Connecter. Entrez le nom

d’utilisateur et le mot de passe spécifiés lors de la création de la machine virtuelle.
6. Vous pouvez éventuellement recevoir un avertissement lié au certificat pendant le

processus de connexion. Si vous recevez l’avertissement, sélectionnez Oui ou
La connexion aboutit parce que le trafic entrant en provenance d’Internet à

destination du groupe de sécurité d’application myAsgMgmtServers est autorisé
via le port 3389.
L’interface réseau de myVMMgmt est associée au groupe de sécurité d’application
myAsgMgmtServers et autorise la connexion.
7. Ouvrez une session PowerShell sur myVMMgmt. Connectez-vous à myVMWeb en

PowerShell
mstsc /v:myVmWeb
La connexion RDP de myVMMgmt à myVMWeb aboutit parce que des machines

virtuelles dans le même réseau peuvent communiquer entre elles sur n’importe
quel port par défaut.
Vous ne pouvez pas créer de connexion RDP à la machine virtuelle myVMWeb à

partir d’Internet. La règle de sécurité de myAsgWebServers empêche les
connexions entrantes en provenance d’Internet sur le port 3389. Par défaut, le
trafic entrant en provenance d’Internet est refusé pour toutes les ressources.
8. Pour installer Microsoft IIS sur la machine virtuelle myVMWeb, entrez la

commande suivante à partir d’une session PowerShell sur la machine virtuelle
myVMWeb :
PowerShell
9. Une fois l’installation d’IIS effectuée, déconnectez-vous de la machine virtuelle

myVMWeb. Cela vous laisse ensuite uniquement la connexion Bureau à distance
de la machine virtuelle myVMMgmt.
10. Déconnectez-vous de la machine virtuelle myVMMgmt.
12. Dans la page Vue d’ensemble de myVMWeb, notez l’adresse IP publique de votre
machine virtuelle. L’adresse affichée dans l’exemple suivant est 23.96.39.113, mais
votre adresse est différente :
13. Pour vérifier si vous pouvez accéder au serveur web myVMWeb depuis Internet,
ouvrez un navigateur Internet sur votre ordinateur et accédez à http://<public-
ip-address-from-previous-step> .
Vous voyez cette page par défaut IIS parce que le trafic entrant en provenance
d’Internet à destination du groupe de sécurité d’application myAsgWebServers est
autorisé via le port 80.
L’interface réseau attachée à myVMWeb est associée au groupe de sécurité

d’application myAsgWebServers et autorise la connexion.

Quand vous n’avez plus besoin du groupe de ressources, supprimez-le, ainsi que toutes

Étapes suivantes
Vous avez créé un groupe de sécurité réseau, et vous l’avez associé à un sous-
réseau de réseau virtuel.
Vous avez créé des groupes de sécurité d’application pour le web et la gestion.
Créez deux machines virtuelles et associez leurs interfaces réseau aux groupes de
Vous avez testé le filtrage réseau du groupe de sécurité d’application.
Pour en savoir plus sur les groupes de sécurité réseau, consultez Vue d’ensemble d’un
groupe de sécurité réseau et Gérer un groupe de sécurité réseau.
virtuelle, agissant comme un pare-feu.
Pour apprendre à créer une table de routage, passez au didacticiel suivant.

Filtrer le trafic réseau avec un groupe de
sécurité réseau à l’aide de PowerShell
Vous pouvez filtrer le trafic réseau entrant dans un sous-réseau de réseau virtuel ou qui
en sort, avec un groupe de sécurité réseau. Les groupes de sécurité réseau contiennent
des règles de sécurité qui filtrent le trafic réseau par adresse IP, port et protocole. Les
règles de sécurité sont appliquées aux ressources déployées dans un sous-réseau. Dans
cet article, vous apprendrez comment :
Créer un groupe de sécurité réseau et les règles associées

Créer un réseau virtuel et associer un groupe de sécurité réseau à un sous-réseau
Déployer des machines virtuelles dans un sous-réseau

commencer.
Azure Cloud Shell

Option Exemple/Lien








Un groupe de sécurité réseau contient des règles de sécurité. Les règles de sécurité
spécifient une source et une destination. Les sources et les destinations peuvent être
des groupes de sécurité d’application.

Tout d’abord, créez un groupe de ressources pour toutes les ressources créées dans cet
article avec New-AzResourceGroup. L’exemple suivant crée un groupe de ressources
dans l’emplacement eastus :
Azure PowerShell
Créez un groupe de sécurité d’application avec New-AzApplicationSecurityGroup. Un

groupe de sécurité d’application vous permet de regrouper des serveurs avec des
exigences de filtrage de port similaires. L’exemple suivant crée deux groupes de sécurité
d’application.
Azure PowerShell
$webAsg = New-AzApplicationSecurityGroup `
-Name myAsgWebServers `
-Location eastus
$mgmtAsg = New-AzApplicationSecurityGroup `
-Name myAsgMgmtServers `
-Location eastus

Créez une règle de sécurité avec New-AzNetworkSecurityRuleConfig. L’exemple suivant
crée une règle qui autorise le trafic entrant à partir d’Internet vers le groupe de sécurité
d’application myWebServers par les ports 80 et 443 :
Azure PowerShell
$webRule = New-AzNetworkSecurityRuleConfig `
-Name "Allow-Web-All" `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 100 `
-SourceAddressPrefix Internet `
-SourcePortRange * `
-DestinationApplicationSecurityGroupId $webAsg.id `
-DestinationPortRange 80,443
The following example creates a rule that allows traffic inbound from the
internet to the *myMgmtServers* application security group over port 3389:
$mgmtRule = New-AzNetworkSecurityRuleConfig `
-Name "Allow-RDP-All" `
-Access Allow `
-Protocol Tcp `
-Priority 110 `
-SourceAddressPrefix Internet `
-DestinationApplicationSecurityGroupId $mgmtAsg.id `
-DestinationPortRange 3389
Dans cet article, RDP (port 3389) est exposé sur Internet pour la machine virtuelle
myAsgMgmtServers. Pour les environnements de production, au lieu d’exposer le port
3389 sur Internet, il est recommandé de vous connecter aux ressources Azure que vous
souhaitez gérer à l’aide d’une connexion réseau VPN ou privée.

Créez un groupe de sécurité réseau avec New-AzNetworkSecurityGroup. L’exemple
suivant permet de créer un groupe de sécurité réseau nommé myNsg :
PowerShell
$nsg = New-AzNetworkSecurityGroup `
-Location eastus `
-Name myNsg `
-SecurityRules $webRule,$mgmtRule

Créez un réseau virtuel avec New-AzVirtualNetwork. L’exemple suivant crée un réseau
virtuel nommé myVirtualNetwork :
Azure PowerShell
-Location EastUS `
Créez une configuration de sous-réseau avec New-AzVirtualNetworkSubnetConfig, puis

écrivez la configuration du sous-réseau dans le réseau virtuel avec Set-
AzVirtualNetwork. L’exemple suivant ajoute un sous-réseau nommé mySubnet au réseau
virtuel et l’associe au groupe de sécurité réseau myNsg :
Azure PowerShell
Add-AzVirtualNetworkSubnetConfig `
-Name mySubnet `
-AddressPrefix "10.0.2.0/24" `
-NetworkSecurityGroup $nsg

Avant de créer les machines virtuelles, récupérez l’objet de réseau virtuel avec le sous-
réseau à l’aide de la commande Get-AzVirtualNetwork :
PowerShell
$virtualNetwork = Get-AzVirtualNetwork `
-Resourcegroupname myResourceGroup
Créez une adresse IP publique pour chaque machine virtuelle avec New-
AzPublicIpAddress :
PowerShell
$publicIpWeb = New-AzPublicIpAddress `
-AllocationMethod Dynamic `
-Location eastus `
-Name myVmWeb
$publicIpMgmt = New-AzPublicIpAddress `
-AllocationMethod Dynamic `
-Location eastus `
-Name myVmMgmt
Créez deux interfaces réseau avec New-AzNetworkInterfaceet attribuez une adresse IP

publique à l’interface réseau. L’exemple suivant crée une interface réseau, lui associe
l’adresse IP publique myVmWeb et la rend membre du groupe de sécurité d’application
myAsgWebServers :
PowerShell
$webNic = New-AzNetworkInterface `
-Location eastus `
-Name myVmWeb `
-SubnetId $virtualNetwork.Subnets[0].Id `
-ApplicationSecurityGroupId $webAsg.Id `
-PublicIpAddressId $publicIpWeb.Id
L’exemple suivant crée une interface réseau, lui associe l’adresse IP publique
myVmMgmt et la rend membre du groupe de sécurité d’application myAsgMgmtServers :
PowerShell
$mgmtNic = New-AzNetworkInterface `
-Location eastus `
-Name myVmMgmt `
-SubnetId $virtualNetwork.Subnets[0].Id `
-ApplicationSecurityGroupId $mgmtAsg.Id `
-PublicIpAddressId $publicIpMgmt.Id
Créez deux machines virtuelles dans le réseau virtuel pour pouvoir valider le filtrage du
trafic à une étape ultérieure.
Créez une configuration de machine virtuelle avec New-AzVMConfig, puis créez la

machine virtuelle avec New-AzVM. L’exemple suivant crée une machine virtuelle qui
servira de serveur web. L’option -AsJob crée la machine virtuelle en arrière-plan. Vous
pouvez donc passer à l’étape suivante :
Azure PowerShell
# Create user object

$cred = Get-Credential -Message "Enter a username and password for the
virtual machine."
$webVmConfig = New-AzVMConfig `
-VMName myVmWeb `
-VMSize Standard_DS1_V2 | `
-ComputerName myVmWeb `
-Version latest | `
Add-AzVMNetworkInterface `
-Id $webNic.Id
New-AzVM `
-Location eastus `
-VM $webVmConfig `
-AsJob
Créez une machine virtuelle comme un serveur d’administration :
Azure PowerShell
# Create user object

$cred = Get-Credential -Message "Enter a username and password for the
virtual machine."
# Create the web server virtual machine configuration and virtual machine.
$mgmtVmConfig = New-AzVMConfig `
-VMName myVmMgmt `
-VMSize Standard_DS1_V2 | `
-ComputerName myVmMgmt `
-Version latest | `
Add-AzVMNetworkInterface `
-Id $mgmtNic.Id
New-AzVM `
-Location eastus `
-VM $mgmtVmConfig
La création de la machine virtuelle prend quelques minutes. Ne passez pas à l’étape

suivante avant qu’Azure ait terminé la création de la machine virtuelle.

Utilisez Get-AzPublicIpAddress pour retourner l’adresse IP publique d’une machine
virtuelle. L’exemple suivant retourne l’adresse IP publique de la machine virtuelle
myVmMgmt :
Azure PowerShell
-Name myVmMgmt `
| Select IpAddress
virtuelle myVmMgmt à partir de votre ordinateur local. Remplacez <publicIpAddress>
par l’adresse IP retournée par la commande précédente.
Ouvrez le fichier .rdp téléchargé. Si vous y êtes invité, sélectionnez Connexion.
Entrez le nom d’utilisateur et le mot de passe spécifiés lors de la création de la machine

virtuelle (il se peut que vous deviez choisir Plus de choix, puis Utiliser un compte
différent pour spécifier les informations d’identification que vous avez entrées lors de la
création de la machine virtuelle), puis sélectionnez OK. Un avertissement de certificat
peut s’afficher pendant le processus de connexion. SélectionnezOui pour poursuivre le
processus de connexion.
La connexion réussit, car le port 3389 autorise le trafic entrant depuis Internet vers le
groupe de sécurité d’application myAsgMgmtServers dans lequel se situe l’interface
réseau attachée à la machine virtuelle myVmMgmt.
Utilisez la commande suivante pour créer une connexion Bureau à distance vers la
machine virtuelle myVmWeb à partir de la machine virtuelle myVmMgmt, avec la
commande suivante, à partir de PowerShell :
mstsc /v:myvmWeb
La connexion réussit car une règle de sécurité par défaut au sein de chaque groupe de
sécurité réseau autorise le trafic par tous les ports entre toutes les adresses IP au sein
d’un réseau virtuel. Vous ne pouvez pas créer une connexion Bureau à distance à la
machine virtuelle myVmWeb depuis Internet, car la règle de sécurité pour le
myAsgWebServers n’autorise pas les données entrantes venant d’Internet sur le port
3389.
Utilisez la commande suivante pour installer Microsoft IIS sur la machine virtuelle
myVmWeb à partir de PowerShell :
PowerShell
Une fois l’installation d’IIS terminée, déconnectez-vous de la machine virtuelle

myVmWeb, ce qui vous laisse dans la connexion Bureau à distance de la machine
virtuelle myVmMgmt. Pour afficher l’écran d’accueil d’IIS, ouvrez un navigateur web et
accédez à http://myVmWeb.
Déconnectez-vous de la machine virtuelle myVmMgmt.
Sur votre ordinateur, entrez la commande suivante à partir de PowerShell pour

récupérer l’adresse IP publique du serveur myVmWeb :
Azure PowerShell
-Name myVmWeb `
| Select IpAddress
Pour confirmer que vous pouvez accéder au serveur web myVmWeb sans être dans
Azure, ouvrez un navigateur web sur votre ordinateur et accédez à http://<public-ip-
address-from-previous-step> . La connexion réussit, car le port 80 autorise le trafic
entrant depuis Internet vers le groupe de sécurité d’application myAsgWebServers dans

lequel se situe l’interface réseau attachée à la machine virtuelle myVmWeb.

Quand vous n’avez plus besoin d’un groupe de ressources, vous pouvez utiliser
Remove-AzResourceGroup pour le supprimer ainsi que toutes les ressources qu’il
contient :
Azure PowerShell
Étapes suivantes
Dans cet article, vous avez créé un groupe de sécurité réseau et vous l’avez associé à un
sous-réseau d’un réseau virtuel. Pour en savoir plus sur les groupes de sécurité réseau,
consultez Vue d’ensemble d’un groupe de sécurité réseau et Gérer un groupe de
sécurité réseau.
virtuelle, agissant comme un pare-feu. Pour savoir comment procéder, consultez Créer
Filtrer le trafic réseau avec un groupe de
sécurité réseau à l’aide d’Azure CLI
Article • 01/06/2023
Vous pouvez filtrer le trafic réseau entrant dans un sous-réseau de réseau virtuel ou qui
en sort, avec un groupe de sécurité réseau. Les groupes de sécurité réseau contiennent
des règles de sécurité qui filtrent le trafic réseau par adresse IP, port et protocole. Les
règles de sécurité sont appliquées aux ressources déployées dans un sous-réseau. Dans
cet article, vous apprendrez comment :
Créer un groupe de sécurité réseau et les règles associées

Créer un réseau virtuel et associer un groupe de sécurité réseau à un sous-réseau
Déployer des machines virtuelles dans un sous-réseau
commencer.
Prérequis


upgrade.

Un groupe de sécurité réseau contient des règles de sécurité. Les règles de sécurité
spécifient une source et une destination. Les sources et les destinations peuvent être
des groupes de sécurité d’application.

Tout d’abord, créez un groupe de ressources pour toutes les ressources créées dans cet
article avec az group create. L’exemple suivant crée un groupe de ressources dans
l’emplacement eastus :
Azure CLI
az group create \
--location eastus
Créez un groupe de sécurité d’application avec la commande az network asg create. Un

groupe de sécurité d’application vous permet de regrouper des serveurs avec des
exigences de filtrage de port similaires. L’exemple suivant crée deux groupes de sécurité
d’application.
Azure CLI
az network asg create \

--name myAsgWebServers \
--location eastus
az network asg create \

--name myAsgMgmtServers \
--location eastus

Créez un groupe de sécurité réseau avec la commande az network nsg create. L’exemple
suivant permet de créer un groupe de sécurité réseau nommé myNsg :
Azure CLI
# Create a network security group

az network nsg create \
--name myNsg

Créez une règle de sécurité avec az network nsg rule create. L’exemple suivant crée une
règle qui autorise le trafic entrant à partir d’Internet vers le groupe de sécurité
d’application myWebServers par les ports 80 et 443 :
Azure CLI
az network nsg rule create \

--nsg-name myNsg \
--name Allow-Web-All \
--access Allow \
--protocol Tcp \
--direction Inbound \
--priority 100 \
--source-address-prefix Internet \
--source-port-range "*" \
--destination-asgs "myAsgWebServers" \
--destination-port-range 80 443
L’exemple suivant crée une règle qui autorise le trafic entrant à partir d’Internet vers le
groupe de sécurité d’application myMgmtServers par le port 22 :
Azure CLI

--nsg-name myNsg \
--name Allow-SSH-All \
--access Allow \
--protocol Tcp \
--priority 110 \
--destination-asgs "myAsgMgmtServers" \
--destination-port-range 22
Dans cet article, SSH (port 22) est exposé sur Internet pour la machine virtuelle
myAsgMgmtServers. Pour les environnements de production, au lieu d’exposer le port 22
sur l’Internet, il est recommandé de vous connecter aux ressources Azure que vous
souhaitez gérer à l’aide d’une connexion réseau VPN ou privée.

Créez un réseau virtuel avec la commande az network vnet create. L’exemple suivant
crée un réseau virtuel nommé myVirtualNetwork :
Azure CLI

--address-prefixes 10.0.0.0/16
Ajoutez un sous-réseau au réseau virtuel avec la commande az network vnet subnet

create. L’exemple suivant ajoute un sous-réseau nommé mySubnet au réseau virtuel et
l’associe au groupe de sécurité réseau myNsg :
Azure CLI

--name mySubnet \
--network-security-group myNsg

Créez deux machines virtuelles dans le réseau virtuel pour pouvoir valider le filtrage du
trafic à une étape ultérieure.
machine virtuelle qui servira de serveur web. L’option --asgs myAsgWebServers amène
Azure à rendre l’interface réseau qu’il crée pour la machine virtuelle membre du groupe
de sécurité d’application myAsgWebServers.
L’option --nsg "" est spécifiée pour empêcher la création par Azure d’un groupe de
sécurité réseau par défaut pour l’interface réseau créée par Azure lorsqu’il crée la
machine virtuelle. Pour simplifier cet article, un mot de passe est utilisé. Les clés sont
généralement utilisées dans les déploiements en production. Si vous utilisez des clés,
vous devez également configurer le transfert de l’agent SSH pour les étapes restantes.
Pour plus d’informations, consultez la documentation associée à votre client SSH.
Remplacez <replace-with-your-password> dans la commande suivante par un mot de
passe de votre choix.
Azure CLI
adminPassword="<replace-with-your-password>"
az vm create \
--name myVmWeb \
--image UbuntuLTS \
--subnet mySubnet \
--nsg "" \
--asgs myAsgWebServers \

machine virtuelle créée, une sortie similaire à l’exemple suivant est renvoyée :
Sortie
{
"fqdns": "",
ualMachines/myVmWeb",
"macAddress": "00-0D-3A-23-9A-49",
}
virtuelle à partir d’Internet dans une prochaine étape. Créez une machine virtuelle
comme un serveur d’administration :
Azure CLI
az vm create \
--name myVmMgmt \
--image UbuntuLTS \
--subnet mySubnet \
--nsg "" \
--asgs myAsgMgmtServers \

machine virtuelle, prenez note de la valeur de publicIpAddress dans la sortie retournée.
Cette adresse est utilisée pour accéder à la machine virtuelle à la prochaine étape. Ne
passez pas à l’étape suivante avant qu’Azure ait terminé la création de la machine
virtuelle.

myVmMgmt. Remplacez <publicIpAddress> par l’adresse IP publique de votre machine
virtuelle. Dans l’exemple ci-dessus, l’adresse IP est 13.90.242.231.
Bash
ssh azureuser@<publicIpAddress>
Lorsque vous êtes invité à indiquer un mot de passe, entrez le mot de passe que vous
avez utilisé dans Créer des machines virtuelles.
La connexion réussit, car le port 22 autorise le trafic entrant depuis Internet vers le
groupe de sécurité d’application myAsgMgmtServers dans lequel se situe l’interface
réseau attachée à la machine virtuelle myVmMgmt.
Utilisez la commande suivante pour établir une connexion SSH avec la machine virtuelle
myVmWeb à partir de la machine virtuelle myVmMgmt :
Bash
ssh azureuser@myVmWeb
La connexion réussit car une règle de sécurité par défaut au sein de chaque groupe de
sécurité réseau autorise le trafic par tous les ports entre toutes les adresses IP au sein
d’un réseau virtuel. Vous ne pouvez pas établir une connexion SSH myVmWeb depuis
Internet, car la règle de sécurité pour le myAsgWebServers n’autorise pas les données
entrantes venant d’Internet sur le port 22.
Utilisez les commandes suivantes pour installer le serveur web nginx sur la machine
virtuelle myVmWeb :
Bash
# Update package source

# Install NGINX
sudo apt-get -y install nginx
La machine virtuelle myVmWeb autorise la récupération de nginx par le trafic sortant

vers Internet car une règle de sécurité par défaut autorise tout le trafic sortant vers
Internet. Fermez la session SSH myVmWeb, ce qui vous laisse à l’invite de commandes
username@myVmMgmt:~$ de la machine virtuelle myVmMgmt. Pour récupérer l’écran
d’accueil nginx à partir de la machine virtuelle myVmWeb, entrez la commande suivante

:
Bash
curl myVmWeb
Déconnectez-vous de la machine virtuelle myVmMgmt. Pour confirmer que vous pouvez

accéder au serveur web myVmWeb sans être dans Azure, entrez curl <publicIpAddress>
à partir de votre propre ordinateur. La connexion réussit, car le port 80 autorise le trafic
entrant depuis Internet vers le groupe de sécurité d’application myAsgWebServers dans
lequel se situe l’interface réseau attachée à la machine virtuelle myVmWeb.

Azure CLI
Étapes suivantes
Dans cet article, vous avez créé un groupe de sécurité réseau et vous l’avez associé à un
sous-réseau d’un réseau virtuel. Pour en savoir plus sur les groupes de sécurité réseau,
consultez Vue d’ensemble d’un groupe de sécurité réseau et Gérer un groupe de
sécurité réseau.
virtuelle, agissant comme un pare-feu. Pour savoir comment procéder, consultez Créer
Démarrage rapide – Créer un point de
terminaison privé en utilisant le portail
Azure
Démarrez avec Azure Private Link en créant et utilisant un point de terminaison privé
pour vous connecter en toute sécurité à une application web Azure.
Dans ce guide de démarrage rapide, vous allez créer un point de terminaison privé pour
une application web Azure, puis créer et déployer une machine virtuelle pour tester la
connexion privée.
Vous pouvez créer des points de terminaison privés pour divers services Azure, tels
qu’Azure SQL et Stockage Azure.
Prérequis
Compte Azure avec un abonnement actif. Si vous n’avez pas encore de compte
Azure, créez-en un gratuitement .
Une application web Azure avec un niveau PremiumV2 ou un plan App Service
supérieur déployé dans votre abonnement Azure.
Pour plus d’informations et pour obtenir un exemple, consultez Démarrage

rapide : Créer une application web ASP.NET Core dans Azure.
L’exemple d’application web dans cet article est nommé myWebApp1979.

Remplacez l’exemple par le nom de votre application web.

Créez un réseau virtuel, un sous-réseau et un hôte bastion.
L’hôte Bastion vous permet de vous connecter en toute sécurité à la machine virtuelle
pour tester le point de terminaison privé.
2. Dans la zone de recherche située en haut du portail, entrez Réseau virtuel. Dans
les résultats de recherche, sélectionnez Réseaux virtuels.
3. Sélectionnez + Créer dans Réseaux virtuels.

sélectionnez les informations suivantes.
Paramètre Valeur
Détails du projet

Entrez CreatePrivateEndpointQS-rg dans Name et sélectionnez OK.
Nom Entrez myVNet.
Région Sélectionnez Europe Ouest.
5. Sélectionnez Suivant : Adresses IP ou l’onglet Adresses IP.
6. Sélectionnez l’onglet Adresses IP, ou sélectionnez Suivant : Adresses IP au bas de

la page.
7. Sous l’onglet Adresses IP, entrez les informations suivantes :
Paramètre Valeur
Espace d’adressage IPv4 Entrez 10.1.0.0/16
8. Sous Nom de sous-réseau, sélectionnez le mot par défaut. Si aucun sous-réseau

n’est présent, sélectionnez + Ajouter un sous-réseau.
9. Dans Modifier le sous-réseau, entrez les informations suivantes :
Paramètre Valeur
Nom du sous-réseau Entrez mySubnet
Plage d’adresses de sous-réseau Entrez 10.1.0.0/24
10. Sélectionnez Enregistrer ou Ajouter.
11. Sélectionnez Suivant : Sécurité ou l’onglet Sécurité.

Paramètre Valeur
Nom du bastion Entrez myBastionHost
Espace d’adressage AzureBastionSubnet Entrez 10.1.1.0/26

Pour Nom, entrez myBastionIP.
Sélectionnez OK.
７ Notes
Le réseau virtuel et le sous-réseau sont créés immédiatement. La création de

l’hôte bastion est soumise en tant que tâche et se termine dans les
10 minutes. Vous pouvez passer aux étapes suivantes pendant la création de
l’hôte bastion.
Créer une machine virtuelle de test

Ensuite, créez une machine virtuelle que vous pouvez utiliser pour tester le point de
terminaison privé.

Sélectionnez Machines virtuelles.
3. Sélectionnez + Créer puis Machine virtuelle Azure dans Machines virtuelles.
ou sélectionnez les informations suivantes.
Paramètre Valeur
Détails du projet
Abonnement Sélectionnez votre abonnement Azure.
Resource group Sélectionnez CreatePrivateEndpointQS-rg.
Paramètre Valeur
Nom de la machine Entrez myVM.

virtuelle

disponibilité
Taille Sélectionnez la taille de la machine virtuelle, ou utilisez le

paramètre par défaut.
Compte
administrateur
Confirmer le mot de Entrez de nouveau le mot de passe.

passe
Règles des ports

d’entrée
Aucun port d’entrée Sélectionnez Aucun.

public
6. Sous l’onglet Mise en réseau, entrez ou sélectionnez les informations suivantes.
Paramètre Valeur
Interface réseau

７ Notes
Créer un Private Endpoint

Ensuite, vous allez créer un point de terminaison privé pour l’application web que vous
avez créée dans la section des prérequis.
） Important
Vous devez disposer d’une application web Azure précédemment déployée pour
suivre les étapes décrites dans cet article. Pour plus d’informations, consultez
Prérequis.
1. Dans la zone de recherche située en haut du portail, entrez Point de terminaison

privé. Sélectionnez Points de terminaison privés.
2. Sélectionnez + Créer dans Points de terminaison privés.
3. Sous l’onglet Général de Créer un point de terminaison privé, entrez ou

sélectionnez les informations suivantes.
Paramètre Valeur
Détails du projet
Resource group Sélectionnez CreatePrivateEndpointQS-rg
Nom Entrez myPrivateEndpoint.
Nom de l'interface réseau Conservez la valeur par défaut myPrivateEndpoint-nic.
4. Sélectionnez Suivant : Ressource.
5. Dans le volet Ressource, entrez ou sélectionnez les informations suivantes.
Paramètre Valeur
Méthode de Conservez la valeur par défaut Se connecter à une ressource Azure

connexion dans mon répertoire.
Type de ressource Sélectionnez Microsoft.Web/sites.
Ressource Sélectionnez mywebapp1979.
Sous-ressource Sélectionnez les sites.

cible
6. Sélectionnez Suivant : réseau virtuel.
7. Dans Réseau virtuel, entrez ou sélectionnez les informations suivantes.
Paramètre Valeur
Mise en réseau
Subnet Sélectionnez myVNet/mySubnet (10.1.0.0/24).

Paramètre Valeur
Stratégie réseau pour Sélectionnez Modifier pour appliquer des groupes de sécurité
les points de réseau ou des tables de routage au sous-réseau contenant le point
terminaison privés de terminaison privé.
Dans Modifier la stratégie réseau du sous-réseau, cochez la case
en regard de Groupes de sécurité réseau et Tables de routage.
Sélectionnez Enregistrer.
Pour plus d’informations, consultez Gestion des stratégies réseau

des points de terminaison privés.
Adresse IP dynamique
Paramètre Valeur
Configuration d’adresse IP privée Sélectionnez Allouer dynamiquement l’adresse IP.
8. Sélectionnez Suivant : DNS.

9. Conservez les valeurs par défaut dans DNS. Sélectionnez Suivant : Balises, puis
Suivant : Vérifier + créer.
Tester la connectivité au point de terminaison

privé
Utilisez la machine virtuelle que vous avez créée pour vous connecter à l’application web
via le point de terminaison privé.

3. Dans la page de vue d’ensemble pour myVM, sélectionnez Se connecter, puis

Bastion.
4. Entrez le nom d’utilisateur et le mot de passe que vous avez utilisés lors de la
création de la machine virtuelle.
6. Une fois connecté, ouvrez PowerShell sur le serveur.
7. Entrez nslookup mywebapp1979.azurewebsites.net . Vous recevez un message

similaire à l’exemple suivant :
PowerShell
Server: UnKnown
Address: 168.63.129.16
Name: mywebapp1979.privatelink.azurewebsites.net
Address: 10.1.0.5
Aliases: mywebapp1979.azurewebsites.net
Une adresse IP privée 10.1.0.5 est retournée pour le nom de l’application web si
vous avez choisi l’adresse IP dynamique dans les étapes précédentes. Cette adresse
se trouve dans le sous-réseau du réseau virtuel que vous avez créé plus tôt.
8. Dans la connexion de l’hôte bastion à myVM, ouvrez le navigateur web.

9. Entrez l’URL de votre application web, https://mywebapp1979.azurewebsites.net .
Si votre application web n’a pas été déployée, vous obtiendrez la page
d’application web par défaut suivante :
10. Fermez la connexion à myVM.

Si vous ne comptez pas continuer à utiliser cette application web, supprimez le réseau
virtuel, la machine virtuelle et l’application web en effectuant les étapes suivantes :
1. Dans le volet gauche, sélectionnez Groupes de ressources.
2. Sélectionnez CreatePrivateEndpointQS-rg.
4. Sous Entrez le nom du groupe de ressources, entre CreatePrivateEndpointQS-rg.
Étapes suivantes
Dans le cadre de ce guide de démarrage rapide, vous avez créé les éléments suivants :
Un réseau virtuel et un hôte Bastion
Une machine virtuelle

Un point de terminaison privé pour une application web Azure
Vous avez utilisé la machine virtuelle pour tester la connectivité à l’application web sur le
point de terminaison privé.
Pour plus d’informations sur les services qui prennent en charge les points de
terminaison privés, consultez :

Démarrage rapide : Créer un point de
terminaison privé en utilisant Azure
PowerShell
Démarrez avec Azure Private Link en utilisant un point de terminaison privé pour vous
connecter en toute sécurité à une application web Azure.
connexion privée.
Prérequis



module Azure PowerShell version 5.4.1 ou ultérieure pour les besoins de cet article. Pour
trouver la version installée, exécutez Get-Module -ListAvailable Az . Si vous devez
effectuer une mise à niveau, consultez Installation et configuration d’Azure PowerShell.
Si vous exécutez PowerShell en local, vous devez également exécuter Connect-AzAccount

Un groupe de ressources Azure est un conteneur logique dans lequel les ressources
Azure sont déployées et gérées.
Créez un groupe de ressources avec New-AzResourceGroup :
Azure PowerShell
New-AzResourceGroup -Name 'CreatePrivateEndpointQS-rg' -Location 'eastus'

Un réseau virtuel et un sous-réseau sont requis pour héberger l’adresse IP privée du
point de terminaison privé. Vous allez créer un hôte bastion pour vous connecter en
toute sécurité à la machine virtuelle pour tester le point de terminaison privé. Vous allez
créer la machine virtuelle dans une section ultérieure.
Dans cette section, vous allez :
Créez un réseau virtuel avec New-AzVirtualNetwork
Créer des configurations de sous-réseau pour le sous-réseau principal et le sous-

réseau bastion avec New-AzVirtualNetworkSubnetConfig
Créez une adresse IP publique pour l’hôte bastion avec New-AzPublicIpAddress
Créez l’hôte bastion avec New-AzBastion
Azure PowerShell
## Configure the back-end subnet. ##

$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name myBackendSubnet -
AddressPrefix 10.1.0.0/24
## Create the Azure Bastion subnet. ##

$bastsubnetConfig = New-AzVirtualNetworkSubnetConfig -Name
AzureBastionSubnet -AddressPrefix 10.1.1.0/24
## Create the virtual network. ##

$net = @{
Name = 'MyVNet'
ResourceGroupName = 'CreatePrivateEndpointQS-rg'
Location = 'eastus'
Subnet = $subnetConfig, $bastsubnetConfig
}
$vnet = New-AzVirtualNetwork @net
## Create the public IP address for the bastion host. ##

$ip = @{
Name = 'myBastionIP'
Location = 'eastus'
Sku = 'Standard'
AllocationMethod = 'Static'
Zone = 1,2,3
}
$publicip = New-AzPublicIpAddress @ip
## Create the bastion host. ##

$bastion = @{
Name = 'myBastion'
PublicIpAddress = $publicip
VirtualNetwork = $vnet
}
New-AzBastion @bastion -AsJob

Un service Azure qui prend en charge les points de terminaison privés est nécessaire
pour configurer le point de terminaison privé et la connexion au réseau virtuel. Pour
obtenir les exemples de cet article, nous utilisons une application web Azure à partir des
conditions préalables. Pour plus d’informations sur les services Azure qui prennent en
charge un point de terminaison privé, consultez Disponibilité d’Azure Private Link.
Un point de terminaison privé peut avoir une adresse IP statique ou affectée

dynamiquement.
） Important
Prérequis.
Créez une connexion de service de liaison privée avec New-

AzPrivateLinkServiceConnection.
Créez le point de terminaison privé avec New-AzPrivateEndpoint.
Si vous le souhaitez, créez la configuration IP statique du point de terminaison

privé avec New-AzPrivateEndpointIpConfiguration.
Azure PowerShell
## Place the previously created webapp into a variable. ##

$webapp = Get-AzWebApp -ResourceGroupName CreatePrivateEndpointQS-rg -
Name myWebApp1979
## Create the private endpoint connection. ##

$pec = @{
Name = 'myConnection'
PrivateLinkServiceId = $webapp.ID
GroupID = 'sites'
}
$privateEndpointConnection = New-AzPrivateLinkServiceConnection @pec
## Place the virtual network you created previously into a variable. ##

$vnet = Get-AzVirtualNetwork -ResourceGroupName
'CreatePrivateEndpointQS-rg' -Name 'myVNet'
## Create the private endpoint. ##

$pe = @{
Name = 'myPrivateEndpoint'
Location = 'eastus'
Subnet = $vnet.Subnets[0]
PrivateLinkServiceConnection = $privateEndpointConnection
}
New-AzPrivateEndpoint @pe
Configurer la zone DNS privée

Une zone DNS privée est utilisée pour résoudre le nom DNS du point de terminaison
privé dans le réseau virtuel. Pour cet exemple, nous utilisons les informations DNS pour
une application web Azure. Pour plus d’informations sur la configuration DNS des points
de terminaison privés, consultez Configuration DNS des points de terminaison privés
Azure.
Créer une zone DNS Azure privée avec New-AzPrivateDnsZone
Lier la zone DNS au réseau virtuel que vous avez créé précédemment avec New-
AzPrivateDnsVirtualNetworkLink
Créer une configuration de zone DNS avec New-AzPrivateDnsZoneConfig

Créer un groupe de zones DNS avec New-AzPrivateDnsZoneGroup
Azure PowerShell
## Place the virtual network into a variable. ##

$vnet = Get-AzVirtualNetwork -ResourceGroupName 'CreatePrivateEndpointQS-rg'
-Name 'myVNet'
## Create the private DNS zone. ##

$zn = @{
Name = 'privatelink.azurewebsites.net'
}
$zone = New-AzPrivateDnsZone @zn
## Create a DNS network link. ##

$lk = @{
ZoneName = 'privatelink.azurewebsites.net'
Name = 'myLink'
VirtualNetworkId = $vnet.Id
}
$link = New-AzPrivateDnsVirtualNetworkLink @lk
## Configure the DNS zone. ##

$cg = @{
Name = 'privatelink.azurewebsites.net'
PrivateDnsZoneId = $zone.ResourceId
}
$config = New-AzPrivateDnsZoneConfig @cg
## Create the DNS zone group. ##

$zg = @{
PrivateEndpointName = 'myPrivateEndpoint'
Name = 'myZoneGroup'
PrivateDnsZoneConfig = $config
}
New-AzPrivateDnsZoneGroup @zg

Pour vérifier l’adresse IP statique et les fonctionnalités du point de terminaison privé,
une machine virtuelle de test connectée à votre réseau virtuel est requise.
Créer des informations d’identification de connexion pour la machine virtuelle avec

Get-Credential
Créez une interface réseau avec New-AzNetworkInterface pour la machine virtuelle
Créer une configuration de machine virtuelle avec New-AzVMConfig, Set-

AzVMOperatingSystem, Set-AzVMSourceImage et Add-AzVMNetworkInterface
Créez la machine virtuelle avec New-AzVM
Azure PowerShell
## Create the credential for the virtual machine. Enter a username and
password at the prompt. ##
$cred = Get-Credential
## Place the virtual network into a variable. ##

$vnet = Get-AzVirtualNetwork -Name myVNet -ResourceGroupName
CreatePrivateEndpointQS-rg
## Create a network interface for the virtual machine. ##

$nic = @{
Name = 'myNicVM'
Location = 'eastus'
Subnet = $vnet.Subnets[0]
}
$nicVM = New-AzNetworkInterface @nic
## Create the configuration for the virtual machine. ##

$vm1 = @{
VMName = 'myVM'
VMSize = 'Standard_DS1_v2'
}
$vm2 = @{
ComputerName = 'myVM'
Credential = $cred
}
$vm3 = @{
PublisherName = 'MicrosoftWindowsServer'
Offer = 'WindowsServer'
Skus = '2019-Datacenter'
Version = 'latest'
}
$vmConfig =
New-AzVMConfig @vm1 | Set-AzVMOperatingSystem -Windows @vm2 | Set-
AzVMSourceImage @vm3 | Add-AzVMNetworkInterface -Id $nicVM.Id
## Create the virtual machine. ##

New-AzVM -ResourceGroupName 'CreatePrivateEndpointQS-rg' -Location 'eastus'
-VM $vmConfig
７ Notes
Tester la connectivité avec point de terminaison

privé
Utilisez la machine virtuelle que vous avez créée à l’étape précédente pour vous
connecter à l’application web sur le point de terminaison privé.


Bastion.
création de la machine virtuelle. Sélectionnez Connecter.
7. Entrez nslookup mywebapp1979.azurewebsites.net . Remplacez mywebapp1979 par

le nom de l’application web que vous avez créée précédemment. Vous recevez un
message similaire à l’exemple suivant :
PowerShell
Server: UnKnown
Address: 168.63.129.16
Address: 10.0.0.10

Lorsque vous n'en avez plus besoin, vous pouvez utiliser la commande Remove-
AzResourceGroup pour supprimer le groupe de ressources, le réseau virtuel et les
ressources restantes.
Azure PowerShell
Remove-AzResourceGroup -Name 'CreatePrivateEndpointQS-rg'

Étapes suivantes

Démarrage rapide – Créer un point de
terminaison privé en utilisant le portail
Azure CLI
Article • 01/06/2023
Démarrez avec Azure Private Link en utilisant un point de terminaison privé pour vous
connecter en toute sécurité à une application web Azure.
connexion privée.
Prérequis
Pour vous assurer que votre abonnement est actif, connectez-vous au portail
Azure, puis vérifiez votre version en exécutant az login .


La dernière version d’Azure CLI installée.
Vérifiez votre version d’Azure CLI dans un terminal ou une fenêtre de commande
en exécutant az --version . Pour obtenir la dernière version, consultez les notes de
publication les plus récentes.
Si vous ne disposez pas de la dernière version d’Azure CLI, mettez-la à jour en

suivant le guide d’installation pour votre système d’exploitation ou votre
plateforme.
Un groupe de ressources Azure est un conteneur logique dans lequel les ressources
Azure sont déployées et gérées.
Commencez par créer un groupe de ressources à l’aide de la commande az group

create :
Azure CLI
az group create \
--name CreatePrivateEndpointQS-rg \
--location eastus

Un réseau virtuel et un sous-réseau sont requis pour héberger l’adresse IP privée du
point de terminaison privé. Vous allez créer un hôte bastion pour vous connecter en
toute sécurité à la machine virtuelle pour tester le point de terminaison privé. Vous allez
créer la machine virtuelle dans une section ultérieure.
Créez un réseau virtuel à l’aide de la commande az network vnet create.
Azure CLI

--resource-group CreatePrivateEndpointQS-rg \
--location eastus \
--name myVNet \
--subnet-name myBackendSubnet \
--subnet-prefixes 10.0.0.0/24
Créez un sous-réseau bastion à l’aide de la commande az network vnet subnet create.
Azure CLI

--name AzureBastionSubnet \
--vnet-name myVNet \
--address-prefixes 10.0.1.0/27
Créez une adresse IP publique pour l’hôte bastion à l’aide de la commande az network
public-ip create.
Azure CLI

--name myBastionIP \
--sku Standard \
--zone 1 2 3
Créez l’hôte bastion à l’aide de la commande az network bastion create
Azure CLI
az network bastion create \

--name myBastionHost \
--public-ip-address myBastionIP \
--location eastus
Le déploiement de l’hôte Azure Bastion peut prendre quelques minutes.

Un service Azure qui prend en charge les points de terminaison privés est nécessaire
pour configurer le point de terminaison privé et la connexion au réseau virtuel. Pour
accéder aux exemples de cet article, vous allez utiliser l’application web Azure spécifiée
dans les prérequis. Pour plus d’informations sur les services Azure qui prennent en
charge un point de terminaison privé, consultez Disponibilité d’Azure Private Link.
Un point de terminaison privé peut avoir une adresse IP statique ou affectée

dynamiquement.
） Important
Prérequis.
Placez l’ID de ressource de l’application web que vous avez créée précédemment dans
une variable d’interpréteur de commandes à l’aide de la commande az webapp list.
Créez le point de terminaison privé à l’aide de la commande az network private-
endpoint create.
Azure CLI
id=$(az webapp list \

--query '[].[id]' \
--output tsv)
az network private-endpoint create \

--connection-name myConnection
--name myPrivateEndpoint \
--private-connection-resource-id $id \
--subnet myBackendSubnet \
--group-id sites \
--vnet-name myVNet
Configurer la zone DNS privée

Une zone DNS privée est utilisée pour résoudre le nom DNS du point de terminaison
privé dans le réseau virtuel. Pour cet exemple, nous utilisons les informations DNS pour
une application web Azure. Pour plus d’informations sur la configuration DNS des points
de terminaison privés, consultez Configuration DNS des points de terminaison privés
Azure.
Créez une zone DNS Azure privée à l’aide de la commande az network private-dns zone
create.
Azure CLI
az network private-dns zone create \

--name "privatelink.azurewebsites.net"
Liez la zone DNS au réseau virtuel que vous avez créé précédemment, à l’aide de la
commande az network private-dns link vnet create.
Azure CLI
az network private-dns link vnet create \

--zone-name "privatelink.azurewebsites.net" \
--name MyDNSLink \
--virtual-network myVNet \
--registration-enabled false
Créez un groupe de zones DNS à l’aide de la commande az network private-endpoint
dns-zone-group create.
Azure CLI
az network private-endpoint dns-zone-group create \

--endpoint-name myPrivateEndpoint \
--name MyZoneGroup \
--private-dns-zone "privatelink.azurewebsites.net" \
--zone-name webapp

Pour vérifier l’adresse IP statique et les fonctionnalités du point de terminaison privé,
une machine virtuelle de test connectée à votre réseau virtuel est requise.
Créez la machine virtuelle à l’aide de la commande az vm create.
Azure CLI
az vm create \
--name myVM \
--image Win2019Datacenter \
--public-ip-address "" \
--subnet myBackendSubnet \
--admin-username azureuser
７ Notes
Tester la connectivité avec point de terminaison

privé
Utilisez la machine virtuelle que vous avez créée à l’étape précédente pour vous
connecter à l’application web sur le point de terminaison privé.


Bastion.
création de la machine virtuelle. Sélectionnez Connecter.
7. Entrez nslookup mywebapp1979.azurewebsites.net . Remplacez mywebapp1979 par

le nom de l’application web que vous avez créée précédemment. Vous recevez un
message similaire à l’exemple suivant :
PowerShell
Server: UnKnown
Address: 168.63.129.16
Address: 10.0.0.10


Lorsque vous n’en avez plus besoin, utilisez la commande az group delete pour
supprimer le groupe de ressources, le service de liaison privée, l’équilibreur de charge et
toutes les ressources associées.
Azure CLI
az group delete \
--name CreatePrivateEndpointQS-rg
Étapes suivantes

Tutoriel : Restreindre l’accès réseau aux
Article • 01/06/2023

toujours sur le serveur principal de Microsoft Azure.

＂ Ajouter un sous-réseau et activer un point de terminaison de service
＂ Créer une ressource Azure et autoriser l’accès réseau à cette ressource uniquement
＂ Déployer une machine virtuelle sur chaque sous-réseau
＂ Vérifier l’accès à une ressource à partir d’un sous-réseau
＂ Vérifier que l’accès à une ressource est refusé à partir d’un sous-réseau et d’Internet
CLI ou PowerShell.

commencer.
Prérequis
Un abonnement Azure
Connexion à Azure
1. Dans le menu du portail Azure, sélectionnez + Créer une ressource.
3. Dans l'onglet De base, entrez les informations suivantes, puis sélectionnez

Suivant : Adresses IP >.
Paramètre Valeur

4. Dans l'onglet Adresses IP, sélectionnez les paramètres d'adresse IP suivants, puis
sélectionnez Réviser + créer.
Paramètre Valeur
Espace d’adressage IPv4 Laissez la valeur par défaut.
Nom du sous-réseau Sélectionnez Par défaut et changez le nom du sous-réseau en

« Public ».
Plage d’adresses de sous- Laissez la valeur par défaut.

réseau
5. Si les contrôles de validation réussissent, sélectionnez Créer.
6. Attendez que le déploiement se termine, puis sélectionnez Accéder à la ressource

ou passez à la section suivante.

Les points de terminaison de service sont activés par service, par sous-réseau. Pour créer
un sous-réseau et activer un point de terminaison de service pour le sous-réseau :
1. Si vous n’êtes pas déjà sur la page de ressources du réseau virtuel, vous pouvez
rechercher le réseau virtuel créé dans la case située en haut du portail. Saisissez
myVirtualNetwork, et sélectionnez-le dans la liste.
2. Sélectionnez Sous-réseaux sous Paramètres, puis sélectionnez + Sous-réseau

comme indiqué ici :
3. Dans la page Ajouter un sous-réseau, entrez ou sélectionnez les informations
suivantes, puis sélectionnez Enregistrer :
Paramètre Valeur
Name Privé
Plage d’adresses de sous-réseau Laissez la valeur par défaut
Points de terminaison de service Sélectionnez Microsoft.Storage
Stratégies de points de terminaison de Conservez la valeur par défaut. 0

service sélectionné.
Ｕ Attention
Avant d’activer un point de terminaison de service pour un sous-réseau existant qui

contient des ressources, consultez Modifier les paramètres de sous-réseau.

Par défaut, toutes les instances de machines virtuelles d’un sous-réseau peuvent
communiquer avec l’ensemble des ressources. Vous pouvez limiter les communications
vers et à partir de toutes les ressources d’un sous-réseau par la création d’un groupe de
sécurité réseau et son association au sous-réseau :
1. Dans la zone de recherche située en haut du portail Azure, recherchez les groupes
2. Dans la page Groupe de sécurité réseau, sélectionnez + Créer.

Paramètre Valeur
Resource group Sélectionnez myResourceGroup dans la liste
Nom Entrez myNsgPrivate
Emplacement Sélectionnez USA Est.
4. Sélectionnez Vérifier + créer et, lorsque le contrôle de validation est réussi,

5. Une fois le groupe de sécurité réseau créé, sélectionnez Accéder à la ressource ou
recherchez myNsgPrivate en haut du portail Azure.
6. Sous Paramètres, sélectionnez Règles de sécurité de trafic sortant, puis sélectionnez

+ Ajouter.
7. Créer une règle qui autorise les communications sortantes vers le service Stockage
Azure. Saisissez ou sélectionnez les informations suivantes, puis sélectionnez
Ajouter :
Paramètre Valeur
Balise du service Sélectionnez VirtualNetwork

source
Source port *
ranges
Identification de Sélectionnez Stockage

destination
Plages de ports Remplacez par 445. Le protocole SMB est utilisé pour se connecter à un
de destination partage de fichiers créé lors d’une étape ultérieure.
Protocol Quelconque
Action Autoriser
Priority 100
Nom Renommez avec Allow-Storage-All

8. Créer une règle de sécurité de trafic sortant qui refuse les communications vers
Internet. Cette règle qui permet la communication Internet sortante se substitue à
une règle par défaut dans tous les groupes de sécurité réseau. Répétez les étapes 6
à 9 ci-dessus en utilisant les valeurs suivantes, puis sélectionnez Ajouter :
Paramètre Valeur
Balise du service source Sélectionnez VirtualNetwork
Identification de destination Sélectionnez Internet
Plages de ports de destination *
Protocol Quelconque
Action Modifiez la valeur par défaut en spécifiant Refuser.
Priority 110
Name Remplacez par Deny-Internet-All

9. Créez une règle de sécurité de trafic entrant qui autorise le trafic du protocole RDP
(Remote Desktop Protocol) vers le sous-réseau en provenance de n’importe quel
endroit. La règle remplace une règle de sécurité par défaut qui refuse tout le trafic
entrant provenant d’Internet. Les connexions Bureau à distance sont autorisées sur
le sous-réseau afin que la connectivité puisse être testée dans une étape ultérieure.
Sous Paramètres, sélectionnez Règles de sécurité de trafic entrant, puis sélectionnez
+ Ajouter.
10. Entrez ou sélectionnez les valeurs suivantes, puis sélectionnez Ajouter.

Paramètre Valeur
Source Quelconque
Identification de destination Sélectionnez VirtualNetwork
Plages de ports de destination Remplacez par 3389
Protocol Quelconque
Action Autoriser
Priority 120
Name Remplacez par Allow-RDP-All

２ Avertissement
Le port RDP 3389 est exposé à Internet. Ceci est recommandé uniquement
pour les tests. Pour Environnements de production, nous vous recommandons
d’utiliser une connexion VPN ou privée.
11. Sélectionnez Sous-réseaux sous Paramètres, puis sélectionnez + Associer.
12. Sélectionnez myVirtualNetwork sous Réseau virtuel, puis sélectionnez Privé sous
Sous-réseaux. Sélectionnez OK pour associer le groupe de sécurité réseau au sous-
réseau sélectionné.

des services Azure, qui sont activées pour les points de terminaison varient d’un service
à l’autre. Pour connaître les étapes à suivre, consultez la documentation relative à
chacun des services. La suite de ce tutoriel comprend des étapes permettant de
restreindre, par exemple, l’accès réseau pour un compte Stockage Azure.

2. Entrez « Compte de stockage » dans la barre de recherche, puis sélectionnez-le

dans le menu déroulant. Sélectionnez ensuite Créer.
3. Entrez les informations suivantes :
Paramètre Valeur
Resource Sélectionner myResourceGroup

group
Nom du Entrez un nom qui est unique dans tous les emplacements Azure. La
compte de longueur du nom doit être comprise entre 3 et 24 caractères, en utilisant
stockage uniquement des chiffres et des lettres minuscules.
Région Sélectionnez (États-Unis) USA Est
Performances standard
Redondance Stockage localement redondant (LRS)

4. Sélectionnez Créer + vérifieret, lorsque les contrôles de validation ont réussi,
cliquez sur Créer.
７ Notes
Le déploiement peut prendre quelques minutes.
5. Une fois le compte de stockage créé, sélectionnez Accéder à la ressource.

1. Sélectionnez Partages de fichiers sous Stockage de données, puis sélectionnez +
Partage de fichiers.
2. Entrez ou définissez les valeurs suivantes pour le partage de fichiers, puis
sélectionnez Créer :
Paramètre Valeur
Nom my-file-share
Quota Sélectionnez Définir sur la valeur maximale.
Niveau Laissez la valeur par défaut, Transaction optimisée.

3. Le nouveau partage de fichiers devrait apparaître sur la page de partage de
fichiers, si ce n'est pas le cas, sélectionnez le bouton Actualiser en haut de la page.
Restreindre l’accès réseau à un sous-réseau

clients de n’importe quel réseau, y compris Internet. Vous pouvez limiter l’accès réseau à
partir d’Internet et de tous les autres sous-réseaux de tous les réseaux virtuels (à
l’exception du sous-réseau Privé du réseau virtuel myVirtualNetwork). Pour limiter
l’accès réseau à un sous-réseau :
1. Sous Paramètres pour votre compte de stockage (nom unique), sélectionnez Mise
en réseau.
2. Sélectionnez Autoriser l’accès de Réseaux sélectionnés puis + Ajouter un réseau

existant.
3. Sous Ajouter des réseaux, sélectionnez les valeurs suivantes puis Ajouter :
Paramètre Valeur
Réseaux virtuels myVirtualNetwork
Sous-réseaux Privé
4. Sélectionnez le bouton Enregistrer pour enregistrer la configuration du réseau

virtuel.
5. Sélectionnez Clés d'accès sous Sécurité + mise en réseau pour le compte de
stockage et sélectionnez Afficher les clés. Notez la valeur de clé1 pour l'utiliser
dans une étape ultérieure lors du mappage du partage de fichiers dans une
machine virtuelle.


1. Dans le portail Azure, sélectionnez + Créer une ressource.
3. Sous l’onglet Informations de base, entrez ou sélectionnez les informations

suivantes :
Paramètre Valeur
Resource Sélectionnez myResourceGroup, qui a été créé précédemment.

group
Paramètre Valeur
Nom de la Entrez myVmPublic

machine
virtuelle
Région (États-Unis) USA Est
Options de Zone de disponibilité

disponibilité
Zone de 1
disponibilité
Image Sélectionnez une image de système d’exploitation. Pour cette machine

virtuelle, Centre de données Windows Server 2019 – Gen1 est sélectionnée.
Taille Sélectionnez la taille d’instance de machine virtuelle que vous souhaitez

utiliser
Nom Entrez un nom d’utilisateur de votre choix.

d’utilisateur
Aucun port Autoriser les ports sélectionnés

d’entrée
public
Sélectionner Conservez le paramètre par défaut RDP (3389)

des ports
d’entrée

Paramètre Valeur
Réseau Sélectionnez myVirtualNetwork.

virtuel
Groupe de Sélectionnez Avancé. Le portail crée automatiquement pour vous un

sécurité groupe de sécurité réseau qui autorise le port 3389. Vous aurez besoin de
réseau de la ce port ouvert pour vous connecter à la machine virtuelle dans une étape
carte réseau ultérieure.


myVmPublic, qui doit être démarrée.

1. Répétez les étapes 1-5 pour créer une deuxième machine virtuelle. À l’étape 3,
nommez la machine virtuelle myVmPrivate. À l’étape 4, sélectionnez le sous-réseau
Privé et définissez le groupe de sécurité réseau sur Aucun.

２ Avertissement
Ne passez à l’étape suivante que lorsque le déploiement sera terminé.

myVmPrivate, qui doit être démarrée.

1. Une fois que la machine virtuelle myVmPrivate a été créée, allez à la page d'aperçu
de la machine virtuelle. Pour vous connecter à la machine virtuelle, sélectionnez
Connexion, puis sélectionnez RDP dans la liste déroulante.
2. Sélectionnez Télécharger le fichier RDP pour télécharger le fichier de Bureau à

distance sur votre ordinateur.
3. Ouvrez le fichier .rdp téléchargé. Lorsque vous y êtes invité, sélectionnez
Connexion.
4. Entrez le nom d’utilisateur et le mot de passe spécifiés lors de la création de la

machine virtuelle. Vous devrez peut-être sélectionner Plus de choix puis Utiliser un
autre compte pour spécifier les informations d’identification que vous avez entrées
lorsque vous avez créé la machine virtuelle. Pour le champ d’adresse e-mail, entrez
les informations d’identification « Compte d’administrateur : nom d’utilisateur »
que vous avez spécifiées précédemment. Sélectionnez OK pour vous connecter à la
machine virtuelle.
７ Notes
Un avertissement de certificat peut s’afficher pendant le processus de

connexion. Si vous recevez l’avertissement, sélectionnez Oui ou Continuer
pour poursuivre le processus de connexion.
5. Une fois connecté, ouvrez Windows PowerShell. Utilisez le script ci-dessous pour
mapper le partage de fichiers Azure au lecteur Z à l’aide de PowerShell. Remplacez
<storage-account-key> et les deux variables <storage-account-name> par les
valeurs récupérées plus tôt lors des étapes de création du compte de stockage.
PowerShell

AsPlainText -Force

PowerShell

---- --------- --------- -------- ----
Z FileSystem
\\mystorage007.file.core.windows.net\my-f...
6. Fermez les sessions Bureau à distance sur la machine virtuelle myVmPrivate.

refusé
À partir de myVmPublic :
1. Entrez myVmPublic dans le champ Rechercher des ressources, services et
documents en haut du portail. Quand myVmPublic apparaît dans les résultats de
la recherche, sélectionnez cette entrée.
2. Répétez les étapes 1 à 5 ci-dessus dans Vérifier l’accès au compte de stockage

pour la machine virtuelle myVmPublic.
Après un court délai d’attente, vous recevez une erreur New-PSDrive : Access is
denied . L’accès est refusé car la machine virtuelle myVmPublic est déployée sur le
sous-réseau Public. Le sous-réseau Public ne dispose d’aucun point de terminaison

de service activé pour le Stockage Azure. Le compte de stockage permet
uniquement l’accès à partir du sous-réseau Private et non au sous-réseau Public.
PowerShell
New-PSDrive : Access is denied

At line:1 char:1
+ New-PSDrive -Name Z -PSProvider FileSystem -Root "\\mystorage007.file
...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Z:PSDriveInfo) [New-
PSDrive], Win32Exception
+ Fu llyQualifiedErrorId :
CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand
3. Fermez les sessions Bureau à distance sur la machine virtuelle myVmPublic.

À partir d’un ordinateur local :
1. Dans le portail Azure, accédez au compte de stockage nommé de manière unique
que vous avez créé précédemment. Par exemple, mystorage007.
2. Sélectionnez Partages de fichiers sous Stockage de données, puis sélectionnez le

fichier my-file-share créé plus tôt.
3. Vous devriez obtenir le message d’erreur suivant :
７ Notes
L’accès est refusé, car votre ordinateur ne se trouve pas dans le sous-réseau Private


Étapes suivantes
Dans ce tutoriel, vous avez activé un point de terminaison de service pour un sous-
être activés pour les ressources déployées à partir de différents services Azure. Vous
Si vous avez plusieurs réseaux virtuels dans votre compte, vous souhaiterez peut-être
établir une connectivité entre eux afin que les ressources puissent communiquer entre
elles. Pour savoir comment connecter des réseaux virtuels, passez au didacticiel suivant.

Restreindre l’accès réseau aux
en utilisant Azure PowerShell
Article • 11/05/2023

toujours sur le serveur principal de Microsoft Azure. Dans cet article, vous apprendrez
comment :
Créer un réseau virtuel avec un sous-réseau

Ajouter un sous-réseau et activer un point de terminaison de service
Créer une ressource Azure et autoriser l’accès réseau à cette ressource uniquement
Déployer une machine virtuelle sur chaque sous-réseau
Vérifier l’accès à une ressource à partir d’un sous-réseau
Vérifier que l’accès à une ressource est refusé à partir d’un sous-réseau et
d’Internet

commencer.
Azure Cloud Shell


Option Exemple/Lien







ressources avec New-AzResourceGroup. L’exemple suivant permet de créer un groupe
de ressources nommé myResourceGroup :
Azure PowerShell

un réseau virtuel nommé myVirtualNetwork avec le préfixe d’adresse 10.0.0.0/16.
Azure PowerShell
-Location EastUS `
Créez une configuration de sous-réseau à l’aide de la commande New-

AzVirtualNetworkSubnetConfig. L’exemple suivant crée une configuration de sous-
réseau pour un sous-réseau nommé Public :
Azure PowerShell
$subnetConfigPublic = Add-AzVirtualNetworkSubnetConfig `
-Name Public `
Créez le sous-réseau dans le réseau virtuel en écrivant la configuration du sous-réseau

dans le réseau virtuel à l’aide de Set-AzVirtualNetwork :
Azure PowerShell

Vous ne pouvez activer des points de terminaison de service que pour les services qui
prennent en charge les points de terminaison de service. Affichez les services avec
points de terminaison qui se trouvent à un emplacement Azure donné avec Get-
AzVirtualNetworkAvailableEndpointService. L’exemple suivant retourne la liste des
services de la région eastus pour lesquels les points de terminaison de service ont été
activés. La liste des services retournés augmente avec chaque nouvelle activation des
points de terminaison de service.
Azure PowerShell
Get-AzVirtualNetworkAvailableEndpointService -Location eastus | Select Name
Créez un autre sous-réseau dans le réseau virtuel. Dans cet exemple, un sous-réseau
nommé Private est créé avec un point de terminaison de service Microsoft.Storage :
Azure PowerShell
-Name Private `
-ServiceEndpoint Microsoft.Storage

Créez des règles de sécurité de groupe de sécurité réseau avec New-
AzNetworkSecurityRuleConfig. La règle suivante autorise un accès sortant vers les
adresses IP publiques affectées au service Stockage Azure :
Azure PowerShell
$rule1 = New-AzNetworkSecurityRuleConfig `
-Name Allow-Storage-All `
-Access Allow `
-DestinationAddressPrefix Storage `
-DestinationPortRange * `
-Direction Outbound `
-Priority 100 `
-Protocol * `
-SourceAddressPrefix VirtualNetwork `
-SourcePortRange *
La règle suivante refuse l’accès à toutes les adresses IP publiques. La règle précédente
remplace cette règle, du fait de sa priorité plus élevée, ce qui permet d’accéder aux
adresses IP publiques du Stockage Azure.
Azure PowerShell
-Name Deny-Internet-All `
-Access Deny `
-DestinationAddressPrefix Internet `
-Priority 110 `
-Protocol * `
-SourcePortRange *
La règle suivante autorise le trafic du protocole RDP (Remote Desktop Protocol) entrant
dans le sous-réseau à partir de n’importe quel endroit. Les connexions Bureau à distance
sont autorisées dans le sous-réseau, afin que vous puissiez vérifier l’accès réseau à une
ressource dans une étape ultérieure.
Azure PowerShell
-Name Allow-RDP-All `
-Access Allow `
-DestinationAddressPrefix VirtualNetwork `
-DestinationPortRange 3389 `
-Priority 120 `
-Protocol * `
-SourceAddressPrefix * `
-SourcePortRange *

suivant crée un groupe de sécurité réseau nommé myNsgPrivate.
Azure PowerShell
-Location EastUS `
-Name myNsgPrivate `
-SecurityRules $rule1,$rule2,$rule3
Associez le groupe de sécurité réseau au sous-réseau Private avec Set-

réseau virtuel. L’exemple suivant associe le groupe de sécurité réseau myNsgPrivate au
sous-réseau Private :
Azure PowerShell
-VirtualNetwork $VirtualNetwork `
-Name Private `
-ServiceEndpoint Microsoft.Storage `

des services Azure avec activation des points de terminaison varient d’un service à
l’autre. Pour connaître les étapes à suivre, consultez la documentation relative à chacun
des services. La suite de cet article comprend des étapes permettant de restreindre
l’accès réseau pour un compte Stockage Azure.

Créez un compte de stockage Azure avec New-AzStorageAccount. Remplacez <replace-
with-your-unique-storage-account-name> par un nom qui n’existe dans aucun autre
emplacement Azure. Le nom doit comprendre entre 3 et 24 caractères, correspondant à

des chiffres et à des lettres en minuscules.
Azure PowerShell
$storageAcctName = '<replace-with-your-unique-storage-account-name>'
New-AzStorageAccount `
-Location EastUS `
-Name $storageAcctName `
-SkuName Standard_LRS `
-Kind StorageV2
Une fois le compte de stockage créé, récupérez la clé du compte de stockage dans une
variable avec Get-AzStorageAccountKey :
Azure PowerShell
$storageAcctKey = (Get-AzStorageAccountKey `
-AccountName $storageAcctName).Value[0]
La clé sera utilisée pour créer un partage de fichiers lors d’une prochaine étape. Entrez
$storageAcctKey et notez la valeur, car vous devez également l’entrer dans une étape
ultérieure lorsque vous mapperez le partage de fichiers à un lecteur d’une machine
virtuelle.

Créez un contexte pour votre compte de stockage et votre clé avec New-
AzStorageContext. Celui-ci encapsule le nom et la clé du compte de stockage :
Azure PowerShell
$storageContext = New-AzStorageContext $storageAcctName $storageAcctKey
Créez un partage de fichiers avec New-AzStorageShare :
$share = New-AzStorageShare my-file-share -Context $storageContext
Refuser tout accès réseau au compte de stockage

clients de n’importe quel réseau. Pour limiter l’accès aux réseaux sélectionnés, définissez
l’action par défaut sur Refuser avec Update-AzStorageAccountNetworkRuleSet. Une fois
l’accès réseau refusé, le compte de stockage n’est plus accessible par aucun des réseaux.
Azure PowerShell
Update-AzStorageAccountNetworkRuleSet `
-ResourceGroupName "myresourcegroup" `
-DefaultAction Deny
Activer l’accès réseau à partir d’un sous-réseau

Récupérez le réseau virtuel créé avec Get-AzVirtualNetwork, puis récupérez l’objet de
sous-réseau privé dans une variable avec Get-AzVirtualNetworkSubnetConfig :
Azure PowerShell
$privateSubnet = Get-AzVirtualNetwork `
-Name "myVirtualNetwork" `
| Get-AzVirtualNetworkSubnetConfig `
-Name "Private"
Autorisez l’accès réseau au compte de stockage à partir du sous-réseau Private avec

Add-AzStorageAccountNetworkRule.
Azure PowerShell
Add-AzStorageAccountNetworkRule `
-ResourceGroupName "myresourcegroup" `
-VirtualNetworkResourceId $privateSubnet.Id

Créez une machine virtuelle dans le sous-réseau Public avec New-AzVM. Lors de
l’exécution de la commande qui suit, vous êtes invité à saisir vos informations
d’identification. Les valeurs que vous saisissez sont configurées comme le nom
d’utilisateur et le mot de passe pour la machine virtuelle. L’option -AsJob crée la
machine virtuelle en arrière-plan. Vous pouvez donc passer à l’étape suivante.
Azure PowerShell
New-AzVm `
-SubnetName "Public" `
-Name "myVmPublic" `
-AsJob
Une sortie similaire à la sortie suivante est renvoyée :
PowerShell

Location Command
-- ---- ------------- ----- ----------- -------
- -------
localhost New-AzVM

Créez une machine virtuelle dans le sous-réseau Private :
Azure PowerShell
New-AzVm `
-SubnetName "Private" `
-Name "myVmPrivate"
La création de la machine virtuelle par Azure ne nécessite que quelques minutes. Ne

passez pas à l’étape suivante tant qu’Azure n’a pas terminé la création de la machine
virtuelle et retourné de sortie à PowerShell.

myVmPrivate :
Azure PowerShell
-Name myVmPrivate `
| Select IpAddress
Remplacez <publicIpAddress> dans la commande suivante par l’adresse IP publique

adresse retournée à partir de la commande précédente, puis entrez la commande
suivante :
PowerShell
Un fichier .rdp (Remote Desktop Protocol) est créé et téléchargé sur votre ordinateur.
Ouvrez le fichier .rdp téléchargé. Si vous y êtes invité, sélectionnez Connexion. Entrez le
nom d’utilisateur et le mot de passe spécifiés lors de la création de la machine virtuelle.
Vous devrez peut-être sélectionner Plus de choix, puis Utiliser un autre compte, pour
spécifier les informations d’identification que vous avez entrées lorsque vous avez créé
la machine virtuelle. Sélectionnez OK. Un avertissement de certificat peut s’afficher
pendant le processus de connexion. Si vous recevez l’avertissement, sélectionnez Oui ou
Sur la machine virtuelle myVmPrivate, mappez le partage de fichiers Azure au lecteur Z à

l’aide de PowerShell. Avant d’exécuter les commandes qui suivent, remplacez <storage-
account-key> et <storage-account-name> par les valeurs que vous avez fournies ou
récupérées dans Créer un compte de stockage.
PowerShell

AsPlainText -Force
PowerShell

---- --------- --------- -------- ----
Z FileSystem
\\vnt.file.core.windows.net\my-f...
Vérifiez que la machine virtuelle ne dispose d’aucune connexion sortante à d’autres

adresses IP publiques :
PowerShell
ping bing.com
Vous ne recevez aucune réponse, car le groupe de sécurité réseau associé au sous-
réseau Private n’autorise pas l’accès sortant aux adresses IP publiques autres que les
adresses affectées au service Stockage Azure.

refusé
Obtenir l’adresse IP publique de la machine virtuelle myVmPublic :
Azure PowerShell
-Name myVmPublic `
| Select IpAddress
suivante :
PowerShell
Sur la machine virtuelle myVmPublic, essayez de mapper le partage de fichiers Azure au

lecteur Z. Avant d’exécuter les commandes qui suivent, remplacez <storage-account-
key> et <storage-account-name> par les valeurs que vous avez fournies ou récupérées
dans Créer un compte de stockage.
PowerShell

AsPlainText -Force
L’accès au partage est refusé et vous recevez une erreur New-PSDrive : Access is
denied . L’accès est refusé car la machine virtuelle myVmPublic est déployée sur le sous-
réseau Public. Le sous-réseau Public ne dispose pas d’un point de terminaison de service
activé pour Stockage Azure, et le compte de stockage autorise uniquement l’accès
réseau à partir du sous-réseau Private et non à partir du sous-réseau Public.
Fermez les sessions Bureau à distance sur la machine virtuelle myVmPublic.
Sur votre ordinateur, essayez d’afficher les partages de fichier du compte de stockage
avec la commande suivante :
PowerShell
Get-AzStorageFile `
-ShareName my-file-share `
-Context $storageContext
L’accès est refusé, et vous recevez une erreur indiquant Get-AzStorageFile : Le serveur
distant a retourné une erreur : (403) Interdit. Code d’état HTTP : 403 - Message d’erreur
HTTP : Cette requête n’est pas autorisée à effectuer cette opération, car votre ordinateur
ne se trouve pas dans le sous-réseau Private du réseau virtuel MyVirtualNetwork.
contient :
Azure PowerShell
Étapes suivantes
Dans cet article, vous avez activé un point de terminaison de service pour un sous-
être activés pour les ressources déployées à l’aide de différents services Azure. Vous
Si votre compte comporte plusieurs réseaux virtuels, vous pouvez relier deux réseaux
virtuels pour que les ressources de chaque réseau virtuel puissent communiquer entre
elles. Pour connaître la marche à suivre, consultez Connecter des réseaux virtuels.
Restreindre l’accès réseau aux
en utilisant Azure CLI
Article • 01/06/2023

toujours sur le serveur principal de Microsoft Azure. Dans cet article, vous apprendrez
comment :
Créer un réseau virtuel avec un sous-réseau

Ajouter un sous-réseau et activer un point de terminaison de service
Créer une ressource Azure et autoriser l’accès réseau à cette ressource uniquement
Déployer une machine virtuelle sur chaque sous-réseau
Vérifier l’accès à une ressource à partir d’un sous-réseau
Vérifier que l’accès à une ressource est refusé à partir d’un sous-réseau et
d’Internet
commencer.
Prérequis



upgrade.

Azure CLI
az group create \
--location eastus
Créez un réseau virtuel avec un sous-réseau en utilisant la commande az network vnet

create.
Azure CLI

--subnet-name Public \
Vous ne pouvez activer des points de terminaison de service que pour les services qui
prennent en charge les points de terminaison de service. Si vous souhaitez voir les
services d’un emplacement Azure donné pour lesquels les points de terminaison de
service ont été activés, utilisez az network vnet list-endpoint-services. L’exemple suivant
retourne la liste des services de la région eastus pour lesquels les points de terminaison
de service ont été activés. La liste des services retournés augmente avec chaque
nouvelle activation des points de terminaison de service.
Azure CLI
az network vnet list-endpoint-services \

--location eastus \
--out table
Créez un sous-réseau supplémentaire dans le réseau virtuel avec az network vnet subnet
create. Dans cet exemple, un point de terminaison Microsoft.Storage est créé pour le
sous-réseau :
Azure CLI

--name Private \
--service-endpoints Microsoft.Storage

Azure CLI

--name myNsgPrivate
Pour associer le groupe de sécurité réseau au sous-réseau Private, utilisez az network

vnet subnet update. L’exemple suivant associe le groupe de sécurité réseau
myNsgPrivate au sous-réseau Private :
Azure CLI

--name Private \
--network-security-group myNsgPrivate
Créez des règles de sécurité avec az network nsg rule create. La règle qui suit autorise
un accès sortant vers les adresses IP publiques affectées au service Stockage Azure :
Azure CLI

--nsg-name myNsgPrivate \
--name Allow-Storage-All \
--access Allow \
--protocol "*" \
--direction Outbound \
--priority 100 \
--source-address-prefix "VirtualNetwork" \
--destination-address-prefix "Storage" \
--destination-port-range "*"
Chaque groupe de sécurité réseau contient plusieurs règles de sécurité par défaut. La
règle qui suit remplace une règle de sécurité par défaut, qui autorise l’accès de trafic
sortant à toutes les adresses IP publiques. L’option destination-address-prefix
"Internet" refuse l’accès sortant à toutes les adresses IP publiques. La règle précédente
Azure CLI

--name Deny-Internet-All \
--access Deny \
--protocol "*" \
--priority 110 \
--destination-address-prefix "Internet" \
La règle suivante autorise le trafic SSH entrant vers le sous-réseau à partir de n’importe
quel endroit. La règle remplace une règle de sécurité par défaut qui refuse tout le trafic
entrant provenant d’Internet. Le SSH est autorisé sur le sous-réseau afin que la
connectivité puisse être testée dans une étape ultérieure.
Azure CLI

--access Allow \
--protocol Tcp \
--priority 120 \
--source-address-prefix "*" \
--destination-address-prefix "VirtualNetwork" \
--destination-port-range "22"


Créez un compte de stockage Azure avec la commande az storage account create.
Remplacez <replace-with-your-unique-storage-account-name> par un nom qui n’existe
dans aucun autre emplacement Azure. Le nom doit comprendre entre 3 et 24 caractères,
correspondant à des chiffres et à des lettres en minuscules.
Azure CLI
storageAcctName="<replace-with-your-unique-storage-account-name>"
az storage account create \

--name $storageAcctName \
--sku Standard_LRS \
--kind StorageV2
Une fois le compte de stockage créé, récupérez la chaîne de connexion du compte de
stockage dans une variable avec az storage account show-connection-string. La chaîne
de connexion sera utilisée pour créer un partage de fichiers lors d’une prochaine étape.
Azure CLI
saConnectionString=$(az storage account show-connection-string \

--query 'connectionString' \
--out tsv)
Affichez le contenu de la variable et notez la valeur de AccountKey qui est retournée

dans la sortie, car vous devrez l’utiliser dans une prochaine étape.
Azure CLI
echo $saConnectionString

Créez un partage de fichiers dans le compte de stockage avec az storage share create.
Dans une étape ultérieure, ce partage de fichiers sera monté pour vérifier qu’il est
possible d’y accéder via le réseau.
Azure CLI
az storage share create \

--name my-file-share \
--quota 2048 \
--connection-string $saConnectionString > /dev/null

l’action par défaut sur Refuser avec az storage account update. Une fois l’accès réseau
refusé, le compte de stockage n’est plus accessible par aucun des réseaux.
Azure CLI
az storage account update \

--default-action Deny
Activer l’accès réseau à partir d’un sous-réseau

Autorisez l’accès réseau au compte de stockage à partir du sous-réseau Private avec az
storage account network-rule add.
Azure CLI
az storage account network-rule add \

--account-name $storageAcctName \
--subnet Private


Créez une machine virtuelle dans le sous-réseau Public avec az vm create. Si des clés
Pour utiliser un ensemble spécifique de clés, utilisez l’option --ssh-key-value .
Azure CLI
az vm create \
--name myVmPublic \
--image UbuntuLTS \
--subnet Public \
--generate-ssh-keys

Azure CLI
{
"fqdns": "",
ualMachines/myVmPublic",
"macAddress": "00-0D-3A-23-9A-49",
}
Prenez note de la valeur de publicIpAddress dans la sortie retournée. Cette adresse sera
utilisée pour accéder à la machine virtuelle à partir d’Internet dans une prochaine étape.

Azure CLI
az vm create \
--image UbuntuLTS \
--subnet Private \
--generate-ssh-keys

machine virtuelle créée, prenez note de la valeur de publicIpAddress dans la sortie
retournée. Cette adresse sera utilisée pour accéder à la machine virtuelle à partir
d’Internet dans une prochaine étape.

Ouvrez une session SSH avec la machine virtuelle myVmPrivate. Remplacez
<publicIpAddress> par l’adresse IP publique de votre machine virtuelle myVmPrivate.
Bash
Créez un dossier comme point de montage :

Bash
sudo mkdir /mnt/MyAzureFileShare
Montez le partage de fichiers Azure dans le répertoire que vous avez créé. Avant
d’exécuter la commande suivante, remplacez <storage-account-name> par le nom du
compte et <storage-account-key> par la clé que vous avez récupérée dans Créer un
compte de stockage.
Bash
sudo mount --types cifs //<storage-account-name>.file.core.windows.net/my-

file-share /mnt/MyAzureFileShare --options vers=3.0,username=<storage-
account-name>,password=<storage-account-
key>,dir_mode=0777,file_mode=0777,serverino
Vous recevez l’invite user@myVmPrivate:~$ . Le partage de fichiers Azure est monté sur
/mnt/MyAzureFileShare.
Vérifiez que la machine virtuelle ne dispose d’aucune connexion sortante à d’autres

adresses IP publiques :
Bash
ping bing.com -c 4
Vous ne recevez aucune réponse, car le groupe de sécurité réseau associé au sous-
réseau Private n’autorise pas l’accès sortant aux adresses IP publiques autres que les
adresses affectées au service Stockage Azure.
Fermez la session SSH sur la machine virtuelle myVmPrivate.

refusé
myVmPublic. Remplacez <publicIpAddress> par l’adresse IP publique de votre machine
virtuelle myVmPublic :
Bash
Créez un répertoire comme point de montage :
Bash
sudo mkdir /mnt/MyAzureFileShare
Essayez de monter le partage de fichiers Azure dans le répertoire que vous avez créé.
Cet article suppose que vous ayez déployé la dernière version d’Ubuntu. Si vous utilisez
une version antérieure d’Ubuntu, consultez Montage sur Linux pour en savoir plus sur le
montage des partages de fichiers. Avant d’exécuter la commande suivante, remplacez
<storage-account-name> par le nom du compte et <storage-account-key> par la clé que
vous avez récupérée dans Créer un compte de stockage :
Bash
sudo mount --types cifs //storage-account-name>.file.core.windows.net/my-

file-share /mnt/MyAzureFileShare --options vers=3.0,username=<storage-
account-name>,password=<storage-account-
L’accès est refusé et vous recevez une erreur mount error(13): Permission denied , car la
machine virtuelle myVmPublic est déployée sur le sous-réseau Public. Le sous-réseau
Public ne dispose pas d’un point de terminaison de service activé pour Stockage Azure,
et le compte de stockage autorise uniquement l’accès réseau à partir du sous-réseau
Private et non à partir du sous-réseau Public.
Fermez la session SSH sur la machine virtuelle myVmPublic.
Sur votre ordinateur, essayez d’afficher les partages de votre compte de stockage avec
az storage share list. Remplacez <account-name> et <account-key> par le nom de compte
de stockage et la clé utilisés dans la section Créer un compte de stockage :
Azure CLI
az storage share list \

--account-name <account-name> \
--account-key <account-key>
L’accès est refusé et vous recevez une erreur indiquant que la requête n’est pas autorisée
à effectuer cette opération, car votre ordinateur ne fait pas partie du sous-réseau Private

Azure CLI
Étapes suivantes
Dans cet article, vous avez activé un point de terminaison de service pour un sous-
être activés pour les ressources déployées à l’aide de différents services Azure. Vous
Si votre compte comporte plusieurs réseaux virtuels, vous pouvez relier deux réseaux
virtuels pour que les ressources de chaque réseau virtuel puissent communiquer entre
elles. Pour connaître la marche à suivre, consultez Connecter des réseaux virtuels.
Créer, changer ou supprimer une
stratégie de point de terminaison de
service à l’aide du portail Azure
Article • 01/06/2023
Les stratégies de point de terminaison de service vous permettent de filtrer le trafic de

réseau virtuel sur des ressources Azure spécifiques sur des points de terminaison de
service. Si vous n’êtes pas familiarisé avec les stratégies de point de terminaison de
service, consultez la vue d’ensemble des stratégies de point de terminaison de service
pour en savoir plus.
＂ Créer une stratégie de point de terminaison de service

＂ Créer une définition de stratégie de point de terminaison de service
＂ Associer une stratégie de point de terminaison de service à un sous-réseau

commencer.
Connexion à Azure
Connectez-vous au portail Azure sur https://portal.azure.com .
Créer une stratégie de point de terminaison de

service
2. Dans le volet de recherche, tapez « stratégie de point de terminaison de service »,
sélectionnez Stratégie de point de terminaison de service, puis Créer.
3. Entrez ou sélectionnez les informations suivantes dans Informations de base :
Abonnement : sélectionnez votre abonnement pour la stratégie.

Groupe de ressources : Sélectionnez Créer et entrez myResourceGroup.
Nom : myEndpointPolicy
Emplacement : USA Centre
4. Sélectionnez + Ajouter sous Ressources, puis entrez ou sélectionnez les

informations suivantes dans le volet Ajouter une ressource
Service : seul Microsoft.Storage est disponible avec les stratégies de points
de terminaison de service.
Étendue : vous avez le choix entre Compte unique, Tous les comptes de
l’abonnement ou Tous les comptes du groupe de ressources.
Abonnement : sélectionnez votre abonnement pour le compte de stockage.
La stratégie et les comptes de stockage peuvent se trouver dans des
Groupe de ressources : Sélectionnez votre groupe de ressources. Obligatoire
si l’étendue est définie avec la valeur « Tous les comptes du groupe de
ressources » ou « Compte unique ».
Ressource : sélectionnez votre ressource de stockage Azure sous
l’abonnement ou le groupe de ressources sélectionné.
Cliquez sur le bouton Ajouter en bas pour terminer l’ajout de la ressource
Ajoutez des ressources supplémentaires en répétant les étapes ci-dessus en

fonction des besoins
5. Facultatif : Entrez ou sélectionnez les informations suivantes dans Étiquettes :
Clé : sélectionnez votre clé pour la stratégie. Exemple : Département

Valeur : entrez la paire de valeurs pour la clé. Exemple : Finances
6. Sélectionnez Vérifier + créer. Validez les informations, puis cliquez sur Créer. Pour
apporter d’autres modifications, cliquez sur Précédent.
Afficher des stratégies de points de
terminaison
1. Dans la zone Tous les services du portail, commencez à taper stratégies de point de
terminaison de service. Sélectionnez Stratégies de points de terminaison de
service.
2. Sous Abonnements, sélectionnez votre abonnement et votre groupe de

ressources, comme illustré dans l’image suivante.
3. Sélectionnez la stratégie, puis cliquez sur Définitions de stratégie pour afficher ou

ajouter des définitions de stratégie supplémentaires.
4. Sélectionnez Sous-réseaux associés pour afficher les sous-réseaux auxquels la
stratégie est associée. Si aucun sous-réseau n’est encore associé, suivez les
instructions de l’étape suivante.
5. Associer une stratégie à un sous-réseau
２ Avertissement
Vérifiez que toutes les ressources ayant fait l’objet d’un accès à partir du sous-
réseau sont ajoutées à la définition de stratégie avant d’associer la stratégie au
sous-réseau indiqué. Une fois que la stratégie est associée, seul l’accès aux
ressources de la liste verte sera autorisé sur les points de terminaison de service.
Vérifiez également qu’il n’existe aucun service Azure managé dans le sous-réseau
associé à la stratégie de point de terminaison de service
Avant de pouvoir associer une stratégie à un sous-réseau, vous devez créer un
réseau virtuel et un sous-réseau. Pour obtenir de l’aide, reportez-vous à l’article
Créer un réseau virtuel.
Une fois que vous avez configuré le réseau virtuel et le sous-réseau, vous devez
configurer des points de terminaison de service de réseau virtuel pour le stockage
Azure. Dans le panneau Réseau virtuel, sélectionnez Points de terminaison de
service puis, dans le volet suivant, sélectionnez Microsoft.Storage et le réseau
virtuel ou le sous-réseau souhaité sous Sous-réseaux
À présent, vous pouvez choisir de sélectionner la stratégie de point de terminaison

de service dans la liste déroulante du volet ci-dessus si vous avez déjà créé des
stratégies de points de terminaison de service avant de configurer le point de
terminaison de service pour le sous-réseau, comme indiqué ci-dessous
OU, si vous associez des stratégies de points de terminaison de service après avoir
déjà configuré des points de terminaison de service, vous pouvez choisir d’associer
le sous-réseau à partir du panneau Stratégie de point de terminaison de service en
accédant au volet Sous-réseaux associés, comme indiqué ci-dessous
２ Avertissement
L’accès aux ressources de stockage Azure dans toutes les régions est limité en
fonction de la stratégie de point de terminaison de service de ce sous-réseau.
Étapes suivantes
Dans ce tutoriel, vous avez créé une stratégie de point de terminaison de service que
vous avez associée à un sous-réseau. Pour en savoir plus sur les stratégies de point de
terminaison de service, consultez la vue d’ensemble des stratégies de point de
Gérer l’exfiltration de données vers des
comptes de stockage Azure avec des
stratégies de point de terminaison de
service de réseau virtuel à l’aide d’Azure
PowerShell
Article • 11/05/2023
Les stratégies de points de terminaison de service de réseau virtuel vous permettent

d’appliquer un contrôle d’accès sur des comptes Stockage Azure depuis un réseau
virtuel sur des points de terminaison de service. Il s’agit d’une stratégie clé pour
sécuriser vos charges de travail, gérer les comptes de stockage autorisés et gérer les
destinations d’exfiltration de données autorisées. Dans cet article, vous apprendrez
comment :
Créez un réseau virtuel.

Ajouter un sous-réseau et activer un point de terminaison de service pour le
stockage Azure
Créer deux comptes de stockage Azure et autoriser l’accès réseau à ces derniers à
partir du sous-réseau précédemment créé.
Créer une stratégie de point de terminaison de service pour autoriser l’accès à l’un
des comptes de stockage uniquement.
Déployer une machine virtuelle sur le sous-réseau.
Vérifier l’accès au compte de stockage autorisé à partir du sous-réseau.
Vérifier que l’accès au compte de stockage non autorisé à partir du sous-réseau est
refusé.
７ Notes


commencer.
Azure Cloud Shell
Option Exemple/Lien







ressources avec New-AzResourceGroup. L’exemple suivant permet de créer un groupe
de ressources nommé myResourceGroup :
Azure PowerShell
New-AzResourceGroup `
-Location EastUS

un réseau virtuel nommé myVirtualNetwork avec le préfixe d’adresse 10.0.0.0/16.
Azure PowerShell
-Location EastUS `

Créez un sous-réseau dans le réseau virtuel. Dans cet exemple, un sous-réseau nommé
Private est créé avec un point de terminaison de service Microsoft.Storage :
Azure PowerShell
-Name Private `
-ServiceEndpoint Microsoft.Storage
Restreindre l’accès réseau pour le sous-réseau

Créez des règles de sécurité de groupe de sécurité réseau avec New-
AzNetworkSecurityRuleConfig. La règle suivante autorise un accès sortant vers les
adresses IP publiques affectées au service Stockage Azure :
Azure PowerShell
-Name Allow-Storage-All `
-Access Allow `
-DestinationAddressPrefix Storage `
-Priority 100 -Protocol * `
-SourcePortRange *
La règle suivante refuse l’accès à toutes les adresses IP publiques. La règle précédente
Azure PowerShell
-Name Deny-Internet-All `
-Access Deny `
-DestinationAddressPrefix Internet `
-Priority 110 -Protocol * `
-SourcePortRange *
La règle suivante autorise le trafic du protocole RDP (Remote Desktop Protocol) entrant
dans le sous-réseau à partir de n’importe quel endroit. Les connexions Bureau à distance
sont autorisées dans le sous-réseau, afin que vous puissiez vérifier l’accès réseau à une
ressource dans une étape ultérieure.
Azure PowerShell
-Name Allow-RDP-All `
-Access Allow `
-DestinationAddressPrefix VirtualNetwork `
-DestinationPortRange 3389 `
-Priority 120 `
-Protocol * `
-SourcePortRange *

Azure PowerShell
-Location EastUS `
-Name myNsgPrivate `
-SecurityRules $rule1,$rule2,$rule3
Associez le groupe de sécurité réseau au sous-réseau Private avec Set-

réseau virtuel. L’exemple suivant associe le groupe de sécurité réseau myNsgPrivate au
sous-réseau Private :
Azure PowerShell
-VirtualNetwork $VirtualNetwork `
-Name Private `
Restreindre l’accès réseau aux comptes

Stockage Azure
Créer deux comptes de stockage

Créez un compte de stockage Azure avec New-AzStorageAccount.
Azure PowerShell
$storageAcctName1 = 'allowedaccount'
-Location EastUS `
-Name $storageAcctName1 `
-Kind StorageV2
Une fois le compte de stockage créé, récupérez la clé du compte de stockage dans une
variable avec Get-AzStorageAccountKey :
Azure PowerShell
$storageAcctKey1 = (Get-AzStorageAccountKey -ResourceGroupName

myResourceGroup -AccountName $storageAcctName1).Value[0]
La clé sera utilisée pour créer un partage de fichiers lors d’une prochaine étape. Entrez
$storageAcctKey et notez la valeur, car vous devez également l’entrer dans une étape
ultérieure lorsque vous mapperez le partage de fichiers à un lecteur d’une machine
virtuelle.
À présent, répétez les étapes ci-dessus pour créer un deuxième compte de stockage.
Azure PowerShell
$storageAcctName2 = 'notallowedaccount'
-Location EastUS `
-Kind StorageV2
Vous devez également récupérer la clé de compte de stockage à partir de ce compte.

Vous l’utiliserez ultérieurement pour créer un partage de fichiers.
Azure PowerShell
$storageAcctKey2 = (Get-AzStorageAccountKey -ResourceGroupName

myResourceGroup -AccountName $storageAcctName2).Value[0]
Créer un partage de fichiers dans chaque compte de

stockage
Créez un contexte pour votre compte de stockage et votre clé avec New-
AzStorageContext. Celui-ci encapsule le nom et la clé du compte de stockage :
Azure PowerShell
$storageContext1 = New-AzStorageContext $storageAcctName1 $storageAcctKey1
$storageContext2 = New-AzStorageContext $storageAcctName2 $storageAcctKey2
Créez un partage de fichiers avec New-AzStorageShare :
Azure PowerShell
$share1 = New-AzStorageShare my-file-share -Context $storageContext1
$share2 = New-AzStorageShare my-file-share -Context $storageContext2
Refuser tout accès réseau aux comptes de stockage

l’action par défaut sur Refuser avec Update-AzStorageAccountNetworkRuleSet. Une fois
l’accès réseau refusé, le compte de stockage n’est plus accessible par aucun des réseaux.
Azure PowerShell
-ResourceGroupName myresourcegroup `
-DefaultAction Deny
-DefaultAction Deny
Autoriser l’accès réseau uniquement à partir du sous-

réseau de réseau virtuel
Récupérez le réseau virtuel créé avec Get-AzVirtualNetwork, puis récupérez l’objet de
sous-réseau privé dans une variable avec Get-AzVirtualNetworkSubnetConfig :
Azure PowerShell
$privateSubnet = Get-AzVirtualNetwork `
| Get-AzVirtualNetworkSubnetConfig -Name Private
Autorisez l’accès réseau au compte de stockage à partir du sous-réseau Private avec
Add-AzStorageAccountNetworkRule.
Azure PowerShell
Appliquer la stratégie pour autoriser l’accès au

compte de stockage valide
Pour vous assurer que les utilisateurs du réseau virtuel peuvent accéder uniquement aux
comptes de stockage Azure sécurisés et autorisés, vous pouvez créer une stratégie de
point de terminaison de service avec la liste des comptes de stockage autorisés dans la
définition. Cette stratégie est ensuite appliquée au sous-réseau de réseau virtuel
connecté au stockage par le biais de points de terminaison de service.
Créer une stratégie de point de terminaison de service

Dans le cadre de cette section, vous allez créer la définition de stratégie avec la liste des
ressources dont l’accès est autorisé sur le point de terminaison de service.
Récupérer l’ID de ressource pour le premier compte de stockage (autorisé)
Azure PowerShell
$resourceId = (Get-AzStorageAccount -ResourceGroupName myresourcegroup -Name

$storageAcctName1).id
Créer la définition de stratégie pour autoriser la ressource ci-dessus
Azure PowerShell
$policyDefinition = New-AzServiceEndpointPolicyDefinition -Name

mypolicydefinition `
-Description "Service Endpoint Policy Definition" `
-Service "Microsoft.Storage" `
-ServiceResource $resourceId
Créer la stratégie de point de terminaison de service à l’aide de la définition de stratégie

créée ci-dessus
Azure PowerShell
$sepolicy = New-AzServiceEndpointPolicy -ResourceGroupName myresourcegroup `

-Name mysepolicy -Location EastUS
-ServiceEndpointPolicyDefinition $policyDefinition
Associer la stratégie de point de terminaison de service

au sous-réseau de réseau virtuel
Après avoir créé la stratégie de point de terminaison de service, vous devez l’associer au
sous-réseau cible avec la configuration de point de terminaison de service pour le
stockage Azure.
Azure PowerShell
Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $VirtualNetwork `

-Name Private `
-NetworkSecurityGroup $nsg `
-ServiceEndpointPolicy $sepolicy
Vérifier la restriction d’accès aux comptes de

stockage Azure
Déployer la machine virtuelle

le sous-réseau.
Créez une machine virtuelle dans le sous-réseau Privé avec New-AzVM. Lors de
l’exécution de la commande qui suit, vous êtes invité à saisir vos informations
d’identification. Les valeurs que vous saisissez sont configurées comme le nom
d’utilisateur et le mot de passe pour la machine virtuelle. L’option -AsJob crée la
machine virtuelle en arrière-plan. Vous pouvez donc passer à l’étape suivante.
Azure PowerShell
New-AzVm -ResourceGroupName myresourcegroup `

-VirtualNetworkName myVirtualNetwork `
-SubnetName Private `
-Name "myVMPrivate" -AsJob
Une sortie similaire à la sortie suivante est renvoyée :
PowerShell

Location Command
-- ---- ------------- ----- ----------- -------
- -------
localhost New-AzVM
Vérifier l’accès au compte de stockage autorisé

myVmPrivate :
Azure PowerShell
-Name myVmPrivate `
| Select IpAddress

suivante :
PowerShell
Un fichier .rdp (Remote Desktop Protocol) est créé et téléchargé sur votre ordinateur.
Ouvrez le fichier .rdp téléchargé. Si vous y êtes invité, sélectionnez Connexion. Entrez le
nom d’utilisateur et le mot de passe spécifiés lors de la création de la machine virtuelle.
Vous devrez peut-être sélectionner Plus de choix, puis Utiliser un autre compte, pour
spécifier les informations d’identification que vous avez entrées lorsque vous avez créé
la machine virtuelle. Sélectionnez OK. Un avertissement de certificat peut s’afficher
pendant le processus de connexion. Si vous recevez l’avertissement, sélectionnez Oui ou
Sur la machine virtuelle myVmPrivate, mappez le partage de fichiers Azure du compte

de stockage autorisé au lecteur Z à l’aide de PowerShell.
PowerShell
$acctKey = ConvertTo-SecureString -String $storageAcctKey1 -AsPlainText -

Force
ArgumentList ("Azure\allowedaccount"), $acctKey
New-PSDrive -Name Z -PSProvider FileSystem -Root
"\\allowedaccount.file.core.windows.net\my-file-share" -Credential
$credential
PowerShell

---- --------- --------- -------- ----
Z FileSystem
\\allowedaccount.file.core.windows.net\my-f...
Vérifier que l’accès au compte de stockage non autorisé

est refusé
Toujours sur la machine virtuelle myVmPrivate, essayez de mapper le partage de fichiers
Azure au lecteur X.
PowerShell
$acctKey = ConvertTo-SecureString -String $storageAcctKey1 -AsPlainText -

Force
ArgumentList "Azure\notallowedaccount", $acctKey
New-PSDrive -Name X -PSProvider FileSystem -Root
"\\notallowedaccount.file.core.windows.net\my-file-share" -Credential
$credential
L’accès au partage est refusé et vous recevez une erreur New-PSDrive : Access is
denied . L’accès est refusé, car le compte de stockage notallowedaccount ne figure pas
dans la liste des ressources autorisées de la stratégie de point de terminaison de service.
Fermez les sessions Bureau à distance sur la machine virtuelle myVmPublic.

contient :
Azure PowerShell
Étapes suivantes
Dans le cadre de cet article, vous avez appliqué une stratégie de point de terminaison
de service sur un point de terminaison de service de réseau virtuel Azure au stockage
Azure. Vous avez créé des comptes de stockage Azure et vous avez limité l’accès réseau
à certains comptes de stockage (et refusé l’accès à d’autres) à partir d’un sous-réseau de
réseau virtuel. Pour en savoir plus sur les stratégies de point de terminaison de service,
consultez Vue d’ensemble des stratégies de points de terminaison de service.
Gérer l’exfiltration de données vers des
comptes Stockage Azure avec des
stratégies de points de terminaison de
service de réseau virtuel à l’aide d’Azure
CLI
Les stratégies de points de terminaison de service de réseau virtuel vous permettent

d’appliquer un contrôle d’accès sur des comptes Stockage Azure depuis un réseau
virtuel sur des points de terminaison de service. Il s’agit d’une stratégie clé pour
sécuriser vos charges de travail, gérer les comptes de stockage autorisés et gérer les
destinations d’exfiltration de données autorisées. Dans cet article, vous apprendrez
comment :
Créer un réseau virtuel et ajouter un sous-réseau.

Activer un point de terminaison de service pour Stockage Azure.
Créer deux comptes de stockage Azure et autoriser l’accès réseau à ces derniers à
partir du sous-réseau précédemment créé.
Créer une stratégie de point de terminaison de service pour autoriser l’accès à l’un
des comptes de stockage uniquement.
Déployer une machine virtuelle sur le sous-réseau.
Vérifier l’accès au compte de stockage autorisé à partir du sous-réseau.
Vérifier que l’accès au compte de stockage non autorisé à partir du sous-réseau est
refusé.
commencer.
Prérequis



upgrade.

Azure CLI
az group create \
--location eastus
Créez un réseau virtuel avec un sous-réseau en utilisant la commande az network vnet

create.
Azure CLI

--subnet-name Private \
Dans cet exemple, un point de terminaison Microsoft.Storage est créé pour le sous-
réseau Private :
Azure CLI

--name Private \
--service-endpoints Microsoft.Storage

Azure CLI

--name myNsgPrivate
Pour associer le groupe de sécurité réseau au sous-réseau Private, utilisez az network

vnet subnet update. L’exemple suivant associe le groupe de sécurité réseau
myNsgPrivate au sous-réseau Private :
Azure CLI

--name Private \
--network-security-group myNsgPrivate
Créez des règles de sécurité avec az network nsg rule create. La règle qui suit autorise
un accès sortant vers les adresses IP publiques affectées au service Stockage Azure :
Azure CLI

--name Allow-Storage-All \
--access Allow \
--protocol "*" \
--priority 100 \
--destination-address-prefix "Storage" \
Chaque groupe de sécurité réseau contient plusieurs règles de sécurité par défaut. La
règle qui suit remplace une règle de sécurité par défaut, qui autorise l’accès de trafic
sortant à toutes les adresses IP publiques. L’option destination-address-prefix
"Internet" refuse l’accès sortant à toutes les adresses IP publiques. La règle précédente
Azure CLI

--name Deny-Internet-All \
--access Deny \
--protocol "*" \
--priority 110 \
--destination-address-prefix "Internet" \
La règle suivante autorise le trafic SSH entrant vers le sous-réseau à partir de n’importe
quel endroit. La règle remplace une règle de sécurité par défaut qui refuse tout le trafic
entrant provenant d’Internet. Le SSH est autorisé sur le sous-réseau afin que la
connectivité puisse être testée dans une étape ultérieure.
Azure CLI

--access Allow \
--protocol Tcp \
--priority 120 \
--source-address-prefix "*" \
--destination-address-prefix "VirtualNetwork" \
--destination-port-range "22"
Restreindre l’accès réseau aux comptes

Stockage Azure
Cette section répertorie les étapes permettant de limiter l’accès réseau pour un compte
Stockage Azure à partir du sous-réseau donné dans un réseau virtuel via un point de

Créez deux comptes Stockage Azure avec la commande az storage account create.
Azure CLI
storageAcctName1="allowedstorageacc"

--name $storageAcctName1 \
--kind StorageV2
storageAcctName2="notallowedstorageacc"

--kind StorageV2
Une fois les comptes de stockage créés, récupérez la chaîne de connexion des comptes
de stockage dans une variable avec az storage account show-connection-string. La
chaîne de connexion sera utilisée pour créer un partage de fichiers lors d’une prochaine
étape.
Azure CLI
saConnectionString1=$(az storage account show-connection-string \

--out tsv)
saConnectionString2=$(az storage account show-connection-string \

--out tsv)
Affichez le contenu de la variable et notez la valeur de AccountKey qui est retournée

dans la sortie, car vous devrez l’utiliser dans une prochaine étape.
Azure CLI
echo $saConnectionString1
echo $saConnectionString2

Créez un partage de fichiers dans le compte de stockage avec az storage share create.
Dans une étape ultérieure, ce partage de fichiers sera monté pour vérifier qu’il est
possible d’y accéder via le réseau.
Azure CLI

--quota 2048 \
--connection-string $saConnectionString1 > /dev/null

--quota 2048 \
--connection-string $saConnectionString2 > /dev/null

l’action par défaut sur Refuser avec az storage account update. Une fois l’accès réseau
refusé, le compte de stockage n’est plus accessible par aucun des réseaux.
Azure CLI

Activer l’accès réseau à partir du sous-réseau de réseau

virtuel
Autorisez l’accès réseau au compte de stockage à partir du sous-réseau Private avec az
storage account network-rule add.
Azure CLI

--account-name $storageAcctName1 \
--subnet Private

--account-name $storageAcctName2 \
--subnet Private
Appliquer la stratégie pour autoriser l’accès au

compte de stockage valide
Les stratégies de points de terminaison de service Azure sont uniquement disponibles
pour le Stockage Azure. Pour cet exemple de configuration, nous allons donc activer le
point de terminaison de service pour Microsoft.Storage sur ce sous-réseau.
Les stratégies de points de terminaison de service sont appliquées sur les points de
terminaison de service. Nous allons commencer par créer une stratégie de points de
terminaison de service. Après quoi, nous allons créer les définitions de stratégie dans le
cadre de cette stratégie pour les comptes Stockage Azure à approuver pour ce sous-
réseau.
Créer une stratégie de point de terminaison de service
Azure CLI
az network service-endpoint policy create \
--name mysepolicy \
--location eastus
Enregistrez l’URI de ressource pour le compte de stockage autorisé dans une variable.
Avant d’exécuter la commande ci-dessous, remplacez <your-subscription-id> par la
valeur réelle de votre ID d’abonnement.
Azure CLI
$serviceResourceId="/subscriptions/<your-subscription-
id>/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccoun
ts/allowedstorageacc"
Créer et ajouter une définition de stratégie pour autoriser le compte Stockage Azure ci-
dessus dans la stratégie de point de terminaison de service
Azure CLI
az network service-endpoint policy-definition create \

--policy-name mysepolicy \
--name mypolicydefinition \
--service "Microsoft.Storage" \
--service-resources $serviceResourceId
Mettre à jour le sous-réseau de réseau virtuel pour l’associer à la stratégie de points de

terminaison de service créée à l’étape précédente
Azure CLI

--name Private \
--service-endpoints Microsoft.Storage \
--service-endpoint-policy mysepolicy
Vérifier la restriction d’accès aux comptes de

stockage Azure
Créer la machine virtuelle

le sous-réseau.
Créez une machine virtuelle dans le sous-réseau Private avec az vm create. Si des clés
Pour utiliser un ensemble spécifique de clés, utilisez l’option --ssh-key-value .
Azure CLI
az vm create \
--image UbuntuLTS \
--subnet Private \
--generate-ssh-keys

machine virtuelle créée, prenez note de la valeur de publicIpAddress dans la sortie
retournée. Cette adresse sera utilisée pour accéder à la machine virtuelle à partir
d’Internet dans une prochaine étape.

Ouvrez une session SSH avec la machine virtuelle myVmPrivate. Remplacez
<publicIpAddress> par l’adresse IP publique de votre machine virtuelle myVmPrivate.
Bash
Créez un dossier comme point de montage :
Bash
sudo mkdir /mnt/MyAzureFileShare1
Montez le partage de fichiers Azure dans le répertoire que vous avez créé. Avant
d’exécuter la commande ci-dessous, remplacez <storage-account-key> par la valeur
AccountKey de $saConnectionString1.
Bash
sudo mount --types cifs //allowedstorageacc.file.core.windows.net/my-file-
share /mnt/MyAzureFileShare1 --options
vers=3.0,username=allowedstorageacc,password=<storage-account-
Vous recevez l’invite user@myVmPrivate:~$ . Le partage de fichiers Azure est monté sur
/mnt/MyAzureFileShare.
Vérifier que l’accès au compte de stockage est refusé

À partir de la même machine virtuelle myVmPrivate, créez un répertoire pour un point
de montage :
Bash
sudo mkdir /mnt/MyAzureFileShare2
Essayez de monter le partage de fichiers Azure à partir du compte de stockage

notallowedstorageacc dans le répertoire que vous avez créé. Cet article suppose que
vous ayez déployé la dernière version d’Ubuntu. Si vous utilisez une version antérieure
d’Ubuntu, consultez Montage sur Linux pour en savoir plus sur le montage des partages
de fichiers.
Avant d’exécuter la commande ci-dessous, remplacez <storage-account-key> par la

valeur AccountKey de $saConnectionString2.
Bash
sudo mount --types cifs //notallowedstorageacc.file.core.windows.net/my-

file-share /mnt/MyAzureFileShare2 --options
vers=3.0,username=notallowedstorageacc,password=<storage-account-
L’accès est refusé et vous recevez une erreur mount error(13): Permission denied , car
ce compte de stockage ne figure pas dans la liste verte de la stratégie de points de
terminaison de service que nous avons appliquée au sous-réseau.
Fermez la session SSH sur la machine virtuelle myVmPublic.

Azure CLI
Étapes suivantes
Dans le cadre de cet article, vous avez appliqué une stratégie de point de terminaison
de service sur un point de terminaison de service de réseau virtuel Azure au stockage
Azure. Vous avez créé des comptes de stockage Azure et vous avez limité l’accès réseau
à certains comptes de stockage (et refusé l’accès à d’autres) à partir d’un sous-réseau de
réseau virtuel. Pour en savoir plus sur les stratégies de point de terminaison de service,
consultez Vue d’ensemble des stratégies de points de terminaison de service.
 Documentation
Gérer les stratégies réseau pour les points de terminaison privés - Azure Private Link
Découvrez comment désactiver les stratégies réseau pour les points de terminaison privés.
az network firewall policy rule-collection-group collection
Configuration DNS des points de terminaison privés Azure

En savoir plus sur la configuration DNS des points de terminaison privés Azure.
Tutoriel : Créer une infrastructure DNS de point de terminaison privé avec Azure
Private Resolver pour une charge de travail locale - Azure Private Link
Découvrez comment déployer un point de terminaison privé avec un résolveur privé Azure pour une
charge de travail locale.
az network service-endpoint
Qu’est-ce qu’une sous-ressource de liaison de réseau virtuel dans les zones Azure
DNS privées ?
Vue d’ensemble d’une sous-ressource de liaison de réseau virtuel dans une zone Azure DNS privée
Qu’est-ce qu’une zone Azure DNS privée ?

Vue d’ensemble d’une zone DNS privée
az network firewall
Afficher 5 de plus
 Entrainement
Parcours d’apprentissage
AZ-104 : Implémenter et gérer le stockage dans Azure - Training
AZ-104 : Implémenter et gérer le stockage dans Azure
Certification
Démarrage rapide : Créer et configurer
Azure DDoS Network Protection à l’aide
du portail Azure
Article • 01/06/2023
Prise en main d’Azure DDoS Network Protection à l’aide du portail Azure.
Un plan de protection DDoS définit un ensemble de réseaux virtuels pour lesquels DDoS
Network Protection est activée entre différents abonnements. Vous pouvez configurer
un plan de protection DDoS pour votre organisation et lier des réseaux virtuels à partir
de plusieurs abonnements sous un même locataire Azure AD au même plan.
Dans ce démarrage rapide, vous allez créer un plan de protection DDoS et le lier à un
réseau virtuel.
Prérequis
commencer.
Connectez-vous au portail Azure sur https://portal.azure.com . Assurez-vous que
votre compte dispose du rôle de contributeur de réseau ou d’un rôle personnalisé
attribué aux actions appropriées répertoriées dans le guide pratique relatif aux
Autorisations.
Créer un plan de protection DDoS

1. Sélectionnez Créer une ressource en haut à gauche du portail Azure.
2. Recherchez le terme DDoS. Lorsque Plan de protection DDoS apparaît dans les
résultats de la recherche, sélectionnez cette entrée.
4. Entrez ou sélectionnez les valeurs suivantes.
Paramètre Valeur
Resource group Sélectionnez Créer et entrez MyResourceGroup.

Paramètre Valeur
Nom Entrez MyDdosProtectionPlan.
Région Entrez USA Est.
5. Sélectionnez Vérifier + créer, puis Créer
７ Notes
Bien que les ressources du plan de protection DDoS doivent être associées à une
région, les utilisateurs peuvent activer la protection DDoS sur des réseaux virtuels
dans différentes régions et sur plusieurs abonnements sous un seul locataire Azure
Active Directory.
Activer la protection DDoS pour un réseau

virtuel
Activer la protection DDoS pour un nouveau réseau

virtuel
1. Sélectionnez Créer une ressource en haut à gauche du portail Azure.
2. Sélectionnez Mise en réseau, puis Réseau virtuel.
3. Entrez ou sélectionnez les valeurs suivantes.
Paramètre Valeur
Resource group Sélectionnez Utiliser l’existant, puis MyResourceGroup.
Nom Entrez MyVnet.
Région Entrez USA Est.
4. Sélectionnez Suivant : Adresses IP et entrez les valeurs suivantes.
Paramètre Valeur
Espace Saisissez 10.1.0.0/16.

d’adressage IPv4
Paramètre Valeur
Nom du sous-réseau Sous le nom du sous-réseau, sélectionnez le lien Ajouter un sous-

réseau et entrez mySubnet.
Plage d’adresses de Entrez 10.1.0.0/24.

sous-réseau
7. Sélectionnez Activer sur la case d’option DDoS Network Protection.
8. Sélectionnez MyDdosProtectionPlan dans le volet Plan de protection DDoS. Le

plan que vous sélectionnez peut se trouver dans le même abonnement que le
réseau virtuel, ou dans un abonnement différent, mais les deux abonnements
doivent être associés au même locataire Azure Active Directory.
9. Sélectionnez Vérifier + créer, puis Créer.
７ Notes
Vous ne pouvez pas déplacer un réseau virtuel vers un autre groupe de ressources
ou abonnement quand la protection DDoS Standard est activée pour le réseau
virtuel. Si vous devez déplacer un réseau virtuel pour lequel la protection DDoS
Standard est activée, désactivez d’abord celle-ci, déplacez le réseau virtuel, puis
activez la protection DDoS Standard. Après le déplacement, les seuils de stratégie
réglée automatiquement pour toutes les adresses IP publiques protégées dans le
réseau virtuel sont réinitialisés.
Activer la protection DDoS pour un réseau virtuel existant

1. Créez un plan de protection DDoS en effectuant les étapes décrites dans Créer un
plan de protection DDoS, si vous n’avez pas de plan de protection DDoS.
2. Entrez le nom du réseau virtuel pour lequel vous souhaitez activer DDoS Network
Protection dans la zone Rechercher dans les ressources, les services et les
documents en haut du portail Azure. Quand le nom du réseau virtuel apparaît
dans les résultats de la recherche, sélectionnez-le.
3. Sélectionnez Protection DDoS, sous Paramètres.
4. Sélectionnez Activer. Sous Plan de protection DDoS, sélectionnez un plan de
protection DDoS existant, ou le plan que vous avez créé à l’étape 1, puis cliquez
sur Enregistrer. Le plan que vous sélectionnez peut se trouver dans le même
abonnement que le réseau virtuel, ou dans un abonnement différent, mais les deux
abonnements doivent être associés au même locataire Azure Active Directory.
Vous pouvez également activer le plan de protection DDoS pour un réseau virtuel
existant à partir du plan de protection DDoS, et non à partir du réseau virtuel.
1. Recherchez « Plans de protection DDoS » dans la zone Rechercher dans les

ressources, services et documents en haut du portail Azure. Quand Plans de
protection DDoS apparaît dans les résultats de la recherche, sélectionnez cette
entrée.
2. Sélectionnez le plan de protection DDoS que vous souhaitez activer pour votre
réseau virtuel.
3. Sélectionnez Ressources protégées sous Paramètres.
4. Cliquez sur +Ajouter et sélectionnez l’abonnement, le groupe de ressources et le
nom du réseau virtuel adéquats. Cliquez de nouveau sur Ajouter.
Configurer un plan de protection Azure DDoS à

l’aide d’Azure Firewall Manager (préversion)
Azure Firewall Manager est une plateforme qui permet de gérer et de protéger vos
ressources réseau à grande échelle. Vous pouvez associer vos réseaux virtuels à un plan
de protection DDoS dans Azure Firewall Manager. Cette fonctionnalité est actuellement
disponible en préversion publique. Consultez Configurer un plan de protection Azure
DDoS à l’aide d’Azure Firewall Manager.
Activer la protection DDoS pour tous les

réseaux virtuels
Cette stratégie intégrée détectera tous les réseaux virtuels dans une étendue définie
pour lesquels DDoS Network Protection n’est pas activée. Cette stratégie créera ensuite
éventuellement une tâche de correction qui créera l'association pour protéger le réseau
virtuel. Pour connaître la liste complète des stratégies intégrées, consultez Définitions
intégrées Azure Policy pour Azure DDoS Network Protection.
Désactiver pour un réseau virtuel :

Pour désactiver la protection DDoS pour un réseau virtuel, suivez les étapes suivantes.
1. Entrez le nom du réseau virtuel pour lequel vous souhaitez désactiver DDoS
Network Protection dans la zone Rechercher dans les ressources, les services et
les documents en haut du portail. Quand le nom du réseau virtuel apparaît dans
les résultats de la recherche, sélectionnez-le.
2. Sous DDoS Network Protection, sélectionnez Désactiver.
Valider et tester
Tout d’abord, vérifiez les détails de votre plan de protection DDoS :
1. Sélectionnez Tous les services dans la partie supérieure gauche du portail.

2. Entrez DDoS dans la zone Filtre. Quand Plans de protection DDoS apparaît dans
les résultats, sélectionnez cette entrée.
3. Sélectionnez votre plan de protection DDoS dans la liste.
Le réseau virtuel MyVnet doit être répertorié.
Afficher les ressources protégées

Sous Ressources protégées, vous pouvez afficher vos réseaux virtuels protégés et vos
adresses IP publiques, ou ajouter d’autres réseaux virtuels à votre plan de protection
DDoS :
Vous pouvez conserver vos ressources pour le tutoriel suivant. Si vous n’en avez plus
besoin, supprimez le groupe de ressources MyResourceGroup. Lorsque vous supprimez
le groupe de ressources, vous supprimez aussi le plan de protection DDoS et toutes ses
ressources associées. Si vous n’envisagez pas d’utiliser ce plan de protection DDoS, vous
devez supprimer les ressources pour éviter des frais inutiles.
２ Avertissement
Cette action est irréversible.
1. Dans le portail Azure, sélectionnez et recherchez Groupes de ressources ou

sélectionnez Groupes de ressources dans le menu du portail Azure.
2. Filtrez ou faites défiler vers le bas pour rechercher le groupe de ressources

MyResourceGroup.
3. Sélectionnez le groupe de ressources, puis Supprimer le groupe de ressources.
4. Tapez le nom du groupe de ressources pour vérifier, puis sélectionnez Supprimer.
７ Notes
Si vous souhaitez supprimer un plan de protection DDoS, vous devez d’abord

dissocier tous les réseaux virtuels de celui-ci.
Étapes suivantes
Pour savoir comment consulter et configurer la télémétrie pour votre plan de protection
DDoS, passez aux tutoriels.
Consulter et configurer la télémétrie de la protection DDoS

Partenariat avec Azure DDoS Protection
Article • 01/06/2023
Cet article décrit les opportunités de partenariat offertes par Azure DDoS Protection. Il
est conçu pour aider les chefs de produits et les personnes en charge du
développement commercial à comprendre les parcours d’investissement et à fournir des
insights sur les propositions de valeur de partenariat.
Arrière-plan
Les attaques par déni de service distribué (DDoS) représentent l’un des problèmes de
disponibilité et de sécurité majeurs soulevés par les clients qui déplacent leurs
applications vers le cloud. L’extorsion et le « hacktivisme » sont des motivations
courantes d’attaques DDoS, et elles présentent une augmentation constante en termes
de type, d’échelle et de fréquence des occurrences, car elles sont relativement faciles et
peu onéreuses à lancer.
Azure DDoS Protection propose des mesures contre les menaces DDoS les plus
sophistiquées, en tirant parti de l’échelle mondiale des réseaux Azure. Le service fournit
des fonctionnalités améliorées d’atténuation des attaques DDoS pour les applications et
les ressources déployées sur des réseaux virtuels.
Les partenaires informatiques peuvent protéger les ressources de leurs clients de

manière native avec Azure DDoS Protection afin de répondre aux problèmes de
disponibilité et de fiabilité dus aux attaques DDoS.
Présentation de Azure DDoS Protection

Azure DDoS Protection offre des fonctionnalités améliorées d’atténuation DDoS contre
les attaques DDoS de couche 3 et de couche 4. Voici les principales fonctionnalités du
service DDoS Protection :
Réglage adaptatif en temps réel

Pour chaque application protégée, Azure DDoS Protection ajuste automatiquement les
seuils de stratégie d’atténuation DDoS en fonction des modèles de profil de trafic de
l’application. Le service effectue cette personnalisation en s’appuyant sur deux éléments
:
L’apprentissage automatique des modèles de trafic par client (par adresse IP) pour
les couches 3 et 4.
La réduction des faux positifs dans la mesure où l’échelle d’Azure permet
d’absorber une quantité importante de trafic.
Analytique des attaques, télémétrie, supervision et alertes

Azure DDoS Protection identifie et atténue les attaques DDoS sans aucune intervention
de l’utilisateur.
Si la ressource protégée se trouve dans l’abonnement couvert par Microsoft

Defender pour le cloud, DDoS Protection envoie automatiquement une alerte à
Defender pour le cloud chaque fois qu’une attaque DDoS est détectée et atténuée
sur l’application protégée.
En guise d’alternative, pour être notifié en cas d’atténuation active pour une
adresse IP publique protégée, vous pouvez configurer une alerte sur la métrique
Sous attaque DDoS ou non.
Vous pouvez également choisir de créer des alertes pour les autres métriques
DDoS et configurer la télémétrie des attaques afin de comprendre l’ampleur de
l’attaque, le trafic abandonné, les vecteurs d’attaque, les principaux contributeurs
et d’autres détails.
DDoS Rapid Response (DRR)

Les clients DDoS Protection peuvent contacter l’équipe du service Rapid Response
pendant une attaque active. Le service DRR peut aider en enquêtant sur l’attaque
lorsqu’elle survient et en publiant une analyse de cette dernière.
Garantie du contrat SLA et protection des coûts

Le service DDoS Protection est couvert par un contrat SLA de 99,99 %, et la protection
des coûts fournit des crédits de ressources pour le scale-out lors d’une attaque
documentée. Pour plus d’informations, consultez SLA pour Protection DDoS Azure .
Scénarios de partenaires
Voici les principaux avantages dont vous pouvez bénéficier par l’intégration à Azure
DDoS Protection :
Les services proposés par les partenaires (équilibreur de charge, pare-feu

d’applications web, pare-feu, etc.) à leurs clients sont protégés automatiquement
(marqués en blanc) par Azure DDoS Protection dans le back-end.
Les partenaires ont accès à l’analytique des attaques et à la télémétrie Azure DDoS
Protection qu’ils peuvent intégrer à leurs propres produits, offrant ainsi une
expérience client unifiée.
Les partenaires ont accès au support de réponse rapide DDoS, même en l’absence
de réponse rapide Azure, pour les problèmes liés à DDoS.
Les applications protégées des partenaires bénéficient d’une garantie de contrat
SLA DDoS et d’une protection des coûts en cas d’attaques DDoS.
Présentation de l’intégration technique
Les opportunités de partenariat Azure DDoS Protection sont mises à disposition par le
biais du portail Azure, des API et de l’interface CLI/PS.
Intégrer à DDoS Protection

La configuration de l’intégration avec Azure DDoS Protection par les partenaires
nécessite les étapes suivantes :
1. Créez un plan de protection DDoS dans l’abonnement (partenaire) souhaité. Pour

obtenir des instructions pas à pas, consultez Créer un plan de protection DDoS.
７ Notes
Un seul plan de protection DDoS doit être créé pour un locataire donné.
2. Déployez un service avec un point de terminaison public dans vos abonnements

(partenaires), par exemple équilibreur de charge, pare-feu et pare-feu
d’applications web.
3. Activez Azure DDoS Protection sur le réseau virtuel du service qui a des points de
terminaison publics à l’aide du plan de protection DDoS créé à la première étape.
Pour obtenir des instructions pas à pas, consultez Activer un plan de protection
DDoS
） Important
Une fois qu’Azure DDoS Protection est activé sur un réseau virtuel, toutes les
adresses IP publiques de ce réseau virtuel sont protégées automatiquement.
L’origine de ces adresses IP publiques peut être dans Azure (abonnement
client) ou en dehors d’Azure.
4. Si vous le souhaitez, vous pouvez intégrer l’analytique des attaques et la télémétrie

Azure DDoS Protection dans votre tableau de bord client propre à l’application.
Pour plus d’informations sur l’utilisation de la télémétrie, reportez-vous à Consulter
et configurer la télémétrie de la protection DDoS.
Guides d’intégration et documentation technique

Azure DDoS Protection : page produit
Documentation sur Azure DDoS Protection
Informations de référence sur l’API Azure DDoS Protection
Informations de référence sur l’API de Réseau virtuel Azure
Obtenir de l’aide
Si vous avez des questions sur l’intégration des applications, des services ou des
produits avec Azure DDoS Protection, contactez la communauté de sécurité
Azure .
Suivez les discussions sur Stack Overflow .
Accès au marché
Le principal programme de partenariat avec Microsoft est le Microsoft Partner
Network . – Les intégrations de Microsoft Graph Security sont comprises dans le
suivi MPN Independent Software Vendor (ISV) .
Microsoft Intelligent Security Association est un programme spécifiquement
destiné aux partenaires de sécurité Microsoft afin de les aider à enrichir leurs
produits de sécurité et à améliorer la découvertibilité par les clients des
intégrations aux produits de sécurité Microsoft.
Étapes suivantes
Consultez les intégrations partenaires existantes :
Barracuda WAF-as-a-Service
Créer, changer ou supprimer un groupe
Article • 24/04/2023
Les règles de sécurité dans les groupes de sécurité réseau permettent de filtrer le type
de trafic réseau qui peut circuler vers et depuis les interfaces réseau et les sous-réseaux
de réseau virtuel. Pour en savoir plus sur les groupes de sécurité réseau, consultez Vue
d’ensemble du groupe de sécurité réseau. Ensuite, suivez le tutoriel Filtrer le trafic
réseau pour gagner en expérience avec les groupes de sécurité réseau.
Prérequis

Azure.


connecter à Azure.
vous connecter à Azure.
Attribuez le rôle Contributeur réseau ou un rôle Personnalisé avec les autorisations

appropriées.
Utiliser des groupes de sécurité réseau

Vous pouvez effectuer différentes opérations concernant les groupes de sécurité réseau
: en créer, les voir tous, afficher les détails d’un des groupes, les changer et en
supprimer. Vous pouvez également associer ou dissocier un groupe de sécurité réseau à
ou d’une interface réseau ou sous-réseau.

Le nombre de groupes de sécurité réseau que vous pouvez créer par abonnement et par
région Azure est limité. Pour en savoir plus, consultez Abonnement Azure et les limites,
quotas et contraintes des services.
Portail
1. Dans la zone de recherche située en haut du portail, entrez Groupe de sécurité

réseau. Dans les résultats de la recherche, sélectionnez Groupe de sécurité
réseau.
3. Dans la page Créer un groupe de sécurité réseau, sous l’onglet De base,

entrez ou sélectionnez les valeurs suivantes :
Paramètre Action
Détails du
projet
Resource Sélectionnez un groupe de ressources existant ou créez-en un en

group sélectionnant Créer. Cet exemple utilise le groupe de ressources
myResourceGroup .
Paramètre Action
Détails de
l’instance
Nom du Entrez un nom pour le groupe de sécurité réseau que vous créez.
groupe de
sécurité
réseau
Région Sélectionnez la région souhaitée.
5. Quand le message Validation réussie s’affiche, sélectionnez Créer.
Voir tous les groupes de sécurité réseau
Portail
Dans la zone de recherche située en haut du portail, entrez Groupe de sécurité

réseau. Sélectionnez Groupes de sécurité réseau dans les résultats de la recherche
pour afficher la liste des groupes de sécurité réseau dans votre abonnement.
Voir les détails d’un groupe de sécurité réseau
Portail

réseau , puis sélectionnez Groupes de sécurité réseau dans les résultats de la
recherche.
2. Sélectionnez le nom de votre groupe de sécurité réseau.
Sous Paramètres vous pouvez voir les Règles de sécurité de trafic entrant, les
Règles de sécurité de trafic sortant, les Interfaces réseau et les Sous-réseaux
auxquels le groupe de sécurité réseau est associé.
Sous Surveillance, vous pouvez activer ou désactiver les Paramètres de diagnostic.

Pour plus d’informations, consultez Journalisation des ressources pour un groupe
Sous Aide, vous pouvez voir les Règles de sécurité effectives. Pour plus
d’informations, consultez Diagnostiquer un problème de filtre de trafic réseau sur

Pour en savoir plus sur les paramètres Azure courants répertoriés, consultez les
articles suivants :
Balises
Verrous
Script Automation
Changer un groupe de sécurité réseau

Les modifications les plus courantes apportées à un groupe de sécurité réseau sont les
suivantes :
Associer ou dissocier un groupe de sécurité réseau à une interface réseau
Associer ou dissocier un groupe de sécurité réseau à un sous-réseau
Créer une règle de sécurité
Supprimer une règle de sécurité

Associer ou dissocier un groupe de sécurité réseau à une
interface réseau
Pour plus d’informations sur l’association et la dissociation d’un groupe de sécurité
réseau, consultez Associer ou dissocier un groupe de sécurité réseau.
Associer ou dissocier un groupe de sécurité réseau à un

sous-réseau
Portail

recherche.
2. Sélectionnez le nom de votre groupe de sécurité réseau, puis sélectionnez

Sous-réseaux.
Pour associer un groupe de sécurité réseau au sous-réseau, sélectionnez +

Associer, puis sélectionnez votre réseau virtuel et le sous-réseau auquel vous
souhaitez associer le groupe de sécurité réseau. Sélectionnez OK.
Pour dissocier un groupe de sécurité réseau du sous-réseau, sélectionnez les trois

points en regard du sous-réseau dont vous souhaitez dissocier le groupe de
sécurité réseau, puis sélectionnez Dissocier. Sélectionnez Oui.
Supprimer un groupe de sécurité réseau
Si un groupe de sécurité réseau est associé à des sous-réseaux ou à des interfaces
réseau, il ne peut pas être supprimé. Dissociez un groupe de sécurité réseau de tous les
sous-réseaux et interfaces réseau avant de tenter de le supprimer.
Portail

recherche.
2. Sélectionnez le groupe de sécurité réseau que vous souhaitez supprimer.
Utiliser des règles de sécurité

Un groupe de sécurité réseau contient zéro règle de sécurité, ou plus. Vous pouvez
effectuer différentes opérations concernant les règles de sécurité : en créer, les voir tout,
afficher les détails d’une des règles, les changer et en supprimer.
Créer une règle de sécurité

Le nombre de règles par groupe de sécurité réseau que vous pouvez créer par
abonnement et par emplacement Azure est limité. Pour en savoir plus, consultez
Abonnement Azure et les limites, quotas et contraintes des services.
Portail

recherche.
2. Sélectionnez le groupe de sécurité réseau auquel vous souhaitez ajouter une

règle de sécurité.
3. Sélectionnez Règles de sécurité de trafic entrant ou Règles de sécurité de

trafic sortant.
Plusieurs règles existantes sont répertoriées, y compris quelques-unes que

vous n’avez peut-être pas ajoutées. Lorsque vous créez un groupe de sécurité
réseau, plusieurs règles de sécurité par défaut y sont créées. Pour plus
d’informations, consultez Règles de sécurité par défaut. Vous ne pouvez pas
supprimer les règles de sécurité par défaut, mais vous pouvez les remplacer
par des règles qui ont une priorité plus élevée.
4. Sélectionnez +Ajouter. Sélectionnez ou ajoutez des valeurs pour les

paramètres suivants, puis sélectionnez Ajouter :

Source Valeurs possibles : Si vous choisissez Adresses IP, vous devez

Any également spécifier les Plages d’adresses
Adresses IP IP/CIDR sources.
Mon adresse
IP Si vous choisissez Balise de service, vous
Étiquette du pouvez également choisir une balise de
service service source.
Groupe de
Si vous choisissez Groupe de sécurité
sécurité
d’application, vous devez également
d’application
sélectionner un groupe de sécurité
d’application existant. Si vous choisissez
Groupe de sécurité d’application en tant que
source et destination, les interfaces réseau
dans les deux groupes de sécurité
d’application doivent se trouver dans le même
réseau virtuel. Découvrez comment créer un
groupe de sécurité d’application.
Plages Liste délimitée par Ce paramètre apparaît si vous changez Source

d’adresses des virgules en Adresses IP. Vous devez spécifier une
IP/CIDR d’adresses IP et de valeur unique ou une liste de valeurs séparées
sources plages CIDR par des virgules. Un exemple de plusieurs
(Classless valeurs est 10.0.0.0/16, 192.188.1.1 . Le
Interdomain nombre de valeurs que vous pouvez spécifier
Routing) est limité. Pour plus d'informations, consultez
Limites Azure.
Si l’adresse IP que vous spécifiez est attribuée

à une machine virtuelle Azure, spécifiez son
adresse IP privée, et non son adresse IP
publique. Azure traite les règles de sécurité
sont traitées une fois l’adresse IP publique
convertie en adresse IP privée pour les règles
de sécurité liées au trafic entrant, mais avant
de convertir l’adresse IP privée en adresse IP
publique pour les règles de trafic sortant. Pour
en savoir plus sur les adresses IP dans Azure,
consultez Adresses IP publiques et adresses IP
privées.
Balise du Une balise de Ce paramètre apparaît si vous définissez

service source service dans la liste Source sur Balise de service pour une règle
déroulante de sécurité. Une balise de service est un
identificateur prédéfini pour une catégorie
d’adresses IP. Pour en savoir plus sur les
balises de service disponibles et ce que
représente chaque balise, consultez Balises de
service.
Groupe de Groupe de sécurité Ce paramètre apparaît si vous définissez

sécurité d’application Source sur Groupe de sécurité d’application.
d’application source existant Sélectionnez un groupe de sécurité
source d’application qui existe dans la même région
que l’interface réseau. Découvrez comment
créer un groupe de sécurité d’application.
Plages de Valeurs possibles : Ce paramètre spécifie les ports sur lesquels la

ports source Un port règle autorise ou refuse le trafic. Le nombre
unique, par de ports que vous pouvez spécifier est limité.
exemple 80 Pour plus d'informations, consultez Limites
Un plage de Azure.
ports, par
exemple
1024-65535
Une liste
séparée par
des virgules
de ports
uniques
et/ou de
plages de
ports, par
exemple 80,
1024-65535
Un
astérisque
( * ) pour
autoriser le
trafic sur
n’importe
quel port
Destination Valeurs possibles : Si vous sélectionnez Adresses IP, vous devez

Any spécifier les Plages d’adresses IP/CIDR de
Adresses IP destination.
Étiquette du
service Si vous choisissez Balise de service, vous
Groupe de pouvez également choisir une balise de
sécurité service Destination.
d’application
Si vous choisissez Groupe de sécurité
d’application, vous devez également
sélectionner un groupe de sécurité
d’application existant. Si vous choisissez
Groupe de sécurité d’application en tant que
source et destination, les interfaces réseau
dans les deux groupes de sécurité
d’application doivent se trouver dans le même
réseau virtuel. Découvrez comment créer un
groupe de sécurité d’application.
Plages Liste délimitée par Ce paramètre apparaît si vous changez

d’adresses des virgules Destination en Adresses IP. À l’image de
IP/CIDR de d’adresses IP et de Source et de Plages d’adresses IP/CIDR
destination plages CIDR sources, vous pouvez spécifier une seule
adresse ou plage, ou bien plusieurs. Le
nombre de ports que vous pouvez spécifier
est limité. Pour plus d'informations, consultez
Limites Azure.
Si l’adresse IP que vous spécifiez est attribuée

à une machine virtuelle Azure, vérifiez que
vous spécifiez bien son adresse IP privée, et
non son adresse IP publique. Azure traite les
règles de sécurité sont traitées une fois
l’adresse IP publique convertie en adresse IP
privée pour les règles de sécurité liées au
trafic entrant, mais avant de convertir
l’adresse IP privée en adresse IP publique
pour les règles de trafic sortant. Pour en savoir
plus sur les adresses IP dans Azure, consultez
Adresses IP publiques et adresses IP privées.
Balise Une balise de Ce paramètre apparaît si vous définissez

d’identification service dans la liste Destination sur Balise de service pour une
de destination déroulante règle de sécurité. Une balise de service est un
identificateur prédéfini pour une catégorie
d’adresses IP. Pour en savoir plus sur les
balises de service disponibles et ce que
représente chaque balise, consultez Balises de
service.
Groupe de Groupe de sécurité Ce paramètre apparaît si vous définissez

sécurité d’application Destination sur Groupe de sécurité
d’application source existant d’application. Sélectionnez un groupe de
de destination sécurité d’application qui existe dans la même
région que l’interface réseau. Découvrez
comment créer un groupe de sécurité
d’application.
Service Un protocole de Ce paramètre spécifie le protocole de

destination dans la destination et la plage de ports pour la règle
liste déroulante de sécurité. Vous pouvez choisir un service
prédéfini, comme RDP, ou choisir
Personnalisé et fournir la plage de ports dans
Plages de ports de destination.
Plages de Valeurs possibles : Comme pour Plages de ports source, vous

ports de Un port pouvez spécifier un ou plusieurs ports et
destination unique, par plages. Le nombre de ports que vous pouvez
exemple 80 spécifier est limité. Pour plus d'informations,
Un plage de consultez Limites Azure.
ports, par
exemple
1024-65535
Une liste
séparée par
des virgules
de ports
uniques
et/ou de
plages de
ports, par
exemple 80,
1024-65535
Un
astérisque
( * ) pour
autoriser le
trafic sur
n’importe
quel port
Protocole Any, TCP, UDP ou Vous pouvez restreindre la règle au protocole

ICMP TCP (Transmission Control Protocol), UDP
(User Datagram Protocol) ou ICMP (Internet
Control Message Protocol). La valeur par
défaut correspond à la règle qui s’applique à
tous les protocoles (Tous).
Action Autoriser ou Ce paramètre spécifie si cette règle autorise

Refuser ou refuse l’accès pour la configuration source
et de destination fournie.
Priorité Entrez une valeur Azure traite les règles de sécurité par ordre de
comprise entre 100 priorité. Plus le numéro est faible, plus la
et 4096 qui est priorité est élevée. Nous vous recommandons
unique pour toutes de laisser un écart entre les numéros de
les règles de priorité quand vous créez des règles, par
sécurité au sein du exemple, 100, 200, 300. Cela permet par la
groupe de sécurité suite d’intercaler de nouvelles règles et de leur
réseau. donner une priorité plus ou moins élevée que
les règles existantes.
Nom Nom unique de la Le nom peut comprendre jusqu’à 80

règle au sein du caractères. Il doit commencer par une lettre
groupe de sécurité ou un chiffre et se terminer par une lettre, un
réseau chiffre ou un trait de soulignement. Le nom
peut contenir uniquement des lettres, des
chiffres, des traits d’union, des traits de
soulignement et des points.
Description Description texte Vous pouvez éventuellement spécifier une

description texte de la règle de sécurité. La
description ne doit pas avoir plus de
140 caractères.
Voir toutes les règles de sécurité

Un groupe de sécurité réseau contient zéro ou plusieurs règles. Pour en savoir plus sur
les informations affichées avec les règles, consultez Règles de sécurité.
Portail

recherche.
2. Dans la liste, sélectionnez le nom du groupe de sécurité réseau dont vous

souhaitez voir les règles.

trafic sortant.
La liste contient toutes les règles que vous avez créées et les règles de sécurité
par défaut de votre groupe de sécurité réseau.
Voir les détails d’une règle de sécurité
Portail

recherche.


trafic sortant.
4. Sélectionnez la règle dont vous souhaitez voir les détails. Pour obtenir une
explication détaillée de tous les paramètres, consultez les paramètres de règle
de sécurité.
７ Notes
Cette procédure s’applique uniquement aux règles de sécurité

personnalisées. Cela ne fonctionne pas si vous choisissez une règle de
sécurité par défaut.
Changer une règle de sécurité
Portail

recherche.

trafic sortant.
4. Sélectionnez la règle que vous souhaitez modifier.
5. Changez les paramètres comme vous le souhaitez, puis sélectionnez

Enregistrer. Pour obtenir une explication détaillée de tous les paramètres,
consultez les paramètres de règle de sécurité.
７ Notes

personnalisées. Vous n’êtes pas autorisé à modifier les règles de sécurité
par défaut.
Supprimer une règle de sécurité
Portail

recherche.


trafic sortant.
4. Sélectionnez les règles que vous souhaitez supprimer.
5. Sélectionnez Supprimer, puis cliquez sur Oui.

７ Notes

personnalisées. Vous n’êtes pas autorisé à supprimer les règles de
sécurité par défaut.
Utiliser des groupes de sécurité d’application

Un groupe de sécurité d’application contient zéro interface réseau, ou plus. Pour en
savoir plus, consultez Groupes de sécurité d’application. Toutes les interfaces réseau
dans un groupe de sécurité d’application doivent exister dans le même réseau virtuel.
Pour savoir comment ajouter une interface réseau à un groupe de sécurité d’application,
consultez Ajouter une interface réseau à un groupe de sécurité d’application.
Créer un groupe de sécurité d’application
Portail

application. Dans les résultats de la recherche, sélectionnez Groupes de
3. Dans la page Créer un groupe de sécurité application, sous l’onglet De base,

entrez ou sélectionnez les valeurs suivantes :
Paramètre Action
Détails du
projet
Resource Sélectionnez un groupe de ressources existant ou créez-en un en

group sélectionnant Créer. Cet exemple utilise le groupe de ressources
myResourceGroup .
Détails de
l’instance
Nom Entrez un nom pour le groupe de sécurité d’application que vous

créez.
Région Sélectionnez la région dans laquelle vous souhaitez créer le groupe de

5. Quand le message Validation réussie s’affiche, sélectionnez Créer.
Voir tous les groupes de sécurité d’application
Portail
Dans la zone de recherche située en haut du portail, entrez Groupe de sécurité
application. Dans les résultats de la recherche, sélectionnez Groupes de sécurité
d’application. Le portail Azure affiche la liste de vos groupes de sécurité
d’application.
Voir les détails d’un groupe de sécurité d’application

spécifique
Portail

2. Sélectionnez le groupe de sécurité d’application dont vous souhaitez afficher

les détails.
Changer un groupe de sécurité d’application
Portail

2. Sélectionnez le groupe de sécurité d’application que vous souhaitez modifier.
Sélectionnez Déplacer en regard de Groupe de ressources ou Abonnement pour

modifier respectivement le groupe de ressources ou l’abonnement.
Sélectionnez Modifier en regard de Balises pour ajouter ou supprimer des balises.
Pour plus d’informations, consultez Utiliser des étiquettes pour organiser vos
ressources Azure et votre hiérarchie de gestion
７ Notes
Vous ne pouvez pas modifier l’emplacement d’un groupe de sécurité

d’application.
Sélectionnez Contrôle d’accès (IAM) pour ajouter ou supprimer des autorisations

pour le groupe de sécurité d’application.
Supprimer un groupe de sécurité d’application

Vous ne pouvez pas supprimer un groupe de sécurité d’application s’il contient des
interfaces réseau. Pour supprimer toutes les interfaces réseau du groupe de sécurité
d’application, vous pouvez modifier les paramètres d’interface réseau ou supprimer les
interfaces réseau. Pour plus d’informations, consultez Ajout ou suppression dans les
groupes de sécurité d’application ou Supprimer une interface réseau.
Portail

2. Sélectionnez le groupe de sécurité d’application que vous souhaitez

supprimer.
3. Sélectionnez Supprimer, puis sélectionnez Oui pour supprimer le groupe de
Autorisations
Pour gérer les groupes de sécurité réseau, les règles de sécurité et les groupes de
sécurité des applications, votre compte doit disposer du rôle Contributeur réseau. Vous
pouvez également utiliser un rôle personnalisé disposant des autorisations appropriées,
comme indiqué dans les tableaux suivants :
Groupe de sécurité réseau
Action Nom
Microsoft.Network/networkSecurityGroups/read Obtenir un groupe de sécurité réseau
Microsoft.Network/networkSecurityGroups/write Créer ou mettre à jour un groupe de

sécurité réseau
Microsoft.Network/networkSecurityGroups/delete Supprimer un groupe de sécurité réseau
Microsoft.Network/networkSecurityGroups/join/action Associez un groupe de sécurité réseau à

un sous-réseau ou à une interface réseau
７ Notes
Pour effectuer des opérations write sur un groupe de sécurité réseau, le compte
d’abonnement doit au moins avoir les autorisations read pour le groupe de
ressources, ainsi que l’autorisation
Microsoft.Network/networkSecurityGroups/write .
Règle de groupe de sécurité réseau
Action Nom
Microsoft.Network/networkSecurityGroups/securityRules/read Obtenir une règle
Microsoft.Network/networkSecurityGroups/securityRules/write Créer ou mettre à jour une

règle
Microsoft.Network/networkSecurityGroups/securityRules/delete Supprimer une règle
Groupe de sécurité d’application
Action Nom
Microsoft.Network/applicationSecurityGroups/joinIpConfiguration/action Joindre une

configuration IP
aux groupes de
sécurité
d’application
Microsoft.Network/applicationSecurityGroups/joinNetworkSecurityRule/action Joindre une règle

de sécurité aux
groupes de
sécurité
d’application
Microsoft.Network/applicationSecurityGroups/read Obtenir un
groupe de
sécurité
d’application
Microsoft.Network/applicationSecurityGroups/write Créer ou mettre

à jour un groupe
de sécurité
d’application
Microsoft.Network/applicationSecurityGroups/delete Supprimer un
groupe de
sécurité
d’application
Étapes suivantes
Ajouter ou supprimer une interface réseau dans ou à partir d’un groupe de
Créez et attribuez des définitions Azure Policy pour les réseaux virtuels
Scénario d’appliance virtuelle
Pour les clients Azure volumineux, il faut souvent fournir une application à deux niveaux
exposée à Internet, tout en autorisant l’accès au niveau d’arrière-plan à partir d’un
centre de données local. Ce document vous guide dans un scénario utilisant des tables
de routage, une passerelle VPN et des appliances virtuelles de réseau pour déployer un
environnement à deux niveaux conforme aux exigences suivantes :
L’application web ne doit être accessible qu’à partir de l’Internet public.
Le serveur web hébergeant l’application doit pouvoir accéder à un serveur

d’application principal.
Tout le trafic transitant entre Internet et l’application web doit passer par une
appliance virtuelle de pare-feu. Cette appliance virtuelle n’est utilisée que pour le
trafic Internet.
Tout le trafic envoyé au serveur d’applications doit transiter par une appliance
virtuelle de pare-feu. Cette appliance virtuelle est utilisée pour accéder au serveur
principal depuis le réseau local via une passerelle VPN.
Les administrateurs doivent pouvoir gérer les appliances virtuelles de pare-feu à

partir de leurs ordinateurs locaux, en utilisant une troisième appliance virtuelle de
pare-feu exclusivement à des fins de gestion.
Cet exemple est un scénario de réseau de périmètre standard (également nommé DMZ)
avec une zone DMZ et un réseau protégé. Ce scénario peut être mis en œuvre dans
Azure à l’aide de groupes de sécurité réseau, d’appliances virtuelles de pare-feu ou
d’une combinaison des deux.
Le tableau ci-dessous présente certains avantages et inconvénients des groupes de

sécurité réseau et appliances virtuelles de pare-feu.
Élément Avantages Inconvénients
Groupe de Aucun coût. Complexité variable dans les

sécurité Intégré à l’accès en fonction du rôle Azure. environnements de grande taille.
réseau Il est possible de créer des règles dans les
modèles Azure Resource Manager.
Pare-feu Contrôle total sur le plan des données. Coût de l’appliance de pare-feu.
Gestion centralisée via la console du pare- Non intégré à l’accès en fonction
feu. du rôle Azure.
La solution suivante utilise des appliances virtuelles de pare-feu pour implémenter un
scénario de réseau de périmètre (DMZ)/réseau protégé.
Considérations
Vous pouvez déployer l’environnement décrit précédemment dans Azure à l’aide de
différentes fonctionnalités disponibles aujourd’hui, comme suit.
Réseau virtuel. Un réseau virtuel Azure se comporte de manière similaire à un

réseau local et peut se décomposer en un ou plusieurs sous-réseaux pour isoler le
trafic et les problèmes.
Appliance virtuelle. Plusieurs partenaires fournissent des appliances virtuelles dans

la Place de marché Azure, utilisables pour les trois pare-feu décrits précédemment.
Tables de routage. Les tables de routage sont utilisées par les itinéraires définis par
l’utilisateur, utilisées par la mise en réseau Azure pour contrôler le flux de paquets
dans un réseau virtuel. Ces tables d’itinéraires peuvent être appliquées à des sous-
réseaux. Vous pouvez appliquer une table de routage à GatewaySubnet, qui
transfère tout le trafic entrant dans le réseau virtuel Azure d’une connexion hybride
à une appliance virtuelle.
Transfert IP. Par défaut, le moteur de mise en réseau Azure ne transfère les
paquets aux cartes réseau que si l’adresse IP de destination des paquets
correspond à l’adresse IP de la carte réseau. Par conséquent, si une table de
routage définie par l’utilisateur détermine qu’un paquet doit être envoyé à une
appliance virtuelle donnée, le moteur de mise en réseau Azure supprime ce
paquet. Pour vérifier que le paquet est envoyé à une machine virtuelle (dans ce cas,
une appliance virtuelle) qui n’est pas la destination réelle du paquet, activez le
transfert IP pour l’appliance virtuelle.
Groupes de sécurité réseau (NSG) . L’exemple suivant ne tire pas parti de groupes
de sécurité réseau, mais vous pouvez utiliser les groupes de sécurité réseau
appliqués aux sous-réseaux et/ou à des NIC dans cette solution. Les groupes de
sécurité réseau filtrent davantage le trafic entrant et sortant de ces sous-réseaux et
cartes réseau.
Dans cet exemple, il existe un abonnement qui contient les éléments suivants :
Deux groupes de ressources, non représentés sur le diagramme.
ONPREMRG. Contient toutes les ressources nécessaires pour simuler un réseau

local.
AZURERG. Contient toutes les ressources nécessaires pour l’environnement du

Un réseau virtuel nommé onpremvnet segmenté comme suit utilisé pour imiter un
centre de données local.
onpremsn1. Sous-réseau contenant une machine virtuelle exécutant Ubuntu

pour imiter un serveur local.
onpremsn2. Sous-réseau contenant une machine virtuelle exécutant Ubuntu

pour simuler un ordinateur local utilisé par un administrateur.
Une appliance virtuelle de pare-feu nommée OPFW sur onpremvnet utilisée pour
conserver un tunnel vers azurevnet.
Un réseau virtuel nommé azurevnet segmenté comme suit.
azsn1. Sous-réseau utilisé exclusivement pour le pare-feu externe. Tout le trafic

Internet entrera par ce sous-réseau. Ce sous-réseau ne contient qu’une carte
réseau liée au pare-feu externe.
azsn2. Sous-réseau front-end hébergeant une machine virtuelle exécutée en
tant que serveur web accessible à partir d’Internet.
azsn3. Sous-réseau principal hébergeant une machine virtuelle exécutant un

serveur d’applications principal sollicité par le serveur web front-end.
azsn4. Sous-réseau utilisé exclusivement pour fournir un accès de gestion à

toutes les appliances virtuelles de pare-feu. Ce sous-réseau ne contient qu’une
carte réseau pour chaque appliance virtuelle de pare-feu utilisée dans la
solution.
GatewaySubnet. Sous-réseau de connexion hybride Azure requis pour une

route ExpressRoute et une passerelle VPN assurant la connectivité entre des
réseaux virtuels Azure et d’autres réseaux.
Le réseau azurevnet contient 3 appliances virtuelle de pare-feu.
AZF1. Pare-feu externe exposé à l’Internet public par l’utilisation d’une ressource
ayant une adresse IP publique dans Azure. Vous devez vous procurer un modèle
auprès de Marketplace ou directement auprès de votre fournisseur d’appliances,
qui déploie une appliance virtuelle à 3 cartes réseau.
AZF2. Pare-feu interne utilisé pour contrôler le trafic entre azsn2 et azsn3. Ce
pare-feu est également une appliance virtuelle à 3 cartes réseau.
AZF3. Pare-feu de gestion accessible aux administrateurs à partir du centre de

données local, et connecté à un sous-réseau servant à gérer toutes les
appliances de pare-feu. Vous pouvez trouver des modèles d’appliance virtuelle à
2 cartes réseau dans Marketplace ou en demander un à votre fournisseur
d’appliances.
Tables de routage
Chaque sous-réseau dans Azure peut être lié à une table de routage utilisée pour définir
le mode d’acheminement du trafic dans ce sous-réseau. Si aucun UDR n’est défini, Azure
utilise les itinéraires par défaut pour autoriser le trafic d’un sous-réseau à un autre. Pour
mieux comprendre les tables de routage et le routage du trafic, consultez Routage du
trafic de réseau virtuel Azure.
Pour assurer que la communication transite par l’appliance de pare-feu appropriée,

conformément à la dernière exigence indiquée précédemment, vous devez créer la table
de routage suivante dans azurevnet.
azgwudr
Dans ce scénario, seul le trafic local dirigé vers Azure sert à gérer le pare-feu en se
connectant à AZF3. De plus, le trafic doit transiter par le pare-feu interne AZF2. Par
conséquent, un seul itinéraire est nécessaire dans GatewaySubnet comme indiqué ci-
dessous.
Destination Tronçon suivant Explication
10.0.4.0/24 10.0.3.11 Autorise le trafic local à atteindre le pare-feu de gestion AZF3
azsn2udr
Destination Tronçon Explication

suivant
10.0.3.0/24 10.0.2.11 Autorise le trafic vers le sous-réseau principal qui héberge le serveur
d’applications, à transiter par AZF2
0.0.0.0/0 10.0.2.10 Autorise tout autre trafic à transiter par AZF1
azsn3udr

suivant
10.0.2.0/24 10.0.3.10 Autorise le trafic destiné à azsn2 à circuler du serveur d’applications

vers le serveur web via AZF2.
Vous devez également créer des tables d’itinéraires pour les sous-réseaux dans
onpremvnet afin d’imiter le centre de données local.
onpremsn1udr
Destination Tronçon suivant Explication
192.168.2.0/24 192.168.1.4 Autorise le trafic destiné à onpremsn2 à transiter par OPFW.
onpremsn2udr

suivant
suivant
10.0.3.0/24 192.168.2.4 Autorise le trafic vers le sous-réseau sauvegardé dans Azure à

transiter par OPFW
192.168.1.0/24 192.168.2.4 Autorise le trafic destiné à onpremsn1 à transiter par OPFW.
transfert IP
Les tables de routage et le transfert IP sont des fonctionnalités que vous pouvez
combiner pour permettre à des appliances virtuelles de contrôler le trafic dans un
réseau virtuel Azure. Une appliance virtuelle n’est rien de plus qu’une machine virtuelle
qui exécute une application permettant de gérer le trafic réseau d’une certaine façon,
comme un pare-feu ou un périphérique NAT.
La machine virtuelle d’appliance virtuelle doit être capable de recevoir le trafic entrant
qui ne lui est pas adressé. Pour permettre à une machine virtuelle de recevoir le trafic
adressé à d’autres destinations, vous devez activer le transfert IP pour la machine
virtuelle. Il s’agit d’un paramètre Azure, pas d’un paramètre du système d’exploitation
invité. Votre appliance virtuelle doit toujours exécuter un type d’application pour gérer
le trafic entrant et l’acheminer correctement.
Pour en savoir plus sur le transfert IP, consultez Routage du trafic de réseau virtuel
Azure.
Par exemple, imaginez un réseau virtuel Azure avec la configuration suivante :
Le sous-réseau onpremsn1 contient une machine virtuelle nommée onpremvm1.
Le sous-réseau onpremsn2 contient une machine virtuelle nommée onpremvm2.
Une appliance virtuelle nommée OPFW est connectée à onpremsn1 et à

onpremsn2.
Un itinéraire défini par l’utilisateur et lié à onpremsn1 spécifie que tout le trafic
destiné à onpremsn2 doit être envoyé à OPFW.
À ce point, si onpremvm1 tente d’établir une connexion à onpremvm2, l’UDR sera utilisé
et le trafic sera envoyé à OPFW en tant tronçon suivant. N’oubliez pas que la destination
réelle du paquet n’est pas modifiée (onpremvm2).
Si le transfert IP n’est pas activé pour OPFW, la logique du réseau virtuel Azure supprime
les paquets, car elle n’autorise l’envoi des paquets qu’à une machine virtuelle dont
l’adresse IP correspond à la destination du paquet.
Avec le transfert IP, la logique du réseau virtuel Azure transmet les paquets à OPFW,
sans modifier leur adresse de destination d’origine. OPFW doit gérer les paquets et
déterminer ce qu’il faut en faire.
Pour que ce scénario vu précédemment fonctionne, vous devez activer le transfert IP sur
les cartes réseau d’OPFW, AZF1, AZF2 et AZF3 qui sont utilisées pour le routage (toutes
les cartes réseau sauf celles liées au sous-réseau de gestion).
Règles de pare-feu
Comme décrit précédemment, le transfert IP ne garantit que l’envoi des paquets à des
appliances virtuelles. Votre appliance doit encore décider quoi faire avec les paquets.
Dans le scénario précédent, vous devez créer les règles suivantes dans vos appliances :
OPFW
OPFW représente un appareil local contenant les règles suivantes :
Itinéraire : tout le trafic vers 10.0.0.0/16 (azurevnet) doit être envoyé via le tunnel
ONPREMAZURE.
Stratégie : autoriser tout le trafic bidirectionnel entre port2 et ONPREMAZURE.
AZF1
AZF1 représente une appliance virtuelle Azure contenant les règles suivantes :
Stratégie : autoriser tout le trafic bidirectionnel entre port1 et port2.
AZF2
Stratégie : autoriser tout le trafic bidirectionnel entre port1 et port2.
AZF3
Itinéraire : tout le trafic vers 192.168.0.0/16 (onpremvnet) doit être envoyé à
l’adresse IP de la passerelle Azure (par exemple, 10.0.0.1) via port1.
Groupes de sécurité réseau (NSG)

Dans ce scénario, les groupes de sécurité réseau ne sont pas utilisés. Toutefois, vous
pouvez appliquer des groupes de sécurité réseau à chaque sous-réseau pour limiter les
trafics entrant et sortant. Par exemple, vous pouvez appliquer les règles de groupe de
sécurité réseau suivantes au sous-réseau FW externe.
Entrant
Autoriser tout le trafic TCP provenant d’Internet vers le port 80 sur toutes les
machines virtuelles du sous-réseau.
Refuser tout autre trafic provenant d’Internet.
Sortant
Refuser tout le trafic provenant d’Internet.
Étapes de haut niveau

Pour déployer ce scénario, suivez les étapes générales suivantes.
1. Connectez-vous à votre abonnement Azure.
2. Si vous souhaitez déployer un réseau virtuel pour imiter le réseau local, déployez
les ressources qui font partie d’ONPREMRG.
3. Déployez les ressources qui font partie d’AZURERG.
4. Déployez le tunnel reliant onpremvnet à azurevnet.
5. Une fois toutes les ressources approvisionnées, connectez-vous sur onpremvm2 et

envoyez la commande ping 10.0.3.101 pour tester la connectivité entre onpremsn2
et azsn3.
Implémenter un réseau hybride
sécurisé
Pare-feu Load Balancer Machines Virtuelles Réseau virtuel
Cette architecture de référence montre un réseau sécurisé hybride qui étend un réseau
local sur Azure. Cette architecture implémente un réseau de périmètre, également appelé
DMZ, entre le réseau local et un réseau virtuel Azure. Tout le trafic entrant et sortant
transite par le pare-feu Azure.
Architecture
Téléchargez un fichier Visio de cette architecture.
Composants
L’architecture repose sur les aspects suivants :
Réseau local. Réseau local privé implémenté dans une organisation.
Réseau virtuel Azure Le réseau virtuel héberge les composants de la solution et les
autres ressources exécutées dans Azure.
Les itinéraires de réseau virtuel définissent le flux de trafic IP au sein du réseau

virtuel Azure. Le diagramme contient deux tables de routage définies par
l'utilisateur.
Dans le sous-réseau de passerelle, le trafic est acheminé via le Pare-feu Azure.
７ Notes
Selon les exigences de votre connexion VPN, vous pouvez configurer des
itinéraires de protocole BGP (Border Gateway Protcol) pour implémenter les
règles de transfert qui orientent le trafic par le biais du réseau local.
Passerelle. La passerelle assure la connectivité entre les routeurs du réseau local et

ceux du réseau virtuel. La passerelle est placée dans son propre sous-réseau.
Pare-feu Azure. Le Pare-feu Azure est un pare-feu géré en tant que service.
L'instance de pare-feu est placée dans son propre sous-réseau.
Groupes de sécurité réseau. Utilisez des groupes de sécurité pour limiter le trafic
réseau au sein du réseau virtuel.
Azure Bastion. Azure Bastion vous permet de vous connecter aux machines
virtuelles du réseau virtuel via SSH ou RDP (Remote Desktop Protocol) sans
exposer les machines virtuelles directement à Internet. Utilisez Bastion pour gérer
les machines virtuelles du réseau virtuel.
Bastion nécessite un sous-réseau dédié appelé AzureBastionSubnet.
Cas d’usage potentiels

Cette architecture requiert une connexion à votre centre de données local, à l'aide d'une
passerelle VPN ou d'une connexion ExpressRoute. Utilisations courantes de cette
architecture :
Les applications hybrides où les charges de travail s’exécutent en partie en local et

dans Azure.
Une infrastructure qui nécessite un contrôle granulaire sur le trafic entrant d'un
réseau virtuel Azure à partir d'un centre de données local.
Les applications qui doivent auditer le trafic sortant. L’audit est souvent une
exigence réglementaire de nombreux systèmes commerciaux, qui peut permettre
d’éviter la divulgation publique d’informations privées.
Recommandations
Les recommandations suivantes s’appliquent à la plupart des scénarios. Suivez ces
recommandations, sauf si vous avez un besoin spécifique qui vous oblige à les ignorer.
Recommandations en matière de contrôle d’accès

Utilisez le contrôle d’accès en fonction du rôle Azure (RBAC Azure) pour gérer les
ressources de votre application. Envisagez de créer les rôles personnalisés suivants :
Un rôle DevOps avec des autorisations pour gérer l’infrastructure de l’application,

déployer les composants d’application et surveiller et redémarrer les machines
virtuelles.
Un rôle d’administrateur informatique centralisé pour gérer et surveiller les

ressources réseau.
Un rôle d'administrateur informatique de sécurité pour gérer les ressources réseau

sécurisées telles que le pare-feu.
Le rôle d’administrateur informatique ne doit pas avoir accès aux ressources du pare-
feu. L’accès doit être limité au rôle d’administrateur informatique de sécurité.
Recommandations pour les groupes de ressources

Les ressources Azure, telles que les machines virtuelles, les réseaux virtuels et les
équilibreurs de charge, peuvent être facilement gérées en les regroupant dans des
groupes de ressources. Attribuez des rôles Azure à chaque groupe de ressources pour
limiter l’accès.
Nous vous recommandons de créer les groupes de ressources suivants :
Un groupe de ressources contenant le réseau virtuel (sauf les machines virtuelles),

les groupes de sécurité réseau et les ressources de passerelle pour la connexion au
réseau local. Assignez le rôle d’administrateur informatique centralisé à ce groupe
de ressources.
Un groupe de ressources contenant les machines virtuelles de l'instance du Pare-
feu Azure et les itinéraires définis par l'utilisateur pour le sous-réseau de passerelle.
Assignez le rôle d’administrateur informatique de sécurité à ce groupe de
ressources.
Des groupes de ressources distincts pour chaque réseau virtuel spoke qui convient
l’équilibreur de charge et les machines virtuelles.
Recommandations pour la mise en réseau

Pour accepter le trafic entrant en provenance d'Internet, ajoutez une règle DNAT
(Destination Network Address Translation) au Pare-feu Azure.
Adresse de destination = Adresse IP publique de l'instance du pare-feu.

Adresse traduite = Adresse IP privée au sein du réseau virtuel.
Acheminez de force tout le trafic Internet sortant via votre réseau local à l'aide du tunnel
VPN site à site, et acheminez-le vers Internet à l'aide de la traduction d'adresses réseau
(NAT). Cette conception empêche la divulgation accidentelle d’informations
confidentielles et permet d’inspecter et d’auditer tout le trafic sortant.
Ne bloquez pas complètement le trafic Internet des ressources dans les sous-réseaux
spoke. Bloquer le trafic empêchera ces ressources d’utiliser les services PaaS Azure qui
reposent sur les adresses IP publiques, comme la journalisation des diagnostics des
machines virtuelles, le téléchargement des extensions de machines virtuelles, et d’autres
fonctionnalités. Les diagnostics Azure exigent également que les composants puissent
lire et écrire dans un compte de stockage Azure.
Vérifiez que le trafic Internet sortant est correctement acheminé de force. Si vous utilisez
une connexion VPN avec le service de routage et d'accès à distance sur un serveur local,
utilisez un outil tel que WireShark .
Pensez à utiliser Application Gateway ou Azure Front Door pour l'arrêt SSL.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est
un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge
de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected
Framework.
Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la
demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue
d’ensemble du pilier d’efficacité des performances.
Pour plus d'informations sur les limites de bande passante de la passerelle VPN,
consultez Références SKU de passerelles. Pour des bandes passantes plus élevées,
envisagez d’effectuer une mise à niveau vers une passerelle ExpressRoute. ExpressRoute
offre jusqu’à 10 Gbit/s de bande passante avec une latence inférieure à celle d’une
connexion VPN.
Pour plus d’informations sur la scalabilité des passerelles Azure, consultez les sections
relatives à la scalabilité dans :
Implémentation d'une architecture réseau hybride avec Azure et un VPN local

Implémentation d’une architecture réseau hybride avec Azure ExpressRoute
Pour plus de détails sur la gestion des réseaux virtuels et des groupes de sécurité réseau
à grande l'échelle, consultez Azure Virtual Network Manager (AVNM): Créer un réseau
hub-and-spoke sécurisé pour créer de nouvelles topologies de réseau virtuel hub-and-
spoke (et intégrer les topologies existantes) pour une gestion centralisée de la
connectivité et des règles des groupes de sécurité réseau.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de
vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de
fiabilité.
Si vous utilisez Azure ExpressRoute pour fournir la connectivité entre le réseau local et le
réseau virtuel, configurez une passerelle VPN pour proposer un basculement si la
connexion ExpressRoute n'est plus disponible.
Pour obtenir des informations sur le maintien de la disponibilité des connexions VPN et
ExpressRoute, consultez les considérations relatives à la disponibilité dans :
Implémentation d'une architecture réseau hybride avec Azure et un VPN local

Implémentation d’une architecture réseau hybride avec Azure ExpressRoute
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une
application et maintiennent son fonctionnement en production. Pour plus
d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.
En cas de problème de connectivité sur la passerelle qui relie votre réseau local à Azure,
vous pouvez toujours accéder aux machines virtuelles du réseau virtuel Azure via Azure
Bastion.
Chaque sous-réseau de couche dans l’architecture de référence est protégé par les
règles du groupe de sécurité réseau. Vous devrez peut-être créer une règle pour ouvrir
le port 3389 pour l’accès au protocole RDP sur les machines virtuelles Windows ou le
port 22 pour l’accès SSH sur les machines virtuelles Linux. D’autres outils de gestion et
de surveillance peuvent nécessiter des règles pour ouvrir des ports supplémentaires.
Si vous utilisez ExpressRoute pour fournir la connectivité entre votre centre de données
local et Azure, utilisez Azure Connectivity Toolkit (AzureCT) pour surveiller et résoudre
les problèmes de connexion.
Vous trouverez des informations supplémentaires sur la supervision et la gestion des
connexions VPN et ExpressRoute dans l’article Implémentation d’une architecture réseau
hybride avec Azure et un VPN local.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation
abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue
d’ensemble du pilier Sécurité.
Cette architecture de référence implémente plusieurs niveaux de sécurité.
Routage de toutes les requêtes des utilisateurs locaux via le Pare-

feu Azure
L'itinéraire défini par l'utilisateur dans le sous-réseau de passerelle bloque toutes les
requêtes des utilisateurs en dehors de celles reçues du site local. La route transmet les
demandes autorisées au pare-feu. Les demandes sont transmises ensuite aux ressources
dans les réseaux virtuels spoke si elles sont autorisées par les règles de pare-feu. Vous
pouvez ajouter d'autres itinéraires, mais veillez à ce qu'ils ne contournent pas par
inadvertance le pare-feu ou à ce qu'ils ne bloquent pas le trafic destiné au sous-réseau
de gestion.
Utilisation de groupes de sécurité réseau pour bloquer/transmettre

le trafic vers des sous-réseaux de réseau virtuel spoke
Le trafic vers et depuis des sous-réseaux de ressources dans des réseaux virtuels spoke
est limité moyennant des groupes de sécurité réseau. Si vous avez besoin d’une
exigence pour développer les règles du groupe de sécurité réseau afin d’autoriser un
accès plus large à ces ressources, évaluez ces exigences par rapport aux risques de
sécurité. Chaque nouveau chemin d’accès entrant représente un risque d’altération
d’application ou de divulgation de données volontaire ou accidentelle.
Protection DDoS
Azure DDoS Protection Standard, combiné aux meilleures pratiques de conception
d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées
pour une meilleure défense contre les attaques DDoS. Vous devez activer Azure DDoS
Protection Standard sur tout réseau virtuel de périmètre.
Utiliser AVNM pour créer des règles de base
d’administration de la sécurité
AVNM vous permet de créer des bases de référence de règles de sécurité, qui peuvent
prendre la priorité sur les règles de groupe de sécurité réseau. Les règles
d’administration de la sécurité sont évaluées avant celles du NSG (groupe de sécurité
réseau) et ont la même nature que ces dernières, avec la prise en charge de la
hiérarchisation, des balises de service et des protocoles L3-L4. AVNM permet au service
informatique central de mettre en place une base de référence des règles de sécurité,
tout en autorisant une indépendance des règles de groupe de sécurité réseau
supplémentaires pour les propriétaires des réseaux virtuels spoke. Pour faciliter un
déploiement contrôlé des changements de règles de sécurité, la fonctionnalité de
déploiements d’AVNM vous permet de libérer en toute sécurité les changements de
rupture de ces configurations dans les environnements hub-and-spoke.
Accès DevOps
Utilisez RBAC Azure pour limiter les opérations que DevOps peut effectuer sur chaque
couche. Lorsque vous accordez des autorisations, utilisez le principe des privilèges
minimum. Journalisez toutes les opérations d’administration et réalisez des audits
réguliers pour vérifier qu’aucune modification de configuration n’est prévue.
Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles
et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue
d’ensemble du pilier d’optimisation des coûts.
Utiliser la calculatrice de prix Azure pour estimer les coûts. D'autres considérations
sont décrites dans la section Optimisation des coûts de Microsoft Azure Well-
Architected Framework.
Les considérations de coûts suivantes s'appliquent aux services utilisés dans cette
architecture.
Pare-feu Azure
Dans cette architecture, le Pare-feu Azure est déployé sur le réseau virtuel pour
contrôler le trafic entre le sous-réseau de la passerelle et les ressources des réseaux
virtuels spoke. De cette façon, Azure Firewall est rentable car il est utilisé en tant que
solution partagée consommée par plusieurs charges de travail. Les modèles de
tarification du Pare-feu Azure sont les suivants :
Taux fixe par heure de déploiement.

Données traitées par Go pour prendre en charge la mise à l'échelle automatique.
Par rapport aux appliances virtuelles réseau (NVA), le Pare-feu Azure vous permet
d'économiser 30 à 50 %. Pour plus d’informations, consultez Pare-feu Azure et
appliances virtuelles réseau .
Azure Bastion
Azure Bastion se connecte en toute sécurité à votre machine virtuelle via RDP et SSH
sans qu'il soit nécessaire de configurer une adresse IP publique sur celle-ci.
La facturation Bastion est comparable à celle d’une machine virtuelle de base de bas
niveau configurée en tant que jumpbox. Bastion est plus rentable qu’un serveur de
rebond, car il intègre des fonctionnalités de sécurité et n’entraîne pas de coûts
supplémentaires pour le stockage et la gestion d’un serveur distinct.
Le service Réseau virtuel Azure est gratuit. Chaque abonnement est autorisé à créer
jusqu’à 50 réseaux virtuels dans toutes les régions. Au sein du réseau virtuel, tout le
trafic est gratuit. Par exemple, les machines virtuelles d’un même réseau virtuel qui
communiquent entre elles n’entraînent pas de frais de trafic réseau.
Équilibreur de charge interne

L'équilibrage de charge de base entre les machines virtuelles d'un même réseau virtuel
est gratuit.
Dans cette architecture, des équilibreurs de charge internes sont utilisés pour équilibrer
la charge du trafic au sein d'un réseau virtuel.
Déployer ce scénario
Ce déploiement crée deux groupes de ressources : la première détient un réseau local
fictif, le deuxième un ensemble de réseaux Hub-and-Spoke. Le réseau local fictif et le
réseau hub sont connectés à l’aide de passerelles de réseau virtuel Azure pour former
une connexion de site à site. Cette configuration est très similaire à celle que vous
utiliseriez pour connecter votre centre de données local à Azure.
Ce déploiement peut prendre jusqu’à 45 minutes. La méthode de déploiement

recommandée utilise l’option de portail ci-dessous.
Azure portal
Utilisez le bouton suivant pour déployer la référence à l’aide du portail Azure.
Une fois le déploiement terminé, vérifiez la connectivité de site à site en examinant les
ressources de connexion nouvellement créées. Tant que vous êtes dans le portail Azure,
recherchez « connexions » et notez l’état de chaque connexion.
L’instance IIS trouvée dans le réseau spoke est accessible à partir de la machine virtuelle
située dans le réseau local fictif. Créez une connexion à la machine virtuelle à l’aide de
l’hôte Azure Bastion inclus, ouvrez un navigateur web et accédez à l’adresse de
l’équilibreur de charge réseau de l’application.
Pour obtenir des informations détaillées et d’autres options de déploiement, consultez

les modèles Azure Resource Manager (ARM) utilisés pour déployer cette solution :
Réseau hybride sécurisé.
Étapes suivantes
Le centre de données virtuel Azure : une perspective réseau.
Documentation sur la sécurité Azure.
Ressources associées
Connecter un réseau local à Azure en utilisant ExpressRoute.
Configurer ExpressRoute des connexions coexistantes de site à site en utilisant
PowerShell
Étendre un réseau local en utilisant ExpressRoute.
Tutoriel : Migrer l'adresse IP publique
d'une machine virtuelle vers une
passerelle NAT Azure
Article • 01/05/2023
Dans cet article, vous apprendrez à migrer l'adresse IP publique de votre machine
virtuelle vers une passerelle NAT. Vous apprendrez à supprimer l'adresse IP de la
machine virtuelle. Vous réutiliserez l'adresse IP de la machine virtuelle pour la passerelle
NAT.
Azure NAT Gateway est la méthode recommandé pour la connectivité sortante. Une
passerelle NAT Azure est un service de traduction d’adresses réseau entièrement
managé et hautement résilient. Une passerelle NAT n’a pas les mêmes limites
d’épuisement de ports SNAT qu’un accès sortant par défaut. Une passerelle NAT évite à
une machine virtuelle d'avoir à utiliser une adresse IP publique pour disposer d’une
connectivité sortante.
Pour plus d’informations sur Azure NAT Gateway, consultez Qu’est-ce que Azure NAT
Gateway
＂ Supprimer l’adresse IP publique de la machine virtuelle.

＂ Associez l’adresse IP publique de la machine virtuelle à une passerelle NAT.
Prérequis
Une machine virtuelle Azure avec une adresse IP publique attribuée à son interface
réseau. Pour plus d'informations sur la création d'une machine virtuelle avec une
adresse IP publique, consultez Démarrage rapide : Créer une machine virtuelle
Windows sur le Portail Azure.
Dans cet article, l'exemple de machine virtuelle est nommé myVM. L'exemple
d'adresse IP publique est nommé myPublicIP.
７ Notes
La suppression de l'adresse IP publique empêche les connexions directes à la

machine virtuelle depuis Internet. L'accès RDP ou SSH ne fonctionnera pas sur la
machine virtuelle après avoir effectué cette migration. Pour gérer en toute sécurité
les machines virtuelles de votre abonnement, utilisez Azure Bastion. Pour plus
d'informations sur Azure Bastion, consultez Présentation d'Azure Bastion.
Supprimer l'adresse IP publique de la machine

virtuelle
Dans cette section, vous apprendrez à supprimer l'adresse IP publique de la machine
virtuelle.

3. Dans Machines virtuelles, sélectionnez myVM ou votre machine virtuelle.
4. Dans la section Vue d’ensemble de myVM, sélectionnez Adresse IP publique.
5. Dans myPublicIP, sélectionnez la page Vue d'ensemble dans la colonne de

gauche.
6. Dans Vue d'ensemble, sélectionnez Dissocier.

7. Sélectionnez Oui dans Dissocier l'adresse IP publique.
(Facultatif) Mettre à niveau de l'adresse IP

La ressource de passerelle NAT nécessite une adresse IP publique SKU standard. Dans
cette section, vous allez mettre à niveau l'adresse IP que vous avez supprimée de la
machine virtuelle dans la section précédente. Si l'adresse IP que vous avez supprimée
est déjà une IP publique SKU standard, vous pouvez passer à la section suivante.
1. Dans la zone de recherche située en haut du portail, entrez IP publique.

Sélectionnez Adresses IP publiques.
2. Dans Adresses IP publiques, sélectionnez myPublicIP ou votre adresse IP SKU de

base.
3. Dans la section Vue d’ensemble de myPublicIP, sélectionnez la bannière de mise à

niveau de l'adresse IP.
4. Dans Mettre à niveau vers la référence SKU Standard, cochez la case J'accepte.
Sélectionnez le bouton Mettre à niveau.
5. Une fois la mise à niveau terminée, passez à la section suivante.
Créer une passerelle NAT

Dans cette section, vous allez créer une passerelle NAT avec l'adresse IP que vous avez
précédemment supprimée de la machine virtuelle. Vous assignerez la passerelle NAT à
votre sous-réseau pré-créé dans votre réseau virtuel. Le nom du sous-réseau pour cet
exemple est default.
1. Dans la zone de recherche située en haut du portail, entrez Passerelle NAT.

Sélectionnez Passerelles NAT.
2. Dans Passerelles NAT, sélectionnez + Créer.
3. Dans Créer une passerelle NAT (traduction d’adresses réseau), entrez ou

sélectionnez les informations suivantes dans l’onglet Informations de base.
Paramètre Valeur
Détails du projet

Sélectionnez OK.
Détails de
l’instance
Nom de la Entrez myNATgateway.

passerelle NAT
Paramètre Valeur
Région Sélectionnez la région de votre réseau virtuel. Dans cet exemple, il

s’agit de USA Ouest 2.
Zone de Conservez la valeur par défaut Aucune.

disponibilité
Délai d’inactivité Entrez 10.

(minutes)
4. Sélectionnez l’onglet IP sortante ou Suivant : IP sortante en bas de la page.
5. Dans Adresses IP publiques sous l’onglet IP sortante, sélectionnez l’adresse IP

affichée dans le champ Adresses IP publiques de la section précédente. Dans cet
exemple, il s’agit de myPublicIP.
6. Sélectionnez l’onglet Sous-réseau ou Suivant : Sous-réseau en bas de la page.
7. Dans la zone déroulante Réseau virtuel, sélectionnez votre réseau virtuel.
8. Dans Nom du sous-réseau, cochez la case en regard de votre sous-réseau. Dans

cet exemple, il s’agit de default.
9. Sélectionnez l’onglet Vérifier + créer ou sélectionnez Vérifier + créer en bas de la

page.

Si vous ne comptez pas continuer à utiliser cette application, supprimez la passerelle
NAT en effectuant les étapes suivantes :
1. Dans le menu de gauche, sélectionnez Groupes de ressources.
2. Sélectionnez le groupe de ressources myResourceGroup.
4. Entrez myResourceGroup, puis sélectionnez Supprimer.
Étapes suivantes
Dans cet article, vous avez appris à effectuer les opérations suivantes :
Supprimer une adresse IP publique d’une machine virtuelle.
Créez une passerelle NAT et utilisez l’adresse IP publique de la machine virtuelle

pour la ressource de passerelle NAT.
Toute machine virtuelle créée dans ce sous-réseau n'aura pas besoin d'une adresse IP
publique et disposera automatiquement d’une connectivité sortante. Pour plus
d’informations sur la passerelle NAT et les avantages de connectivité qu’elle offre,
consultez Concevoir des réseaux virtuels avec une passerelle NAT.
Passez à l'article suivant pour apprendre à migrer l'accès sortant par défaut vers
Passerelle NAT Azure :
Migrer l’accès sortant vers une passerelle NAT

Ajouter ou supprimer des interfaces
réseau pour des machines virtuelles
Article • 11/05/2023
Découvrez comment ajouter une interface réseau existante quand vous créez une
machine virtuelle Azure, Découvrez également comment ajouter ou supprimer des
interfaces réseau d’une machine virtuelle existante à l’état arrêté (libéré). Une interface
réseau permet à une machine virtuelle Azure de communiquer avec des ressources sur
Internet, sur Azure et locales. Une machine virtuelle a une ou plusieurs interfaces réseau.
Si vous devez ajouter, changer ou supprimer des adresses IP pour une interface réseau,
consultez Configurer des adresses IP pour une interface réseau Azure. Pour gérer les
interfaces réseau, consultez Créer, changer ou supprimer une interface réseau.
Prérequis
Si vous n’en avez pas, configurez un compte Azure avec un abonnement actif. Créez un
compte gratuitement . Effectuez une des tâches suivantes avant de commencer les
étapes décrites dans la suite de cet article :

Azure.


rechercher la version installée. Si vous devez effectuer une mise à niveau, consultez
connecter à Azure.
exécuter les étapes de cet article. Sous l’onglet de navigateur Azure Cloud Shell,
ouvrez la liste déroulante Sélectionner un environnement, puis choisissez Bash si
ce n’est pas déjà fait.
créer une connexion avec Azure.
Ajouter des interfaces réseau existantes à une

nouvelle machine virtuelle
Quand vous créez une machine virtuelle par le biais du portail, celui-ci crée une interface
réseau avec des paramètres par défaut et l’attache à la machine virtuelle pour vous.
Vous ne pouvez pas utiliser le portail pour ajouter des interfaces réseau existantes à une
nouvelle machine virtuelle, ni pour créer une machine virtuelle avec plusieurs interfaces
réseau. Vous pouvez en revanche effectuer ces deux opérations à l’aide de l’interface de
ligne de commande ou de PowerShell. Veillez à vous familiariser avec les contraintes. Si
vous créez une machine virtuelle avec plusieurs interfaces réseau, vous devez également
configurer le système d’exploitation pour les utiliser correctement une fois la machine
virtuelle créée. Découvrez comment configurer Linux ou Windows pour plusieurs
interfaces réseau.
Commandes
Avant de créer la machine virtuelle, créez une interface réseau.
Outil Commande
Interface de ligne de commande az vm create. Consultez l’exemple
PowerShell New-AzNetworkInterface et New-AzVM. Consultez l’exemple
Ajouter une interface réseau à une machine

virtuelle existante
Pour ajouter une interface réseau à votre machine virtuelle
1. Accédez au portail Azure pour trouver une machine virtuelle existante.

Recherchez et sélectionnez Machines virtuelles.
2. Sélectionnez le nom de votre machine virtuelle. La machine virtuelle doit prendre
en charge le nombre d’interfaces réseau que vous souhaitez ajouter. Pour
connaître le nombre d’interfaces réseau prises en charge par chaque taille de
machine virtuelle, consultez Tailles des machines virtuelles dans Azure.
3. Dans la page Vue d’ensemble de la machine virtuelle, sélectionnez Arrêter, puis

Oui. Ensuite, attendez que la zone État de la machine virtuelle passe à Arrêté
(désalloué) .
4. Sélectionnez Réseau>Attacher l’interface réseau. Dans Attacher l’interface réseau

existante, sélectionnez ensuite l’interface réseau à rattacher, puis sélectionnez OK.
７ Notes
L’interface réseau que vous sélectionnez doit exister dans le même réseau
virtuel que l’interface réseau attachée à la machine virtuelle.
Si vous ne disposez pas d’une interface réseau existante, vous devez d’abord en
créer une. Pour ce faire, sélectionnez Créer une interface réseau. Pour plus
d’informations sur la création d’une interface réseau, consultez Créer une interface
réseau. Pour plus d’informations sur les contraintes supplémentaires qui
s’appliquent à l’ajout d’interfaces réseau à des machines virtuelles, consultez
Contraintes.
5. Sélectionnez Vue d’ensemble>Démarrer pour démarrer la machine virtuelle.

Vous pouvez maintenant configurer le système d’exploitation de la machine virtuelle de
façon à utiliser correctement plusieurs interfaces réseau. Découvrez comment configurer
Linux ou Windows pour plusieurs interfaces réseau.
Commandes
Outil Commande
Interface de ligne de commande az vm nic add. Consultez l’exemple
PowerShell Add-AzVMNetworkInterface. Consultez l’exemple
Afficher les interfaces réseau d’une machine

virtuelle
Vous pouvez afficher les interfaces réseau actuellement attachées à une machine
virtuelle pour découvrir la configuration de chaque interface réseau et l’adresse IP qui lui
est attribuée.

７ Notes
Connectez-vous à l’aide d’un compte disposant des autorisations associées au

rôle Propriétaire, Collaborateur ou Collaborateur de réseau pour votre
abonnement. Pour en savoir plus sur l’attribution de rôles à des comptes,
consultez Rôles intégrés pour le contrôle d’accès en fonction du rôle Azure.
2. Sélectionnez le nom de la machine virtuelle pour laquelle vous voulez afficher les
interfaces réseau attachées.
3. Sélectionnez Réseau pour voir les interfaces réseau attachées à la machine

virtuelle. Sélectionnez une interface réseau pour voir sa configuration
Pour plus d’informations sur les paramètres d’interface réseau et leur modification,
consultez Gérer les interfaces réseau. Pour savoir comment ajouter, modifier ou
supprimer des adresses IP pour une interface réseau, consultez la section sur la gestion
des adresses IP des interfaces réseau.
Commandes
Outil Commande
Interface de ligne de commande az vm nic list
PowerShell Get-AzVM
Supprimer une interface réseau d’une machine

virtuelle
2. Sélectionnez le nom de la machine virtuelle dont vous souhaitez supprimer les

interfaces réseau attachées.
3. Sélectionnez Arrêter.
4. Attendez que la zone État de la machine virtuelle passe à Arrêté (désalloué) .
5. Sélectionnez Réseau>Détacher l’interface réseau.
6. Dans Détacher l’interface réseau, sélectionnez l’interface réseau à détacher.

Sélectionnez ensuite OK.
７ Notes
S’il n’y a qu’une seule interface réseau, vous ne pouvez pas la détacher, car
une machine virtuelle doit toujours avoir au moins une interface réseau
attachée.
Commandes
Outil Commande
Interface de ligne de commande az vm nic remove. Consultez l’exemple
PowerShell Remove-AzVMNetworkInterface. Consultez l’exemple
Contraintes
Une machine virtuelle doit avoir au moins une interface réseau attachée.
Le nombre d’interfaces réseau d’une machine virtuelle est limité par ce que la taille
de machine virtuelle prend en charge. Pour en savoir plus sur le nombre
d’interfaces réseau prises en charge par chaque taille de machine virtuelle,
consultez Tailles des machines virtuelles dans Azure. Toutes les tailles prennent en
charge au moins deux interfaces réseau.
Actuellement, les interfaces réseau que vous ajoutez à une machine virtuelle ne
peuvent pas être attachées à une autre machine virtuelle. Pour plus d’informations
sur la création d’une interface réseau, consultez Créer une interface réseau.
Auparavant, vous pouviez ajouter des interfaces réseau uniquement aux machines
virtuelles prenant en charge plusieurs interfaces réseau et créées avec au moins
deux interfaces réseau. Vous ne pouviez pas ajouter une interface réseau à une
machine virtuelle créée avec une seule interface réseau, même si la taille de
machine virtuelle prenait en charge plusieurs interfaces réseau. À l’inverse, vous
pouviez uniquement supprimer des interfaces réseau à partir d’une machine
virtuelle comportant au moins trois interfaces réseau, car les machines virtuelles
créées avec au moins deux interfaces réseau devaient toujours avoir au moins deux
interfaces réseau. Ces contraintes ne s’appliquent plus. Vous pouvez désormais
créer des machines virtuelles avec un nombre quelconque d’interfaces réseau
(dans la limite du nombre pris en charge par la taille de machine virtuelle).
Par défaut, la première interface réseau attachée à une machine virtuelle est
l’interface réseau principale. Toutes les autres interfaces réseau de la machine
virtuelle sont des interfaces réseau secondaires.
Vous pouvez contrôler l’interface réseau vers laquelle vous envoyez le trafic
sortant. Toutefois, par défaut une machine virtuelle envoie tout le trafic sortant à
l’adresse IP affectée à la configuration IP principale de l’interface réseau principale.
Auparavant, toutes les machines virtuelles du même groupe à haute disponibilité

étaient requises pour une seule ou plusieurs interfaces réseau. Des machines
virtuelles comportant un nombre quelconque d’interfaces réseau peuvent
désormais exister dans le même groupe à haute disponibilité, pour autant que ce
nombre soit pris en charge par la taille de la machine virtuelle. Vous ne pouvez
ajouter une machine virtuelle à un groupe à haute disponibilité qu’au moment de
la création de celui-ci. Pour en savoir plus sur les groupes à haute disponibilité,
consultez Options de disponibilité pour machines virtuelles Azure.
Vous pouvez connecter des interfaces réseau dans la même machine virtuelle à
différents sous-réseaux au sein d’un réseau virtuel. Toutefois, les interfaces réseau
doivent toutes être connectées au même réseau virtuel.
Vous pouvez ajouter n’importe quelle adresse IP pour n’importe quelle

configuration IP d’une interface réseau principale ou secondaire à un pool principal
Azure Load Balancer. Auparavant, seule l’adresse IP principale de l’interface réseau
principale pouvait être ajoutée à un pool principal. Pour en savoir plus sur les
adresses IP et les configurations, consultez Configurer des adresses IP pour une
interface réseau Azure.
La suppression d’une machine virtuelle n’a pas pour effet de supprimer les
interfaces réseau qui y sont attachées. Lorsque vous supprimez une machine
virtuelle, les interfaces réseau sont détachées de la machine virtuelle. Vous pouvez
attacher ces interfaces réseau à différentes machines virtuelles, ou les supprimer.
Pour obtenir des performances optimales, vous devez disposer d’une mise en
réseau accélérée. Dans certains cas, vous devez activer explicitement la mise en
réseau accélérée pour les machines virtuelles Windows ou Linux.
７ Notes
Étapes suivantes
Pour créer une machine virtuelle avec plusieurs interfaces réseau ou adresses IP,
consultez :
Tâche Outil
Créer une machine virtuelle avec plusieurs cartes d’interface CLI, PowerShell
réseau
Créer une machine virtuelle à carte réseau unique avec plusieurs CLI, PowerShell
adresses IPv4
Créer une machine virtuelle à carte réseau unique avec une CLI, PowerShell, modèle
adresse IPv6 privée (derrière Azure Load Balancer) Azure Resource Manager
Créer et gérer une machine virtuelle
Windows équipée de plusieurs cartes
Article • 01/06/2023
S’applique à : ✔️Machines virtuelles Windows ✔️Groupes identiques flexibles
Les machines virtuelles (VM) dans Azure peuvent être équipées de plusieurs cartes
d’interface réseau (NIC) virtuelles. Un scénario courant consiste à disposer de sous-
réseaux différents pour les connectivités frontale et principale. Vous pouvez associer
plusieurs cartes d’interface réseau d’une machine virtuelle à différents sous-réseaux,
mais ces sous-réseaux doivent tous résider dans le même réseau virtuel. Cet article
explique comment créer une machine virtuelle équipée de plusieurs cartes d’interface
réseau. Il explique également comment ajouter ou supprimer des cartes d’interface
réseau d’une machine virtuelle existante. Comme le nombre de cartes réseau prises en
charge varie suivant la taille des machines virtuelles , pensez à dimensionner la vôtre en
conséquence.
７ Notes
Si plusieurs sous-réseaux ne sont pas requis pour un scénario, il peut être plus
simple d’utiliser plusieurs configurations IP sur une seule carte réseau. Vous
trouverez des instructions pour cette configuration ici.
Prérequis
Dans les exemples suivants, remplacez les exemples de noms de paramètre par vos
propres valeurs. Les noms de paramètre sont par exemple myResourceGroup, myVnet et
myVM.
Créer une machine virtuelle avec plusieurs

cartes d’interface réseau
Créez d’abord un groupe de ressources. L’exemple suivant crée un groupe de ressources
nommé myResourceGroup à l’emplacement EastUs:
PowerShell
New-AzResourceGroup -Name "myResourceGroup" -Location "EastUS"
Créer un réseau virtuel et des sous-réseaux

Un scénario courant pour un réseau virtuel consiste à avoir deux sous-réseaux ou plus.
Un sous-réseau peut être dédié au trafic frontal, et l’autre au trafic principal. Pour
connecter les deux sous-réseaux, vous utilisez ensuite plusieurs cartes d’interface réseau
sur votre machine virtuelle.
1. Définissez deux sous-réseaux de réseau virtuel avec la commande New-

AzVirtualNetworkSubnetConfig. L’exemple suivant définit les sous-réseaux pour
mySubnetFrontEnd et mySubnetBackEnd :
PowerShell
$mySubnetFrontEnd = New-AzVirtualNetworkSubnetConfig -Name

"mySubnetFrontEnd" `
-AddressPrefix "192.168.1.0/24"
$mySubnetBackEnd = New-AzVirtualNetworkSubnetConfig -Name
"mySubnetBackEnd" `
-AddressPrefix "192.168.2.0/24"
2. Créez votre réseau virtuel et vos sous-réseaux avec la commande New-

AzVirtualNetwork. L’exemple suivant crée un réseau virtuel nommé myVnet :
PowerShell
$myVnet = New-AzVirtualNetwork -ResourceGroupName "myResourceGroup" `

-Location "EastUs" `
-Name "myVnet" `
-AddressPrefix "192.168.0.0/16" `
-Subnet $mySubnetFrontEnd,$mySubnetBackEnd
Créer plusieurs cartes réseau

Créez deux cartes d’interface réseau avec la commande New-AzNetworkInterface.
Associez une carte d’interface réseau au sous-réseau frontal et l’autre au sous-réseau
principal. L’exemple suivant crée des cartes d’interface réseau nommées myNic1 et
myNic2 :
PowerShell
$frontEnd = $myVnet.Subnets|?{$_.Name -eq 'mySubnetFrontEnd'}

$myNic1 = New-AzNetworkInterface -ResourceGroupName "myResourceGroup" `
-Name "myNic1" `
-SubnetId $frontEnd.Id
$backEnd = $myVnet.Subnets|?{$_.Name -eq 'mySubnetBackEnd'}

-Name "myNic2" `
-SubnetId $backEnd.Id
En général, vous créez également un groupe de sécurité réseau pour filtrer le trafic vers
la machine virtuelle, ainsi qu’un équilibreur de charge pour répartir le trafic entre
plusieurs machines virtuelles.
Créer la machine virtuelle

Maintenant, commencez à élaborer la configuration de votre machine virtuelle. La taille
d’une machine virtuelle détermine le nombre maximal de cartes réseau qu’elle peut
accueillir. Pour plus d’informations, voir Tailles des machines virtuelles Windows.
1. Tout d’abord, définissez les informations d’identification de votre machine virtuelle

sur la variable $cred comme suit :
PowerShell
2. Définissez votre machine virtuelle avec la commande New-AzVMConfig. L’exemple

suivant définit une machine virtuelle nommée myVM et utilise une taille de
machine virtuelle qui prend en charge plus de deux cartes d’interface réseau
(Standard_DS3_v2) :
PowerShell
$vmConfig = New-AzVMConfig -VMName "myVM" -VMSize "Standard_DS3_v2"
3. Créez le reste de la configuration de votre machine virtuelle avec les commandes

Set-AzVMOperatingSystem et Set-AzVMSourceImage. L’exemple suivant crée une
machine virtuelle Windows Server 2016 R2 :
PowerShell
$vmConfig = Set-AzVMOperatingSystem -VM $vmConfig `

-Windows `
-ComputerName "myVM" `
-Credential $cred `
-ProvisionVMAgent `
-EnableAutoUpdate
$vmConfig = Set-AzVMSourceImage -VM $vmConfig `
-PublisherName "MicrosoftWindowsServer" `
-Offer "WindowsServer" `
-Skus "2016-Datacenter" `
-Version "latest"
4. Associez les deux cartes d’interface réseau que vous avez créées précédemment à
l’aide de la commande Add-AzVMNetworkInterface :
PowerShell
$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $myNic1.Id -

Primary
$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $myNic2.Id
5. Créez votre machine virtuelle avec New-AzVM :
PowerShell
New-AzVM -VM $vmConfig -ResourceGroupName "myResourceGroup" -Location

"EastUs"
6. Ajoutez des itinéraires pour les cartes réseau secondaires au système d’exploitation
en suivant les étapes décrites dans Configurer le système d’exploitation pour
plusieurs cartes réseau.
Ajouter une carte réseau à une machine

virtuelle existante
Pour ajouter une carte d’interface réseau virtuelle à une machine virtuelle existante,
désallouez la machine virtuelle, ajoutez la carte d’interface réseau virtuelle, puis
démarrez la machine virtuelle. Comme le nombre de cartes réseau prises en charge varie
suivant la taille des machines virtuelles , pensez à dimensionner la vôtre en
conséquence. Si nécessaire, vous pouvez redimensionner une machine virtuelle.
1. Libérez la machine virtuelle avec la commande Stop-AzVM. L’exemple suivant

désalloue la machine virtuelle nommée myVM dans myResourceGroup:
PowerShell
Stop-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"

2. Obtenez la configuration existante de la machine virtuelle avec commande Get-
AzVm. L’exemple suivant récupère des informations sur la machine virtuelle
nommée myVM dans myResourceGroup :
PowerShell
$vm = Get-AzVm -Name "myVM" -ResourceGroupName "myResourceGroup"
3. L’exemple suivant crée une carte d’interface réseau virtuelle avec la commande
New-AzNetworkInterface, nommée myNic3, et associée à mySubnetBackEnd. La
carte d’interface réseau virtuelle est ensuite associée à la machine virtuelle
nommée myVM dans myResourceGroup avec la commande Add-
AzVMNetworkInterface :
PowerShell
# Get info for the back end subnet

$myVnet = Get-AzVirtualNetwork -Name "myVnet" -ResourceGroupName
"myResourceGroup"
$backEnd = $myVnet.Subnets|?{$_.Name -eq 'mySubnetBackEnd'}
# Create a virtual NIC

-Name "myNic3" `
-SubnetId $backEnd.Id
# Get the ID of the new virtual NIC and add to VM

$nicId = (Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" -
Name "MyNic3").Id
Add-AzVMNetworkInterface -VM $vm -Id $nicId | Update-AzVm -
ResourceGroupName "myResourceGroup"
Cartes d’interface réseau virtuelles principales

L’une des cartes d’interface réseau sur une machine virtuelle dotées de plusieurs
cartes doit être la carte principale. Si l’une des cartes d’interface réseau virtuelles
existantes sur la machine virtuelle est déjà définie comme principale, vous pouvez
ignorer cette étape. L’exemple suivant suppose que deux cartes d’interface réseau
virtuelles sont désormais présentes sur une machine virtuelle, et que vous
souhaitez ajouter la première carte d’interface réseau ( [0] ) en tant que carte
principale :
PowerShell
# List existing NICs on the VM and find which one is primary
$vm.NetworkProfile.NetworkInterfaces
# Set NIC 0 to be primary

$vm.NetworkProfile.NetworkInterfaces[0].Primary = $true
$vm.NetworkProfile.NetworkInterfaces[1].Primary = $false
# Update the VM state in Azure

Update-AzVM -VM $vm -ResourceGroupName "myResourceGroup"
4. Démarrez la machine virtuelle avec la commande Start-AzVm :
PowerShell
Start-AzVM -ResourceGroupName "myResourceGroup" -Name "myVM"
5. Ajoutez des itinéraires pour les cartes réseau secondaires au système d’exploitation
en suivant les étapes décrites dans Configurer le système d’exploitation pour
plusieurs cartes réseau.
Supprimer une carte réseau d’une machine

virtuelle existante
Pour supprimer une carte d’interface réseau virtuelle à partir d’une machine virtuelle
existante, désallouez la machine virtuelle, supprimez la carte d’interface réseau virtuelle,
puis démarrez la machine virtuelle.
1. Libérez la machine virtuelle avec la commande Stop-AzVM. L’exemple suivant

désalloue la machine virtuelle nommée myVM dans myResourceGroup:
PowerShell
Stop-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"
2. Obtenez la configuration existante de la machine virtuelle avec commande Get-

AzVm. L’exemple suivant récupère des informations sur la machine virtuelle
nommée myVM dans myResourceGroup :
PowerShell
$vm = Get-AzVm -Name "myVM" -ResourceGroupName "myResourceGroup"

3. Obtenez des informations sur la suppression de la carte d’interface réseau avec la
commande Get-AzNetworkInterface. L’exemple suivant obtient des informations
sur la carte myNic3 :
PowerShell
# List existing NICs on the VM if you need to determine NIC name

$vm.NetworkProfile.NetworkInterfaces
$nicId = (Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" -

Name "myNic3").Id
4. Supprimez la carte d’interface réseau avec la commande Remove-

AzVMNetworkInterface, puis mettez à jour la machine virtuelle avec la commande
Update-AzVm. L’exemple suivant supprime la carte myNic3 obtenue par $nicId à
l’étape précédente :
PowerShell
Remove-AzVMNetworkInterface -VM $vm -NetworkInterfaceIDs $nicId | `

Update-AzVm -ResourceGroupName "myResourceGroup"
5. Démarrez la machine virtuelle avec la commande Start-AzVm :
PowerShell
Start-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"
Créer plusieurs cartes d’interface réseau avec

des modèles
Grâce aux modèles Azure Resource Manager, vous pouvez créer plusieurs instances
d’une ressource pendant le déploiement, à l’image de la création de plusieurs cartes
d’interface réseau. Les modèles Resource Manager utilisent des fichiers JSON déclaratifs
pour définir votre environnement. Pour plus d’informations, voir Présentation d’Azure
Resource Manager. Vous pouvez utiliser la commande copy pour spécifier le nombre
d’instances à :
JSON
"copy": {
"name": "multiplenics",
"count": "[parameters('count')]"
}
Pour plus d’informations, voir Création de plusieurs instances à l’aide de la commande

copie.
Vous pouvez également utiliser la commande copyIndex() pour ajouter un numéro à un

nom de ressource. Vous pouvez ensuite créer les cartes myNic1, MyNic2 et ainsi de suite.
Voici un exemple de code pour l’ajout de la valeur d’index :
JSON
"name": "[concat('myNic', copyIndex())]",
Vous pouvez consulter un exemple complet de la création de plusieurs cartes d’interface

réseau à l’aide de modèles Resource Manager.
Ajoutez des itinéraires pour les cartes réseau secondaires au système d’exploitation en
suivant les étapes décrites dans Configurer le système d’exploitation pour plusieurs
cartes réseau.
Configurer plusieurs cartes réseau dans un

système d’exploitation invité
Azure affecte une passerelle par défaut aux premières (principales) interfaces réseau
associées à la machine virtuelle. Azure n’affecte pas de passerelle par défaut aux
interfaces réseau additionnelles (secondaires) associées à la machine virtuelle. Par
conséquent, vous ne pouvez pas communiquer avec les ressources hors du sous-réseau
dans lequel se trouve, par défaut, une interface réseau secondaire. Toutefois, les
interfaces réseau secondaires peuvent communiquer avec les ressources hors de leur
sous-réseau. Ceci dit, les étapes à suivre pour permettre cette communication sont
différentes d’un système d’exploitation à un autre.
1. Dans une invite de commande Windows, exécutez la commande route print , qui
retourne une sortie similaire à la sortie suivante d’une machine virtuelle à deux
interfaces réseau :
=======================================================================
====
Interface List
3...00 0d 3a 10 92 ce ......Microsoft Hyper-V Network Adapter #3
7...00 0d 3a 10 9b 2a ......Microsoft Hyper-V Network Adapter #4
=======================================================================
====
Dans cet exemple, Microsoft Hyper-V Network Adapter #4 (interface 7) est

l’interface réseau secondaire à laquelle aucune passerelle par défaut n’est assignée.
2. Depuis une invite de commande, exécutez la commande ipconfig pour voir quelle
adresse IP est assignée à l’interface réseau secondaire. Dans cet exemple, l’adresse
192.168.2.4 est assignée à l’interface 7. Aucune adresse de passerelle par défaut
n’est retournée pour l’interface réseau secondaire.
3. Pour acheminer le trafic destiné aux adresses hors du sous-réseau de l’interface

réseau secondaire vers la passerelle du sous-réseau, exécutez la commande
suivante :
route add -p 0.0.0.0 MASK 0.0.0.0 192.168.2.1 METRIC 5015 IF 7
L’adresse de la passerelle du sous-réseau est la première adresse IP (celle qui finit

par .1) dans la plage d’adresse définie pour le sous-réseau. Si vous ne voulez pas
acheminer le trafic hors du sous-réseau, vous avez la possibilité d’ajouter des
itinéraires individuels vers des destinations spécifiques. Par exemple, si vous voulez
acheminer le trafic de l’interface réseau secondaire vers le réseau 192.168.3.0
uniquement, entrez la commande :
route add -p 192.168.3.0 MASK 255.255.255.0 192.168.2.1 METRIC 5015 IF

7
4. Pour vérifier si la communication fonctionne avec une ressource du réseau

192.168.3.0, par exemple, entrez la commande suivante pour faire un test Ping de
l’adresse 192.168.3.4 à l’aide de l’interface 7 (192.168.2.4) :
ping 192.168.3.4 -S 192.168.2.4
Vous devrez peut-être ouvrir le protocole ICMP via le pare-feu Windows de

l’appareil sur lequel vous effectuez le test Ping. Exécutez cette commande :
netsh advfirewall firewall add rule name=Allow-ping protocol=icmpv4
dir=in action=allow
5. Pour confirmer que l’itinéraire ajouté se trouve dans la table de routage, entrez la
commande route print , qui retourne une sortie similaire à ce qui suit :
=======================================================================
====
Active Routes:
Network Destination Netmask Gateway Interface
Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.4
15
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.4
5015
L’itinéraire répertorié avec l’adresse 192.168.1.1 sous Passerelle représente

l’itinéraire se trouvant là par défaut pour l’interface réseau principale. L’itinéraire
avec l’adresse 192.168.2.1 sous Passerelle représente l’itinéraire que vous avez
ajouté.
Étapes suivantes
Réviser les Tailles des machines virtuelles Windows lorsque vous tentez de créer une
machine virtuelle équipée de plusieurs cartes d’interface réseau. Faites attention au
nombre maximal de cartes d’interface réseau pris en charge par chaque taille de
machine virtuelle.
Guide de création d’une machine
virtuelle Linux dans Azure avec plusieurs
cartes d’interface réseau
Article • 01/06/2023
S’applique à : ✔️Machines virtuelles Linux ✔️Groupes identiques flexibles
Cet article explique comment créer une machine virtuelle avec plusieurs cartes réseau à
l’aide de l’interface Azure CLI.
Créer des ressources de support

Installez la dernière version d’Azure CLI et connectez-vous à un compte Azure avec
az login.
Dans les exemples suivants, remplacez les exemples de noms de paramètre par vos
propres valeurs. Les noms de paramètre sont par exemple myResourceGroup,
mystorageaccount et myVM.
Tout d’abord, 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 :
Azure CLI
az group create --name myResourceGroup --location eastus
Créez le réseau virtuel avec la commande az network vnet create. L’exemple suivant
permet de créer un réseau virtuel nommé myVnet et un sous-réseau nommé
mySubnetFrontEnd :
Azure CLI

--name myVnet \
--subnet-name mySubnetFrontEnd \
Créez un sous-réseau pour le trafic principal avec la commande az network vnet subnet
create. L’exemple suivant permet de créer un sous-réseau nommé mySubnetBackEnd :
Azure CLI

--vnet-name myVnet \
--name mySubnetBackEnd \
suivant crée un groupe de sécurité réseau nommé myNetworkSecurityGroup :
Azure CLI

--name myNetworkSecurityGroup
Créer et configurer plusieurs cartes réseau

Créez deux cartes réseau avec la commande az network nic create. L’exemple suivant
crée deux cartes réseau, nommées myNic1 et myNic2, connectées au groupe de sécurité
réseau et avec une carte réseau se connectant à chaque sous-réseau :
Azure CLI
az network nic create \

--name myNic1 \
--subnet mySubnetFrontEnd \
--network-security-group myNetworkSecurityGroup
--name myNic2 \
--subnet mySubnetBackEnd \
Créer une machine virtuelle et attacher les

cartes réseau
Lorsque vous créez la machine virtuelle, spécifiez les cartes réseau que vous avez créées
avec --nics . Vous devez également faire attention en définissant la taille de la machine
virtuelle. Il existe des limites pour le nombre maximal de cartes réseau que vous pouvez
ajouter à une machine virtuelle. En savoir plus sur les tailles des machines virtuelles
Linux.
machine virtuelle nommée myVM :
Azure CLI
az vm create \
--name myVM \
--image UbuntuLTS \
--size Standard_DS3_v2 \
--generate-ssh-keys \
--nics myNic1 myNic2
Ajoutez des tables de routage au SE invité en suivant la procédure décrite dans

Configurer plusieurs cartes réseau dans un système d’exploitation invité.
Ajout d’une carte réseau à une machine

virtuelle existante
Les étapes précédentes ont permis de créer une machine virtuelle avec plusieurs cartes
réseau. Vous pouvez également ajouter des cartes réseau à une machine virtuelle
existante avec l’interface Azure CLI. Comme le nombre de cartes réseau prises en charge
varie suivant la taille des machines virtuelles , pensez à dimensionner la vôtre en
conséquence. Si nécessaire, vous pouvez redimensionner une machine virtuelle.
Créez une autre carte réseau avec az network nic create. L’exemple suivant crée une
carte réseau nommée myNic3 connectée au sous-réseau principal et au groupe de
sécurité réseau créés lors des étapes précédentes :
Azure CLI

--name myNic3 \
--subnet mySubnetBackEnd \
Pour ajouter une carte réseau à une machine virtuelle existante, libérez d’abord la
machine virtuelle avec az vm deallocate. L’exemple suivant libère la machine virtuelle
nommée myVM :
Azure CLI
az vm deallocate --resource-group myResourceGroup --name myVM
Ajoutez la carte réseau avec az vm nic add. L’exemple suivant ajoute myNic3 à myVM :
Azure CLI
az vm nic add \
--vm-name myVM \
--nics myNic3
Démarrez la machine virtuelle avec az vm start :
Azure CLI
az vm start --resource-group myResourceGroup --name myVM

Suppression d’une carte réseau d’une machine

virtuelle
Pour supprimer une carte réseau d’une machine virtuelle existante, libérez d’abord la
machine virtuelle avec az vm deallocate. L’exemple suivant libère la machine virtuelle
nommée myVM :
Azure CLI
az vm deallocate --resource-group myResourceGroup --name myVM
Supprimez la carte réseau avec az vm nic remove. L’exemple suivant supprime myNic3
de myVM :
Azure CLI
az vm nic remove \
--vm-name myVM \
--nics myNic3
Démarrez la machine virtuelle avec az vm start :
Azure CLI
az vm start --resource-group myResourceGroup --name myVM
Créer plusieurs cartes réseau à l’aide de

modèles Resource Manager
Les modèles Azure Resource Manager utilisent des fichiers JSON déclaratifs pour définir
votre environnement. Vous pouvez consulter une vue d’ensemble d’Azure Resource
Manager. Grâce aux modèles Resource Manager, vous pouvez créer plusieurs instances
d’une ressource pendant le déploiement, à l’image de la création de plusieurs cartes
réseau. Utilisez copy pour spécifier le nombre d’instances à créer :
JSON
"copy": {
"name": "multiplenics"
"count": "[parameters('count')]"
}
En savoir plus sur la création de plusieurs instances à l’aide de copy.
Vous pouvez également utiliser copyIndex() pour ajouter ensuite un numéro à un nom
de ressource permettant de créer myNic1 , myNic2 , etc. Voici un exemple d’ajout de la
valeur d’index :
JSON
"name": "[concat('myNic', copyIndex())]",
Vous pouvez consulter un exemple complet de la création de plusieurs cartes réseau à

l’aide de modèles Resource Manager.

Configurer plusieurs cartes réseau dans un
système d’exploitation invité
Les étapes précédentes ont permis de créer un réseau virtuel et un sous-réseau, de
joindre des cartes réseau, puis de créer une machine virtuelle. Aucune adresse IP
publique ni règle de groupe de sécurité réseau qui autorise le trafic SSH n’a été créée.
Afin de configurer le système d’exploitation invité pour plusieurs cartes réseau, vous
devez autoriser les connexions à distance et exécuter les commandes localement sur la
machine virtuelle.
Pour autoriser le trafic SSH, créez une règle de groupe de sécurité réseau avec az
network nsg rule create comme suit :
Azure CLI

--nsg-name myNetworkSecurityGroup \
--name allow_ssh \
--priority 101 \
--destination-port-ranges 22
Créez une adresse IP publique avec az network public-ip create et affectez-la à la

première carte réseau avec az network nic ip-config update :
Azure CLI
az network public-ip create --resource-group myResourceGroup --name

myPublicIP
az network nic ip-config update \

--nic-name myNic1 \
--name ipconfig1 \
--public-ip myPublicIP
Pour voir l’adresse IP publique de la machine virtuelle, utilisez az vm show comme suit :
Azure CLI
az vm show --resource-group myResourceGroup --name myVM -d --query publicIps

-o tsv
Établissez maintenant la connexion SSH à l’adresse IP publique de votre machine

virtuelle. Le nom d’utilisateur par défaut fourni lors d’une étape précédente était
azureuser. Indiquez vos propres nom d’utilisateur et adresse IP publique :
Bash
ssh azureuser@137.117.58.232
Pour effectuer un envoi vers ou depuis une interface réseau secondaire, vous devez
ajouter manuellement des itinéraires persistants au système d’exploitation pour chaque
interface réseau secondaire. Dans cet article, eth1 représente l’interface secondaire. Les
instructions pour l’ajout d’itinéraires persistants au système d’exploitation varient selon
la distribution. Consultez la documentation de votre distribution pour obtenir des
instructions.
Lors de l’ajout de l’itinéraire au système d’exploitation, l’adresse de la passerelle est la

première adresse du sous-réseau dans lequel se trouve l’interface réseau. Par exemple, si
la plage 10.0.2.0/24est attribuée au sous-réseau, la passerelle que vous spécifiez pour
l’itinéraire est 10.0.2.1. De même, si la plage 10.0.2.128/25a été attribuée au sous-réseau,
la passerelle que vous spécifiez pour l’itinéraire est 10.0.2.129. Vous pouvez définir un
réseau spécifique pour la destination de l’itinéraire ou spécifier la destination 0.0.0.0 si
vous voulez que tout le trafic pour l’interface passe par la passerelle spécifiée. La
passerelle pour chaque sous-réseau est gérée par le réseau virtuel.
Une fois que vous avez ajouté l’itinéraire pour une interface secondaire, vérifiez que
l’itinéraire est dans votre table de routage avec route -n . L’exemple de sortie suivant
concerne la table de routage qui contient les deux interfaces réseau ajoutées à la
machine virtuelle dans cet article :
Bash
Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use
Iface
0.0.0.0 10.0.1.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 10.0.2.1 0.0.0.0 UG 0 0 0 eth1
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
168.63.129.16 10.0.1.1 255.255.255.255 UGH 0 0 0 eth0
169.254.169.254 10.0.1.1 255.255.255.255 UGH 0 0 0 eth0
Confirmez que l’itinéraire que vous avez ajouté est conservé entre les redémarrages en
vérifiant à nouveau votre table de routage après un redémarrage. Pour tester la
connectivité, vous pouvez par exemple entrer la commande suivante, où eth1 est le nom
d’une interface réseau secondaire :
Bash
ping bing.com -c 4 -I eth1
Étapes suivantes
Vérifiez les tailles des machines virtuelles Linux si vous créez une machine virtuelle avec
plusieurs cartes réseau. Faites attention au nombre maximal de cartes réseau pris en
charge par chaque taille de machine virtuelle.
Pour sécuriser davantage vos machines virtuelles, utilisez l’accès aux machines virtuelles
juste-à-temps. Cette fonctionnalité ouvre les règles de groupe de sécurité réseau pour le
trafic SSH en cas de besoin et pour une période de temps définie. Pour plus
d’informations, consultez Gérer l’accès Juste à temps à la machine virtuelle.
Vue d’ensemble de Performances réseau
accélérées (AccelNet)
Article • 02/06/2023
Cet article explique Performances réseau accélérées et décrit ses avantages, ses
contraintes et ses configurations prises en charge. Performances réseau accélérées
active la virtualisation SR-IOV (Single Root I/O Virtualization) sur des types de machines
virtuelles pris en charge, ce qui améliore considérablement les performances réseau. Ce
chemin d’accès aux données hautement performant contourne l’hôte, ce qui réduit la
latence, l’instabilité et l’utilisation du processeur pour les charges de travail réseau les
plus exigeantes.
Le diagramme suivant illustre la façon dont deux machines virtuelles communiquent

avec et sans Performances réseau accélérées :
Sans Performances réseau accélérées, tout le trafic réseau en direction et en

provenance de la machine virtuelle doit transiter par l’hôte et le réseau virtuel. Le réseau
virtuel fournit toute application de stratégie au trafic. Les stratégies incluent les groupes
de sécurité réseau, les listes de contrôle d’accès, l’isolation et d’autres services virtualisés
réseau. Pour plus d’informations sur les commutateurs virtuels, consultez Commutateur
virtuel Hyper-V.
Avec Performances réseau accélérées, le trafic qui parvient à l’interface réseau (NIC) de
la machine virtuelle est directement transféré à celle-ci. Performances réseau accélérées
décharge toutes les stratégies réseau que le réseau virtuel applique, et les applique dans
le matériel. Étant donné que le matériel applique les stratégies, la NIC peut transférer le
trafic réseau directement à la machine virtuelle. La carte d’interface réseau ignore l’hôte
et le commutateur virtuel, alors qu’elle gère l’ensemble de la stratégie appliquée à
l’hôte.
Avantages
Performances réseau accélérées présente les avantages suivants :
Une latence plus faible et un plus grand nombre de paquets par seconde (pps).
Une suppression du réseau virtuel du chemin de données évite que les paquets liés
au traitement des stratégies séjournent sur l'hôte, ce qui augmente le nombre de
paquets que la machine virtuelle peut traiter.
Une instabilité réduite. Le temps de traitement du réseau virtuel dépend du

nombre de stratégie à appliquer et de la charge de travail du processeur qui
effectue le traitement. L’application de la stratégie de déchargement sur le matériel
supprime cette variabilité en livrant des paquets directement à la machine virtuelle.
Le déchargement supprime également la communication entre l’hôte et la
machine virtuelle, toutes les interruptions logicielles et tous les changements de
contexte.
Une utilisation réduite du processeur. en contournant le commutateur virtuel de

l'hôte, le processeur utilise moins de ressources pour traiter le trafic réseau.
Limitations et contraintes
Les avantages de Performances réseau accélérées s’appliquent uniquement à la
machine virtuelle qui l’active.
Pour obtenir de meilleurs résultats, vous devez activer Performances réseau

accélérées sur au moins deux machines virtuelles du même réseau virtuel Azure.
Cette fonctionnalité a un effet minimal sur la latence lorsque vous communiquez
sur plusieurs réseaux virtuels ou que vous vous connectez localement.
Vous ne pouvez pas activer Performances réseau accélérées dans une machine
virtuelle en cours d’exécution. Vous pouvez activer Performances réseau accélérées
sur une machine virtuelle prise en charge uniquement lorsque la machine virtuelle
est arrêtée et libérée.
Vous ne pouvez pas déployer de machines virtuelles (classiques) avec

Performances réseau accélérées via Azure Resource Manager.
Régions prises en charge

Performances réseau accélérées est disponible dans toutes les régions Azure globales et
Azure Government Cloud.
Systèmes d’exploitation pris en charge
Les versions suivantes de Windows prennent en charge Performances réseau
accélérées :
Windows Server 2022

Windows Server 2019 Standard ou Datacenter
Windows Server 2016 Standard ou Datacenter
Windows Server 2012 R2 Standard/Datacenter
Windows 10, version 21H2 ou ultérieure, y compris Windows 10 Entreprise
multisession
Windows 11, y compris Windows 11 Entreprise multisession
Les distributions Linux et FreeBSD suivantes à partir d’Azure Gallery prennent en charge
Performances réseau accélérées prêt à l’emploi :
Ubuntu 14.04 avec le noyau linux-azure

Ubuntu 16.04 ou version ultérieure
SLES12 SP3 ou version ultérieure
RHEL 7.4 ou version ultérieure
CentOS 7.4 ou version ultérieure
CoreOS Linux
Debian « Stretch » with backports kernel
Debian « Buster » ou une version ultérieure
Oracle Linux 7.4 et versions ultérieures avec Red Hat Compatible Kernel (RHCK)
Oracle Linux 7.5 et versions ultérieures avec UEK version 5
FreeBSD 10.4, 11.1 et 12.0 ou versions ultérieures
Instances de machines virtuelles prises en charge

La plupart des tailles d’instances de machines virtuelles d’usage général et
optimisées pour le calcul (avec deux processeurs virtuels ou plus) prennent en
charge Performances réseau accélérées. Dans des instances qui acceptent
l’hyperthreading, les instances de machines virtuelles comptant au minimum
quatre processeurs virtuels prennent en charge Performances réseau accélérées.
Pour vérifier si une taille de machine virtuelle prend en charge Performances

réseau accélérées, consultez Tailles des machines virtuelles dans Azure.
Vous pouvez interroger directement la liste des références SKU de machine

virtuelle qui prennent en charge Performances réseau accélérées à l’aide de la
commande Azure CLI az vm list-skus.
Azure CLI
az vm list-skus \
--location westus \
--all true \
--resource-type virtualMachines \
--query '[].{size:size, name:name, acceleratedNetworkingEnabled:
capabilities[?name==`AcceleratedNetworkingEnabled`].value | [0]}' \
--output table
７ Notes
Bien que les tailles NC et NV apparaissent dans la sortie de commande, ces

tailles ne prennent pas en charge Performances réseau accélérées. L’activation
de Performances réseau accélérées sur les machines virtuelles NC ou NV n’a
aucun effet.
Images de machine virtuelle personnalisées

Si vous utilisez une image personnalisée et qui prend en charge Performances réseau
accélérées, veillez à disposer des pilotes nécessaires compatibles avec les cartes réseau
ConnectX-3, ConnectX-4 Lx et ConnectX-5 de Mellanox sur Azure. Performances réseau
accélérées nécessite des configurations réseau qui dispensent d’une configuration des
fonctions virtuelles sur les pilotes mlx4_en et mlx5_core. Les images avec cloud-init
version 19.4 ou ultérieure ont un réseau correctement configuré pour prendre en charge
Performances réseau accélérées pendant l’approvisionnement.
RHEL, CentOS
L’exemple suivant montre un exemple de liste déroulante de configuration pour

NetworkManager sur RHEL ou CentOS :
Bash
sudo mkdir -p /etc/NetworkManager/conf.d

sudo cat /etc/NetworkManager/conf.d/99-azure-unmanaged-devices.conf
<<EOF
# Ignore SR-IOV interface on Azure, since it's transparently bonded
# to the synthetic interface
[keyfile]
unmanaged-devices=driver:mlx4_core;driver:mlx5_core
EOF
Étapes suivantes
Fonctionnement des performances réseau accélérées dans les machines virtuelles
Linux et FreeBSD
Créer une machine virtuelle Performances réseau accélérées à l’aide de PowerShell
Créer une machine virtuelle Performances réseau accélérées à l’aide d’Azure CLI
Groupes de placement de proximité
Utilisez Azure PowerShell pour créer une
machine virtuelle avec Performances
réseau accélérées
Cet article explique comment utiliser Azure PowerShell pour créer une machine virtuelle
Windows avec Performances réseau accélérées (AccelNet) activé. Il explique aussi
comment activer et gérer les performances réseau accélérées sur des machines virtuelles
existantes.
Vous pouvez aussi créer une machine virtuelle avec les performances réseau accélérées
activées à l’aide du portail Azure. Pour plus d’informations sur l’utilisation du portail
Azure pour gérer les performances réseau accélérées sur des machines virtuelles,
consultez la section Gérer les performances réseau accélérées dans le portail.
Pour utiliser Azure CLI pour créer une machine virtuelle Windows avec Performances
réseau accélérées activé, consultez l’article Créer une machine virtuelle dotée de
performances réseau accélérées à l’aide d’Azure CLI.
Prérequis
gratuitement .
Azure PowerShell version 1.0.0 ou une version ultérieure installée. Pour connaître la
version actuellement installée, exécutez Get-Module -ListAvailable Az . Si vous
devez installer ou mettre à niveau le module Az, installez la dernière version du
module à partir de PowerShell Gallery .
Dans PowerShell, connectez-vous à votre compte Azure à l’aide de Connect-

AzAccount.
Créer une machine virtuelle avec Performances

réseau accélérées activé
Dans les exemples suivants, vous pouvez remplacer les exemples de paramètres tels que
<myResourceGroup> , <myNic> et <myVm> par vos propres valeurs.
1. Utilisez la commande New-AzResourceGroup pour créer un groupe de ressources
destiné à contenir les ressources.
Azure PowerShell
New-AzResourceGroup -Name "<myResourceGroup>" -Location "

<myAzureRegion>"
2. Utilisez la commande New-AzVirtualNetworkSubnetConfig pour créer une

configuration de sous-réseau.
Azure PowerShell
$subnet = New-AzVirtualNetworkSubnetConfig `
-Name "<mySubnet>" `
-AddressPrefix "<192.168.1.0/24>"
3. Créez un réseau virtuel à l’aide de la commande New-AzVirtualNetwork avec un

sous-réseau.
Azure PowerShell
$vnet = New-AzVirtualNetwork -ResourceGroupName "<myResourceGroup>" `

-Location "<myAzureRegion>" `
-Name "<myVnet>" `
-AddressPrefix "<192.168.0.0/16>" `
-Subnet $Subnet

1. Un groupe de sécurité réseau (NSG) contient plusieurs règles par défaut, dont
l’une désactive tous les accès entrants à partir d’Internet. Utilisez la commande
New-AzNetworkSecurityRuleConfig pour créer une règle afin de pouvoir vous
connecter à distance à la machine virtuelle via le protocole RDP (Remote Desktop
Protocol).
Azure PowerShell
$rdp = New-AzNetworkSecurityRuleConfig `
-Name "Allow-RDP-All" `
-Description "Allow RDP" `
-Access Allow `
-Protocol Tcp `
-Priority 100 `
-DestinationAddressPrefix * `
-DestinationPortRange 3389
2. Utilisez la commande New-AzNetworkSecurityGroup pour créer le groupe de

sécurité réseau et affecter la règle Allow-RDP-All au NSG.
Azure PowerShell
-ResourceGroupName "<myResourceGroup>" `
-Name "<myNsg>" `
-SecurityRules $rdp
3. Utilisez la commande Set-AzVirtualNetworkSubnetConfig pour associer le NSG au

sous-réseau. Les règles NSG sont efficaces pour toutes les ressources déployées
dans le sous-réseau.
Azure PowerShell
-VirtualNetwork $vnet `
-Name "<mySubnet>" `
-AddressPrefix "<192.168.1.0/24>" `
Créer une interface réseau avec mise en réseau accélérée

1. Utilisez New-AzPublicIpAddress pour créer une adresse IP publique. La machine
virtuelle n’a pas besoin d’une adresse IP publique si vous n’y accédez pas à partir
d’Internet. Toutefois, vous avez besoin de l’adresse IP publique pour effectuer les
étapes de cet article.
Azure PowerShell
$publicIp = New-AzPublicIpAddress `
-Name "<myPublicIp>" `
-AllocationMethod Dynamic
2. Utilisez la commande New-AzNetworkInterface pour créer une interface réseau
(NIC) avec Performances réseau accélérées activé, et attribuez l’adresse IP publique
à la NIC.
Azure PowerShell
$nic = New-AzNetworkInterface `
-Name "<myNic>" `
-SubnetId $vnet.Subnets[0].Id `
-PublicIpAddressId $publicIp.Id `
-EnableAcceleratedNetworking
Créer une machine virtuelle et attacher l’interface réseau

1. Utilisez la commande Get-Credential pour définir un nom d’utilisateur et un mot
de passe pour la machine virtuelle et les stocker dans la variable $cred .
Azure PowerShell
2. Utilisez New-AzVMConfig pour définir une machine virtuelle avec une taille de
machine virtuelle qui prend en charge la mise en réseau accélérée, comme indiqué
dans Mise en réseau accélérée Windows . Pour obtenir la liste de toutes les tailles
de machine virtuelle Windows et leurs caractéristiques, consultez Tailles de
machines virtuelles Windows.
Azure PowerShell
$vmConfig = New-AzVMConfig -VMName "<myVm>" -VMSize "Standard_DS4_v2"
3. Utilisez les commandes Set-AzVMOperatingSystem et Set-AzVMSourceImage pour

créer le reste de la configuration de votre machine virtuelle. L’exemple suivant crée
une machine virtuelle Datacenter Windows Server 2019 R2 :
Azure PowerShell
$vmConfig = Set-AzVMOperatingSystem -VM $vmConfig `

-Windows `
-ComputerName "<myVM>" `
-Credential $cred `
-ProvisionVMAgent `
-EnableAutoUpdate
$vmConfig = Set-AzVMSourceImage -VM $vmConfig `
-PublisherName "MicrosoftWindowsServer" `
-Offer "WindowsServer" `
-Skus "2019-Datacenter" `
-Version "latest"
4. Utilisez la commande Add-AzVMNetworkInterface pour attacher à la machine

virtuelle la carte réseau précédemment créée.
Azure PowerShell
$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $nic.Id
5. Utilisez la commande New-AzVM pour créer la machine virtuelle avec

Performances réseau accélérées activé.
Azure PowerShell
New-AzVM -VM $vmConfig -ResourceGroupName "<myResourceGroup>" -Location

"<myAzureRegion>"
Confirmer que le contrôleur Ethernet est

installé
Une fois la machine virtuelle créée dans Azure, connectez-vous à cette dernière et
vérifiez que le contrôleur Ethernet est installé dans Windows.
2. Sur la page Machines virtuelles, sélectionnez votre nouvelle machine virtuelle.
3. Sur la page Vue d’ensemble de la machine virtuelle, sélectionnez Connecter.
4. Dans l’écran Connecter, sélectionnez RDP natif.
5. Dans l’écran RDP natif, sélectionnez Télécharger le fichier RDP.
6. Ouvrez le fichier RDP téléchargé, puis connectez-vous avec les informations

d’identification que vous avez entrées lors de la création de la machine virtuelle.
7. Sur la machine virtuelle distante, cliquez avec le bouton droit sur Démarrer, puis
sélectionnez Gestionnaire de périphériques.
8. Dans la fenêtre Gestionnaire d'appareils, développez le nœud Cartes réseau.

9. Vérifiez que la mention Mellanox ConnectX-4 Lx Virtual Ethernet Adapter (Carte
Ethernet virtuelle Mellanox ConnectX-4 Lx) s’affiche comme dans l’image suivante :
La présence de la carte confirme que Performances réseau accélérées est activé

pour votre machine virtuelle.
７ Notes
Si la carte Mellanox ne parvient pas à démarrer, ouvrez une invite de commandes

Administrateur sur la machine virtuelle distante, puis entrez la commande suivante :
netsh int tcp set global rss = enabled

Gérer les performances réseau accélérées sur
des machines virtuelles existantes
Vous pouvez activer les performances réseau accélérées sur une machine virtuelle
existante. La machine virtuelle doit répondre aux exigences suivantes pour prendre en
charge Performances réseau accélérées :
Avoir une taille prise en charge pour Performances réseau accélérées.

Être une image Place de marché Azure prise en charge.
Être arrêtée ou libérée avant l’activation des performances réseau accélérées sur
une carte réseau. Cette exigence s’applique à une machine virtuelle individuelle ou
aux machines virtuelles d’un groupe à haute disponibilité ou dans Azure Virtual
Machine Scale Sets.
Activer les performances réseau accélérées sur une

machine virtuelle individuelle ou des machines virtuelles
dans des groupes à haute disponibilité
1. Arrêtez ou libérez la machine virtuelle individuelle ou, dans le cas d’un groupe à
haute disponibilité, toutes les machines virtuelles du groupe :
Azure PowerShell
Stop-AzVM -ResourceGroup "<myResourceGroup>" -Name "<myVM>"
Si vous avez créé la machine virtuelle individuellement, sans groupe à haute

disponibilité, vous ne devez arrêter ou libérer que cette machine pour activer les
performances réseau accélérées. Si vous avez créé votre machine virtuelle avec un
groupe à haute disponibilité, vous devez arrêter ou libérer toutes les machines
virtuelles du groupe pour que les machines virtuelles finissent sur un cluster qui
prend en charge des performances réseau accélérées.
L’exigence d’arrêt ou de désallocation n’est pas nécessaire pour désactiver les

performances réseau accélérées. Les clusters qui prennent en charge les
performances réseau accélérées fonctionnent également correctement avec les
cartes réseau qui n’utilisent pas les performances réseau accélérées.
2. Activez les performances réseau accélérées sur la carte réseau de votre machine
virtuelle :
Azure PowerShell
$nic = Get-AzNetworkInterface -ResourceGroupName "<myResourceGroup>" -
Name "<myNic>"
$nic.EnableAcceleratedNetworking = $true
$nic | Set-AzNetworkInterface
3. Redémarrez la machine virtuelle ou toutes les machines virtuelles du groupe à

haute disponibilité, puis vérifiez que Performances réseau accélérées est bien
activé.
Azure PowerShell
Start-AzVM -ResourceGroup "<myResourceGroup>" -Name "<myVM>"
Activer les performances réseau accélérées dans Virtual

Machine Scale Sets
Azure Virtual Machine Scale Sets est légèrement différent, mais suit le même flux de
travail.
1. Arrêtez les machines virtuelles :
Azure PowerShell
Stop-AzVmss -ResourceGroupName "<myResourceGroup>" -VMScaleSetName "

<myScaleSet>"
2. Mettez à jour la propriété Performances réseau accélérées sur la NIC :
Azure PowerShell
$vmss = Get-AzVmss -ResourceGroupName "<myResourceGroup>" -

VMScaleSetName "<myScaleSet>"
$vmss.VirtualMachineProfile.NetworkProfile.NetworkInterfaceConfiguratio
ns[0].EnableAcceleratedNetworking = $true
Update-AzVmss
-VMScaleSetName "<myScaleSet>" `
-VirtualMachineScaleSet $vmss
3. Virtual Machine Scale Sets a une stratégie de mise à niveau qui applique des mises
à jour à l’aide de paramètres automatiques, propagés ou manuels. Définissez les
stratégies de mise à niveau sur « automatique » afin que les modifications soient
immédiatement récupérées.
Azure PowerShell
$vmss.UpgradePolicy.Mode = "Automatic"
Update-AzVmss
-VMScaleSetName "<myScaleSet>" `
-VirtualMachineScaleSet $vmss
4. Redémarrez le groupe identique :
Azure PowerShell
Start-AzVmss -ResourceGroupName "<myResourceGroup>" -VMScaleSetName "

<myScaleSet>"
Une fois le redémarrage et les mises à niveau terminés, la fonction virtuelle (VF) apparaît
dans les machines virtuelles qui utilisent un système d’exploitation et une taille de
machine virtuelle pris en charge.
Redimensionner des machines virtuelles existantes avec

Performances réseau accélérées
Les machines virtuelles avec Performances réseau accélérées activé peuvent être
redimensionnées uniquement en fonction de tailles qui prennent également en charge
les performances réseau accélérées. Vous ne pouvez pas redimensionner une machine
virtuelle avec Performances réseau accélérées en une instance de machine virtuelle qui
ne prend pas en charge les performances réseau accélérées à l’aide de l’opération de
redimensionnement. Utilisez plutôt la procédure suivante pour redimensionner ces
machines virtuelles :
1. Arrêtez et libérez la machine virtuelle ou toutes les machines virtuelles du groupe à

haute disponibilité ou dans Virtual Machine Scale Sets.
2. Désactivez les performances réseau accélérées sur la carte réseau de la machine
virtuelle ou sur toutes les machines virtuelles du groupe à haute disponibilité ou
dans Virtual Machine Scale Sets.
3. Attribuez aux machines virtuelles une nouvelle taille qui ne prend pas en charge les
performances réseau accélérées, puis redémarrez-les.
Gérer les performances réseau accélérées dans le portail

Quand vous créez une machine virtuelle dans le portail Azure, vous pouvez activer la
case à cocher Activer les performances réseau accélérées sous l’onglet Mise en réseau
de l’écran Créer une machine virtuelle. Si la machine virtuelle utilise un système
d’exploitation et une taille de machine virtuelle pris en charge pour les performances
réseau accélérées, la case est automatiquement cochée. Si les performances réseau
accélérées ne sont pas prises en charge, la case à cocher n’est pas activée, et un
message en explique la raison.
７ Notes
Vous pouvez activer les performances réseau accélérées lors de la création d’une
machine virtuelle du portail uniquement pour les systèmes d’exploitation pris en
charge de la Place de marché Azure. Pour créer et activer les performances réseau
accélérées pour une machine virtuelle avec une image de système d’exploitation
personnalisée, vous devez utiliser PowerShell ou Azure CLI.
Pour activer ou désactiver les performances réseau accélérées pour une machine
virtuelle existante à l’aide du portail Azure :
1. Dans le portail Azure , sur la page de la machine virtuelle, sélectionnez Mise en

réseau dans le menu de gauche.
3. En haut de la page Vue d’ensemble de la carte réseau, sélectionnez Modifier les
performances réseau accélérées.
4. Sélectionnez l’option Automatique, Activé ou Désactivé, puis sélectionnez
Enregistrer.
Pour vérifier si les performances réseau accélérées sont activées pour une machine
virtuelle existante :

3. Sur la page Vue d’ensemble de la NIC, sous Informations de base, notez si le
paramètre Performances réseau accélérées est défini sur l’option Activé ou
Désactivé.
Étapes suivantes
Linux et FreeBSD
Créer une machine virtuelle Performances réseau accélérées à l’aide d’Azure CLI
Créer une machine virtuelle Windows
ou Linux avec les performances réseau
accélérées à l’aide d’Azure CLI
Article • 18/04/2023
Cet article explique comment créer une machine virtuelle Linux ou Windows avec les
performances réseau accélérées (AccelNet) activées à l’aide de l’interface de ligne de
commande Azure CLI. Il explique également comment activer et gérer les performances
réseau accélérées sur des machines virtuelles existantes.
Vous pouvez aussi créer une machine virtuelle avec les performances réseau accélérées
activées à l’aide du portail Azure. Pour plus d’informations sur l’utilisation du portail
Azure pour gérer les performances réseau accélérées sur des machines virtuelles,
consultez la section Gérer les performances réseau accélérées dans le portail.
Pour utiliser Azure PowerShell pour créer une machine virtuelle Windows dont les
performances réseau accélérées sont activées, consultez l’article Créer une machine
virtuelle Linux avec les performances réseau accélérées à l’aide d’Azure PowerShell.
Prérequis
gratuitement .
Dernière version d’Azure CLI installée. Connectez-vous à Azure à l’aide de la

commande az login.
Créer une machine virtuelle avec les

performances réseau accélérées
Dans les exemples suivants, vous pouvez remplacer les exemples de paramètres tels que
<myResourceGroup> , <myNic> et <myVm> par vos propres valeurs.

1. Utilisez la commande az group create pour créer un groupe de ressources destiné
à contenir les ressources. Veillez à sélectionner une région Windows ou Linux prise
en charge mentionnée dans l’article sur les performances réseau accélérées
Windows et Linux .
Azure CLI
az group create --name <myResourceGroup> --location <myAzureRegion>
2. Utilisez la commande az network vnet create pour créer un réseau virtuel avec un
sous-réseau au sein du groupe de ressources :
Azure CLI

--resource-group <myResourceGroup> \
--name <myVnet> \
--address-prefix 192.168.0.0/16 \
--subnet-name <mySubnet> \

1. Utilisez la commande az network nsg create pour créer un groupe de sécurité
réseau (NSG).
Azure CLI

--name <myNsg>
2. Le groupe de sécurité réseau contient plusieurs règles par défaut, dont l’une
désactive tous les accès entrants à partir d’Internet. Utilisez la commande az
network nsg rule create pour ouvrir un port afin d’autoriser l’accès RDP (Remote
Desktop Protocol) ou SSH (Secure Shell) à la machine virtuelle.
Windows
Azure CLI

--nsg-name <myNsg> \
--name Allow-RDP-Internet \
--access Allow \
--protocol Tcp \
--priority 100 \
--destination-address-prefix "*" \
--destination-port-range 3389
Créer une interface réseau avec mise en réseau accélérée

1. Utiliser la commande az network public-ip create pour créer une adresse IP
publique. La machine virtuelle n’a pas besoin d’une adresse IP publique si vous n’y
accédez pas à partir d’Internet. Toutefois, vous avez besoin de l’adresse IP publique
pour effectuer les étapes de cet article.
Azure CLI

--name <myPublicIp> \
--resource-group <myResourceGroup>
2. Utilisez la commande az network nic create pour créer une interface réseau (NIC)
dont les performances réseau accélérées sont activées. L’exemple suivant crée une
interface réseau dans le sous-réseau du réseau virtuel et associe le groupe de
sécurité réseau à la carte réseau.
Azure CLI

--name <myNic> \
--vnet-name <myVnet> \
--subnet <mySubnet> \
--accelerated-networking true \
--public-ip-address <myPublicIp> \
--network-security-group <myNsg>
Créer une machine virtuelle et attacher la carte réseau

Utilisez la commande az vm create pour créer la machine virtuelle, puis utilisez l’option
--nics pour attacher l’interface réseau que vous avez créée. Veillez à sélectionner une
taille et une distribution de machine virtuelle mentionnées dans l’article sur les
performances réseau accélérées Windows et Linux . Pour obtenir la liste de l’ensemble
des tailles et caractéristiques des machines virtuelles, consultez l’article Tailles des
machines virtuelles dans Azure.
Windows
L’exemple suivant crée une machine virtuelle Windows Server 2019 Datacenter avec
une taille qui prend en charge les performances réseau accélérées,
Standard_DS4_v2.
Azure CLI
az vm create \
--name <myVm> \
--image Win2019Datacenter \
--size Standard_DS4_v2 \
--admin-username <myAdminUser> \
--admin-password <myAdminPassword> \
--nics <myNic>
Une fois la machine virtuelle créée, vous obtenez une sortie similaire à l’exemple suivant.
Pour une machine Linux, notez l’élément publicIpAddress , que vous entrez pour
accéder à la machine virtuelle à l’étape suivante.
Sortie
{
"fqdns": "",
ualMachines/myVm",
"location": "centralus",
"macAddress": "00-0D-3A-23-9A-49",
}
Confirmer l’activation de la mise en réseau

accélérée
Windows
Une fois la machine virtuelle créée dans Azure, connectez-vous à cette dernière et
vérifiez que le contrôleur Ethernet est installé dans Windows.
2. Sur la page Machines virtuelles, sélectionnez votre nouvelle machine virtuelle.
3. Sur la page Vue d’ensemble de la machine virtuelle, sélectionnez Connecter.
4. Dans l’écran Connecter, sélectionnez RDP natif.
5. Dans l’écran RDP natif, sélectionnez Télécharger le fichier RDP.
6. Ouvrez le fichier RDP téléchargé, puis connectez-vous avec les informations

d’identification que vous avez entrées lors de la création de la machine
virtuelle.
7. Sur la machine virtuelle distante, cliquez avec le bouton droit sur Démarrer,
puis sélectionnez Gestionnaire de périphériques.
8. Dans la fenêtre Gestionnaire d'appareils, développez le nœud Cartes réseau.
9. Vérifiez que la mention Mellanox ConnectX-4 Lx Virtual Ethernet Adapter

(Carte Ethernet virtuelle Mellanox ConnectX-4 Lx) s’affiche comme dans
l’image suivante :
La présence de la carte confirme que Performances réseau accélérées est
activé pour votre machine virtuelle.
７ Notes
Si la carte Mellanox ne parvient pas à démarrer, ouvrez une invite de

commandes Administrateur sur la machine virtuelle distante, puis entrez la
commande suivante :
netsh int tcp set global rss = enabled
Gérer la liaison dynamique et la révocation de

fonction virtuelle
La liaison à la carte réseau synthétique exposée à la machine virtuelle est une exigence
obligatoire pour toutes les applications tirant parti des performances réseau accélérées.
Si une application s’exécute directement via la carte réseau de fonction virtuelle, elle ne
reçoit pas tous les paquets destinés à la machine virtuelle, car certains paquets
s’affichent via l’interface synthétique.
Vous devez exécuter une application via la carte réseau synthétique pour garantir que
l’application reçoit tous les paquets qui lui sont destinés. La liaison à la carte réseau
synthétique garantit également que l’application continue à s’exécuter même si la
fonction virtuelle est révoquée pendant la maintenance de l’hôte.
Pour plus d’informations sur les exigences de liaison d’application, consultez l’article
Fonctionnement des performances réseau accélérées dans les machines virtuelles Linux
et FreeBSD.
Gérer les performances réseau accélérées sur

des machines virtuelles existantes
Il est possible d’activer les performances réseau accélérées sur une machine virtuelle
existante. La machine virtuelle doit répondre aux exigences suivantes pour prendre en
charge les performances réseau accélérées :
Une taille prise en charge pour les Performances réseau accélérées.
Une version de l’image et du noyau de la Place de marché Azure prise en charge

pour Linux.
Arrêté ou libéré avant l’activation des performances réseau accélérées sur une
carte réseau. Cette exigence s’applique à une machine virtuelle individuelle ou aux
machines virtuelles d’un groupe à haute disponibilité ou dans Azure Virtual
Machine Scale Sets.
Activer les performances réseau accélérées sur une

machine virtuelle individuelle ou des machines virtuelles
dans des groupes à haute disponibilité
1. Commencez par arrêter et libérer la machine virtuelle individuelle ou toutes les
machines virtuelles du groupe à haute disponibilité.
Azure CLI
az vm deallocate \
--name <myVm>
Si vous avez créé la machine virtuelle individuellement, sans groupe à haute
disponibilité, vous ne devez arrêter ou libérer que cette machine pour activer les
performances réseau accélérées. Si vous avez créé votre machine virtuelle avec un
groupe à haute disponibilité, vous devez arrêter ou libérer toutes les machines
virtuelles du groupe pour pouvoir activer les performances réseau accélérées sur
une carte réseau.
2. Après avoir arrêté la machine virtuelle, activez les performances réseau accélérées
sur la carte réseau de la machine virtuelle.
Azure CLI
az network nic update \

--name <myNic> \
--accelerated-networking true
3. Redémarrez la machine virtuelle ou toutes les machines virtuelles du groupe à

haute disponibilité, puis vérifiez que les performances réseau accélérées sont bien
activées.
Azure CLI
az vm start --resource-group <myResourceGroup> \

--name <myVm>
Activer les performances réseau accélérées dans Virtual

Machine Scale Sets
Azure Virtual Machine Scale Sets est légèrement différent, mais suit le même flux de
travail.
1. Tout d’abord, arrêtez les machines virtuelles :
Azure CLI
az vmss deallocate \
--name <myVmss> \
2. Une fois que les machines virtuelles sont arrêtées, mettez à jour la propriété
Performances réseau accélérées sur l’interface réseau.
Azure CLI
az vmss update --name <myVmss> \
--set
virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].
enableAcceleratedNetworking=true
3. Virtual Machine Scale Sets a une stratégie de mise à niveau qui applique des mises
à jour à l’aide de paramètres automatiques, propagés ou manuels. Les instructions
suivantes définissent la stratégie en mode automatique afin que Virtual Machine
Scale Sets récupère les modifications immédiatement après le redémarrage.
Azure CLI
az vmss update \
--name <myVmss> \
--set upgradePolicy.mode="automatic"
4. Enfin, redémarrez Virtual Machine Scale Sets.
Azure CLI
az vmss start \
--name <myVmss> \
Une fois le redémarrage et les mises à niveau terminés, la fonction virtuelle apparaît
dans les machines virtuelles qui utilisent un système d’exploitation et une taille de
machine virtuelle pris en charge.
Redimensionner des machines virtuelles existantes avec

les performances réseau accélérées
Vous pouvez redimensionner les machines virtuelles dont les performances réseau
accélérées sont activées uniquement en fonction de tailles qui prennent également en
charge les performances réseau accélérées. Vous ne pouvez pas redimensionner une
machine virtuelle avec les performances réseau accélérées en une instance de machine
virtuelle qui ne prend pas en charge les performances réseau accélérées à l’aide de
l’opération de redimensionnement. Utilisez plutôt la procédure suivante pour
redimensionner ces machines virtuelles :
1. Arrêtez et libérez la machine virtuelle ou toutes les machines virtuelles du groupe à

haute disponibilité ou dans Virtual Machine Scale Sets.
2. Désactivez les performances réseau accélérées sur la carte réseau de la machine
virtuelle ou sur toutes les machines virtuelles du groupe à haute disponibilité ou
dans Virtual Machine Scale Sets.
3. Attribuez aux machines virtuelles une nouvelle taille qui ne prend pas en charge les
performances réseau accélérées, puis redémarrez-les.
Gérer les performances réseau accélérées dans

le portail
Quand vous créez une machine virtuelle dans le portail Azure, vous pouvez activer la
case à cocher Activer les performances réseau accélérées sous l’onglet Mise en réseau
de l’écran Créer une machine virtuelle.
Si la machine virtuelle utilise un système d’exploitation pris en charge et une taille de

machine virtuelle prise en charge pour les performances réseau accélérées, la case à
cocher Activer les performances réseau accélérées sous l’onglet Mise en réseau de
l’écran Créer une machine virtuelle est automatiquement activée. Si les performances
réseau accélérées ne sont pas prises en charge, la case à cocher n’est pas activée, et un
message en explique la raison.
７ Notes
Vous pouvez activer les performances réseau accélérées lors de la création

d’une machine virtuelle du portail uniquement pour les systèmes
d’exploitation pris en charge de la Place de marché Azure. Pour créer et
activer les performances réseau accélérées pour une machine virtuelle avec
une image de système d’exploitation personnalisée, vous devez utiliser
Azure CLI ou PowerShell.
Le paramètre Performances réseau accélérées disponible dans le portail

reflète l’état sélectionné par l’utilisateur. Les performances réseau accélérées
permettent de choisir l’option Désactivé dans le portail, même si la taille de la
machine virtuelle nécessite les performances réseau accélérées. Les tailles de
machine virtuelle qui nécessitent les performances réseau accélérées activent
ce paramètre au moment de l’exécution, quel que soit le paramètre utilisateur
défini dans le portail.
Pour activer ou désactiver les performances réseau accélérées pour une machine
virtuelle existante à l’aide du portail Azure :

3. En haut de la page Vue d’ensemble de la carte réseau, sélectionnez Modifier les

performances réseau accélérées.
4. Sélectionnez l’option Automatique, Activé ou Désactivé, puis sélectionnez

Enregistrer.
Pour vérifier si les performances réseau accélérées sont activées pour une machine
virtuelle existante :
1. Sur la page de la machine virtuelle dans le portail, sélectionnez Mise en réseau

dans le menu de gauche.
3. Sur la page Vue d’ensemble de l’interface réseau, sous Informations de base,

notez si le paramètre Performances réseau accélérées est défini sur l’option Activé
ou Désactivé.
Étapes suivantes
Linux et FreeBSD
Créer une machine virtuelle avec performances réseau accélérées à l’aide de

PowerShell

Fonctionnement des performances
réseau accélérées dans les machines
virtuelles Linux et FreeBSD
Article • 26/04/2023
Quand une machine virtuelle est créée dans Azure, une interface réseau synthétique est
créée pour chaque carte réseau virtuelle dans sa configuration. L’interface synthétique
est un appareil VMbus et utilise le pilote « netvsc ». Les paquets réseau qui utilisent
cette interface synthétique circulent dans le commutateur virtuel de l’hôte Azure et sur
le réseau physique du centre de données.
Si la machine virtuelle est configurée avec les performances réseau accélérées, une
deuxième interface réseau est créée pour chaque carte réseau virtuelle configurée. La
deuxième interface est une fonction virtuelle (VF, Virtual Fonction) SR-IOV fournie par la
carte réseau physique dans l’hôte Azure. L’interface VF apparaît dans l’invité Linux en
tant qu’appareil PCI et utilise le pilote Mellanox « mlx4 » ou « mlx5 » dans Linux, car les
hôtes Azure utilisent des cartes réseau physiques Mellanox. La plupart des paquets
réseau sont directement placés entre l’invité Linux et la carte réseau physique sans
traverser le commutateur virtuel ni un autre logiciel qui s’exécute sur l’ordinateur hôte.
En raison de l’accès direct au matériel, la latence du réseau est plus faible et moins de
temps processeur est utilisé pour traiter les paquets réseau par rapport à l’interface
synthétique.
Différents hôtes Azure utilisent différents modèles de carte réseau physique Mellanox.
Linux détermine automatiquement s’il faut utiliser le pilote « mlx4 » ou « mlx5 ».
L’infrastructure Azure contrôle l’emplacement de la machine virtuelle sur l’hôte Azure. Si
aucune option client ne spécifie la carte réseau physique qui doit être utilisée par un
déploiement de machine virtuelle, les machines virtuelles doivent inclure les deux
pilotes. Si une machine virtuelle est arrêtée/libérée, puis redémarrée, elle peut être
redéployée sur du matériel avec un autre modèle de carte réseau physique Mellanox.
Par conséquent, la machine virtuelle peut utiliser l’autre pilote Mellanox.
Si une image de machine virtuelle n’inclut pas de pilote pour la carte réseau physique
Mellanox, les fonctionnalités réseau continuent de fonctionner à des vitesses plus lentes
de la carte réseau virtuelle. Le portail, Azure CLI et Azure PowerShell affichent la
fonctionnalité Performances réseau accélérées comme étant activée.
FreeBSD offre la même prise en charge des performances réseau accélérées que Linux
lors de l’exécution dans Azure. Le reste de cet article décrit Linux et utilise des exemples
Linux, mais les mêmes fonctionnalités sont disponibles dans FreeBSD.
７ Notes
Cet article contient des références au terme esclave, un terme que Microsoft
n’utilise plus. Lorsque ce terme sera supprimé du logiciel, nous le supprimerons de
cet article.
Agrégation de liens (bonding)

L’interface réseau synthétique et l’interface VF sont appairées automatiquement et
agissent comme une interface unique dans la plupart des aspects utilisés par les
applications. L’agrégation de liens (bonding) est effectuée par le pilote netvsc. Selon la
distribution Linux, les règles et scripts Udev peuvent vous aider à nommer l’interface VF
et à configurer le réseau. Si la machine virtuelle est configurée avec plusieurs cartes
réseau virtuelles, l’hôte Azure fournit un numéro de série unique pour chacune d’entre
elles. Cela permet à Linux d’effectuer le jumelage approprié des interfaces synthétiques
et VF pour chaque carte réseau virtuelle.
Les interfaces synthétiques et VF ont la même adresse MAC. Ensemble, elles constituent
une carte réseau unique du point de vue des autres entités réseau qui échangent des
paquets avec la carte réseau virtuelle dans la machine virtuelle. Les autres entités
n’effectuent aucune action spéciale en raison de l’existence de l’interface synthétique et
de l’interface VF.
Les deux interfaces sont visibles via la commande ifconfig ou ip addr dans Linux. Voici
un exemple de sortie de ifconfig :
Sortie
U1804:~$ ifconfig
enP53091s1np0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500
ether 00:0d:3a:f5:76:bd txqueuelen 1000 (Ethernet)
RX packets 365849 bytes 413711297 (413.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9447684 bytes 2206536829 (2.2 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 10.1.19.4 netmask 255.255.255.0 broadcast 10.1.19.255
inet6 fe80::20d:3aff:fef5:76bd prefixlen 64 scopeid 0x20<link>
ether 00:0d:3a:f5:76:bd txqueuelen 1000 (Ethernet)
RX packets 8714212 bytes 4954919874 (4.9 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9103233 bytes 2183731687 (2.1 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
L’interface synthétique a toujours un nom de la forme eth\<n\> . Selon la distribution
Linux, l’interface VF peut avoir un nom de la forme eth\<n\> ou d’une forme différente
en raison d’une règle udev qui effectue le renommage.
Qu’une interface particulière soit l’interface synthétique ou que l’interface VF puisse être
déterminée à l’aide de la ligne de commande shell qui affiche le pilote d’appareil utilisé
par l’interface :
Sortie
$ ethtool -i <interface name> | grep driver
Si le pilote est hv_netvsc , c’est l’interface synthétique. L’interface VF a un nom de pilote

qui contient « mlx ». L’interface VF est également identifiable, car son champ
d’indicateurs inclut SLAVE . Cet indicateur indique qu’il est sous le contrôle de l’interface
synthétique qui a la même adresse MAC. Enfin, les adresses IP sont affectées seulement
à l’interface synthétique, et la sortie de ifconfig ou de ip addr montre également cette
distinction.
Utilisation de l'application
Les applications doivent interagir uniquement avec l’interface synthétique, comme dans
tout autre environnement de mise en réseau. Les paquets réseau sortants sont envoyés
du pilote netvsc au pilote VF, puis transmis par le biais de l’interface VF. Les paquets
entrants sont reçus et traités sur l’interface VF avant d’être transmis à l’interface
synthétique. Les exceptions sont les paquets TCP SYN entrants et les paquets de
diffusion/multidiffusion qui sont traités seulement par l’interface synthétique.
Vous pouvez vérifier que les paquets circulent sur l’interface VF à partir de la sortie de
ethtool -S eth\<n\> . Les lignes de la sortie qui contiennent vf montrent le trafic sur
l’interface VF. Par exemple :
Sortie
U1804:~# ethtool -S eth0 | grep ' vf_'

vf_rx_packets: 111180
vf_rx_bytes: 395460237
vf_tx_packets: 9107646
vf_tx_bytes: 2184786508
vf_tx_dropped: 0
Si ces compteurs sont incrémentés lors de l’exécution consécutive de la commande
« ethtool », le trafic réseau passe par l’interface VF.
La commande lspci permet de constater l’existence de l’interface VF en tant

qu’appareil PCI. Par exemple, sur la machine virtuelle de génération 1, vous pouvez voir
une sortie similaire à celle-ci (les machines virtuelles de génération 2 n’ont pas les
appareils PCI hérités) :
Sortie
U1804:~# lspci
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (AGP disabled) (rev 03)
0000:00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)
0000:00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev
01)
0000:00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
0000:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V
virtual VGA
cf63:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family
[ConnectX-4 Lx Virtual Function] (rev 80)
Dans cet exemple, la dernière ligne de sortie identifie une fonction VF à partir de la carte
réseau physique Mellanox ConnectX-4.
La commande « ethtool -l » ou « ethtool -L » (pour obtenir et définir le nombre de files

d’attente de transmission et de réception) est une exception par rapport aux instructions
pour interagir avec l’interface « eth<n> ». Cette commande peut être utilisée
directement sur l’interface VF pour contrôler le nombre de files d’attente pour l’interface
VF. Le nombre de files d’attente pour l’interface VF est indépendant du nombre de files
d’attente pour l’interface synthétique.
Interprétation des messages de démarrage

Lors du démarrage, Linux affiche de nombreux messages liés à l’initialisation et à la
configuration de l’interface VF. Des informations sur l’agrégation de liens (bonding) avec
l’interface synthétique s’affichent également. La compréhension de ces messages peut
être utile pour identifier les problèmes dans le processus.
Voici un exemple de sortie de la commande « dmesg », réduit uniquement aux lignes

pertinentes pour l’interface VF. En fonction de la distribution et de la version du noyau
Linux dans votre machine virtuelle, les messages peuvent varier légèrement, mais le flux
général reste identique.
Sortie
[ 2.327663] hv_vmbus: registering driver hv_netvsc

[ 3.918902] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: VF slot
1 added
Le pilote netvsc pour eth0 a été inscrit.
Sortie
[ 6.944883] hv_vmbus: registering driver hv_pci
Le pilote PCI VMbus virtuel a été inscrit. Ce pilote fournit des services PCI de base dans
une machine virtuelle Linux dans Azure et doit être inscrit pour que l’interface VF puisse
être détectée et configurée.
Sortie
[ 6.945132] hv_pci e9ac9b28-cf63-4466-9ae3-4b849c3ee03b: PCI VMBus

probing: Using version 0x10002
[ 6.947953] hv_pci e9ac9b28-cf63-4466-9ae3-4b849c3ee03b: PCI host bridge
to bus cf63:00
[ 6.947955] pci_bus cf63:00: root bus resource [mem 0xfe0000000-
0xfe00fffff window]
[ 6.948805] pci cf63:00:02.0: [15b3:1016] type 00 class 0x020000
[ 6.957487] pci cf63:00:02.0: reg 0x10: [mem 0xfe0000000-0xfe00fffff
64bit pref]
[ 7.035464] pci cf63:00:02.0: enabling Extended Tags
[ 7.040811] pci cf63:00:02.0: 0.000 Gb/s available PCIe bandwidth,
limited by Unknown x0 link at cf63:00:02.0 (capable of 63.008 Gb/s with 8.0
GT/s PCIe x8 link)
[ 7.041264] pci cf63:00:02.0: BAR 0: assigned [mem 0xfe0000000-
0xfe00fffff 64bit pref]
L’appareil PCI avec le GUID répertorié (attribué par l’hôte Azure) a été détecté. Il reçoit
un ID de domaine PCI (0xcf63 dans le cas présent) en fonction du GUID. L’ID de
domaine PCI doit être unique sur tous les appareils PCI disponibles dans la machine
virtuelle. Cette exigence d’unicité s’étend aux autres interfaces Mellanox VF, GPU,
appareils NVMe, etc. pouvant être présents dans la machine virtuelle.
Sortie
[ 7.128515] mlx5_core cf63:00:02.0: firmware version: 14.25.8362

[ 7.139925] mlx5_core cf63:00:02.0: handle_hca_cap:524:(pid 12):
log_max_qp value in current profile is 18, changing it to HCA capability
limit (12)
[ 7.342391] mlx5_core cf63:00:02.0: MLX5E: StrdRq(0) RqSz(1024)
StrdSz(256) RxCqeCmprss(0)
Une fonction VF Mellanox qui utilise le pilote mlx5 a été détectée et le pilote mlx5
commence son initialisation de l’appareil.
Sortie
[ 7.465085] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: VF

registering: eth1
[ 7.465119] mlx5_core cf63:00:02.0 eth1: joined to eth0
L’interface synthétique correspondante qui utilise le pilote netvsc a détecté un VF

correspondant. Le pilote mlx5 reconnaît qu’il a été lié par bonding à l’interface
synthétique.
Sortie
[ 7.466064] mlx5_core cf63:00:02.0 eth1: Disabling LRO, not supported in

legacy RQ
[ 7.480575] mlx5_core cf63:00:02.0 eth1: Disabling LRO, not supported in
legacy RQ
[ 7.480651] mlx5_core cf63:00:02.0 enP53091s1np0: renamed from eth1
L’interface VF était initialement nommée « eth1 » par le noyau Linux. Une règle udev l’a
renommée pour éviter toute confusion avec les noms donnés aux interfaces
synthétiques.
Sortie
[ 8.087962] mlx5_core cf63:00:02.0 enP53091s1np0: Link up
L’interface Mellanox VF est désormais opérationnelle et active.
Sortie
[ 8.090127] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: Data

path switched to VF: enP53091s1np0
path switched from VF: enP53091s1np0
Ces messages indiquent que le chemin d’accès aux données de la paire liée a changé
pour utiliser l’interface VF. Il repasse ensuite à l’interface synthétique au bout de
1,6 seconde environ. Ces commutations peuvent se produire deux ou trois fois pendant
le processus de démarrage. Il s’agit du comportement normal quand la configuration est
initialisée.
Sortie

[ 11.532147] mlx5_core cf63:00:02.0 enP53091s1np0: Disabling LRO, not
supported in legacy RQ
Le message final indique que le chemin des données a changé pour utiliser l’interface
VF. Ce comportement est attendu pendant le fonctionnement normal de la machine
virtuelle.
Maintenance de l’hôte Azure

Lors de l’exécution de la maintenance de l’hôte Azure, toutes les interfaces VF peuvent
être supprimées temporairement de la machine virtuelle pendant la maintenance. Une
fois la maintenance effectuée, les interfaces VF sont de nouveau ajoutées à la machine
virtuelle. Le fonctionnement normal se poursuit. Pendant que la machine virtuelle
fonctionne sans les interfaces VF, le trafic réseau continue à circuler via l’interface
synthétique sans aucune interruption des applications. Dans ce contexte, la maintenance
de l’hôte Azure peut inclure la mise à jour des différents composants de l’infrastructure
réseau Azure ou une mise à niveau complète du logiciel hyperviseur de l’hôte Azure. Ces
événements de maintenance se produisent à des intervalles de temps en fonction des
besoins opérationnels de l’infrastructure Azure. Ces événements peuvent généralement
se produire plusieurs fois au cours d’une année. La commutation automatique entre
l’interface VF et l’interface synthétique garantit que les événements de maintenance ne
perturbent pas les charges de travail si les applications interagissent seulement avec
l’interface synthétique. Les latences et la charge du processeur peuvent être plus élevées
pendant ces périodes en raison de l’utilisation de l’interface synthétique. Ces périodes
durent généralement 30 secondes environ. Toutefois, elles peuvent parfois durer
quelques minutes.
La suppression et le rajout de l’interface VF pendant un événement de maintenance sont

visibles dans la sortie « dmesg » de la machine virtuelle. Voici une sortie standard :
Sortie

unregistering: enP53091s1np0
slot 1 removed
Le chemin d’accès aux données n’indique plus l’interface VF et l’interface VF a été

désinscrite. À ce stade, Linux a supprimé toutes les connaissances de l’interface VF et
fonctionne comme si les performances réseau accélérées n’avaient pas été activées.
Sortie

slot 1 added
[ 8225.557867] hv_pci e9ac9b28-cf63-4466-9ae3-4b849c3ee03b: PCI VMBus
probing: Using version 0x10002
[ 8225.566794] hv_pci e9ac9b28-cf63-4466-9ae3-4b849c3ee03b: PCI host
bridge to bus cf63:00
[ 8225.566797] pci_bus cf63:00: root bus resource [mem 0xfe0000000-
0xfe00fffff window]
[ 8225.571556] pci cf63:00:02.0: [15b3:1016] type 00 class 0x020000
[ 8225.584903] pci cf63:00:02.0: reg 0x10: [mem 0xfe0000000-0xfe00fffff
64bit pref]
[ 8225.662860] pci cf63:00:02.0: enabling Extended Tags
[ 8225.667831] pci cf63:00:02.0: 0.000 Gb/s available PCIe bandwidth,
limited by Unknown x0 link at cf63:00:02.0 (capable of 63.008 Gb/s with 8.0
GT/s PCIe x8 link)
[ 8225.667978] pci cf63:00:02.0: BAR 0: assigned [mem 0xfe0000000-
0xfe00fffff 64bit pref]
Quand l’interface VF est rajoutée une fois que la maintenance est effectuée, un nouvel
appareil PCI avec le GUID spécifié est détecté. Il se voit attribuer le même ID de domaine
PCI (0xcf63) que précédemment. Le traitement de l’interface VF après rajout est
identique au démarrage initial.
Sortie
[ 8225.679672] mlx5_core cf63:00:02.0: firmware version: 14.25.8362

[ 8225.888476] mlx5_core cf63:00:02.0: MLX5E: StrdRq(0) RqSz(1024)
StrdSz(256) RxCqeCmprss(0)
registering: eth1
[ 8226.021058] mlx5_core cf63:00:02.0 eth1: joined to eth0
[ 8226.021968] mlx5_core cf63:00:02.0 eth1: Disabling LRO, not supported
in legacy RQ
[ 8226.026631] mlx5_core cf63:00:02.0 eth1: Disabling LRO, not supported
in legacy RQ
[ 8226.026699] mlx5_core cf63:00:02.0 enP53091s1np0: renamed from eth1
Le pilote mlx5 initialise l’interface VF et l’interface est désormais fonctionnelle. La sortie
est similaire à la sortie lors du démarrage initial.
Sortie

Le chemin d’accès aux données est repassé à l’interface VF.
Désactiver/activer les performances réseau

accélérées dans une machine virtuelle qui n’est
pas en cours d’exécution
Les performances réseau accélérées peuvent être activées/désactivées avec Azure CLI
sur une carte réseau virtuelle dans une machine virtuelle qui n’est pas en cours
d’exécution. Par exemple :
Sortie
$ az network nic update --name u1804895 --resource-group testrg --

accelerated-network false
La désactivation des performances réseau accélérées activée dans la machine virtuelle

invitée génère une sortie « dmesg ». L’action est similaire à la suppression de l’interface
VF pour la maintenance de l’hôte Azure. L’activation des performances réseau accélérées
produit la même sortie « dmesg » que lorsque l’interface VF est ajoutée de nouveau
après la maintenance de l’hôte Azure. Ces commandes Azure CLI peuvent être utilisées
pour simuler la maintenance de l’hôte Azure. Elles vous permettent de vérifier que vos
applications ne dépendent pas de manière incorrecte de l’interaction directe avec
l’interface VF.
Étapes suivantes
Découvrez comment créer une machine virtuelle avec les performances réseau
accélérées dans PowerShell
Découvrez comment créer une machine virtuelle avec des performances réseau
accélérées en utilisant Azure CLI
Améliorer la latence avec le groupe de placement de proximité Azure
Configurer DPDK dans une machine
virtuelle Linux
Article • 30/04/2023
Le kit DPDK (Data Plan Development Kit) dans Azure offre une infrastructure de
traitement des paquets d’espace utilisateur plus rapide pour les applications exigeantes
en termes de performance. Cette infrastructure contourne la pile réseau du noyau de la
machine virtuelle.
Dans le traitement de paquets typique qui utilise la pile réseau du noyau, le processus
est piloté par les interruptions. Lorsque l’interface réseau reçoit des paquets entrants, le
noyau s’interrompt afin de traiter le paquet et un changement de contexte de l’espace
noyau à l’espace utilisateur. DPDK remplace le changement de contexte et la méthode
pilotée par les interruptions par l’implémentation d’un espace utilisateur qui se sert des
pilotes du mode d’interrogation pour traiter rapidement les paquets.
DPDK se compose d'ensembles de bibliothèques d'espace utilisateur qui donnent accès

à des ressources de niveau inférieur. Ces ressources peuvent inclure le matériel, les
cœurs logiques, la gestion de la mémoire et les pilotes de mode d’interrogation pour les
cartes d'interface réseau.
DPDK peut s’exécuter sur des machines virtuelles Azure prenant en charge plusieurs
distributions de système d’exploitation. DPDK fournit une différenciation de
performance clé dans le pilotage des implémentations de virtualisation des fonctions
réseau. Ces implémentations peuvent prendre la forme d'appliances virtuelles réseau
(NVA), telles que des routeurs virtuels, des pare-feu, des VPN, des équilibreurs de
charge, des cœurs de paquets évolués et des applications de déni de service (DDoS).
Avantage
Nombre supérieur de paquets par seconde (PPS) : le contournement du noyau et la
prise de contrôle des paquets dans l’espace utilisateur ont pour effet de réduire le
nombre de cycles du fait de l’élimination des changements de contexte. Il améliore
également le nombre de paquets traités à la seconde dans les machines virtuelles Linux
Azure.
Versions minimales des systèmes d’exploitation

prises en charge
Voici les distributions de la Place de marché Azure qui sont prises en charge :
Système d’exploitation Linux Version du noyau
Ubuntu 18.04 4.15.0-1014-azure+
SLES 15 SP1 4.12.14-8.19-azure+
RHEL 7.5 3.10.0-862.11.6.el7.x86_64+
CentOS 7.5 3.10.0-862.11.6.el7.x86_64+
Debian 10 4.19.0-1-cloud+
Les versions indiquées correspondent à la configuration minimale requise. Les versions

plus récentes sont également prises en charge.
Prise en charge de noyau personnalisé
Pour toute version du noyau Linux non répertoriée, voir Correctifs pour la création d'un
noyau Linux optimisé pour Azure . Pour plus d’informations, vous pouvez également
contacter aznetdpdk@microsoft.com.
Prise en charge de la région

Toutes les régions Azure prennent en charge DPDK.
Prérequis
La mise en réseau accélérée doit être activée sur une machine virtuelle Linux. La machine
virtuelle doit disposer d’au moins deux interfaces réseau, dont une pour la gestion.
L’activation des performances réseau accélérées sur l’interface de gestion n’est pas
recommandée. Découvrez comment créer une machine virtuelle Linux en ayant activé la
mise en réseau accélérée.
De plus, DPDK utilise des verbes RDMA pour créer des files d’attente de données sur
l’adaptateur réseau. Dans la machine virtuelle, vérifiez que les pilotes de noyau RDMA
corrects sont chargés. Elles peuvent être mlx4_ib, mlx5_ib ou mana_ib selon les tailles de
machine virtuelle.
Installer DPDK manuellement (non

recommandé)
Installer les dépendances de build
RHEL, CentOS
RHEL 7.5/CentOS 7.5
Bash
yum -y groupinstall "Infiniband Support"

sudo dracut --add-drivers "mlx4_en mlx4_ib mlx5_ib" -f
yum install -y gcc kernel-devel-`uname -r` numactl-devel.x86_64
librdmacm-devel libmnl-devel meson
Compiler et installer DPDK manuellement

1. Téléchargez la dernière version de DPDK . La version 22.11 LTS ou ultérieure est
recommandée pour Azure.
2. Créez la configuration par défaut avec meson builddir .
3. Compilez avec ninja -C builddir .
4. Installez avec DESTDIR=<output folder> ninja -C builddir install .
Configurez l’environnement d’exécution

Après le redémarrage, exécutez une fois les commandes suivantes :
1. Hugepages
Configurez les Hugepages en exécutant la commande suivante, une seule fois

pour chaque nœud NUMA :
Bash
echo 1024 | sudo tee

/sys/devices/system/node/node*/hugepages/hugepages-2048kB/nr_hugepages
Créez un répertoire pour un montage avec mkdir /mnt/huge .
Montez les Hugepages avec mount -t hugetlbfs nodev /mnt/huge .

Vérifiez que les HugePages sont réservées avec grep Huge /proc/meminfo .
L’exemple ci-dessus concerne 2 M de pages volumineuses. Des pages

volumineuses de 1 G peuvent également être utilisées.
７ Notes
Il existe un moyen de modifier le fichier grub de sorte que les HugePages

soient réservées au démarrage en suivant les instructions relatives à DPDK.
Les instructions figurent au bas de la page. Lorsque vous utilisez une machine
virtuelle Linux Azure, modifiez plutôt les fichiers sous /etc/config/grub.d de
sorte que les HugePages soient réservées à tous les redémarrages.
2. Adresses MAC et IP : utilisez ifconfig –a pour afficher l’adresse MAC et IP des

interfaces réseau. Les interface réseau VF et NETVSC ont la même adresse MAC,
mais seule l’interface réseau NETVSC possède une adresse IP. Les interfaces VF
s’exécutent en tant qu’interfaces subordonnées des interfaces NETVSC.
3. Adresses PCI
Utiliser ethtool -i <vf interface name> pour savoir quelle adresse PCI
utiliser pour ethtool -i <vf interface name> .
Si la mise en réseau accélérée d’eth0 est activée, assurez-vous que testpmd

ne prend pas accidentellement le contrôle de l’appareil pci VF pour eth0. Si
l’application DPDK prend accidentellement le contrôle de l’interface réseau
de gestion et que cela vous fait perdre la connexion SSH, utilisez la console
série pour arrêter l’application DPDK. Vous pouvez également utiliser la
console série pour arrêter ou démarrer la machine virtuelle.
4. Chargez ibuverbs à chaque redémarrage avec . Pour SLES 15 uniquement, chargez

aussi mlx4_ib avec .
PMD maître
Les applications DPDK doivent être exécutées sur le PMD maître exposé dans Azure. Si
l’application s’exécute directement via le PMD VF, elle ne reçoit pas tous les paquets
destinés à la machine virtuelle, car certains paquets s’affichent via l’interface
synthétique. DPDK prend en charge deux types de PMD maître : NetVSC PMD et Failsafe
PMD. Un PMD maître garantit que l’application reçoit tous les paquets qui lui sont
destinés. Il permet également de s’assurer que l’application continue de fonctionner en
mode DPDK sur le PMD maître, même si le VF est révoqué lorsque l’hôte est en cours de
maintenance.
PMD NetVSC
NetVSC est le PMD recommandé pour fonctionner en tant que PMD maître dans Azure.
Il garantit que l’application reçoit tous les paquets qui lui sont destinés. Il est par ailleurs
certain que l’application continuera à s’exécuter en mode DPDK, même si la fonction
virtuelle est révoqué lorsque l’hôte est en cours de maintenance. Pour plus
d’informations sur l’utilisation et la configuration de PMD NetVSC, consultez
(https://doc.dpdk.org/guides/nics/netvsc.html ).
PMD fiable (failsafe)

Remarque : il n’est pas recommandé d’utiliser Failsafe PMD dans Azure. Si votre version
DPDK est 22.11 LTS ou ultérieure, il est recommandé d’utiliser NetVSC PMD.
Vous pouvez également exécuter une application DPDK sur le PMD de sécurité
automatique. Si vous souhaitez obtenir plus d’informations sur le PMD fiable (failsafe),
consultez la Bibliothèque de pilotes de prévention de défaillance en mode
interrogation .
Exécuter testpmd
Pour exécuter testpmd en mode racine, utilisez sudo avant la commande sudo .
De base : contrôle d’intégrité, initialisation d’adaptateur

fiable (failsafe)
1. Exécutez les commandes suivantes pour démarrer une application testpmd à port
unique :
Bash
testpmd -w <pci address from previous step> \

-- -i \
--port-topology=chained
2. Exécutez les commandes suivantes pour démarrer une application testpmd à deux
ports :
Bash
testpmd -w <pci address nic1> \

-w <pci address nic2> \
-- -i
Après que l’application a démarré, exécutez show port info all pour vérifier les
informations de port. Un ou deux ports DPDK net_netvsc devraient s’afficher.
3. Utilisez start <port> /stop <port> pour lancer le trafic.
Les commandes précédentes démarrent testpmd en mode interactif, ce qui est

recommandé, pour tester des commandes testpmd.
De base : expéditeur unique/destinataire unique

Les commandes suivantes impriment régulièrement des statistiques relatives au nombre
de paquets par seconde :
1. Du côté de TX, exécutez la commande suivante :
Bash
testpmd \
-l <core-list> \
-n <num of mem channels> \
-w <pci address of the device you plan to use> \
-- --port-topology=chained \
--nb-cores <number of cores to use for test pmd> \
--forward-mode=txonly \
--eth-peer=<port id>,<receiver peer MAC address> \
--stats-period <display interval in seconds>
2. Du côté de RX, exécutez la commande suivante :
Bash
testpmd \
-l <core-list> \
--forward-mode=rxonly \
--eth-peer=<port id>,<sender peer MAC address> \
Si vous exécutez les commandes précédentes sur une machine virtuelle, modifiez
IP_SRC_ADDR et IP_DST_ADDR dans pour faire correspondre l’adresse IP effective des
machines virtuelles avant de procéder à la compilation. Sinon, les paquets seront
abandonnés avant de parvenir au destinataire.
Avancé : expéditeur unique/redirecteur unique

Les commandes suivantes impriment régulièrement des statistiques relatives au nombre
de paquets par seconde :
1. Du côté de TX, exécutez la commande suivante :
Bash
testpmd \
-l <core-list> \
--forward-mode=txonly \
--eth-peer=<port id>,<receiver peer MAC address> \
2. Du côté de FWD, exécutez la commande suivante :
Bash
testpmd \
-l <core-list> \
-w <pci address NIC1> \
-w <pci address NIC2> \
-- --nb-cores <number of cores to use for test pmd> \
--forward-mode=io \
--eth-peer=<recv port id>,<sender peer MAC address> \
Si vous exécutez les commandes précédentes sur une machine virtuelle, modifiez
IP_SRC_ADDR et IP_DST_ADDR dans pour faire correspondre l’adresse IP effective des
machines virtuelles avant de procéder à la compilation. Sinon, les paquets seront
abandonnés avant de parvenir au redirecteur. Vous ne pouvez pas utiliser une troisième
machine pour la réception du trafic transféré, car le redirecteur testpmd ne modifie pas
les adresses de couche 3, sauf si vous apportez des modifications au code.
Installer DPDK via le package système (non
recommandé)
RHEL, CentOS
Bash
sudo yum install -y dpdk
References
Options EAL
Commandes Testpmd
Commandes de vidage des paquets

Optimisation des performances TCP/IP
pour les machines virtuelles Azure
Article • 11/04/2023
Cet article présente les techniques courantes d'optimisation des performances TCP/IP et
certains éléments à prendre en compte lorsque vous les utilisez pour les machines
virtuelles exécutées sur Azure. Il fournira un aperçu de base des techniques et détaillera
les différentes méthodes d’optimisation.
Techniques courantes d’optimisation TCP/IP
MTU, fragmentation et déchargement d’envoi important
MTU
L'unité de transmission maximale (MTU) est la trame de taille maximale (paquet),
spécifiée en octets, qui peut être envoyée via une interface réseau. La MTU est un
paramètre configurable. La MTU par défaut utilisée sur les machines virtuelles Azure, et
le paramètre par défaut sur la plupart des périphériques réseau dans le monde, est de 1
500 octets.
Fragmentation
La fragmentation survient lorsqu'un paquet envoyé dépasse la MTU d'une interface
réseau. La pile TCP/IP décomposera le paquet en plus petits morceaux (fragments)
conformes à la MTU de l'interface. La fragmentation se produit au niveau de la couche
IP et est indépendante du protocole sous-jacent (par exemple TCP). Lorsqu'un paquet
de 2 000 octets est envoyé via une interface réseau avec une MTU de 1 500, le paquet
sera décomposé en un paquet de 1 500 octets et un autre paquet de 500 octets.
Les périphériques réseau dans le chemin qui sépare une source et une destination
peuvent soit supprimer des paquets qui dépassent la MTU, soit fragmenter le paquet en
plus petits morceaux.
Bit Ne pas fragmenter d’un paquet IP

Le bit Ne pas fragmenter (Don’t Fragment, DF) représente un drapeau dans l'en-tête du
protocole IP. Le bit DF indique que les périphériques réseau sur le chemin entre
l'émetteur et le récepteur ne doivent pas fragmenter le paquet. Ce bit peut être défini
pour de nombreuses raisons. (Voir la section « Détection MTU du chemin d'accès » de
cet article pour visualiser un exemple). Lorsqu'un périphérique réseau reçoit un paquet
avec le bit Ne pas fragmenter défini et que ce paquet dépasse la MTU de l'interface du
périphérique, le comportement standard veut que le périphérique supprime le paquet.
L'appareil envoie un message « ICMP Fragmentation Needed » (Fragmentation ICMP
requise) à la source originale du paquet.
Impact de la fragmentation sur les performances
La fragmentation peut avoir des répercussions négatives sur les performances. L'un des
principaux effets sur les performances est l'impact au niveau du processeur/de la
mémoire de la fragmentation et du réassemblage des paquets. Lorsqu'un périphérique
réseau a besoin de fragmenter un paquet, il devra allouer des ressources
processeur/mémoire pour effectuer la fragmentation.
La même chose se produit lorsque le paquet est réassemblé. Le périphérique réseau doit
stocker tous les fragments jusqu'à ce qu'ils soient reçus afin de pouvoir les réassembler
dans le paquet original. Ce processus de fragmentation et de réassemblage peut
également provoquer une certaine latence.
L'autre conséquence négative possible de la fragmentation sur les performances est que
les paquets fragmentés peuvent arriver en désordre. Lorsque les paquets sont reçus en
désordre, certains types de périphériques réseau peuvent les supprimer. Lorsque cela se
produit, le paquet entier doit être retransmis.
Les fragments sont généralement supprimés par les dispositifs de sécurité tels que les
pare-feu réseau ou lorsque les tampons de réception d'un périphérique réseau sont
épuisés. Lorsque les tampons de réception d'un périphérique réseau sont épuisés, un
périphérique réseau tente de réassembler un paquet fragmenté mais ne dispose pas des
ressources nécessaires pour stocker et consommer à nouveau ce paquet.
La fragmentation peut être considérée comme une opération négative, mais la prise en
charge de cette fragmentation est nécessaire lorsque vous connectez divers réseaux via
Internet.
Avantages et conséquences de la modification de la MTU
En règle générale, vous pouvez créer un réseau plus performant en augmentant la MTU.
Chaque paquet transmis contient des informations d'en-tête qui sont ajoutées au
paquet d'origine. Lorsque la fragmentation crée d’autres paquets, une surcharge se
produit au niveau de l’en-tête, et cela rend le réseau moins efficace.
Voici un exemple. La taille de l'en-tête Ethernet est de 14 octets plus une séquence de
vérification de trame de 4 octets pour assurer la cohérence des trames. Si un paquet de
2 000 octets est envoyé, 18 octets de surcharge Ethernet sont ajoutés sur le réseau. Si le
paquet est fragmenté en un paquet de 1 500 octets plus un paquet de 500 octets,
chaque paquet aura 18 octets d'en-tête Ethernet, soit 36 octets au total.
Gardez à l'esprit que l'augmentation de la MTU ne rendra pas nécessairement un réseau

plus efficace. Si une application n'envoie que des paquets de 500 octets, la même
surcharge d’en-tête existe, que la MTU soit de 1 500 octets ou de 9 000 octets. Le
réseau ne sera plus efficace que s'il utilise des paquets de plus grande taille, affectés par
la MTU.
MTU pour Azure et les machines virtuelles

La MTU par défaut pour les machines virtuelles Azure est de 1 500 octets. La pile du
réseau virtuel Azure tentera de fragmenter un paquet à 1 400 octets.
Notez que la pile du réseau virtuel n'est pas intrinsèquement inefficace car elle
fragmente les paquets à 1 400 octets même si les machines virtuelles ont une MTU de 1
500 octets. Un grand pourcentage des paquets réseau sont beaucoup plus petits que 1
400 ou 1 500 octets.
Azure et la fragmentation
La pile du réseau virtuel est configurée pour supprimer les « fragments en désordre »,
c'est-à-dire les paquets fragmentés qui n'arrivent pas dans leur ordre fragmenté
d'origine. Ces paquets sont supprimés principalement à cause d'une vulnérabilité de
sécurité réseau annoncée en novembre 2018 et appelée FragmentSmack.
FragmentSmack est un défaut dans la façon dont le noyau Linux traite le réassemblage
des paquets IPv4 et IPv6 fragmentés. Un attaquant distant pourrait utiliser cette faille
pour déclencher des opérations coûteuses de réassemblage des fragments, ce qui
risquerait d’entraîner une augmentation du processeur et un déni de service sur le
système cible.
Ajuster la MTU
Vous pouvez configurer une MTU de machine virtuelle Azure, comme dans tout autre
système d'exploitation. Mais vous devriez tenir compte de la fragmentation qui se
produit dans Azure, décrite ci-dessus, lorsque vous configurez une MTU.
Nous déconseillons aux clients d’augmenter les MTU des machines virtuelles. Cette
discussion a pour but d'expliquer en détail comment Azure implémente la MTU et
effectue la fragmentation.
） Important
L’augmentation de la MTU ne vise pas à améliorer les performances et pourrait

avoir un effet négatif sur les performances des applications.
Déchargement d’envoi important

Le déchargement d’envoi important (Large Send Offload ou LSO) peut améliorer les
performances du réseau en déchargeant la segmentation des paquets sur l'adaptateur
Ethernet. Lorsque LSO est activé, la pile TCP/IP crée un grand paquet TCP et l'envoie à
l'adaptateur Ethernet pour segmentation avant de le transférer. L'avantage de LSO est
qu'il évite au processeur d’effectuer la segmentation des paquets en tailles conformes à
la MTU et décharge ce traitement sur l'interface Ethernet où il est effectué dans le
matériel. Pour en savoir plus sur les avantages de LSO, consultez la rubrique Prise en
charge du déchargement d'envoi important.
Lorsque LSO est activé, les clients Azure peuvent voir de grandes tailles de trames
lorsqu'ils effectuent des captures de paquets. Ces grandes tailles de trames peuvent
amener certains clients à penser à tort qu’une fragmentation se produit ou qu'une
grande MTU est utilisée. Avec LSO, l'adaptateur Ethernet peut annoncer une taille de
segment maximale (MSS) plus grande à la pile TCP/IP afin de créer un paquet TCP plus
grand. Toute cette trame non segmentée est ensuite transmise à l'adaptateur Ethernet et
apparaît dans une capture de paquets effectuée sur la machine virtuelle. Mais le paquet
sera décomposé en de nombreuses trames plus petites par l'adaptateur Ethernet, selon
la MTU de l'adaptateur Ethernet.
Mise à l'échelle des fenêtres TCP MSS et PMTUD
Taille maximale des segments TCP

La taille maximale des segments TCP (MSS) est un paramètre qui limite la taille des
segments TCP, évitant ainsi la fragmentation des paquets TCP. Les systèmes
d'exploitation utilisent généralement cette formule pour définir les MSS :
MSS = MTU - (IP header size + TCP header size)

L'en-tête IP et l'en-tête TCP sont de 20 octets chacun, soit 40 octets au total. Ainsi, une
interface avec une MTU de 1 500 octets aura une MSS de 1 460 octets. Mais la MSS est
configurable.
Ce paramètre est validé dans la connexion en trois temps TCP lorsqu'une session TCP est
configurée entre une source et une destination. Les deux côtés envoient une valeur
MSS, et la valeur la plus faible est utilisée pour la connexion TCP.
Gardez à l'esprit que les MTU de la source et de la destination ne sont pas les seuls
facteurs qui déterminent la valeur MSS. Les périphériques réseau intermédiaires, comme
les passerelles VPN et notamment la passerelle VPN Azure, peuvent ajuster la MTU
indépendamment de la source et de la destination pour assurer des performances
réseau optimales.
Détection MTU du chemin d'accès

La MSS est négociée, mais il se peut qu'elle n'indique pas la MSS réelle qui peut être
utilisée. En effet, d'autres périphériques réseau dans le chemin entre la source et la
destination peuvent avoir une valeur MTU inférieure à celle de la source et de la
destination. Dans ce cas, le périphérique dont la MTU est inférieure au paquet
supprimera le paquet. L'appareil renverra un message « ICMP Fragmentation Needed
(Type 3, Code 4) » (Fragmentation ICMP requise (type 3, code 4)) contenant sa MTU. Ce
message ICMP permet à l'hôte source de réduire la MTU de son chemin de manière
appropriée. Ce processus est appelé Détection MTU du chemin d'accès ou PMTUD (Path
MTU Discovery).
Le processus PMTUD est inefficace et affecte les performances du réseau. Lorsque des
paquets sont envoyés et dépassent la MTU d'un chemin réseau, ils doivent être
retransmis avec une MSS inférieure. Si l'expéditeur ne reçoit pas le message « ICMP
Fragmentation Needed » (Fragmentation ICMP requise), la cause peut venir d'un pare-
feu réseau installé dans le chemin d'accès (communément appelé trou noir PMTUD) :
l'expéditeur ne sait pas qu'il doit baisser la MSS et retransmet continuellement le
paquet. C'est pourquoi nous déconseillons d'augmenter la MTU des machines virtuelles
Azure.
VPN et MTU
Si vous utilisez des machines virtuelles qui effectuent une encapsulation (comme les
VPN IPsec), vous devez tenir compte de quelques exigences supplémentaires
concernant la taille des paquets et la MTU. Les VPN ajoutent d’autres en-têtes aux
paquets, ce qui augmente la taille des paquets et nécessite une MSS inférieure.
Pour Azure, nous vous recommandons de définir la MSS TCP sur 1 350 octets et la MTU
de l’interface tunnel sur 1 400 octets. Pour plus d'informations, voir la page Appareils
VPN et paramètres IPSec/IKE.
Latence, durée des boucles et mise à l'échelle de la

fenêtre TCP
Latence et durée des boucles

La latence du réseau est régie par la vitesse de la lumière sur un réseau à fibre optique.
Le débit réseau TCP est également régi par la durée des bouches (Round-Trip Time ou
RTT) entre deux périphériques réseau.
Routage Distance Durée (unidirectionnel) RTT
New York à San Francisco 4 148 km 21 ms 42 ms
New York à London 5 585 km 28 ms 56 ms
New York à Sydney 15 993 km 80 ms 160 ms
Ce tableau indique la distance en ligne droite entre deux emplacements. Dans les
réseaux, la distance est généralement plus longue que la distance en ligne droite. Voici
une formule simple pour calculer la RTT minimale en fonction de la vitesse de la lumière
:
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
Vous pouvez utiliser 200 comme vitesse de propagation. C'est la distance, en kilomètres,
que parcourt la lumière en 1 milliseconde.
Prenons comme exemple la distance de New York à San Francisco. La distance en ligne
droite est de 4 148 km. En intégrant cette valeur à l'équation, nous obtenons le résultat
suivant :
Minimum RTT = 2 * (4,148 / 200)
Le résultat de l'équation est exprimé en millisecondes.
Si vous voulez obtenir les meilleures performances réseau, l'option logique consiste à
sélectionner les destinations les plus proches les unes des autres. Vous devriez
également concevoir votre réseau virtuel en essayant d’optimiser le chemin du trafic et
de réduire la latence. Pour plus d’informations, voir la section « Considérations relatives
à la conception du réseau » de cet article.
Effets de la latence et de la durée des bouches sur TCP
La durée des boucles a un impact direct sur le débit TCP maximal. Dans le protocole
TCP, la taille de la fenêtre est la quantité maximale de trafic qui peut être envoyée via
une connexion TCP avant que l'expéditeur ait besoin de recevoir un accusé de réception
du destinataire. Si la MSS TCP est définie sur 1 460 octets et la taille de la fenêtre TCP
sur 65 535 octets, l'expéditeur peut envoyer 45 paquets avant de devoir recevoir un
accusé de réception du destinataire. Si l'expéditeur n'obtient pas cet accusé de
réception, il retransmet les données. Voici la formule :
TCP window size / TCP MSS = packets sent
Dans cet exemple, 65 535 / 1 460 est arrondi à 45.
Cet état d’« attente d’un accusé de réception », mécanisme permettant d'assurer une
transmission fiable des données, est à l’origine de l’impact de la RTT sur le débit TCP.
Plus l'expéditeur attend un accusé de réception, plus il doit patienter avant d'envoyer
d'autres données.
Voici la formule pour calculer le débit maximal d'une connexion TCP unique :
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
Ce tableau indique le débit maximal en mégaoctets/seconde d'une connexion TCP

unique. (Pour une meilleure lisibilité, les mégaoctets sont utilisés comme unité de
mesure.)
Taille de la fenêtre Latence Débit maximal en Débit maximal en

TCP (octets) RTT (ms) mégaoctets/seconde mégabits/seconde
65 535 1 65,54 524,29
65 535 30 2.18 17,48
65 535 60 1,09 8,74
65 535 90 0,73 5,83
65 535 120 0,55 4.37
En cas de perte de paquets, le débit maximal d'une connexion TCP sera réduit pendant
que l'expéditeur retransmet les données qu'il a déjà envoyées.
Mise à l’échelle de la fenêtre TCP

La mise à l'échelle de la fenêtre TCP est une technique qui augmente dynamiquement la
taille de la fenêtre TCP pour permettre d'envoyer plus de données avant qu'un accusé
de réception ne soit nécessaire. Dans l'exemple précédent, 45 paquets seraient envoyés
avant qu'un accusé de réception ne soit requis. Si vous augmentez le nombre de
paquets pouvant être envoyés avant qu'un accusé de réception ne soit nécessaire,
réduisez le nombre de fois qu'un expéditeur attend l'accusé de réception afin
d’augmenter le débit TCP maximal.
Ce tableau illustre ces relations :
Taille de la fenêtre Latence Débit maximal en Débit maximal en

TCP (octets) RTT (ms) mégaoctets/seconde mégabits/seconde
65 535 30 2.18 17,48
131 070 30 4.37 34,95
262 140 30 8,74 69,91
524 280 30 17,48 139,81
Mais la valeur de l'en-tête TCP pour la taille de la fenêtre TCP n'est que de 2 octets, ce
qui signifie que la valeur maximale pour une fenêtre de réception est de 65 535 octets.
Pour augmenter la taille maximale de la fenêtre, un facteur d'échelle de la fenêtre TCP a
été introduit.
Le facteur d'échelle est également un paramètre que vous pouvez configurer dans un
système d'exploitation. Voici la formule pour calculer la taille de la fenêtre TCP en
utilisant des facteurs d'échelle :
TCP window size = TCP window size in bytes * (2^scale factor)
Voici le calcul pour un facteur d'échelle de fenêtre de 3 octets et une taille de fenêtre de
65 535 octets :
65,535 * (2^3) = 262,140 bytes
Un facteur d'échelle de 14 octets donne une taille de fenêtre TCP de 14 octets (le
décalage maximal autorisé). La taille de la fenêtre TCP sera de 1 073 725 440 octets (8,5
gigabits).
Prise en charge de la mise à l'échelle de la fenêtre TCP
Windows peut définir différents facteurs d'échelle pour différents types de connexion.
(Les classes de connexions incluent les centres de données, Internet, etc.) Vous utilisez la
commande PowerShell Get-NetTCPConnection pour afficher le type de connexion de
mise à l'échelle de la fenêtre :
PowerShell
Get-NetTCPConnection
Vous pouvez utiliser la commande PowerShell Get-NetTCPSetting pour afficher les

valeurs de chaque classe :
PowerShell
Get-NetTCPSetting
Vous pouvez définir la taille initiale de la fenêtre TCP et le facteur d'échelle TCP dans
Windows en utilisant la commande PowerShell Set-NetTCPSetting . Pour plus
d’informations, voir Set-NetTCPSetting.
PowerShell
Set-NetTCPSetting
Voici les paramètres TCP effectifs pour AutoTuningLevel :
AutoTuningLevel Facteur de mise à Multiplicateur de mise Formule pour

l’échelle à l’échelle calculer la taille maximale
de la fenêtre
Désactivé None None Taille de la fenêtre
Restreint 4 2^4 Taille de la fenêtre * (2^4)
Très restreinte 2 2^2 Taille de la fenêtre * (2^2)
Normal 8 2^8 Taille de la fenêtre * (2^8)
Expérimental 14 2^14 Taille de la fenêtre * (2^14)
Ces paramètres sont les plus susceptibles d'affecter les performances TCP, mais gardez à
l'esprit que de nombreux autres facteurs sur Internet, hors du contrôle d’Azure, peuvent
également affecter les performances TCP.
Augmenter la taille de la MTU

Puisqu’une MTU plus grande signifie une MSS plus grande, vous pouvez vous demander
si l'augmentation de la MTU pourrait augmenter les performances TCP. Probablement
pas. Il y a des avantages et des inconvénients liés à la taille des paquets au-delà du seul
trafic TCP. Comme nous l'avons vu précédemment, les facteurs les plus importants
affectant la performance du débit TCP sont la taille de la fenêtre TCP, la perte de
paquets et la valeur RTT.
） Important
Nous déconseillons clients Azure de modifier la valeur MTU par défaut des
Mise en réseau accélérée et mise à l'échelle côté

réception
Mise en réseau accélérée
Les fonctions réseau de la machine virtuelle ont toujours été gourmandes en ressources
processeur, tant sur la machine virtuelle invitée que sur l'hyperviseur/hôte. Chaque
paquet qui transite par l'hôte est traité dans un logiciel par le processeur hôte, y compris
toutes les encapsulations et décapsulations du réseau virtuel. Ainsi, plus le trafic qui
passe par l'hôte est important, plus le processeur est sollicité. Et si le processeur hôte est
occupé par d’autres opérations, cela affectera également le débit et la latence du réseau.
Azure règle ce problème grâce à la mise en réseau accélérée.
La mise en réseau accélérée offre une latence réseau ultra-faible constante grâce à un
matériel programmable interne Azure et à des technologies comme SR-IOV. La mise en
réseau accélérée déplace une grande partie de la pile réseau définie par le logiciel Azure
des processeurs vers les cartes SmartNIC basées sur FPGA. Ce changement permet aux
applications des utilisateurs finaux de récupérer des cycles de calcul, ce qui réduit la
charge sur la machine virtuelle, diminue la gigue et l’incohérence de la latence. En
d'autres termes, les performances peuvent être plus déterministes.
La mise en réseau accélérée améliore les performances en permettant à la machine

virtuelle invitée de contourner l'hôte et d'établir un chemin de données directement
avec la carte SmartNIC de l'hôte. Voici quelques avantages de la mise en réseau
accélérée :
Latence plus faible/Nombre supérieur de paquets par seconde (pps) : la

suppression du commutateur virtuel du chemin de données évite que les paquets
liés au traitement des stratégies séjournent sur l'hôte, ce qui augmente le nombre
de paquets pouvant être traités dans la machine virtuelle.
Instabilité réduite : le traitement du commutateur virtuel dépend de la stratégie à

appliquer et de la charge de travail du processeur qui effectue le traitement. Le
déchargement des stratégies sur le matériel supprime cette variabilité en
fournissant des paquets directement à la machine virtuelle, en supprimant l’hôte
dans la communication de la machine virtuelle et toutes les interruptions de
logiciel et les changements de contexte.
Utilisation réduite du processeur : en contournant le commutateur virtuel de

l'hôte, le processeur utilise moins de ressources pour traiter le trafic réseau.
Pour utiliser la mise en réseau accélérée, vous devez l'activer explicitement sur chaque
machine virtuelle applicable. Consultez Créer une machine virtuelle Linux avec la mise en
réseau accélérée pour obtenir des instructions.
Mise à l'échelle côté réception

La mise à l'échelle côté réception (Receive Side Scaling ou RSS) est une technologie de
pilote réseau qui distribue plus efficacement la réception du trafic réseau en répartissant
le traitement de réception entre plusieurs processeurs dans un système multiprocesseur.
Pour simplifier, RSS permet à un système de traiter plus de trafic reçu en utilisant tous
les processeurs disponibles au lieu d'un seul. Pour obtenir des informations plus
techniques sur RSS, consultez Introduction à la mise à l'échelle côté réception.
Pour obtenir les meilleures performances lorsque la mise en réseau accélérée est activée
sur une machine virtuelle, vous devez activer RSS. RSS peut également offrir des
avantages sur les machines virtuelles qui n'utilisent pas la mise en réseau accélérée. Pour
un aperçu sur la façon de vérifier si RSS est activé et comment le faire le cas échéant,
voir Optimiser le débit du réseau des machines virtuelles Azure.
Assassinat TCP TIME_WAIT et TIME_WAIT

TCP TIME_WAIT est un autre paramètre courant qui affecte les performances du réseau
et des applications. Sur les machines virtuelles occupées qui ouvrent et ferment
plusieurs sockets, soit en tant que clients, soit en tant que serveurs (IP source : port
source + IP de destination : port de destination), pendant le fonctionnement TCP
normal, un socket donné peut finir dans un état TIME_WAIT sur une longue période.
L'état TIME_WAIT a pour but de permettre aux données supplémentaires d'être
transmises sur un socket avant sa fermeture. Ainsi, les piles TCP/IP empêchent
généralement la réutilisation d'un socket en supprimant silencieusement le paquet TCP
SYN du client.
La durée pendant laquelle un socket est à l’état TIME_WAIT est configurable. Elle peut
varier de 30 à 240 secondes. Les sockets constituent une ressource limitée, et le nombre
de sockets qui peuvent être utilisés à tout moment est configurable. (Le nombre de
sockets disponibles est généralement d'environ 30 000.) Si les sockets disponibles sont
consommés, ou si les paramètres TIME_WAIT des clients et des serveurs ne
correspondent pas, et qu'une machine virtuelle tente de réutiliser un socket à un état
TIME_WAIT, les nouvelles connexions échoueront car les paquets TCP SYN sont
supprimés en silence.
La valeur de la plage de ports pour les sockets sortants est généralement configurable
dans la pile TCP/IP d'un système d'exploitation. C’est également le cas pour les
paramètres TCP TIME_WAIT et la réutilisation d’un socket. La modification de ces valeurs
peut potentiellement améliorer l'évolutivité. Mais, selon la situation, ces changements
pourraient provoquer des problèmes d'interopérabilité. Faites attention si vous modifiez
ces valeurs.
Vous pouvez utiliser l'assassinat TIME_WAIT pour résoudre ce problème de mise à

l'échelle. L'assassinat TIME_WAIT permet de réutiliser un socket dans certaines
situations, comme lorsque le numéro de séquence dans le paquet IP de la nouvelle
connexion dépasse le numéro de séquence du dernier paquet de la connexion
précédente. Dans ce cas, le système d'exploitation permettra d'établir la nouvelle
connexion (il acceptera le nouvelle valeur SYN/ACK) et forcera la fermeture de la
connexion précédente qui était dans un état TIME_WAIT. Cette capacité est prise en
charge sur les machines virtuelles Windows dans Azure. Pour en savoir plus sur la prise
en charge dans d'autres machines virtuelles, contactez l’éditeur du système
d'exploitation.
Pour en savoir plus sur la configuration des paramètres TCP TIME_WAIT et la plage de
ports source, voir Paramètres pouvant être modifiés pour améliorer les performances du
réseau.
Facteurs du réseau virtuel pouvant affecter les

performances
Débit sortant maximal de la machine virtuelle

Azure offre une variété de tailles et de types de machines virtuelles, qui présentent une
combinaison différente de capacités de performances. Une de ces capacités est le débit
réseau (ou bande passante), mesurée en mégabits par seconde (Mbit/s). Étant donné
que les machines virtuelles sont hébergées sur du matériel partagé, la capacité du
réseau doit être répartie équitablement entre les machines virtuelles partageant le
même matériel. Les machines virtuelles plus volumineuses bénéficient d’une plus grande
bande passante que les machines plus petites.
La bande passante réseau allouée à chaque machine virtuelle est mesurée en fonction
du trafic sortant de la machine virtuelle. L’ensemble du trafic réseau quittant la machine
virtuelle est mesuré en fonction de la limite d’allocation, quelle que soit la destination.
Par exemple, si une machine virtuelle se voit allouer une limite de 1 000 Mbit/s, cette
limite s’applique de toute façon, que le trafic sortant soit destiné à une machine virtuelle
du réseau virtuel ou à une machine en dehors d’Azure.
Le trafic en entrée n’est pas compté ou limité directement. Mais il existe d’autres
facteurs, tels que les limites en termes de processeur et de stockage, susceptibles
d’affecter la capacité d’une machine virtuelle à traiter les données entrantes.
La mise en réseau accélérée est conçue pour améliorer les performances du réseau,
notamment la latence, le débit et le taux d’utilisation des processeurs. La mise en réseau
accélérée peut améliorer le débit de la machine virtuelle, mais en deçà de la limite de
bande passante allouée à la machine virtuelle.
Les machines virtuelles Azure doivent toujours être associées à au moins une interface
réseau. Il peut y en avoir plusieurs. La bande passante allouée à une machine virtuelle
représente l’intégralité du trafic sortant sur l’ensemble des interfaces réseau associées à
la machine. En d’autres termes, la bande passante est allouée machine virtuelle par
machine virtuelle, quel que soit le nombre d’interfaces réseau associées à cette machine.
Le débit sortant attendu et le nombre d’interfaces réseau prises en charge par chaque
taille de machine virtuelle sont détaillés dans la section Tailles des machines virtuelles
Windows dans Azure. Pour afficher le débit maximal, sélectionnez un type, par exemple
Usage général, puis recherchez la section consacrée aux séries de tailles sur la page
résultante (par exemple, « Série Dv2 »). Pour chaque série, un tableau fournit les
spécifications réseau dans la dernière colonne, sous le titre « Nombre max de cartes
réseau / Bande passante réseau attendue (Mbit/s) ».
Cette limite de débit s’applique à la machine virtuelle. Le débit n'est pas affecté par ces
facteurs :
Nombre d'interfaces réseau : La limite de bande passante s’applique à l’ensemble

du trafic sortant en provenance de la machine virtuelle.
Mise en réseau accélérée : bien que cette fonctionnalité puisse être utile pour
atteindre la limite publiée, elle ne modifie pas cette limite.
Destination du trafic : toutes les destinations s’inscrivent dans la limite de sortie.
Protocole : L’intégralité du trafic sortant, sur l’ensemble des protocoles, s’inscrit

dans la limite.
Pour plus d’informations, consultez Bande passante réseau des machines virtuelles.
Considérations relatives aux performances Internet

Comme expliqué tout au long de cet article, des facteurs sur Internet et hors du contrôle
d'Azure peuvent affecter les performances du réseau. Voici quelques-uns de ces
facteurs :
Latence : La durée des boucles entre deux destinations peut être affectée par des
problèmes sur les réseaux intermédiaires, par un trafic qui ne prend pas le chemin
le plus court, et par des chemins de peering non optimaux.
Perte de paquets : Une perte de paquets peut être causée par l'encombrement du
réseau, des problèmes de chemin physique et des périphériques réseau moins
performants.
Taille de MTU/fragmentation : La fragmentation le long du chemin peut entraîner

des retards dans la réception des données ou une réception de paquets en
désordre, ce qui peut affecter la remise des paquets.
Traceroute est un bon outil pour mesurer les performances du réseau (notamment la
perte de paquets et la latence) le long de chaque chemin réseau entre un périphérique
source et un périphérique cible.
Considérations relatives à la conception du réseau

Outre les considérations abordées précédemment dans cet article, la topologie d'un
réseau virtuel peut affecter les performances du réseau. Par exemple, une conception
« hub-and-spoke » qui renvoie le trafic mondial vers un réseau virtuel à un seul
concentrateur entraînera une latence du réseau, ce qui affectera ses performances
globales.
Le nombre de périphériques réseau par lesquels le trafic réseau transite peut également
affecter la latence globale. Par exemple, dans une conception « hub-and-spoke », si le
trafic transite via une appliance virtuelle réseau spoke et une appliance virtuelle de
concentrateur avant d’être dirigé vers Internet, les appliances virtuelles réseau peuvent
entraîner une latence.
Régions Azure, réseaux virtuels et latence

Les régions Azure sont composées de plusieurs centres de données qui existent dans
une zone géographique générale. Ces centres de données peuvent ne pas être
physiquement adjacents. Dans certains cas, ils sont séparés par une distance pouvant
atteindre 10 kilomètres. Le réseau virtuel est une superposition logique sur le réseau du
centre de données physique Azure. Un réseau virtuel n'implique aucune topologie de
réseau spécifique au sein du centre de données.
Par exemple, deux machines virtuelles figurant dans le même réseau virtuel et le même
sous-réseau peuvent se trouver dans des racks, des lignes ou même des centres de
données différents. Elles pourraient être séparées par plusieurs mètres ou plusieurs
kilomètres de câble à fibre optique. Cette variation pourrait entraîner une latence
variable (une différence de quelques millisecondes) entre différentes machines virtuelles.
L'emplacement géographique des machines virtuelles et la latence potentielle qui en

résulte entre deux machines virtuelles peuvent être influencés par la configuration des
groupes à haute disponibilité et des zones de disponibilité. Mais la distance entre les
centres de données d'une région est spécifique à cette région et elle est principalement
influencée par la topologie des centres de données de cette région.
Épuisement du port NAT source

Un déploiement dans Azure peut communiquer avec des points de terminaison en
dehors d’Azure sur le réseau Internet public et/dans l’espace d’adressage IP public.
Quand une instance démarre une connexion sortante, Azure mappe dynamiquement
l’adresse IP privée à une adresse IP publique. Une fois ce mappage créé, le trafic de
retour pour le flux sortant peut aussi atteindre l’adresse IP privée d’où provient le flux.
Pour chaque connexion sortante, Azure Load Balancer doit maintenir ce mappage
pendant un certain temps. Étant donné la nature multilocataire d'Azure, le maintien de
ce mappage pour chaque flux sortant de chaque machine virtuelle peut consommer
beaucoup de ressources. Il existe donc des limites fixées et basées sur la configuration
du réseau virtuel Azure. Ou, pour simplifier, une machine virtuelle Azure ne peut
uniquement établir un certain nombre de connexions sortantes à un moment donné.
Lorsque ces limites sont atteintes, la machine virtuelle ne pourra plus établir de
connexions sortantes.
Mais ce comportement est configurable. Pour plus d'informations sur SNAT et
l'épuisement de port SNAT, consultez cet article.
Mesurer les performances du réseau sur Azure

Un certain nombre des performances maximales de cet article sont liées à la latence du
réseau et à la durée des bouches (RTT) entre deux machines virtuelles. Cette section
fournit quelques suggestions sur la façon de tester la latence/RTT et les performances
TCP et des machines virtuelles du réseau. Vous pouvez régler les valeurs TCP/IP et
réseau et tester leurs performances, comme discuté précédemment, en utilisant les
techniques décrites dans cette section. Vous pouvez intégrer des valeurs de latence,
MTU, MSS et de taille de fenêtre aux calculs fournis précédemment et comparer les
valeurs maximales théoriques aux valeurs réelles que vous observez pendant les tests.
Mesurer la durée des bouches (RTT) et la perte de

paquets
Les performances TCP dépendent fortement de RTT et de la perte de paquets. L'utilitaire
PING disponible sur Windows et Linux fournit le moyen le plus simple de mesurer la
durée RTT et la perte de paquets. Le résultat affiché par PING indiquera la latence
minimale/maximale/moyenne entre une source et une destination. Il précisera
également la perte de paquets. PING utilise le protocole ICMP par défaut. Vous pouvez
utiliser PsPing pour tester TCP RTT. Pour plus d'informations, consultez PsPing.
Mesurer le débit réel d'une connexion TCP

NTttcp est un outil permettant de tester les performances TCP d'une machine virtuelle
Linux ou Windows. Vous pouvez modifier divers paramètres TCP et tester leurs
performances en utilisant NTttcp. Pour plus d’informations, consultez ces ressources :
Test de bande passante/débit (NTttcp)
Utilitaire NTttcp
Mesurer la bande passante réelle d'une machine virtuelle

Vous pouvez tester les performances de différents types de machines virtuelles, de mises
en réseau accélérées, etc. en utilisant un outil appelé iPerf. iPerf est également
disponible sur Linux et Windows. iPerf peut utiliser TCP ou UDP pour tester le débit
global du réseau. Les tests de débit TCP iPerf sont influencés par les facteurs abordés
dans cet article (notamment la latence et la durée RTT). Ainsi, UDP peut donner de
meilleurs résultats si vous voulez juste tester le débit maximal.
Pour plus d’informations, voir les articles suivants :
Résolution des problèmes de performances réseau ExpressRoute
Comment valider un débit VPN sur un réseau virtuel
Détecter les comportements TCP inefficaces

Dans les captures de paquets, les clients Azure peuvent voir des paquets TCP avec des
indicateurs TCP (SACK, DUP ACK, RETRANSMIT et FAST RETRANSMIT) qui pourraient
signaler des problèmes de performance réseau. Ces paquets indiquent spécifiquement
les problèmes réseau qui résultent de la perte de paquets. Mais la perte de paquets
n'est pas nécessairement causée par des problèmes de performance Azure. Ces baisses
de performance pourraient être le résultat de problèmes au niveau des applications, du
système d'exploitation, ou d’autres problèmes qui pourraient ne pas être directement
liés à la plate-forme Azure.
Sans oublier que certains événements ACK de retransmission et de duplication sont

normaux sur un réseau. Les protocoles TCP ont été conçus pour être fiables. La présence
de ces paquets TCP dans une capture de paquets n'indique pas nécessairement un
problème de réseau systémique, à moins que leur nombre soit excessif.
Néanmoins, ces types de paquets sont des indications que le débit TCP n'atteint pas ses
performances maximales, pour les raisons discutées dans d’autres sections de cet article.
Étapes suivantes
Maintenant que vous en savez plus sur l'optimisation des performances TCP/IP pour les
machines virtuelles Azure, vous pouvez examiner d'autres considérations sur la
planification des réseaux virtuels ou en savoir plus sur la connexion et la configuration
des réseaux virtuels.
Bande passante réseau des machines
virtuelles
Azure offre de nombreuses tailles et types de machines virtuelles, qui présentent une
combinaison différente de capacités de performances. L’une de ces capacités est la
bande passante réseau (ou débit réseau), mesurée en mégabits par seconde (Mbits/s).
Étant donné que les machines virtuelles sont hébergées sur du matériel partagé, la
capacité du réseau doit être répartie équitablement entre les machines virtuelles
partageant le même matériel. Les machines virtuelles plus volumineuses bénéficient
d’une plus grande bande passante que les machines plus petites.
La bande passante réseau allouée à chaque machine virtuelle est mesurée en fonction
du trafic sortant de la machine virtuelle. L’ensemble du trafic réseau quittant la machine
virtuelle est mesuré en fonction de la limite d’allocation, quelle que soit la destination.
Par exemple, si une machine virtuelle a une limite de 1 000 Mbits/s, cette limite
s’applique que le trafic sortant soit destiné à une autre machine virtuelle du même
réseau virtuel ou qu’il se dirige en dehors d’Azure.
L’entrée n’est pas mesurée ni limitée directement. Toutefois, il existe d’autres facteurs,
tels que les limites de processeur et de stockage, qui peuvent affecter la capacité d’une
machine virtuelle à traiter des données entrantes.
La mise en réseau accélérée est une fonctionnalité conçue pour améliorer les
performances du réseau, notamment la latence, le débit et le taux d’utilisation des
processeurs. La mise en réseau accélérée peut améliorer le débit de la machine virtuelle,
mais en deçà de la limite de bande passante allouée à la machine virtuelle. Pour en
savoir plus sur la mise en réseau accélérée, consultez « Mise en réseau accélérée pour
les machines virtuelles Windows ou Linux ».
Les machines virtuelles Azure doivent être associées à une interface réseau minimum. La
bande passante allouée à une machine virtuelle représente l’intégralité du trafic sortant
sur l’ensemble des interfaces réseau associées à une machine virtuelle. En d’autres
termes, la bande passante est allouée machine virtuelle par machine virtuelle, quel que
soit le nombre d’interfaces réseau associées à cette machine. Pour savoir combien
d’interfaces réseau les machines virtuelles Azure de différentes tailles peuvent prendre
en charge, consultez les informations sur les tailles de machines virtuelles Windows et
Linux.
Débit réseau attendu

Le débit sortant attendu et le nombre d’interfaces réseau prises en charge par chaque
taille de machine virtuelle sont détaillés dans les spécifications des tailles de machine
virtuelle Azure Windows et Linux. Sélectionnez un type, comme le type d’usage général,
puis choisissez une taille et une série dans la page qui en résulte, par exemple « Dv2-
series ». Chaque série comporte une table qui détaille les spécifications de mise en
réseau, dont la dernière colonne intitulée
Nombre max de cartes réseau/Performance réseau attendue (Mbits/s).
Cette limite de débit s’applique à la machine virtuelle. Le débit n’est pas affecté par les
facteurs suivants :
Nombre d’interfaces réseau : la limite de bande passante inclut l’ensemble du

trafic sortant en provenance de la machine virtuelle.
Mise en réseau accélérée : bien que la fonctionnalité puisse être utile pour
atteindre la limite publiée, elle ne modifie pas cette limite.
Destination du trafic : toutes les destinations s’inscrivent dans la limite de sortie.
Protocole : l’intégralité du trafic sortant, sur l’ensemble des protocoles, s’inscrit

dans la limite.
Limites de flux de réseau

En plus de la bande passante, le nombre de connexions réseau présentes sur une
machine virtuelle à un moment donné peut affecter ses performances réseau. La pile de
mise en réseau Azure maintient l’état pour chaque direction d’une connexion TCP/UDP
dans des structures de données appelées « flux ». Deux flux sont créés pour une
connexion TCP/UDP classique, l’un pour la direction entrante et l’autre pour la sortante.
Le transfert de données entre les points de terminaison nécessite la création de

plusieurs flux en plus des flux qui effectuent le transfert de données. Certains exemples
sont des flux créés pour une résolution DNS et des flux créés pour des sondes
d’intégrité de l’équilibreur de charge. Les appliances virtuelles réseau, comme les
passerelles, les proxys et les pare-feu, voient des flux créés pour les connexions
terminées au niveau de l’appliance et provenant de l’appliance.
Recommandations relatives aux limites de flux
et aux connexions actives
Aujourd’hui, la pile réseau Azure prend en charge 1 million de flux au total (500 000
entrants et 500 000 sortants) pour une machine virtuelle. Le nombre total de connexions
actives gérées par une machine virtuelle dans différents scénarios est le suivant.
Les machines virtuelles appartenant à un réseau virtuel peuvent gérer

500 000 connexions actives pour toutes les tailles de machine virtuelle avec
500 000 flux actifs dans chaque direction.
Les machines virtuelles avec des appliances virtuelles réseau, telles qu’une
passerelle, un proxy ou un pare-feu, peuvent gérer 250 000 connexions actives
avec 500 000 flux actifs dans chaque direction, en raison du transfert et de la
création de nouveaux flux sur la configuration de la nouvelle connexion jusqu’au
tronçon suivant, comme indiqué dans le diagramme ci-dessus.
Une fois cette limite atteinte, les autres connexions sont supprimées. Le taux
d’établissement et de fin de connexions peut également affecter le niveau de
performance réseau, car l’établissement et la fin des connexions partagent l’UC avec les
routines de traitement de paquets. Nous vous recommandons d’évaluer les charges de
travail pour les modèles de trafic attendus et d’effectuer un scale-out de manière
appropriée en fonction de vos besoins en matière de niveau de performance.
Des métriques permettant de suivre le nombre de flux réseau et le taux de création des
flux sur votre machine virtuelle ou sur des instances de groupe de machines virtuelles
identiques sont disponibles dans Azure Monitor.
Étapes suivantes
Optimiser le débit réseau d’un système d’exploitation de machine virtuelle
Tester le débit réseau d’une machine virtuelle

Déplacer des machines virtuelles Azure
d’une région à une autre
Ce tutoriel montre comment déplacer dans une autre région Azure des machines
virtuelles Azure ainsi que les ressources réseau et de stockage associées, en utilisant
Azure Resource Mover.
Azure Resource Mover vous permet de déplacer des ressources Azure d’une région
Azure à l’autre. Vous pouvez migrer vos ressources vers une autre région pour de
multiples raisons. Par exemple, pour tirer parti d’une nouvelle région Azure, pour
déployer des fonctionnalités ou des services disponibles dans des régions spécifiques
uniquement, pour répondre à des exigences de stratégie et de gouvernance internes ou
pour respecter des exigences de planification de la capacité.
＂ Déplacer des machines virtuelles Azure dans une autre région avec Azure Resource
Mover.
＂ Déplacer les ressources associées aux machines virtuelles dans une autre région.
７ Notes
Les tutoriels indiquent le moyen le plus rapide de tester un scénario, et ils utilisent
les options par défaut lorsque cela est possible.
Connexion à Azure
commencer et connectez-vous au portail Azure .
Prérequis
Avant de commencer, vérifiez que les conditions suivantes sont remplies :
Condition Description
requise
requise
Prise en Consultez les régions prises en charge et les autres questions courantes.
charge de
Resource
Mover
Autorisations Veillez à disposer d’un accès Propriétaire sur l’abonnement contenant les
d’abonnement ressources que vous souhaitez déplacer.
Pourquoi ai-je besoin d’un accès Propriétaire ? La première fois que vous
ajoutez une ressource pour une paire source et destination spécifique dans un
abonnement Azure, Resource Mover crée une identité managée affectée par le
système (anciennement Managed Service Identity, MSI) qui est approuvée par
l’abonnement. Afin de créer l’identité et lui affecter le rôle demandé
(Contributeur ou Administrateur de l’accès utilisateur dans l’abonnement
source), le compte que vous utilisez pour ajouter des ressources a besoin des
autorisations Propriétaire sur l’abonnement. Explorez en détail les rôles Azure.
Prise en - Assurez-vous que les machines virtuelles que vous souhaitez déplacer sont
charge des prises en charge.
machines - Vérifiez les machines virtuelles Windows prises en charge.
virtuelles - Vérifiez les machines virtuelles Linux et les versions du noyau prises en charge.
Contrôlez les paramètres de calcul, de stockage et de réseau pris en charge.
Abonnement L’abonnement dans la région de destination a besoin d’un quota suffisant pour
de destination créer les ressources que vous déplacez dans la région cible. S’il n’a pas de quota,
demandez des limites supplémentaires.
Frais relatifs à Vérifiez le tarif et les frais associés à la région cible vers laquelle vous déplacez
la région de des machines virtuelles. Utilisez la calculatrice de prix pour vous aider.
destination
Préparer les machines virtuelles

Pour préparer des machines virtuelles pour le déplacement, procédez comme suit :
1. Après avoir vérifié que les machines virtuelles répondaient aux conditions requises,
vérifiez que les machines virtuelles que vous souhaitez déplacer sont allumées.
Tous les disques de machines virtuelles que vous souhaitez mettre à disposition
dans la région de destination doivent être attachés et initialisés dans la machine
virtuelle.
2. Vérifiez que les machines virtuelles disposent des certificats racines approuvés les
plus récents et d’une liste de révocation de certificats mise à jour. Pour ce faire :
Sur les machines virtuelles Windows, installez les dernières mises à jour
Windows.
Sur les machines virtuelles Linux, suivez les instructions du distributeur afin
que les machines disposent des derniers certificats et des listes de révocation
de certificats les plus récentes.
3. Autorisez une connexion sortante à partir des machines virtuelles :
Si vous utilisez un proxy de pare-feu basé sur des URL pour contrôler la
connectivité sortante, autorisez l’accès à ces URL.
Si vous utilisez des règles de groupe de sécurité réseau (NSG) pour contrôler
la connexion sortante, créez ces règles d’étiquette de service.
Sélection des ressources

Notez que tous les types de ressources pris en charge dans les groupes de ressources
de la région source sélectionnée sont affichés. Les ressources qui ont déjà été ajoutées
pour passer d’une région à une autre ne sont pas affichées. Vous déplacez des
ressources dans une région cible du même abonnement que la région source. Si vous
voulez changer d’abonnement, vous pouvez le faire après le déplacement des
ressources.
Pour sélectionner les ressources que vous souhaitez déplacer, procédez comme suit :
1. Dans le portail Azure, recherchez resource mover. Sous Services, sélectionnez

2. Dans le volet Vue d’ensemble, sélectionnez Bien démarrer.


3. Sous l’onglet Déplacer des ressources>Source + destination, procédez comme

suit :
a. Sélectionnez l’abonnement et la région source.
b. Sous Destination, sélectionnez la région vers laquelle vous souhaitez déplacer
c. Sélectionnez Suivant.

4. Sous l’onglet Déplacer des ressources>Ressources à déplacer, procédez comme

suit :
a. Sélectionnez l’option Sélectionner des ressources.
b. Dans Sélectionner des ressources, sélectionnez la machine virtuelle. Vous

pouvez uniquement ajouter des ressources prises en charge pour le
déplacement.
c. Sélectionnez Terminé.
d. Sélectionnez Suivant.
5. Dans Vérifier, contrôlez les paramètres de source et de destination.


6. Cliquez sur Continuer pour commencer à ajouter les ressources.
7. Une fois le processus d’ajout terminé, dans le volet Notifications, sélectionnez

Ressources ajoutées pour le déplacement.
8. Après avoir sélectionné la notification, passez en revue les ressources dans la page
Entre régions.
７ Notes
Les ressources ajoutées présentent l’état Préparation en attente.

Le groupe de ressources pour les machines virtuelles est ajouté
automatiquement.
Si vous souhaitez supprimer une ressource d’une collection de déplacement,
la méthode permettant d’effectuer cette opération dépend de l’étape où vous
vous trouvez dans la procédure de déplacement. Plus d’informations
Résoudre les erreurs de dépendance
Pour résoudre les dépendances avant le déplacement, procédez comme suit :
1. Les dépendances sont automatiquement validées en arrière-plan lorsque vous

ajoutez les ressources. Si vous voyez toujours l’option Valider les dépendances,
sélectionnez-la pour déclencher la validation manuellement.
2. Si des dépendances sont trouvées, cliquez sur Ajouter des dépendances pour les
ajouter.
3. Dans Ajouter des dépendances, conservez l’option par défaut Afficher toutes les
dépendances.
L’option Afficher toutes les dépendances itère au sein de toutes les

dépendances directes et indirectes d’une ressource. Par exemple, pour une
machine virtuelle, la carte réseau, le réseau virtuel, les groupes de sécurité
réseau, etc. sont affichés.
L’option Afficher uniquement les dépendances de premier niveau n’affiche
que les dépendances directes. Par exemple, pour une machine virtuelle, la
carte réseau est affichée, mais pas le réseau virtuel.
4. Sélectionnez les ressources dépendantes que vous souhaitez ajouter, puis Ajouter
des dépendances. Vous pouvez suivre la progression dans les notifications.
5. Les dépendances sont automatiquement validées en arrière-plan une fois que vous
les avez ajoutées. Si vous voyez un bouton Valider les dépendances, sélectionnez-
le pour déclencher la validation manuelle.
Déplacer le groupe de ressources source

Avant de pouvoir préparer et déplacer une machine virtuelle, le groupe de ressources de
cette machine virtuelle doit être présent dans la région cible.
Préparer le déplacement du groupe de ressources source

Pendant le processus de préparation, Resource Mover génère des modèles Azure
Resource Manager (ARM) à l’aide des paramètres du groupe de ressources. Les
ressources à l’intérieur du groupe de ressources ne sont pas affectées.
Pour préparer le déplacement d’un groupe de ressources source, procédez comme

suit :
1. Dans le volet Entre régions, sélectionnez le groupe de ressources

source >Préparer.
2. Dans le volet Préparer les ressources, sélectionnez Préparer pour démarrer le

processus.

７ Notes
Après sa préparation, le groupe de ressources présente l’état Lancement du

déplacement en attente.

Pour démarrer le déplacement, procédez comme suit :
1. Dans le volet Entre régions, sélectionnez le groupe de ressources >Lancer le

déplacement.
2. Dans le volet Déplacer des ressources, sélectionnez Lancer le déplacement. Le

groupe de ressources passe à l’état Lancement du déplacement en cours.
3. Après l’initialisation du déplacement, le groupe de ressources cible est créé, en

fonction du modèle ARM généré. Le groupe de ressources source passe à l’état
Validation du déplacement en attente.
Pour valider et terminer la procédure de déplacement :
1. Dans Entre régions, sélectionnez le groupe de ressources >Valider le

déplacement.
2. Dans le volet Déplacer des ressources, sélectionnez Valider.
７ Notes
Après la validation du déplacement, le groupe de ressources source présente l’état

Suppression de la source en attente.
Préparer les ressources à déplacer

Maintenant que le groupe de ressources source est déplacé, vous pouvez préparer le
déplacement d’autres ressources qui sont à l’état Préparation en attente.
Pour déplacer des ressources qui sont dans l’état Préparation en attente, procédez
comme suit :
1. Dans le volet Entre régions, vérifiez que les ressources présentent maintenant
l’état Préparation en attente sans aucun problème répertorié. Si ce n’est pas le cas,
validez à nouveau et résolvez les problèmes en suspens.
2. Si vous souhaitez modifier les paramètres cibles avant de commencer le

déplacement, sélectionnez le lien dans la colonne Configuration de la destination
pour la ressource, puis modifiez les paramètres. Si vous modifiez les paramètres de
la machine virtuelle cible, la taille de cette machine ne doit pas être inférieure à
celle de la machine virtuelle source.
déplacement des autres ressources.
3. Sélectionnez les ressources que vous souhaitez préparer.
4. Sélectionnez Préparer.
７ Notes
Durant le processus de préparation, l’agent de mobilité Azure Site Recovery

est installé sur les machines virtuelles, en vue de leur réplication.
Les données des machines virtuelles sont répliquées régulièrement dans la
région cible. Cette opération n’a pas d’incidence sur la machine virtuelle
source.
Le déplacement de ressources génère des modèles ARM pour les autres
ressources sources.
Après leur préparation, les ressources présentent l’état Lancement du

Lancer le déplacement
Les ressources préparées, vous pouvez maintenant lancer le déplacement. Pour lancer le
déplacement, procédez comme suit :
1. Dans le volet Entre régions, sélectionnez les ressources avec l’état Lancement du
2. Sélectionnez Lancer le déplacement pour démarrer le processus.
3. Dans l’onglet Déplacer des ressources, sélectionnez Lancer le déplacement.


4. Suivez la progression du déplacement dans la barre de notification.
７ Notes
Pour les machines virtuelles, les machines virtuelles de réplication sont créées
dans la région cible. La machine virtuelle source est arrêtée, et un temps
d’interruption se produit (généralement en minutes).
Resource Mover recrée d’autres ressources à l’aide des modèles ARM
préparés. Il n’y a généralement pas de temps d’arrêt.
Après leur déplacement, les ressources présentent l’état Validation du
lancement en attente.
Valider ou ignorer le déplacement

Après le déplacement initial, vous pouvez décider de valider le déplacement ou de
l’abandonner.
Abandonner : vous pouvez abandonner un déplacement si vous effectuez un test

et que vous ne souhaitez pas déplacer réellement la ressource source. Si vous
abandonnez le déplacement, la ressource reviendra à l’état Lancement du
Valider : La validation termine le déplacement vers la région cible. Après sa
validation, une ressource source se présente avec l’état de Suppression de la source
en attente, et vous pouvez décider si vous voulez la supprimer.
Abandonner le déplacement
Vous pouvez abandonner le déplacement de la manière suivante :
1. Dans le volet Entre régions, sélectionnez les ressources avec l’état Validation du
déplacement en attente, puis cliquez sur Abandonner le déplacement.
2. Dans le volet Abandonner le déplacement, sélectionnez Abandonner.
７ Notes
Après l’abandon des ressources, les machines virtuelles présentent l’état Lancement
du déplacement en attente.
Valider le déplacement
Si vous voulez terminer la procédure de déplacement, validez le déplacement. Pour
valider le déplacement, procédez comme suit :
déplacement en attente, puis sélectionnez Valider le déplacement.
2. Dans le volet Valider les ressources, sélectionnez Valider.


3. Suivez la progression de la validation dans la barre de notification.

７ Notes
Après la validation du déplacement, les machines virtuelles arrêtent la

réplication. La machine virtuelle source n’est pas affectée par la validation.
La validation n’a pas d’incidence sur les ressources réseau sources.
Après la validation du déplacement, les ressources présentent l’état de
Configurer des paramètres après le

déplacement
Vous pouvez configurer les paramètres suivants après le processus de déplacement :
Le service Mobilité n’est pas désinstallé automatiquement sur les machines

virtuelles. Désinstallez-le manuellement ou laissez-le si vous envisagez de déplacer
à nouveau le serveur.
Modifiez les règles de contrôle d’accès en fonction du rôle (Azure RBAC) après le
déplacement.
Supprimer les ressources sources après la

validation
Après le déplacement, vous pouvez, si vous le souhaitez, supprimer les ressources dans
la région source. Pour supprimer les ressources sources après la validation :
７ Notes
Certaines ressources, telles que les coffres de clés et les serveurs SQL Server, ne
peuvent pas être supprimées à partir du portail et doivent être supprimées à partir
de la page de propriétés de la ressource.
1. Dans le volet Entre régions, sélectionnez le nom de la ressource source que vous
souhaitez supprimer.
2. Sélectionnez Supprimer la source.
Supprimer les ressources supplémentaires
créées pour le déplacement
Après le déplacement, vous pouvez supprimer manuellement la collection de
déplacement ainsi que les ressources Site Recovery qui ont été créées.
Avant de supprimer les ressources supplémentaires créées pour le déplacement, notez

que :
La collection de déplacement est masquée par défaut. Pour la voir, vous devez
activer les ressources masquées.
Le stockage du cache a un verrou. Avant de supprimer le stockage du cache, vous
devez d’abord supprimer le verrou.
Pour supprimer les ressources supplémentaires créées pour le déplacement, procédez

comme suit :
1. Localisez les ressources dans le groupe de ressources RegionMoveRG-

<sourceregion>-<target-region> .
2. Vérifiez que toutes les machines virtuelles et les autres ressources sources de la
région source ont été déplacées ou supprimées. Cette vérification permet de
s’assurer qu’aucune ressource en attente ne les utilise.
3. Supprimer les ressources :
Le nom de la collection de déplacement est movecollection-<sourceregion>-

<target-region> .
Le nom du compte de stockage de cache est resmovecache<guid> .

Le nom du coffre est ResourceMove-<sourceregion>-<target-region>-GUID .
Étapes suivantes
En savoir plus sur le déplacement de bases de données Azure SQL et de pools élastiques
vers une autre région.
Mover.
７ Notes
Connexion à Azure
Prérequis
requise
requise
charge de
Resource
Mover
destination

virtuelle.
Windows.

ressources.




suit :


suit :

déplacement.



Entre régions.
７ Notes

automatiquement.

ajouter.
dépendances.




suit :

source >Préparer.

processus.

７ Notes



déplacement.



déplacement.
７ Notes


comme suit :

７ Notes

source.
ressources sources.



７ Notes

l’abandonner.

７ Notes



７ Notes


déplacement

déplacement.

validation
７ Notes

que :

comme suit :


<target-region> .

Étapes suivantes
Mover.
７ Notes
Connexion à Azure
Prérequis
requise
requise
charge de
Resource
Mover
destination

virtuelle.
Windows.

ressources.




suit :


suit :

déplacement.



Entre régions.
７ Notes

automatiquement.

ajouter.
dépendances.




suit :

source >Préparer.

processus.

７ Notes



déplacement.



déplacement.
７ Notes


comme suit :

７ Notes

source.
ressources sources.



７ Notes

l’abandonner.

７ Notes



７ Notes


déplacement

déplacement.

validation
７ Notes

que :

comme suit :


<target-region> .

Étapes suivantes
Déplacer un groupe de sécurité réseau
Azure vers une autre région à l’aide du
Portail Azure
Il existe différents scénarios dans lesquels vous pouvez être amené à déplacer vos
groupe de sécurité réseau existants d’une région à une autre. Par exemple, vous pouvez
avoir besoin de créer un groupe de sécurité réseau avec la même configuration et les
mêmes règles de sécurité à des fins de test. Vous pouvez également déplacer un groupe
de sécurité réseau vers une autre région dans le cadre de la planification de la reprise
d’activité après sinistre.
Les groupes de sécurité Azure ne peuvent pas être déplacés d’une région vers une autre.
Toutefois, vous pouvez utiliser un modèle Azure Resource Manager pour exporter la
configuration existante et les règles de sécurité d’un groupe de sécurité réseau. Vous
pouvez ensuite déplacer la ressource dans une autre région en exportant le groupe de
sécurité réseau vers un modèle, en modifiant les paramètres pour qu’ils correspondent à
la région de destination, puis en déployant le modèle dans la nouvelle région. Pour plus
d’informations sur Resource Manager et les modèles, consultez Démarrage rapide :
Créer et déployer des modèles Azure Resource Manager à l’aide du portail Azure.
Prérequis
Vérifiez que le groupe de sécurité réseau Azure se trouve dans la région Azure à
partir de laquelle vous souhaitez effectuer le déplacement.
Les groupes de sécurité réseau Azure ne peuvent pas être déplacés entre les
régions. Vous devez associer le nouveau groupe de sécurité réseau à des
ressources dans la région cible.
Pour exporter une configuration de groupe de sécurité réseau et déployer un

modèle afin de créer un groupe de sécurité réseau dans une autre région, vous
devez disposer au minimum du rôle Contributeur de réseaux.
Identifiez la topologie du réseau source et toutes les ressources que vous utilisez
actuellement. Cette disposition comprend notamment les équilibreurs de charge,
les adresses IP publiques et les réseaux virtuels.
Vérifiez que votre abonnement Azure vous permet de créer des groupes de
sécurité réseau dans la région cible utilisée. Contactez le support pour activer le
quota requis.
Vérifiez que votre abonnement dispose de suffisamment de ressources pour

prendre en charge l’ajout de groupes de sécurité réseau pour ce processus.
Consultez Abonnement Azure et limites, quotas et contraintes de service.
Préparer et déplacer
Les étapes suivantes montrent comment préparer le groupe de sécurité réseau pour le
déplacement de la configuration et de la règle de sécurité à l’aide d’un modèle Resource
Manager et comment déplacer la configuration et les règles de sécurité du groupe de
sécurité réseau vers la région cible à l’aide du portail.
Exporter le modèle et le déployer à partir du portail

1. Connectez-vous au Portail Azure >Groupes de ressources.
2. Recherchez le groupe de ressources contenant le groupe de sécurité réseau source

et cliquez dessus.
3. Sélectionnez >Paramètres>Exporter le modèle.
4. Choisissez Déployer dans le panneau Exporter le modèle.
5. Cliquez sur MODÈLE>Modifier les paramètres pour ouvrir le fichier

parameters.json dans l’éditeur en ligne.
6. Pour modifier le paramètre du nom du groupe de sécurité réseau, modifiez la

propriété value sous parameters :
JSON
{
"$schema": "https://schema.management.azure.com/schemas/2015-
01-01/deploymentParameters.json#",
"parameters": {
"networkSecurityGroups_myVM1_nsg_name": {
"value": "<target-nsg-name>"
}
}
}
7. Remplacez la valeur du groupe de sécurité réseau source dans l’éditeur par le nom
de votre choix pour le groupe de sécurité réseau cible. Veillez à placer le nom entre
guillemets.
8. Cliquez sur Enregistrer dans l’éditeur.
9. Cliquez sur MODÈLE>Modifier le modèle pour ouvrir le fichier template.json dans

l’éditeur en ligne.
10. Pour modifier la région cible où la configuration et les règles de sécurité du

groupe de sécurité réseau seront déplacées, modifiez la propriété location sous
resources dans l’éditeur en ligne :
JSON
"resources": [
{
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2019-06-01",
"name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",
"location": "<target-region>",
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "2c846acf-58c8-416d-be97-ccd00a4ccd78",
}
}
]
11. Pour obtenir les codes d’emplacement des régions, consultez Emplacements
Azure . Le code d’une région est le nom de la région sans espace, USA Centre =
centralus.
12. Vous pouvez également changer d’autres paramètres dans le modèle ; ces
paramètres sont facultatifs en fonction de vos besoins :
Règles de sécurité : vous pouvez modifier les règles déployées dans le

groupe de sécurité réseau cible en ajoutant ou en supprimant des règles
dans la section securityRules du fichier template.json :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"name": "
[parameters('networkSecurityGroups_myVM1_nsg_name')]",
"properties": {
"securityRules": [
{
"name": "RDP",
"etag": "W/\"c630c458-6b52-4202-8fd7-
172b7ab49cf5\"",
"properties": {
"protocol": "TCP",
"sourcePortRange": "*",
"destinationPortRange": "3389",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 300,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [],
"sourceAddressPrefixes": [],
"destinationAddressPrefixes": []
}
},
]
}
Pour terminer l’ajout ou la suppression des règles dans le groupe de sécurité

réseau cible, vous devez également modifier les types de règles
personnalisées à la fin du fichier template.json selon le format de l’exemple
ci-dessous :
JSON
{
"type":
"Microsoft.Network/networkSecurityGroups/securityRules",
"apiVersion": "2019-06-01",
"name": "
[concat(parameters('networkSecurityGroups_myVM1_nsg_name'),
'/Port_80')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups',
parameters('networkSecurityGroups_myVM1_nsg_name'))]"
],
"properties": {
"protocol": "*",
"access": "Allow",
"priority": 310,
}
13. Cliquez sur Enregistrer dans l’éditeur en ligne.
14. Cliquez sur DE BASE>Abonnement pour choisir l’abonnement dans lequel le

groupe de sécurité réseau sera déployé.
15. Cliquez sur DE BASE>Groupe de ressources pour choisir le groupe de ressources

dans lequel le groupe de sécurité réseau sera déployé. Vous pouvez cliquer sur
Créer pour créer un groupe de ressources pour le groupe de sécurité réseau cible.
Vérifiez que le nom n’est pas identique à celui du groupe de ressources source du
groupe de sécurité réseau existant.
16. Vérifiez que DE BASE>Emplacement est défini avec l’emplacement cible où vous
souhaitez déployer le groupe de sécurité réseau.
17. Sous PARAMÈTRES, vérifiez que le nom correspond à celui que vous avez entré
dans l’éditeur de paramètres ci-dessus.
18. Cochez la case sous CONDITIONS GÉNÉRALES.
19. Cliquez sur le bouton Acheter pour déployer le groupe de sécurité réseau cible.
Abandonner
Si vous souhaitez abandonner le groupe de sécurité réseau cible, supprimez le groupe
de ressources contenant le groupe de sécurité réseau cible. Pour ce faire, sélectionnez le
groupe de ressources à partir de votre tableau de bord dans le portail, puis sélectionnez
Supprimer en haut de la page de vue d’ensemble.
Nettoyer
Pour valider les modifications et terminer le déplacement du groupe de sécurité réseau,
supprimez le groupe de ressources ou le groupe de sécurité réseau source. Pour ce faire,
sélectionnez le groupe de sécurité réseau ou le groupe de ressources à partir de votre
tableau de bord dans le portail, puis sélectionnez Supprimer en haut de chaque page.
Étapes suivantes
Dans ce tutoriel, vous avez déplacé un groupe de sécurité réseau Azure d’une région à
une autre et nettoyé les ressources sources. Pour en savoir plus sur le déplacement de
ressources entre régions et la reprise d’activité après sinistre dans Azure, consultez :
Déplacer des ressources vers un nouveau groupe de ressource ou un nouvel

abonnement
Déplacer des machines virtuelles Azure vers une autre région
Déplacer un groupe de sécurité réseau
Azure vers une autre région à l’aide
d’Azure PowerShell
Il existe différents scénarios dans lesquels vous pouvez être amené à déplacer vos
groupe de sécurité réseau existants d’une région à une autre. Par exemple, vous pouvez
avoir besoin de créer un groupe de sécurité réseau avec la même configuration et les
mêmes règles de sécurité à des fins de test. Vous pouvez également déplacer un groupe
de sécurité réseau vers une autre région dans le cadre de la planification de la reprise
d’activité après sinistre.
Les groupes de sécurité Azure ne peuvent pas être déplacés d’une région vers une autre.
Toutefois, vous pouvez utiliser un modèle Azure Resource Manager pour exporter la
configuration existante et les règles de sécurité d’un groupe de sécurité réseau. Vous
pouvez ensuite déplacer la ressource dans une autre région en exportant le groupe de
sécurité réseau vers un modèle, en modifiant les paramètres pour qu’ils correspondent à
la région de destination, puis en déployant le modèle dans la nouvelle région. Pour plus
d’informations sur Resource Manager et les modèles, consultez Exporter des groupes de
ressources vers des modèles.
Prérequis
Vérifiez que le groupe de sécurité réseau Azure se trouve dans la région Azure à
partir de laquelle vous souhaitez effectuer le déplacement.
Les groupes de sécurité réseau Azure ne peuvent pas être déplacés entre les
régions. Vous devez associer le nouveau groupe de sécurité réseau à des
ressources dans la région cible.
Pour exporter une configuration de groupe de sécurité réseau et déployer un

modèle afin de créer un groupe de sécurité réseau dans une autre région, vous
devez disposer au minimum du rôle Contributeur de réseaux.
les adresses IP publiques et les réseaux virtuels.
Vérifiez que votre abonnement Azure vous permet de créer des groupes de
sécurité réseau dans la région cible utilisée. Contactez le support pour activer le
quota requis.

prendre en charge l’ajout de groupes de sécurité réseau pour ce processus.
Consultez Abonnement Azure et limites, quotas et contraintes de service.
Les étapes suivantes montrent comment préparer le groupe de sécurité réseau pour le
déplacement de la configuration et de la règle de sécurité à l’aide d’un modèle Resource
Manager et comment déplacer la configuration et les règles de sécurité du groupe de
sécurité réseau vers la région cible à l’aide d’Azure PowerShell.
７ Notes

Exporter le modèle et le déployer à partir d’un script

1. Connectez-vous à votre abonnement Azure avec la commande Connect-
AzAccount et suivez les instructions qui s'affichent à l’écran :
Azure PowerShell
Connect-AzAccount
2. Obtenez l’ID de ressource du groupe de sécurité réseau que vous souhaitez

déplacer vers la région cible, puis placez-le dans une variable à l’aide de Get-
AzNetworkSecurityGroup :
Azure PowerShell
$sourceNSGID = (Get-AzNetworkSecurityGroup -Name <source-nsg-name> -

ResourceGroupName <source-resource-group-name>).Id
3. Exportez le groupe de sécurité réseau source vers un fichier .json dans le répertoire
où vous exécutez la commande Export-AzResourceGroup :
Azure PowerShell
Export-AzResourceGroup -ResourceGroupName <source-resource-group-name>

-Resource $sourceNSGID -IncludeParameterDefaultValue
4. Le fichier téléchargé est nommé d’après le groupe de ressources à partir duquel la

ressource a été exportée. Recherchez le fichier nommé <resource-group-
name>.json qui a été exporté à partir de la commande, et ouvrez-le dans l’éditeur
de votre choix :
Azure PowerShell
notepad <source-resource-group-name>.json
5. Pour modifier le paramètre du nom de groupe de sécurité réseau, remplacez la

propriété defaultValue par le nom de votre groupe de sécurité réseau cible, en
veillant à placer le nom entre guillemets :
JSON
{
"parameters": {
"networkSecurityGroups_myVM1_nsg_name": {
"defaultValue": "<target-nsg-name>",
"type": "String"
}
}
6. Pour modifier la région cible où la configuration et les règles de sécurité du

groupe de sécurité réseau seront déplacées, modifiez la propriété location sous
resources :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",
"properties": {
}
}
7. Pour obtenir les codes d’emplacement des régions, vous pouvez utiliser l’applet de
commande Azure PowerShell Get-AzLocation en exécutant la commande suivante :
Azure PowerShell
Get-AzLocation | format-table
8. Vous pouvez également modifier d’autres paramètres dans le fichier

<nom_groupe_de_ressources>.json ; ces paramètres sont facultatifs en fonction
de vos besoins :
Règles de sécurité : vous pouvez modifier les règles déployées dans le

groupe de sécurité réseau cible en ajoutant ou en supprimant des règles
dans la section securityRules du fichier <nom_groupe_de_ressources>.json :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"name": "
[parameters('networkSecurityGroups_myVM1_nsg_name')]",
"location": "TARGET REGION",
"properties": {
"resourceGuid": "2c846acf-58c8-416d-be97-
ccd00a4ccd78",
"securityRules": [
{
"name": "RDP",
"etag": "W/\"c630c458-6b52-4202-8fd7-
172b7ab49cf5\"",
"properties": {
"protocol": "TCP",
"access": "Allow",
"priority": 300,
}
]
}
Pour terminer l’ajout ou la suppression des règles dans le groupe de sécurité

réseau cible, vous devez également modifier les types de règles
personnalisées à la fin du fichier <nom_groupe_de_ressources>.json selon le
format de l’exemple ci-dessous :
JSON
{
"type":
"Microsoft.Network/networkSecurityGroups/securityRules",
"apiVersion": "2019-06-01",
"name": "
[concat(parameters('networkSecurityGroups_myVM1_nsg_name'),
'/Port_80')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups',
parameters('networkSecurityGroups_myVM1_nsg_name'))]"
],
"properties": {
"protocol": "*",
"access": "Allow",
"priority": 310,
}
9. Enregistrez le fichier <resource-group-name>.json.
10. Créez un groupe de ressources dans la région cible pour le groupe de sécurité
réseau cible à déployer à l’aide de New-AzResourceGroup :
Azure PowerShell
New-AzResourceGroup -Name <target-resource-group-name> -location

<target-region>
11. Déployez le fichier <nom_groupe_de_ressources>.json modifié sur le groupe de
ressources créé à l’étape précédente à l’aide de New-
AzResourceGroupDeployment :
Azure PowerShell
New-AzResourceGroupDeployment -ResourceGroupName <target-resource-

group-name> -TemplateFile <source-resource-group-name>.json
12. Pour vérifier que les ressources ont été créées dans la région cible, utilisez Get-
AzResourceGroup et Get-AzNetworkSecurityGroup :
Azure PowerShell
Get-AzResourceGroup -Name <target-resource-group-name>
Azure PowerShell
Get-AzNetworkSecurityGroup -Name <target-nsg-name> -ResourceGroupName

<target-resource-group-name>
Abandonner
Après le déploiement, si vous souhaitez recommencer ou ignorer le groupe de sécurité
réseau dans la cible, supprimez le groupe de ressources qui a été créé dans la cible et le
groupe de sécurité réseau déplacé sera supprimé. Pour supprimer le groupe de
ressources, utilisez Remove-AzResourceGroup :
Azure PowerShell
Remove-AzResourceGroup -Name <target-resource-group-name>
Nettoyer
Pour valider les modifications et terminer le déplacement du groupe de sécurité réseau,
supprimez le groupe de ressources ou le groupe de sécurité réseau source avec
Remove-AzResourceGroup ou Remove-AzNetworkSecurityGroup :
Azure PowerShell
Remove-AzResourceGroup -Name <source-resource-group-name>
Azure PowerShell
Remove-AzNetworkSecurityGroup -Name <source-nsg-name> -ResourceGroupName

<source-resource-group-name>
Étapes suivantes
Dans ce tutoriel, vous avez déplacé un groupe de sécurité réseau Azure d’une région à
une autre et nettoyé les ressources sources. Pour en savoir plus sur le déplacement de

abonnement
Déplacer un réseau virtuel Azure vers
une autre région en utilisant le portail
Azure
Article • 01/06/2023
Il existe différents scénarios pour déplacer un réseau virtuel Azure existant d’une région
à une autre. Par exemple, vous voulez créer un réseau virtuel avec la même
configuration pour des tests et la même disponibilité que votre réseau virtuel existant.
Vous pourriez aussi déplacer un réseau virtuel de production vers une autre région dans
le cadre de la planification de la reprise d’activité.
Vous pouvez utiliser un modèle Azure Resource Manager pour terminer la migration du
réseau virtuel vers une autre région. Pour ce faire, exportez le réseau virtuel vers un
modèle, modifiez les paramètres pour qu’ils correspondent à la région de destination,
puis déployez le modèle dans la nouvelle région. Pour plus d’informations sur les
modèles Resource Manager, consultez Démarrage rapide : Créer et déployer des
modèles Azure Resource Manager à l’aide du portail Azure.
Prérequis
Vérifiez que votre réseau virtuel Azure se trouve dans la région Azure à partir de
laquelle vous voulez effectuer le déplacement.
Pour exporter un réseau virtuel et déployer un modèle pour créer un réseau virtuel
dans une autre région, vous avez besoin du rôle Contributeur de réseaux ou d’un
rôle supérieur.
Les appairages de réseaux virtuels ne sont pas recréés et échouent s’ils sont
toujours présents dans le modèle. Avant d’exporter le modèle, vous devez
supprimer les pairs du réseau virtuel. Vous pouvez ensuite les rétablir après le
déplacement du réseau virtuel.
les groupes de sécurité réseau et les adresses IP publiques.
Vérifiez que votre abonnement Azure vous permet de créer des réseaux virtuels
dans la région cible. Pour activer le quota nécessaire, contactez le support
technique.
prendre en charge l’ajout de réseaux virtuels pour ce processus. Pour plus
d’informations, consultez Abonnement Azure et limites, quotas et contraintes de
service.
Préparer le déplacement
Dans cette section, vous préparez le réseau virtuel pour le déplacement en utilisant un
modèle Resource Manager. Vous déplacez ensuite le réseau virtuel vers la région cible
en utilisant le portail Azure.
Pour exporter le réseau virtuel et déployer le réseau virtuel cible en utilisant le portail
Azure, procédez comme suit :
1. Connectez-vous au portail Azure , puis sélectionnez Groupes de ressources.
2. Localisez le groupe de ressources qui contient le réseau virtuel source, puis

sélectionnez-le.
3. Sélectionnez Automatisation>Exporter le modèle.
4. Dans le volet Exporter le modèle, sélectionnez Déployer.
5. Pour ouvrir le fichier parameters.json dans votre éditeur en ligne, sélectionnez

Modèle>Modifier les paramètres.
6. Pour modifier le paramètre du nom du réseau virtuel, modifiez la propriété value

sous parameters :
JSON
{
01/deploymentParameters.json#",
"parameters": {
"virtualNetworks_myVNET1_name": {
"value": "<target-virtual-network-name>"
}
}
}
7. Dans l’éditeur, remplacez la valeur du nom du réseau virtuel source par le nom de
votre choix pour le réseau virtuel cible. Veillez à placer le nom entre guillemets.
8. Sélectionnez Enregistrer dans l’éditeur.

9. Pour ouvrir le fichier template.json dans l’éditeur en ligne, sélectionnez
Modèle>Modifier le modèle.
10. Dans l’éditeur en ligne, pour modifier la région cible où le réseau virtuel sera
déplacé, modifiez la propriété location sous resources :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"name": "[parameters('virtualNetworks_myVNET1_name')]",
"properties": {
"resourceGuid": "6e2652be-35ac-4e68-8c70-
621b9ec87dcb",
"addressSpace": {
"10.0.0.0/16"
]
},
Azure . Le code d’une région est le nom de la région, sans espace (par exemple
USA Centre (Central US) = centralus).
12. (Facultatif) Vous pouvez aussi changer d’autres paramètres dans le modèle, en
fonction de vos besoins :
Espace d’adressage : Avant d’enregistrer le fichier, vous pouvez modifier

l’espace d’adressage du réseau virtuel en modifiant la section
resources>addressSpace et en changeant la propriété addressPrefixes :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"name": "
[parameters('virtualNetworks_myVNET1_name')]",
"location": "<target-region",
"properties": {
621b9ec87dcb",
"addressSpace": {
"10.0.0.0/16"
]
},
Sous-réseau : Vous pouvez changer ou ajouter le nom du sous-réseau et

l’espace d’adressage du sous-réseau en modifiant la section subnets du
modèle. Vous pouvez changer le nom du sous-réseau en modifiant la
propriété name. Vous pouvez changer l’espace d’adressage du sous-réseau
en modifiant la propriété addressPrefix :
JSON
"subnets": [
{
"name": "subnet-1",
"etag": "W/\"d9f6e6d6-2c15-4f7c-b01f-bed40f748dea\"",
"properties": {
"addressPrefix": "10.0.0.0/24",
"delegations": [],
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
},
{
"name": "GatewaySubnet",
"properties": {
"serviceEndpoints": [],
"delegations": [],
}
}
Pour changer le préfixe d’adresse dans le fichier template.json, modifiez-le à

deux endroits : dans le code de la section précédente et dans la section type
du code suivant. Modifiez la propriété addressPrefix dans le code suivant
pour qu’elle corresponde à la propriété addressPrefix dans le code de la
section précédente.
JSON
"type": "Microsoft.Network/virtualNetworks/subnets",
"apiVersion": "2019-06-01",
"name": "[concat(parameters('virtualNetworks_myVNET1_name'),
'/GatewaySubnet')]",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks',
parameters('virtualNetworks_myVNET1_name'))]"
],
"properties": {
"delegations": [],
}
},
{
"apiVersion": "2019-06-01",
"name": "
[concat(parameters('virtualNetworks_myVNET1_name'), '/subnet-
1')]",
"dependsOn": [
],
"properties": {
"delegations": [],
}
}
]
13. Dans l’éditeur en ligne, sélectionnez Enregistrer.
14. Pour choisir l’abonnement où le réseau virtuel cible sera déployé, sélectionnez
Général>Abonnement.
15. Pour choisir le groupe de ressources où le réseau virtuel cible sera déployé,
sélectionnez Général>Groupe de ressources.
Si vous devez créer un groupe de ressources pour le réseau virtuel cible,

sélectionnez Créer. Vérifiez que le nom n’est pas identique à celui du groupe de
ressources source dans le réseau virtuel existant.
16. Vérifiez que Général>Emplacement est défini sur l’emplacement cible où vous
voulez déployer le réseau virtuel.
17. Sous Paramètres, vérifiez que le nom correspond à celui que vous avez entré
précédemment dans l’éditeur de paramètres.
18. Cochez la case Conditions générales.
19. Pour déployer le réseau virtuel cible, sélectionnez Acheter.
Supprimer le réseau virtuel cible

Pour supprimer le réseau virtuel cible, supprimez le groupe de ressources qui le
contient. Pour ce faire :
1. Dans le tableau de bord du portail Azure, sélectionnez le groupe de ressources.

2. En haut du volet Vue d’ensemble, sélectionnez Supprimer.
Nettoyer
Pour valider les modifications et effectuer le déplacement du réseau virtuel, vous
supprimez le réseau virtuel ou le groupe de ressources source. Pour ce faire :
1. Dans le tableau de bord du portail Azure, sélectionnez le réseau virtuel ou le

2. En haut de chaque volet, sélectionnez Supprimer.
Étapes suivantes
Dans ce tutoriel, vous avez déplacé un réseau virtuel Azure d’une région à une autre en
utilisant le portail Azure, puis vous avez nettoyé les ressources sources non nécessaires.
Pour plus d’informations sur le déplacement de ressources entre régions et la reprise
d’activité dans Azure, consultez :

abonnement
Déplacer un réseau virtuel Azure vers
une autre région en utilisant Azure
PowerShell
Article • 11/05/2023
Il existe différents scénarios pour déplacer un réseau virtuel Azure existant d’une région
à une autre. Par exemple, vous voulez créer un réseau virtuel avec la même
configuration pour des tests et la même disponibilité que votre réseau virtuel existant.
Vous pourriez aussi déplacer un réseau virtuel de production vers une autre région dans
le cadre de la planification de la reprise d’activité.
Vous pouvez utiliser un modèle Azure Resource Manager pour terminer la migration du
réseau virtuel vers une autre région. Pour ce faire, exportez le réseau virtuel vers un
modèle, modifiez les paramètres pour qu’ils correspondent à la région de destination,
puis déployez le modèle dans la nouvelle région. Pour plus d’informations sur les
modèles Resource Manager, consultez Exporter des groupes de ressources vers des
modèles.
Prérequis
Vérifiez que votre réseau virtuel Azure se trouve dans la région Azure à partir de
laquelle vous voulez effectuer le déplacement.
Pour exporter un réseau virtuel et déployer un modèle pour créer un réseau virtuel
dans une autre région, vous avez besoin du rôle Contributeur de réseaux ou d’un
rôle supérieur.
Les appairages de réseaux virtuels ne sont pas recréés et échouent s’ils sont
toujours présents dans le modèle. Avant d’exporter le modèle, vous devez
supprimer les pairs du réseau virtuel. Vous pouvez ensuite les rétablir après le
déplacement du réseau virtuel.
les groupes de sécurité réseau et les adresses IP publiques.
Vérifiez que votre abonnement Azure vous permet de créer des réseaux virtuels
dans la région cible. Pour activer le quota nécessaire, contactez le support
technique.
prendre en charge l’ajout de réseaux virtuels pour ce processus. Pour plus
d’informations, consultez Abonnement Azure et limites, quotas et contraintes de
service.
Préparer le déplacement
Dans cette section, vous préparez le réseau virtuel pour le déplacement en utilisant un
modèle Resource Manager. Vous déplacez ensuite le réseau virtuel vers la région cible
en utilisant des commandes Azure PowerShell.
７ Notes

Pour exporter le réseau virtuel et déployer le réseau virtuel cible en utilisant PowerShell,
procédez comme suit :

AzAccount, puis suivez les instructions qui s’affichent à l’écran :
Azure PowerShell
Connect-AzAccount
2. Obtenez l’ID de ressource du réseau virtuel que vous voulez déplacer vers la région
cible, puis placez-le dans une variable en utilisant Get-AzVirtualNetwork :
Azure PowerShell
$sourceVNETID = (Get-AzVirtualNetwork -Name <source-virtual-network-

name> -ResourceGroupName <source-resource-group-name>).Id
3. Exportez le réseau virtuel source vers un fichier .json dans le répertoire où vous
exécutez la commande Export-AzResourceGroup :
Azure PowerShell
-Resource $sourceVNETID -IncludeParameterDefaultValue
4. Le fichier téléchargé a le même nom que le groupe de ressources à partir duquel la

ressource a été exportée. Recherchez le fichier <resource-group-name>.json que
vous avez exporté avec la commande, puis ouvrez-le dans votre éditeur :
Azure PowerShell
5. Pour modifier le paramètre du nom du réseau virtuel, remplacez la valeur de la

propriété defaultValue du nom du réseau virtuel source par le nom de votre
réseau virtuel cible. Veillez à placer le nom entre guillemets.
JSON
01/deploymentmyResourceGroupVNET.json#",
"parameters": {
"virtualNetworks_myVNET1_name": {
"defaultValue": "<target-virtual-network-name>",
"type": "String"
}
6. Pour modifier la région cible où le réseau virtuel sera déplacé, changez la propriété
location sous resources :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"name": "[parameters('virtualNetworks_myVNET1_name')]",
"properties": {
621b9ec87dcb",
"addressSpace": {
"10.0.0.0/16"
]
},
Azure PowerShell
8. (Facultatif) Vous pouvez aussi modifier d’autres paramètres dans le fichier

<resource-group-name>.json en fonction de vos besoins :
Espace d’adressage : Avant d’enregistrer le fichier, vous pouvez modifier

l’espace d’adressage du réseau virtuel en modifiant la section
resources>addressSpace et en changeant la propriété addressPrefixes :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"name": "
[parameters('virtualNetworks_myVNET1_name')]",
"location": "<target-region",
"properties": {
621b9ec87dcb",
"addressSpace": {
"10.0.0.0/16"
]
},
Sous-réseau : Vous pouvez changer ou ajouter le nom du sous-réseau et

l’espace d’adressage du sous-réseau en modifiant la section subnets du
fichier. Vous pouvez changer le nom du sous-réseau en modifiant la propriété
name. Vous pouvez changer l’espace d’adressage du sous-réseau en
modifiant la propriété addressPrefix :
JSON
"subnets": [
{
"name": "subnet-1",
"properties": {
"delegations": [],
}
},
{
"name": "GatewaySubnet",
"properties": {
"delegations": [],
}
}
Pour changer le préfixe d’adresse, modifiez-le à deux endroits : dans le code

de la section précédente et dans la section type du code suivant. Modifiez la
propriété addressPrefix dans le code suivant pour qu’elle corresponde à la
propriété addressPrefix dans le code de la section précédente.
JSON
"apiVersion": "2019-06-01",
"name": "[concat(parameters('virtualNetworks_myVNET1_name'),
'/GatewaySubnet')]",
"dependsOn": [
],
"properties": {
"delegations": [],
}
},
{
"apiVersion": "2019-06-01",
"name": "
[concat(parameters('virtualNetworks_myVNET1_name'), '/subnet-
1')]",
"dependsOn": [
],
"properties": {
"delegations": [],
}
}
]
10. Créez un groupe de ressources dans la région cible pour le réseau virtuel cible à
déployer en utilisant New-AzResourceGroup :
Azure PowerShell

<target-region>
11. Déployez le fichier <resource-group-name>.json modifié sur le groupe de

ressources que vous avez créé à l’étape précédente en utilisant la commande New-
Azure PowerShell

AzResourceGroup et Get-AzVirtualNetwork :
Azure PowerShell
Azure PowerShell
Get-AzVirtualNetwork -Name <target-virtual-network-name> -

ResourceGroupName <target-resource-group-name>
Supprimer le réseau virtuel ou le groupe de
ressources
Une fois que vous avez déployé le réseau virtuel , pour recommencer ou supprimer le
réseau virtuel dans la région cible, supprimez le groupe de ressources que vous avez
créé dans la région cible : le réseau virtuel déplacé est alors supprimé.
Pour supprimer le groupe de ressources, utilisez Remove-AzResourceGroup :
Azure PowerShell
Nettoyer
Pour valider vos changements et effectuer le déplacement du réseau virtuel, effectuez
une des actions suivantes :
Supprimez le groupe de ressources en utilisant la commande Remove-

AzResourceGroup :
Azure PowerShell
Supprimez le réseau virtuel source en utilisant Remove-AzVirtualNetwork :
Azure PowerShell
Remove-AzVirtualNetwork -Name <source-virtual-network-name> -

ResourceGroupName <source-resource-group-name>
Étapes suivantes
Dans ce tutoriel, vous avez déplacé un réseau virtuel d’une région à une autre en
utilisant PowerShell, puis vous avez nettoyé les ressources sources non nécessaires. Pour
plus d’informations sur le déplacement de ressources entre régions et la reprise
d’activité dans Azure, consultez :

abonnement
Déplacer la configuration des
adresses IP publiques Azure vers une
autre région à l’aide du portail Azure
Article • 01/06/2023
Il existe différents scénarios dans lesquels vous pouvez être amené à déplacer les
configurations de vos adresses IP publiques Azure existantes d’une région à une autre.
Par exemple, vous pouvez avoir besoin de créer une adresse IP publique avec la même
configuration et la même référence SKU à des fins de test. Vous pouvez également
déplacer une configuration d’adresses IP publiques vers une autre région dans le cadre
de la planification de la récupération d’urgence.
Les adresses IP publiques Azure sont spécifiques à une région et ne peuvent pas être
déplacées d’une région vers une autre. Toutefois, vous pouvez utiliser un modèle Azure
Resource Manager pour exporter la configuration existante d’une adresse IP publique.
Vous pouvez ensuite déplacer la ressource dans une autre région en exportant l’adresse
IP publique vers un modèle, en modifiant les paramètres pour qu’ils correspondent à la
région de destination, puis en déployant le modèle dans la nouvelle région. Pour plus
d’informations sur Resource Manager et les modèles, consultez Démarrage rapide :
Créer et déployer des modèles Azure Resource Manager à l’aide du portail Azure.
Prérequis
Vérifiez que l’adresse IP publique Azure se trouve dans la région Azure à partir de
laquelle vous souhaitez effectuer le déplacement.
Vous ne pouvez pas déplacer les adresses IP publiques Azure entre les régions.
Vous devez associer la nouvelle adresse IP publique à des ressources dans la
région cible.
Pour exporter une configuration d’adresse IP publique et déployer un modèle pour

créer une adresse IP publique dans une autre région, vous devez disposer au
minimum du rôle Contributeur de réseaux.
les groupes de sécurité réseau et les réseaux virtuels.
Vérifiez que votre abonnement Azure vous permet de créer des adresses IP
publiques dans la région cible utilisée. Contactez le support pour activer le quota
requis.

prendre en charge l’ajout d’adresses IP publiques pour ce processus. Consultez
Abonnement Azure et limites, quotas et contraintes de service.
Les étapes suivantes montrent comment préparer l’adresse IP publique pour le
déplacement à l’aide d’un modèle Resource Manager et comment déplacer la
configuration de l’adresse IP publique vers la région cible à l’aide du Portail Azure.

1. Connectez-vous au Portail Azure >Groupes de ressources.
2. Recherchez le groupe de ressources qui contient l’adresse IP publique source et

cliquez dessus.
3. Sélectionnez >Paramètres>Exporter le modèle.
4. Choisissez Déployer dans le panneau Exporter le modèle.
5. Cliquez sur MODÈLE>Modifier les paramètres pour ouvrir le fichier

parameters.json dans l’éditeur en ligne.
6. Pour modifier le paramètre du nom d’adresse IP publique, remplacez la propriété

sous parameters>value par le nom de votre adresse IP publique cible, en veillant à
placer le nom entre guillemets :
JSON
{
01/deploymentParameters.json#",
"parameters": {
"publicIPAddresses_myVM1pubIP_name": {
"value": "<target-publicip-name>"
}
}
}
7. Cliquez sur Enregistrer dans l’éditeur.

8. Cliquez sur MODÈLE>Modifier le modèle pour ouvrir le fichier template.json dans
l’éditeur en ligne.
9. Pour modifier la région cible où l’adresse IP publique sera déplacée, changez la

propriété location sous resources :
JSON
"resources": [
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2019-06-01",
"name": "[parameters('publicIPAddresses_myPubIP_name')]",
"sku": {
"name": "Basic",
"tier": "Regional"
},
"properties": {
"resourceGuid": "7549a8f1-80c2-481a-a073-018f5b0b69be",
"ipAddress": "52.177.6.204",
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Dynamic",
"idleTimeoutInMinutes": 4,
"ipTags": []
}
}
]
Azure . Le code d’une région est le nom de la région sans espace, USA Centre =
centralus.
Référence SKU : vous pouvez permuter la référence SKU de l’adresse IP

publique dans la configuration entre les valeurs basic et standard en
modifiant la propriété sku>name dans le fichier template.json :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"sku": {
"name": "Basic",
"tier": "Regional"
},
Pour plus d’informations sur les différences entre les adresses IP publiques
des références SKU basic et standard, consultez Créer, modifier ou supprimer
une adresse IP publique :
Méthode d’allocation d’adresse IP publique et Délai d’inactivité : vous

pouvez changer ces deux options dans le modèle en permutant la propriété
publicIPAllocationMethod entre les valeurs Dynamic et Static. Vous pouvez
changer le délai d’inactivité en affectant la valeur souhaitée à la propriété
idleTimeoutInMinutes. La valeur par défaut est 4 :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"sku": {
"name": "Basic",
"tier": "Regional"
},
"properties": {
"ipAddress": "52.177.6.204",
"ipTags": []
Pour plus d’informations sur les méthodes d’allocation et les valeurs de délai
d’inactivité, consultez Créer, modifier ou supprimer une adresse IP publique.
12. Cliquez sur Enregistrer dans l’éditeur en ligne.
13. Cliquez sur DE BASE>Abonnement pour choisir l’abonnement dans lequel

l’adresse IP publique cible sera déployée.
14. Cliquez sur DE BASE>Groupe de ressources pour choisir le groupe de ressources

dans lequel l’adresse IP publique cible sera déployée. Vous pouvez cliquer sur
Créer afin de créer un groupe de ressources pour l’adresse IP publique cible.
Vérifiez que le nom n’est pas identique à celui du groupe de ressources source de
l’adresse IP publique cible existante.
15. Vérifiez que DE BASE>Emplacement est défini avec l’emplacement cible où vous
souhaitez déployer l’adresse IP publique.
16. Sous PARAMÈTRES, vérifiez que le nom correspond à celui que vous avez entré
dans l’éditeur de paramètres ci-dessus.
17. Cochez la case sous CONDITIONS GÉNÉRALES.
18. Cliquez sur le bouton Acheter pour déployer l’adresse IP publique cible.
Abandonner
Si vous souhaitez abandonner l’adresse IP publique cible, supprimez le groupe de
ressources contenant l’adresse IP publique cible. Pour ce faire, sélectionnez le groupe de
ressources à partir de votre tableau de bord dans le portail, puis sélectionnez Supprimer
en haut de la page de vue d’ensemble.
Nettoyer
Pour valider les modifications et terminer le déplacement de l’adresse IP publique cible,
supprimez le groupe de ressources ou l’adresse IP publique source. Pour ce faire,
sélectionnez l’adresse IP publique ou le groupe de ressources à partir de votre tableau
de bord dans le portail, puis sélectionnez Supprimer en haut de chaque page.
Étapes suivantes
Dans ce tutoriel, vous avez déplacé une adresse IP publique Azure d’une région à une
autre et nettoyé les ressources sources. Pour en savoir plus sur le déplacement de

abonnement
Déplacer la configuration d’adresses IP
publiques Azure vers une autre région à
l’aide d’Azure PowerShell
Il existe différents scénarios dans lesquels vous pouvez être amené à déplacer les
configurations de vos adresses IP publiques Azure existantes d’une région à une autre.
Par exemple, vous pouvez avoir besoin de créer une adresse IP publique avec la même
configuration et la même référence SKU à des fins de test. Vous pouvez également
déplacer une configuration d’adresses IP publiques vers une autre région dans le cadre
de la planification de la récupération d’urgence.
Les adresses IP publiques Azure sont spécifiques à une région et ne peuvent pas être
déplacées d’une région vers une autre. Toutefois, vous pouvez utiliser un modèle Azure
Resource Manager pour exporter la configuration existante d’une adresse IP publique.
Vous pouvez ensuite déplacer la ressource dans une autre région en exportant l’adresse
IP publique vers un modèle, en modifiant les paramètres pour qu’ils correspondent à la
région de destination, puis en déployant le modèle dans la nouvelle région. Pour plus
d’informations sur Resource Manager et les modèles, consultez Exporter des groupes de
ressources vers des modèles
Prérequis
Vérifiez que l’adresse IP publique Azure se trouve dans la région Azure à partir de
laquelle vous souhaitez effectuer le déplacement.
Vous ne pouvez pas déplacer les adresses IP publiques Azure entre les régions.
Vous devez associer la nouvelle adresse IP publique à des ressources dans la
région cible.
Pour exporter une configuration d’adresse IP publique et déployer un modèle pour

créer une adresse IP publique dans une autre région, vous devez disposer au
minimum du rôle Contributeur de réseaux.
les groupes de sécurité réseau et les réseaux virtuels.
Vérifiez que votre abonnement Azure vous permet de créer des adresses IP
publiques dans la région cible utilisée. Contactez le support pour activer le quota
requis.

prendre en charge l’ajout d’adresses IP publiques pour ce processus. Consultez
Abonnement Azure et limites, quotas et contraintes de service.
Les étapes suivantes montrent comment préparer l’adresse IP publique pour le
déplacement à l’aide d’un modèle Resource Manager et comment déplacer la
configuration de l’adresse IP publique vers la région cible à l’aide d’Azure PowerShell.
７ Notes


AzAccount et suivez les instructions qui s'affichent à l’écran :
Azure PowerShell
Connect-AzAccount
2. Obtenez l’ID de ressource de l’adresse IP publique que vous souhaitez déplacer

vers la région cible, puis placez-la dans une variable à l’aide de Get-
AzPublicIPAddress :
Azure PowerShell
$sourcePubIPID = (Get-AzPublicIPaddress -Name <source-public-ip-name> -

ResourceGroupName <source-resource-group-name>).Id
3. Exportez le réseau virtuel source vers un fichier .json dans le répertoire où vous
exécutez la commande Export-AzResourceGroup :
Azure PowerShell
-Resource $sourceVNETID -IncludeParameterDefaultValue
4. Le fichier téléchargé est nommé d’après le groupe de ressources à partir duquel la

ressource a été exportée. Recherchez le fichier nommé <resource-group-
name>.json qui a été exporté à partir de la commande, et ouvrez-le dans l’éditeur
de votre choix :
Azure PowerShell
5. Pour modifier le paramètre du nom d’adresse IP publique, remplacez la propriété

defaultValue par le nom de votre adresse IP publique cible, en veillant à placer le
nom entre guillemets :
JSON
{
"parameters": {
"publicIPAddresses_myVM1pubIP_name": {
"defaultValue": "<target-publicip-name>",
"type": "String"
}
}
6. Pour modifier la région cible où l’adresse IP publique sera déplacée, changez la

propriété location sous resources :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"sku": {
"name": "Basic",
"tier": "Regional"
},
"properties": {
"ipAddress": "52.177.6.204",
"ipTags": []
}
}
]
Azure PowerShell

Référence SKU : vous pouvez permuter la référence SKU de l’adresse IP

publique dans la configuration entre les valeurs basic et standard en
modifiant la propriété sku>name dans le fichier <resource-group-
name>.json :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"name": "
[parameters('publicIPAddresses_myPubIP_name')]",
"sku": {
"name": "Basic",
"tier": "Regional"
},
Pour plus d’informations sur les différences entre les adresses IP publiques
des références SKU basic et standard, consultez Créer, modifier ou supprimer
une adresse IP publique.
Méthode d’allocation d’adresse IP publique et Délai d’inactivité : vous

pouvez changer ces deux options dans le modèle en permutant la propriété
publicIPAllocationMethod entre les valeurs Dynamic et Static. Vous pouvez
changer le délai d’inactivité en affectant la valeur souhaitée à la propriété
idleTimeoutInMinutes. La valeur par défaut est 4 :
JSON
"resources": [
{
"apiVersion": "2019-06-01",
"sku": {
"name": "Basic",
"tier": "Regional"
},
"properties": {
"ipAddress": "52.177.6.204",
"ipTags": []
}
}
Pour plus d’informations sur les méthodes d’allocation et les valeurs de délai
d’inactivité, consultez Créer, modifier ou supprimer une adresse IP publique.
10. Créez un groupe de ressources dans la région cible pour l'adresse IP publique cible
à déployer à l’aide de New-AzResourceGroup.
Azure PowerShell

<target-region>
11. Déployez le fichier <nom_groupe_de_ressources>.json modifié sur le groupe de

ressources créé à l’étape précédente à l’aide de New-
Azure PowerShell

AzResourceGroup et Get-AzPublicIPAddress :
Azure PowerShell
Azure PowerShell
Get-AzPublicIPAddress -Name <target-publicip-name> -ResourceGroupName

<target-resource-group-name>
Abandonner
Après le déploiement, si vous souhaitez recommencer ou ignorer l’adresse IP publique
dans la cible, supprimez le groupe de ressources qui a été créé dans la cible et l’adresse
IP publique déplacée sera supprimée. Pour supprimer le groupe de ressources, utilisez
Remove-AzResourceGroup :
Azure PowerShell
Nettoyer
Pour valider les modifications et terminer le déplacement du réseau virtuel, supprimez le
réseau virtuel ou le groupe de ressources source avec Remove-AzResourceGroup ou
Remove-AzPublicIPAddress :
Azure PowerShell
Azure PowerShell
Remove-AzPublicIpAddress -Name <source-publicip-name> -ResourceGroupName

<resource-group-name>
Étapes suivantes
Dans ce tutoriel, vous avez déplacé une adresse IP publique Azure d’une région à une
autre et nettoyé les ressources sources. Pour en savoir plus sur le déplacement de
abonnement
Résoudre les problèmes d’appairage de
réseaux virtuels
Article • 01/06/2023
Ce guide de dépannage décrit les étapes de résolution de la plupart des problèmes

d’appairage de réseaux virtuels.
Configurer l’appairage entre deux réseaux

virtuels
Les réseaux virtuels se trouvent-ils dans le même abonnement ou dans des
abonnements différents ?
Les réseaux virtuels se trouvent dans le même

abonnement
Pour configurer le peering des réseaux virtuels qui se trouvent dans le même
abonnement, utilisez les méthodes décrites dans les articles suivants :
Si les réseaux virtuels se trouvent dans la même région, consultez Créer un peering.
Si les réseaux virtuels se trouvent dans des régions distinctes, consultez Peering de
réseau virtuel.
７ Notes
La connectivité ne fonctionne pas via le peering de réseaux virtuels mondiaux pour

les ressources suivantes :
Machines virtuelles derrière le SKU ILB (équilibreur de charge interne) de base

Cache Redis (utilise le SKU ILB de base)
Application Gateway v1 (utilise le SKU ILB de base)
Virtual Machine Scale Sets (utilise le SKU ILB de base)
Clusters Azure Service Fabric (utilise le SKU ILB de base)
SQL Server Always On (utilise le SKU ILB de base)
Azure App Service Environment pour PowerApps (utilise le SKU ILB de base)
Gestion des API Azure (utilise le SKU ILB de base)
Azure AD DS (Azure Active Directory Domain Services) (utilise le SKU ILB de
base)
Pour plus d’informations, voir la configuration requise et les contraintes d’un appairage
mondial.
Les réseaux virtuels se trouvent dans des abonnements

ou des locataires Active Directory distincts
Pour configurer l’appairage de réseaux virtuels se trouvant dans des abonnements ou
des locataires Active Directory distincts, consultez Créer un appairage de réseaux virtuels
entre des abonnements différents.
７ Notes
Pour configurer l’appairage de réseaux, vous devez disposer des autorisations

Contributeur de réseaux dans les deux abonnements. Pour plus d’informations,
voir Autorisations d’appairage.
Configurer le peering de réseaux virtuels avec

une topologie hub-and-spoke qui utilise des
ressources locales
Pour une connexion site à site ou une connexion
ExpressRoute
Suivez les étapes décrites dans : Configurer le transit par passerelle VPN pour
Pour des connexions point à site

1. Suivez les étapes décrites dans : Configurer le transit par passerelle VPN pour
2. Une fois le peering de réseaux virtuels établi ou changé, téléchargez et réinstallez
le package point à site pour que les clients point à site obtiennent la mise à jour
des routes vers le réseau virtuel spoke.
Configurer le peering de réseaux virtuels avec

un réseau virtuel ayant une topologie hub-and-
spoke
Les réseaux virtuels se trouvent dans la même région
1. Dans le réseau virtuel hub, configurez une appliance virtuelle réseau (NVA).
2. Dans les réseaux virtuels spoke, utilisez des routes définies par l’utilisateur ayant
pour type de tronçon suivant « appliance virtuelle réseau ».
Pour plus d’informations, voir Chaînage de services.
７ Notes
Si vous avez besoin d’aide pour configurer un appliance virtuelle réseau, contactez
le fournisseur de l’appliance virtuelle réseau .
Pour plus d’informations sur la résolution des problèmes de configuration et de routage

d’appliance virtuelle réseau, voir Problèmes d’appliance virtuelle réseau dans Azure.
Les réseaux virtuels se trouvent dans des régions

différentes
Le transit via le peering de réseaux virtuels mondiaux est désormais pris en charge. La
connectivité ne fonctionne pas via le peering de réseaux virtuels mondiaux pour les
ressources suivantes :
Machines virtuelles derrière une référence (SKU) ILB de base

Application Gateway (utilise le SKU ILB de base)
Groupes identiques (utilise le SKU ILB de base)
Clusters Service Fabric (utilise la référence (SKU) ILB de base)
App Service Environment (utilise le SKU ILB de base)
Gestion des API (utilise la référence (SKU) ILB de base)
Azure AD DS (utilise le SKU ILB de base)
Pour en savoir plus sur les conditions et les contraintes d’un peering mondial, consultez
Peering de réseaux virtuels.
Résoudre un problème de connectivité entre

deux réseaux virtuels appairés
Connectez-vous au portail Azure avec un compte disposant des rôles et autorisations
nécessaires. Sélectionnez le réseau virtuel, sélectionnez Peering, puis consultez le champ
État. Qu’est-ce que l’état ?
L’état du peering est « Connecté »

Pour résoudre ce problème :
1. Vérifiez les flux de trafic réseau :
Utilisez les procédures Résolution des problèmes de connexion et de Vérification

du flux IP de la machine virtuelle source à la machine virtuelle de destination pour
déterminer s’il existe un groupe de sécurité réseau ou un UDR qui provoque des
interférences dans les flux de trafic.
Si vous utilisez un pare-feu ou une appliance virtuelle réseau :

a. Documentez les paramètres UDR pour pouvoir les restaurer une fois cette étape
effectuée.
b. Supprimez l’UDR du sous-réseau ou de la carte réseau de la machine virtuelle
source qui pointe vers l’appliance virtuelle réseau en tant que tronçon suivant.
Vérifiez la connectivité de la machine virtuelle source directement à la
destination, qui contourne l’appliance virtuelle réseau. Si cette étape ne
fonctionne pas, consultez l’utilitaire de résolution des problèmes d’appliance
virtuelle réseau.
2. Obtenez une trace réseau :

a. Commencez à capturer une trace réseau sur la machine virtuelle de destination.
Pour Windows, vous pouvez utiliser la commande Netsh. Pour Linux, utilisez la
commande TCPDump.
b. Exécutez la commande TcpPing ou PsPing de la source à la l’adresse IP de

destination.
Voici un exemple de commande TcpPing : tcping64.exe -t <destination VM

address> 3389
c. Une fois la commande TcpPing exécutée, arrêtez la capture de la trace réseau

sur la destination.
d. Si des paquets arrivent de la source, cela signifie qu’il n’y a aucun problème de
réseau. Examinez le pare-feu de la machine virtuelle et l’application écoutant sur
ce port pour localiser le problème de configuration.
７ Notes
Vous ne pouvez pas vous connecter aux types de ressources suivants via un
appairage de réseaux virtuels globaux (réseaux virtuels se trouvant dans des
régions différentes) :

Pour plus d’informations, voir la configuration requise et les contraintes d’un appairage
mondial.
L’état du peering est « Déconnecté »

Pour résoudre ce problème, supprimez le peering des deux réseaux virtuels, puis
recréez-le.
Résoudre un problème de connectivité entre un
réseau virtuel hub-and-spoke et une ressource
locale
Est-ce que votre réseau utilise une passerelle VPN ou une appliance virtuelle réseau
tierce ?
Mon réseau utilise une passerelle VPN ou d’appliance

virtuelle réseau tierce
Pour résoudre les problèmes de connectivité qui affectent une passerelle VPN ou
d’appliance virtuelle réseau tierce, voir les articles suivants :
Utilitaire de résolution des problèmes d’appliance virtuelle réseau

Chaînage de services
Mon réseau n’utilise pas de passerelle VPN ou

d’appliance virtuelle réseau tierce
Le réseau virtuel hub et le réseau virtuel spoke ont-ils une passerelle VPN ?
Le réseau virtuel hub et le réseau virtuel spoke ont une passerelle

VPN
L’utilisation d’une passerelle distante n’est pas prise en charge.
Si le réseau virtuel spoke dispose déjà d’une passerelle VPN, l’option Utiliser des
passerelles distantes n’est pas prise en charge sur le réseau virtuel spoke. Cela est dû à
une limitation du peering de réseaux virtuels.
Le réseau virtuel hub et le réseau virtuel spoke n’ont pas de

passerelle VPN
Pour les connexions site à site ou Azure ExpressRoute, vérifiez les points suivants. Il
s’agit des principales causes des problèmes de connectivité au réseau virtuel distant à
partir de ressources locales :
Sur le réseau virtuel doté d’une passerelle, vérifiez que la case Autoriser le trafic
transféré est cochée.
Sur le réseau virtuel non doté d’une passerelle, vérifiez que la case Utiliser des
passerelles distantes est cochée.
Demandez à votre administrateur réseau de vérifier vos appareils locaux pour
s’assurer que l’espace d’adressage du réseau virtuel distant a bien été ajouté à
tous.
Pour les connexions point à site :
Sur le réseau virtuel doté d’une passerelle, vérifiez que la case Autoriser le trafic
transféré est cochée.
Sur le réseau virtuel non doté d’une passerelle, vérifiez que la case Utiliser des
passerelles distantes est cochée.
Téléchargez et réinstallez le package client point à site. Les routes de réseau virtuel
qui viennent d’être appairées n’ajoutent pas automatiquement des routes aux
clients point à site.
Résoudre un problème de connectivité réseau

hub-and-spoke entre des réseaux virtuels
spoke de même région
Un réseau hub doit inclure une appliance virtuelle réseau. Configurez des UDR dans les
spokes qui ont une appliance virtuelle réseau définie en tant que tronçon suivant, puis
activez Autoriser le trafic transféré dans le réseau virtuel hub.
Pour plus d’informations, voir Chaînage de services et discutez de ces exigences avec le
fournisseur de l’appliance virtuelle réseau de votre choix.

hub-and-spoke entre des réseaux virtuels
spoke de régions distinctes
Le transit via le peering de réseaux virtuels mondiaux est désormais pris en charge. La
connectivité ne fonctionne pas via le peering de réseaux virtuels mondiaux pour les
ressources suivantes :

Pour plus d’informations, consultez les exigences et contraintes d’un peering mondial et
les différentes topologies VPN.

hub-and-spoke entre une application web et le
réseau virtuel spoke
Pour résoudre ce problème :
1. Connectez-vous au portail Azure.

2. Dans l’application web, sélectionnez réseau, puis Intégration de réseau virtuel.
3. Vérifiez si vous pouvez voir le réseau virtuel distant. Entrez manuellement l’espace
d’adressage du réseau virtuel distant (Synchroniser le réseau et Ajouter des
routes).
Pour plus d’informations, consultez les articles suivants :
Intégrer votre application à un réseau virtuel Azure

À propos du routage VPN point à site
Résoudre les problèmes liés à un message

d’erreur de configuration du peering de
réseaux virtuels
Le locataire actuel <TENANT ID> n’est pas autorisé à

accéder à l’abonnement lié
Pour résoudre ce problème, consultez Créer un appairage de réseaux virtuels entre des
Non connecté
Pour résoudre ce problème, supprimez le peering des deux réseaux virtuels, puis
recréez-le.
Échec de l’appairage d’un réseau virtuel Databricks

Pour résoudre ce problème, configurez le peering de réseaux virtuels sous Azure
Databricks, puis spécifiez le réseau virtuel cible à l’aide de l’ID de la ressource. Pour plus
d’informations, voir Appairer un réseau virtuel Databricks à un réseau virtuel distant.
Le réseau virtuel distant n’a pas de passerelle

Ce problème se produit lorsque vous appairez des réseaux virtuels de différents
locataires et que vous souhaitez ensuite configurer Use Remote Gateways . Une des
limites du Portail Azure est qu’il ne peut pas valider la présence d’une passerelle de
réseau virtuel dans le réseau virtuel d’un autre locataire.
Il existe deux façons de résoudre le problème :
Supprimez les Peerings et activez l’option Use Remote Gateways lorsque vous créez
un nouveau Peering.
Utilisez PowerShell ou l’interface CLI au lieu du Portail Azure pour activer Use
Remote Gateways .
Étapes suivantes
Résolution des problèmes de connectivité entre machines virtuelles Azure
Configurer et valider des connexions de
réseaux virtuels ou de VPN
Article • 01/06/2023
Ce guide pas à pas fournit des instructions pour configurer et valider différents
déploiements de VPN et de réseaux virtuels Azure. Les scénarios incluent les itinéraires
de transit, les connexions réseau à réseau, le protocole BGP (Border Gateway Protocol),
les connexions multisites et les connexions point à site.
Les passerelles VPN Azure offrent une certaine flexibilité quant à l'agencement de
pratiquement tout type de topologie de réseau virtuel connecté dans Azure. Par
exemple, vous pouvez connecter des réseaux virtuels :
Situés dans des régions différentes

Appartenant à des types de réseaux virtuels différents (Azure Resource Manager
ou classique)
Dans Azure ou dans un environnement hybride local
Dans le cadre d'abonnements différents
Connexion VPN réseau à réseau

La connexion d'un réseau virtuel à un autre réseau virtuel (réseau à réseau) via un VPN
est semblable à la connexion d'un réseau virtuel à un emplacement local. Les deux types
de connectivité utilisent une passerelle VPN pour fournir un tunnel sécurisé via IPsec et
IKE. Les réseaux virtuels peuvent être situés dans des régions identiques ou différentes
et appartenir à des abonnements identiques ou différents.
Si vos réseaux virtuels se trouvent dans la même région, vous pouvez envisager de les
connecter à l'aide de l'appairage de réseaux virtuels. L'appairage de réseaux virtuels
n'utilise pas de passerelle VPN. Il augmente le débit et diminue la latence. Pour
configurer une connexion d'appairage de réseaux virtuels, sélectionnez Configurer et
valider l'appairage de réseaux virtuels.
Si vos réseaux virtuels ont été créés à l'aide du modèle de déploiement Azure Resource
Manager, sélectionnez Configurer et valider un réseau virtuel Resource Manager sur
une connexion de réseau virtuel Resource Manager pour configurer une connexion
VPN.
Si l'un des réseaux virtuels a été créé à l'aide du modèle de déploiement Azure Classic et
l'autre via Resource Manager, sélectionnez Configurer et valider un réseau virtuel
classique sur une connexion de réseau virtuel Resource Manager pour configurer une
connexion VPN.
Configurer l'appairage de réseaux virtuels pour deux

réseaux virtuels de la même région
Avant de commencer à implémenter et à configurer l'appairage de réseaux virtuels
Azure, assurez-vous que vous remplissez les conditions préalables suivantes :
Les réseaux virtuels homologués doivent se trouver dans la même région Azure.
Les réseaux virtuels appairés doivent disposer d'espaces d'adressage IP qui ne se
chevauchent pas.
Le peering se fait entre deux réseaux virtuels. Il n’y a aucune relation transitive
dérivée entre les appairages. Par exemple, si VNetA est appairé à VNetB et que
VNetB est appairé à VNetC, VNetA n'est pas appairé à VNetC.
Si vous remplissez les conditions requises, vous pouvez suivre le Didacticiel : Connecter
des réseaux virtuels à l'aide de l'appairage de réseaux virtuels à partir du portail Azure
pour créer et configurer l'appairage.
Pour vérifier la configuration de l'appairage, utilisez la méthode suivante :
1. Connectez-vous au portail Azure à l'aide d'un compte doté des rôles et

2. Dans la boîte de dialogue contenant le texte Rechercher des ressources en haut
du portail Azure, tapez réseaux virtuels. Quand la mention Réseaux virtuels
apparaît dans les résultats de recherche, sélectionnez-la.
3. Dans le panneau Réseaux virtuels qui s'affiche, sélectionnez le réseau virtuel pour
lequel vous souhaitez créer un appairage.
4. Dans le volet qui s'affiche pour le réseau virtuel, accédez à la section Paramètres et
sélectionnez Appairages.
5. Sélectionnez un appairage et consultez les résultats de la configuration.
Pour Azure PowerShell, exécutez la commande Get-AzureRmVirtualNetworkPeering afin
d'obtenir l'appairage de réseaux virtuels. Voici un exemple :
PS C:\Users\User1> Get-AzureRmVirtualNetworkPeering -VirtualNetworkName

Vnet10-01 -ResourceGroupName dev-vnets
Name : LinkToVNET10-02
Id : /subscriptions/GUID/resourceGroups/dev-
vnets/providers/Microsoft.Network/virtualNetworks/VNET10-
01/virtualNetworkPeerings/LinkToVNET10-0
2
Etag : W/"GUID"
ResourceGroupName : dev-vnets
VirtualNetworkName : vnet10-01
ProvisioningState : Succeeded
RemoteVirtualNetwork : {
"Id":
"/subscriptions/GUID/resourceGroups/DEV-VNET
s/providers/Microsoft.Network/virtualNetworks/VNET10-02"
}
AllowVirtualNetworkAccess : True
AllowForwardedTraffic : False
AllowGatewayTransit : False
UseRemoteGateways : False
RemoteGateways : null
RemoteVirtualNetworkAddressSpace : null
Connecter un réseau virtuel Resource Manager à un autre

réseau virtuel Resource Manager
Vous pouvez directement configurer une connexion entre deux réseaux virtuels
Resource Manager. Ou vous pouvez configurer la connexion à l'aide d'IPsec.
Configurer une connexion VPN entre des réseaux virtuels

Resource Manager
Pour configurer une connexion entre des réseaux virtuels Resource Manager sans IPSec,
consultez Configurer une connexion de passerelle VPN réseau à réseau à l'aide du
portail Azure.
Pour configurer une connexion entre deux réseaux virtuels Resource Manager à l'aide
d'IPSec, suivez les étapes 1 à 5 de la section Créer une connexion site à site dans le
portail Azure pour chaque réseau virtuel.
７ Notes
Ces étapes s'appliquent uniquement aux réseaux virtuels associés au même

abonnement. Si vos réseaux virtuels figurent dans des abonnements différents,
vous devrez utiliser PowerShell pour établir la connexion. Consultez l’article
concernant PowerShell.
Valider une connexion VPN entre réseaux virtuels

Resource Manager
Pour vérifier que votre connexion VPN est correctement configurée, suivez les
instructions ci-dessous.
７ Notes
Les chiffres qui suivent les composants de réseau virtuel correspondent à ceux du
diagramme précédent.
1. Assurez-vous que les espaces d'adressage ne se chevauchent pas dans les réseaux
virtuels connectés.
2. Vérifiez que la plage d'adresses du réseau virtuel Azure Resource Manager (1) est
correctement définie dans l'instance Objet de connexion (4).
correctement définie dans l'instance Objet de connexion (3).
4. Vérifiez que les clés prépartagées correspondent aux objets de connexion.
5. Vérifiez que l'adresse IP virtuelle de la passerelle de réseau virtuel Azure Resource
Manager (2) est correctement définie dans l'instance Objet de connexion (4).
6. Vérifiez que l'adresse IP virtuelle de la passerelle de réseau virtuel Azure Resource
Manager (5) est correctement définie dans l'instance Objet de connexion (3).
Connecter un réseau virtuel classique à un réseau virtuel

Resource Manager
Vous pouvez établir une connexion entre des réseaux virtuels associés à des
abonnements différents et situés dans des régions différentes. Vous pouvez également
connecter des réseaux virtuels déjà connectés à des réseaux locaux, à condition que le
type de passerelle soit basé sur l'itinéraire.
Pour configurer une connexion entre un réseau virtuel classique et un réseau virtuel
Resource Manager, consultez Connecter des réseaux virtuels à partir de différents
modèles de déploiement à l'aide du portail Azure.
Pour vérifier la configuration lors de la connexion d'un réseau virtuel classique à un
réseau virtuel Azure Resource Manager, suivez les instructions ci-dessous.
７ Notes
Les chiffres qui suivent les composants de réseau virtuel correspondent à ceux du
diagramme précédent.
1. Assurez-vous que les espaces d'adressage ne se chevauchent pas dans les réseaux
virtuels connectés.
correctement définie dans la définition du réseau local classique (3).
3. Vérifiez que la plage d'adresses du réseau virtuel classique (1) est correctement
définie dans l'instance Objet de connexion d'Azure Resource Manager (4).
4. Vérifiez que l'adresse IP virtuelle de la passerelle de réseau virtuel classique (2) est
correctement définie dans l'instance Objet de connexion d'Azure Resource
Manager (4).
5. Vérifiez que la passerelle de réseau virtuel Azure Resource Manager (5) est
correctement définie dans l'instance Définition du réseau local classique (3).
6. Vérifiez que les clés prépartagées correspondent sur les deux réseaux virtuels
connectés :
Réseau virtuel classique : Définition du réseau local (3)

Réseau virtuel Azure Resource Manager : Objet de connexion (4)
Créer une connexion VPN point à site

Une configuration point à site (P2S dans le diagramme suivant) vous permet de
connecter de manière sécurisée un ordinateur client individuel à un réseau virtuel. Les
connexions point à site vous permettent de vous connecter à votre réseau virtuel à
partir d'un emplacement distant, par exemple depuis votre domicile ou une salle de
conférence. Elles sont également utiles lorsque seuls quelques clients doivent se
connecter à un réseau virtuel.
La connexion VPN point à site est initiée à partir de l'ordinateur client à l'aide du client
VPN Windows natif. Les clients qui se connectent utilisent des certificats pour
l’authentification.
Les connexions point à site ne nécessitent aucun périphérique VPN. Elles établissent la
connexion VPN via le protocole SSTP (Secure Socket Tunneling Protocol). Vous pouvez
établir une connexion point à site à un réseau virtuel à l'aide de divers outils et modèles
de déploiement :
Configurer une connexion point à site à un réseau virtuel à l'aide du portail Azure
Configurer une connexion point à site à un réseau virtuel à l'aide du portail Azure
(classique)
Configurer une connexion point à site à un réseau virtuel à l'aide de PowerShell
Valider votre connexion point à site

L'article Dépannage : problèmes de connexion point à site Azure passe en revue les
problèmes courants de connexion point à site.
Créer une connexion VPN multisite
Vous pouvez ajouter une connexion site à site (S2S dans le diagramme suivant) à un
réseau virtuel qui dispose déjà d'une connexion site à site, d'une connexion point à site
ou d'une connexion réseau à réseau. Ce type de connexion est souvent appelé
configuration multisite.
Actuellement, Azure utilise deux modèles de déploiement : Resource Manager et le

déploiement classique. Les deux modèles ne sont pas entièrement compatibles entre
eux. Pour configurer une connexion multisite avec des modèles différents, consultez les
articles suivants :
Ajouter une connexion site à site à un réseau virtuel avec une connexion de
passerelle VPN existante
Ajouter une connexion site à site à un réseau virtuel avec une connexion de
passerelle VPN existante (classique)
７ Notes
Les étapes décrites dans ces articles ne s'appliquent pas aux configurations avec
coexistence de connexions site à site et Azure ExpressRoute. Pour plus
d'informations, consultez Configurer la coexistence de connexions site à site et
ExpressRoute.
Configurer un itinéraire de transit

Un itinéraire de transit est un scénario de routage spécifique dans lequel vous connectez
plusieurs réseaux dans le cadre d'une topologie de connexion en chaîne. Ce routage
permet à des ressources de réseaux virtuels situées à chaque extrémité d'une chaîne de
communiquer entre elles par le biais de réseaux virtuels. Sans itinéraire de transit, des
réseaux ou appareils appairés via un hub ne peuvent pas communiquer.
Configurer un itinéraire de transit dans le cadre d'une

connexion point à site
Imaginez un scénario dans lequel vous souhaitez configurer une connexion VPN site à
site entre VNetA et VNetB. Vous pouvez également configurer un VPN point à site pour
que le client se connecte à la passerelle de VNetA. Ensuite, vous pouvez activer un
itinéraire de transit pour que les clients point à site puissent se connecter au réseau
virtuel VNetB qui transite par le réseau virtuel VNetA.
Ce scénario est pris en charge lorsque le protocole BGP est activé sur le VPN site à site
entre les réseaux virtuels VNetA et VNetB. Pour plus d'informations, consultez À propos
du routage VPN point à site.
Configurer un itinéraire de transit dans une connexion

ExpressRoute
Azure ExpressRoute vous permet d’étendre vos réseaux locaux au cloud de Microsoft
par le biais d’une connexion privée dédiée assurée par un fournisseur de connectivité.
Avec ExpressRoute, vous pouvez établir des connexions aux services de cloud
computing Microsoft, par exemple Microsoft Azure, Microsoft 365 et Dynamics 365.
Pour plus d’informations, voir Appairage ExpressRoute.
７ Notes
Si les réseaux virtuels VNetA et VNetB se trouvent dans la même région

géopolitique, nous vous recommandons de lier les deux réseaux virtuels au circuit
ExpressRoute au lieu de configurer un itinéraire de transit. Si vos réseaux virtuels se
trouvent dans des régions géopolitiques différentes, vous pouvez également les lier
directement à votre circuit, à condition de disposer d'ExpressRoute Premium.
Si vous disposez d'ExpressRoute et d'une coexistence site à site, l'itinéraire de transit

n'est pas pris en charge. Pour plus d'informations, consultez Configurer ExpressRoute et
le mode site à site à l'aide de PowerShell.
Si vous avez activé ExpressRoute pour connecter vos réseaux locaux à un réseau virtuel
Azure, vous pouvez activer un appairage des réseaux virtuels pour lesquels vous
souhaitez disposer d'un itinéraire de transit. Pour permettre à vos réseaux locaux de se
connecter au réseau virtuel distant, vous devez configurer un appairage de réseaux
virtuels.
７ Notes
L'appairage de réseaux virtuels est uniquement disponible pour les réseaux virtuels
d'une même région.
Pour savoir si vous avez configuré un itinéraire de transit pour l'appairage de réseaux
virtuels, suivez les instructions ci-dessous :

2. Créez un appairage entre VNetA et VNetB, comme indiqué dans le diagramme
précédent.
3. Dans le volet qui s'affiche pour le réseau virtuel, accédez à la section Paramètres et
sélectionnez Appairages.
4. Sélectionnez l'appairage que vous souhaitez afficher. Puis sélectionnez
Configuration pour confirmer que vous avez activé l'option Autoriser le transit par
passerelle sur le réseau virtuel VNetA connecté au circuit ExpressRoute et l'option
Utiliser la passerelle distante sur le réseau virtuel VNetB distant non connecté au

connexion d'appairage de réseaux virtuels
Lorsque des réseaux virtuels sont homologués, vous pouvez également configurer la
passerelle du réseau virtuel homologué en tant que point de transit vers un réseau local.
Pour configurer un itinéraire de transit dans le cadre d'un appairage de réseaux virtuels,
consultez Connexions réseau à réseau.
７ Notes
Le transit de la passerelle n’est pas pris en charge dans la relation d’appairage entre
des réseaux virtuels créés via des modèles de déploiement différents. Les deux
réseaux virtuels de la relation d'appairage doivent avoir été créés via Resource
Manager pour que le transit par passerelle fonctionne.
Pour savoir si vous avez configuré un itinéraire de transit pour l'appairage de réseaux
virtuels, suivez les instructions ci-dessous :

2. Dans la boîte de dialogue contenant le texte Rechercher des ressources en haut
du portail Azure, tapez réseaux virtuels. Quand la mention Réseaux virtuels
apparaît dans les résultats de recherche, sélectionnez-la.
3. Dans le panneau Réseaux virtuels qui s'affiche, sélectionnez le réseau virtuel pour
lequel vous souhaitez vérifier le paramètre d'appairage.
4. Dans le volet qui s'affiche pour le réseau virtuel que vous avez sélectionné, accédez
à la section Paramètres et sélectionnez Appairages.
5. Sélectionnez l'appairage que vous souhaitez afficher. Vérifiez que vous avez activé
les options Autoriser le transit par passerelle et Utiliser la passerelle distante sous
Configuration.

connexion réseau à réseau
Pour configurer un itinéraire de transit entre réseaux virtuels, vous devez activer le
protocole BGP sur toutes les connexions réseau à réseau intermédiaires à l'aide du
modèle de déploiement Resource Manager et de PowerShell. Pour obtenir des
instructions, consultez Configurer le protocole BGP sur des passerelles VPN Azure à
l'aide de PowerShell.
Le trafic de transit par le biais de passerelles VPN Azure est possible à l'aide du modèle
de déploiement classique, mais il s'appuie sur des espaces d'adressage définis de
manière statique dans le fichier de configuration réseau. Le protocole BGP n'est pas
encore pris en charge par les réseaux virtuels et passerelles VPN Azure via le modèle de
déploiement classique. Sans le protocole BGP, la définition manuelle d'espaces
d'adressage de transit peut entraîner des erreurs et n'est donc pas recommandée.
７ Notes
Vous devez configurer les connexions réseau à réseau classiques à l'aide du portail
Azure Classic ou d'un fichier de configuration réseau sur le portail Classic. Vous ne
pouvez pas créer ou modifier un réseau virtuel classique via le modèle de
déploiement Azure Resource Manager ou le portail Azure. Pour plus d'informations
sur l'itinéraire de transit relatif aux réseaux virtuels classiques, consultez le blog des
développeurs Microsoft.

connexion site à site
Pour configurer un itinéraire de transit entre votre réseau local et un réseau virtuel via
une connexion site à site, vous devez activer le protocole BGP sur toutes les connexions
site à site intermédiaires à l'aide du modèle de déploiement Resource Manager et de
PowerShell. Pour obtenir des instructions, consultez Configurer le protocole BGP sur des
passerelles VPN Azure à l'aide de PowerShell.
Le trafic de transit par le biais de passerelles VPN Azure est possible à l'aide du modèle
de déploiement classique, mais il s'appuie sur des espaces d'adressage définis de
manière statique dans le fichier de configuration réseau. Le protocole BGP n'est pas
encore pris en charge par les réseaux virtuels et passerelles VPN Azure via le modèle de
déploiement classique. Sans le protocole BGP, la définition manuelle d'espaces
d'adressage de transit peut entraîner des erreurs et n'est donc pas recommandée.
７ Notes
Vous devez configurer les connexions site à site classiques à l'aide du portail Azure
Classic ou d'un fichier de configuration réseau sur le portail Classic. Vous ne pouvez
pas créer ou modifier un réseau virtuel classique via le modèle de déploiement
Azure Resource Manager ou le portail Azure. Pour plus d'informations sur
l'itinéraire de transit relatif aux réseaux virtuels classiques, consultez le blog des
développeurs Microsoft.
Configurer BGP pour une passerelle VPN

BGP est le protocole de routage standard utilisé sur Internet pour échanger des
informations de routage et d'accessibilité entre plusieurs réseaux. Lorsque le protocole
BGP est utilisé dans le contexte des réseaux virtuels Azure, il active les passerelles VPN
Azure et vos périphériques VPN locaux, que l'on appelle des pairs ou voisins BGP. Ceux-
ci échangent des « itinéraires » informent les deux passerelles sur la disponibilité et
l’accessibilité des préfixes pour le passage à travers les passerelles ou routeurs
impliqués.
Le protocole BGP assure également le routage de transit entre plusieurs réseaux en

propageant les itinéraires qu'une passerelle BGP obtient d'un pair BGP à tous les autres
pairs BGP. Pour plus d'informations, consultez Vue d'ensemble du protocole BGP avec
les passerelles VPN Azure.
Configurer BGP pour une connexion VPN

Pour configurer une connexion VPN utilisant le protocole BGP, consultez Configurer le
protocole BGP sur des passerelles VPN Azure à l'aide de PowerShell.
Activez le protocole BGP sur la passerelle de réseau virtuel en créant un numéro de

système autonome. Les passerelles de base ne prennent pas en charge le protocole
BGP. Pour vérifier la référence SKU de la passerelle, accédez à la section Vue d'ensemble
du panneau Passerelle VPN dans le portail Azure. Si vous disposez d'une référence SKU
De base, vous devez la remplacer (voir Redimensionner la passerelle) par VpnGw1.
La vérification de la référence SKU peut entraîner un temps d'arrêt de 20 à 30 minutes.

Dès que la passerelle dispose de la référence SKU qui convient, vous pouvez ajouter le
numéro de système autonome via la cmdlet PowerShell Set-
AzureRmVirtualNetworkGateway. Une fois le numéro AS configuré, une adresse IP de
pair BGP pour la passerelle est fournie automatiquement.
Vous devez fournir manuellement à LocalNetworkGateway un numéro de système

autonome et une adresse de pair BGP. Vous pouvez définir les valeurs ASN et -
BgpPeeringAddress à l'aide de la cmdlet PowerShell New-AzureRmLocalNetworkGateway
ou Set-AzureRmLocalNetworkGateway. Certains numéros de système autonome sont

réservés à Azure et vous ne pouvez pas les utiliser de la manière décrite dans À propos
du protocole BGP avec une passerelle VPN Azure.
Le protocole BGP doit être activé sur l'objet de connexion. Vous pouvez définir la valeur
-EnableBGP sur $True via la cmdlet New-AzureRmVirtualNetworkGatewayConnection ou
Set-AzureRmVirtualNetworkGatewayConnection.
Valider la configuration BGP

Pour savoir si le protocole BGP est correctement configuré, vous pouvez exécuter les
cmdlets get-AzureRmVirtualNetworkGateway et get-AzureRmLocalNetworkGateway . Vous
verrez ensuite une sortie liée au protocole BGP dans la partie BgpSettingsText . Par
exemple :
"Asn": AsnNumber,
"BgpPeeringAddress": "IP address",
"PeerWeight": 0
Créer une connexion VPN active/active

hautement disponible
Les principales différences entre les passerelles en modes actif/actif et actif/passif sont
les suivantes :
Vous devez créer deux configurations IP de passerelle avec deux adresses IP

publiques.
Vous devez définir l'indicateur EnableActiveActiveFeature.
La référence SKU de la passerelle doit être VpnGw1, VpnGw2 ou VpnGw3.
Pour obtenir une haute disponibilité des connexions intersites et réseau à réseau, vous
devez déployer plusieurs passerelles VPN, et établir différentes connexions parallèles
entre vos réseaux et Azure. Pour une vue d'ensemble des options de connectivité et de
topologie, consultez Configuration haute disponibilité pour la connectivité intersites et
réseau à réseau.
Pour créer des connexions intersites et réseau à réseau en mode actif/actif, suivez les
instructions de la section Configurer des connexions VPN S2S en mode actif/actif avec
des passerelles VPN Azure afin de configurer une passerelle VPN Azure en mode
actif/actif.
７ Notes
Lorsque vous ajoutez des adresses à la passerelle de réseau local pour le

mode actif/actif activé pour le protocole BGP, ajoutez uniquement les adresses
/32 des pairs BGP. Si vous ajoutez des autres adresses, celles-ci sont
considérées comme des itinéraires statiques et ont priorité sur les itinéraires
BGP.
Vous devez utiliser des numéros de système autonome BGP différents pour
les réseaux locaux qui se connectent à Azure. (En cas de numéros de système
autonome identiques, vous devez modifier celui de votre réseau virtuel si
votre périphérique VPN local l'utilise déjà pour s'appairer à des voisins BGP.)
Modifier un type de passerelle VPN Azure après

le déploiement
Vous ne pouvez pas procéder au remplacement direct d'un type de passerelle de réseau
virtuel Azure basé sur une stratégie par un type basé sur un itinéraire, ou inversement.
Vous devez d'abord supprimer la passerelle. Suite à cela, l'adresse IP et la clé
prépartagée ne seront pas conservées. Vous pourrez alors créer une nouvelle passerelle
du type souhaité.
Pour supprimer et créer une passerelle, procédez comme suit :
1. Supprimez toutes les connexions associées à la passerelle d’origine.

2. Supprimez la passerelle à l'aide du portail Azure, de PowerShell ou de PowerShell
classique :
Supprimer une passerelle de réseau virtuel à l'aide du portail Azure

Supprimer une passerelle de réseau virtuel à l'aide de PowerShell
Supprimer une passerelle de réseau virtuel à l'aide de PowerShell (classique)
3. Suivez les étapes de la section Créer la passerelle VPN pour créer la nouvelle
passerelle du type souhaité et terminer l'installation du VPN.
７ Notes
Ce processus prend environ 60 minutes.
Étapes suivantes
Diagnostiquer un problème de filtre de
trafic réseau sur une machine virtuelle
Dans cet article, vous allez apprendre à diagnostiquer un problème de filtre de trafic
réseau en consultant les règles de sécurité du groupe de sécurité réseau (NSG) qui
entrent en vigueur pour une machine virtuelle.
Les groupes de sécurité réseau vous permettent de contrôler les types de trafic
transitant sur 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 le sous-réseau sur lequel celle-ci se trouve. Les règles dans
différents groupe de sécurité réseau sont parfois en conflit entre elles et peuvent avoir
une incidence sur la connectivité réseau d’une machine virtuelle. Vous pouvez afficher
toutes les règles de sécurité effectives de vos groupes de sécurité réseau, telles
qu’appliquées aux interfaces réseau de votre machine virtuelle. Si vous n’êtes pas
familiarisé 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, et une interface réseau appelé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, selon le cas, pour la machine virtuelle dont vous analysez le
problème.
Diagnostiquer à l’aide du portail Azure
1. Connectez-vous au portail Azure avec un compte Azure disposant des
2. 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.
3. Sous PARAMÈTRES, sélectionnez Mise en réseau, comme indiqué dans l’image

suivante :
Les règles répertoriées dans l’image précédente concernent une interface réseau
nommée myVMVMNic. 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 :
mySubnetNSG : associé au sous-réseau dans lequel se trouve l’interface

réseau.
myVMNSG : associé à l’interface réseau de la machine virtuelle nommée
myVMVMNic.
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.
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 se trouvent en-dessous. 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. Dans 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é.
4. Assurez-vous que la machine virtuelle est en cours d’exécution, et sélectionnez

Règles de sécurité effectives, comme illustré dans l’image précédente, pour voir
les règles de sécurité effectives illustrées dans l’image suivante :
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.
Pour voir les préfixes représentés par chaque balise de service, sélectionnez une
règle, telle que la règle nommée AllowAzureLoadBalancerInbound. L’illustration
suivante montre les préfixes pour la balise de service AzureLoadBalancer :
Bien que la balise de service AzureLoadBalancer représente uniquement un

préfixe, d’autres balises de service en représentent plusieurs.
5. Les étapes précédentes ont montré les règles de sécurité pour une interface réseau
nommée myVMVMNic, mais vous avez également vu une interface réseau
nommée myVMVMNic2 dans certaines des images précédentes. 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 pour l’interface réseau myVMVMNic2, sélectionnez-le. Comme
indiqué dans l’illustration qui suit, l’interface réseau a les mêmes règles associées à
son sous-réseau que l’interface réseau myVMVMNic, 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 myVMVMNic, l’interface réseau myVMVMNic2
ne dispose pas d’un 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 ils peuvent être différents. Vous pouvez associer le même groupe
de sécurité réseau à toutes les interfaces réseau individuelles et à tous les sous-
réseaux que vous 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.

Groupe de sécurité réseau : découvrez comment afficher un groupe de sécurité
réseau.
Diagnostiquer à l’aide de PowerShell
７ Notes

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 exécutez PowerShell localement, vous devez aussi exécuter
Connect-AzAccount pour vous connecter à Azure avec un compte disposant des
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é
effectifs d’une interface réseau nommée myVMVMNic, qui se trouve dans un groupe de
ressources appelé myResourceGroup :
Azure PowerShell
Get-AzEffectiveNetworkSecurityGroup `
-NetworkInterfaceName myVMVMNic `
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 à laquelle différents groupes de
sécurité réseau sont 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 Diagnostic

supplémentaire et Considérations.
Si vous ignorez le nom d’une interface réseau, mais que vous connaissez le nom de la
machine virtuelle à laquelle l’interface réseau est attachée, les commandes suivantes
retournent les ID de toutes les interfaces réseau attachées à une machine virtuelle :
Azure PowerShell
$VM = Get-AzVM -Name myVM -ResourceGroupName myResourceGroup
$VM.NetworkProfile
Le résultat ressemble à ce qui suit :
Sortie
NetworkInterfaces
-----------------
{/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/Microsoft.Netw
ork/networkInterfaces/myVMVMNic
Dans la précédente sortie, le nom d’interface réseau est myVMVMNic.
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 rechercher 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
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é effectives d’une interface
réseau nommée myVMVMNic, qui se trouve dans un groupe de ressources appelé
myResourceGroup :
Azure CLI
az network nic list-effective-nsg \

--name myVMVMNic \
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 à laquelle différents groupes de
sécurité réseau sont 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 Diagnostic
supplémentaire et Considérations.
Azure CLI
az vm show \
--name myVM \
Dans les résultats retournés, vous obtenez des informations similaires à l’exemple
suivant :
Sortie
"networkProfile": {
"additionalProperties": {},
"networkInterfaces": [
{
"additionalProperties": {},
"id":
"/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/Microsoft.Netw
ork/networkInterfaces/myVMVMNic",
"primary": true,
},
Dans la sortie précédente, le nom de l’interface réseau est interface myVMVMNic.
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: si le groupe de sécurité réseau est associé à une interface réseau ou à
un sous-réseau. Si un groupe de sécurité réseau est associé aux deux, la sortie est
retournée avec le NetworkSecurityGroup, Association, et les
EffectiveSecurityRules, pour chaque groupe de sécurité réseau. Si le groupe de
sécurité réseau est associé ou dissocié immédiatement avant l’exécution de cette
commande pour afficher les règles de sécurité effectives, il se peut que vous deviez
attendre quelques secondes pour que la modification apparaisse dans la sortie de
la commande.
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 commençant par la règle
securityRules/ sont des règles que vous avez créées. 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.
Si vous voyez des règles en double répertoriées dans la sortie, cela est dû au fait qu’un
groupe de sécurité réseau est associé à la fois à l’interface réseau et au sous-réseau. Les
deux groupes de sécurité réseau ont les mêmes règles par défaut et peuvent avoir des
règles supplémentaires en double, si vous avez créé vos propres règles identiques pour
les deux groupes de sécurité réseau.
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) ne permet de trafic entrant par le port 80 à partir d’internet.
Résoudre un problème
Si vous utilisez le portail Azure, PowerShell, ou Azure CLI pour diagnostiquer le
problème présenté dans le scénario de cet article, la solution consiste à créer une règle
de sécurité réseau avec les propriétés suivantes :
Propriété Valeur
Source Quelconque
Source port ranges 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 80
destination
Protocol TCP
Propriété Valeur
Action Allow
Priority 100
Name Allow-HTTP-All
Après avoir créé la règle, le port 80 autorise le trafic entrant à partir d’internet, étant
donné que la priorité de la règle est supérieure à la règle de sécurité par défaut
nommée DenyAllInBound, qui interdit le trafic. Apprenez à créer une règle de sécurité. Si
différents groupes de sécurité réseau sont associés à l’interface réseau et au sous-
réseau, vous devez créer la même règle dans chaque groupe de sécurité réseau.
Lorsque Azure traite le trafic entrant, il traite les règles dans le groupe de sécurité réseau
associé au sous-réseau (s’il existe un groupe de sécurité réseau associé) et il traite
ensuite les règles dans le groupe de sécurité réseau associé à l’interface réseau. S’il
existe un groupe de sécurité réseau associé à l’interface réseau et au sous-réseau, le
port doit être ouvert dans chaque groupe de sécurité réseau, pour que le trafic atteigne
la machine virtuelle. 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é.
Si vous avez des réseaux virtuels homologues, par défaut, la balise de service
VIRTUAL_NETWORK s’étend automatiquement pour inclure les préfixes des
réseaux virtuels homologues. 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.
Les règles de sécurité effectives sont uniquement affichées pour une interface
réseau s’il existe un groupe de sécurité réseau associé à l’interface réseau de la
machine virtuelle et/ ou au sous-réseau, et si la machine virtuelle est en cours
d’exécution.
Si aucun groupe de sécurité réseau n’est associé à la carte réseau ou au sous-
réseau, et si une adresse IP publique est affectée à une machine virtuelle, tous les
ports sont ouverts pour les accès entrants et sortants pour toutes les destinations.
Si la machine virtuelle possède une adresse IP publique, nous vous recommandons
d’appliquer un groupe de sécurité réseau au sous-réseau de l’interface réseau.
Diagnostic supplémentaire
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é. S’il est
refusé, IP Flow Verify vous indique la règle de sécurité refusant le trafic.
Si aucune règle de sécurité n’est à l’origine d’un échec de connectivité réseau
d’une machine virtuelle, les causes du problème peuvent être les suivantes :
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 de tunnel vers une appliance
virtuelle ou sur site, vous n’êtes peut-être pas en mesure de vous connecter à la
machine virtuelle à partir d’internet. Pour savoir comment diagnostiquer les
problèmes de routage pouvant entraver le flux du trafic sortant de la machine
virtuelle, consultez Diagnostiquer un problème de routage de trafic réseau de la
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 mes 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
Diagnostiquer un problème de routage
sur une machine virtuelle
Dans cet article, vous apprenez à diagnostiquer un problème de routage en regardant

les itinéraires qui sont effectifs pour une interface réseau sur une machine virtuelle.
Azure crée plusieurs itinéraires par défaut pour chaque sous-réseau de machine
virtuelle. Vous pouvez remplacer les itinéraires par défaut d’Azure, en définissant des
itinéraires dans une table de routage que vous associez ensuite à un sous-réseau. Ce
mélange d’itinéraires que vous créez, d’itinéraires par défaut d’Azure et d’itinéraires
propagés à partir de votre réseau local via une passerelle VPN Azure (si le réseau virtuel
est connecté au réseau local) en utilisant Border Gateway Protocol (BGP), constitue les
itinéraires effectifs de toutes les interfaces réseau d’un sous-réseau. Si les notions de
réseau virtuel, d’interface réseau ou de routage ne vous sont pas familières, consultez
Vue d’ensemble du réseau virtuel, Interface réseau et Vue d’ensemble du routage.
Scénario
Vous essayez de vous connecter à une machine virtuelle, mais la connexion échoue. Afin
de déterminer la raison pour laquelle vous ne pouvez pas vous connecter à la machine
virtuelle, consultez les itinéraires effectifs d’une interface réseau au moyen du portail
Azure, de PowerShell, ou d’Azure CLI.
Les étapes qui suivent supposent que vous disposez d’une machine virtuelle existante
qui permet d’afficher les itinéraires effectifs. 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, et une interface réseau appelée myVMNic1.
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, selon le cas, pour la machine virtuelle dont vous analysez le problème.
Diagnostiquer à l’aide du portail Azure

1. Connectez-vous au portail Azure avec un compte Azure disposant des
2. En haut du portail Azure, dans la zone de recherche, indiquez le nom d’une

machine virtuelle en cours d’exécution. Quand le nom de cette machine virtuelle
apparaît dans les résultats de la recherche, sélectionnez-le.
3. Sous Paramètres sur la gauche, sélectionnez Mise en réseau et accédez à la

ressource d’interface réseau en sélectionnant son nom.
4. Sur la gauche, sélectionnez Itinéraires effectifs. Les routes effectives d’une

interface réseau nommée myVMNic1 sont affichés dans l’image suivante :
S’il existe plusieurs interfaces réseau attachées à la machine virtuelle, vous pouvez
voir les itinéraires effectifs de chaque interface réseau en sélectionnant les
interfaces une à une. Chaque interface réseau pouvant se trouver dans un sous-
réseau différent, ces interfaces peuvent chacune disposer de plusieurs itinéraires
effectifs.
Dans l’exemple de l’image précédente, les itinéraires répertoriés sont les itinéraires
par défaut qu’Azure crée pour chaque sous-réseau. Votre liste contient au moins
ces itinéraires, mais elle peut s’enrichir d’itinéraires supplémentaires, selon les
fonctionnalités que vous avez peut-être activées pour votre réseau virtuel, par
exemple son appairage à un autre réseau virtuel ou sa connexion à votre réseau
local par le biais d’une passerelle VPN Azure. Pour en savoir plus sur chacun de ces
itinéraires, et sur les autres itinéraires pouvant s’afficher pour votre interface
réseau, consultez Routage de trafic de réseaux virtuels. Si votre liste comporte un
grand nombre d’itinéraires, il peut être plus facile de sélectionner Télécharger pour
récupérer un fichier .csv contenant la liste des itinéraires.
Même si dans les étapes précédentes, les itinéraires effectifs ont été affichés à l’aide de
la machine virtuelle, vous pouvez également les voir avec une :
Interface réseau individuelle : découvrez comment voir une interface réseau.

Table de routage individuelle : Découvrez comment voir une table de routage.
Diagnostiquer à l’aide de PowerShell
７ Notes

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 exécutez PowerShell localement, vous devez aussi exécuter
Connect-AzAccount pour vous connecter à Azure avec un compte disposant des
Obtenez les itinéraires effectifs d’une interface réseau avec Get-AzEffectiveRouteTable.

L’exemple suivant récupère les itinéraires effectifs d’une interface réseau nommée
myVMNic1, qui se trouve dans un groupe de ressources appelé myResourceGroup :
Azure PowerShell
Get-AzEffectiveRouteTable `
-NetworkInterfaceName myVMNic1 `
| Format-Table
Pour comprendre les informations retournées dans le résultat, consultez Vue d’ensemble
du routage. Le résultat n’est retourné que si la machine virtuelle est en cours
d’exécution. S’il existe plusieurs interfaces réseau attachées à la machine virtuelle, vous
pouvez examiner les itinéraires effectifs de chaque interface réseau. Chaque interface
réseau pouvant se trouver dans un sous-réseau différent, ces interfaces peuvent
chacune disposer de plusieurs itinéraires effectifs. Si des problèmes de communication
subsistent, consultez Diagnostic supplémentaire et Considérations.
Azure PowerShell
$VM = Get-AzVM -Name myVM `

$VM.NetworkProfile
Le résultat ressemble à ce qui suit :
PowerShell
NetworkInterfaces
-----------------
{/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/Microsoft.Netw
ork/networkInterfaces/myVMNic1
Dans la précédente sortie, le nom d’interface réseau est myVMNic1.
Diagnostiquer à l’aide d’Azure CLI

Vous pouvez exécuter les commandes qui suivent dans Azure Cloud Shell ou en
exécutant l’interface CLI à partir de votre ordinateur. Azure CLI version 2.0.32 ou
ultérieure est nécessaire pour cet article. Exécutez az --version pour rechercher 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 itinéraires effectifs d’une interface réseau avec az network nic show-
effective-route-table. L’exemple suivant récupère les itinéraires effectifs d’une interface
réseau nommée myVMNic1, qui se trouve dans un groupe de ressources appelé
myResourceGroup :
Azure CLI
az network nic show-effective-route-table \

--name myVMNic1 \
Pour comprendre les informations retournées dans le résultat, consultez Vue d’ensemble
du routage. Le résultat n’est retourné que si la machine virtuelle est en cours
d’exécution. S’il existe plusieurs interfaces réseau attachées à la machine virtuelle, vous
pouvez examiner les itinéraires effectifs de chaque interface réseau. Chaque interface
réseau pouvant se trouver dans un sous-réseau différent, ces interfaces peuvent
chacune disposer de plusieurs itinéraires effectifs. Si des problèmes de communication
subsistent, consultez Diagnostic supplémentaire et Considérations.
Azure CLI
az vm show \
--name myVM \
Résoudre un problème
En règle générale, la résolution des problèmes de routage englobe les solutions
suivantes :
Ajout d’un itinéraire personnalisé pour remplacer un des itinéraires par défaut
d’Azure. Découvrez comment ajouter un itinéraire personnalisé.
Modification ou suppression d’un itinéraire personnalisé pouvant provoquer le
routage vers un emplacement non souhaité. Découvrez comment modifier ou
supprimer un itinéraire personnalisé.
Vérification de l’association de la table de routage qui contient les itinéraires
personnalisés définis, au sous-réseau dans lequel se trouve l’interface réseau.
Découvrez comment associer une table de routage à un sous-réseau.
Vérification du bon fonctionnement des dispositifs, tels qu’une passerelle VPN
Azure ou des appliances virtuelles de réseau déployées. Utilisez la fonctionnalité
Diagnostics VPN de Network Watcher pour déterminer les problèmes rencontrés
avec une passerelle VPN Azure.
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 communication, considérez les points suivants :
Le routage est basé sur le plus long préfixe correspondant parmi les itinéraires que
vous avez définis, le BGP (Border Gateway Protocol) et les itinéraires système. S’il
existe plusieurs itinéraires avec la même correspondance de préfixe le plus long, un
itinéraire est sélectionné en fonction de son origine, selon l’ordre répertorié dans
Vue d’ensemble du routage. Avec les itinéraires effectifs, vous ne pouvez voir que
les itinéraires effectifs présentant une correspondance de préfixe le plus long, par
rapport à tous les itinéraires disponibles. En comprenant comment sont évalués les
itinéraires d’une interface réseau, il est beaucoup plus facile ensuite de résoudre
les problèmes d’itinéraires spécifiques qui peuvent avoir une incidence sur la
communication depuis votre machine virtuelle.
Si vous avez défini des itinéraires personnalisés vers une appliance virtuelle de
réseau, en utilisant Appliance virtuelle comme type de tronçon suivant, assurez-
vous que le transfert IP est activé sur l’appliance virtuelle de réseau recevant le
trafic, sinon les paquets sont ignorés. En savoir plus sur l’activation du transfert IP
pour une interface réseau. Le système d’exploitation, ou l’application dans
l’appliance virtuelle de réseau, doit être également en mesure de transférer le trafic
réseau et être configuré pour cela.
Si vous avez créé un itinéraire vers 0.0.0.0/0, l’intégralité du trafic internet sortant
est acheminé vers le tronçon suivant que vous avez spécifié, par exemple vers une
appliance virtuelle de réseau ou une passerelle VPN. La création d’un itinéraire de
ce type est généralement appelé « tunneling forcé ». Les connexions à distance,
utilisant les protocoles RDP ou SSH depuis internet vers votre machine virtuelle,
peuvent ne pas fonctionner avec cet itinéraire, selon la façon dont le tronçon
suivant gère le trafic. Le tunneling forcé peut être activé :
Lors de l’utilisation du VPN de site à site, en créant un itinéraire avec comme
type de tronçon suivant une passerelle VPN. En savoir plus sur la configuration
du tunneling forcé.
Si un 0.0.0.0/0 (itinéraire par défaut) est publié sur BGP via une passerelle de
réseau virtuel lors de l’utilisation d’un VPN de site à site, ou du circuit
ExpressRoute. En savoir plus sur l’utilisation de BGP avec un VPN de site à site
ou ExpressRoute.
Pour que le trafic d’homologation de réseau virtuel fonctionne correctement, un
itinéraire système, avec comme type de tronçon suivant VNet Peering, doit exister
pour la plage de préfixes du réseau virtuel homologué. S’il n’existe aucune route
de ce type, et si le lien de peering de réseau virtuel est Connecté :
Attendez quelques secondes et réessayez. S’il s’agit d’un lien de peering
récemment établi, il faut parfois plus de temps pour propager les itinéraires à
toutes les interfaces réseau d’un sous-réseau. Pour en savoir plus sur le peering
de réseau virtuel, consultez la Vue d’ensemble du peering de réseau virtuel et la
gestion du peering de réseau virtuel.
Les règles du groupe de sécurité réseau peuvent avoir une incidence sur la
communication. Pour plus d’informations, consultez Diagnostiquer un problème
de filtre de trafic réseau sur une machine virtuelle.
Même si Azure affecte des itinéraires par défaut à chaque interface réseau Azure, si
vous disposez de plusieurs interfaces réseau attachées à la machine virtuelle, seule
l’interface réseau principale se voit attribuer un itinéraire par défaut (0.0.0.0/0), ou
une passerelle, au sein du système d’exploitation de la machine virtuelle.
Découvrez comment créer un itinéraire par défaut pour les interfaces réseau
secondaires attachées à une machine virtuelle Windows ou Linux. Apprenez-en
davantage sur les interfaces réseau principale et secondaire.
Diagnostic supplémentaire
Pour exécuter un test rapide en vue de déterminer le type de tronçon suivant pour
le trafic destiné à un emplacement, utilisez la fonctionnalité Tronçon suivant
d’Azure Network Watcher. Cette fonctionnalité vous renseigne sur le type de
tronçon suivant du trafic destiné à un emplacement spécifié.
Si aucun itinéraire n’est à l’origine de l’échec de la communication réseau d’une
machine virtuelle, le problème peut provenir d’un logiciel de pare-feu s’exécutant
dans le système d’exploitation de la machine virtuelle.
Si vous établissez un trafic de tunneling forcé vers un appareil local par
l’intermédiaire d’une passerelle VPN, ou d’une appliance virtuelle de réseau, il est
possible que vous ne puissiez pas vous connecter à une machine virtuelle depuis
internet, selon la façon dont vous avez configuré le routage pour ces dispositifs.
Vérifiez que le routage configuré pour le dispositif achemine le trafic jusqu’à une
adresse IP publique ou privée pour la machine virtuelle.
Utilisez la fonctionnalité Résolution des problèmes de connexion de Network
Watcher pour déterminer les causes de routage, de filtrage ou les causes internes
au système d’exploitation pouvant être à l’origine des problèmes de
communication sortante.
Étapes suivantes
En savoir plus sur les tâches, les propriétés et les paramètres d’une table de
routage et des itinéraires.
En savoir plus sur tous les types de tronçon suivant, les itinéraires système et sur la
façon dont Azure choisit un itinéraire.
 Documentation
Résolution des problèmes d’appliance virtuelle réseau dans Azure

Résolvez les problèmes liés aux appliances virtuelles réseau (NVA) dans Azure et validez les exigences
de base de la plateforme Azure pour les configurations NVA.
Gérer un préfixe d’adresse IP personnalisé - Azure Virtual Network

En savoir plus sur les préfixes d’adresse IP personnalisés, et comment les gérer et les supprimer.
Configurer une capture de paquets pour les connexions VPN S2S à l’aide du Portail
Azure - Azure Virtual WAN
Découvrir comment configurer la capture de paquets de site à site pour le réseau étendu virtuel
Azure à l’aide du portail
Réinitialiser un circuit en échec - ExpressRoute : PowerShell : Azure

Cet article vous aide à réinitialiser un circuit ExpressRoute en état d’échec.
Configurer la capture de paquets pour une passerelle VPN - Azure VPN Gateway
Découvrez la fonctionnalité de capture de paquets que vous pouvez utiliser sur les passerelles VPN
pour cerner plus précisément la cause d’un problème.
Configurer une capture de paquets pour les connexions de site à site Virtual WAN -
Azure Virtual WAN
Découvrez comment effectuer une capture de paquets sur la passerelle VPN site à site Virtual WAN
au moyen de PowerShell.
Configurer le protocole BGP pour une passerelle VPN : Portail - Azure VPN Gateway
Découvrez comment configurer le protocole BGP pour la passerelle VPN Azure à l’aide du Portail
Azure.
Configuration de l’équilibreur de charge en sortie uniquement - Azure Load Balancer

Dans cet article, découvrez comment créer un équilibreur de charge interne avec NAT sortante.
Afficher 5 de plus
 Entrainement
Module
Introduction au Serveur de routes Azure - Training
Déterminez si le service Serveur de routes Microsoft Azure convient pour résoudre les retards et les
pannes dans la communication réseau.
Certification
Tester un débit réseau de machine
virtuelle à l’aide de NTTTCP
Cet article explique comment utiliser l’outil NTTTCP gratuit de Microsoft pour tester une
bande passante réseau et des performances de débit sur des machines virtuelles Azure
Windows ou Linux. Un outil comme NTTTCP cible le réseau à des fins de test et réduit
l’utilisation d’autres ressources susceptibles d’affecter les performances.
Prérequis
Pour tester un débit, vous avez besoin de deux machines virtuelles de même taille pour
qu’elles fonctionnent comme expéditeur et récepteur. Les deux machines virtuelles
doivent se trouver dans le même groupe de placement de proximité ou groupe à haute
disponibilité. Vous pouvez donc utiliser leurs adresses IP internes et exclure des
équilibreurs de charge du test.
Notez le nombre de cœurs de machine virtuelle et l’adresse IP de machine virtuelle du

récepteur à utiliser dans les commandes. Les commandes expéditeur et récepteur
utilisent l’adresse IP du récepteur.
７ Notes
Le test à l’aide d’une adresse IP virtuelle (VIP) est possible, mais il dépasse le cadre
de cet article.
Tester un débit avec des machines virtuelles

Windows ou Linux
Vous pouvez tester un débit à partir de machines virtuelles Windows en tirant parti de
NTTTCP ou de machines virtuelles Linux à l’aide de NTTTCP-for-Linux .
Windows
Configurer NTTTPS et tester une configuration

1. Sur les machines virtuelles de l’expéditeur et du destinataire, téléchargez la
dernière version de NTTTCP dans un dossier distinct tel que c:\tools.
2. Sur la machine virtuelle du destinataire, créez une règle allow de pare-feu

Windows Defender pour autoriser l’arrivée du trafic de NTTTCP. Il est plus
facile d’autoriser nttcp.exe par nom que d’autoriser des ports TCP entrants
spécifiques. Exécutez la commande suivante, en remplaçant c:\tools par
votre chemin de téléchargement pour ntttcp.exe si différent.
netsh advfirewall firewall add rule program=c:\tools\ntttcp.exe

name="ntttcp" protocol=any dir=in action=allow enable=yes
profile=ANY
3. Pour confirmer votre configuration, testez un seul flux TCP (Transfer Control
Protocol) pendant 10 secondes en exécutant les commandes suivantes :
Sur la machine virtuelle du récepteur, exécutez ntttcp -r -t 10 -P 1 .

Sur la machine virtuelle de l’expéditeur, exécutez ntttcp -s<receiver IP
address> -t 10 -n 1 -P 1 .
７ Notes
Utilisez les commandes précédentes uniquement pour tester la

configuration.
 Conseil
Lorsque vous exécutez le test pour la première fois afin de vérifier

l’installation, utilisez une courte durée de test pour obtenir des
commentaires rapides. Une fois la vérification du bon fonctionnement de
l’outil effectuée, étendez la durée de test à 300 secondes pour des
résultats plus précis.
Exécuter des tests de débit

Exécutez ntttcp.exe à partir de la ligne de commande Windows et non à partir de
PowerShell. Exécutez le test pendant 300 secondes, ou cinq minutes, sur les
machines virtuelles de l’expéditeur et du destinataire. L’expéditeur et le récepteur
doivent spécifier la même durée de test du paramètre -t .
1. Sur la machine virtuelle du destinataire, exécutez la commande suivante, en

remplaçant les espaces réservés <number of VM cores> et <receiver IP
address> par vos propres valeurs.
ntttcp -r -m [<number of VM cores> x 2],*,<receiver IP address> -t

300
L’exemple suivant montre une commande pour une machine virtuelle avec
quatre cœurs et une adresse IP de 10.0.0.4 .
ntttcp -r -m 8,*,10.0.0.4 -t 300
2. Sur la machine virtuelle de l’expéditeur, exécutez la commande suivante. Les

commandes expéditeur et récepteur diffèrent uniquement par le paramètre -
s ou -r qui désigne la machine virtuelle de l’expéditeur ou du récepteur.
ntttcp -s -m [<number of VM cores> x 2],*,<receiver IP address> -t

300
L’exemple suivant montre la commande de l’expéditeur pour une adresse IP

de récepteur de 10.0.0.4 .
ntttcp -s -m 8,*,10.0.0.4 -t 300
3. Attendez les résultats.
Tester un débit entre une machine virtuelle

Windows et une machine virtuelle Linux
Pour exécuter des tests de débit NTTTCP entre une machine virtuelle Windows et une
machine virtuelle Linux, activez le mode sans synchronisation à l’aide de l’indicateur -ns
sur Windows ou de l’indicateur -N sur Linux.
Windows
Pour effectuer un test avec la machine virtuelle Windows comme récepteur,

exécutez la commande suivante :
ntttcp -r -m [<number of VM cores> x 2],*,<Linux VM IP address> -t 300
Pour effectuer un test avec la machine virtuelle Windows en tant qu’expéditeur,

exécutez la commande suivante :
ntttcp -s -m [<number of VM cores> x 2],*,<Linux VM IP address> -ns -t

300
Test d’instances de service cloud

Ajoutez la section suivante à ServiceDefinition.csdef :
XML
<Endpoints>
<InternalEndpoint name="Endpoint3" protocol="any" />
</Endpoints>
Étapes suivantes
Optimisez le débit du réseau des machines virtuelles Azure.
Bande passante réseau de machine virtuelle.
Tester la latence du réseau des machines virtuelles
FAQ sur les réseaux virtuels Azure
Tester la latence du réseau entre des
machines virtuelles Azure
Cet article décrit comment tester la latence du réseau entre des machines virtuelles (VM)
Azure à l’aide des outils disponibles publiquement Latte pour Windows ou SockPerf
pour Linux.
Pour obtenir les résultats les plus précis, vous devez mesurer la latence du réseau des
machines virtuelles (VM) avec un outil conçu pour la tâche et qui exclut d’autres types
de latence, tels que la latence de l’application. Latte et SockPerf fournissent les résultats
de latence du réseau les plus pertinents en se concentrant sur le trafic des protocoles
TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). La plupart des
applications utilisent ces protocoles, et ce trafic a l’effet le plus important sur le niveau
de performance de l’application.
De nombreux autres outils courants de test de latence du réseau, tels que Ping, ne
mesurent pas le trafic TCP ou UDP. Des outils tels que Ping utilisent le protocole ICMP
(Internet Control Message Protocol), que les applications n’utilisent pas. Le trafic ICMP
peut être traité différemment du trafic d’application et n’affecte pas directement le
niveau de performances de l’application. Les résultats des tests ICMP ne s’appliquent
pas directement aux charges de travail qui utilisent TCP et UDP.
Latte et SockPerf mesurent uniquement les délais de livraison de la charge utile TCP ou
UDP. Ces outils utilisent l’approche suivante pour mesurer la latence du réseau entre
deux ordinateurs physiques ou virtuels :
1. Créez un canal de communication bidirectionnel entre les ordinateurs en désignant

l’un comme expéditeur et l’autre comme destinataire.
2. Envoyez et recevez des paquets dans les deux directions et mesurer la durée des
boucles (RTT).
Conseils et meilleures pratiques pour optimiser

la latence du réseau
Pour optimiser la latence du réseau entre des machines virtuelles, observez les
recommandations suivantes lorsque vous créez les machines virtuelles :
Utilisez la dernière version de Windows ou de Linux.

Activez la Mise en réseau accélérée pour des performances accrues.
Déployer des machines virtuelles dans un groupe de placement de proximité
Azure.
Créez des machines virtuelles plus volumineuses pour de meilleures performances.
Utilisez les meilleures pratiques suivantes pour tester et analyser la latence du réseau :
1. Dès que vous avez terminé le déploiement, la configuration et l’optimisation des

machines virtuelles du réseau, prenez des mesures de base de la latence du réseau
entre les machines virtuelles déployées afin d’établir des points de référence.
2. Testez les effets sur la latence du réseau de la modification de l’un des composants
suivants :
au logiciel du système d’exploitation ou de la pile réseau, y compris les

modifications de configuration ;
Une méthode de déploiement de machine virtuelle, telle que le déploiement
dans une zone de disponibilité ou un groupe de placement de proximité
(PPG).
aux propriétés des machines virtuelles, telles que les changements de taille
ou de mise en réseau accélérée ;
Une configuration de réseau virtuel, telle que le routage ou le filtrage des
modifications.
3. Comparez toujours les nouveaux résultats de test à la base de référence ou aux

derniers résultats de test avant les modifications contrôlées.
4. Répétez les tests chaque fois que vous observez ou déployez des modifications.
Tester des machines virtuelles avec Latte ou

SockPerf
Utilisez les procédures suivantes pour installer et tester la latence du réseau avec Latte
pour Windows ou SockPerf pour Linux.
Windows
Installer Latte et configurer des machines virtuelles

1. Téléchargez la dernière version de latte.exe sur les deux machines virtuelles,
dans un dossier distinct tel que c:\tools.
2. Sur la machine virtuelle du destinataire, créez une règle allow de pare-feu
Windows Defender pour autoriser l’arrivée du trafic de Latte. Il est plus facile
d’autoriser le programme latte.exe par nom que d’autoriser des ports TCP
entrants spécifiques. Dans la commande, remplacez l’espace réservé <path>
par le chemin d’accès dans lequel vous avez téléchargé latte.exe, par exemple
c:\tools\.
netsh advfirewall firewall add rule program=<path>latte.exe

name="Latte" protocol=any dir=in action=allow enable=yes
profile=ANY
Exécuter Latte sur les machines virtuelles

Exécutez latte.exe à partir de la ligne de commande Windows et non à partir de
PowerShell.
1. Sur la machine virtuelle du destinataire, exécutez la commande suivante, en

remplaçant les espaces réservés <receiver IP address> , <port> et
<iterations> par vos propres valeurs.
latte -a <receiver IP address>:<port> -i <iterations>
Environ 65 000 itérations suffisent à renvoyer des résultats représentatifs.

Tout numéro de port disponible est correct.
L’exemple suivant montre la commande pour une machine virtuelle ayant une
adresse IP 10.0.0.4 :
latte -a 10.0.0.4:5005 -i 65100
2. Sur la machine virtuelle de l’expéditeur, exécutez la même commande que sur

celle du destinataire, en ajoutant -c pour indiquer la machine virtuelle du
client ou de l’expéditeur. Remplacez à nouveau les espaces réservés <receiver
IP address> , <port> et <iterations> par vos propres valeurs.
latte -c -a <receiver IP address>:<port> -i <iterations>

Par exemple :
latte -c -a 10.0.0.4:5005 -i 65100
3. Attendez les résultats. Selon l’éloignement des machines virtuelles, le test peut
prendre quelques minutes. Vous pouvez commencer par un nombre inférieur
d'itérations pour vérifier que cela fonctionne avant d'exécuter de plus long
tests.
Étapes suivantes
Réduire la latence avec un groupe de placement de proximité Azure.
Optimiser le débit du réseau des machines virtuelles Azure.
Allouer la bande passante du réseau des machines virtuelles.
Testez la bande passante et le débit.
Pour plus d'informations sur le réseau virtuel Azure, consultez le FAQ du réseau
virtuel Azure.
Résolution des problèmes : Échec de la
suppression d’un réseau virtuel dans
Azure
Vous rencontrez peut-être des erreurs lors de vos tentatives de suppression de réseau
virtuel dans Microsoft Azure. Cet article fournit les étapes requises pour vous aider à
résoudre ce problème.
Si le problème que vous rencontrez avec Azure n’est pas traité dans cet article,
parcourez les forums Azure sur Microsoft Q&A et Stack Overflow . Vous pouvez publier
votre problème sur ces forums ou @AzureSupport sur Twitter . Vous pouvez
également envoyer une demande de support Azure. Pour envoyer une demande de
support sur la page Prise en charge Azure , sélectionnez Obtenir de l’aide.
Instructions pour la résolution des problèmes

1. Vérifiez si une passerelle de réseau virtuel s’exécute dans le réseau virtuel.
2. Vérifiez si une passerelle d’application s’exécute dans le réseau virtuel.
3. Vérifiez si des instances de conteneur Azure existent toujours dans le réseau
virtuel.
4. Vérifiez si Azure Active Directory Domain Services est activé dans le réseau virtuel.
5. Vérifiez si le réseau virtuel est connecté à d’autres ressources.
6. Vérifiez si une machine virtuelle s’exécute toujours dans le réseau virtuel.
7. Vérifiez si le réseau virtuel est bloqué en cours de migration.
8. Vérifiez si le réseau virtuel a été utilisé par une application web pour l’intégration
VNet.
Étapes de dépannage
Vérifier si une passerelle de réseau virtuel s’exécute dans

le réseau virtuel
Pour supprimer le réseau virtuel, vous devez d’abord supprimer la passerelle de réseau
virtuel.
Pour les réseaux virtuels classiques, accédez à la Vue d’ensemble du réseau virtuel
classique dans le portail Azure. Si la passerelle est en cours d’exécution dans le réseau
virtuel, vous verrez son adresse IP dans la section Connexions VPN.
Pour les réseaux virtuels, accédez à la page Vue d’ensemble du réseau virtuel.
Recherchez la passerelle de réseau virtuel dans les Appareils connectés.
Avant de pouvoir supprimer la passerelle, supprimez d’abord les objets de connexion de

la passerelle.
Vérifier si une passerelle d’application s’exécute dans le

réseau virtuel
Accédez à la page Vue d’ensemble du réseau virtuel. Vérifiez les Appareils connectés
dans la passerelle d’application.
S’il existe une passerelle d’application, vous devez la supprimer avant de pouvoir
supprimer le réseau virtuel.
Vérifier si des instances de conteneur Azure existent

toujours dans le réseau virtuel
1. Dans le portail Azure, accédez à la page Vue d’ensemble du groupe de ressources.
2. Dans l’en-tête de la liste des ressources du groupe de ressources, sélectionnez

Afficher les types masqués. Le type de profil réseau est masqué par défaut dans le
portail Azure.
3. Sélectionnez le profil réseau associé aux groupes de conteneurs.
5. Supprimez de nouveau le sous-réseau ou le réseau virtuel.
Si ces étapes ne résolvent pas le problème, utilisez ces commandes Azure CLI pour
nettoyer les ressources.
Vérifier si Azure Active Directory Domain Services est
activé dans le réseau virtuel
Si Active Directory Domain Services est activé et connecté au réseau virtuel, vous ne
pouvez pas supprimer ce dernier.
Pour désactiver le service, consultez la page Désactiver Azure Active Directory Domain
Services à l’aide du Portail Azure.
Vérifier si le réseau virtuel est connecté à d’autres

ressources
Recherchez les liaisons de circuit, les connexions et les peerings de réseaux virtuels. Tous
ces éléments peuvent empêcher la suppression d’un réseau virtuel.
Voici la séquence de suppression recommandée :
1. Connexions de passerelle
2. Passerelles
3. Adresses IP
4. Peerings de réseaux virtuels
5. App Service Environment (ASE)
Vérifier si une machine virtuelle s’exécute toujours dans le

réseau virtuel
Vérifiez qu’aucune machine virtuelle ne s’exécute dans le réseau virtuel.
Vérifier si le réseau virtuel est bloqué en cours de

migration
Si le réseau virtuel est bloqué dans un état de migration, il ne peut pas être supprimé.
Exécutez la commande suivante pour annuler la migration, puis supprimez le réseau
virtuel.
Azure PowerShell
Move-AzureVirtualNetwork -VirtualNetworkName "Name" -Abort
Vérifier si le réseau virtuel a été utilisé par une application

web pour l’intégration VNet
Si le réseau virtuel était auparavant intégré à une application web, celle-ci a été
supprimée sans déconnecter l’intégration VNet ; consultez Supprimer le plan App
Service ou l’application web avant de déconnecter l’intégration VNet .
Étapes suivantes
Résolution des problèmes de
connectivité entre machines virtuelles
Azure
Article • 01/06/2023
Vous pouvez rencontrer des problèmes de connectivité entre machines virtuelles. Cet
article fournit les étapes requises pour vous aider à résoudre ce problème.
Symptôme
Une machine virtuelle Azure ne peut pas se connecter à une autre machine virtuelle
Azure.
Instructions pour la résolution des problèmes

1. Vérifiez si la carte réseau est mal configurée
2. Vérifiez si le trafic réseau est bloqué par un groupe de sécurité réseau ou un
itinéraire défini par l’utilisateur
3. Vérifiez si le trafic réseau est bloqué par un pare-feu de machine virtuelle
4. Vérifiez si une application ou un service de la machine virtuelle écoute sur le port
5. Vérifiez si le problème est causé par SNAT
6. Vérifiez si le trafic est bloqué par des ACL pour la machine virtuelle classique
7. Vérifiez si le point de terminaison est créé pour la machine virtuelle classique
8. Essayez de vous connecter à un partage réseau de machine virtuelle
9. Vérifiez la connectivité entre réseaux virtuels
Étapes de dépannage
Suivez ces étapes pour résoudre le problème. Après chaque étape, vérifiez si le
problème est résolu.
Étape 1 : Vérifier si la carte réseau est mal configurée
Suivez les étapes de Comment réinitialiser l’interface réseau pour une machine virtuelle
Windows Azure.
Si le problème se produit après la modification de l’interface réseau (NIC), procédez

comme suit :
Machines virtuelles avec plusieurs cartes réseau
1. Ajoutez une carte réseau.

2. Corrigez les problèmes dans la carte réseau défectueuse ou supprimez la carte
réseau défectueuse. Ensuite, ajoutez de nouveau la carte réseau.
Pour plus d’informations, consultez Ajouter ou supprimer des cartes réseau de machines
virtuelles.
Machine virtuelle à carte réseau unique
Redéployez la machine virtuelle Windows.

Redéployer la machine virtuelle Linux.
Étape 2 : Vérifiez si le trafic réseau est bloqué par un

groupe de sécurité réseau ou un itinéraire défini par
l’utilisateur
Utilisez la Vérification des flux d’IP de Network Watcher et l’Enregistrement de flux de
groupe de sécurité réseau pour déterminer s’il existe un groupe de sécurité réseau
(NSG) ou un itinéraire défini par l’utilisateur (UDR) qui dérange le flux de trafic.
Étape 3 : Vérifiez si le trafic réseau est bloqué par un

pare-feu de machine virtuelle
Désactivez le pare-feu, puis testez le résultat. Si le problème est résolu, vérifiez les
paramètres du pare-feu, puis réactivez le pare-feu.
Étape 4 : Vérifiez si une application ou un service de la

machine virtuelle écoute sur le port
Vous pouvez utiliser une des méthodes suivantes pour vérifier si une application ou un
service de la machine virtuelle écoute sur le port.
Exécutez les commandes suivantes pour vérifier si le serveur écoute sur ce port.
Machine virtuelle Windows
Console
netstat –ano
Machine virtuelle Linux
Console
netstat -l
Exécutez la commande telnet sur la machine virtuelle elle-même pour tester le

port. Si le test échoue, l’application ou le service n’est pas configuré pour écouter
sur ce port.
Étape 5 : Vérifiez si le problème est causé par SNAT

Dans certains scénarios, la machine virtuelle est placée derrière une solution
d’équilibrage de charge qui a une dépendance sur des ressources en dehors d’Azure.
Dans ces scénarios, si vous rencontrez des problèmes de connexion intermittents, le
problème peut être dû à l’épuisement du port SNAT. Pour résoudre ce problème, créez
une adresse IP virtuelle (ou ILPIP pour la version classique) pour chaque machine
virtuelle qui se trouve derrière l’équilibrage de charge et est sécurisée avec un groupe
de sécurité réseau ou des ACL.
Étape 6 : Vérifiez si le trafic est bloqué par des ACL pour

la machine virtuelle classique
Une liste ACL permet d’autoriser ou refuser le trafic de manière sélective pour un point
de terminaison de machine virtuelle. Pour plus d’informations, consultez la page Gestion
de l’ACL sur un point de terminaison.
Étape 7 : Vérifiez si le point de terminaison est créé pour

la machine virtuelle classique
Toutes les machines virtuelles créées dans Azure à l’aide du modèle de déploiement
classique peuvent automatiquement communiquer sur un canal réseau privé avec
d’autres machines virtuelles dans le même service cloud ou réseau virtuel. Toutefois, les
ordinateurs sur d'autres réseaux virtuels requièrent des points de terminaison pour
diriger le trafic réseau entrant vers une machine virtuelle. Pour plus d’informations,
consultez Configuration de points de terminaison.
Étape 8 : Essayez de vous connecter à un partage réseau

de machine virtuelle
Si vous ne parvenez pas à vous connecter à un partage réseau de machine virtuelle, le
problème peut être causé par des cartes réseau non disponibles sur la machine virtuelle.
Pour supprimer les cartes réseau non disponibles, consultez Supprimer les cartes réseau
non disponibles
Étape 9 : Vérifiez la connectivité entre réseaux virtuels

Utilisez la Vérification des flux d’IP de Network Watcher et l’Enregistrement de flux de
groupe de sécurité réseau pour déterminer s’il existe un groupe de sécurité réseau ou
un itinéraire défini par l’utilisateur qui dérange le flux de trafic. Vous pouvez également
vérifier votre configuration entre réseaux virtuels ici .
Vous avez besoin d’aide ? Contactez le support technique.

Si vous avez besoin d’aide, contactez le support technique pour obtenir une prise en
charge rapide de votre problème.
Configurer des zones de recherche
inversée pour une vérification de
bannière SMTP
Article • 01/06/2023
Cet article décrit comment utiliser une zone de recherche inversée dans Azure DNS et
créer un enregistrement DNS inversé (PTR) pour une vérification de bannière SMTP.
Symptôme
Si vous hébergez un serveur SMTP dans Microsoft Azure, vous pouvez recevoir le
message d’erreur suivant quand vous envoyez ou recevez un message à partir de
serveurs de messagerie distants :
554 : Aucun enregistrement PTR
Solution
Pour une adresse IP virtuelle dans Azure, les enregistrements inversés sont créés dans
des zones de domaine de Microsoft, pas dans des zones de domaine personnalisées.
Pour configurer les enregistrements PTR dans des zones de domaine de Microsoft,
utilisez la propriété -ReverseFqdn sur la ressource PublicIpAddress. Pour plus
d’informations, consultez Configurer des DNS inversés dans les services hébergés par
Azure.
Lorsque vous configurez les enregistrements PTR, assurez-vous que l’adresse IP et le

nom de domaine complet inversé sont détenus par l’abonnement. Si vous essayez de
définir un nom de domaine complet inversé qui n’appartient pas à l’abonnement, le
message d’erreur suivant s’affiche :
Sortie
Set-AzPublicIpAddress : ReverseFqdn mail.contoso.com that PublicIPAddress

ip01 is trying to use does not belong to subscription <Subscription ID>. One
of the following conditions need to be met to establish ownership:
1) ReverseFqdn matches fqdn of any public ip resource under the

subscription;
2) ReverseFqdn resolves to the fqdn (through CName records chain) of any
public ip resource under the subscription;
3) It resolves to the ip address (through CName and A records chain) of a
static public ip resource under the subscription.
Si vous modifiez manuellement votre bannière SMTP pour qu’elle corresponde à notre
nom de domaine complet inversé par défaut, le serveur de messagerie distant peut
toujours échouer, car il peut s’attendre à ce que l’hôte de la bannière SMPT corresponde
à l’enregistrement MX du domaine.
Problèmes d’appliance virtuelle réseau
dans Azure
Article • 11/05/2023
７ Notes

Vous pouvez rencontrer des problèmes de connectivité de machines virtuelles (MV) ou

de réseau privé virtuel (VPN), ainsi que des erreurs lors de l’utilisation d’une appliance
virtuelle réseau (NVA) dans Microsoft Azure. Cet article décrit les étapes élémentaires
pour valider les exigences de plateforme Azure de base pour des configurations
d’appliance virtuelle réseau.
Un support technique pour appliances virtuelles réseau tierces et leur intégration avec la
plateforme Azure est fourni par le fournisseur de l’appliance virtuelle réseau.
７ Notes
Si vous rencontrez un problème de connectivité ou de routage qui implique une

appliance virtuelle réseau, vous devez contactez directement le fournisseur de
l’appliance virtuelle réseau .
Liste de contrôle pour le dépannage avec un

fournisseur d’appliance virtuelle réseau
Mises à jour logicielles pour machine virtuelle d’appliance virtuelle réseau
Fonctionnalités et configuration de compte de service
Itinéraires définis par l’utilisateur sur des sous-réseaux de réseau virtuel qui
dirigent le trafic vers l’appliance virtuelle réseau
Itinéraires définis par l’utilisateur sur des sous-réseaux de réseau virtuel qui
dirigent le trafic à partir de l’appliance virtuelle réseau
Tables et règles de routage au sein de l’appliance virtuelle réseau (par exemple, de
NIC1 à NIC2)
Suivi sur les NIC d’appliance virtuelle réseau pour vérifier la réception et l’envoi de
trafic réseau
Lorsque vous utilisez une référence SKU Standard et des adresses IP publiques,
vous devez disposer d’un groupe de sécurité réseau et d’une règle explicite pour
autoriser le routage du trafic vers l’appliance virtuelle réseau.
Étapes de dépannage de base

Vérifier la configuration de base
Vérifier les performances de l’appliance virtuelle réseau
Dépannage de réseau avancé
Vérifiez la configuration minimale requise pour

les appliances virtuelles réseau sur Azure
Chaque appliance virtuelle réseau a des exigences de configuration de base pour
fonctionner correctement sur Azure. La section suivante décrit les étapes de vérification
de ces configurations de base. Pour plus d’informations, contactez le fournisseur de
l’appliance virtuelle réseau .
Vérifier si le transfert IP est activé sur l’appliance virtuelle réseau
Utiliser le portail Azure
1. Localisez la ressource d’appliance virtuelle réseau sur le portail Azure ,

sélectionnez Mise en réseau, puis sélectionnez l’interface réseau.
2. Sur la page Interface réseau, sélectionnez Configuration IP.
3. Assurez-vous que le transfert IP est activé.
Utiliser PowerShell
1. Ouvrez PowerShell, puis connectez-vous à votre compte Azure.
2. Exécutez la commande suivante (en remplaçant les valeurs entre crochets par vos
informations) :
PowerShell
Get-AzNetworkInterface -ResourceGroupName <ResourceGroupName> -Name

<NicName>
3. Vérifiez la propriété EnableIPForwarding.
4. Si le transfert IP n’est pas activé, exécutez les commandes suivantes pour l’activer :
PowerShell
$nic2 = Get-AzNetworkInterface -ResourceGroupName <ResourceGroupName> -

Name <NicName>
$nic2.EnableIPForwarding = 1
Set-AzNetworkInterface -NetworkInterface $nic2
Execute: $nic2 #and check for an expected output:
EnableIPForwarding : True
NetworkSecurityGroup : null
Vérifiez l’existence d’un groupe de sécurité réseau quand vous utilisez des adresses IP
publiques et une référence SKU Standard Quand vous utilisez une référence SKU
Standard et des adresses IP publiques, il doit y avoir un groupe de sécurité réseau créé
et une règle explicite pour autoriser le trafic vers l’appliance virtuelle réseau.
Vérifier si le trafic peut être routé vers l’appliance virtuelle réseau
1. Sur le portail Azure , ouvrez Network Watcher, puis sélectionnez Tronçon

suivant.
2. Spécifiez une machine virtuelle qui est configurée pour rediriger le trafic vers
l’appliance virtuelle réseau, et une adresse IP de destination à laquelle afficher le
tronçon suivant.
3. Si l’appliance virtuelle réseau n’est pas répertoriée comme tronçon suivant, vérifiez
et mettez à jour les tables de routage Azure.
Vérifier si le trafic peut atteindre l’appliance virtuelle réseau
1. Dans le portail Azure , ouvrez Network Watcher, puis sélectionnez Vérification

du flux IP.
2. Spécifiez la machine virtuelle et l’adresse IP de l’appliance virtuelle réseau, puis
vérifiez si le trafic est bloqué par des groupes de sécurité réseau (NSG).
3. S’il existe une règle de groupe de sécurité réseau qui bloque le trafic, localisez le
groupe de sécurité réseau dans les règles de sécurité efficace, puis mettez-le à
jour pour autoriser le passage du trafic. Réexécutez ensuite la Vérification du flux
IP et utilisez la Résolution des problèmes de connexion pour tester les
communications TCP entre la machine virtuelle et votre adresse IP interne ou
externe.
Vérifier si l’appliance virtuelle réseau et les machines virtuelles écoutent le trafic

attendu
1. Connectez-vous à l’appliance virtuelle réseau en utilisant le protocole RDP ou SSH,

puis exécutez la commande suivante :
Pour Windows :
Console
netstat -an
Pour Linux :
Console
netstat -an | grep -i listen
2. Si vous ne voyez pas le port TCP utilisé par le logiciel de l’appliance virtuelle réseau
répertorié dans les résultats, vous devez configurer l’application sur l’appliance
virtuelle réseau et la machine virtuelle pour écouter le trafic qui atteint ces ports et
y répondre. Contactez le fournisseur de l’appliance virtuelle réseau au besoin .
Vérifier les performances de l’appliance

virtuelle réseau
Valider le processeur de machine virtuelle

Si l’utilisation du processeur approche 100 pour cent, vous risquez de rencontrer des
problèmes affectant les rejets de paquet réseau. Votre machine virtuelle indique
l’utilisation moyenne du processeur pendant intervalle de temps spécifique dans le
portail Azure. Lors d’un pic d’utilisation du processeur, examinez sur la machine virtuelle
invitée le processus à l’origine de l’utilisation élevée du processeur, et atténuez celle-ci
autant que possible. Il se peut que vous deviez également redimensionner la machine
virtuelle en définissant une taille de référence (SKU) supérieure ou, pour un groupe de
machines virtuelles identiques, augmenter le nombre d’instances ou définir une mise à
l’échelle automatique en fonction de l’utilisation du processeur. Pour chacun de ces
problèmes, contactez le fournisseur de l’appliance virtuelle réseau en fonction des
besoins.
Valider les statistiques du réseau de machines virtuelles

Si l’utilisation du réseau de machines virtuelles présente des pics ou des périodes
d’utilisation intense, il se peut également que vous deviez augmenter la taille de la
référence (SKU) de la machine virtuelle pour obtenir des capacités de débit supérieures.
Vous pouvez également redéployer la machine virtuelle en activant la fonctionnalité
Mise en réseau accélérée. Pour vérifier si l’appliance virtuelle réseau prend en charge la
fonctionnalité Mise en réseau accélérée, contactez le fournisseur de l’appliance virtuelle
réseau pour obtenir de l’assistance si nécessaire.
Dépannage d’administrateur réseau avancé
Capturer la trace réseau

Capturez une trace réseau simultanée sur la machine virtuelle source, l’appliance
virtuelle réseau et la machine virtuelle de destination pendant que vous exécutez PsPing
ou Nmap, puis arrêtez la capture de la trace.
1. Pour capturer une trace réseau simultanée, exécutez la commande suivante :
Pour Windows
netsh trace start capture=yes tracefile=c:\server_IP.etl scenario=netconnection
Pour Linux
sudo tcpdump -s0 -i eth0 -X -w vmtrace.cap
2. Utilisez PsPing ou Nmap à partir de la machine virtuelle source vers la machine

virtuelle de destination (par exemple, PsPing 10.0.0.4:80 ou Nmap -p 80
10.0.0.4 ).
3. Ouvrez la trace réseau à partir de la machine virtuelle de destination en utilisant le

Moniteur réseau ou la commande tcpdump. Appliquez un filtre d’affichage pour
l’adresse IP de la machine virtuelle Source à partir de laquelle vous avez exécuté
PsPing ou Nmap, par exemple, IPv4.address==10.0.0.4 (Windows netmon) ou
tcpdump -nn -r vmtrace.cap src or dst host 10.0.0.4 (Linux).
Analyser les traces

Si vous ne voyez pas les paquets entrants dans la trace de machine virtuelle principale, il
est probable qu’un groupe de sécurité réseau ou un itinéraire défini par l’utilisateur
interfère, ou que les tables de routage de l’appliance virtuelle réseau soient incorrectes.
Si vous voyez les paquets entrants, mais pas de réponse, vous devrez peut-être résoudre
un problème lié au pare-feu ou à l’application de la machine virtuelle. Pour chacun de
ces problèmes, contactez au besoin le fournisseur de l’appliance virtuelle réseau .
SMTP sortante dans Azure
Les e-mails sortants envoyés directement à des domaines externes (comme outlook.com
et gmail.com) à partir d’une machine virtuelle ne sont accessibles qu’à certains types
d’abonnements dans Microsoft Azure.
） Important
Pour tous les exemples ci-dessous, le processus s’applique essentiellement aux

ressources de machines virtuelles & de groupes de machines virtuelles identiques
( Microsoft.Compute/virtualMachines & Microsoft.Compute/virtualMachineScaleSets )
. Il est possible d’utiliser le port 25 pour la communication sortante sur Azure App
Service et Azure Functions via la fonctionnalité d’intégration de réseau
virtuel ou lors de l’utilisation d’App Service Environment v3. Toutefois, les
limitations d’abonnement décrites ci-dessous s’appliquent toujours. L’envoi d’e-
mails sur le port 25 n’est pas pris en charge pour les autres ressources PaaS
(Platform-as-a-Service) Azure.
Méthode recommandée de l’envoi d’e-mails

Nous vous recommandons d’utiliser des services de relais SMTP authentifiés pour
envoyer des e-mails à partir de machines virtuelles Azure ou d’Azure App Service. (Ces
services de relais se connectent généralement via le port TCP 587, mais ils prennent en
charge d’autres ports.) Ces services sont utilisés pour maintenir la réputation de
l’adresse IP et du domaine afin de minimiser la possibilité que des domaines externes
rejettent vos messages ou les placent dans le dossier des courriers indésirables.
SendGrid est un service de relais SMTP, mais il en existe d’autres. Vous pouvez
également disposer d’un service de relais SMTP authentifié sur vos serveurs locaux.
L’utilisation de ces services de remise d’e-mails n’est pas limitée dans Azure, quel que
soit le type d’abonnement.
Contrat Entreprise
Pour les machines virtuelles qui sont déployées dans des abonnements Contrat
Entreprise classiques, les connexions SMTP sortantes sur le port TCP 25 ne sont pas
bloquées. Toutefois, il n’y a aucune garantie que les domaines externes accepteront les
e-mails entrants provenant des machines virtuelles. Si vos e-mails sont rejetés ou filtrés
par les domaines externes, vous devez contacter les fournisseurs de services de
messagerie des domaines externes pour résoudre les problèmes. Ces problèmes ne sont
pas couverts par le support Azure.
Pour les abonnements Enterprise Dev/Test, le port 25 est bloqué par défaut. Il est
possible de supprimer ce blocage. Pour demander la suppression du blocage, accédez à
la section Impossible d’envoyer un e-mail (SMTP/Port 25) du panneau Diagnostiquer
et résoudre pour une ressource Réseau virtuel Azure dans le portail Azure et effectuez le
diagnostic. Cela permet d’exempter automatiquement les abonnements qualifiés
Enterprise Dev/Test.
Une fois que l’abonnement est exempté de ce blocage et que les machines virtuelles
sont arrêtées et redémarrées, toutes les machines virtuelles de cet abonnement sont
exemptées. L’exemption s’applique uniquement à l’abonnement demandé et au trafic de
machine virtuelle acheminé directement vers Internet.
Tous les autres types d’abonnements

La plateforme Azure bloque les connexions SMTP sortantes sur le port TCP 25 pour les
machines virtuelles déployées. Cela permet de garantir une meilleure sécurité pour les
partenaires et les clients Microsoft, de protéger la plateforme Azure de Microsoft et de
se conformer aux normes du secteur d’activité.
Si vous utilisez un abonnement de type non-entreprise, nous vous invitons à utiliser un

service de relais SMTP authentifié, comme indiqué plus haut dans cet article.
Modification du type d’abonnement

Si vous remplacez votre type d’abonnement Contrat Entreprise par un autre type
d’abonnement, les modifications apportées à vos déploiements peuvent entraîner le
blocage du trafic SMTP sortant.
Vous avez besoin d’aide ? Contacter le support

technique
Si vous utilisez un abonnement Accord Entreprise et avez encore besoin d’aide,
contactez le support technique pour résoudre vos problèmes rapidement. Utilisez ce
type de problème : Technique>Réseau virtuel>Impossible d’envoyer un e-mail
(SMTP/Port 25) .
 Documentation
DNS inversé pour les services Azure - Azure DNS

Grâce à ce parcours d’apprentissage, commencez à configurer des recherches DNS inversé pour les
services hébergés dans Azure.
Configurer des zones de recherche inversée pour une vérification de bannière SMTP
Décrit comment configurer des zones de recherche inversée pour une vérification de bannière SMTP
dans Azure
Guide de déploiement FortiGate - Microsoft Entra

Configurez et utilisez le produit de pare-feu nouvelle génération Fortinet FortiGate.
Erreurs courantes et problèmes connus lors de la migration vers Azure Cloud Services
(support étendu)
Vue d’ensemble des erreurs courantes lors de la migration de Cloud Services (classique) vers Cloud
Services (support étendu)
Configurer un nom de domaine personnalisé Azure Cloud Services (classique)

Découvrez comment exposer votre application ou vos données Azure sur Internet, sur un domaine
personnalisé, en configurant les paramètres DNS. Ces exemples utilisent le portail Azure.
Gérer des jeux d’enregistrements DNS et des enregistrements avec Azure DNS
Azure DNS permet de gérer les jeux d’enregistrements DNS et les enregistrements lors de
l’hébergement de votre domaine.
Héberger des zones de recherche DNS inversées dans Azure DNS

Découvrez comment utiliser Azure DNS pour héberger les zones de recherche inversées DNS pour
vos plages d’adresses IP
Importer et exporter un fichier de zone de domaine - Azure CLI - Azure DNS

Apprenez à importer et exporter un fichier de zone DNS (Domain Name System) vers Azure DNS à
l’aide d’Azure CLI
Afficher 5 de plus
Quelle est l’adresse IP 168.63.129.16 ?
L’adresse IP 168.63.129.16 est une adresse IP publique virtuelle qui est utilisée pour
établir un canal de communication vers les ressources de la plateforme Azure. Les clients
peuvent définir n’importe quel espace d'adressage pour leur réseau virtuel privé dans
Azure. Par conséquent, les ressources de la plateforme Azure doivent être présentées en
tant qu’adresse IP publique unique. Cette adresse IP publique virtuelle facilite les
opérations suivantes :
Permet à l’agent de machine virtuelle de communiquer avec la plateforme Azure

pour signaler qu’il est dans un état « Prêt ».
Permet la communication avec le serveur virtuel DNS pour fournir une résolution
de nom filtré aux ressources (machine virtuelle, par exemple) qui ne possèdent pas
de serveur DNS personnalisé. Ce filtrage permet de s’assurer que les clients
peuvent résoudre uniquement les noms d’hôte de leurs ressources.
Donne les moyens aux sondes d’intégrité d’Azure Load Balancer de déterminer
l’état d’intégrité des machines virtuelles.
Permet à la machine virtuelle d’obtenir une adresse IP dynamique auprès du

service DHCP dans Azure.
Active les messages de pulsation de l’agent invité pour le rôle PaaS.
７ Notes
Dans un scénario de réseau non virtuel (classique), une adresse IP privée est utilisée
à la place de 168.63.129.16. Cette adresse IP privée est détectée dynamiquement
par le biais du protocole DHCP. Les règles de pare-feu spécifiques à 168.63.129.16
doivent être ajustées en conséquence.
Portée de l’adresse IP 168.63.129.16

L’adresse IP publique 168.63.129.16 est utilisée dans toutes les régions et tous les clouds
nationaux. Microsoft possède cette adresse IP publique spéciale et elle ne change pas.
Nous vous conseillons d’autoriser cette adresse IP dans toutes les stratégies de pare-feu
local (dans la machine virtuelle) dans le sens sortant. La communication est sécurisée
entre cette adresse IP spéciale et les ressources car seule la plateforme Azure interne
peut envoyer un message à partir de cette adresse. Si cette adresse est bloquée, un
comportement inattendu peut se produire dans diverses situations. L’adresse IP
168.63.129.16 est une adresse IP virtuelle du nœud hôte. Les routes définies par
l’utilisateur n’affectent donc pas cette adresse.
L’agent de machine virtuelle a besoin d’une communication sortante avec

WireServer (168.63.129.16) sur les ports 80/tcp et 32526/tcp. Ces ports doivent être
ouverts dans le pare-feu local sur la machine virtuelle. Les groupes de sécurité
réseau configurés n’affectent pas la communication sur ces ports avec l’adresse
168.63.129.16.
La machine virtuelle peut obtenir des services DNS auprès de

l’adresse 168.63.129.16. Si des services DND fournis par 168.63.129.16 ne sont pas
souhaités, le trafic sortant vers 168.63.129.16 sur les ports 168.63.129.16 53/udp et
53/tcp peut être bloqué dans le pare-feu local sur la machine virtuelle.
Par défaut, les groupes de sécurité réseau configurés n’affectent pas la

communication DNS, sauf si elle est ciblée en utilisant la balise de service
AzurePlatformDNS. Pour bloquer le trafic DNS vers Azure DNS via un groupe de
sécurité réseau (NSG), créez une règle de trafic sortant pour refuser le trafic vers
AzurePlatformDNS. Spécifiez « N’importe laquelle » comme « Source », « * »
comme « Plages de ports de destination », « N’importe lequel » comme
protocole et « Refuser » comme action.
Quand la machine virtuelle fait partie d’un pool de back-ends d’équilibreur de

charge, la communication avec la sonde d’intégrité doit être autorisée à partir de
l’adresse 168.63.129.16. La configuration du groupe de sécurité réseau par défaut
inclut une règle qui autorise cette communication. Cette règle utilise la balise de
service AzureLoadBalancer. Si vous le souhaitez, vous pouvez bloquer ce trafic en
configurant le groupe de sécurité réseau. La configuration du bloc entraîne l’échec
des sondes d’intégrité.
７ Notes
Lors de l’exécution des tests suivants, l’action doit être exécutée en tant
qu’Administrateur (Windows) et Racine (Linux) pour garantir des résultats précis.
Système d’exploitation Windows

Vous pouvez tester la communication vers 168.63.129.16 en utilisant les tests suivants
avec PowerShell.
PowerShell
Test-NetConnection -ComputerName 168.63.129.16 -Port 80

Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri
http://168.63.129.16/?comp=versions
Les résultats doivent être retournés comme suit.
PowerShell

ComputerName : 168.63.129.16
RemoteAddress : 168.63.129.16
RemotePort : 80
InterfaceAlias : Ethernet
SourceAddress : 10.0.0.4
TcpTestSucceeded : True
PowerShell

ComputerName : 168.63.129.16
RemoteAddress : 168.63.129.16
RemotePort : 32526
InterfaceAlias : Ethernet
SourceAddress : 10.0.0.4
TcpTestSucceeded : True
PowerShell
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri

http://168.63.129.16/?comp=versions
xml Versions
--- --------
version="1.0" encoding="utf-8" Versions
Vous pouvez également tester la communication vers 168.63.129.16 en utilisant telnet

ou psping .
En cas de réussite, telnet doit se connecter et le fichier créé est vide.
PowerShell
telnet 168.63.129.16 80 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test-
port80.txt
telnet 168.63.129.16 32526 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test--
port32526.txt
PowerShell
Psping 168.63.129.16:80 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test--

port80.txt
Psping 168.63.129.16:32526 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test-
port32526.txt
Système d’exploitation Linux

Sur Linux, vous pouvez tester la communication vers 168.63.129.16 en utilisant les tests
suivants.
Bash
echo "Testing 80 168.63.129.16 Port 80" > 168-63-129-16_test.txt

traceroute -T -p 80 168.63.129.16 >> 168-63-129-16_test.txt
echo "Testing 80 168.63.129.16 Port 32526" >> 168-63-129-16_test.txt
traceroute -T -p 32526 168.63.129.16 >> 168-63-129-16_test.txt
echo "Test 168.63.129.16 Versions" >> 168-63-129-16_test.txt
curl http://168.63.129.16/?comp=versions >> 168-63-129-16_test.txt
Les résultats dans 168-63-129-16_test.txt doivent être retournés comme suit.
Bash
traceroute -T -p 80 168.63.129.16
traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets
1 168.63.129.16 (168.63.129.16) 0.974 ms 1.085 ms 1.078 ms
traceroute -T -p 32526 168.63.129.16

traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets
1 168.63.129.16 (168.63.129.16) 0.883 ms 1.004 ms 1.010 ms
curl http://168.63.129.16/?comp=versions
<?xml version="1.0" encoding="utf-8"?>
<Versions>
<Preferred>
<Version>2015-04-05</Version>
</Preferred>
<Supported>
</Supported>
Étapes suivantes
Groupes de sécurité
Créer, changer ou supprimer un groupe de sécurité réseau

des machines virtuelles Azure
Article • 01/06/2023
Cet article aide les administrateurs à diagnostiquer et résoudre les problèmes de

connectivité qui affectent les machines virtuelles Azure.
Problèmes
Une machine virtuelle Azure déployée à l’aide de Resource Manager ne peut pas
se connecter à une autre machine virtuelle Azure dans le même réseau virtuel.
Une machine virtuelle Azure ne peut pas se connecter à la deuxième carte réseau
d’une machine virtuelle Azure dans le même réseau virtuel.
Une machine virtuelle Azure ne peut pas se connecter à Internet.
Pour résoudre ces problèmes, effectuez les étapes de la section suivante.
Résolution
Une machine virtuelle Azure ne peut pas se connecter à

une autre machine virtuelle Azure dans le même réseau
virtuel
Étape 1 : Vérifiez que les machines virtuelles peuvent communiquer

entre elles.
1. Téléchargez TCping sur votre machine virtuelle source.
2. Ouvrez une fenêtre d’invite de commandes.
3. Accédez au dossier dans lequel vous avez téléchargé TCping.
4. Envoyez une commande ping à la destination à partir de la machine virtuelle

source en utilisant la commande suivante :
tcping64.exe -t <destination VM address> 3389
 Conseil
Si le test ping réussit, passez à l’étape 3. Sinon, passez à l'étape suivante.
Étape 2 : Vérifiez les paramètres du groupe de sécurité réseau.

Pour chaque machine virtuelle, vérifiez les règles de port entrant par défaut (« Autoriser
le trafic entrant du réseau virtuel » et « Autoriser le trafic entrant de l’équilibreur de
charge »). Veillez également à vérifier qu’il n’existe aucune règle bloquante
correspondante répertoriée sous une règle de priorité inférieure.
７ Notes
Les règles qui ont un nombre inférieur sont mises en correspondance d’abord. Par
exemple, si vous avez des règles qui ont les priorités 1000 et 6500, la règle qui a la
priorité 1000 sera mise en correspondance en premier.
Ensuite, essayez d’effectuer un test ping sur la destination à partir de la machine

virtuelle source :
tcping64.exe -t <destination VM address> 3389
Étape 3 : Vérifiez si vous pouvez vous connecter à la machine

virtuelle de destination à l’aide de Bureau à distance ou SSH.
Pour vous connecter à l’aide de Bureau à distance, procédez comme suit.
Windows :
1. Connectez-vous au portail Azure.

2. Dans le menu de gauche, sélectionnez Machines virtuelles.
3. Sélectionnez la machine virtuelle dans la liste.
4. Dans la page de la machine virtuelle, sélectionnez Connecter.
Pour plus d’informations, consultez Connexion à une machine virtuelle Azure exécutant
Windows.
Linux :
Pour plus d’informations, consultez Connexion à une machine virtuelle Linux dans Azure.
Si la connexion Bureau à distance ou SSH réussit, passez à l’étape suivante.
Étape 4 : Effectuez une vérification de la connectivité.

Exécutez une vérification de la connectivité sur la machine virtuelle source, puis vérifiez
la réponse.
Windows : Vérifier la connectivité avec Azure Network Watcher à l’aide de PowerShell
Linux : Vérifier la connectivité avec Azure Network Watcher à l’aide d’Azure CLI 2.0
Voici un exemple de réponse :
ConnectionStatus : Unreachable
AvgLatencyInMs :
MinLatencyInMs :
MaxLatencyInMs :
ProbesSent : 100
ProbesFailed : 100
Hops : [
{
"Type": "Source",
"Id": "c5222ea0-3213-4f85-a642-cee63217c2f3",
"Address": "10.1.1.4",
"ResourceId": "/subscriptions/00000000-0000-0000-
0000-000000000000/resourceGrou
ps/ContosoRG/providers/Microsoft.Network/networkInterfaces/appNic0/ipConfigu
rat
ions/ipconfig1",
"NextHopIds": [
"9283a9f0-cc5e-4239-8f5e-ae0f3c19fbaa"
],
"Issues": []
},
{
"Type": "VirtualAppliance",
"Id": "9283a9f0-cc5e-4239-8f5e-ae0f3c19fbaa",
"Address": "10.1.2.4",
ps/ContosoRG/providers/Microsoft.Network/networkInterfaces/fwNic/ipConfigura
tio
ns/ipconfig1",
"NextHopIds": [
"0f1500cd-c512-4d43-b431-7267e4e67017"
],
"Issues": []
},
Étape 5 : Corrigez le problème dans le résultat de la vérification de

la connectivité.
1. Dans la section Tronçons de la réponse de vérification de la connectivité que vous

avez reçue, vérifiez les problèmes indiqués.
2. Recherchez la résolution correspondante dans le tableau suivant et suivez les
étapes indiquées pour résoudre les problèmes.
Type de problème Valeur Action de résolution
NetworkSecurityRule Nom du Vous pouvez Supprimer la règle de groupe de sécurité

groupe de réseau ou modifier la règle comme décrit ici.
sécurité
réseau
bloquant
UserDefinedRoute Nom de Si vous n’en avez pas besoin, supprimez l’itinéraire

l’itinéraire défini par l’utilisateur. Si vous ne pouvez pas
défini par supprimer l’itinéraire, mettez-le à jour à l’aide du
l’utilisateur préfixe d’adresse approprié et du tronçon suivant.
bloquant Vous pouvez également ajuster l’appliance virtuelle
réseau pour transférer le trafic de manière appropriée.
Pour plus d’informations, consultez : Routage du trafic
de réseau virtuel et Acheminer le trafic réseau avec
une table de routage à l’aide de PowerShell.
Type de problème Valeur Action de résolution
UC Usage Suivez ces recommandations qui décrivent la

Résolution de problèmes de performances génériques
pour une machine virtuelle Azure exécutant Linux ou
Windows .
Mémoire Usage Suivez les recommandations décrites dans Résolution

de problèmes de performances génériques pour une
machine virtuelle Azure exécutant Linux ou
Windows .
Pare-feu invité Nom du Procédez comme suit : Activer ou désactiver le pare-

pare-feu feu Windows Defender .
bloquant
Résolution DNS Nom du Procédez comme suit : Guide de résolution des

DNS problèmes d’Azure DNS et Résolution de noms des
ressources dans les réseaux virtuels Azure.
Erreur de socket Non Le port spécifié est déjà utilisé par une autre
applicable application. Essayez d’utiliser un autre port.
3. Réexécutez la vérification de la connectivité pour déterminer si le problème est

résolu.
La machine virtuelle Azure ne peut pas se connecter à la

deuxième carte réseau d’une machine virtuelle Azure
dans le même réseau virtuel
Étape 1 : Assurez-vous que la deuxième carte réseau est autorisée à

communiquer à l’extérieur du sous-réseau.
Par défaut, les cartes réseau secondaires (également appelées cartes d’interface réseau
ou cartes réseau) ne sont pas configurées pour avoir une passerelle par défaut. Par
conséquent, le flux de trafic sur la carte secondaire sera limité au même sous-réseau.
Si les utilisateurs souhaitent autoriser les cartes réseau secondaires à communiquer en
dehors de leur propre sous-réseau, ils doivent ajouter une entrée à la table de routage
pour configurer la passerelle. Pour cela, procédez comme suit :
1. Sur la machine virtuelle sur laquelle la deuxième carte réseau est configurée,
ouvrez une fenêtre d’invite de commandes en tant qu’administrateur.
2. Exécutez la commande suivante pour ajouter l’entrée dans la table de routage :
Route add 0.0.0.0 mask 0.0.0.0 -p <Gateway IP>
Par exemple, si la deuxième adresse IP est 192.168.0.4, l’adresse IP de la passerelle

doit être 192.168.0.1. Vous devez exécuter la commande suivante :
Route add 0.0.0.0 mask 0.0.0.0 -p 192.168.0.1
3. Exécutez Route Print. Si l’entrée est correctement ajoutée, une entrée semblable à
la suivante s’affiche :
À présent, essayez de vous connecter à la carte réseau secondaire. Si la connexion
échoue, passez à l’étape suivante.
Étape 2 : Vérifiez les paramètres du groupe de sécurité réseau pour

les cartes réseau.
Pour les cartes réseau principale et secondaire, vérifiez les règles de port entrant par
défaut (autoriser le trafic entrant du réseau virtuel, autoriser l’équilibreur de charge)
pour qu’ils acceptent le trafic entrant sur les deux cartes réseau. Vous devez également
vous assurer qu’il n’existe pas de règles bloquantes correspondantes avec une priorité
inférieure.
Étape 3 : Exécutez une vérification de la connectivité à la carte
réseau secondaire.
1. Exécutez une vérification de la connectivité à la carte réseau secondaire.

2. Exécutez une vérification de la connectivité dans l’environnement pour vous
assurer que le processus fonctionne de bout en bout.
Pour plus d’informations sur l’exécution de la vérification de la connectivité, consultez

les articles suivants :
Windows : Vérifier la connectivité avec Azure Network Watcher à l’aide de PowerShell
Linux : Vérifier la connectivité avec Azure Network Watcher à l’aide d’Azure CLI 2.0.
Voici un exemple de réponse :
ConnectionStatus : Unreachable
AvgLatencyInMs :
MinLatencyInMs :
MaxLatencyInMs :
ProbesSent : 100
ProbesFailed : 100
Hops : [
{
"Type": "Source",
"Id": "c5222ea0-3213-4f85-a642-cee63217c2f3",
"Address": "10.1.1.4",
ps/ContosoRG/providers/Microsoft.Network/networkInterfaces/appNic0/ipConfigu
rat
ions/ipconfig1",
"NextHopIds": [
"9283a9f0-cc5e-4239-8f5e-ae0f3c19fbaa"
],
"Issues": []
},
{
"Type": "VirtualAppliance",
"Id": "9283a9f0-cc5e-4239-8f5e-ae0f3c19fbaa",
"Address": "10.1.2.4",
ps/ContosoRG/providers/Microsoft.Network/networkInterfaces/fwNic/ipConfigura
tio
ns/ipconfig1",
"NextHopIds": [
"0f1500cd-c512-4d43-b431-7267e4e67017"
],
"Issues": []
},
Étape 4 : Reportez-vous au tableau de l’étape 5 et suivez ces étapes

pour résoudre les problèmes.
La machine virtuelle Azure ne peut pas se connecter à

Internet
Étape 1 : Vérifiez si la carte réseau est dans un état d’échec.

Pour vérifier l’état de la carte réseau, procédez comme suit :
1. Connectez-vous au portail Explorateur de ressources.
2. Sélectionnez Abonnements dans le volet gauche.
3. Dans le volet gauche, sélectionnez le groupe de ressources auquel la carte réseau

ou la machine virtuelle en question appartient.
4. Accédez à Réseau Microsoft.
5. Sélectionnez l’option Interfaces réseau.
6. Sélectionnez l’interface réseau affectée.
7. Sélectionnez l’option Lecture/écriture en haut du portail.
8. Sélectionnez l’option Modifier.

７ Notes
Une fois que vous avez sélectionné l’option Modifier, l’option « Get » devient
une option Put.
9. Sélectionnez l’interface réseau affectée, puis sélectionnez l’option Put.
７ Notes
Une fois cette sélection effectuée, ProvisioningState s’affiche en tant que

Mise à jour. Le même résultat s’affiche sur le portail Azure Resource Manager
standard. Si l’opération s’est terminée avec succès, la valeur de
ProvisioningState devient Réussi, comme indiqué.
10. Actualisez votre portail. La carte réseau doit être dans un état de réussite.
Étape 2 : Suivez l’étape 4 pour exécuter une vérification de la

connectivité.
Étape 3 : Reportez-vous au tableau de l’étape 5 et suivez les étapes

pour résoudre les problèmes.
Étapes suivantes
Superviser le réseau virtuel Azure
Article • 01/06/2023
Lorsque vous avez des applications critiques et des processus métier basés sur des
ressources Azure, vous voulez superviser ces ressources pour connaître leur
disponibilité, leurs performances et leur fonctionnement.
Cet article décrit les données de supervision générées Réseau virtuel Azure. Le réseau
virtuel Azure utilise Azure Monitor. Si vous n’êtes pas familiarisé avec les fonctionnalités
d’Azure Monitor communes à tous les services Azure qui l’utilisent, consultez
Supervision de ressources Azure avec Azure Monitor.
Données de surveillance
Réseau virtuel Azure collecte les mêmes types de données de supervision que d’autres
ressources Azure, lesquelles sont décrites dans Données de supervision de ressources
Azure.
Pour obtenir des informations détaillées sur les métriques et les journaux de métriques
créés par Réseau virtuel Azure, consultez Informations de référence sur les données de
supervision de Réseau virtuel Azure.
Collecte et routage
Les métriques de plateforme et le journal d’activité sont collectés et stockés
automatiquement, mais ils peuvent être acheminés vers d’autres emplacements à l’aide
d’un paramètre de diagnostic.
Les journaux de ressources ne sont pas collectés ni stockés tant que vous n’avez pas
créé un paramètre de diagnostic et que vous ne les acheminez pas vers un ou plusieurs
emplacements.
Pour plus d’informations sur la création d’un paramètre de diagnostic à l’aide du portail
Azure, de l’interface CLI ou de PowerShell, consultez Créer un paramètre de diagnostic
pour collecter des journaux et métriques de plateforme dans Azure. Lorsque vous créez
un paramètre de diagnostic, vous spécifiez les catégories de journaux à collecter. Les
catégories pour Réseau virtuel Azure sont listées dans Informations de référence sur les
données de supervision de Réseau virtuel Azure.
） Important
L’activation de ces paramètres nécessite des services Azure supplémentaires
(compte de stockage, hub d’événements ou Log Analytics), ce qui peut augmenter
vos coûts. Pour calculer un coût estimé, consultez la rubrique Calculatrice de prix
Azure .
Les métriques et les journaux que vous pouvez collecter sont décrits dans les sections
suivantes.
Analyse des métriques

Azure Monitor ne prend actuellement pas en charge l’analyse des métriques de Réseau
virtuel Azure à partir de Metrics Explorer. Pour afficher les métriques de Réseau virtuel
Azure, sélectionnez Métriques sous Supervision depuis le réseau virtuel que vous voulez
analyser.
Pour obtenir la liste des métriques de plateforme collectées pour Réseau virtuel Azure,
consultez Analyse des métriques de référence de données de Réseau virtuel Azure.
Pour référence, vous pouvez voir une liste de toutes les métriques de ressources prises
en charge dans Azure Monitor.
Analyse des journaux d’activité

Le réseau virtuel Azure ne prend pas en charge les journaux de ressources.
Pour obtenir la liste des types de journaux de ressources collectés pour les ressources
d’un réseau virtuel, consultez Informations de référence sur la surveillance des données
du réseau virtuel
Le journal d’activité est un type de journal de plateforme dans Azure qui fournit des
insights de tous les événements de niveau abonnement. Vous pouvez l’afficher
indépendamment ou le router vers Azure Monitor Logs, où vous pouvez effectuer des
requêtes bien plus complexes à l’aide de Log Analytics.
Alertes
Azure Monitor vous avertit de façon proactive lorsque des conditions significatives sont
détectées dans vos données de surveillance. Elles permettent d’identifier et de résoudre
les problèmes affectant votre système avant que vos clients ne les remarquent. Vous
pouvez définir des alertes sur des métriques, sur des journaux et sur le journal d’activité.
Les différents types d’alertes présentent des avantages et des inconvénients.
Le tableau suivant répertorie les règles d’alerte d’activité courantes et recommandées

pour Réseau virtuel Azure.
Type d’alerte Condition Description
Créer ou Niveau d’événement : Tous sélectionnés, Lorsqu’un utilisateur crée ou

mettre à jour État : Tous sélectionnés, Événement initié apporte des modifications de
un réseau par : Tous les services et utilisateurs configuration au réseau virtuel.
virtuel
Supprimer un Niveau d’événement : Tous sélectionnés, Lorsqu’un utilisateur supprime un

réseau virtuel État : Démarré réseau virtuel.
Étapes suivantes
Pour plus d’informations sur les métriques, les journaux et d’autres valeurs
importantes créées par Réseau virtuel Azure, consultez Surveillance des
informations de référence sur les données de surveillance du réseau virtuel.
Pour plus d’informations sur le monitoring des ressources Azure, voir Monitoring
des ressources Azure avec Azure Monitor.
Migrer un réseau virtuel Azure depuis le
modèle classique vers le modèle
Resource Manager en utilisant Azure
PowerShell
Article • 11/05/2023
Dans cet article, vous allez découvrir comment effectuer une migration depuis le modèle
de déploiement classique vers le nouveau modèle de déploiement Resource Manager.
La migration depuis le modèle classique vers le modèle Resource Manager s’effectue à

raison d’un réseau virtuel à la fois. Il n’existe aucune exigence supplémentaire en
matière d’outils ou de prérequis pour la migration, autres que les exigences liées à
Azure PowerShell. La migration est une migration par plan de contrôle d’une ressource
de réseau virtuel. À aucun moment l’accès aux données n’est interrompu pendant la
migration. Les charges de travail existantes continuent de fonctionner sans perte de
connectivité locale durant cette période. Les adresses IP publiques associées au réseau
virtuel ne changent pas pendant le processus de migration.
Une fois la migration terminée, toutes les opérations de gestion doivent être effectuées
avec le modèle Resource Manager. Les opérations de gestion ne sont accessibles que
via le modèle de déploiement Resource Manager. Les changements de ressources de
sous-réseau ou de réseau virtuel ne sont plus disponibles via l’ancien modèle de
déploiement.
Quand vous migrez le réseau virtuel depuis le modèle classique vers le modèle Resource
Manager, les ressources prise en charge au sein du réseau virtuel sont automatiquement
migrées vers le nouveau modèle.
Prérequis
Compte Azure avec un abonnement actif. Créez-en un gratuitement .
Les étapes et les exemples de cet article utilisent le module Azure PowerShell Az.
Pour installer les modules Az en local sur un ordinateur, voir Installer Azure
PowerShell. Pour plus d’informations sur le module Az, voir Présentation du
nouveau module Azure PowerShell Az. Les cmdlets PowerShell sont fréquemment
mises à jour. Si vous n’exécutez pas leur dernière version, les valeurs spécifiées
dans les instructions peuvent échouer. Pour rechercher les versions installées de
PowerShell sur votre système, utilisez l’applet de commande Get-Module -
ListAvailable Az.
Pour migrer un réseau virtuel à l’aide d’une passerelle d’application, supprimez la
passerelle avant d’exécuter une opération de préparation pour déplacer le réseau.
Après avoir effectué la migration, reconnectez la passerelle dans Azure Resource
Manager.
Vérifiez que vous avez installé les modules Azure PowerShell classique et Az
localement sur votre ordinateur. Pour plus d’informations, consultez Installer et
configurer Azure PowerShell.
Les passerelles Azure ExpressRoute se connectant à des circuits ExpressRoute dans
un autre abonnement ne peuvent pas être migrées automatiquement. Dans ces
cas, supprimez la passerelle ExpressRoute, migrez le réseau virtuel et recréez la
passerelle.
Scénarios pris en charge

Les scénarios suivants sont pris en charge pour une migration depuis le modèle
classique vers le modèle Resource Manager :
Réseaux virtuels classiques contenant des machines virtuelles.
Réseaux virtuels classiques avec un groupe à haute disponibilité par service cloud
au maximum.
Réseaux virtuels classiques contenant des services de domaine Azure AD.
Réseaux virtuels classiques avec une seule passerelle VPN ou un seul circuit Express
Route.
Scénarios non pris en charge

Les scénarios suivants ne sont pas pris en charge pour une migration :
Gestion du cycle de vie d’un réseau virtuel à partir du modèle de déploiement

classique.
Prise en charge du contrôle d’accès en fonction du rôle Azure dans le modèle de

déploiement classique.
Migration d’un réseau virtuel doté d’une passerelle ExpressRoute et d’une

passerelle VPN.
Migration de réseaux virtuels avec plusieurs groupes à haute disponibilité dans un
seul service cloud.
Migration de réseaux virtuels avec un ou plusieurs groupes à haute disponibilité et

des machines virtuelles qui ne se trouvent pas dans un groupe à haute
disponibilité au sein d’un service cloud unique.
Migration d’une passerelle d’application depuis le modèle classique vers le modèle

Resource Manager.
S’inscrire auprès du fournisseur de ressources

Dans cette section, vous allez vous connecter à votre abonnement avec les applets de
commande Resource Manager et inscrire le fournisseur de ressources de migration.
1. Connectez-vous à Azure PowerShell :
Azure PowerShell
Connect-AzAccount
2. Inscrivez le fournisseur de ressources de migration :
Azure PowerShell
Register-AzResourceProvider -ProviderNamespace
Microsoft.ClassicInfrastructureMigrate
Patientez cinq minutes le temps que l’inscription se termine. Vérifiez l’état de

l’inscription avec la commande suivante :
Azure PowerShell
Get-AzResourceProvider -ProviderNamespace
Microsoft.ClassicInfrastructureMigrate
Assurez-vous que RegistrationState est Registered avant de continuer.
７ Notes
L’inscription constitue une étape unique, mais vous devez la faire une fois
avant de tenter la migration. Sans vous inscrire, vous verrez le message
suivant :
BadRequest : L'abonnement n'est pas inscrit pour la migration.
Récupérer le nom du réseau virtuel à migrer

Dans cette section, vous allez vous connecter au modèle de déploiement classique
PowerShell et récupérer le nom du réseau virtuel à migrer.
1. Connectez-vous au déploiement classique PowerShell :
Azure PowerShell
Add-AzureAccount
2. Exécutez la commande suivante pour récupérer le nom du réseau virtuel classique :
Azure PowerShell
Get-AzureVnetSite | Select -Property Name
Notez le nom du réseau virtuel pour la section suivante.
Migrer le réseau virtuel

Dans cette section, vous allez vérifier que la migration peut continuer, puis préparer la
migration.
1. Placez le nom du réseau virtuel que vous avez noté dans la section précédente
dans une variable que les commandes peuvent utiliser. Remplacez myVNet par le
nom du réseau virtuel récupéré dans la section précédente :
Azure PowerShell
$vnetname = "myVNet"
2. Validez la possibilité de migrer le réseau virtuel en exécutant la commande
suivante :
Azure PowerShell
Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName
La commande affiche tout avertissement ou erreur qui bloque la migration. Si la

validation se déroule correctement, vous pouvez passer à l’étape de la préparation
suivante.
７ Notes
Vous obtenez un message d’erreur pour la validation si le réseau virtuel

contient des rôles web/de travail ou des machines virtuelles avec des
configurations non prises en charge.
3. Exécutez la commande suivante pour préparer le réseau virtuel en vue de la

migration :
Azure PowerShell
Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName
Si vous n’êtes pas prêt pour la migration et que vous souhaitez revenir à l’ancien
état, utilisez la commande suivante :
Azure PowerShell
Move-AzureVirtualNetwork -Abort -VirtualNetworkName $vnetName
Valider la migration
Si tout semble bon dans la configuration préparée, vous pouvez valider la migration en
exécutant la commande suivante :
Azure PowerShell
Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName

Étapes suivantes
Pour plus d’informations sur la migration des ressources dans Azure depuis le modèle
classique vers le modèle Resource Manager, consultez :
Vue d’ensemble de la migration prise en charge par la plateforme de ressources

IaaS Classic vers Azure Resource Manager.
Passez en revue les questions fréquemment posées sur la migration des ressources
IaaS de Classic vers Azure Resource Manager.
Planification de la migration des ressources IaaS d’Azure Classic vers Azure
Resource Manager.
Informations de référence sur la
surveillance des données du réseau
virtuel
Article • 01/06/2023
Consultez Surveillance du réseau virtuel Azure pour plus d’informations sur la collecte et
l’analyse des données de surveillance des réseaux virtuels Azure.
Mesures
Cette section répertorie toutes les métriques de plateforme collectées automatiquement
pour le réseau virtuel Azure.
Type de métrique Fournisseur de ressources / espace de noms du type

et lien vers des métriques individuelles
Réseau virtuel Microsoft.Network/virtualNetworks
interface réseau Microsoft.Network/networkInterfaces
Adresse IP publique Microsoft.Network/publicIPAddresses
Passerelles NAT Microsoft.Network/natGateways
Pour plus d’informations, consultez la liste de toutes les métriques de plateforme prises
en charge dans Azure Monitor.
Dimensions de métrique
Pour plus d’informations sur les dimensions de métrique, consultez Métriques
multidimensionnelles.
Le réseau virtuel Azure a les dimensions suivantes associées à ses métriques.
Dimensions de la passerelle NAT
Nom de la dimension Description
Direction (Sortie - Direction du flux de trafic. Les valeurs prises en charge sont Entrée et
Entrée) Sortie.
Nom de la dimension Description
Protocole Type de protocole de transport. Les valeurs prises en charge sont TCP
et UDP.
Journaux d’activité de ressources

Cette section répertorie les types de journaux de ressources que vous pouvez collecter
pour les ressources utilisées avec un réseau virtuel Azure.
Pour référence, consultez la liste de tous les types de catégories de journaux de

ressources pris en charge dans Azure Monitor.
Type de journal de ressources Fournisseur de ressources / espace de noms du type

et lien vers des métriques individuelles
Un groupe de sécurité réseau Microsoft.Network/networksecuritygroups
Adresse IP publique Microsoft.Network/publicIPAddresses
Tables des journaux Azure Monitor

Cette section fait référence à toutes les tables Kusto des journaux d’Azure Monitor
pertinentes pour le réseau virtuel Azure et qui peuvent être interrogées par Log
Analytics.
Type de ressource Notes
Réseau virtuel Microsoft.Network/virtualNetworks
interface réseau Microsoft.Network/networkInterface
Adresse IP publique Microsoft.Network/publicIP
Tables de diagnostic
Réseau virtuel
Le réseau virtuel Azure n’a pas de journaux de diagnostic.
Le tableau suivant répertorie les opérations relatives au réseau virtuel Azure qui peuvent
être créées dans le journal d’activité.
Opération Description
Toutes les opérations Toutes les opérations administratives, dont la création, la mise à jour et
administratives la suppression d’un réseau virtuel Azure.
Créer ou mettre à jour Un réseau virtuel a été créé ou mis à jour.

un réseau virtuel
Supprime un réseau Un réseau virtuel a été supprimé.

virtuel
Pour plus d’informations sur le schéma des entrées du journal d’activité, consultez
Schéma du journal d’activité.
Voir aussi
Pour obtenir une description de la surveillance du réseau virtuel Azure, consultez
Surveillance du réseau virtuel Azure.
Pour plus d’informations sur le monitoring des ressources Azure, voir Monitoring
des ressources Azure avec Azure Monitor.
Commandes de référence Azure CLI
pour Réseau Azure
L’interface de ligne de commande (CLI, command-line interface) Azure est un ensemble

de commandes utilisées pour créer et gérer des ressources Azure. Elle est disponible
dans de nombreux services Azure et vous permet de gérer les services réseau à partir
d’une ligne de commande.
Les commandes Azure CLI pour Réseau Azure se divisent en deux parties : le noyau et
les extensions. Les commandes du noyau d’Azure CLI sont fournies dans le cadre de
l’interface de ligne de commande et sont entièrement prises en charge. Une extension
vous donne accès aux commandes expérimentales et en préversion. Elle est
automatiquement installée la première fois que vous exécutez une référence
d’extension. Pour plus d’informations sur les références d’extension, consultez Utiliser
des extensions avec Azure CLI.
Pour obtenir la liste par ordre alphabétique des références sur les commandes du noyau
et des extensions d’Azure CLI disponibles pour le service Réseau Azure, consultez az
network. Pour obtenir les références de chaque sous-groupe, consultez les tableaux
dans les sections suivantes :
Réseau virtuel
Connectivité WAN et locale
Équilibrage de charge et adresses IP
Sécurité
Monitoring
Liste
７ Notes
Vous êtes invité à installer une référence d’extension lors de la première utilisation.
Vous pouvez également utiliser la commande az extension add pour installer
manuellement une extension.
Références pour les réseaux virtuels

Sous- Informations Utilisation Est une
groupe de référence extension
Appliance az network Gérer l’appliance virtuelle Azure Network.

virtual-
appliance
DNS az network Gérer les domaines DNS privés dans Azure.

private-dns
Point de az network Gérer les stratégies liées aux points de terminaison

terminaison service- de service.
endpoint
NAT az network nat Gérer les ressources de traduction d’adresses réseau.
Carte az network nic Gérer des interfaces réseau.

d’interface
réseau
Carte az network nic Gérer les configurations de point d’accès terminal de Oui
d’interface vtap-config réseau virtuel.
réseau
Peering az peering Gérer le peering. Oui
Profil az network Gérer les profils réseau.

profile
Routage az network Gérer les filtres de routage.

route-filter
Routage az network Gérer les serveurs de routes.

routeserver
Routage az network Gérer les tables de routage.

route-table
VMware az network Commandes pour gérer Azure VMware Solutions. Oui

vmware
Réseau az network Gérer les réseaux virtuels Azure.

virtuel vnet
Réseau az network Gérer les taps de réseau virtuel. Oui

virtuel vnet-tap
Réseau az network Utiliser une passerelle de réseau virtuel Azure pour

virtuel vnet-gateway établir une connectivité entre sites sécurisée.
Références pour les réseaux WAN et la
connectivité locale
Sous- Informations de Utilisation Est une
groupe référence extension
Connexion az network cross- Gérer les ressources Azure Network. Oui

croisée connection
ExpressRoute az network Gérer les connexions de réseau privé dédiées

express-route par fibre optique à Azure.
vHub az network vhub Gérer les hubs virtuels. Oui
VPN az network p2s- Gérer les passerelles VPN point à site. Oui
vpn-gateway
VPN az network vpn- Gérer les connexions VPN.

connection
VPN az network vpn- Gérer les passerelles VPN. Oui

gateway
VPN az network vpn- Gérer les configurations de serveur VPN. Oui

server-config
VPN az network vpn- Gérer les configurations de site VPN. Oui

site
vRouter az network Gérer les routeurs virtuels.

vrouter
vWAN az network vwan Gérer des WAN virtuels. Oui
Références pour l’équilibrage de charge et les

adresses IP
passerelle az network Gérer les services de routage et d’équilibrage de

d’application application- charge au niveau de l’application.
gateway
Front Door az network front- Gérer les ressources Front Door de mise en Oui
door réseau.
IP az network ip- Gérer les ipGroups. Oui

group
IP az network Gérer les adresses IP publiques.

public-ip
Équilibrer la az network cross- Gérer et configurer les équilibreurs de charge

charge region-lb inter-régions.
Équilibrer la az network lb Gérer et configurer les équilibreurs de charge.

charge
Passerelle az network local- Gérer les passerelles locales.

locale gateway
Traffic az network Gérer le routage du trafic entrant.

Manager traffic-manager
Références de sécurité
Sous-groupe Informations de Utilisation Est une
référence extension
ASG az asg Gérer les groupes de sécurité

d’application.
Bastion az network bastion Gérer des hôtes Azure Bastion.
DDoS az network ddos- Gérer les plans de protection

protection DDoS.
Pare-feu az network firewall Gérer et configurer les pare-feu Oui

Azure.
Pare-feu az network security- Gérer les fournisseurs partenaires

partner-provider de sécurité Azure.
Groupe de az network nsg Gérer les groupes de sécurité

sécurité réseau réseau Azure.
Point de az network private- Gérer les points de terminaison

terminaison endpoint privés.
privé
Sous-groupe Informations de Utilisation Est une
référence extension
Point de az network private- Gérer les connexions de point de

terminaison endpoint-connection terminaison privé.
privé
Liaison privée az network private-link- Gérer les ressources de liaison

resource privée.
Liaison privée az network private-link- Gérer les services de liaison

service privée.
Références pour la supervision

Sous- Informations de Utilisation Est une extension
groupe référence
Observateur az network watcher Gérer Azure Network

Watcher.
Références pour les listes

Service az network Lister les alias de service disponibles dans la région qui
list-service- peuvent être utilisés pour les stratégies de point de
aliases terminaison de service.
Service az network Lister toutes les étiquettes de service qui appartiennent à

list-service- des ressources différentes.
tags
Usage az network Lister le nombre de ressources réseau dans une région

list-usages utilisées par rapport à un quota d’abonnement.
Articles Réseau Azure populaires utilisant

Création d'un réseau virtuel
Exemples Azure CLI pour machines virtuelles Windows
Créer un groupe de machines virtuelles identiques
Exécuter Azure IoT Edge sur des machines virtuelles Ubuntu
Équilibrer la charge des machines virtuelles Linux dans Azure
Créer et gérer des réseaux virtuels Azure pour des machines virtuelles Linux
Configurer un point de terminaison de service pour Cosmos DB
Voir aussi
Gérer des machines virtuelles Linux ou Windows avec az vm.
Découvrez les commandes de référence supplémentaires et les extensions
disponibles dans la documentation d’Azure CLI.
Apprendre à utiliser Bash avec Azure CLI
Az.Network
Référence
Cette rubrique affiche des rubriques d’aide pour les applets de commande réseau Azure.
Application Gateway
Add-AzApplicationGatewayAuthenticationCertificate Adds an authentication certificate to an
application gateway.
Add-AzApplicationGatewayBackendAddressPool Adds a back-end address pool to an application

gateway.
Add-AzApplicationGatewayBackendHttpSetting Adds back-end HTTP settings to an application

gateway.
Add-AzApplicationGatewayBackendSetting Adds back-end TCP\TLS settings to an application

gateway.
Add-AzApplicationGatewayCustomError Adds a custom error to an application gateway.
Add-AzApplicationGatewayFrontendIPConfig Adds a front-end IP configuration to an

Add-AzApplicationGatewayFrontendPort Adds a front-end port to an application gateway.
Add-AzApplicationGatewayHttpListener Adds an HTTP listener to an application gateway.
Add-AzApplicationGatewayHttpListenerCustomError Adds a custom error to a http listener of an

Add-AzApplicationGatewayIPConfiguration Adds an IP configuration to an application

gateway.
Add-AzApplicationGatewayListener Adds an listener to an application gateway.
Add-AzApplicationGatewayPrivateLinkConfiguration Adds a private link configuration to an application

gateway.
Add-AzApplicationGatewayProbeConfig Adds a health probe to an Application Gateway.
Add-AzApplicationGatewayRedirectConfiguration Adds a redirect configuration to an Application

Gateway.
Add-AzApplicationGatewayRequestRoutingRule Adds a request routing rule to an application

gateway.
Add-AzApplicationGatewayRewriteRuleSet Adds a rewrite rule set to an application gateway.
Add-AzApplicationGatewayRoutingRule Adds a routing rule to an application gateway.
Add-AzApplicationGatewaySslCertificate Adds an SSL certificate to an application gateway.
Add-AzApplicationGatewaySslProfile Adds SSL profile to an application gateway.
Add-AzApplicationGatewayTrustedClientCertificate Adds a trusted client CA certificate chain to an

Add-AzApplicationGatewayTrustedRootCertificate Adds a trusted root certificate to an application
gateway.
Add-AzApplicationGatewayUrlPathMapConfig Adds an array of URL path mappings to a backend

server pool.
Get-AzApplicationGateway Gets an application gateway.
Get-AzApplicationGatewayAuthenticationCertificate Gets an authentication certificate for an

Get-AzApplicationGatewayAutoscaleConfiguration Gets the Autoscale Configuration of the

Get-AzApplicationGatewayAvailableServerVariableAndHeader Get the supported server variables and available

request and response headers.
Get-AzApplicationGatewayAvailableSslOption Gets all available ssl options for ssl policy for
Get-AzApplicationGatewayAvailableWafRuleSet Gets all available web application firewall rule sets.
Get-AzApplicationGatewayBackendAddressPool Gets a back-end address pool for an application

gateway.
Get-AzApplicationGatewayBackendHealth Gets application gateway backend health.
Get-AzApplicationGatewayBackendHttpSetting Gets the back-end HTTP settings of an application

gateway.
Get-AzApplicationGatewayBackendSetting Gets the back-end TCP\TLS settings of an

Get-AzApplicationGatewayClientAuthConfiguration Gets the client authentication configuration of a

SSL profile object.
Get-AzApplicationGatewayConnectionDraining Gets the connection draining configuration of a

back-end HTTP settings object.
Get-AzApplicationGatewayCustomError Gets custom error(s) from an application gateway.
Get-AzApplicationGatewayFirewallPolicy Gets an application gateway firewall policy.
Get-AzApplicationGatewayFrontendIPConfig Gets the front-end IP configuration of an

Get-AzApplicationGatewayFrontendPort Gets the front-end port of an application gateway.
Get-AzApplicationGatewayHttpListener Gets the HTTP listener of an application gateway.
Get-AzApplicationGatewayHttpListenerCustomError Gets custom error(s) from a http listener of an

Get-AzApplicationGatewayIdentity Get identity assigned to the application gateway.
Get-AzApplicationGatewayIPConfiguration Gets the IP configuration of an application

gateway.
Get-AzApplicationGatewayListener Gets the TCP\TLS listener of an application

gateway.
Get-AzApplicationGatewayPrivateLinkConfiguration Gets the private link configuration of an

Get-AzApplicationGatewayProbeConfig Gets an existing health probe configuration from
an Application Gateway.
Get-AzApplicationGatewayRedirectConfiguration Gets an existing redirect configuration from an

Get-AzApplicationGatewayRequestRoutingRule Gets the request routing rule of an application

gateway.
Get-AzApplicationGatewayRewriteRuleSet Gets the rewrite rule set of an application gateway.
Get-AzApplicationGatewayRoutingRule Gets the routing rule of an application gateway.
Get-AzApplicationGatewaySku Gets the SKU of an application gateway.
Get-AzApplicationGatewaySslCertificate Gets an SSL certificate for an application gateway.
Get-AzApplicationGatewaySslPolicy Gets the SSL policy of an application gateway.
Get-AzApplicationGatewaySslPredefinedPolicy Gets Predefined SSL Policies provided by

Get-AzApplicationGatewaySslProfile Gets the SSL profile of an application gateway.
Get-AzApplicationGatewaySslProfilePolicy Gets the SSL policy of an application gateway SSL

profile.
Get-AzApplicationGatewayTrustedClientCertificate Gets the trusted client CA certificate chain with a

specific name from the Application Gateway.
Get-AzApplicationGatewayTrustedRootCertificate Gets the Trusted Root Certificate with a specific

name from the Application Gateway.
Get-AzApplicationGatewayUrlPathMapConfig Gets an array of URL path mappings to a backend

server pool.
Get-AzApplicationGatewayWafDynamicManifest Gets the web application firewall manifest and all

the supported rule sets.
Get-AzApplicationGatewayWebApplicationFirewallConfiguration Gets the WAF configuration of an application

gateway.
New-AzApplicationGateway Creates an application gateway.
New-AzApplicationGatewayAuthenticationCertificate Creates an authentication certificate for an

New-AzApplicationGatewayAutoscaleConfiguration Creates a Autoscale Configuration for the

New-AzApplicationGatewayBackendAddressPool Creates a back-end address pool for an

New-AzApplicationGatewayBackendHttpSetting Creates back-end HTTP setting for an application

gateway.
New-AzApplicationGatewayBackendSetting Creates back-end TCP\TLS setting for an

New-AzApplicationGatewayClientAuthConfiguration Creates a new client authentication configuration

for SSL profile.
New-AzApplicationGatewayConnectionDraining Creates a new connection draining configuration
for back-end HTTP settings.
New-AzApplicationGatewayCustomError Creates a custom error with http status code and

custom error page url
New-AzApplicationGatewayFirewallCondition Creates a match condition for custom rule
New-AzApplicationGatewayFirewallCustomRule Creates a new custom rule for the application

gateway firewall policy.
New- Creates a new GroupByUserSession for the

AzApplicationGatewayFirewallCustomRuleGroupByUserSession application gateway firewall custom rule.
New-AzApplicationGatewayFirewallCustomRuleGroupByVariable Creates a new GroupByVariable for the application

gateway firewall custom rule GroupByUserSession.
New-AzApplicationGatewayFirewallDisabledRuleGroupConfig Creates a new disabled rule group configuration.
New-AzApplicationGatewayFirewallExclusionConfig Creates a new exclusion rule list for application

gateway waf
New-AzApplicationGatewayFirewallMatchVariable Creates a match variable for firewall condition.
New-AzApplicationGatewayFirewallPolicy Creates a application gateway firewall policy.
New-AzApplicationGatewayFirewallPolicyExclusion Creates an exclusion on the Firewall Policy
New-AzApplicationGatewayFirewallPolicyExclusionManagedRule Creates an exclusionManagedRule entry for

ExclusionManagedRuleGroup entry.
New- Creates ExclusionManagedRuleGroup entry in

AzApplicationGatewayFirewallPolicyExclusionManagedRuleGroup ExclusionManagedRuleSets for the firewall policy
exclusion.
New- Creates an ExclusionManagedRuleSet for the

AzApplicationGatewayFirewallPolicyExclusionManagedRuleSet firewallPolicy exclusion
New- Creates a log scrubbing configuration for firewall

AzApplicationGatewayFirewallPolicyLogScrubbingConfiguration policy
New-AzApplicationGatewayFirewallPolicyLogScrubbingRule Creates a log scrubbing rule for firewall policy
New-AzApplicationGatewayFirewallPolicyManagedRule Create ManagedRules for the firewall policy.
New- Creates RuleGroupOverride entry in

AzApplicationGatewayFirewallPolicyManagedRuleGroupOverride ManagedRuleSets for the firewall policy.
New-AzApplicationGatewayFirewallPolicyManagedRuleOverride Creates a managedRuleOverride entry for

RuleGroupOverrideGroup entry.
New-AzApplicationGatewayFirewallPolicyManagedRuleSet Creates a ManagedRuleSet for the firewallPolicy
New-AzApplicationGatewayFirewallPolicySetting Creates a policy setting for the firewall policy
New-AzApplicationGatewayFrontendIPConfig Creates a front-end IP configuration for an

New-AzApplicationGatewayFrontendPort Creates a front-end port for an application

gateway.
New-AzApplicationGatewayHttpListener Creates an HTTP listener for an application

gateway.
New-AzApplicationGatewayIdentity Creates an identity object for an application
gateway. This will hold reference to the user
assigned identity.
New-AzApplicationGatewayIPConfiguration Creates an IP configuration for an application

gateway.
New-AzApplicationGatewayListener Creates an TCP\TLS listener for an application

gateway.
New-AzApplicationGatewayPathRuleConfig Creates an application gateway path rule.
New-AzApplicationGatewayPrivateLinkConfiguration Creates a private link configuration for an

application gateway
New-AzApplicationGatewayPrivateLinkIpConfiguration Creates an Ip Configuration to be associated with

PrivateLink Configuration
New-AzApplicationGatewayProbeConfig Creates a health probe.
New-AzApplicationGatewayProbeHealthResponseMatch Creates a health probe response match used by

Health Probe for an application gateway.
New-AzApplicationGatewayRedirectConfiguration Creates a redirect configuration for an application

gateway.
New-AzApplicationGatewayRequestRoutingRule Creates a request routing rule for an application

gateway.
New-AzApplicationGatewayRewriteRule Creates a rewrite rule for an application gateway.
New-AzApplicationGatewayRewriteRuleActionSet Creates a rewrite rule action set for an application

gateway.
New-AzApplicationGatewayRewriteRuleCondition Adds a condition to the RewriteRule for an

New-AzApplicationGatewayRewriteRuleHeaderConfiguration Creates a rewrite rule header configuration for an

New-AzApplicationGatewayRewriteRuleSet Creates a rewrite rule set for an application

gateway.
New-AzApplicationGatewayRewriteRuleUrlConfiguration Creates a rewrite rule url configuration for an

New-AzApplicationGatewayRoutingRule Creates a routing rule for an application gateway.
New-AzApplicationGatewaySku Creates a SKU for an application gateway.
New-AzApplicationGatewaySslCertificate Creates an SSL certificate for an Azure application

gateway.
New-AzApplicationGatewaySslPolicy Creates an SSL policy for an application gateway.
New-AzApplicationGatewaySslProfile Creates SSL profile for an application gateway.
New-AzApplicationGatewayTrustedClientCertificate Creates a trusted client CA certificate chain for an

New-AzApplicationGatewayTrustedRootCertificate Creates a Trusted Root Certificate for an

New-AzApplicationGatewayUrlPathMapConfig Creates an array of URL path mappings to a
backend server pool.
New-AzApplicationGatewayWebApplicationFirewallConfiguration Creates a WAF configuration for an application

gateway.
Remove-AzApplicationGateway Removes an application gateway.
Remove-AzApplicationGatewayAuthenticationCertificate Removes an authentication certificate from an

Remove-AzApplicationGatewayAutoscaleConfiguration Removes Autoscale Configuration from an

Remove-AzApplicationGatewayBackendAddressPool Removes a back-end address pool from an

Remove-AzApplicationGatewayBackendHttpSetting Removes back-end HTTP settings from an

Remove-AzApplicationGatewayBackendSetting Removes back-end TCP\TLS settings from an

Remove-AzApplicationGatewayClientAuthConfiguration Removes the client authentication configuration of

a SSL profile object.
Remove-AzApplicationGatewayConnectionDraining Removes the connection draining configuration of

a back-end HTTP settings object.
Remove-AzApplicationGatewayCustomError Removes a custom error from an application

gateway.
Remove-AzApplicationGatewayFirewallPolicy Removes an application gateway firewall policy.
Remove-AzApplicationGatewayFrontendIPConfig Removes a front-end IP configuration from an

Remove-AzApplicationGatewayFrontendPort Removes a front-end port from an application

gateway.
Remove-AzApplicationGatewayHttpListener Removes an HTTP listener from an application

gateway.
Remove-AzApplicationGatewayHttpListenerCustomError Removes a custom error from a http listener of an

Remove-AzApplicationGatewayIdentity Removes a identity from an application gateway.
Remove-AzApplicationGatewayIPConfiguration Removes an IP configuration from an application

gateway.
Remove-AzApplicationGatewayListener Removes a TCP\TLS listener from an application

gateway.
Remove-AzApplicationGatewayPrivateLinkConfiguration Removes a privateLink configuration from an

Remove-AzApplicationGatewayProbeConfig Removes a health probe from an existing

Remove-AzApplicationGatewayRedirectConfiguration Removes a redirect configuration from an existing

Remove-AzApplicationGatewayRequestRoutingRule Removes a request routing rule from an

Remove-AzApplicationGatewayRewriteRuleSet Removes a rewrite rule set from an application

gateway.
Remove-AzApplicationGatewayRoutingRule Removes a routing rule from an application

gateway.
Remove-AzApplicationGatewaySslCertificate Removes an SSL certificate from an Azure

Remove-AzApplicationGatewaySslPolicy Removes an SSL policy from an Azure application

gateway.
Remove-AzApplicationGatewaySslProfile Removes the ssl profile from an application

gateway.
Remove-AzApplicationGatewaySslProfilePolicy Removes an SSL policy from an Azure application

gateway SSL profile.
Remove-AzApplicationGatewayTrustedClientCertificate Removes the trusted client CA certificate chain

object from an application gateway.
Remove-AzApplicationGatewayTrustedRootCertificate Removes a Trusted Root Certificate from an

Remove-AzApplicationGatewayUrlPathMapConfig Removes URL path mappings to a backend server

pool.
Set-AzApplicationGateway Updates an application gateway.
Set-AzApplicationGatewayAuthenticationCertificate Updates an authentication certificate for an

Set-AzApplicationGatewayAutoscaleConfiguration Updates Autoscale Configuration of an application

gateway.
Set-AzApplicationGatewayBackendAddressPool Updates a back-end address pool for an

Set-AzApplicationGatewayBackendHttpSetting Updates back-end HTTP settings for an application

gateway.
Set-AzApplicationGatewayBackendSetting Updates back-end TCP\TLS settings for an

Set-AzApplicationGatewayClientAuthConfiguration Modifies the client auth configuration of a ssl

profile object.
Set-AzApplicationGatewayConnectionDraining Modifies the connection draining configuration of

a back-end HTTP settings object.
Set-AzApplicationGatewayCustomError Updates a custom error in an application gateway.
Set-AzApplicationGatewayFirewallPolicy Updates an application gateway firewall policy.
Set-AzApplicationGatewayFrontendIPConfig Modifies a front-end IP address configuration.
Set-AzApplicationGatewayFrontendPort Modifies a front-end port for an application

gateway.
Set-AzApplicationGatewayHttpListener Modifies an HTTP listener for an application

gateway.
Set-AzApplicationGatewayHttpListenerCustomError Updates a custom error in a http listener of an

Set-AzApplicationGatewayIdentity Updates a identity assigned to the application

gateway.
Set-AzApplicationGatewayIPConfiguration Modifies an IP configuration for an application

gateway.
Set-AzApplicationGatewayListener Modifies a TCP\TLS listener for an application

gateway.
Set-AzApplicationGatewayPrivateLinkConfiguration Modifies an PrivateLink Configuration for an

Set-AzApplicationGatewayProbeConfig Sets the health probe configuration on an existing

Set-AzApplicationGatewayRedirectConfiguration Sets the redirect configuration on an existing

Set-AzApplicationGatewayRequestRoutingRule Modifies a request routing rule for an application

gateway.
Set-AzApplicationGatewayRewriteRuleSet Modifies a rewrite rule set for an application

gateway.
Set-AzApplicationGatewayRoutingRule Modifies a routing rule for an application gateway.
Set-AzApplicationGatewaySku Modifies the SKU of an application gateway.
Set-AzApplicationGatewaySslCertificate Updates an SSL certificate for an application

gateway.
Set-AzApplicationGatewaySslPolicy Modifies the SSL policy of an application gateway.
Set-AzApplicationGatewaySslProfile Updates ssl profile for an application gateway.
Set-AzApplicationGatewaySslProfilePolicy Modifies the SSL policy of an application gateway

SSL profile.
Set-AzApplicationGatewayTrustedClientCertificate Modifies the trusted client CA certificate chain of

an application gateway.
Set-AzApplicationGatewayTrustedRootCertificate Updates a Trusted Root Certificate of an

Set-AzApplicationGatewayUrlPathMapConfig Sets configuration for an array of URL path

mappings to a backend server pool.
Set-AzApplicationGatewayWebApplicationFirewallConfiguration Modifies the WAF configuration of an application

gateway.
Start-AzApplicationGateway Starts an application gateway.
Stop-AzApplicationGateway Stops an application gateway

DNS
Get-AzPrivateDnsZoneGroup Gets private DNS zone group
New-AzFirewallPolicyDnsSetting Creates a new DNS Setting for Azure Firewall Policy
New-AzPrivateDnsZoneConfig Creates DNS zone configuration of the private dns zone group.
New-AzPrivateDnsZoneGroup Creates a private DNS zone group in the specified private endpoint.
Remove-AzPrivateDnsZoneGroup Removes a DNS zone group.
Set-AzPrivateDnsZoneGroup Updates DNS zone group
Test-AzDnsAvailability Checks whether a domain name in the cloudapp.azure.com zone is available

for use.
ExpressRoute
Add-AzExpressRouteCircuitAuthorization Adds an ExpressRoute circuit authorization.
Add-AzExpressRouteCircuitConnectionConfig Adds a circuit connection configuration to Private Peering of

an Express Route Circuit.
Add-AzExpressRouteCircuitPeeringConfig Adds a peering configuration to an ExpressRoute circuit.
Add-AzExpressRouteCrossConnectionPeering Adds a peering configuration to an ExpressRoute cross

connection.
Add-AzExpressRoutePortAuthorization Adds an ExpressRoutePort authorization.
Get-AzExpressRouteCircuit Gets an Azure ExpressRoute circuit from Azure.
Get-AzExpressRouteCircuitARPTable Gets the ARP table from an ExpressRoute circuit.
Get-AzExpressRouteCircuitAuthorization Gets information about ExpressRoute circuit authorizations.
Get-AzExpressRouteCircuitConnectionConfig Gets an ExpressRoute circuit connection configuration

associated with Private Peering of ExpressRouteCircuit.
Get-AzExpressRouteCircuitPeeringConfig Gets an ExpressRoute circuit peering configuration.
Get-AzExpressRouteCircuitRouteTable Gets a route table from an ExpressRoute circuit.
Get-AzExpressRouteCircuitRouteTableSummary Gets a route table summary of an ExpressRoute circuit.
Get-AzExpressRouteCircuitStat Gets usage statistics of an ExpressRoute circuit.
Get-AzExpressRouteConnection Gets a ExpressRoute connection by name or lists all

ExpressRoute connections connected to a
ExpressRouteGateway.
Get-AzExpressRouteCrossConnection Gets an Azure ExpressRoute cross connection from Azure.
Get-AzExpressRouteCrossConnectionArpTable Gets the ARP table from an ExpressRoute cross connection.
Get-AzExpressRouteCrossConnectionPeering Gets an ExpressRoute cross connection peering configuration.
Get-AzExpressRouteCrossConnectionRouteTable Gets a route table from an ExpressRoute cross connection.

Get- Gets a route table summary of an ExpressRoute cross
AzExpressRouteCrossConnectionRouteTableSummary connection.
Get-AzExpressRouteGateway Gets a ExpressRouteGateway resource using

ResourceGroupName and GatewayName OR lists all gateways
by ResourceGroupName or SubscriptionId.
Get-AzExpressRoutePort Gets an Azure ExpressRoutePort resource.
Get-AzExpressRoutePortAuthorization Gets information about ExpressRoutePort authorizations.
Get-AzExpressRoutePortIdentity Get identity assigned to an ExpressRoutePort.
Get-AzExpressRoutePortLinkConfig Gets an ExpressRoutePort link configuration.
Get-AzExpressRoutePortsLocation Gets the locations at which ExpressRoutePort resources are

available.
Get-AzExpressRouteServiceProvider Gets a list ExpressRoute service providers and their attributes.
Move-AzExpressRouteCircuit Moves an ExpressRoute circuit from the classic deployment

model to the Resource Manager deployment model.
New-AzExpressRouteCircuit Creates an Azure express route circuit.
New-AzExpressRouteCircuitAuthorization Creates an ExpressRoute circuit authorization.
New-AzExpressRouteCircuitPeeringConfig Creates a new peering configuration to be added to an

ExpressRoute circuit.
New-AzExpressRouteConnection Creates an ExpressRoute connection that connects an

ExpressRoute gateway to an on premise ExpressRoute circuit
New-AzExpressRouteGateway Creates a Scalable ExpressRoute Gateway.
New-AzExpressRoutePort Creates an Azure ExpressRoutePort.
New-AzExpressRoutePortIdentity Creates an Azure ExpressRoutePortIdentity.
New-AzExpressRoutePortLOA Download letter of authorization document for an express

route port.
Remove-AzExpressRouteCircuit Removes an ExpressRoute circuit.
Remove-AzExpressRouteCircuitAuthorization Removes an existing ExpressRoute configuration authorization.
Remove-AzExpressRouteCircuitConnectionConfig Removes an ExpressRoute circuit connection configuration.
Remove-AzExpressRouteCircuitPeeringConfig Removes an ExpressRoute circuit peering configuration.
Remove-AzExpressRouteConnection Removes a ExpressRouteConnection.
Remove-AzExpressRouteCrossConnectionPeering Removes an ExpressRoute cross connection peering

configuration.
Remove-AzExpressRouteGateway The Remove-AzExpressRouteGateway cmdlet removes an

Azure ExpressRoute gateway. This is a gateway specific to
Azure Virtual WAN's software defined connectivity.
Remove-AzExpressRoutePort Removes an ExpressRoutePort.
Remove-AzExpressRoutePortAuthorization Removes an existing ExpressRoutePort authorization.

Remove-AzExpressRoutePortIdentity Removes a identity from an ExpressRoutePort.
Set-AzExpressRouteCircuit Modifies an ExpressRoute circuit.
Set-AzExpressRouteCircuitConnectionConfig Updates a circuit connection configuration created in Private

Peerings for an Express Route Circuit.
Set-AzExpressRouteCircuitPeeringConfig Saves a modified ExpressRoute peering configuration.
Set-AzExpressRouteConnection Updates an express route connection created between an

express route gateway and on-premise express route circuit
peering.
Set-AzExpressRouteCrossConnection Modifies an ExpressRoute cross connection.
Set-AzExpressRouteGateway Updates a Scalable ExpressRoute Gateway.
Set-AzExpressRoutePort Modifies an ExpressRoutePort.
Set-AzExpressRoutePortIdentity Updates a identity assigned to an ExpressRoutePort.
Load Balancer
Add-AzLoadBalancerBackendAddressPoolConfig Adds a backend address pool configuration to a load
balancer.
Add-AzLoadBalancerFrontendIpConfig Adds a front-end IP configuration to a load balancer.
Add-AzLoadBalancerInboundNatPoolConfig Adds an inbound NAT pool to a load balancer.
Add-AzLoadBalancerInboundNatRuleConfig Adds an inbound NAT rule configuration to a load balancer.
Add-AzLoadBalancerOutboundRuleConfig Adds an outbound rule configuration to a load balancer.
Add-AzLoadBalancerProbeConfig Adds a probe configuration to a load balancer.
Add-AzLoadBalancerRuleConfig Adds a rule configuration to a load balancer.
Get-AzLoadBalancer Gets a load balancer.
Get- Get-
AzLoadBalancerBackendAddressInboundNatRulePortMapping AzLoadBalancerBackendAddressInboundNatRulePortMapping
retrieves inbound nat rule port mapping list for one backend
address.
Get-AzLoadBalancerBackendAddressPool Get-AzLoadBalancerBackendAddressPool retrieves one or

more backend address pools associated with a load balancer.
Get-AzLoadBalancerBackendAddressPoolConfig Gets a backend address pool configuration for a load

balancer.
Get-AzLoadBalancerFrontendIpConfig Gets a front-end IP configuration in a load balancer.
Get-AzLoadBalancerInboundNatPoolConfig Gets one or more inbound NAT pool configurations from a

load balancer.
Get-AzLoadBalancerInboundNatRuleConfig Gets an inbound NAT rule configuration for a load balancer.
Get-AzLoadBalancerOutboundRuleConfig Gets an outbound rule configuration in a load balancer.
Get-AzLoadBalancerProbeConfig Gets a probe configuration for a load balancer.

Get-AzLoadBalancerRuleConfig Gets the rule configuration for a load balancer.
New-AzLoadBalancer Creates a load balancer.
New-AzLoadBalancerBackendAddressConfig Returns a load balancer backend address config.
New-AzLoadBalancerBackendAddressPool Creates a backend address pool on a loadbalancer.
New-AzLoadBalancerBackendAddressPoolConfig Creates a backend address pool configuration for a load

balancer.
New- Creates a tunnel interface in a backend address pool of a load

AzLoadBalancerBackendAddressPoolTunnelInterfaceConfig balancer.
New-AzLoadBalancerFrontendIpConfig Creates a front-end IP configuration for a load balancer.
New-AzLoadBalancerInboundNatPoolConfig Creates an inbound NAT pool configuration for a load

balancer.
New-AzLoadBalancerInboundNatRuleConfig Creates an inbound NAT rule configuration for a load

balancer.
New-AzLoadBalancerOutboundRuleConfig Creates an outbound rule configuration for a load balancer.
New-AzLoadBalancerProbeConfig Creates a probe configuration for a load balancer.
New-AzLoadBalancerRuleConfig Creates a rule configuration for a load balancer.
Remove-AzLoadBalancer Removes a load balancer.
Remove-AzLoadBalancerBackendAddressPool Removes a backend pool from a load balancer
Remove-AzLoadBalancerBackendAddressPoolConfig Removes a backend address pool configuration from a load

balancer.
Remove-AzLoadBalancerFrontendIpConfig Removes a front-end IP configuration from a load balancer.
Remove-AzLoadBalancerInboundNatPoolConfig Removes an inbound NAT pool configuration from a load

balancer.
Remove-AzLoadBalancerInboundNatRuleConfig Removes an inbound NAT rule configuration from a load

balancer.
Remove-AzLoadBalancerOutboundRuleConfig Removes an outbound rule configuration from a load

balancer.
Remove-AzLoadBalancerProbeConfig Removes a probe configuration from a load balancer.
Remove-AzLoadBalancerRuleConfig Removes a rule configuration for a load balancer.
Set-AzLoadBalancer Updates a load balancer.
Set-AzLoadBalancerBackendAddressPool Updates the backend pool on a loadbalancer
Set-AzLoadBalancerFrontendIpConfig Updates a front-end IP configuration for a load balancer.
Set-AzLoadBalancerInboundNatPoolConfig Sets an inbound NAT pool configuration for a load balancer.
Set-AzLoadBalancerInboundNatRuleConfig Sets an inbound NAT rule configuration for a load balancer.
Set-AzLoadBalancerOutboundRuleConfig Sets an outbound rule configuration for a load balancer.
Set-AzLoadBalancerProbeConfig Updates a probe configuration for a load balancer.

Set-AzLoadBalancerRuleConfig Updates a rule configuration for a load balancer.
Network Watcher
Get-AzNetworkWatcher Gets the properties of a Network Watcher
Get-AzNetworkWatcherConnectionMonitor Returns connection monitor with specified

name or the list of connection monitors
Get-AzNetworkWatcherConnectionMonitorReport Query a snapshot of the most recent

connection states.
Get-AzNetworkWatcherFlowLog Gets a flow log resource or a list of flow log

resources in the specified subscription and
region.
Get-AzNetworkWatcherFlowLogStatus Gets the status of flow logging on a resource.
Get-AzNetworkWatcherNextHop Gets the next hop from a VM.
Get-AzNetworkWatcherPacketCapture Gets information and properties and status of a

packet capture resource.
Get-AzNetworkWatcherReachabilityProvidersList Lists all available internet service providers for a

specified Azure region.
Get-AzNetworkWatcherReachabilityReport Gets the relative latency score for internet

service providers from a specified location to
Azure regions.
Get-AzNetworkWatcherSecurityGroupView View the configured and effective network

security group rules applied on a VM.
Get-AzNetworkWatcherTopology Gets a network level view of resources and their

relationships in a resource group.
Get-AzNetworkWatcherTroubleshootingResult Gets the troubleshooting result from the

previously run or currently running
troubleshooting operation.
Invoke-AzNetworkWatcherNetworkConfigurationDiagnostic Invoke network configuration diagnostic session

for specified network profiles on target
resource.
New-AzNetworkWatcher Creates a new Network Watcher resource.
New-AzNetworkWatcherConnectionMonitor Creates a connection monitor resource.
New-AzNetworkWatcherConnectionMonitorEndpointObject Creates connection monitor endpoint.
New- Creates a connection monitor endpoint scope

AzNetworkWatcherConnectionMonitorEndpointScopeItemObject item.
New-AzNetworkWatcherConnectionMonitorObject Create a connection monitor V2 object.
New-AzNetworkWatcherConnectionMonitorOutputObject Create connection monitor output destination

object.
New- Create protocol configuration used to perform

AzNetworkWatcherConnectionMonitorProtocolConfigurationObject test evaluation over TCP, HTTP or ICMP.
New- Create a connection monitor test configuration.

AzNetworkWatcherConnectionMonitorTestConfigurationObject
New-AzNetworkWatcherConnectionMonitorTestGroupObject Create a connection monitor test group.
New-AzNetworkWatcherFlowLog Create or update a flow log resource for the

specified network security group.
New-AzNetworkWatcherNetworkConfigurationDiagnosticProfile Creates a new network configuration diagnostic

profile object. This object is used to restrict the
network configuration during a diagnostic
session using the specified criteria.
New-AzNetworkWatcherPacketCapture Creates a new packet capture resource and

starts a packet capture session on a VM.
New-AzNetworkWatcherPacketCaptureV2 V2 Version of Packet Capture Cmdlet which

creates a new packet capture resource and
starts a packet capture session on a VM, VMSS
or few instances of VMSS.
New-AzNetworkWatcherProtocolConfiguration Creates a new protocol configuration object.
Remove-AzNetworkWatcher Removes a Network Watcher.
Remove-AzNetworkWatcherConnectionMonitor Remove connection monitor.
Remove-AzNetworkWatcherFlowLog Deletes the specified flow log resource.
Remove-AzNetworkWatcherPacketCapture Removes a packet capture resource.
Set-AzNetworkWatcherConfigFlowLog Configures flow logging for a target resource.
Set-AzNetworkWatcherConnectionMonitor Updates connection monitor resource.
Set-AzNetworkWatcherFlowLog Updates flow log resource.
Start-AzNetworkWatcherConnectionMonitor Start a connection monitor
Start-AzNetworkWatcherResourceTroubleshooting Starts troubleshooting on a Networking

resource in Azure.
Stop-AzNetworkWatcherConnectionMonitor Stop a connection monitor
Stop-AzNetworkWatcherPacketCapture Stops a running packet capture session
Test-AzNetworkWatcherConnectivity Returns connectivity information for a specified

source VM and a destination.
Test-AzNetworkWatcherIPFlow Returns whether the packet is allowed or denied

to or from a particular destination.
Mise en réseau
Add-AzDelegation Adds a delegation to a subnet.
Add-AzNetworkInterfaceIpConfig Adds a network interface IP configuration to a network

interface.
Add-AzNetworkInterfaceTapConfig Creates a TapConfiguration resource associated to a
NetworkInterface. This will reference to an existing
VirtualNetworkTap resource.
Add-AzNetworkSecurityRuleConfig Adds a network security rule configuration to a network

security group.
Add-AzRoutingPolicy Add a Routing Policy to the Routing Intent object.
Add-AzServiceEndpointPolicyDefinition Adds a service endpoint policy definition to a specified

policy.
Approve-AzPrivateEndpointConnection Approves a private endpoint connection.
Deny-AzPrivateEndpointConnection denies a private endpoint connection.
Deploy-AzNetworkManagerCommit Deploys a network manager commit.
Get-AzApplicationSecurityGroup Gets an application security group.
Get-AzAutoApprovedPrivateLinkService Gets an array of private link service id that can be linked to a

private end point with auto approved.
Get-AzAvailablePrivateEndpointType Return available private end point types in the location.
Get-AzAvailableServiceAlias Get available service aliases in the region.
Get-AzAvailableServiceDelegation Get available service delegations in the region.
Get-AzBastion Gets a Bastion resource or Bastion resources.
Get-AzBgpServiceCommunity Provides a list of all services / regions, BGP communities, and

associated prefixes.
Get-AzCustomIpPrefix Gets a CustomIpPrefix resource
Get-AzDdosProtectionPlan Gets a DDoS protection plan.
Get-AzDelegation Get a delegation (or all of the delegations) on a given subnet.
Get-AzEffectiveNetworkSecurityGroup Gets the effective network security group of a network

interface.
Get-AzFirewall Gets a Azure Firewall.
Get-AzFirewallFqdnTag Gets the available Azure Firewall Fqdn Tags.
Get-AzFirewallLearnedIpPrefix Gets firewall auto learned ip prefixes.
Get-AzFirewallPolicy Gets a Azure Firewall Policy
Get-AzFirewallPolicyRuleCollectionGroup Gets a Azure Firewall Policy Rule Collection Group
Get-AzIpAllocation Gets a Azure IpAllocation.
Get-AzIpGroup Get an Azure IpGroup
Get-AzLocalNetworkGateway Gets a Local Network Gateway
Get-AzNatGateway Gets a Nat Gateway resource in a resource group by name or

NatGateway Id or all Nat Gateway resources in a resource
group.
Get-AzNetworkInterface Gets a network interface.
Get-AzNetworkInterfaceIpConfig Gets a network interface IP configuration for a network

interface.
Get-AzNetworkInterfaceTapConfig Gets a Tap configuration resource.
Get-AzNetworkManager Gets a network manager in a resource group.
Get- Lists NetworkManager Active Connectivity Configurations in

AzNetworkManagerActiveConnectivityConfiguration network manager.
Get-AzNetworkManagerActiveSecurityAdminRule Lists NetworkManager Active Security Admin Rules in

network manager.
Get-AzNetworkManagerConnectivityConfiguration Gets a connectivity configuration in a network manager.
Get-AzNetworkManagerDeploymentStatus Lists Deployment Status in a network manager.
Get- Lists NetworkManager Effective Connectivity Configurations

AzNetworkManagerEffectiveConnectivityConfiguration applied on a virtual networks.
Get-AzNetworkManagerEffectiveSecurityAdminRule Lists NetworkManager Effective Security Admin Rules applied

on a virtual networks.
Get-AzNetworkManagerGroup Gets network group(s) in a network manager.
Get- Gets a network manager management group connection.

AzNetworkManagerManagementGroupConnection
Get-AzNetworkManagerScopeConnection Gets a scope connection in a network manager.
Get-AzNetworkManagerSecurityAdminConfiguration Gets a network security admin configuration in a network

manager.
Get-AzNetworkManagerSecurityAdminRule Gets a security admin rule in a network manager.
Get-AzNetworkManagerSecurityAdminRuleCollection Gets a security admin rule collection in a network manager.
Get-AzNetworkManagerStaticMember Gets network manager static members.
Get-AzNetworkManagerSubscriptionConnection Gets a network manager subscription connection.
Get-AzNetworkProfile Gets an existing network profile top level resource
Get-AzNetworkSecurityGroup Gets a network security group.
Get-AzNetworkSecurityRuleConfig Get a network security rule configuration for a network

security group.
Get-AzNetworkServiceTag Gets the list of service tag information resources.
Get-AzNetworkUsage Lists network usages for a subscription
Get-AzNetworkVirtualAppliance Get or List Network Virtual Appliances.
Get-AzNetworkVirtualApplianceSku Get or List available Network Virtual Appliance Skus in the

inventory.
Get-AzPrivateEndpoint Get a private endpoint
Get-AzPrivateEndpointConnection Gets a private endpoint connection resource.

Get-AzPrivateLinkResource Gets a private link resource.
Get-AzPrivateLinkService Gets private link service
Get-AzPublicIpAddress Gets a public IP address.
Get-AzPublicIpPrefix Gets a public IP prefix
Get-AzRoutingIntent Retrieves a routing intent resource associated with a

VirtualHub.
Get-AzRoutingPolicy Retrieves a routing policy of a routing intent resource

associated with a VirtualHub.
Get-AzSecurityPartnerProvider Get an Azure SecurityPartnerProvider
Get-AzServiceEndpointPolicy Gets a service endpoint policy.
Get-AzServiceEndpointPolicyDefinition Gets a service endpoint policy definition.
Get-AzVirtualApplianceSite Get or List sites connected to Network Virtual Appliance

resource(s).
Get-AzVirtualHub Gets an Azure VirtualHub by Name and ResourceGroupName

or lists all Virtual Hubs by ResourceGroupName/Subscription.
Get-AzVirtualHubBgpConnection The Get-AzVirtualHubBgpConnection cmdlet gets a Virtual

WAN Hub BGP Connection in a Virtual WAN Hub or lists all
Virtual WAN Hub BGP Connections in a Virtual WAN Hub.
Get-AzVirtualHubVnetConnection Gets a Virtual Network Connection in a virtual hub or lists all

virtual network connections in a virtual hub.
Get-AzVirtualWan Gets a Virtual WAN or all Virtual WANs in a resource group

or subscription.
New-AzApplicationSecurityGroup Creates an application security group.
New-AzBastion Creates a bastion resource.
New-AzContainerNicConfig Creates a new container network interface configuration

object.
New-AzContainerNicConfigIpConfig Creates a container nic configuration ip configuration object.
New-AzCustomIpPrefix Creates a CustomIpPrefix resource
New-AzDdosProtectionPlan Creates a DDoS protection plan.
New-AzDelegation Creates a service delegation.
New-AzFirewall Creates a new Firewall in a resource group.
New-AzFirewallApplicationRule Creates a Firewall Application Rule.
New-AzFirewallApplicationRuleCollection Creates a collection of Firewall application rules.
New-AzFirewallHubIpAddress Ip addresses assoicated to the firewall on virtual hub
New-AzFirewallHubPublicIpAddress Public Ip assoicated to the firewall on virtual hub
New-AzFirewallNatRule Creates a Firewall NAT Rule.

New-AzFirewallNatRuleCollection Creates a collection of Firewall NAT rules.
New-AzFirewallNetworkRule Creates a Firewall Network Rule.
New-AzFirewallNetworkRuleCollection Creates a Azure Firewall Network Collection of Network rules.
New-AzFirewallPolicy Creates a new Azure Firewall Policy
New-AzFirewallPolicyApplicationRule Create a new Azure Firewall Policy Application Rule
New- Create a new Azure Firewall Policy Application Rule Custon

AzFirewallPolicyApplicationRuleCustomHttpHeader HTTP Header
New-AzFirewallPolicyExplicitProxy Creates a new Explicit Proxy
New-AzFirewallPolicyFilterRuleCollection Create a new Azure Firewall Policy Filter Rule Collection
New-AzFirewallPolicyIntrusionDetection Creates a new Azure Firewall Policy Intrusion Detection to

associate with Firewall Policy
New-AzFirewallPolicyIntrusionDetectionBypassTraffic Creates a new Azure Firewall Policy Intrusion Detection

Bypass Traffic Setting
New- Creates a new Azure Firewall Policy Intrusion Detection

AzFirewallPolicyIntrusionDetectionSignatureOverride Signature Override
New-AzFirewallPolicyNatRule Create a new Azure Firewall Policy NAT Rule
New-AzFirewallPolicyNatRuleCollection Create a new Azure Firewall Policy Nat Rule Collection
New-AzFirewallPolicyNetworkRule Create a new Azure Firewall Policy Network Rule
New-AzFirewallPolicyRuleCollectionGroup Create a new Azure Firewall Policy Rule Collection Group
New-AzFirewallPolicySnat Creates SNAT configuration of PrivateRange and

AutoLearnPrivateRanges for the firewall policy
New-AzFirewallPolicySqlSetting Creates a new SQL Setting for Azure Firewall Policy
New-AzFirewallPolicyThreatIntelWhitelist Create a new threat intelligence whitelist for Azure Firewall

Policy
New-AzFirewallPublicIpAddress This is the placeholder for the Ip Address that can be used
for multi pip on azure firewall.
New-AzFirewallThreatIntelWhitelist Create a new threat intelligence whitelist for Azure Firewall
New-AzGatewayCustomBgpIpConfigurationObject creates a new GatewayCustomBgpIpConfigurationObject.
New-AzIpAllocation Creates an Azure IpAllocation.
New-AzIpConfigurationBgpPeeringAddressObject creates a new IpconfigurationBgpPeeringAddressObject
New-AzIpGroup Creates an Azure IpGroup.
New-AzIpsecPolicy Creates an IPSec Policy.
New-AzIpsecTrafficSelectorPolicy Creates a traffic selector policy.
New-AzLocalNetworkGateway Creates a Local Network Gateway
New-AzNatGateway Create new Nat Gateway resource with properties Public Ip

Address/Public Ip Prefix, IdleTimeoutInMinutes and Sku.
New-AzNetworkInterface Creates a network interface.
New-AzNetworkInterfaceIpConfig Creates a network interface IP configuration.
New-AzNetworkManager Creates a network manager.
New-AzNetworkManagerAddressPrefixItem Creates a network manager address prefix item.
New-AzNetworkManagerConnectivityConfiguration Creates a network manager connectivity configuration.
New-AzNetworkManagerConnectivityGroupItem Creates a connectivity group item.
New-AzNetworkManagerGroup Creates a network manager group.
New-AzNetworkManagerHub Creates a network manager hub.
New- Creates a network manager management group connection.

New-AzNetworkManagerScope Creates a network manager scope.
New-AzNetworkManagerScopeConnection Creates a scope connection.
New-AzNetworkManagerSecurityAdminConfiguration Creates a security admin configuration.
New-AzNetworkManagerSecurityAdminRule Creates a security admin rule.
New-AzNetworkManagerSecurityAdminRuleCollection Creates a security admin rule collection.
New-AzNetworkManagerSecurityGroupItem Creates a security group item.
New-AzNetworkManagerStaticMember Creates a network manager static member.
New-AzNetworkManagerSubscriptionConnection Creates a network manager subscription connection.
New-AzNetworkProfile Creates a new network profile.
New-AzNetworkSecurityGroup Creates a network security group.
New-AzNetworkSecurityRuleConfig Creates a network security rule configuration.
New-AzNetworkVirtualAppliance Create a Network Virtual Appliance resource.
New-AzO365PolicyProperty Create an office 365 traffic breakout policy object.
New-AzOffice365PolicyProperty Define a new Office 365 traffic breakout policy to be used

with a Virtual Appliance site.
New-AzPacketCaptureFilterConfig Creates a new packet capture filter object.
New-AzPacketCaptureScopeConfig Creates a new packet capture scope object.
New-AzPrivateEndpoint Creates a private endpoint.
New-AzPrivateEndpointIpConfiguration Creates an IpConfiguration object for private endpoint.
New-AzPrivateLinkService Creates a private link service
New-AzPrivateLinkServiceConnection Creates a private link service connection configuration.
New-AzPrivateLinkServiceIpConfig Create a private link service ip configuration.
New-AzPublicIpAddress Creates a public IP address.

New-AzPublicIpPrefix Creates a Public IP Prefix
New-AzPublicIpTag Creates an IP Tag.
New-AzRadiusServer Creates an external radius server configuration
New-AzRoutingConfiguration Creates a RoutingConfiguration object.
New-AzRoutingIntent Creates a routing intent resource associated with a

VirtualHub.
New-AzRoutingPolicy Returns an in-memory routing policy object.
New-AzSecurityPartnerProvider Creates an Azure SecurityPartnerProvider.
New-AzServiceEndpointPolicy Creates a service endpoint policy.
New-AzServiceEndpointPolicyDefinition Creates a service endpoint policy definition.
New-AzVirtualApplianceAdditionalNicProperty Define a Network Virtual Appliance Additional Nic Property

for the resource.
New-AzVirtualApplianceSite Create a site connected to a Network Virtual Appliance.
New-AzVirtualApplianceSkuProperty Define a Network Virtual Appliance sku for the resource.
New-AzVirtualHub Creates an Azure VirtualHub resource.
New-AzVirtualHubBgpConnection The New-AzVirtualHubBgpConnection cmdlet creates a

HubBgpConnection resource that peers the Azure Virtual
WAN Hub Router with a BGP-enabled peer in a virtual
network connected to the Virtual WAN Hub.
New-AzVirtualHubVnetConnection The New-AzVirtualHubVnetConnection cmdlet creates a

HubVirtualNetworkConnection resource that peers a Virtual
Network to the Azure Virtual Hub.
New-AzVirtualWan Creates an Azure Virtual WAN.
Remove-AzApplicationSecurityGroup Removes an application security group.
Remove-AzBastion Removes a bastion resource.
Remove-AzCustomIpPrefix Removes a CustomIpPrefix
Remove-AzDdosProtectionPlan Removes a DDoS protection plan.
Remove-AzDelegation Removes a service delegation from the provided subnet.
Remove-AzFirewall Remove a Firewall.
Remove-AzFirewallPolicy Removes an Azure Firewall Policy
Remove-AzFirewallPolicyRuleCollectionGroup Removes a Azure Firewall Policy Rule Collection Group in a

Azure firewall policy
Remove-AzIpAllocation Deletes an Azure IpAllocation.
Remove-AzIpGroup Deletes an Azure IpGroup.
Remove-AzLocalNetworkGateway Deletes a Local Network Gateway
Remove-AzNatGateway Remove Nat Gateway resource.

Remove-AzNetworkInterface Removes a network interface.
Remove-AzNetworkInterfaceIpConfig Removes a network interface IP configuration from a network

interface.
Remove-AzNetworkInterfaceTapConfig Removes a tap configuration from given network interface
Remove-AzNetworkManager Removes a network manager.
Remove- Removes a connectivity configuration.

AzNetworkManagerConnectivityConfiguration
Remove-AzNetworkManagerGroup Removes a network Group.
Remove- Removes a network manager management group

AzNetworkManagerManagementGroupConnection connection.
Remove-AzNetworkManagerScopeConnection Removes a network manager scope connection.
Remove- Removes a security admin configuration.

AzNetworkManagerSecurityAdminConfiguration
Remove-AzNetworkManagerSecurityAdminRule Removes a security admin rule.
Remove- Removes a security admin rule collection.

AzNetworkManagerSecurityAdminRuleCollection
Remove-AzNetworkManagerStaticMember Removes a network manager static member.
Remove-AzNetworkManagerSubscriptionConnection Remove a network manager subscription connection.
Remove-AzNetworkProfile Removes a network profile.
Remove-AzNetworkSecurityGroup Removes a network security group.
Remove-AzNetworkSecurityRuleConfig Removes a network security rule from a network security

group.
Remove-AzNetworkVirtualAppliance Remove a Network Virtual Appliance resource.
Remove-AzPrivateEndpoint Removes a private endpoint.
Remove-AzPrivateEndpointConnection Removes a private endpoint connection.
Remove-AzPrivateLinkService Removes a private link service
Remove-AzPublicIpAddress Removes a public IP address.
Remove-AzPublicIpPrefix Removes a public IP prefix
Remove-AzRoutingIntent Delete a routing intent resource associated with a

VirtualHub.
Remove-AzRoutingPolicy Removes the specified routing policy from a routing intent

resource associated with a VirtualHub.
Remove-AzSecurityPartnerProvider Deletes an Azure SecurityPartnerProvider.
Remove-AzServiceEndpointPolicy Removes a service endpoint policy.
Remove-AzServiceEndpointPolicyDefinition Removes a service endpoint policy definition.
Remove-AzVirtualApplianceSite Remove a virtual appliance site from a Network Virtual

Appliance resource.
Remove-AzVirtualHub Removes an Azure VirtualHub resource.
Remove-AzVirtualHubBgpConnection The Remove-AzVirtualHubBgpConnection cmdlet removes a

HubBgpConnection resource that peers the Azure Virtual
WAN Hub Router with a BGP-enabled peer in a virtual
network connected to the Virtual WAN Hub.
Remove-AzVirtualHubVnetConnection The Remove-AzVirtualHubVnetConnection cmdlet removes

an Azure Virtual Network Connection which peers a remote
VNET to the hub VNET.
Remove-AzVirtualWan Removes an Azure Virtual WAN.
Set-AzBastion Updates the Bastion Resource.
Set-AzFirewall Saves a modified Firewall.
Set-AzFirewallPolicy Saves a modified azure firewall policy
Set-AzFirewallPolicyRuleCollectionGroup saves a modified azure firewall policy rule collection group
Set-AzIpAllocation Saves a modified IpAllocation.
Set-AzIpGroup Saves a modified Firewall.
Set-AzLocalNetworkGateway Modifies a local network gateway.
Set-AzNatGateway Update Nat Gateway Resource with Public Ip Address, Public

Ip Prefix and IdleTimeoutInMinutes.
Set-AzNetworkInterface Updates a network interface.
Set-AzNetworkInterfaceIpConfig Updates an IP configuration for a network interface.
Set-AzNetworkInterfaceTapConfig Updates a tap configuration for a network interface.
Set-AzNetworkManager Updates a network manager..
Set-AzNetworkManagerConnectivityConfiguration Updates a connectivity configuration.
Set-AzNetworkManagerGroup Updates a network manager group.
Set- Update a network manger management group connection

Set-AzNetworkManagerScopeConnection Update a network manager scope connection.
Set-AzNetworkManagerSecurityAdminConfiguration Updates a network manager security admin configuration.
Set-AzNetworkManagerSecurityAdminRule Updates a network manager security admin rule.
Set-AzNetworkManagerSecurityAdminRuleCollection Updates a network manager security admin rule collection.
Set-AzNetworkManagerSubscriptionConnection Update a network manager subscription connection.
Set-AzNetworkProfile Updates a network profile.
Set-AzNetworkSecurityGroup Updates a network security group.
Set-AzNetworkSecurityRuleConfig Updates a network security rule configuration for a network

security group.
Set-AzPrivateEndpoint Updates a private endpoint.
Set-AzPrivateEndpointConnection Updates a private endpoint connection state on private link

service.
Set-AzPrivateLinkService Updates a private link service.
Set-AzPublicIpAddress Updates a public IP address.
Set-AzPublicIpPrefix Sets the Tags for an existing PublicIpPrefix
Set-AzRoutingIntent Updates a routing intent resource associated with a

VirtualHub.
Set-AzRoutingPolicy Updates the destinations or nexthop for the specified

Routing Policy of a Routing Intent object.
Set-AzSecurityPartnerProvider Saves a modified Azure SecurityPartnerProvider.
Set-AzServiceEndpointPolicy Updates a service endpoint policy.
Set-AzServiceEndpointPolicyDefinition Updates a service endpoint policy definition.
Set-AzVirtualHub Modifies a Virtual Hub to add a Virtual HUb Route Table to it.
Start-AzVirtualnetworkGatewayPacketCapture Starts Packet Capture Operation on a Virtual Network

Gateway.
Test-AzPrivateIPAddressAvailability Test availability of a private IP address in a virtual network.
Test-AzPrivateLinkServiceVisibility The Test-AzPrivateLinkServiceVisibility checks whether a

private link service is visible for current use.
Update-AzCustomIpPrefix Updates a CustomIpPrefix
Update-AzNetworkVirtualAppliance Update or Change a Network Virtual Appliance resource.
Update-AzVirtualApplianceSite Change or Modify a Virtual Appliance site connected to a

Network Virtual Appliance resource.
Update-AzVirtualHub Updates a virtual hub.
Update-AzVirtualHubBgpConnection The Update-AzVirtualHubBgpConnection cmdlet updates an

existing HubBgpConnection resource (Virtual WAN Hub BGP
Connection).
Update-AzVirtualHubVnetConnection Updates an existing HubVirtualNetworkConnection.
Update-AzVirtualWan Updates an Azure Virtual WAN.
Routage
Add-AzRouteConfig Adds a route to a route table.
Add-AzRouteFilterRuleConfig Adds a route filter rule to a route filter.
Add-AzRouteServerPeer Add a peer to an Azure RouteServer
Add-AzVirtualHubRoute Creates a VirtualHubRoute object which can be passed as parameter to the

Add-AzVirtualHubRouteTable command.
Add-AzVirtualHubRouteTable Creates a Virtual Hub Route Table resource which is a child of VirtualHub.
Add-AzVirtualRouterPeer Add a Peer to an Azure VirtualRouter
Get-AzEffectiveRouteTable Gets the effective route table of a network interface.
Get-AzRouteConfig Gets routes from a route table.
Get-AzRouteFilter Gets a route filter.
Get-AzRouteFilterRuleConfig Gets a route filter rule in a route filter.
Get-AzRouteMap Retrieves a route map of a VirtualHub.
Get-AzRouteServer Get an Azure RouteServer
Get-AzRouteServerPeer Gets a RouteServer peer in an Azure RouteServer
Get- List routes being advertised by specific route server peer

AzRouteServerPeerAdvertisedRoute
Get-AzRouteServerPeerLearnedRoute List routes learned by a specific route server peer
Get-AzRouteTable Gets route tables.
Get-AzVHubEffectiveRoute Retrieves the effective routes of a virtual hub resource
Get-AzVHubInboundRoute Retrieves the inbound routes of a virtual hub connection
Get-AzVHubOutboundRoute Retrieves the outbound routes of a virtual hub connection
Get-AzVHubRouteTable Retrieves a hub route table resource associated with a VirtualHub.
Get-AzVirtualHubRouteTable Gets a Virtual Hub Route Table in a virtual hub or lists all route tables in a
virtual hub. The cmdlet Get-AzVHubRouteTable is replacing this cmdlet.
Get-AzVirtualRouter Get an Azure VirtualRouter
Get-AzVirtualRouterPeer Gets a VirtualRouter peer in an Azure VirtualRouter
Get- List routes being advertised by specific virtual router peer

AzVirtualRouterPeerAdvertisedRoute
Get-AzVirtualRouterPeerLearnedRoute List routes learned by a specific virtual router peer
New-AzRouteConfig Creates a route for a route table.
New-AzRouteFilter Creates a route filter.
New-AzRouteFilterRuleConfig Creates a route filter rule for a route filter.
New-AzRouteMap Create a route map to a VirtualHub.
New-AzRouteMapRule Create a route map rule.
New-AzRouteMapRuleAction Create a route map rule action.
New-AzRouteMapRuleActionParameter Create a route map rule action parameter for the rule action.
New-AzRouteMapRuleCriterion Create a route map rule criterion.
New-AzRouteServer Creates an Azure RouteServer.
New-AzRouteTable Creates a route table.

New-AzStaticRoute Creates a StaticRoute object which can then be added to a
RoutingConfiguration object.
New-AzVHubRoute Creates a VHubRoute object which can be passed as parameter to the New-
AzVHubRouteTable command.
New-AzVHubRouteTable Creates a hub route table resource associated with a VirtualHub.
New-AzVirtualHubRoute Creates an Azure Virtual Hub Route object.
New-AzVirtualHubRouteTable Creates an Azure Virtual Hub Route Table object.
New-AzVirtualRouter Creates an Azure VirtualRouter.
New- Create a VirtualRouterAutoScaleConfiguration object for a Virtual Hub.

AzVirtualRouterAutoScaleConfiguration
Remove-AzRouteConfig Removes a route from a route table.
Remove-AzRouteFilter Removes a route filter.
Remove-AzRouteFilterRuleConfig Removes a route filter rule from a route filter.
Remove-AzRouteMap Remove a route map from a VirtualHub.
Remove-AzRouteServer Deletes an Azure RouteServer.
Remove-AzRouteServerPeer Removes a Peer from an Azure RouteServer
Remove-AzRouteTable Removes a route table.
Remove-AzVHubRouteTable Delete a hub route table resource associated with a VirtualHub.
Remove-AzVirtualHubRouteTable Delete a virtual hub route table resource associated with a virtual hub.
Remove-AzVirtualRouter Deletes an Azure VirtualRouter.
Remove-AzVirtualRouterPeer Removes a Peer from an Azure VirtualRouter
Reset-AzHubRouter Resets the RoutingState of a VirtualHub resource.
Set-AzRouteConfig Updates a route configuration for a route table.
Set-AzRouteFilter Updates a route filter.
Set-AzRouteFilterRuleConfig Modifies the route filter rule of a route filter.
Set-AzRouteTable Updates a route table.
Update-AzRouteMap Update a route map of a VirtualHub.
Update-AzRouteServer Update an Azure RouteServer.
Update-AzRouteServerPeer Update a Peer in an Azure RouteServer
Update-AzVHubRouteTable Delete a hub route table resource associated with a VirtualHub.
Update-AzVirtualRouter Updates a Virtual Router.
Update-AzVirtualRouterPeer Update a Peer in an Azure VirtualRouter

Réseau virtuel
Add-AzVirtualNetworkGatewayIpConfig Adds an IP configuration to a virtual network gateway.
Add-AzVirtualNetworkPeering Creates a peering between two virtual networks.
Add-AzVirtualNetworkSubnetConfig Adds a subnet configuration to a virtual network.
Disconnect-AzVirtualNetworkGatewayVpnConnection Disconnect given connected vpn client connections

with a given virtual network gateway.
Get-AzVirtualNetwork Gets a virtual network in a resource group.
Get-AzVirtualNetworkAvailableEndpointService Lists available endpoint services for location.
Get-AzVirtualNetworkGateway Gets a Virtual Network Gateway
Get-AzVirtualNetworkGatewayAdvertisedRoute Lists routes being advertised by an Azure virtual

network gateway
Get-AzVirtualNetworkGatewayBGPPeerStatus Lists an Azure virtual network gateway's BGP peers
Get-AzVirtualNetworkGatewayConnection Gets a Virtual Network Gateway Connection
Get-AzVirtualNetworkGatewayConnectionIkeSa Get IKE Security Associations of a Virtual Network

Gateway Connection
Get-AzVirtualNetworkGatewayConnectionSharedKey Displays the shared key used for the connection.
Get- This commandlet takes the connection resource, VPN

AzVirtualNetworkGatewayConnectionVpnDeviceConfigScript device brand, model, firmware version, and return the
corresponding configuration script that customers can
apply directly on their on-premises VPN devices. The
script will follow the syntax of the selected device, and
fill in the necessary parameters such as Azure gateway
public IP addresses, virtual network address prefixes,
VPN tunnel pre-shared key, etc. so customers can
simply copy-paste to their VPN device configurations.
Get-AzVirtualNetworkGatewayLearnedRoute Lists routes learned by an Azure virtual network

gateway
Get-AzVirtualNetworkGatewayNatRule Gets a Virtual Network Gateway NatRule.
Get-AzVirtualNetworkGatewaySupportedVpnDevice This commandlet returns a list of supported VPN

device brands, models, and firmware versions.
Get-AzVirtualNetworkGatewayVpnClientConnectionHealth Get the list of vpn client connection health of an Azure

virtual network gateway for per vpn client connection
Get-AzVirtualNetworkPeering Gets the virtual network peering.
Get-AzVirtualNetworkSubnetConfig Gets a subnet in a virtual network.
Get-AzVirtualNetworkTap Gets a virtual network tap
Get-AzVirtualNetworkUsageList Gets virtual network current usage.
New-AzVirtualNetwork Creates a virtual network.
New-AzVirtualNetworkGateway Creates a Virtual Network Gateway

New-AzVirtualNetworkGatewayConnection Creates the Site-to-Site VPN connection between the
virtual network gateway and the on-prem VPN device.
New-AzVirtualNetworkGatewayIpConfig Creates an IP Configuration for a Virtual Network

Gateway
New-AzVirtualNetworkGatewayNatRule Creates the virtual network gateway natRule object.
New-AzVirtualNetworkGatewayPolicyGroup Create a Virtual Network Gateway Policy Group
New-AzVirtualNetworkGatewayPolicyGroupmember Create a Virtual Network Gateway Policy Group

Member
New-AzVirtualNetworkSubnetConfig Creates a virtual network subnet configuration.
New-AzVirtualNetworkTap Creates a VirtualNetworkTap resource.
Remove-AzVirtualNetwork Removes a virtual network.
Remove-AzVirtualNetworkGateway Deletes a Virtual Network Gateway
Remove-AzVirtualNetworkGatewayConnection Deletes a Virtual Network Gateway Connection
Remove-AzVirtualNetworkGatewayDefaultSite Removes the default site from a virtual network

gateway.
Remove-AzVirtualNetworkGatewayIpConfig Removes an IP Configuration from a Virtual Network

Gateway
Remove-AzVirtualNetworkGatewayNatRule Removes or Delete a Virtual Network Gateway NatRule.
Remove-AzVirtualNetworkPeering Removes a virtual network peering.
Remove-AzVirtualNetworkSubnetConfig Removes a subnet configuration from a virtual

network.
Remove-AzVirtualNetworkTap Removes a virtual network tap.
Reset-AzVirtualNetworkGateway Resets the Virtual Network Gateway
Reset-AzVirtualNetworkGatewayConnection Reset a Virtual Network Gateway Connection
Reset-AzVirtualNetworkGatewayConnectionSharedKey Resets the shared key of the virtual network gateway

connection.
Resize-AzVirtualNetworkGateway Resizes an existing virtual network gateway.
Set-AzVirtualNetwork Updates a virtual network.
Set-AzVirtualNetworkGateway Updates a virtual network gateway.
Set-AzVirtualNetworkGatewayConnection Configures a virtual network gateway connection.
Set-AzVirtualNetworkGatewayConnectionSharedKey Configures the shared key of the virtual network

gateway connection.
Set-AzVirtualNetworkGatewayDefaultSite Sets the default site for a virtual network gateway.
Set-AzVirtualNetworkPeering Configures a virtual network peering.
Set-AzVirtualNetworkSubnetConfig Updates a subnet configuration for a virtual network.
Set-AzVirtualNetworkTap Updates a virtual network tap.

Start-AzVirtualNetworkGatewayConnectionPacketCapture Starts Packet Capture Operation on a Virtual Network
Gateway Connection.
Stop-AzVirtualNetworkGatewayConnectionPacketCapture Stops Packet Capture Operation on a Virtual Network

Gateway connection
Stop-AzVirtualNetworkGatewayPacketCapture Stops Packet Capture Operation on a Virtual Network

Gateway.
Sync-AzVirtualNetworkPeering Command to sync the address space on the peering

link if the remote virtual network has a new address
space.
Update-AzVirtualNetworkGatewayNatRule Updates a Virtual Network Gateway NatRule.
VPN
Add-AzVpnClientRevokedCertificate Adds a VPN client-revocation certificate.
Add-AzVpnClientRootCertificate Adds a VPN client root certificate.
Disconnect-AzP2SVpnGatewayVpnConnection Disconnect given connected vpn client connections with a given p2s vpn
gateway
Get-AzP2sVpnGateway Gets an existing P2SVpnGateway under VirtualHub.
Get-AzP2sVpnGatewayConnectionHealth Gets the current aggregared point to site connections health information
from P2SVpnGateway.
Get- Gets the detailed information of current point to site connections from
AzP2sVpnGatewayDetailedConnectionHealth P2SVpnGateway.
Get-AzP2sVpnGatewayVpnProfile Generates and returns a SAS url for customer to download Vpn profile for
point to site client setup to have point to site connectivity to
P2SVpnGateway.
Get-AzVirtualWanVpnConfiguration Gets the Vpn configuration for a subset of VpnSites connected to this WAN
via VpnConnections. Uploads the generated Vpn configuration to a
storage blob specified by the customer.
Get-AzVirtualWanVpnServerConfiguration Gets the list of all VpnServerConfigurations that are associated with this
VirtualWan.
Get- Generates and downloads Vpn profile at VirtualWan-

AzVirtualWanVpnServerConfigurationVpnProfile VpnServerConfiguration level for Point to site client setup.
Get-AzVpnClientConfiguration Allows users to easily download the Vpn Profile package that was
generated using the New-AzVpnClientConfiguration commandlet.
Get-AzVpnClientIpsecParameter Gets the vpn Ipsec parameters set on Virtual Network Gateway for Point to
site connections.
Get-AzVpnClientPackage Gets information about a VPN client package.
Get-AzVpnClientRevokedCertificate Gets information about VPN client-revocation certificates.
Get-AzVpnClientRootCertificate Gets information about VPN root certificates.
Get-AzVpnConnection Gets a vpn connection by name or lists all vpn connections connected to a
VpnGateway.
７ Notes
This Powershell command is for customers using Virtual

WAN Site-to-site VPN Gateway only.
Get-AzVpnGateway Gets a VpnGateway resource using ResourceGroupName and

GatewayName OR lists all gateways by ResourceGroupName or
SubscriptionId.
Get-AzVpnGatewayNatRule Gets a NAT rule associated with VpnGateway.
Get-AzVpnServerConfiguration Gets an existing VpnServerConfiguration for point to site connectivity.
Get-AzVpnServerConfigurationPolicyGroup Create a new P2SVpnGateway under VirtualHub for point to site

connectivity.
Get-AzVpnSite Gets an Azure VpnSite resource by name OR lists all VpnSites in a

ResourceGroup or SubscriptionId.
This is an RM representation of customer branches that are uploaded to

Azure for S2S connectivity with a Cortex virtual hub.
Get-AzVpnSiteLinkConnectionIkeSa Get IKE Security Associations of VPN Site Link Connections
New-AzP2sVpnGateway Create a new P2SVpnGateway under VirtualHub for point to site

connectivity.
New-AzVpnClientConfiguration This command allows the users to create the Vpn profile package based on
pre-configured vpn settings on the VPN gateway, in addition to some
additional settings that users may need to configure, for e.g. some root
certificates.
New-AzVpnClientConnectionConfiguration Create Virtual Network Gateway Connection configuration
New-AzVpnClientIpsecParameter This command allows the users to create the Vpn ipsec parameters object
specifying one or all values such as
IpsecEncryption,IpsecIntegrity,IkeEncryption,IkeIntegrity,DhGroup,PfsGroup
to set on the existing VPN gateway.
New-AzVpnClientIpsecPolicy This command allows the users to create the Vpn ipsec policy object
specifying one or all values such as
IpsecEncryption,IpsecIntegrity,IkeEncryption,IkeIntegrity,DhGroup,PfsGroup
to set on the VPN gateway. This command let output object is used to set
vpn ipsec policy for both new / existing gateway.
New-AzVpnClientRevokedCertificate Creates a new VPN client-revocation certificate.
New-AzVpnClientRootCertificate Creates a new VPN client root certificate.
New-AzVpnConnection Creates a IPSec connection that connects a VpnGateway to a remote

customer branch represented in RM as a VpnSite.
New-AzVpnGateway Creates a Scalable VPN Gateway.
New-AzVpnGatewayNatRule Creates a NAT rule on a VpnGateway which can be associated with

VpnSiteLinkConnection.
New-AzVpnServerConfiguration Create a new VpnServerConfiguration for point to site connectivity.
New-AzVpnServerConfigurationPolicyGroup Create a new P2SVpnGateway under VirtualHub for point to site

connectivity.
New-AzVpnSite Creates a new Azure VpnSite resource. This is an RM representation of

customer branches that are uploaded to Azure for S2S connectivity with a
Cortex virtual hub.
New-AzVpnSiteLink Creates an Azure VpnSiteLink object.
New-AzVpnSiteLinkConnection Creates an Azure VpnSiteLinkConnection object.
Remove-AzP2sVpnGateway Removes an existing P2SVpnGateway.
Remove-AzVpnClientIpsecParameter Removes Vpn custom ipsec policy set on Virtual Network Gateway
resource.
Remove-AzVpnClientRevokedCertificate Removes a VPN client-revocation certificate.
Remove-AzVpnClientRootCertificate Removes an existing VPN client root certificate.
Remove-AzVpnConnection Removes a VpnConnection.
Remove-AzVpnGateway The Remove-AzVpnGateway cmdlet removes an Azure VPN gateway. This

is a gateway specific to Azure Virtual WAN's software defined connectivity.
Remove-AzVpnGatewayNatRule Removes a NAT rule associated with VpnGateway.
Remove-AzVpnServerConfiguration Removes an existing VpnServerConfiguration.
Remove-AzVpnServerConfigurationPolicyGroup Create a new P2SVpnGateway under VirtualHub for point to site

connectivity.
Remove-AzVpnSite Removes an Azure VpnSite resource.
Reset-AzP2sVpnGateway Resets the scalable P2S VPN gateway.
Reset-AzVpnGateway Resets the scalable VPN gateway.
Reset-AzVpnSiteLinkConnection Reset a VPN Site Link Connection
Set-AzVpnClientIpsecParameter Sets the vpn ipsec parameters for existing virtual network gateway.
Start-AzVpnConnectionPacketCapture Starts Packet Capture Operation on a Vpn Connection.
Start-AzVpnGatewayPacketCapture Starts Packet Capture Operation on a Vpn Gateway.
Stop-AzVpnConnectionPacketCapture Stops Packet Capture Operation on a Vpn connection
Stop-AzVpnGatewayPacketCapture Stops Packet Capture Operation on a Vpn Gateway.
Update-AzP2sVpnGateway Update an existing P2SVpnGateway under VirtualHub for point to site

connectivity.
Update-AzVpnConnection Updates a VPN connection.
Update-AzVpnGateway Updates a scalable VPN gateway.
Update-AzVpnGatewayNatRule Updates a NAT rule associated with VpnGateway.
Update-AzVpnServerConfiguration Updates an existing VpnServerConfiguration.
Update-AzVpnServerConfigurationPolicyGroup Create a new P2SVpnGateway under VirtualHub for point to site

connectivity.
Update-AzVpnSite Updates a VPN site.

Kit de développement logiciel (SDK)
Azure Réseau virtuel pour .NET -
dernière version
Article • 03/04/2023
Packages - dernière version

Informations de référence Package Source
Gestion - Réseau Microsoft.Azure.Management.Network GitHub
Gestion - Réseau Fluent Microsoft.Azure.Management.Network.Fluent GitHub
Gestion WindowsAzure - Réseau Microsoft.WindowsAzure.Management.Network GitHub

Azure pour les développeurs JavaScript
et Node.js
Explorez la puissance de JavaScript sur Azure avec des démarrages rapides, des guides
pratiques, des exemples de code et plus encore.
Vous êtes un nouvel utilisateur d’Azure ?
ｂ BIEN DÉMARRER
Qu’est-ce qu’Azure ?
Bases d’Azure
Installer Node.js
Configurer l’environnement de développement
S’authentifier auprès du SDK Azure
Authentifier les utilisateurs de votre application web
Bases de données pour les développeurs
Stockage pour les développeurs
Blog sur le kit SDK Azure
Déployer et héberger des applications
ｇ DIDACTICIEL
Sélectionner un service d’hébergement
Client : JamStack charge l’image dans le stockage
Client : JamStack + authentification
Migrer vers serverless
Serverless : prise en main
Serveur : Déployer Express.js
Serveur à partir du conteneur
Serveur à partir de la machine virtuelle : Express.js avec NGINX

Tutoriels sur les bibliothèques de client de SDK Azure
ｇ DIDACTICIEL
Application web statique : Analyser une image avec Vision par ordinateur
Application web statique : Charger un fichier dans Storage Blob
Application web statique : Bouton de connexion/déconnexion
Express.js : Ajouter la journalisation dans Application Insights
Web + Données
Stockage sur Azure
Bases de données sur Azure
GraphQL sur Azure
Pile complète serverless avec Mongoose
API serverless + base de données
Express.js + MongoDB (formation)
Express.js + MongoDB (docs)
IA/ML
Ajouter la recherche à un site web
Détection de la langue
Extraction d’expressions clés
Reconnaissance vocale
Synthèse vocale
Analyse d’image
Utiliser des bibliothèques clientes Azure (SDK)
ｂ BIEN DÉMARRER
Utiliser les kits SDK Azure pour JS/TS
Dernière version du KIT de développement logiciel (SDK)
Documentation de référence du KIT de développement logiciel (SDK)
Code source du KIT de développement logiciel (SDK) pour JS
Exemples de navigateur
Guides du développeur
ｂ BIEN DÉMARRER
Guide de développement stockage Azure
Guide de développement Azure Database
Outils de développeur
ｂ BIEN DÉMARRER
Visual Studio Code (IDE)
Interface de ligne de commande Azure (CLI)
Azure Developer CLI
Interface CLI d’Azure Static Web Apps
Azure Functions principaux outils CLI
Terminal Windows
Sous-système Windows pour Linux (WSL)

API REST réseaux virtuels
Un réseau virtuel Azure (VNet) est une représentation de votre propre réseau dans le
cloud. Il s’agit d’un isolement logique du cloud Azure dédié à votre abonnement. Vous
pouvez contrôler complètement les blocs d’adresses IP, les paramètres DNS, les
stratégies de sécurité et les tables de routage de ce réseau. Pour obtenir une vue
d’ensemble plus détaillée, consultez la page produit Azure Réseau virtuel .
Groupes d’opérations REST

Groupe d’opérations Description
DDoS Protection Plans Fournit des opérations pour la gestion des plans de
protection DDos.
Cartes d’interface réseau Fournit des opérations pour la gestion des cartes d’interface
réseau.
Groupes de sécurité réseau Fournit des opérations pour la gestion des groupes de
sécurité réseau.
Règles de sécurité réseau Fournit des opérations pour la gestion des règles de sécurité
réseau.
Adresses IP publiques Fournit des opérations pour la gestion des adresses IP

publiques.
Sous-réseaux Fournit des opérations pour la gestion des sous-réseaux.
Réseaux virtuels Fournit des opérations pour la gestion des réseaux virtuels.
Tables de routage Fournit des opérations pour la gestion des tables de routage.
Itinéraires Fournit des opérations pour la gestion des itinéraires.
Réseau virtuel Peerings Fournit des opérations pour la gestion des peerings Réseau
virtuel.
Services de point de terminaison Fournit la liste des services de point de terminaison

disponibles disponibles dans une région.
Vérifier la disponibilité du nom Fournit une opération pour vérifier la disponibilité du nom
DNS DNS.
Utilisations Fournit une opération pour répertorier les utilisations.

Microsoft. Types de ressources réseau
Cet article répertorie les versions disponibles pour chaque type de ressource.
Pour obtenir la liste des modifications apportées à chaque version de l’API, consultez
journal des modifications
Types et versions des ressources

Types Versions
applicationGatewayAvailableSslOptions 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
applicationGatewayAvailableSslOptions/predefinedPolicies 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
applicationGateways 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
applicationGateways/privateEndpointConnections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
ApplicationGatewayWebApplicationFirewallPolicies 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
applicationSecurityGroups 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
azureFirewalls 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
bastionHosts 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
cloudServiceSlots 2022-07-01
2022-05-01
Types Versions
connections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
customIpPrefixes 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
ddosCustomPolicies 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
ddosProtectionPlans 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
dscpConfigurations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
expressRouteCircuits 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
expressRouteCircuits/authorizations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
expressRouteCircuits/peerings 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
expressRouteCircuits/peerings/connections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
expressRouteCircuits/peerings/peerConnections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
expressRouteCrossConnections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
expressRouteCrossConnections/peerings 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
expressRouteGateways 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
expressRouteGateways/expressRouteConnections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
ExpressRoutePorts 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
expressRoutePorts/authorizations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
ExpressRoutePorts/liens 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
ExpressRoutePortsLocations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
expressRouteProviderPorts 2022-07-01
2022-05-01
2022-01-01
firewallPolicies 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
firewallPolicies/ruleCollectionGroups 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
firewallPolicies/signatureOverrides 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
IpAllocations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
ipGroups 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
loadBalancers 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
loadBalancers/backendAddressPools 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
loadBalancers/frontendIPConfigurations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
loadBalancers/inboundNatRules 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
loadBalancers/loadBalancingRules 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
loadBalancers/outboundRules 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
loadBalancers/probes 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
localNetworkGateways 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
managementGroups/networkManagerConnections 2021-05-01-preview
natGateways 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkInterfaces 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkInterfaces/ipConfigurations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkInterfaces/tapConfigurations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
networkManagerConnections 2022-07-01
2022-05-01
2022-04-01-preview
2022-02-01-preview
2022-01-01
2021-05-01-preview
networkManagers 2022-07-01
2022-05-01
2022-04-01-preview
2022-02-01-preview
2022-01-01
2021-05-01-preview
2021-02-01-preview
networkManagers/connectivityConfigurations 2022-07-01
2022-05-01
2022-04-01-preview
2022-02-01-preview
2022-01-01
2021-05-01-preview
2021-02-01-preview
networkManagers/networkGroups 2022-07-01
2022-05-01
2022-04-01-preview
2022-02-01-preview
2022-01-01
2021-05-01-preview
2021-02-01-preview
networkManagers/networkGroups/staticMembers 2022-07-01
2022-05-01
2022-04-01-preview
2022-02-01-preview
2022-01-01
2021-05-01-preview
networkManagers/scopeConnections 2022-07-01
2022-05-01
2022-04-01-preview
2022-02-01-preview
2022-01-01
2021-05-01-preview
Types Versions
networkManagers/securityAdminConfigurations 2022-07-01
2022-05-01
2022-04-01-preview
2022-02-01-preview
2022-01-01
2021-05-01-preview
2021-02-01-preview
networkManagers/securityAdminConfigurations/ruleCollections 2022-07-01
2022-05-01
2022-04-01-preview
2022-02-01-preview
2022-01-01
2021-05-01-preview
2021-02-01-preview
networkManagers/securityAdminConfigurations/ruleCollections/rules 2022-07-01
2022-05-01
2022-04-01-preview
2022-02-01-preview
2022-01-01
2021-05-01-preview
2021-02-01-preview
networkManagers/securityUserConfigurations 2022-04-01-preview
2022-02-01-preview
2021-05-01-preview
2021-02-01-preview
networkManagers/securityUserConfigurations/ruleCollections 2022-04-01-preview
2022-02-01-preview
2021-05-01-preview
2021-02-01-preview
networkManagers/securityUserConfigurations/ruleCollections/rules 2022-04-01-preview
2022-02-01-preview
2021-05-01-preview
2021-02-01-preview
networkProfiles 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
networkSecurityGroups 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkSecurityGroups/defaultSecurityRules 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkSecurityGroups/securityRules 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkSecurityPerimeters 2021-03-01-preview
2021-02-01-preview
networkSecurityPerimeters/linkReferences 2021-02-01-preview
networkSecurityPerimeters/links 2021-02-01-preview
networkSecurityPerimeters/profiles 2021-02-01-preview
networkSecurityPerimeters/profiles/accessRules 2021-02-01-preview
networkSecurityPerimeters/resourceAssociations 2021-02-01-preview
networkVirtualAppliances 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
networkVirtualAppliances/inboundSecurityRules 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkVirtualAppliances/virtualApplianceSites 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkVirtualApplianceSkus 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkWatchers 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkWatchers/connectionMonitors 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
networkWatchers/flowLogs 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
networkWatchers/packetCaptures 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
p2svpnGateways 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
privateEndpoints 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
privateEndpoints/privateDnsZoneGroups 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
privateLinkServices 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
privateLinkServices/privateEndpointConnections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
publicIPAddresses 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
publicIPPrefixes 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
routeFilters 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
routeFilters/routeFilterRules 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
routeTables 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
routeTables/routes 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
securityPartnerProviders 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
serviceEndpointPolicies 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
serviceEndpointPolicies/serviceEndpointPolicyDefinitions 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualHubs 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualHubs/bgpConnections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualHubs/hubRouteTables 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualHubs/hubVirtualNetworkConnections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
virtualHubs/ipConfigurations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualHubs/routeMaps 2022-07-01
2022-05-01
virtualHubs/routeTables 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualHubs/routingIntent 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
virtualNetworkGateways 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualNetworkGateways/natRules 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
Types Versions
virtualNetworks 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualNetworks/subnets 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualNetworks/virtualNetworkPeerings 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualNetworkTaps 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualRouters 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
virtualRouters/peerings 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
virtualWans 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
vpnGateways 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
vpnGateways/natRules 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
vpnGateways/vpnConnections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Types Versions
vpnGateways/vpnConnections/vpnLinkConnections 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
vpnServerConfigurations 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
vpnServerConfigurations/configurationPolicyGroups 2022-07-01
2022-05-01
2022-01-01
2021-08-01
vpnSites 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
vpnSites/vpnSiteLinks 2022-07-01
2022-05-01
2022-01-01
2021-08-01
2021-05-01
2021-03-01
2021-02-01
2020-11-01
Définitions intégrées d’Azure Policy
pour Réseau virtuel Azure
Article • 09/06/2023
Cette page est un index des définitions de stratégie intégrées d’Azure Policy pour Azure
Virtual Network. Pour obtenir des éléments intégrés supplémentaires d’Azure Policy
pour d’autres services, consultez Définitions intégrées d’Azure Policy.
Le nom de chaque définition de stratégie intégrée est un lien vers la définition de la

stratégie dans le portail Azure. Utilisez le lien de la colonne Version pour voir la source
dans le dépôt GitHub Azure Policy .

[Préversion] : Azure Security Center a détecté que AuditIfNotExists, 3.0.0-

[Préversion] : certains de vos sous-réseaux ne sont pas Désactivé preview
L’ensemble du protégés par un pare-feu de nouvelle
trafic Internet doit génération. Protégez vos sous-réseaux
transiter par votre contre les menaces potentielles en limitant
Pare-feu Azure leur accès avec le pare-feu Azure ou un
déployé pare-feu de nouvelle génération pris en
charge
[Préversion] : Cette stratégie audite Container Registry s’il Audit, Désactivé 1.0.0-
[Préversion] : n’est pas configuré pour utiliser un point de preview
Container terminaison de service de réseau virtuel.
Registry doit
utiliser un point
de terminaison de
service de réseau
virtuel
Une stratégie Cette stratégie garantit que toutes les Audit, Désactivé 1.0.0
IPsec/IKE connexions de passerelle de réseau virtuel
personnalisée Azure utilisent une stratégie IPsec (Internet
doit être Protocol Security)/IKE (Internet Key
appliquée à Exchange). Algorithmes et forces de clé pris
toutes les en charge - https://aka.ms/AA62kb0
connexions de
passerelle de
réseau virtuel
Azure
Toutes les Auditez les ressources du journal de flux Audit, Désactivé 1.0.1
ressources du pour vérifier si l’état du journal de flux est
journal de flux activé. L’activation des journaux de flux
doivent être en permet de consigner des informations sur
état activé le trafic IP circulant. Il peut être utilisé pour
optimiser les flux réseau, surveiller le débit,
vérifier la conformité, détecter les
intrusions, etc.
Les applications Utilisez des points de terminaison de AuditIfNotExists, 2.0.0

App Service service de réseau virtuel pour restreindre Désactivé
doivent utiliser un l’accès à votre application à partir des sous-
point de réseaux sélectionnés à partir d’un réseau
terminaison de virtuel Azure. Pour en savoir plus sur les
service de réseau points de terminaison de service App
virtuel Service, consultez
https://aks.ms/appservice-vnet-service-
endpoint .
La stratégie de L’activation de l’inspection TLS est Audit, Refuser, 1.0.0

pare-feu Azure recommandée pour toutes les règles Désactivé
doit activer d’application pour détecter, alerter et
l’inspection TLS atténuer les activités malveillantes dans
dans les règles HTTPS. Pour en savoir plus sur l’inspection
d’application TLS avec le Pare-feu Azure, consultez
https://aka.ms/fw-tlsinspect
Le pare-feu Azure Configurez un certificat intermédiaire valide Audit, Refuser, 1.0.0

Premium doit et activez TLS sur le Pare-feu Azure Désactivé
configurer un inspection TLS pour détecter, alerter et
certificat atténuer les activités malveillantes en
intermédiaire HTTPS. Pour en savoir plus sur l’inspection
valide pour TLS avec le Pare-feu Azure, consultez
activer https://aka.ms/fw-tlsinspect
l’inspection TLS
Les passerelles Cette stratégie garantit que les passerelles Audit, Désactivé 1.0.0
VPN Azure ne VPN n’utilisent pas de référence SKU « de
doivent pas base ».
utiliser la
référence SKU
« de base »
Azure Web Vérifiez que l’inspection du corps de la Audit, Refuser, 1.0.0

Application demande est activée pour les pare-feu Désactivé
Firewall sur Azure d’applications web (WAF) associés aux
Application passerelles d’application Azure. Cela
Gateway doit permet au WAF d’inspecter les propriétés
avoir l’inspection dans le corps HTTP qui ne peuvent pas être
du corps de la évaluées dans les en-têtes HTTP, les
demande cookies ou l’URI.
activée
L’inspection du Vérifiez que l’inspection du corps de la Audit, Refuser, 1.0.0

corps de la demande est activée pour les pare-feu Désactivé
demande doit d’applications web associés aux passerelles
être activé dans Azure Application. Cela permet au WAF
Azure Web d’inspecter les propriétés dans le corps
Application HTTP qui ne peuvent pas être évaluées
Firewall sur Azure dans les en-têtes HTTP, les cookies ou l’URI.
Front Door
Azure Web Déployez Azure Web Application Firewall Audit, Refuser, 1.0.2
Application (WAF) devant les applications web Désactivé
Firewall doit être publiques pour bénéficier d’un contrôle
activé pour les supplémentaire du trafic entrant. Web
points d’entrée Application Firewall (WAF) offre une
Azure Front protection centralisée de vos applications
Door web contre les codes malveillants
exploitant une faille de sécurité et les
vulnérabilités telles que les injections de
code SQL, le scripting inter-site, les
exécutions de fichiers locales et à distance.
Vous pouvez également restreindre l’accès
à vos applications web par pays, plages
d’adresses IP et autres paramètres http(s)
par le biais de règles personnalisées.
La liste de La liste de contournement de l’IDPS Audit, Refuser, 1.0.0

contournement (Intrusion Detection and Prevention Désactivé
de l’IDPS System) vous permet de ne pas filtrer le
(Intrusion trafic vers les adresses IP, les plages et les
Detection and sous-réseaux spécifiés dans cette liste.
Prevention Toutefois, l’activation d’IDPS est
System) doit être recommandée pour tous les flux de trafic
vide dans la afin de mieux identifier les menaces
stratégie de pare- connues. Pour en savoir plus sur les
feu Premium signatures d’Intrusion Detection and
Prevention System (IDPS) avec le Pare-feu
Azure Premium, consultez
https://aka.ms/fw-idps-signature
Configurer les Déployez les paramètres de diagnostic DeployIfNotExists, 1.0.0

paramètres de dans des groupes de sécurité réseau Azure Désactivé
diagnostic pour afin de diffuser les journaux de ressources
les groupes de vers un espace de travail Log Analytics.
sécurité réseau
Azure dans
l’espace de travail
Log Analytics
Configurer les Vous pouvez activer Traffic Analytics pour DeployIfNotExists, 1.2.0
groupes de tous les groupes de sécurité réseau Désactivé
sécurité réseau hébergés dans une région particulière avec
pour activer les paramètres fournis durant la création de
Traffic Analytics la stratégie. Si Traffic Analytics est déjà
activé, la stratégie ne remplace pas ses
paramètres. Les journaux de flux sont
également activés pour les groupes de
sécurité réseau qui n’en disposent pas.
Traffic Analytics est une solution cloud qui
offre une visibilité de l’activité des
utilisateurs et des applications dans vos
réseaux cloud.
Configurer des Si Traffic Analytics est déjà activé, la DeployIfNotExists, 1.2.0

groupes de stratégie remplace ses paramètres existants Désactivé
sécurité réseau par ceux fournis durant la création de la
pour utiliser un stratégie. Traffic Analytics est une solution
espace de travail, cloud qui offre une visibilité de l’activité des
un compte de utilisateurs et des applications dans vos
stockage et une réseaux cloud.
stratégie de
rétention de flux
spécifiques pour
l’analyse du
trafic
Configurer un Vous pouvez activer l’analyse du trafic pour DeployIfNotExists, 1.0.0

réseau virtuel tous les réseaux virtuels hébergés dans une Désactivé
pour qu’il active région particulière avec les paramètres
les analyses de fournis durant la création de la stratégie. Si
trafic Traffic Analytics est déjà activé, la stratégie
ne remplace pas ses paramètres. Les
journaux de flux sont également activés
pour le réseau virtuel qui n’en dispose pas.
Traffic Analytics est une solution cloud qui
offre une visibilité de l’activité des
utilisateurs et des applications dans vos
réseaux cloud.
Configurer des Si Traffic Analytics est déjà activé, la DeployIfNotExists, 1.0.0

réseaux virtuels stratégie remplace ses paramètres existants Désactivé
pour qu’ils par ceux fournis durant la création de la
utilisent un stratégie. Traffic Analytics est une solution
espace de travail, cloud qui offre une visibilité de l’activité des
un compte de utilisateurs et des applications dans vos
stockage et une réseaux cloud.
stratégie de
conservation de
flux spécifiques
pour l’analyse du
trafic
Cosmos DB doit Cette stratégie audite Cosmos DB s’il n’est Audit, Désactivé 1.0.0
utiliser un point pas configuré pour utiliser un point de
de terminaison de terminaison de service de réseau virtuel.
service de réseau
virtuel
Déployer une Configure le journal de flux pour un groupe deployIfNotExists 1.1.0

ressource de de sécurité réseau spécifique. Il permettra à
journal de flux de consigner des informations sur le trafic
avec un groupe IP circulant dans un groupe de sécurité
de sécurité réseau réseau. Le journal de flux aide à identifier le
cible trafic inconnu ou indésirable, à vérifier
l’isolement réseau et la conformité avec les
règles d’accès d’entreprise, à analyser les
flux réseau provenant d’adresses IP et
d’interfaces réseau compromises.
Déployer une Configure le journal de flux pour un réseau DeployIfNotExists, 1.0.0

ressource de virtuel spécifique. Cela permettra de Désactivé
journal de flux consigner des informations sur le trafic IP
avec un réseau circulant dans un réseau virtuel. Le journal
virtuel cible de flux aide à identifier le trafic inconnu ou
indésirable, à vérifier l’isolement réseau et
la conformité avec les règles d’accès
d’entreprise, à analyser les flux réseau
provenant d’adresses IP et d’interfaces
réseau compromises.
Déployer Cette stratégie crée une ressource Network DeployIfNotExists 1.0.0

Network Watcher Watcher dans des régions avec des réseaux
lors de la création virtuels. Vous devez vérifier l’existence d’un
de réseaux groupe de ressources nommé
virtuels networkWatcherRG, qui sert à déployer des
instances de Network Watcher.
Activer la règle de La règle de limitation du débit du pare-feu Audit, Refuser, 1.0.0

limite de débit d’applications web (WAF) Azure pour Azure Désactivé
pour vous Front Door contrôle le nombre de requêtes
protéger contre autorisées à partir d’une adresse IP cliente
les attaques particulière à l’application pendant une
DDoS sur le pare- durée de limitation du débit.
feu d’applications
web Azure Front
Door
Event Hub doit Cette stratégie audite Event Hub s’il n’est AuditIfNotExists, 1.0.0
utiliser un point pas configuré pour utiliser un point de Désactivé
service de réseau
virtuel
La stratégie de L’activation de toutes les règles de Audit, Refuser, 1.0.0

pare-feu signature IDPS (Intrusion Detection and Désactivé
Premium doit Prevention System) est recommandée pour
activer toutes les mieux identifier les menaces connues dans
règles de les flux de trafic. Pour en savoir plus sur les
signature IDPS signatures d’Intrusion Detection and
pour surveiller Prevention System (IDPS) avec le Pare-feu
tous les flux de Azure Premium, consultez
trafic entrant et https://aka.ms/fw-idps-signature
sortant
La stratégie de Activer l’IDPS (Intrusion Detection and Audit, Refuser, 1.0.0

pare-feu Prevention System) vous permet de Désactivé
Premium doit surveiller les activités malveillantes, de
activer le système consigner des informations sur ces activités,
de détection et de les signaler, voire de les bloquer. Pour
de prévention des en savoir plus sur IDPS (Intrusion Detection
intrusions and Prevention System) avec le Pare-feu
(IDPS) Azure Premium, consultez
https://aka.ms/fw-idps
Les journaux de Auditez les groupes de sécurité réseau pour Audit, Désactivé 1.1.0
flux doivent être vérifier si les journaux de flux sont
configurés pour configurés. Activer les journaux de flux
chaque groupe permet de consigner des informations sur
de sécurité le trafic IP circulant dans un groupe de
réseau sécurité réseau. Il peut être utilisé pour
optimiser les flux réseau, surveiller le débit,
vérifier la conformité, détecter les
intrusions, etc.
Les journaux de Auditez les réseaux virtuels pour vérifier si Audit, Désactivé 1.0.0
flux doivent être les journaux de flux sont configurés.
configurés pour L’activation des journaux de flux permet de
chaque réseau consigner des informations sur le trafic IP
virtuel circulant dans un réseau virtuel. Il peut être
utilisé pour optimiser les flux réseau,
surveiller le débit, vérifier la conformité,
détecter les intrusions, etc.
Les sous-réseaux Cette stratégie refuse un sous-réseau de deny 1.0.0

de passerelle ne passerelle configuré avec un groupe de
doivent pas être sécurité réseau. L’attribution d’un groupe
configurés avec de sécurité réseau à un sous-réseau de
un groupe de passerelle entraîne l’arrêt du
sécurité réseau fonctionnement de la passerelle.
Key Vault doit Cette stratégie audite Key Vault s’il n’est Audit, Désactivé 1.0.0
utiliser un point pas configuré pour utiliser un point de
service de réseau
virtuel
Migrer WAF de la Si vous disposez d’une configuration WAF Audit, Refuser, 1.0.0
configuration plutôt que d’une stratégie WAF, vous Désactivé
WAF vers la pouvez éventuellement passer à la nouvelle
stratégie WAF sur stratégie WAF. À l’avenir, la stratégie de
Application pare-feu prendra en charge les paramètres
Gateway de stratégie WAF, les ensembles de règles
managés, les exclusions et les groupes de
règles désactivés.
Les interfaces Cette stratégie refuse les interfaces réseau deny 1.0.0
réseau doivent qui permettaient le transfert IP. Le
désactiver le paramètre de transfert IP désactive la
transfert IP vérification par Azure de la source et de la
destination d’une interface réseau. Il doit
être examiné par l’équipe de sécurité
réseau.
Les interfaces Cette stratégie refuse les interfaces réseau deny 1.0.0
réseau ne doivent configurées avec une adresse IP publique.
pas avoir Les adresses IP publiques permettent aux
d’adresses IP ressources Internet de communiquer avec
publiques les ressources Azure et aux ressources
Azure de communiquer avec Internet. Il
doit être examiné par l’équipe de sécurité
réseau.
Traffic Analytics L’analyse de trafic examine les journaux de Audit, Désactivé 1.0.1
doit être activé flux pour fournir des informations sur le flux
pour les journaux de trafic de votre cloud Azure. Il peut être
de flux Network utilisé pour visualiser l’activité réseau de
Watcher vos abonnements Azure ainsi que pour
identifier les points d’accès, identifier les
menaces de sécurité, comprendre les
modèles de flux de trafic, identifier les
problèmes de configuration réseau, etc.
Network Watcher Network Watcher est un service régional AuditIfNotExists, 3.0.0

doit être activé qui vous permet de surveiller et de Désactivé
diagnostiquer l’état au niveau d’un scénario
réseau dans, vers et depuis Azure. La
surveillance au niveau des scénarios vous
permet de diagnostiquer les problèmes
avec une vue de bout en bout du réseau.
Vous devez créer un groupe de ressources
Network Watcher dans chaque région où
un réseau virtuel est présent. Une alerte est
activée dans le cas où aucun groupe de
ressources Network Watcher n’est
disponible dans une région donnée.
SQL Server doit Cette stratégie audite tout serveur SQL AuditIfNotExists, 1.0.0
utiliser un point Server non configuré pour utiliser un point Désactivé
de terminaison de de terminaison de service de réseau virtuel.
service de réseau
virtuel
Les comptes de Cette stratégie audite les comptes de Audit, Désactivé 1.0.0
stockage doivent stockage non configurés pour utiliser un
utiliser un point point de terminaison de service de réseau
de terminaison de virtuel.
service de réseau
virtuel
L’abonnement Le pare-feu Azure Premium offre une AuditIfNotExists, 1.0.0

doit configurer le protection avancée contre les menaces qui Désactivé
pare-feu Azure répond aux besoins des environnements
Premium pour hautement sensibles et réglementés.
fournir une Déployez le Pare-feu Azure Premium sur
couche de votre abonnement et assurez-vous que tout
protection le trafic du service est protégé par le Pare-
supplémentaire feu Azure Premium. Pour en découvrir plus
sur le Pare-feu Azure Premium, visitez
https://aka.ms/fw-premium
Les machines Cette stratégie audite les machines Audit, Refuser, 1.0.0
virtuelles doivent virtuelles connectées à un réseau virtuel Désactivé
être connectées à non approuvé.
un réseau virtuel
approuvé
Les réseaux Protégez vos réseaux virtuels contre les Modifier, Audit, 1.0.0
virtuels doivent attaques volumétriques et de protocole Désactivé
être protégés par avec Azure DDoS Protection Standard. Pour
Azure DDoS plus d’informations, consultez
Protection https://aka.ms/ddosprotectiondocs .
Standard
Les réseaux Cette stratégie audite les réseaux virtuels si AuditIfNotExists, 1.0.0
virtuels doivent la route par défaut ne pointe pas vers la Désactivé
utiliser la passerelle de réseau virtuel spécifiée.
passerelle de
réseau virtuel
spécifiée
Les passerelles La désactivation des méthodes Audit, Refuser, 1.0.0

VPN doivent d’authentification locales améliore la Désactivé
utiliser sécurité dans la mesure où cela permet de
uniquement garantir que les passerelles VPN utilisent
l’authentification uniquement les identités Azure Active
Azure AD (Azure Directory pour l’authentification. En savoir
Active Directory) plus sur l’authentification Azure AD sur
pour les https://docs.microsoft.com/azure/vpn-
utilisateurs point gateway/openvpn-azure-ad-tenant
à site
Le pare-feu Déployez Azure Web Application Firewall Audit, Refuser, 2.0.0

d’applications (WAF) devant les applications web Désactivé
web (WAF) doit publiques pour bénéficier d’un contrôle
être activé pour supplémentaire du trafic entrant. Web
Application Application Firewall (WAF) offre une
Gateway protection centralisée de vos applications
web contre les codes malveillants
exploitant une faille de sécurité et les
vulnérabilités telles que les injections de
code SQL, le scripting inter-site, les
exécutions de fichiers locales et à distance.
Vous pouvez également restreindre l’accès
à vos applications web par pays, plages
d’adresses IP et autres paramètres http(s)
par le biais de règles personnalisées.
Web Application L’activation de toutes les règles de Web Audit, Refuser, 1.0.1
Firewall (WAF) Application Firewall (WAF) renforce la Désactivé
doit activer toutes sécurité de votre application et protège vos
les règles de applications web contre les vulnérabilités
pare-feu pour courantes. Pour en savoir plus sur Web
Application Application Firewall (WAF) avec Application
Gateway Gateway, visitez https://aka.ms/waf-ag
Le pare-feu Impose l’utilisation du mode de Audit, Refuser, 1.0.0

d’applications « détection » ou de « blocage » pour être Désactivé
web (WAF) doit actif sur toutes les stratégies de pare-feu
utiliser le mode d’applications web pour Application
spécifié pour Gateway.
Application
Gateway
Le pare-feu Impose l’utilisation du mode de Audit, Refuser, 1.0.0

d’applications « détection » ou de « blocage » pour être Désactivé
web (WAF) doit actif sur toutes les stratégies de pare-feu
utiliser le mode d’applications web pour Azure Front Door
spécifié pour Service.
Azure Front Door
Service
Balises
Ajouter une Ajoute l’étiquette et la valeur indiquées lors de la modify 1.0.0

étiquette aux création ou de la mise à jour d’un groupe de ressources
groupes de auquel cette étiquette manque. Il est possible de
ressources corriger des groupes de ressources existants en
déclenchant une tâche de correction. Si l’étiquette existe
avec une valeur différente, elle n’est pas modifiée.
Ajouter une Ajoute l’étiquette et la valeur indiquées lors de la modify 1.0.0

étiquette aux création ou de la mise à jour d’une ressource à laquelle
ressources cette étiquette manque. Il est possible de corriger des
ressources existantes en déclenchant une tâche de
correction. Si l’étiquette existe avec une valeur
différente, elle n’est pas modifiée. Ne modifie pas les
balises sur les groupes de ressources.
Ajouter une Ajoute l’étiquette et la valeur spécifiées aux modify 1.0.0

étiquette aux abonnements par le biais d’une tâche de correction. Si
abonnements l’étiquette existe avec une valeur différente, elle n’est
pas modifiée. Consultez
https://aka.ms/azurepolicyremediation pour plus
d’informations sur la correction d’une stratégie.
Ajouter ou Ajoute ou remplace l’étiquette et la valeur indiquées lors modify 1.0.0

remplacer une de la création ou de la mise à jour d’un groupe de
étiquette sur ressources. Il est possible de corriger des groupes de
des groupes de ressources existants en déclenchant une tâche de
ressources correction.
Ajouter ou Ajoute ou remplace l’étiquette et la valeur indiquées lors modify 1.0.0

remplacer une de la création ou de la mise à jour d’une ressource. Il est
étiquette dans possible de corriger des ressources existantes en
les ressources déclenchant une tâche de correction. Ne modifie pas les
balises sur les groupes de ressources.
Ajouter ou Ajoute ou remplace l’étiquette et la valeur spécifiées sur modify 1.0.0

remplacer une des abonnements par le biais d’une tâche de correction.
étiquette dans Il est possible de corriger des groupes de ressources
les existants en déclenchant une tâche de correction.
abonnements Consultez https://aka.ms/azurepolicyremediation pour
plus d’informations sur la correction d’une stratégie.
Ajouter une Ajoute l’étiquette indiquée avec sa valeur du groupe de append 1.0.0
étiquette et sa ressources lors de la création ou de la mise à jour d’une
valeur à partir ressource à laquelle cette étiquette manque. Ne modifie
du groupe de pas les étiquettes des ressources créées avant
ressources l’application de cette stratégie, tant que ces ressources
ne sont pas modifiées. De nouvelles stratégies d’effet de
« modification » sont disponibles pour prendre en
charge la remédiation des étiquettes sur les ressources
existantes (voir https://aka.ms/modifydoc ).
Ajouter une Ajoute l’étiquette et la valeur indiquées lors de la append 1.0.0

étiquette et sa création ou de la mise à jour d’un groupe ressource
valeur aux auquel cette étiquette manque. Ne modifie pas les
groupes de étiquettes des groupes de ressources créés avant
ressources l’application de cette stratégie, tant que ces groupes de
ressources ne sont pas modifiés. De nouvelles stratégies
d’effet de « modification » sont disponibles pour
prendre en charge la remédiation des étiquettes sur les
ressources existantes (voir https://aka.ms/modifydoc ).
Ajouter une Ajoute l’étiquette et la valeur indiquées lors de la append 1.0.1

étiquette et sa création ou de la mise à jour d’une ressource à laquelle
valeur aux cette étiquette manque. Ne modifie pas les étiquettes
ressources des ressources créées avant l’application de cette
stratégie, tant que ces ressources ne sont pas modifiées.
Ne s’applique pas aux groupes de ressources. De
nouvelles stratégies d’effet de « modification » sont
disponibles pour prendre en charge la remédiation des
étiquettes sur les ressources existantes (voir
https://aka.ms/modifydoc ).
Hériter d’une Ajoute ou remplace l’étiquette et la valeur indiquées du modify 1.0.0

étiquette du groupe de ressources parent lors de la création ou de la
groupe de mise à jour d’une ressource. Il est possible de corriger
ressources des ressources existantes en déclenchant une tâche de
correction.
Hériter d’une Ajoute l’étiquette indiquée avec sa valeur du groupe de modify 1.0.0
étiquette du ressources parent lors de la création ou de la mise à jour
groupe de d’une ressource à laquelle cette étiquette manque. Il est
ressources en possible de corriger des ressources existantes en
cas d’absence déclenchant une tâche de correction. Si l’étiquette existe
Hériter une Ajoute ou remplace l’étiquette spécifiée et sa valeur de modify 1.0.0

étiquette de l’abonnement conteneur lors de la création ou de la
l’abonnement mise à jour d’une ressource. Il est possible de corriger
des ressources existantes en déclenchant une tâche de
correction.
Hériter une Ajoute l’étiquette spécifiée avec sa valeur de modify 1.0.0

étiquette de l’abonnement conteneur lors de la création ou de la
l’abonnement si mise à jour d’une ressource qui n’a pas cette étiquette. Il
elle est est possible de corriger des ressources existantes en
manquante déclenchant une tâche de correction. Si l’étiquette existe
Exiger une Applique une étiquette obligatoire avec sa valeur aux deny 1.0.0
étiquette et sa groupes de ressources.
valeur sur les
groupes de
ressources
Exiger une Applique une balise requise et sa valeur. Ne s’applique deny 1.0.1
étiquette et sa pas aux groupes de ressources.
valeur sur les
ressources
Exiger une Applique l’existence d’une étiquette sur des groupes de deny 1.0.0
étiquette sur les ressources.
groupes de
ressources
Exiger une Applique l’existence d’une étiquette. Ne s’applique pas deny 1.0.1
étiquette sur les aux groupes de ressources.
ressources
Nécessite que Refuse la création d’une ressource qui contient la balise Audit, 1.0.0
les ressources donnée. Ne s’applique pas aux groupes de ressources. Refuser,
n’ont pas de Désactivé
balise
spécifique.
Général
Emplacements Cette stratégie vous permet de restreindre les deny 1.0.0

autorisés emplacements que votre organisation peut spécifier
lors du déploiement de ressources. Utilisez-la pour
appliquer vos exigences de conformité géographique.
Exclut les groupes de ressources,
Microsoft.azureactivedirectory/b2cdirectories et les
ressources qui utilisent la région « globale ».
Emplacements Cette stratégie vous permet de restreindre les deny 1.0.0

autorisés pour emplacements où votre organisation peut créer des
les groupes de groupes de ressources. Utilisez-la pour appliquer vos
ressources exigences de conformité géographique.
Types de Cette stratégie vous permet de spécifier les types de deny 1.0.0
ressources ressources que votre organisation peut déployer. Seuls
autorisés les types de ressources prenant en charge « tags » et
« location » sont affectés par cette stratégie. Pour
restreindre toutes les ressources, dupliquez cette
stratégie et affectez à « mode » la valeur « All ».
Vérifier que Vérifie que l’emplacement de la ressource correspond à audit 2.0.0

l’emplacement l’emplacement de son groupe de ressources
de la ressource
correspond à
l’emplacement
du groupe de
ressources
Auditer Auditer des rôles intégrés tels que « Propriétaire, Audit, 1.0.1
l'utilisation des contributeur, lecteur » au lieu des rôles RBAC Désactivé
rôles RBAC personnalisés, qui sont susceptibles d’engendrer des
personnalisés erreurs. L’utilisation de rôles personnalisés est traitée
comme une exception et nécessite un contrôle
rigoureux et la modélisation des menaces
Types de Limitez les types de ressources qui peuvent être Audit, 2.0.0
ressources non déployés dans votre environnement. La limitation des Refuser,
autorisés types de ressources peut réduire la complexité et la Désactivé
surface d’attaque de votre environnement, tout en
aidant à gérer les coûts. Les résultats de conformité
s’affichent uniquement pour les ressources non
conformes.
Étapes suivantes
Consultez les définitions intégrées dans le dépôt Azure Policy de GitHub .
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
Concepts de base du réseau virtuel
Qu’est un réseau virtuel (VNet) Azure ?

Un réseau virtuel (VNet) Azure est une représentation de votre propre réseau dans le
cloud. Il s’agit d’un isolement logique du cloud Azure dédié à votre abonnement. Vous
pouvez utiliser des réseaux virtuels pour configurer et gérer des réseaux privés virtuels
(VPN) dans Azure et, éventuellement, lier les réseaux virtuels avec les autres réseaux
virtuels dans Azure ou avec votre infrastructure informatique locale pour créer des
solutions hybrides ou intersite. Chaque réseau virtuel que vous créez dispose de son
propre bloc CIDR et peut être lié à d’autres réseaux virtuels et locaux, dans la mesure où
les blocs CIDR ne se chevauchent pas. Vous pouvez également contrôler les paramètres
de serveur DNS pour les réseaux virtuels et la segmentation du réseau virtuel en sous-
réseaux.
Utilisez les réseaux virtuels pour effectuer les actions suivantes :
Créez un réseau virtuel dédié uniquement au cloud privé. Vous n’avez pas toujours
besoin d’une configuration intersite pour votre solution. Lorsque vous créez un
réseau virtuel, vos services et les machines virtuelles au sein de votre réseau virtuel
peuvent communiquer directement et en toute sécurité dans le cloud. Vous
pouvez encore configurer des connexions au point de terminaison pour les
machines virtuelles et les services qui requièrent une communication Internet dans
le cadre de votre solution.
Étendez votre centre de données en toute sécurité. Avec les réseaux virtuels, vous
pouvez créer des VPN site à site (S2S) traditionnels pour faire évoluer en toute
sécurité la capacité de votre centre de données. Les VPN S2S utilisent le protocole
IPSEC pour fournir une connexion sécurisée entre votre passerelle VPN d’entreprise
et Azure.
Activez les scénarios de cloud hybride. Les réseaux virtuels vous donnent la
possibilité de prendre en charge une variété de scénarios de nuage hybride. Vous
pouvez connecter en toute sécurité des applications informatiques à n’importe
quel type de système local, comme les ordinateurs centraux et les systèmes Unix.
Comment faire pour démarrer ?
Consultez la Documentation Réseau virtuel pour commencer. Ce document fournit des
informations de présentation et de déploiement pour toutes les fonctionnalités du
réseau virtuel.
Puis-je utiliser des réseaux virtuels sans connectivité

intersite ?
Oui. Vous pouvez utiliser un réseau virtuel sans connexion à votre site. Par exemple,
vous pouvez exécuter des contrôleurs de domaine Microsoft Windows Server Active
Directory et des batteries de serveurs SharePoint dans un réseau virtuel Azure.
Puis-je exécuter une optimisation WAN entre des réseaux

virtuels ou entre un réseau virtuel et mon centre de
données local ?
Oui. Vous pouvez déployer une appliance virtuelle réseau d’optimisation WAN à partir
de plusieurs fournisseurs via Azure Marketplace.
Configuration
Quels outils utiliser pour créer un réseau virtuel ?

Vous pouvez utiliser les outils suivants pour créer ou configurer un réseau virtuel :
Portail Azure
PowerShell
Azure CLI
Fichier de configuration réseau (netcfg - pour les réseaux virtuels classiques
uniquement). Consultez l’article Configurer un réseau virtuel à l’aide d’un fichier de
configuration réseau.
Quelles plages d’adresses puis-je utiliser dans mes

réseaux virtuels ?
Nous vous recommandons d’utiliser les plages d’adresses énumérées dans RFC 1918 ,
qui ont été mis de côté par l’IETF pour les espaces d’adressage privés et non routables :
10.0.0.0 - 10.255.255.255 (préfixe 10/8)
172.16.0.0 – 172.31.255.255 (préfixe 172.16/12)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Vous pouvez également déployer l’espace d’adressage partagé réservé dans le

document RFC 6598 , qui est traité comme un espace d’adressage IP privé dans Azure :
100.64.0.0 - 100.127.255.255 (100.64/10 préfixe)
D’autres espaces d’adressage, y compris tous les autres espaces d’adressage privés et
non routables reconnus par IETF, peuvent fonctionner, mais ils peuvent avoir des effets
secondaires indésirables.
En outre, vous ne pouvez pas ajouter les plages d’adresses suivantes :
255.255.255.255/32 (diffusion)
127.0.0.0/8 (bouclage)
169.254.0.0/16 (lien-local)
168.63.129.16/32 (DNS interne)
Puis-je avoir des adresses IP publiques dans mes réseaux

virtuels ?
Oui. Pour plus d’informations sur les plages d’adresses IP publiques, consultez Create a
virtual network (Créer un réseau virtuel). Les adresses IP publiques ne sont pas
directement accessibles à partir d’Internet.
Y a-t-il une limite au nombre de sous-réseaux dans mon

réseau virtuel ?
Oui. Pour plus d’informations, consultez Limites de mise en réseau. Les espaces
d’adressage de sous-réseau ne peuvent pas se chevaucher.
Existe-t-il des restrictions sur l’utilisation des adresses IP

au sein de ces sous-réseaux ?
Oui. Azure réserve les quatre premières et la dernière adresse IP pour un total de cinq
adresses IP au sein de chaque sous-réseau.
Par exemple, la plage d’adresses IP 192.168.1.0/24 a les adresses réservées suivantes :

192.168.1.0 : adresse réseau
192.168.1.1 : réservée par Azure pour la passerelle par défaut
192.168.1.2, 192.168.1.3 : réservées par Azure pour mapper les adresses IP Azure
DNS à l’espace du réseau virtuel
192.168.1.255 : adresse de diffusion réseau
Quelle taille peuvent avoir les réseaux virtuels et les sous-

réseaux ?
Le plus petit sous-réseau IPv4 pris en charge est /29 et le plus grand est /2 (à l’aide des
définitions de sous-réseaux CIDR). La taille des sous-réseaux IPv6 doit être exactement
de /64.
Puis-je ajouter mes VLAN à Azure à l’aide de réseaux

virtuels ?
Non. Les réseaux virtuels sont des superpositions de couche 3. Azure ne prend en
charge aucune sémantique de couche 2.
Puis-je spécifier des stratégies de routage personnalisées

sur des réseaux virtuels et des sous-réseaux ?
Oui. Vous pouvez créer une table de routage et l’associer à un sous-réseau. Pour plus
d’informations sur le routage dans Azure, consultez Routage du trafic de réseau virtuel.
Quel serait le comportement quand j’applique à la fois un

groupe de sécurité réseau et un itinéraire défini par
l’utilisateur sur le sous-réseau ?
Pour le trafic entrant, les règles de trafic entrant du groupe de sécurité réseau sont
traitées. Pour le trafic sortant, les règles de trafic sortant du groupe de sécurité réseau
sont traitées, puis viennent les règles UDR.
Quel serait le comportement quand j’applique un groupe

de sécurité réseau à la carte réseau et au sous-réseau
pour une machine virtuelle ?
Lorsque des groupes de sécurité réseau sont appliqués à la fois aux sous-réseaux et aux
cartes réseau pour une machine virtuelle, le groupe de sécurité réseau au niveau du
sous-réseau suivi du groupe de sécurité réseau au niveau de la carte réseau est traité
pour le groupe de sécurité réseau de niveau réseau entrant et au niveau de la carte
réseau, suivi du groupe de sécurité réseau au niveau du sous-réseau pour le trafic
sortant.
Les réseaux virtuels prennent-ils en charge la

multidiffusion ou la diffusion ?
Non. La multidiffusion et la diffusion ne sont pas prises en charge.
Quels protocoles puis-je utiliser au sein de réseaux

virtuels ?
Vous pouvez utiliser les protocoles TCP, UDP et ICMP TCP/IP au sein des réseaux virtuels.
La unidiffusion est prise en charge dans les réseaux virtuels. La multidiffusion, la
diffusion, les paquets encapsulés IP dans IP et les paquets Encapsulation générique de
routage (GRE, Generic Routing Encapsulation) sont bloqués dans les réseaux virtuels.
Vous ne pouvez pas utiliser le protocole de configuration dynamique des hôtes (DHCP)
via Monodiffusion (port source UDP/68 / port de destination UDP/67). Port source UDP
65330 réservé à l’hôte. Consultez « Puis-je déployer un serveur DHCP dans un réseau
virtuel » pour plus d’informations sur ce qui est et n’est pas pris en charge pour DHCP.
Puis-je déployer un serveur DHCP dans un réseau virtuel

?
Les réseaux virtuels Azure fournissent le service DHCP et le DNS aux machines virtuelles
et au client/serveur DHCP (port source UDP/68, port de destination UDP/67) non pris en
charge dans un réseau virtuel. Vous ne pouvez pas déployer votre propre service DHCP
pour recevoir et fournir du trafic DHCP client/diffusion en unidiffusion/serveur pour les
points de terminaison au sein d’un VNet. Vous pouvez déployer un serveur DHCP sur
une machine virtuelle avec l’intention de recevoir le trafic DHCP relais DHCP unicast
(port source UDP/67, port de destination UDP/67) DHCP. Un scénario possible consiste
à configurer le relais DHCP à partir d’appareils locaux vers une machine virtuelle Azure
exécutant un serveur DHCP. Le client est responsable de la configuration des appareils
locaux (par exemple, la configuration du routeur) pour créer ce trafic de relais DHCP vers
l’adresse IP de la machine virtuelle dans Azure.
Puis-je effectuer un test Ping sur la passerelle par défaut

au sein d’un réseau virtuel ?
Non. La passerelle par défaut fournie par Azure ne répond pas à un test Ping. Toutefois,
vous pouvez utiliser un test Ping dans vos réseaux virtuels pour vérifier la connectivité et
la résolution des problèmes entre les machines virtuelles.
Puis-je utiliser l’application tracert pour diagnostiquer la

connectivité ?
Oui.
Puis-je ajouter des sous-réseaux après avoir créé le

réseau virtuel ?
Oui. Des sous-réseaux peuvent être ajoutés à des réseaux virtuels à tout moment, tant
que la plage d’adresses de sous-réseau ne fait pas partie d’un autre sous-réseau et qu’il
reste de l’espace dans la plage d’adresses du réseau virtuel.
Puis-je modifier la taille de mon sous-réseau après sa

création ?
Oui. Vous pouvez ajouter, supprimer, développer ou réduire un sous-réseau si aucune
machine virtuelle ou aucun service n’y est déployé.
Puis-je modifier un Vnet après sa création ?

Oui. Vous pouvez ajouter, supprimer et modifier les blocs CIDR utilisés par un réseau
virtuel.
Si j’exécute mes services dans un réseau virtuel, puis-je

me connecter à Internet ?
Oui. Tous les services déployés au sein d’un réseau virtuel peuvent être connectés en
sortie à Internet. Pour en savoir plus sur les connexions Internet sortantes dans Azure,
consultez Connexions sortantes dans Azure. Si vous souhaitez vous connecter en entrée
à une ressource déployée par le biais de Resource Manager, la ressource doit avoir une
adresse IP publique qui lui est affectée. Pour en savoir plus sur les adresses IP publiques,
consultez Adresses IP publiques. Chaque service cloud Azure déployé dans Azure
dispose d’une adresse IP virtuelle publiquement adressable qui lui est assignée. Vous
définissez des points de terminaison d’entrée pour les points de terminaison et les rôles
PaaS des machines virtuelles afin de permettre à ces services d’accepter les connexions à
partir d’Internet.
Les réseaux virtuels prennent-ils en charge IPv6 ?

Oui, les réseaux virtuels peuvent être IPv4 seulement ou à double pile (IPv4 + IPv6). Pour
plus d’informations, consultez Aperçu du protocole IPv6 pour des réseaux virtuels Azure.
Un réseau virtuel peut-il couvrir plusieurs régions ?

Non. Un réseau virtuel est limité à une seule région. Un réseau virtuel peut toutefois
couvrir des zones de disponibilité. Pour en savoir plus sur les zones de disponibilité,
consultez Vue d’ensemble de zones de disponibilité. Vous pouvez connecter des réseaux
virtuels dans différentes régions à l’aide d’un peering de réseaux virtuels. Pour plus
d’informations, consultez Peering de réseaux virtuels
Puis-je connecter un réseau virtuel à un autre réseau

virtuel dans Azure ?
Oui. Vous pouvez connecter un réseau virtuel à un autre réseau virtuel à l’aide des
éléments suivants :
Peering de réseaux virtuels : Pour plus d’informations, consultez Présentation du

peering de réseaux virtuels
Une passerelle VPN Azure : Pour en savoir plus, consultez Configurer une
connexion de réseau virtuel à réseau virtuel.
Résolution de noms pour les machines

virtuelles et les instances de rôle
Quelles sont les options DNS pour les réseaux virtuels ?

Utilisez la table des décisions sur la page Résolution de noms pour les machines
virtuelles et les instances de rôle pour plus informations sur les options DNS disponibles.
Puis-je spécifier des serveurs DNS pour un réseau

virtuel ?
Oui. Vous pouvez spécifier des adresses IP de serveur DNS dans les paramètres de
réseau virtuel. Le paramètre est appliqué en tant que serveur DNS par défaut pour
toutes les machines virtuelles du réseau virtuel.
Combien de serveurs DNS puis-je spécifier ?

Reportez-vous aux limites de mise en réseau.
Puis-je modifier mes serveurs DNS une fois que le réseau

créé ?
Oui. Vous pouvez modifier la liste des serveurs DNS de votre réseau virtuel à tout
moment. Si vous modifiez votre liste de serveurs DNS, vous devez effectuer un
renouvellement de bail DHCP sur toutes les machines virtuelles affectées dans le réseau
virtuel, pour que les nouveaux paramètres DNS prennent effet. Pour les machines
virtuelles exécutant le système d’exploitation Windows, vous pouvez taper ipconfig
/renew directement sur la machine virtuelle. Pour les autres types de système
d’exploitation, reportez-vous à la documentation de renouvellement du bail DHCP pour

le type de système d’exploitation spécifique.
Qu’est ce qu’un serveur DNS fourni par Azure et

fonctionne-t-il avec les réseaux virtuels ?
Le serveur DNS fourni par Azure est un serveur DNS mutualisé proposé par Microsoft.
Azure enregistre toutes vos machines virtuelles et instances de rôle de service cloud
dans ce service. Ce service fournit la résolution de noms par nom d’hôte pour les
machines virtuelles et les instances de rôles contenues dans le même service cloud et
par nom de domaine complet pour les machines virtuelles et les instances de rôle du
même réseau virtuel. Pour en savoir plus sur DNS, consultez Résolution de noms pour
les machines virtuelles et les instances de rôle.
Il existe une limitation aux 100 premiers services cloud du réseau virtuel pour la
résolution de nom inter-clients à l’aide du serveur DNS fourni par Azure. Si vous utilisez
votre propre serveur DNS, cette restriction ne s’applique pas.
Puis-je remplacer mes paramètres DNS sur une base

machine virtuelle/service cloud ?
Oui. Vous pouvez configurer des serveurs DNS par machine virtuelle ou service cloud
pour remplacer les paramètres réseau par défaut. Toutefois, il est recommandé d’utiliser
autant que possible le DNS à l’échelle du réseau.
Puis-je afficher mon propre suffixe DNS ?

Non. Vous ne pouvez pas spécifier un suffixe DNS personnalisé pour vos réseaux
virtuels.
Connexion aux machines virtuelles
Puis-je déployer des machines virtuelles sur un réseau

virtuel ?
Oui. Toutes les interfaces réseau (NIC) attachées à une machine virtuelle déployée via le
modèle de déploiement Resource Manager doivent être connectées à un réseau virtuel.
Les machines virtuelles déployées via le modèle de déploiement classique peuvent
éventuellement être connectées à un réseau virtuel.
Quels sont les différents types d’adresses IP que je peux

attribuer aux machines virtuelles ?
Privé : attribué à chaque carte réseau sur chaque machine virtuelle. L’adresse est
attribuée à l’aide de la méthode statique ou dynamique. Les adresses IP privées
sont affectées à partir de la plage que vous avez spécifiée dans les paramètres de
sous-réseau de votre réseau virtuel. Les ressources déployées par le biais du
modèle de déploiement classique se voient attribuer des adresses IP privées,
même si elles ne sont pas connectées à un réseau virtuel. Le comportement de la
méthode d’allocation est différent selon qu’une ressource a été déployée avec le
modèle de déploiement classique ou Resource Manager :
Resource Manager : une adresse IP privée attribuée avec la méthode statique
ou dynamique reste associée à une machine virtuelle (Resource Manager)
jusqu’à ce que la ressource soit supprimée. La différence est que vous
sélectionnez l’adresse à attribuer lors de l’utilisation d’une méthode statique, et
Azure choisit quand utiliser la méthode dynamique.
Classique : une adresse IP privée attribuée avec la méthode dynamique peut
changer lorsqu’une machine virtuelle (classique) est redémarrée après avoir été
arrêtée (désallouée). Si vous devez vous assurer que l’adresse IP privée d’une
ressource déployée via le modèle de déploiement classique ne change jamais,
attribuez une adresse IP privée avec la méthode statique.
Public : attribué (facultatif) aux cartes réseau attachées aux machines virtuelles
déployées via le modèle de déploiement Azure Resource Manager. L’adresse peut
être attribuée à l’aide de la méthode d’allocation statique ou dynamique. Toutes
les machines virtuelles et instances de rôle de services cloud déployées via le
modèle de déploiement classique existent au sein d’un service cloud, qui se voit
attribuer une adresse IP virtuelle publique dynamique. Une adresse IP statique
publique, appelée Adresse IP réservée, peut éventuellement être attribuée en tant
qu’adresse IP virtuelle. Vous pouvez attribuer des adresses IP publiques à des
machines virtuelles ou instances de rôle de services cloud individuelles déployées
via le modèle de déploiement classique. Ces adresses sont appelées IP publiques
de niveau d’instance (ILPIP) et peuvent être attribuées de manière dynamique.
Puis-je réserver une adresse IP privée pour une machine

virtuelle que je créerai ultérieurement ?
Non. Vous ne pouvez pas réserver d’adresse IP privée. Si une adresse IP privée est
disponible, elle est affectée à une machine virtuelle ou à une instance de rôle par le
serveur DHCP. La machine virtuelle peut être celle à laquelle vous souhaitez attribuer
l’adresse IP privée. Vous pouvez toutefois modifier l’adresse IP privée d’une machine
virtuelle déjà créée et utiliser n’importe quelle adresse IP privée disponible.
Les adresses IP privées peuvent-elles changer pour les

machines virtuelles d’un réseau virtuel ?
Cela dépend. Si la machine virtuelle a été déployée via Resource Manager, non, et ce,
que l’adresse IP ait été attribuée avec la méthode d’allocation statique ou dynamique. Si
la machine virtuelle a été déployée par le biais du modèle de déploiement classique, les
adresses IP dynamiques peuvent changer quand une machine virtuelle est démarrée
après avoir été arrêtée (désallouée). L’adresse est libérée d’une machine virtuelle
déployée via un modèle de déploiement lorsque la machine virtuelle est supprimée.
Puis-je attribuer manuellement des adresses IP aux cartes

réseau au sein du système d’exploitation de la machine
virtuelle ?
Oui, mais cela n’est pas recommandé, sauf si nécessaire, par exemple lors de
l’affectation de plusieurs adresses IP à une machine virtuelle. Pour plus d’informations,
consultez Ajouter des adresses IP à une machine virtuelle. Si l’adresse IP attribuée à une
carte réseau Azure jointe à une machine virtuelle fait l’objet de modifications et si
l’adresse IP au sein du système d’exploitation de la machine virtuelle est différente, vous
perdez la connectivité à la machine virtuelle.
Si j’arrête un emplacement de déploiement de service

cloud ou si j’arrête une machine virtuelle à partir du
système d’exploitation, que se passe-t-il pour mes
adresses IP ?
Nothing. Les adresses IP (adresse IP virtuelle publique, publique et privée) restent
affectées à la machine virtuelle ou à l’emplacement de déploiement de services cloud.
Puis-je déplacer des machines virtuelles d’un sous-réseau

à un autre dans un réseau virtuel sans redéploiement ?
Oui. Vous trouverez plus d’informations dans l’article Déplacement d’une machine
virtuelle ou d’une instance de rôle vers un autre sous-réseau.
Puis-je configurer une adresse MAC statique pour ma

machine virtuelle ?
Non. Une adresse MAC ne peut pas être configurée de manière statique.
Une fois créée, l’adresse MAC restera-t-elle la même pour

ma machine virtuelle ?
Oui, l’adresse MAC reste la même pour une machine virtuelle déployée via les modèles
de déploiement Resource Manager et classique jusqu’à sa suppression. Auparavant,
l’adresse MAC était libérée si la machine virtuelle était arrêtée (libérée), mais désormais
l’adresse MAC est conservée même lorsque la machine virtuelle est dans l’état libéré.
L’adresse MAC reste assignée à l’interface réseau jusqu’à ce que l’interface réseau soit
supprimée ou que l’adresse IP privée assignée à la configuration IP principale de
l’interface réseau principale soit modifiée.
Puis-je me connecter à Internet à partir d’une machine

virtuelle dans un réseau virtuel ?
Oui. Toutes les machines virtuelles et instances de rôle de services cloud déployés au
sein d’un réseau virtuel peuvent se connecter à Internet.
Services Azure qui se connectent à des réseaux
virtuels
Puis-je utiliser Azure App Service Web Apps avec un

réseau virtuel ?
Oui. Vous pouvez déployer des applications Web à l’intérieur d’un réseau virtuel à l’aide
d’un environnement ASE (App Service Environment). Connectez le serveur principal de
vos applications à vos réseaux virtuels avec la fonction d’intégration au réseau virtuel,
puis verrouillez le trafic entrant vers votre application avec les points de terminaison de
service. Pour plus d’informations, consultez les articles suivants :
Fonctionnalités de mise en réseau App Service

Création d'applications web dans un environnement App Service
Intégrer une application à un réseau virtuel Azure
App Service access restriction (Restrictions d’accès dans App Service)
Puis-je déployer des services cloud avec les rôles web et

de travail (PaaS) dans un réseau virtuel ?
Oui. Vous pouvez déployer (facultatif) des instances de rôle de services cloud dans des
réseaux virtuels. Pour cela, vous spécifiez le nom de réseau virtuel et les mappages
rôle/sous-réseau dans la section de configuration réseau de votre configuration de
service. Il est inutile de mettre à jour vos fichiers binaires.
Puis-je connecter un groupe de machines virtuelles

identiques à un réseau virtuel ?
Oui. Vous devez connecter un groupe de machines virtuelles identiques à un réseau
virtuel.
Existe-t-il une liste complète des services Azure à partir

desquels je peux déployer des ressources dans un réseau
virtuel ?
Oui. Pour plus d’informations, consultez Intégration d’un réseau virtuel pour les services
Azure.
Comment puis-je restreindre l’accès à des ressources PaaS
Azure depuis un réseau virtuel ?
Les ressources déployées via certains services PaaS Azure (comme Stockage Azure et
Azure SQL Database) peuvent restreindre l’accès réseau à un réseau virtuel via
l’utilisation de points de terminaison de service de réseau virtuel ou de Liaison privée
Azure. Pour plus d’informations, consultez Vue d’ensemble des points de terminaison de
service de réseau virtuel, Vue d’ensemble de Liaison privée Azure.
Puis-je faire entrer ou sortir mes services dans les réseaux

virtuels ?
Non. Impossible de faire entrer ou de faire sortir des services dans les réseaux virtuels.
Pour déplacer une ressource vers un autre réseau virtuel, vous devez supprimer et
redéployer la ressource.
Sécurité
Quel est le modèle de sécurité pour les réseaux virtuels ?

Les réseaux virtuels sont isolés les uns des autres, ainsi que des autres services hébergés
dans l’infrastructure Azure. Un réseau virtuel est une délimitation d’approbation.
Puis-je limiter le flux de trafic entrant ou sortant aux

ressources connectées au réseau virtuel ?
Oui. Vous pouvez appliquer des groupes de sécurité réseau à des sous-réseaux
individuels d’un réseau virtuel, à des cartes réseau attachées à un réseau virtuel, ou les
deux.
Puis-je mettre en place un pare-feu entre les ressources

connectées au réseau virtuel ?
Oui. Vous pouvez déployer une appliance virtuelle réseau de pare-feu à partir de
plusieurs fournisseurs via Azure Marketplace.
Existe-t-il des informations sur la sécurisation des réseaux

virtuels ?
Oui. Pour plus d’informations, consultez Présentation de la sécurité réseau Azure.
Les réseaux virtuels stockent-ils des données client ?

Non. Les réseaux virtuels ne stockent aucune donnée client.
Puis-je définir la propriété FlowTimeoutInMinutes pour

un abonnement entier ?
Non. Ce paramétrage doit être défini au niveau du réseau virtuel. Les éléments suivants
peuvent aider à automatiser la définition de cette propriété pour des abonnements plus
volumineux :
Powershell
$Allvnet = Get-AzVirtualNetwork
$time = 4 #The value should be between 4 and 30 minutes (inclusive) to
enable tracking, or null to disable tracking. $null to disable.
ForEach ($vnet in $Allvnet)
{
$vnet.FlowTimeoutInMinutes = $time
$vnet | Set-AzVirtualNetwork
}
API, schémas et outils
Puis-je gérer les réseaux virtuels à partir du code ?

Oui. Vous pouvez utiliser des API REST pour les réseaux virtuels dans les modèles de
déploiement Azure Resource Manager et classique.
Existe-t-il une prise en charge des outils pour les réseaux

virtuels ?
Oui. En savoir plus sur l’utilisation des éléments suivants :
Le portail Azure pour déployer des réseaux virtuels via les modèles de déploiement
Azure Resource Manager et classique.
PowerShell pour gérer les réseaux virtuels déployés via les modèles de
déploiement Resource Manager et classique.
Azure CLI ou Azure Classic CLI pour déployer et gérer les réseaux virtuels déployés
via les modèles de déploiement Resource Manager et classique.
Peering de réseaux virtuels
En quoi consiste le peering VNet ?

Le peering VNet (ou peering de réseau virtuel) permet de connecter des réseaux virtuels.
Une connexion de peering VNet entre réseaux virtuels vous permet d’acheminer le trafic
entre eux de façon privée par le biais d’adresses IPv4. Les machines virtuelles dans les
réseaux virtuels appairés peuvent communiquer entre elles comme si elles se trouvaient
dans le même réseau. Ces réseaux virtuels peuvent se situer dans la même région ou
dans des régions différentes (Global VNet Peering). Il est également possible de créer
des connexions de peering VNet dans les abonnements Azure.
Puis-je créer une connexion de peering pour un réseau

virtuel dans une autre région ?
Oui. Global VNet Peering vous permet d’homologuer des réseaux virtuels dans
différentes régions. Global VNet Peering est disponible dans toutes les régions
publiques Azure, dans les régions cloud de Chine et dans les régions cloud Government.
Vous ne pouvez pas procéder au peering mondial à partir de régions publiques Azure
vers des régions cloud nationales.
Quelles sont les contraintes liées aux équilibreurs de

charge et à Global VNet Peering ?
Si les deux réseaux virtuels dans deux régions différentes sont associés sur le Peering de
réseaux virtuels globaux, vous ne pouvez pas vous connecter aux ressources qui se
trouvent derrière un Load Balancer de base par le biais de l’adresse IP frontale du Load
Balancer. Cette restriction n’existe pas pour un Standard Load Balancer. Les ressources
suivantes peuvent utiliser des Load Balancers de base, ce qui signifie que vous ne
pouvez pas les atteindre via l’adresse IP frontale du Load Balancer sur le peering de
réseaux virtuels globaux. Toutefois, vous pouvez utiliser le peering de réseaux virtuels
globaux pour atteindre les ressources directement par le biais de leurs adresses IP de
réseau virtuel privé, si cela est autorisé.
Machines virtuelles sur lesquelles reposent les équilibreurs de charge de base

Groupes de machines virtuelles identiques avec des équilibreurs de charge de base
Cache Redis
Référence SKU Application Gateway (v1)
Service Fabric
Gestion des API (stv1)
Active Directory Domain Services (ADDS)
Logic Apps
HDInsight
Azure Batch
Environnement App Service
Vous pouvez vous connecter à ces ressources via ExpressRoute ou une connexion entre
deux réseaux virtuels, par l’intermédiaire de passerelles de réseau virtuel.
Puis-je activer le peering de réseau virtuel si mes réseaux

virtuels font partie d’abonnements de différents
locataires Azure Active Directory ?
Oui. Il est possible d’établir un peering de réseau virtuel (local ou global) si vos
abonnements appartiennent à différents locataires Azure Active Directory. Vous pouvez
faire cela via le portail, PowerShell ou Azure CLI.
Ma connexion de peering de réseau est à l’état initié,

pourquoi ne puis-je pas me connecter ?
Si votre connexion de peering est dans un état Initiée, cela signifie que vous n’avez créé
qu’un seul lien. Un lien bidirectionnel doit être créé afin d’établir une connexion réussie.
Par exemple, pour homologuer le réseau virtuel A au réseau virtuel B, un lien doit être
créé de VNetA à VNetB et de VNetB à VNetA. La création des deux liens modifie l’état à
Connecté.
Ma connexion de peering VNet se trouve dans l’état

Déconnecté, pourquoi ne puis-je pas créer une connexion
de peering ?
Si votre connexion de peering VNet se trouve dans un état Déconnecté, cela signifie
qu’un des liens créés a été supprimé. Pour rétablir une connexion de peering, vous
devrez supprimer le lien et le créer de nouveau.
Puis-je homologuer mon réseau virtuel avec un réseau
virtuel dans un autre abonnement ?
Oui. Vous pouvez homologuer des réseaux virtuels entre des abonnements et régions.
Puis-je homologuer deux réseaux virtuels avec des plages

d’adresses correspondantes ou se chevauchant ?
Non. Les espaces d’adresses ne doivent pas se chevaucher pour pouvoir activer le
peering de réseau virtuel.
Puis-je appairer un réseau virtuel à deux réseaux virtuels

différents avec l’option « Utiliser la passerelle à distance »
activée sur les deux peerings ?
Non. Vous ne pouvez activer l’option « Utiliser la passerelle à distance » que sur un
peering avec l’un des réseaux virtuels.
Combien coûtent les liens de peering de réseau virtuel ?

Il n’existe aucun frais pour créer une connexion de peering de réseau virtuel. Le transfert
de données entre des connexions de peering est facturé. Voir ici .
Le trafic de peering de réseau virtuel est-il chiffré ?

Lorsque le trafic Azure se déplace entre des centres de données (hors limites physiques
non contrôlées par Microsoft ou pour le compte de Microsoft), le chiffrement de la
couche de liaison de données MACsec est utilisé sur le matériel réseau sous-jacent. Cela
s’applique au trafic de peering de réseaux virtuels.
Pourquoi ma connexion de peering est-elle dans un état

Déconnecté ?
Les connexions de peering de réseau virtuel passent à l’état Déconnecté lorsqu’un lien
de peering de réseau virtuel est supprimé. Vous devez supprimer les deux liens pour
pouvoir rétablir une connexion de peering.
Si j’effectue une homologation entre VNetA et VNetB, et

que je dois également le faire entre VNetB et VNetC, cela
signifie-il que VNetA et VNetC sont homologués ?
Non. Le peering transitif n’est pas pris en charge. Pour qu’ils le soient, vous devez
homologuer VNetA et VNetC.
Des restrictions de bande passante s’appliquent-elles aux

connexions de peering ?
Non. Le peering de réseau virtuel, qu’il soit local ou global, n’impose aucune restriction
de bande passante. La bande passante n’est limitée que par les ressources de la
machine virtuelle ou de calcul.
Comment résoudre les problèmes liés à VNet Peering ?

Voici un guide sur un utilitaire de résolution des problèmes qui peut vous y aider.
TAP de réseau virtuel
Quelles régions Azure sont disponibles pour le TAP de

réseau virtuel ?
La préversion du TAP de réseau virtuel est disponible dans toutes les régions Azure. Les
interfaces réseau supervisées, la ressource TAP de réseau virtuel, ainsi que la solution du
collecteur ou d’analyse doivent être déployées dans la même région.
Le TAP de réseau virtuel prend-il en charge des

fonctionnalités de filtrage sur les paquets mis en miroir ?
Les fonctionnalités de filtrage ne sont pas prises en charge avec la préversion du TAP de
réseau virtuel. Quand une configuration TAP est ajoutée à une interface réseau, une
copie complète de tout le trafic entrant et sortant sur l’interface réseau est diffusée en
continu vers la destination TAP.
Est-il possible d’ajouter plusieurs configurations TAP à

une interface réseau supervisée ?
Une interface réseau supervisée ne peut avoir qu’une seule configuration TAP. Vérifiez
auprès de la solution de partenaire individuelle si elle dispose de la capacité à diffuser
en continu plusieurs copies du trafic TAP vers les outils d’analytique de votre choix.
La même ressource TAP de réseau virtuel peut-elle
agréger le trafic en provenance d’interfaces réseau
supervisées dans plusieurs réseaux virtuels ?
Oui. La même ressource TAP de réseau virtuel peut être utilisée pour agréger le trafic
mis en miroir en provenance d’interfaces réseau supervisées dans des réseaux virtuels
appairés du même abonnement ou d’un autre abonnement. La ressource TAP de réseau
virtuel et l’équilibreur de charge de destination ou l’interface réseau de destination
doivent se trouver dans le même abonnement. Tous les abonnements doivent se trouver
sous le même locataire Azure Active Directory.
Existe-t-il des considérations relatives aux performances

sur le trafic de production si j’active une configuration
TAP de réseau virtuel sur une interface réseau ?
Le TAP de réseau virtuel est disponible en préversion. Pendant la période de préversion,
il n’existe aucun contrat de niveau de service. La fonctionnalité ne doit pas être utilisée
pour des charges de travail de production. Quand une interface réseau de machine
virtuelle est activée avec une configuration TAP, les mêmes ressources sur l’hôte Azure
allouées à la machine virtuelle pour envoyer le trafic de production sont utilisées pour
exécuter la fonction de mise en miroir et envoyer les paquets mis en miroir. Sélectionnez
la taille de machine virtuelle Linux ou Windows appropriée pour garantir que
suffisamment de ressources sont disponibles pour que la machine virtuelle envoie le
trafic de production et le trafic mis en miroir.
La mise en réseau accélérée pour Linux ou Windows est-

elle prise en charge avec le TAP de réseau virtuel ?
Vous pourrez ajouter une configuration TAP sur une interface réseau attachée à une
machine virtuelle activée avec la mise en réseau accélérée. Mais l’ajout de la
configuration TAP affecte les performances et la latence sur la machine virtuelle, car le
déchargement pour la mise en miroir du trafic n’est actuellement pas prise en charge
par la mise en réseau accélérée Azure.
Points de terminaison de service de réseau

virtuel
Dans quel ordre faut-il effectuer les opérations pour
configurer les points de terminaison d’un service Azure ?
La sécurisation d’une ressource de service Azure avec des points de terminaison de
service s’effectue en deux étapes :
1. Activez les points de terminaison du service Azure.

2. Configurez les ACL de réseau virtuel sur le service Azure.
La première étape est une opération qui s’effectue côté réseau et la deuxième côté
ressources de service. Ces deux étapes peuvent être effectuées par le même
administrateur ou par des administrateurs différents en fonction des autorisations Azure
RBAC accordées au rôle d’administrateur. Nous vous recommandons d’activer les points
de terminaison de service pour votre réseau virtuel avant de configurer les ACL du
réseau virtuel côté service Azure. Ces étapes doivent donc être effectuées dans l’ordre
indiqué ci-dessus pour configurer les points de terminaison de service de réseau virtuel.
７ Notes
Vous ne pouvez pas limiter l’accès au service Azure au réseau virtuel et sous-réseau
autorisés avant d’avoir effectué les deux opérations ci-dessus. La simple activation
des points de terminaison du service Azure côté réseau ne vous permet pas de
définir un accès limité. En outre, vous devez également configurer les ACL du
réseau virtuel côté service Azure.
Certains services (comme Azure SQL et Azure Cosmos DB) autorisent des exceptions à la
séquence ci-dessus avec l’indicateur IgnoreMissingVnetServiceEndpoint . Une fois
l’indicateur défini sur True , les ACL du réseau virtuel peuvent être définies côté service
Azure avant la configuration des points de terminaison de service côté réseau. Les
services Azure fournissent cet indicateur pour aider les clients lorsque des pare-feu IP
spécifiques sont configurés sur les services Azure et que l’activation des points de
terminaison de service côté réseau peut entraîner une baisse de connectivité, car
l’adresse IP source passe d’une adresse IPv4 publique à une adresse privée. La
configuration des ACL du réseau virtuel sur le service Azure avant la définition des
points de terminaison de service côté réseau peut éviter une baisse de connectivité.
Tous les services Azure résident-ils sur le réseau virtuel

Azure fourni par le client ? Comment le point de
terminaison de service du réseau virtuel fonctionne-t-il
avec les services Azure ?
Non, tous les services Azure ne résident pas sur le réseau virtuel du client. La majorité
des services de données Azure comme le Stockage Azure, Azure SQL et Azure Cosmos
DB sont des services mutualisés qui sont accessibles par le biais d’adresses IP publiques.
Vous pouvez en savoir plus sur l’intégration d’un réseau virtuel pour les services Azure
ici.
Lorsque vous utilisez la fonctionnalité de points de terminaison de service de réseau

virtuel (activation du point de terminaison de service du réseau virtuel côté réseau et
configuration des ACL de réseau virtuel appropriées côté service Azure), l’accès à un
service Azure est restreint au réseau virtuel et sous-réseau autorisés.
Comment le point de terminaison de service de réseau

virtuel garantit-il la sécurité ?
La fonctionnalité de point de terminaison de service de réseau virtuel (activation du
point de terminaison de service du réseau virtuel côté réseau et configuration des ACL
de réseau virtuel appropriées côté service Azure) limite l’accès au service Azure au
réseau virtuel et au sous-réseau autorisés, assurant la sécurité et l’isolation du trafic du
service Azure au niveau du réseau. Tout le trafic utilisant les points de terminaison de
réseau virtuel traverse le segment principal Microsoft, ce qui offre une couche
supplémentaire permettant de l’isoler de l’Internet public. En outre, les clients peuvent
choisir de supprimer complètement un accès à l’Internet public aux ressources de
service Azure et d’autoriser le trafic uniquement à partir de leur réseau virtuel via une
combinaison de pare-feu IP et d’ACL de réseau virtuel, protégeant ainsi les ressources
de service Azure contre un accès non autorisé.
Quels éléments le point de terminaison de service du

réseau virtuel protège-t-il ? Les ressources du réseau
virtuel ou le service Azure ?
Les points de terminaison de service de réseau virtuel permettent de protéger les
ressources de service Azure. Les ressources de réseau virtuel sont protégées via les
groupes de sécurité réseau (NSG).
Quel est le coût d’utilisation des points de terminaison de

service de réseau virtuel ?
Aucun. L’utilisation des points de terminaison de service de réseau virtuel n’entraîne
aucuns frais supplémentaires.
Puis-je activer les points de terminaison de service de
réseau virtuel et définir des ACL de réseau virtuel si le
réseau virtuel et les ressources de service Azure
appartiennent à différents abonnements ?
Oui, vous pouvez. Les réseaux virtuels et les ressources du service Azure peuvent être
dans des abonnements identiques ou différents. La seule condition est que le réseau
virtuel et les ressources de service Azure se trouvent sous le même client Active
Directory (AD).
Puis-je activer les points de terminaison de service de

réseau virtuel et définir des ACL de réseau virtuel si le
réseau virtuel et les ressources de service Azure
appartiennent à différents clients AD ?
Oui, c’est possible si vous utilisez des points de terminaison de service pour le service
Stockage Azure et Azure Key Vault. Pour les autres services, les points de terminaison de
service de réseau virtuel et les ACL de réseau virtuel ne sont pas pris en charge sur des
clients AD distincts.
L’adresse IP d’un appareil local connecté par le biais de la

passerelle ExpressRoute ou de la passerelle Réseau virtuel
Azure (VPN) peut-elle accéder au service Azure PaaS via
des points de terminaison de service de réseau virtuel ?
Par défaut, les ressources du service Azure sécurisées pour des réseaux virtuels ne sont
pas accessibles à partir des réseaux locaux. Si vous souhaitez autoriser le trafic depuis un
réseau local, vous devez également autoriser les adresses IP publiques (généralement
NAT) à partir de vos circuits locaux ou ExpressRoute. Ces adresses IP peuvent être
ajoutées via la configuration du pare-feu IP des ressources du service Azure.
Puis-je utiliser la fonctionnalité de point de terminaison

de service de réseau virtuel pour sécuriser un service
Azure pour plusieurs sous-réseaux au sein d’un réseau
virtuel ou sur plusieurs réseaux virtuels ?
Pour sécuriser les services Azure pour plusieurs sous-réseaux au sein d’un réseau virtuel
ou sur plusieurs réseaux virtuels, activez les points de terminaison de service côté réseau
sur chacun des sous-réseaux indépendamment et sécurisez les ressources de service
Azure pour l’ensemble des sous-réseaux en configurant les ACL de réseau virtuel
appropriées côté service Azure.
Comment puis-je filtrer le trafic sortant d’un réseau

virtuel vers les services Azure en continuant d’utiliser les
points de terminaison de service ?
Si vous souhaitez inspecter ou filtrer le trafic destiné à un service Azure à partir d’un
réseau virtuel, vous pouvez déployer une appliance virtuelle réseau au sein du réseau
virtuel. Vous pouvez ensuite appliquer des points de terminaison de service au sous-
réseau sur lequel est déployée l’appliance virtuelle réseau et sécuriser les ressources de
service Azure uniquement pour ce sous-réseau via des ACL de réseau virtuel. Ce
scénario peut également être utile si vous souhaitez restreindre l’accès aux services
Azure à partir de votre réseau virtuel uniquement pour des ressources Azure spécifiques,
à l’aide du filtrage de l’appliance virtuelle réseau. Pour plus d’informations, consultez la
section relative à la sortie avec les appliances virtuelles réseau.
Que se passe-t-il quand vous accédez à un compte de

service Azure qui a une ACL de réseau virtuel activée à
partir d’un emplacement extérieur au réseau virtuel ?
L’erreur HTTP 403 ou HTTP 404 est retournée.
Les sous-réseaux d’un réseau virtuel créés dans des

régions différentes sont-ils autorisés à accéder à un
compte de service Azure dans une autre région ?
Oui, pour la plupart des services Azure, les réseaux virtuels créés dans différentes
régions peuvent accéder aux services Azure dans une autre région via les points de
terminaison de service de réseau virtuel. Par exemple, si un compte Azure Cosmos DB se
trouve dans la région USA Ouest ou USA Est et si les réseaux virtuels se trouvent dans
plusieurs régions, le réseau virtuel peut accéder à Azure Cosmos DB. Le Stockage et SQL
sont des exceptions, car ils sont régionaux par nature. Le réseau virtuel et le service
Azure doivent se trouver dans la même région.
Un service Azure peut-il avoir une ACL de réseau virtuel

et un pare-feu IP ?
Oui, une ACL de réseau virtuel et un pare-feu IP peuvent coexister. Ces deux
fonctionnalités se complètent pour garantir isolation et sécurité.
Que se passe-t-il si l’on supprime un réseau virtuel ou un

sous-réseau ayant un point de terminaison de service
activé pour le service Azure ?
La suppression des réseaux virtuels et des sous-réseaux est une opération indépendante
prise en charge même lorsque des points de terminaison de service sont activés pour les
services Azure. Quand les services Azure sont configurés avec des ACL de réseau virtuel,
pour les réseaux virtuels et sous-réseaux concernés, les informations des ACL de réseau
virtuel associées à ce service Azure sont désactivées en cas de suppression d’un réseau
virtuel ou sous-réseau disposant d’un point de terminaison de service de réseau virtuel
activé.
Que se passe-t-il si l’on supprime un compte de service

Azure qui a un point de terminaison de service de réseau
virtuel activé ?
La suppression d’un compte de service Azure est une opération indépendante prise en
charge même si le point de terminaison de service est activé côté réseau et que des ACL
de réseau virtuel sont configurées côté service Azure.
Qu’arrive-t-il à l’adresse IP source d’une ressource

(comme une machine virtuelle sur un sous-réseau) ayant
un point de terminaison de service de réseau virtuel
activé ?
Quand des points de terminaison de service de réseau virtuel sont activés, les adresses
IP sources des ressources du sous-réseau de votre réseau virtuel n’utilisent plus des
adresses IPV4 publiques mais des adresses IP privées sur le réseau virtuel Azure pour le
trafic vers le service Azure. Notez que cela peut entraîner la panne de pare-feux IP
spécifiques préalablement configurés sur une adresse IPV4 publique sur les services
Azure.
La route du point de terminaison de service est-elle

toujours prioritaire ?
Les points de terminaison de service ajoutent une route système prioritaire sur les
routes BGP et offrent un routage optimal pour le trafic de point de terminaison de
service. Les points de terminaison de service acheminent toujours le trafic de service
directement à partir de votre réseau virtuel vers le service sur le réseau principal de
Microsoft Azure. Pour en savoir plus sur la façon dont Azure sélectionne un itinéraire,
voir Routage du trafic de réseau virtuel Azure.
Les points de terminaison de service fonctionnent-ils avec

le protocole ICMP (Internet Control Message Protocol) ?
Non, le trafic ICMP qui provient d’un sous-réseau dont les points de terminaison de
service sont activés ne prendra pas le chemin du tunnel de service vers le point de
terminaison souhaité. Les points de terminaison de service ne traitent que le trafic TCP.
Cela signifie que si vous souhaitez tester la latence ou la connectivité d’un point de
terminaison via des points de terminaison de service, des outils tels que ping et tracert
ne montreront pas le véritable chemin que les ressources du sous-réseau emprunteront.
Comment le groupe de sécurité réseau d’un sous-réseau

fonctionne-t-il avec les points de terminaison de service ?
Pour atteindre le service Azure, les groupes de sécurité réseau doivent autoriser la
connectivité sortante. Si vos groupes de sécurité réseau sont ouverts à tout le trafic
Internet sortant, le trafic de point de terminaison de service doit fonctionner. Vous
pouvez également limiter le trafic sortant aux adresses IP de service en utilisant
uniquement les balises de service.
De quelles autorisations ai-je besoin pour configurer des

points de terminaison de service ?
Les points de terminaison de service peuvent être configurés indépendamment sur un
réseau virtuel par un utilisateur avec accès en écriture au réseau virtuel. Pour sécuriser
les ressources du service Azure pour un réseau virtuel, l’utilisateur doit disposer des
autorisations sur
Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action pour les
sous-réseaux à ajouter. Cette autorisation est incluse par défaut dans le rôle
d’administrateur de service intégré et peut être modifiée en créant des rôles
personnalisés. Apprenez-en davantage sur les rôles intégrés et l’affectation
d’autorisations spécifiques aux rôles personnalisés.
Puis-je filtrer le trafic du réseau virtuel vers les services
Azure, en autorisant uniquement des ressources de
service Azure spécifiques, sur les points de terminaison
de service VNet ?
Les stratégies de points de terminaison de service de réseau virtuel permettent de filtrer
le trafic de réseau virtuel vers les services Azure, en autorisant uniquement des
ressources de service Azure spécifiques, sur les points de terminaison de service. Les
stratégies de points de terminaison fournissent un contrôle d’accès granulaire du trafic
de réseau virtuel vers les services Azure. Plus d’informations sur les stratégies de point
de terminaison de service sont disponibles ici.
Le logiciel Azure Active Directory (Azure AD) prend-il en

charge les points de terminaison de service du réseau
virtuel ?
Azure Active Directory (Azure AD) ne prend pas en charge les points de terminaison de
service en mode natif. La liste complète des services Azure prenant en charge les points
de terminaison de service du réseau virtuel est accessible ici. Notez que la balise
« Microsoft.AzureActiveDirectory » indiquée sous les services prenant en charge les
points de terminaison de service est utilisée pour gérer ces derniers dans ADLS
génération 1. Pour ADLS génération 1, l’intégration au réseau virtuel dans Azure Data
Lake Storage Gen1 fait appel à la sécurité des points de terminaison de service de
réseau virtuel entre votre réseau virtuel et Azure Active Directory (Azure AD) afin de
générer des revendications de sécurité supplémentaires dans le jeton d’accès. Ces
revendications permettent ensuite d’authentifier votre réseau virtuel à votre compte
Data Lake Storage Gen1 et d’y accéder. Découvrir plus d’informations sur l’intégration
de réseau virtuel dans Azure Data Lake Storage Gen1
Le nombre de points de terminaison de service de réseau

virtuel que je peux configurer à partir de mon réseau
virtuel est-il limité ?
Il n’existe aucune limite sur le nombre total de points de terminaison de service de
réseau virtuel dans un réseau virtuel. Pour une ressource de service Azure (par exemple,
un compte de stockage Azure), les services peuvent appliquer des limites sur le nombre
de sous-réseaux utilisés pour la sécurisation de la ressource. Le tableau suivant présente
des exemples des limites qui s’appliquent :
Service Azure Limites sur les règles de réseau virtuel
Stockage Azure 200
Azure SQL 128
Azure Synapse Analytics 128
Azure KeyVault 200
Azure Cosmos DB 64
Azure Event Hub 128
Azure Service Bus 128
Azure Data Lake Store V1 100
７ Notes
Les limites sont sujettes à modifications à la discrétion du service Azure. Reportez-

vous à la documentation correspondante pour en savoir plus sur chaque service.
Migrer des ressources réseau classiques vers

Resource Manager
Qu'est-ce qu’Azure Service Manager et que signifie le

terme classique ?
Azure Service Manager est l'ancien modèle de déploiement d'Azure responsable de la
création, de la gestion et de la suppression des ressources. Le terme classique dans un
service de réseau fait référence aux ressources gérées par le modèle Azure Service
Manager. Pour plus d'informations, consultez Comparaison des modèles de
déploiement.
Qu’est-ce qu’Azure Resource Manager ?

Azure Resource Manager est le dernier modèle de déploiement et de gestion d'Azure
responsable de la création, de la gestion et de la suppression des ressources dans votre
abonnement Azure. Pour plus d’informations, consultez Qu’est-ce qu’Azure Resource
Manager ?.
Puis-je annuler la migration après la validation des
ressources dans Resource Manager ?
Vous pouvez annuler la migration tant que les ressources sont encore en cours de
préparation. Le retour au modèle de déploiement précédent n'est pas possible si les
ressources ont été correctement migrées par l'opération de validation.
Puis-je annuler la migration si l'opération de validation a

échoué ?
Vous ne pouvez pas annuler une migration si l'opération de validation a échoué. Toutes
les opérations de migration, y compris l'opération de validation, ne peuvent être
modifiées une fois lancées. Il est recommandé de réessayer l'opération après une courte
période. Si l'opération continue d'échouer, envoyez une demande de support.
Puis-je vérifier si mon abonnement ou mes ressources

peuvent faire l’objet d’une migration ?
Oui. Dans le cadre de la procédure de migration, la première étape de la préparation de
la migration consiste à vérifier si les ressources peuvent être migrées. En cas d’échec de
l’opération de validation, vous recevrez des messages avec toutes les raisons pour
lesquelles la migration ne peut pas aboutir.
Les ressources Application Gateway sont-elles migrées

dans le cadre de la migration d’un réseau classique vers
un réseau virtuel Resource Manager ?
Les ressources Application Gateway ne seront pas migrées automatiquement dans le
cadre du processus de migration du réseau virtuel. Si elles sont présentes dans le réseau
virtuel, la migration échouera. Pour migrer une ressource Application Gateway vers
Resource Manager, vous devrez supprimer et recréer Application Gateway une fois la
migration terminée.
La passerelle VPN est-elle migrée dans le cadre de la

migration du réseau virtuel classique vers Resource
Manager ?
Les ressources de la passerelle VPN sont migrées dans le cadre du processus de
migration du réseau virtuel. La migration est effectuée un réseau virtuel à la fois, sans
autre exigence. Les étapes de la migration sont les mêmes que pour la migration d'un
réseau virtuel sans passerelle VPN.
Y a-t-il une interruption de service associée à la migration

des passerelles VPN classiques vers Resource Manager ?
Vous ne subirez aucune interruption de service avec votre connexion VPN lors de la
migration vers Resource Manager. Les charges de travail existantes continueront donc
de fonctionner sans perte de connectivité locale durant la migration.
Dois-je reconfigurer mon appareil local après la migration

de la passerelle VPN vers Resource Manager ?
L'adresse IP publique associée à la passerelle VPN restera inchangée, même après la
migration. Vous n'avez pas besoin de reconfigurer votre routeur local.
Quels sont les scénarios pris en charge pour la migration

de la passerelle VPN classique vers Resource Manager ?
La plupart des scénarios de connectivité VPN courants sont couverts par la migration du
modèle Classic vers le modèle Resource Manager. Les scénarios pris en charge sont les
suivants :
Connectivité de point à site
Connectivité site à site avec une passerelle VPN connectée à un emplacement local
Connectivité entre deux réseaux virtuels en utilisant des passerelles VPN
Plusieurs réseaux virtuels connectés à un même emplacement local
Connectivité multisite
Réseaux virtuels avec tunneling forcé
Quels scénarios ne sont pas pris en charge pour la

migration classique de la passerelle VPN vers Resource
Manager ?
Les scénarios qui ne sont pas pris en charge incluent :
Un réseau virtuel avec à la fois une passerelle ExpressRoute et une passerelle VPN
n'est actuellement pas pris en charge.
Un réseau virtuel avec une passerelle ExpressRoute connectée à un circuit dans un

autre abonnement.
Scénarios de transit dans lesquels des extensions de machine virtuelle sont

connectées à des serveurs locaux.
Où puis-je trouver des informations supplémentaires sur

la migration du modèle classique vers Azure Resource
Manager ?
Pour plus d'informations, consultez la FAQ sur la migration classique vers Azure
Resource Manager.
Comment puis-je signaler un problème ?

Vous pouvez poster vos questions sur vos problèmes de migration à la page QA de
Microsoft. Il est recommandé de poser toutes vos questions sur ce forum. Si vous
disposez d’un contrat d'assistance, vous pouvez également déposer une demande de
support.

Azure Virtual Network

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Azure Virtual Network

Transféré par

Droits d'auteur :

Formats disponibles

Parlez-nous de l’expérience de téléchargement de PDF.

Documentation Réseau virtuel

À propos du Réseau virtuel

Présentation du réseau virtuel Azure

FAQ sur le Réseau virtuel

Introduction aux réseaux virtuels Azure

Provisionner une zone d’atterrissage réseau

Provisionner une nouvelle application dans un réseau existant

Provisionner une infrastructure de région Azure secondaire

Implémenter une sécurité réseau Azure

Création d’un réseau virtuel

Créer, modifier ou supprimer un réseau virtuel

Ajouter, changer ou supprimer un sous-réseau

Groupes de sécurité réseau

Groupes de sécurité d’application

Points de terminaison de service de réseau virtuel

FAQ sur la sécurité du réseau virtuel

Accès sortant par défaut

Filtrer le trafic réseau avec des groupes de sécurité réseau

Restreindre l’accès réseau à l’aide de points de terminaison de service

Utiliser des groupes de sécurité d’application

Sécuriser et isoler l’accès aux ressources Azure

Connecter des réseaux virtuels

Peering de réseau virtuel

FAQ sur le peering de réseaux virtuels

Connecter des réseaux virtuels avec le peering de réseaux virtuels

Même mode de déploiement - même abonnement

Même modèle de déploiement - abonnements différents

Modèles de déploiement différents - même abonnement

Modèles de déploiement différents - abonnements différents

Communiquer sur un réseau virtuel avec le peering

Router le trafic réseau avec des tables de routage

Router le trafic réseau - Portail

Créer des adresses IP

Types d’adresses IP et méthodes d’allocation

Créer, modifier ou supprimer une adresse IP publique

Ajouter une adresse IP publique sur une machine virtuelle

Créer une machine virtuelle avec une adresse IP statique

Configurer une adresse IP privée statique pour une machine virtuelle

Attribuer plusieurs adresses IP à une machine virtuelle

Créer un IPv6 pour des réseaux virtuels

Qu’est-ce que le protocole IPv6 pour réseau virtuel Azure ?

Déployer une application double pile IPV6 - Standard Load Balancer

Surveillance des réseaux virtuels

Point d’accès terminal de réseau virtuel (TAP)

FAQ sur le TAP de réseau virtuel

Créer un TAP de réseau virtuel

Gérer les services IP

Types d’adresses IP et méthodes d’allocation

Qu’est-ce que le protocole IPv6 pour réseau virtuel Azure ?

Préfixe d’adresse IP publique

Créer, modifier ou supprimer une adresse IP publique

Déployer une application double pile IPV6

Créer, changer ou supprimer un préfixe d’adresse IP publique

Découvrir l’architecture de réseau virtuel

Conception de l’architecture réseau

Concevoir une infrastructure de réseau dans Azure

Connecter un réseau local à Azure

Implémenter un réseau hybride sécurisé

Topologie réseau hub-and-spoke dans Azure

Scénarios de haute disponibilité et de reprise d’activité pour les applications IaaS

Pourquoi utiliser un réseau virtuel Azure ?

La communication de ressources Azure avec Internet

La communication entre des ressources Azure