Réseaux virtuels et sous-réseaux

Un réseau virtuel Azure (VNet) est un réseau logiquement isolé dans le cloud Azure que vous définissez et contrôlez. Il constitue le composant fondamental de la mise en réseau Azure et permet aux ressources Azure, telles que les machines virtuelles, les bases de données et les services d’application, de communiquer de manière sécurisée entre elles, avec Internet et avec les réseaux locaux. Un VNet est limité à une seule région Azure et à un espace d’adressage CIDR IPv4 spécifique (et éventuellement IPv6) que vous définissez lors de sa création.

Lors de la création d’un VNet, vous attribuez un espace d’adressage à l’aide de la notation CIDR. La notation CIDR (routage inter-domaines sans classe) indique à la fois l’adresse réseau et le nombre de bits utilisés pour le préfixe réseau. Par exemple, 10.0.0.0/16 vous fournit 65 536 adresses IP (de 10.0.0.0 à 10.0.255.255). L’espace d’adressage doit être une plage d’adresses IP privées (10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, conformément à la RFC 1918). Choisissez un espace d’adressage suffisamment grand pour accueillir tous les sous-réseaux prévus et permettre leur extension, mais évitez tout chevauchement avec les réseaux locaux si vous prévoyez une connexion hybride.

Un sous-réseau divise l’espace d’adressage du VNet en segments réseau plus petits. Chaque sous-réseau possède sa propre plage d’adresses IP (un sous-ensemble de l’espace d’adressage du VNet) et peut contenir des ressources de différents types. Les sous-réseaux ont deux fonctions : l’organisation (regrouper les ressources associées) et l’isolation (appliquer des règles de sécurité différentes à différents groupes de ressources). Par exemple, vous pouvez avoir un sous-réseau web-tier (10.0.1.0/24) pour les serveurs web, un sous-réseau app-tier (10.0.2.0/24) pour les serveurs d’applications et un sous-réseau data-tier (10.0.3.0/24) pour les bases de données.

Dans chaque sous-réseau, Azure réserve les quatre premières adresses IP et la dernière adresse IP pour son propre usage. Pour un sous-réseau 10.0.1.0/24 : 10.0.1.0 (adresse réseau), 10.0.1.1 (passerelle par défaut), 10.0.1.2 et 10.0.1.3 (réservées au DNS Azure), et 10.0.1.255 (adresse de diffusion). Il reste donc 251 adresses IP utilisables dans un sous-réseau /24. Tenez compte de cette réservation lors du dimensionnement des sous-réseaux : un sous-réseau /28 ne dispose que de 11 adresses utilisables (16 moins 5 adresses réservées).

Par défaut, les ressources d’un même VNet peuvent communiquer entre elles à l’aide de leurs adresses IP privées, même si elles se trouvent dans des sous-réseaux différents. Aucune configuration supplémentaire n’est nécessaire pour les communications au sein d’un VNet. Les ressources de VNets différents ne peuvent pas communiquer par défaut : vous devez les connecter explicitement à l’aide de l’appairage de réseaux virtuels. Les ressources d’un même sous-réseau partagent le même segment réseau, ce qui fait de leur communication le chemin le plus direct possible au sein de la couche de mise en réseau définie par logiciel d’Azure.

Les VM d’un VNet peuvent par défaut initier des connexions sortantes vers Internet : Azure fournit automatiquement un accès Internet sortant via un service NAT managé. Pour un accès Internet entrant, une ressource doit disposer d’une adresse IP publique attribuée à son interface réseau ou à son équilibreur de charge. Vous contrôlez ensuite l’accès entrant à l’aide de règles de Network Security Group (NSG) afin de préciser exactement quels ports et protocoles sont autorisés. Une architecture courante place les serveurs web dans un sous-réseau public avec des adresses IP publiques, et les serveurs d’applications dans un sous-réseau privé accessible uniquement depuis le niveau web.

Par défaut, Azure gère automatiquement le routage : le trafic entre les sous-réseaux reste au sein du VNet, le trafic Internet sortant est traité par NAT et le trafic destiné aux services Azure utilise le réseau principal Azure. Vous pouvez remplacer ce comportement à l’aide de routes définies par l’utilisateur (UDR) dans une table de routage. Un cas d’utilisation courant consiste à forcer tout le trafic Internet sortant à passer par une appliance réseau virtuelle (NVA) ou un pare-feu Azure dans un VNet hub afin de centraliser l’inspection. Vous créez une table de routage, y ajoutez des entrées de route, puis l’associez à un ou plusieurs sous-réseaux pour l’appliquer.

Certains services Azure — comme Azure App Service (intégration VNet), Azure Kubernetes Service, Azure SQL Managed Instance et Azure Databricks — nécessitent un sous-réseau dédié délégué à ce service. Un sous-réseau délégué signifie qu'Azure peut y injecter, en votre nom, des ressources propres au service (interfaces réseau, adresses IP internes). Vous ne pouvez pas déployer d'autres types de ressources dans un sous-réseau délégué : il est exclusivement réservé à ce service Azure. Lorsque vous prévoyez d'utiliser des services nécessitant une délégation, allouez toujours un sous-réseau dédié disposant d'un espace IP suffisant.

Bonnes pratiques essentielles pour la conception d'un VNet : planifiez votre espace d'adressage avant de créer le VNet — vous ne pourrez pas le modifier sans recréer les ressources. Utilisez des sous-réseaux séparés pour chaque niveau d'application afin d'appliquer des politiques de sécurité distinctes. Évitez les espaces d'adressage qui se chevauchent avec les réseaux locaux si vous prévoyez une connexion via VPN ou ExpressRoute. Réservez des sous-réseaux plus grands aux services qui doivent évoluer (par exemple, les pools de nœuds AKS). Nommez clairement les ressources (par exemple, vnet-prod-eastus-001) afin de faciliter la gestion à grande échelle. Un VNet bien conçu est beaucoup plus facile à sécuriser et à dépanner qu'un VNet créé sans planification.

Les VNets Azure peuvent être connectés aux réseaux locaux au moyen de deux mécanismes : VPN Gateway — un tunnel IPsec/IKE chiffré sur l'Internet public, économique pour des besoins de bande passante modérés. Azure ExpressRoute — une connexion fibre privée et dédiée fournie par un partenaire opérateur réseau, offrant une bande passante plus élevée, une latence plus faible et des performances plus prévisibles qu'un VPN. Pour les charges de travail sensibles ou les scénarios nécessitant une bande passante garantie, ExpressRoute est l'option privilégiée, même si son coût est nettement plus élevé et que sa mise à disposition demande davantage de temps.

Le dimensionnement de l'espace d'adressage d'un VNet nécessite de planifier les besoins actuels et futurs. Un modèle courant en entreprise est le suivant : espace d'adressage du VNet : /16 (65 536 adresses). Sous-réseaux : /24 par niveau de charge de travail (251 adresses utilisables chacun). Un VNet /16 peut contenir 256 sous-réseaux /24 — largement assez pour la plupart des environnements. Pour les environnements très vastes, utilisez un /8 ou demandez plusieurs plages qui ne se chevauchent pas. Prévoyez toujours une marge de croissance : allouer aujourd'hui un /24 alors qu'un /22 pourrait être nécessaire l'année prochaine entraînera ultérieurement un redimensionnement des adresses particulièrement pénible.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris qu'un VNet Azure est un réseau isolé logiquement, doté d'un espace d'adressage CIDR défini et limité à une seule région, que les sous-réseaux divisent le VNet en segments afin d'organiser les ressources et d'isoler les politiques de sécurité, et qu'Azure réserve 5 adresses IP par sous-réseau et que les ressources d'un même VNet communiquent de manière privée par défaut, sans configuration supplémentaire. Nous allons maintenant découvrir les Network Security Groups et les Application Security Groups, qui servent à filtrer le trafic.