Utiliser Pare-feu Azure pour acheminer une topologie multi hub-and-spoke

La topologie hub-and-spoke est un modèle d’architecture réseau commun dans Azure qui consolide les ressources réseau et centralise les services réseau. Cette topologie fournit une connectivité réseau et une sécurité aux réseaux virtuels déployés sur différents abonnements ou locataires.

Vous pouvez implémenter des architectures hub-and-spoke de deux façons :

• Hub-and-spoke auto-géré (traditionnel) : vous conservez un contrôle total sur les réseaux virtuels hub et la configuration du routage.
• Virtual WAN : Microsoft gère les réseaux virtuels hub et simplifie l’administration par le biais de fonctionnalités telles que l’intention de routage et les stratégies de routage.

Cet article se concentre sur les topologies hub-and-spoke auto-managées où vous disposez d’une visibilité et d’un contrôle complets sur le réseau virtuel hub et le déploiement du pare-feu Azure.

Vous pouvez réduire la surcharge d’administration d’une implémentation hub-and-spoke auto-managée à l’aide d’Azure Virtual Network Manager (AVNM). AVNM peut automatiser la configuration des tables de routage Azure, mais la conception globale et les techniques ne changent pas par rapport à l’approche manuelle. Le contenu de cet article s’applique si vous utilisez AVNM ou configurez manuellement votre topologie hub-and-spoke auto-managée.

Une alternative aux tables de routage Azure dans les réseaux virtuels spoke injecte des itinéraires dans des sous-réseaux avec azure Route Server, comme documenté dans l’injection de routage par défaut dans les réseaux virtuels spoke. Toutefois, ce modèle n’est pas couramment utilisé en raison de la complexité qui peut provenir de l’interaction entre le serveur de routage Azure et les passerelles de réseau virtuel ExpressRoute ou VPN.

Dans une configuration hub-and-spoke auto-managée :

• Hub : réseau virtuel qui sert de point de connectivité centrale à votre réseau local via VPN, ExpressRoute ou réseau étendu à définition logicielle (SD-WAN). Les périphériques de sécurité réseau tels que les pare-feu sont déployés dans le réseau virtuel hub.
• Spokes : réseaux virtuels qui s'interconnectent avec le hub et hébergent vos charges de travail.

Pour les charges de travail réparties entre plusieurs régions, vous déployez généralement un hub par région pour agréger le trafic à partir des spokes de cette région. Le diagramme suivant illustre une architecture hub-and-spoke auto-managée à deux régions avec deux réseaux virtuels spoke dans chaque région :

Architecture monorégionale hub-and-spoke

Pour comprendre la conception multirégion, vous devez d’abord comprendre les concepts d’une seule région. Le diagramme suivant montre la configuration de la table de routage pour la première région :

Tenez compte des exigences de routage pour chaque flux de trafic potentiel dans la conception à une seule région pour comprendre la configuration de routage définie par l’utilisateur :

• Trafic spoke-to-spoke : les spokes ne sont pas connectés entre eux, et l’appairage de réseaux virtuels n’est pas transitif. Chaque branche sait comment acheminer par défaut vers le réseau virtuel du point central, mais pas vers d’autres branches. Un itinéraire pour 0.0.0.0/0 appliqué à tous les sous-réseaux spoke couvre le trafic spoke-to-spoke.
• Trafic spoke-to-internet : l’itinéraire 0.0.0.0/0 dans la table de routage du spoke couvre également le trafic dirigé vers l’internet public. Cet itinéraire remplace l’itinéraire système inclus dans les sous-réseaux publics par défaut. Pour plus d’informations, consultez Accès sortant par défaut dans Azure.
• Trafic internet-to-spoke : le trafic provenant de l’internet vers le concentrateur passe généralement d’abord par le Pare-feu Azure. Le Pare-feu Azure a des règles de traduction d’adresses réseau de destination configurées, ce qui traduit également l’adresse IP source (traduction d’adresses réseau source ou SNAT). Les charges de travail des spokes voient le trafic comme provenant du sous-réseau du Pare-feu Azure. L’appairage de réseaux virtuels crée des itinéraires système vers le hub (10.1.0.0/24), de sorte que les spokes sont capables de router le trafic de retour.
• Trafic sur site à spoke et spoke à sur site : envisagez chaque direction séparément :
  • Trafic local-to-spoke : le trafic arrive du réseau local vers les passerelles VPN ou ExpressRoute. Avec le routage par défaut dans Azure, un itinéraire système est créé dans le GatewaySubnet (ainsi que dans d’autres sous-réseaux du réseau virtuel hub) pour chaque spoke. Vous devez remplacer ces itinéraires système et définir le prochain saut sur l’adresse IP privée du Pare-feu Azure. Dans cet exemple, vous avez besoin de deux itinéraires dans une table de routage associée au sous-réseau de passerelle, un pour chaque branche (10.1.1.0/24 et 10.1.2.0/24). Utiliser un résumé tel que 10.1.0.0/16 qui englobe tous les réseaux virtuels spoke ne fonctionne pas, car les itinéraires système injectés par les appairages de réseau virtuel dans le sous-réseau de passerelle sont plus spécifiques (/24 par rapport au résumé /16). Cette table de routage doit avoir le bouton bascule Propager les itinéraires de passerelle activés (défini sur Oui), sinon le routage de la passerelle peut devenir imprévisible.
  • Trafic spok-to-on-premises : les appairages de réseau virtuel entre le hub et les spokes doivent avoir Autoriser le transit de passerelle activé côté hub et Utiliser les passerelles distantes activé du côté spoke. Ces paramètres sont requis afin que les passerelles VPN et ExpressRoute publient les préfixes spoke via le protocole BGP (Border Gateway Protocol) auprès des réseaux sur site. Ces paramètres font aussi que les spokes apprennent automatiquement, par défaut, les préfixes publiés à partir de l’infrastructure locale vers Azure. Étant donné que les préfixes locaux sont plus spécifiques que l’itinéraire défini par l’utilisateur dans la table de routage 0.0.0.0/0 spoke, le trafic entre spokes et local contourne le pare-feu par défaut. Pour éviter cette situation, définissez le bouton bascule Propager les itinéraires de passerelle sur Non dans la table de routage spoke afin que les préfixes locaux ne soient pas appris et que l’itinéraire 0.0.0.0/0 soit utilisé pour le trafic vers l’emplacement local.

Vous pouvez gérer à la fois la table de routage associée aux sous-réseaux spoke et la table de routage associée au sous-réseau de passerelle à l’aide d’Azure Virtual Network Manager pour réduire la surcharge administrative. Pour plus d’informations, consultez Utiliser le Pare-feu Azure comme étape suivante.

Charges de travail de réseau virtuel hub

Si vous déployez des charges de travail dans le réseau virtuel hub (par exemple, des contrôleurs de domaine Active Directory, des serveurs DNS ou d’autres infrastructures partagées), cela augmente la complexité de la conception hub-and-spoke. Nous vous recommandons d’éviter de placer des charges de travail dans le hub et plutôt de les déployer dans une branche dédiée pour les services partagés.

Cette section décrit la configuration requise pour les charges de travail hub afin de déterminer si cette complexité est acceptable pour vos besoins. Nous décrivons également une erreur courante qui peut provoquer un trafic asymétrique et des suppressions de paquets.

Le diagramme suivant illustre une conception à une seule région avec un sous-réseau de charge de travail dans le réseau virtuel hub :

Le détail critique est que les itinéraires définis par l’utilisateur configurés dans le sous-réseau de passerelle et les sous-réseaux spoke sont définis pour le sous-réseau de charge de travail spécifique et non pour le préfixe de réseau virtuel du hub entier :

• Configuration du sous-réseau de passerelle : la configuration d’un itinéraire dans le sous-réseau de passerelle pour l’ensemble du réseau virtuel hub (10.1.0.0/24dans cet exemple) remplace l’itinéraire système du réseau virtuel hub. Cela entraîne l’envoi du trafic intra-sous-réseau entre les passerelles VPN ou ExpressRoute au pare-feu, ce qui peut perturber l’opération de passerelle.
• Configuration du sous-réseau spoke : la configuration d’un itinéraire dans les sous-réseaux spoke pour l’ensemble du réseau virtuel hub (10.1.0.0/24dans cet exemple) remplace l’itinéraire système créé par le peering avec le réseau virtuel hub. Tout le trafic envoyé au hub serait envoyé au Pare-feu Azure, y compris le trafic provenant du Pare-feu Azure lui-même, tel que le trafic Internet-à-spoke qui passe par la traduction d’adresses réseau source (SNAT). Cette configuration introduit le trafic asymétrique et provoque des suppressions de paquets.

Inspection du trafic entre sous-réseaux

Dans la configuration actuelle, le trafic entre spokes est envoyé au pare-feu, mais le trafic intra-spoke reste dans le réseau virtuel spoke et est contrôlé à l’aide de groupes de sécurité réseau. Cette conception considère les réseaux virtuels comme une limite de sécurité : le pare-feu inspecte uniquement le trafic qui quitte ou entre un réseau virtuel.

Pour inspecter le trafic entre les sous-réseaux du même réseau virtuel spoke, modifiez la table de routage associée aux sous-réseaux spoke, comme illustré dans le diagramme suivant :

Dans le diagramme précédent, deux sous-réseaux spoke sont introduits dans chaque réseau virtuel spoke, et les tables de routage des spokes dans le réseau virtuel A2 sont décrites. L’envoi du trafic entre sous-réseaux au pare-feu nécessite que chaque sous-réseau dispose d’une table de routage distincte, car les itinéraires à installer dans chaque sous-réseau sont différents.

Pour le sous-réseau A21, vous avez besoin de ces deux itinéraires supplémentaires :

• Route vers 10.1.2.0/24: remplace l’itinéraire système pour le trafic réseau intra-virtuel. Sans autres itinéraires, tout le trafic réseau intra-virtuel est envoyé au Pare-feu Azure, même le trafic entre les machines virtuelles du même sous-réseau.
• Route vers le 10.1.2.0/26 avec saut suivant réseau virtuel : une exception à l’itinéraire précédent, ainsi le trafic dans ce sous-réseau spécifique n’est pas envoyé au pare-feu, mais est routé localement dans le réseau virtuel. Cet itinéraire est spécifique à chaque sous-réseau, c’est pourquoi vous avez besoin d’une table de routage distincte pour chaque sous-réseau.

appliances virtuelles réseau SD-WAN

Si vous utilisez SD-WAN appliances virtuelles réseau (NVA) au lieu de passerelles VPN ou ExpressRoute, la conception est similaire, comme illustré dans le diagramme suivant :

Il existe différentes façons d’intégrer des appliances virtuelles réseau SD-WAN dans Azure. Pour plus d’informations, consultez l'intégration SD-WAN avec des topologies de réseau hub-and-spoke Azure. Cet article montre l’intégration à l’aide d’Azure Route Server, l’une des méthodes les plus courantes de routage du trafic vers des réseaux SD-WAN. Les appliances virtuelles réseau SD-WAN publient les préfixes sur site vers Serveur de routes Azure via le protocole BGP. Azure Route Server injecte ces préfixes dans le sous-réseau du Pare-feu Azure afin que le Pare-feu Azure dispose d’informations de routage pour les réseaux locaux. Les spokes n’apprennent pas les préfixes locaux, car l’option « Propager les itinéraires de passerelle » est désactivée dans la table de routage spoke.

Si vous ne souhaitez pas configurer le préfixe de chaque réseau virtuel spoke dans la table de routage associée au sous-réseau de l’appliance virtuelle réseau, vous pouvez placer les appliances virtuelles réseau SD-WAN dans leur réseau virtuel dédié. Le réseau virtuel NVA n’apprend pas les préfixes spoke, car ils ne sont pas directement connectés, et un itinéraire récapitulatif est possible, comme illustré dans le diagramme suivant :

Architecture multirégionale hub-and-spoke

Après avoir compris le fonctionnement du trafic dans une seule région hub-and-spoke, l’extension de la conception à une architecture multirégion est simple. Le diagramme suivant montre une conception réseau mise à jour avec des hubs dans deux régions (A et B) :

Le seul ajout à la configuration est les tables de routage associées aux sous-réseaux du Pare-feu Azure dans chaque région. Chaque réseau virtuel hub ne connaît que les préfixes des réseaux virtuels appairés directement, de sorte qu’il n’existe pas de routage pour les préfixes des spokes distants. Ajoutez des itinéraires définis par l’utilisateur pour chaque sous-réseau de pare-feu Azure afin que le trafic de chaque région soit acheminé vers le pare-feu Azure correspondant.

Dans cet exemple, chaque région peut être facilement résumée :

• La région A contient des préfixes dans 10.1.0.0/16
• La région B contient des préfixes dans 10.2.0.0/16

La définition d’adresses IP dans chaque région facilement résumée simplifie la configuration de votre routage. Sinon, vous devez créer un itinéraire pour chaque spoke distant.

Activez la propagation des itinéraires de passerelle sur la table de routage du sous-réseau du pare-feu Azure afin que le pare-feu puisse apprendre des itinéraires locaux à partir de passerelles VPN et ExpressRoute.

Pour simplifier la gestion des itinéraires définis par l’utilisateur dans un environnement multirégion, vous pouvez utiliser Azure Virtual Network Manager. Pour plus d’informations, consultez Gérer les itinéraires définis par l’utilisateur sur plusieurs topologies hub-and-spoke avec AVNM.

Étapes suivantes

• Découvrez comment déployer et configurer un Pare-feu Azure.