Foxency
Wi-Fi, Cloud et Technologies Réseau

Réseaux Azure : VNets, NSG et connectivité

Dans Azure, le réseau virtuel (VNet) est le socle de toute architecture. Sous-réseaux, NSG, routes personnalisées, accès sortant, peering, points de terminaison privés et topologie hub-and-spoke.

Par Rédaction Foxency Publié le 7 min de lecture

Architecture Azure hub-and-spoke avec réseaux virtuels, groupes de sécurité réseau et passerelle VPN

Microsoft Azure organise son réseau autour du Virtual Network (VNet), équivalent du VPC d'AWS. Les principes généraux sont similaires, mais plusieurs différences importantes — sous-réseaux régionaux, filtrage par NSG, routage système implicite, évolutions de l'accès sortant par défaut — méritent d'être comprises pour concevoir correctement.

Objectif : concevoir un réseau Azure sûr et évolutif : VNets et sous-réseaux, filtrage par NSG, routage personnalisé, accès sortant, interconnexion et accès privé aux services. Les concepts communs sont présentés dans Cloud networking : principes et composants.

Les exemples utilisent Azure CLI et la région France Central à titre d'illustration ; les noms de ressources sont fictifs. En production, privilégiez l'infrastructure en tant que code (Bicep, Terraform/OpenTofu). Les fonctionnalités, quotas et tarifs évoluent : consultez la documentation Microsoft Learn.

VNet et sous-réseaux

  • Un VNet appartient à une région et à un abonnement, et dispose d'un ou plusieurs espaces d'adressage (par exemple 10.30.0.0/16).
  • Les sous-réseaux sont régionaux : un sous-réseau couvre toutes les zones de disponibilité de la région (différence notable avec AWS). La répartition entre zones se fait au niveau des ressources (machines virtuelles, groupes identiques) ou de services zonaux.
  • Azure réserve cinq adresses dans chaque sous-réseau : l'adresse réseau, trois adresses pour ses services (passerelle par défaut et DNS) et la dernière.

Certains services exigent des sous-réseaux dédiés avec un nom précis, par exemple GatewaySubnet pour les passerelles VPN et ExpressRoute, AzureFirewallSubnet pour Azure Firewall, AzureBastionSubnet pour Azure Bastion. D'autres services nécessitent une délégation de sous-réseau. Prévoyez ces sous-réseaux dans le plan d'adressage.

az group create --name rg-reseau-prod --location francecentral
az network vnet create --resource-group rg-reseau-prod --name vnet-app-prod \
  --address-prefixes 10.30.0.0/16 --subnet-name snet-web --subnet-prefixes 10.30.1.0/24
az network vnet subnet create --resource-group rg-reseau-prod --vnet-name vnet-app-prod \
  --name snet-app --address-prefixes 10.30.2.0/24
az network vnet subnet create --resource-group rg-reseau-prod --vnet-name vnet-app-prod \
  --name snet-data --address-prefixes 10.30.3.0/24

Le filtrage : NSG et ASG

Network Security Groups

Un NSG (Network Security Group) est un ensemble de règles avec état, associable à un sous-réseau et/ou à une interface réseau.

  • Chaque règle a une priorité (de 100 à 4096) : les règles sont évaluées par priorité croissante, la première correspondance s'applique.
  • Les règles peuvent autoriser ou refuser.
  • Des règles par défaut existent (priorités 65000 et plus) : elles autorisent le trafic interne au VNet (VirtualNetwork) et depuis le répartiteur de charge Azure, et refusent le reste en entrée ; en sortie, elles autorisent Internet. On ne peut pas les supprimer, mais on peut les surcharger par des règles de priorité plus forte.
  • Des balises de service (service tags) désignent des ensembles d'adresses gérés par Microsoft : Internet, VirtualNetwork, AzureLoadBalancer, Storage, Sql…

Si un NSG est associé à la fois au sous-réseau et à l'interface, les deux doivent autoriser le trafic.

Attention à la règle par défaut AllowVnetInBound : elle autorise tout le trafic entre ressources du VNet (et des réseaux appairés ou connectés). Pour segmenter réellement, ajoutez des règles de refus explicites ou des règles précises de priorité plus forte.

Application Security Groups

Les ASG permettent de regrouper des interfaces par rôle (« serveurs web », « serveurs d'application ») et de les utiliser comme source ou destination dans les règles NSG, sans gérer d'adresses IP :

az network asg create -g rg-reseau-prod -n asg-web
az network asg create -g rg-reseau-prod -n asg-app
az network nsg create -g rg-reseau-prod -n nsg-app
az network nsg rule create -g rg-reseau-prod --nsg-name nsg-app -n autoriser-web-vers-app \
  --priority 200 --direction Inbound --access Allow --protocol Tcp \
  --source-asgs asg-web --destination-asgs asg-app --destination-port-ranges 8443
az network nsg rule create -g rg-reseau-prod --nsg-name nsg-app -n refuser-reste-vnet \
  --priority 4000 --direction Inbound --access Deny --protocol '*' \
  --source-address-prefixes VirtualNetwork --destination-address-prefixes '*' --destination-port-ranges '*'
az network vnet subnet update -g rg-reseau-prod --vnet-name vnet-app-prod -n snet-app --network-security-group nsg-app

Pour un filtrage plus avancé (filtrage FQDN, inspection, journalisation centralisée), on ajoute Azure Firewall ou une appliance de pare-feu tierce dans un VNet hub.

Le routage

Azure crée automatiquement des routes système : communication entre sous-réseaux du VNet, vers les réseaux appairés, vers les réseaux sur site appris par la passerelle, et vers Internet.

Pour forcer le trafic à passer par un pare-feu, on crée des routes définies par l'utilisateur (UDR) dans une table de routage associée aux sous-réseaux :

az network route-table create -g rg-reseau-prod -n rt-spoke-app
az network route-table route create -g rg-reseau-prod --route-table-name rt-spoke-app \
  -n defaut-vers-pare-feu --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.1.4
az network vnet subnet update -g rg-reseau-prod --vnet-name vnet-app-prod -n snet-app --route-table rt-spoke-app

Le trafic du sous-réseau vers Internet passe alors par le pare-feu (10.0.1.4). Pensez au trafic de retour et à la symétrie des flux : un routage asymétrique à travers un pare-feu avec état provoque des rejets.

L'accès sortant vers Internet

Historiquement, une machine virtuelle sans adresse publique bénéficiait d'un accès sortant par défaut implicite. Microsoft a annoncé la fin de ce mécanisme pour les nouveaux réseaux virtuels (retrait annoncé pour septembre 2025) et recommande des méthodes explicites :

  • NAT Gateway associée au sous-réseau (méthode recommandée pour l'accès sortant à grande échelle) ;
  • répartiteur de charge avec règles sortantes ;
  • adresse IP publique sur la ressource ;
  • pare-feu (Azure Firewall ou appliance) avec UDR.

Vérifiez la situation de vos sous-réseaux existants et la documentation à jour : définir explicitement l'accès sortant rend aussi l'architecture plus lisible et contrôlable.

Interconnexion

VNet Peering

Le peering relie deux VNets (même région ou régions différentes) par le réseau privé de Microsoft, avec une faible latence. Il est non transitif par défaut. Les options Allow gateway transit et Use remote gateways permettent à un spoke d'utiliser la passerelle VPN ou ExpressRoute du hub.

Hub-and-spoke et Virtual WAN

L'architecture hub-and-spoke est la référence : un VNet hub contient la connectivité vers le site (passerelle VPN ou ExpressRoute), le pare-feu, Azure Bastion et les services partagés ; les VNets applicatifs (spokes) y sont appairés. Azure Virtual WAN propose une version managée de ce modèle, adaptée aux grands déploiements multi-régions et multi-sites.

L'accès privé aux services PaaS

  • Private Endpoint : une interface réseau privée dans votre sous-réseau donne accès à une instance précise d'un service (compte de stockage, base Azure SQL, Key Vault) via une adresse privée. Il faut configurer le DNS privé (zones privatelink.*) pour que le nom du service se résolve vers l'adresse privée.
  • Service Endpoint : étend l'identité du sous-réseau vers le service, qui peut alors restreindre l'accès à ce sous-réseau ; le trafic reste sur le réseau Microsoft, mais le service conserve une adresse publique.

Le Private Endpoint est généralement préféré pour les données sensibles, combiné à la désactivation de l'accès public du service.

Accès d'administration

Azure Bastion fournit un accès RDP/SSH aux machines virtuelles depuis le portail ou le client natif, sans adresse publique ni port ouvert sur les machines. Alternative : accès via VPN ou ExpressRoute depuis le réseau d'administration. Évitez les règles NSG autorisant 3389 ou 22 depuis Internet.

Observer et diagnostiquer

  • Network Watcher : vérification de flux IP (IP flow verify), prochain saut (next hop), règles effectives, diagnostic de connexion, capture de paquets.
  • Journaux de flux : Microsoft fait évoluer les journaux de flux NSG vers les journaux de flux de réseau virtuel (VNet flow logs) ; consultez la documentation pour la méthode recommandée.
az network nic list-effective-nsg -g rg-reseau-prod -n nic-vm-app01
az network watcher test-ip-flow -g rg-reseau-prod --vm vm-app01 --direction Inbound \
  --protocol TCP --local 10.30.2.4:8443 --remote 10.30.1.5:50000

Erreurs courantes

  • Compter sur AllowVnetInBound et croire les sous-réseaux isolés entre eux.
  • Oublier les sous-réseaux dédiés (GatewaySubnet, AzureFirewallSubnet) dans le plan d'adressage.
  • Private Endpoint sans DNS privé, le nom du service continuant à se résoudre vers l'adresse publique.
  • Routage asymétrique à travers un pare-feu.
  • Dépendre de l'accès sortant par défaut au lieu d'une méthode explicite.

Conclusion

Un réseau Azure robuste combine des VNets à l'adressage planifié, des NSG et ASG qui segmentent réellement, des routes personnalisées vers un pare-feu central, un accès sortant explicite, un modèle hub-and-spoke et des points de terminaison privés. Pour relier ce réseau à votre infrastructure, poursuivez avec VPN cloud et connectivité hybride.

Références