Topologie de réseau hub-and-spoke

Cet article explique comment concevoir un réseau hub-and-spoke dans Azure. Un réseau virtuel hub central héberge des services partagés tandis que les réseaux virtuels spoke isolés hébergent des charges de travail individuelles.

Présentation de cet article

Cet article couvre les services partagés du réseau virtuel hub, l'isolation des spokes et les modèles de routage (standard, peering direct et basé sur des stamps). Il couvre également le transit de passerelle pour la connectivité hybride et la mise à l’échelle des topologies hub-spoke avec Azure Virtual Network Manager.

Qui a besoin de cet article

Lisez cet article si une ou plusieurs de ces conditions s’appliquent :

• Vous avez besoin de services réseau partagés tels que le pare-feu, DNS, Bastion, passerelle VPN ou ExpressRoute pour plusieurs charges de travail.
• Vous souhaitez centraliser l’inspection du trafic, le contrôle de routage ou l’administration au lieu de répéter ces services dans chaque réseau virtuel.
• Vous avez besoin d’une topologie reproductible pour séparer les services de plateforme partagée des réseaux virtuels de charge de travail.
• Vous souhaitez comparer hub-and-spoke avec d’autres modèles de transit avant de standardiser votre topologie.

Si vous avez une seule charge de travail sans configuration requise pour le service partagé, commencez par une topologie de réseau plat à la place.

Azure services et fonctionnalités

Le tableau suivant répertorie les services et fonctionnalités Azure qui prennent en charge une topologie hub-and-spoke :

Fonctionnement

Dans une topologie hub-and-spoke :

1. Un réseau virtuel hub agit comme point central de connectivité. Il contient des services réseau partagés tels qu’un pare-feu, une passerelle et un hôte Bastion.
2. Les réseaux virtuels spoke sont appairés au hub. Chaque spoke héberge une charge de travail : une application, un environnement d’équipe ou un service isolé.
3. Le peering de VNet est non transitif. Les spokes peuvent atteindre le hub, mais ils ne peuvent pas communiquer directement entre eux via le hub, sauf si vous configurez un routage ou un peering direct entre eux.

Ce qui se passe dans le réseau virtuel hub

Utilisez le tableau suivant pour déterminer les services à placer dans votre hub :

Disposition du sous-réseau hub

Un réseau virtuel hub bien conçu inclut généralement ces sous-réseaux :

Pour obtenir des instructions détaillées sur le dimensionnement des sous-réseaux, consultez réseaux virtuels et sous-réseaux.

Comment choisir une variante

Hub-and-spoke comporte trois variantes courantes. Choisissez en fonction de vos exigences d’isolation et de communication :

Hub-and-spoke standard

Cette variante est la plus courante. Tout le trafic entre spokes transite par le pare-feu du hub pour inspection. Les spokes communiquent uniquement via le hub, jamais directement.

Modèle de routage : Appliquez un itinéraire défini par l’utilisateur (UDR) à chaque sous-réseau spoke avec l’itinéraire par défaut (0.0.0.0/0) pointant vers l’adresse IP privée du pare-feu hub. Cela force tout le trafic sortant, y compris entre spokes, à passer par le pare-feu pour la journalisation et le filtrage.

Limite de peering : Un réseau virtuel hub unique prend en charge jusqu’à 500 connexions de peering (limite de plateforme standard). Si vous utilisez Azure Virtual Network Manager (AVNM) avec une configuration de connectivité hub-spoke, la limite augmente à 1 000 spokes.

Hub-and-spoke avec peering direct

Dans certaines architectures, des paires spoke spécifiques nécessitent une communication à faible latence sans traverser le pare-feu hub. Dans ces cas, ajoutez un peering direct de réseau virtuel entre les deux spokes ou utilisez les groupes connectés AVNM.

Utilisez le peering direct entre spokes lorsque :

• Deux charges de travail échangent des données à haut débit (par exemple, une réplication de base de données entre spokes).
• La latence du tronçon de pare-feu est inacceptable pour un chemin de données spécifique.
• Vous acceptez que le trafic directement appairé contourne l'inspection du pare-feu central.

Motif de tampons (entièrement isolé)

Le modèle « Stamps » est une alternative pour les cas d’usage qui nécessitent une isolation stricte du périmètre d’impact. Chaque charge de travail se déploie dans un réseau virtuel entièrement indépendant sans hub et sans peering à d’autres charges de travail.

Quand utiliser des tampons :

• La conformité réglementaire ne nécessite aucun chemin réseau entre les charges de travail.
• SaaS multilocataire où chaque client dispose d’une stack indépendante.
• Isolation maximale des défaillances : une défaillance dans un stamp ne peut pas se propager aux autres.

Exemple : isolation SaaS multilocataire

Un fournisseur SaaS héberge chaque client d’entreprise dans un tampon dédié. Chaque tampon contient son propre réseau virtuel (10.x.0.0/16), sa passerelle d’application, son niveau de calcul et sa base de données. Aucun peering de réseau virtuel n'existe entre les stamps. Ainsi, un groupe de sécurité réseau mal configuré ou une charge de travail compromise dans le stamp du locataire A ne peut pas atteindre les ressources du locataire B via le réseau. Le fournisseur gère les stamps à l'aide de modèles Azure Resource Manager et les déploie dans des groupes de ressources distincts ou des abonnements distincts pour les grands locataires. L’échange de données entre locataires, si nécessaire, utilise un espace de noms de Azure Service Bus partagé. Chaque stamp accède à cet espace de noms via des points de terminaison privés.

Compromis :

• Aucun service partagé. Chaque tampon a besoin de son propre pare-feu, passerelle et hôte Bastion (le cas échéant), ce qui augmente le coût.
• Aucune communication entre charges de travail via un réseau privé.
• La surcharge opérationnelle augmente, car vous gérez des réseaux indépendants au lieu d’une infrastructure centralisée.
• Le coût augmente linéairement avec le nombre d’empreintes, car les économies de service partagé ne s’appliquent pas.

Si vos charges de travail ont besoin de services partagés ou de communications entre charges de travail, utilisez plutôt la variante hub-and-spoke standard.

Modèles de communication entre spokes

Étant donné que le peering de réseaux virtuels n'est pas transitif, la communication entre spokes nécessite un routage explicite. Cette section explique comment le trafic circule entre les spokes à l’aide du pare-feu hub.

Flux de trafic : de Spoke A vers Spoke B via le pare-feu du hub

La séquence suivante décrit comment un paquet passe d’une machine virtuelle en Spoke A (10.1.0.4) à une machine virtuelle en Spoke B (10.2.0.4) :

1. Spoke Une machine virtuelle envoie un paquet destiné à 10.2.0.4. La table de routage effective de la machine virtuelle contient un UDR avec 0.0.0.0/0 → 10.0.1.4 (l'adresse IP privée Pare-feu Azure).
2. Le paquet traverse la liaison de peering du réseau virtuel depuis Spoke A jusqu’au réseau virtuel Hub. Le peering permet au trafic d’atteindre le sous-réseau du pare-feu.
3. Pare-feu Azure reçoit le paquet sur son interface interne. Il évalue le paquet par rapport aux règles de réseau et aux règles d’application dans l’ordre de priorité.
4. Si une règle autorise le flux, le pare-feu transfère le paquet vers 10.2.0.4. Le paquet traverse le lien d’interconnexion entre le hub et Spoke-B.
5. La machine virtuelle Spoke B reçoit le paquet. Le trafic de retour suit le même chemin dans l’inverse. L’UDR de Spoke B renvoie la réponse via le pare-feu.

Configuration des tables de routage

Appliquez ces tables de routage pour activer le modèle précédent :

1. Créez une table de routage pour les sous-réseaux spoke. Désactivez la propagation des routes BGP si vous souhaitez empêcher les routes locales de prendre le pas sur vos UDR.
2. Ajoutez un itinéraire par défaut (0.0.0.0/0) avec le type VirtualAppliance de tronçon suivant et l’adresse de tronçon suivante définie sur l’adresse IP privée Pare-feu Azure.
3. Associez la table de routage à chaque sous-réseau spoke qui doit atteindre d'autres spokes ou Internet.
4. Créez des règles de réseau de pare-feu qui autorisent le trafic spoke-to-spoke spécifique. Par exemple, autorisez 10.1.0.0/16 → 10.2.0.0/16 les ports 443 et 1433.

Alternative : groupes connectés AVNM pour une communication directe entre spokes

Si vous n'avez pas besoin d'une inspection par pare-feu entre certains spokes, les groupes connectés AVNM fournissent un modèle de connectivité maillée. Les spokes d'un même groupe connecté communiquent directement sans transiter par le hub. Cela réduit les exigences en matière de débit de latence et de pare-feu, mais ignore l’inspection centralisée.

Transit de passerelle

Le transit de passerelle permet à tous les spokes de partager une seule passerelle VPN ou ExpressRoute déployée dans le hub. Sans transit de passerelle, chaque spoke a besoin de sa propre passerelle pour atteindre les réseaux locaux.

Étapes de configuration

1. Déployez une passerelle VPN ou ExpressRoute dans le hub GatewaySubnet.
2. Sur la connexion de peering côté hub (hub → spoke) : activez Autoriser le transit de passerelle.
3. Sur la connexion de peering côté spoke (spoke → hub) : activez Utiliser des passerelles distantes.
4. Vérifiez la propagation de l’itinéraire. Après la configuration, vérifiez les itinéraires effectifs sur la carte réseau de la machine virtuelle du spoke. La table de routage affiche les préfixes locaux appris via la passerelle du hub avec un type de saut suivant VNetGlobalPeering ou VNetPeering.

Lorsqu’elle est configurée, les itinéraires appris par la passerelle du hub (par exemple, les préfixes du réseau local provenant d’ExpressRoute) sont automatiquement propagés vers les tables de routage des spokes.

Limitations du transit de passerelle

• Le transit de passerelle fonctionne avec tous les niveaux de passerelle VPN à l’exception du niveau Basic. Si vous utilisez la passerelle VPN Basic, vous ne pouvez pas la partager avec des réseaux virtuels homologues.
• Un réseau virtuel spoke ne peut utiliser qu’une seule passerelle distante. Vous ne pouvez pas activer Use remote gateways sur un spoke appairé à plusieurs hubs.
• Si vous utilisez des UDR pour forcer le trafic à passer par le pare-feu, assurez-vous que les UDR ne remplacent pas involontairement les itinéraires locaux propagés par la passerelle. Définissez des itinéraires plus spécifiques pour les préfixes locaux si nécessaire.

Gestionnaire de réseaux virtuels Azure à grande échelle

Lorsque votre environnement dépasse une poignée de spokes, la gestion manuelle des connexions de peering et des tables de routage devient complexe. AVNM fournit une automatisation pour les topologies hub-spoke :

AVNM est particulièrement utile lorsque vous gérez des topologies hub-spoke dans plusieurs régions ou si vous avez besoin d’une appartenance dynamique à mesure que les nouveaux réseaux virtuels spoke sont en ligne.

Considérations relatives à la mise à l’échelle

À mesure que votre topologie hub-spoke augmente, planifiez les limites de plateforme et les modèles organisationnels suivants :

Limites de peering et de connectivité

Organisation d’abonnement

• Répartissez les spokes dans des abonnements spécifiques aux charges de travail pour les environnements comptant plus de 10 spokes. Cela isole la facturation, le RBAC et les limites de quota pour chaque équipe responsable d’une charge de travail.
• Utilisez un abonnement de connectivité dédié pour le réseau virtuel hub, les passerelles et le pare-feu. Il s’agit du modèle recommandé par les zones d’atterrissage Azure (abonnement de la plateforme).
• Regroupez les abonnements sous un groupe d'administration afin qu'Azure Virtual Network Manager puisse découvrir et gérer dynamiquement les réseaux virtuels spoke de plusieurs abonnements à l'aide des conditions Azure Policy.

Application de la topologie avec Azure Policy

Utilisez Azure Policy pour empêcher la dérive de configuration :

• Refuser le peering avec des réseaux virtuels autres que le hub. Attribuez une stratégie au niveau du groupe d'administration qui bloque la création de peerings de réseaux virtuels, sauf si la cible est le réseau virtuel hub désigné.
• Exiger l'association d'une UDR. Attribuez une stratégie qui audite (ou refuse) les sous-réseaux spoke dépourvus d'une table de routage contenant l'itinéraire 0.0.0.0/0 → Firewall.
• Imposer l’appartenance au groupe AVNM. Utilisez dans AVNM des règles d’appartenance dynamiques basées sur des balises (par exemple, NetworkRole:Spoke) afin que les nouveaux VNets soient automatiquement ajoutés.

Parcours de migration d'une topologie plate vers hub-and-spoke

Si vous avez commencé avec une topologie de réseau plat et que votre environnement a augmenté pour exiger des services partagés ou une segmentation entre charges de travail, suivez ce chemin de migration :

Étape 1 : Planifier le réseau virtuel hub

1. Allouez un nouvel espace d’adressage pour le hub (par exemple) 10.0.0.0/16qui ne chevauche pas votre réseau virtuel plat existant.
2. Déterminez les services partagés à déployer : pare-feu, passerelle, Bastion, programme de résolution DNS.
3. Dimensionnez les sous-réseaux du hub conformément au tableau de disposition des sous-réseaux du hub.

Étape 2 : Déployer des services partagés dans le hub

1. Créez le réseau virtuel de hub et déployez Pare-feu Azure (ou l’appliance réseau virtuelle de votre choix).
2. Déployez la passerelle VPN/ExpressRoute si vous avez besoin d’une connectivité hybride.
3. Déployez Azure Bastion pour sécuriser l’accès aux machines virtuelles.
4. Configurez le résolveur DNS privé si vous utilisez un DNS personnalisé.

Étape 3 : migrer les charges de travail vers les spokes

1. Créez des réseaux virtuels spoke avec de nouveaux espaces d'adressage pour chaque charge de travail. Si vous ne pouvez pas modifier les adresses IP, vous pouvez conserver les plages existantes tant qu'elles ne chevauchent pas celles du hub.
2. Appairez chaque spoke au hub. Activez le transit de passerelle côté hub et utilisez les passerelles distantes côté spoke.
3. Appliquez des UDR aux sous-réseaux spoke avec l’itinéraire par défaut pointant vers le pare-feu hub.
4. Déplacez ou redéployez des machines virtuelles et des services du réseau virtuel plat vers le spoke approprié. Utilisez Azure Resource Mover ou redéploiement, en fonction de la complexité de la charge de travail.
5. Créez des règles de pare-feu pour autoriser les modèles de trafic entre spokes et entre les spokes et Internet que vous autorisiez auparavant dans le réseau virtuel plat.

Étape 4 : Désactiver le réseau virtuel plat

1. Vérifiez que toutes les charges de travail sont accessibles grâce à la nouvelle topologie en hub-spoke.
2. Mettez à jour les enregistrements DNS si les adresses IP privées ont changé.
3. Supprimez l’ancien réseau virtuel plat une fois que vous migrez et validez tout le trafic.

Quand envisager plutôt Virtual WAN

Si votre topologie hub-spoke augmente en complexité, évaluez si Azure Virtual WAN offre un meilleur ajustement :

Pour obtenir une comparaison détaillée, consultez Azure Virtual WAN topologie.

Considérations relatives à la conception

Prerequisites

Avant de concevoir un réseau hub-and-spoke :

• Terminez votre plan de réseau virtuel et de sous-réseau. Connaissez le nombre de spokes dont vous avez besoin et les sous-réseaux dont chaque spoke a besoin.
• Définissez votre schéma d’adresse IP. Les espaces d'adressage du hub et des spokes ne doivent pas se chevaucher.
• Gardez à l'esprit que le peering de réseaux virtuels n'est pas transitif : les spokes n'héritent pas de la connectivité vers les autres spokes via le hub.

Considérations relatives à la sécurité

Une topologie hub-and-spoke centralise l’application des règles de sécurité au niveau du hub. Appliquez ces principes :

• Acheminez tout le trafic des spokes via le pare-feu du hub. Utilisez des UDR avec l’itinéraire par défaut pointant vers le pare-feu. Cette configuration garantit que le pare-feu inspecte et journalise tous les flux entre spokes ainsi qu'entre les spokes et Internet.
• Utilisez des groupes de sécurité réseau sur les sous-réseaux spoke comme mesure de défense en profondeur. Même avec un pare-feu central, les groupes de sécurité réseau sur les sous-réseaux spoke fournissent une couche supplémentaire de segmentation. Refuser le trafic latéral inattendu au niveau du sous-réseau. Pour obtenir des conseils de conception de groupe de sécurité réseau, consultez groupes de sécurité réseau et groupes de sécurité des applications.
• Activez le transit de passerelle avec précaution. Le transit de passerelle expose les itinéraires des réseaux locaux à tous les spokes. Assurez-vous que les règles de pare-feu prennent en compte l’extension de la connectivité.
• Supprimez les adresses IP publiques sur les machines virtuelles spoke. Azure Bastion dans le hub fournit un accès de gestion sécurisé sans exposer de machines virtuelles à Internet.
• Traitez chaque spoke comme une frontière de sécurité. Les charges de travail situées dans des spokes différents restent isolées par défaut. La connectivité entre spokes nécessite un routage explicite et des règles de pare-feu.

Articles connexes

• Topologie de réseau plat : pour les charges de travail uniques qui n’ont pas besoin de services partagés
• topologie Azure Virtual WAN : pour le routage managé et la connectivité à grande échelle
• Mise en réseau multirégion : pour les charges de travail qui s’étendent sur plusieurs régions Azure
• Réseaux virtuels et sous-réseaux : dimensionnement de sous-réseau pour les composants hub
• Planification des adresses IP : plan CIDR pour le concentrateur et les branches
• Groupes de sécurité réseau et groupes de sécurité des applications : défense en profondeur sur les sous-réseaux spoke

Learn more

• Topologie de réseau hub-spoke dans Azure
• Interconnexion de réseaux virtuels
• Vue d’ensemble du Pare-feu Azure
• Vue d’ensemble d’Azure Virtual Network Manager
• Transit passerelle VPN pour le peering
• Azure Bastion et peering de réseaux virtuels

Étapes suivantes