Editions ENI Livres | Vidéos | e-Formations
Le réseau
Introduction
Le réseau virtuel est dans la grande majorité des cas la première ressource créée sur Azure si l’on exclut le groupe de ressources présenté dans le chapitre Concepts de base. Pour rappel, un groupe de ressources n’est pas à proprement parler une ressource mais plutôt un conteneur de ressources. Il n’est pas possible de créer une ressource sans cet élément.
Le réseau Azure est un terme générique et adresse bien plus qu’un réseau virtuel. Pour ce livre, l’auteur a choisi de parler des composants les plus utilisés, de les présenter en détail et de cibler uniquement ce qui va être utilisé dans le réseau Azure. En voici la liste :
-
Le réseau virtuel (ou VNet) : le composant de base.
-
Le sous-réseau (ou Subnet) : une découpe du réseau virtuel en plages d’adresses.
-
Les groupes de sécurité réseau (ou NSG) : des règles d’accès, d’autorisations et de blocages pour contrôler le trafic entre les réseaux.
-
Les équilibreurs de charge (ou load balancer) : équilibrer la charge, c’est positionner un composant en entrée de réseau qui va répartir le trafic, ceci afin d’équilibrer mais aussi pour ne le répartir...
Liaison entre le centre de données local et Azure
Dans une utilisation classique d’un fournisseur de Cloud, le centre de données de l’entreprise est relié au centre de données Azure par deux types de connexion (il existe une autre solution plus anecdotique, de point à site) :
-
VPN (Virtual Private Network ou réseau privé virtuel) site à site.
-
ExpressRoute : service de connexion privée en partenariat avec un fournisseur de connectivité.
Il y a une différence fondamentale entre le VPN site à site et ExpressRoute. Ce dernier n’utilise pas l’Internet public. Express route est également un service qui propose différents niveaux : une offre de base à 50 Mbit/s de bande passante, une connexion entrante illimitée et un trafic sortant facturé mais aussi un service à 100 Gbit/s et un trafic entrant/sortant illimité. Entre ces deux extrêmes nous est proposé un choix varié. L’offre VPN est également modulable mais fournit un débit inférieur aux services ExpressRoute.
Il faut voir ces services comme le lien, le "tuyau" qui unit le réseau du centre de données local au centre de données Azure. Ce service est attaché à des passerelles qui sont un point d’entrée/sortie pour le réseau sur les deux centres...
VNet
Le VNet (réseau virtuel ou Virtual Network) est l’équivalent du réseau local comme on le retrouve sur un centre de données. Il est complètement isolé du réseau virtuel existant pour les autres clients Azure. Les plages d’adresses IP à utiliser doivent être conformes à la RFC1918 (Requests For Comments), c’est-à-dire les adresses privées suivantes :
-
10.0.0.0 - 10.255.255.255 (10/8 prefix).
-
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
-
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Sur ces plages, toutes les adresses ne sont pas disponibles. On retrouve les restrictions classiques pour les adresses 0 (adresse du réseau) et 255 (adresse de diffusion réseau), mais également des restrictions propres à Azure :
-
x.x.x.1 : réservée pour la passerelle par défaut.
-
x.x.x.2, x.x.x.3 : mappage des adresses Azure DNS à l’espace du réseau.
Le réseau virtuel doit être traité comme un réseau à part entière. Il demande autant de soin d’adressage lors de sa mise en place qu’un réseau classique. Le Cloud offre un mode de délégation poussé mais des contrôles centralisés...
Les sous-réseaux
Les sous-réseaux ou subnet sont une découpe des réseaux virtuels présentés ci-dessus. Ce sont des espaces dédiés dans la portée du réseau VNet.
Le sous-réseau est obligatoire. Comme présenté dans les exercices à venir, il n’est pas possible de valider la création d’un réseau sans créer un sous-réseau dans ce réseau. Même si un sous-réseau appelé default est créé en /24, si l’administrateur n’effectue pas explicitement l’opération, il est préférable de supprimer ce sous-réseaux et de créer ses propres sous-réseaux avec des plages IP adaptées et une bonne convention de nommage.
De même, une ressource Azure qui doit avoir des accès réseau est attachée à un sous-réseau, pas directement au réseau. Le sous-réseau est donc un composant enfant du réseau virtuel. Au-delà de cette obligation, un réseau sans sous-réseau n’a pas de sens.
La découpe offre des possibilités fines et granulaires, par exemple la liaison d’un groupe de sécurité (NSG) à un sous-réseau (voir section suivante).
NSG
Les NSG (Network Security Group ou groupe de sécurité réseau) sont des groupes de règles de filtrage pour les accès au réseau. Ils contrôlent les accès entrants et sortants pour les ressources.
Une règle est une combinaison port + protocole + source + destination + sens + action (autoriser/interdire) + priorité. À noter également que des règles par défaut sont attachées au sous-réseau à sa création.
Cette section va être particulièrement détaillée car sous son apparente simplicité, le NSG est un composant très puissant. Il assure une partie de la sécurité des accès, c’est donc un sujet sensible. Il n’est pas compliqué à aborder, il est cependant très complet.
Pour en comprendre la raison, il faut revenir à la composition d’une règle, comme expliqué ci-dessus : port + protocole + source + destination + sens + action (autoriser/interdire) + priorité.
Il y a quelques subtilités pour les paramètres source, destination et priorité :
-
source peut être une adresse IP ou une plage d’adresse IP, mais également un Application Security Group ou un Service Tag.
-
destination peut être une adresse IP ou une plage d’adresse IP, mais également un Application Security...
Tables d’itinéraire
Comme dans un réseau classique, l’utilisation d’une table d’itinéraire ou table de routage est possible. Des itinéraires par défaut sont créés directement par Azure. L’utilisateur peut créer des routes supplémentaires que l’on connaît sous l’appellation UDR (User Defined Routes ou routes définies par l’utilisateur) qui sont des routes statiques. Plutôt que de laisser une ressource emprunter la route Azure, la table d’itinéraire force un ou plusieurs sauts vers une plage d’IP différente. Un très bon exemple d’utilisation est de forcer les ressources à passer par un service réseau ou une appliance réseau de type pare-feu ou par un service comme le pare-feu Azure ou Azure Firewall (voir à ce sujet le chapitre La sécurité).
Équilibreur de charge
Le dernier élément réseau présenté dans le chapitre est l’équilibreur de charge ou load balancer. C’est une ressource qui va répartir la charge entre plusieurs ressources.
Elle est exposée en externe au travers d’une adresse IP publique ou en interne entre les différentes couches d’une application ; typiquement, entre la partie web d’une application exposée en externe et la partie données de cette même application exposée à la partie web en interne.
Voici ci-dessous un modèle simple d’utilisation qui facilite la compréhension. Ce schéma de base peut être porté et complété d’autres ressources pour devenir plus performant et plus résilient. C’est donc un modèle plus pédagogique que technique. Il représente toute la mécanique de l’équilibreur de charge.
Équilibreur public externe et équilibreur interne
La création d’un équilibreur de charge nécessite de nombreux paramètres. C’est un composant très technique qui ne fait pas simplement de la répartition de trafic entre des points de terminaison ; il va beaucoup plus loin.
Il ne faut pas voir l’équilibreur comme un composant autonome mais plutôt comme une partie d’un...
Exercices
Les exercices suivants reprennent des points théoriques présentés plus haut dans ce chapitre en ajoutant quelques nouvelles notions. Du réseau virtuel aux groupes de sécurité réseau, tous ces exercices sont très liés. Il ne faut pas hésiter à revenir sur les points dédiés dans le chapitre pour bien comprendre ce qui est mis en œuvre ici.
Dans ce premier exercice, un Application Security Group est créé. Avant de préparer des groupes de sécurité réseau, il faut préparer les éléments sur lesquels sont positionnées les règles.
Dans le portail Azure, effectuez une recherche en tapant groupe de sécurité et sélectionnez Groupes de sécurité d’application, puis + Nouveau.
Sélectionnez votre abonnement, puis le groupe de ressources rg-formation-eni-test.
Nommez le groupe ASG-ApplicationENI1, puis choisissez (Europe), France-Centre dans le menu Région. En bas de page, sélectionnez Suivant : Etiquettes.
Créez une paire nom/valeur où le nom est Application et la valeur Appli1, puis Suivant : Vérifier + créer.
Relisez le résumé de la demande et attendez le message Validation réussie, puis Créer.
La création ne prend que quelques secondes et se termine par le message Votre déploiement a été effectué. Choisissez Accéder à la ressource.
Le groupe de sécurité d’application est créé, il n’est pas utilisable depuis ce menu. C’est un conteneur qui est mis à disposition des ressources réseau et qui s’utilise depuis le menu de ces ressources.
Le groupe de sécurité d’application est un composant particulier. Il est présent dans le menu mais il n’est pas possible d’en connaître le contenu. Une fois créé, il s’utilise depuis la machine virtuelle.
Dans l’exemple suivant, dans le menu Mise en réseau d’une machine virtuelle, puis dans l’onglet Groupe de sécurité d’application, on trouve une option Configurer les groupes de sécurité d’application.
Le menu Mise en réseau d’une...
