Editions ENI Livres | Vidéos | e-Formations
Fondamentaux
Principe et description des réseaux IP Azure
Pour appréhender au mieux les enjeux et concepts associés au réseau dans le cloud Microsoft Azure, il est primordial d’aborder, en premier lieu et de manière globale, les fondements d’un tel réseau. Cette première partie sera donc dédiée aux concepts de zones géographiques, de régions et de haute disponibilité.
1. Zones géographiques, régions et haute disponibilité
a. Zones géographiques
Le cloud Microsoft Azure est un réseau mondial conséquent, constitué d’une soixantaine de régions réparties dans une trentaine de zones géographiques. Chaque zone géographique est un groupement d’une ou plusieurs régions. Lorsque vous sélectionnez une zone géographique, Azure s’assure de ne pas faire transiter vos données en dehors de celle-ci. Le choix d’une zone géographique, outre la proximité avec vos utilisateurs, implique également des aspects juridiques importants.
Les zones géographiques peuvent prendre différentes formes. Il peut s’agir d’un pays (États-Unis), d’un continent (Europe occidentale) ou encore d’une région spécifique (Asie Pacifique). Autre exemple de région cette fois plus spécifique, la région "Azure Government", disponible mais non accessible au grand public. Cette dernière, hautement sécurisée, est destinée aux organisations gouvernementales américaines.
b. Régions et jumelage
Chacune de ces zones géographiques est constituée d’une ou plusieurs régions. C’est au sein de ces dernières que vos ressources seront déployées et rendues disponibles au plus proche de vos utilisateurs. Évidemment, le déploiement de vos ressources n’est pas limité à une seule et même région. Pour répondre à vos enjeux de disponibilité, Azure assure de la redondance inter-régionale en s’appuyant notamment sur des paires régionales prédéfinies au sein d’une même zone géographique (à l’image des régions France Centre et France Sud). Ces paires sont directement...
Routage
De manière générale, le routage définit le processus par lequel un chemin réseau est sélectionné pour permettre à un équipement source (un serveur par exemple) de transiter vers une destination donnée (un équipement, un réseau…). Le routage dans Azure nécessite une attention particulière car il est configuré par défaut. Il est donc primordial de maîtriser ses mécanismes par défaut afin d’assurer la sécurité de vos environnements et de pouvoir y intégrer, quand cela est nécessaire, du routage défini par l’utilisateur au travers d’une table de routage personnalisée.
1. Types d’itinéraires et table de routage
Une table de routage (aussi appelée table d’itinéraires) est une table contenant l’ensemble des itinéraires accessibles, associés à leur tronçon suivant (next-hop). Autrement dit, la table permet de trouver une correspondance entre un préfixe à joindre et la ressource suivante dans la chaîne de routage.
Il existe différents types de routes sur Microsoft Azure :
-
Les itinéraires système par défaut obligatoires.
-
Les itinéraires système par défaut facultatifs.
-
Les itinéraires personnalisés définis par l’utilisateur.
-
Les itinéraires personnalisés provenant d’une passerelle.
Certains d’entre eux nécessitent la création d’une table de routage. D’autres, par défaut, sont actifs dès la configuration d’un réseau virtuel.
La suite de ce chapitre revient point par point sur ces itinéraires ainsi que sur leur conséquence en termes de routage.
a. Les itinéraires système par défaut obligatoires
Premièrement, les itinéraires système sont des itinéraires créés automatiquement pour chaque sous-réseau et sur lesquels aucune modification ou suppression n’est autorisée. Ces "règles internes" sont obligatoires pour tout déploiement et sont incluses dans une table de routage par défaut.
De ce fait, lorsque vous déployez un réseau virtuel contenant un ou plusieurs sous-réseaux...
Services DNS
Les services DNS (Domain Name System) jouent eux aussi un rôle primordial au sein de vos environnements locaux ou cloud et font partie des concepts fondamentaux à maîtriser. Une mauvaise compréhension ou configuration de ces derniers sur le cloud Azure pourrait être source de comportements inadaptés ou être à l’origine de dysfonctionnements.
Pour rappel, le DNS a pour objectif de résoudre un nom que nous pourrions qualifier de facile et compréhensible, en adresse IP publique ou privée. Les grands principes autour des services DNS sont comparables aux déploiements locaux mais leur implémentation et leur intégration dans vos réseaux virtuels Azure s’avèrent toutefois quelque peu différentes.
Pour répondre aux besoins de résolutions DNS, Azure DNS propose deux types de services :
-
Les DNS Azure privés (Par défaut, Zones DNS Privées ou Personnalisés).
-
Les DNS Azure publics.
Concentrons-nous dans un premier temps sur les services DNS privés.
1. DNS Privés - Par défaut
Par défaut, les ressources et machines virtuelles situées dans vos réseaux virtuels utilisent les services DNS Azure pour la résolution de nom. L’adresse IP dédiée au service DNS Azure est unique et fixe : 168.63.129.16.
Le service par défaut fournit une résolution de nom pour toute ressource située dans un même réseau virtuel. Toutefois, en dehors de ce réseau virtuel, la résolution de nom ne sera plus possible. De plus, le déploiement de multiples domaines dans votre environnement n’est pas supporté par défaut.
Cette solution par défaut est donc relativement limitée et ne permet pas d’atteindre le même niveau de service que celui que vous pourriez obtenir dans un réseau local avec vos propres infrastructures DNS. C’est pourquoi, pour pouvoir déployer plusieurs domaines et que ces derniers soient accessibles depuis différents réseaux virtuels, Microsoft propose un service nommé Zone DNS Privée dans Azure.
2. DNS Privés - Zone DNS Privée
Une Zone DNS Privée est une ressource Azure globale, accessible au travers de différentes régions, souscriptions...
Cas concret - Partie 1
Comme évoqué lors de l’introduction de cet ouvrage, le cas concret a pour objectif de déployer étape par étape un réseau d’entreprise complet, hybridé et sécurisé. Chaque chapitre permet ainsi de compléter le déploiement global en ajoutant plus de fonctionnalités, de connectivité ou de sécurité.
La première partie de ce cas concret se concentre sur la mise en place du socle réseau de base de la société Dream Company. Ce socle, déployé en Europe occidentale, est constitué de différents réseaux virtuels, sous-réseaux, groupes de ressources et machines virtuelles. Pour rappel, la cible du déploiement est une architecture de type Hub-and-Spoke sur laquelle nous reviendrons régulièrement. C’est pourquoi le socle réseau est pour le moment constitué des éléments suivants :
-
Trois réseaux virtuels.
-
Un réseau "hub" central dans lequel seront déployés les différents passerelles et pare-feux.
-
Deux réseaux "spoke", dédiés aux ressources applicatives.
-
Quatre sous-réseaux.
-
Chaque sous-réseau sera dédié à un besoin spécifique (passerelles, ressources applicatives…).
-
Trois groupes de ressources.
Les groupes de ressources sont des regroupements logiques de vos ressources Azure. Il s’agit de conteneurs logiques dans lesquels vous pouvez placer n’importe laquelle de vos ressources. Dès lors, il est possible de gérer vos ressources de manière centralisée. Par exemple, un groupe de ressources "réseau" peut contenir l’ensemble de vos interfaces réseau, adresses IP, etc. Autre exemple, un groupe de ressources peut représenter l’ensemble des briques associées à une application hébergée dans le cloud (machines virtuelles, interfaces réseau, équilibreur de charge…).
Ici, chaque groupe de ressources représentera un des trois réseaux virtuels et les ressources qui y sont incluses. Une nomenclature simple est utilisée pour conserver un déploiement lisible et abordable. C’est pourquoi tous les groupes de ressources seront nommés...
