Hub-and-spoke-netwerktopologie

In dit artikel wordt uitgelegd hoe u een hub-and-spoke-netwerk in Azure ontwerpt. Een centraal virtueel hubnetwerk host gedeelde services terwijl geïsoleerde virtuele spoke-netwerken afzonderlijke workloads hosten.

Wat in dit artikel wordt behandeld

In dit artikel worden gedeelde services van het hub-virtuele netwerk, spoke-isolatie en routeringspatronen (standaard, directe peering en stamp-gebaseerd) behandeld. Het omvat ook gatewayoverdracht voor hybride connectiviteit en het schalen van hub-spoke-topologieën met Azure Virtual Network Manager.

Wie heeft dit artikel nodig

Lees dit artikel als een of meer van deze voorwaarden van toepassing zijn:

• U hebt gedeelde netwerkservices nodig, zoals firewall, DNS, Bastion, VPN Gateway of ExpressRoute voor meerdere workloads.
• U wilt verkeersinspectie, routeringsbeheer of beheer centraliseren in plaats van deze services in elk VNet te herhalen.
• U hebt een herhaalbare topologie nodig voor het scheiden van gedeelde platformservices van workload-VNets.
• U wilt hub-and-spoke vergelijken met andere transitmodellen voordat u uw topologie standaardiseert.

Als u één workload hebt zonder vereisten voor gedeelde services, begint u in plaats daarvan met een platte netwerktopologie .

Azure services en functies

De volgende tabel bevat de Azure services en functies die ondersteuning bieden voor een hub-and-spoke-topologie:

Hoe werkt het?

In een hub-and-spoke-topologie:

1. Een virtueel hubnetwerk fungeert als het centrale punt van connectiviteit. Het bevat gedeelde netwerkservices, zoals een firewall, gateway en Bastion-host.
2. Spoke-virtuele netwerken hebben een peering met de hub. Elke spoke fungeert als host voor een workload: een toepassing, een teamomgeving of een geïsoleerde service.
3. VNet-peering is niet transitief. Spokes kunnen de hub bereiken, maar spokes kunnen elkaar niet rechtstreeks bereiken via de hub, tenzij u routering of directe peering tussen hen configureert.

Wat er in het virtuele hubnetwerk gebeurt

Gebruik de volgende tabel om te bepalen welke services u in uw hub wilt plaatsen:

Indeling van hubsubnet

Een goed ontworpen virtueel hubnetwerk bevat doorgaans deze subnetten:

Zie VNets en subnetten voor gedetailleerde richtlijnen voor subnetdimensionering.

Een variant kiezen

Hub-and-spoke heeft drie veelvoorkomende varianten. Kies op basis van uw isolatie- en communicatievereisten:

Standaard naaf-en-spaakmodel

Deze variant is de meest voorkomende. Al het spoke-to-spoke-verkeer passeert de hubfirewall voor inspectie. Spokes communiceren alleen via de hub, nooit rechtstreeks.

Routeringspatroon: Pas een door de gebruiker gedefinieerde route (UDR) toe op elk spoke-subnet met de standaardroute (0.0.0.0/0) die verwijst naar het privé-IP-adres van de hubfirewall. Hierdoor wordt al het uitgaande verkeer, inclusief spoke-to-spoke-verkeer, door de firewall geleid voor logregistratie en filtering.

Limiet voor peering: Een virtueel netwerk met één hub ondersteunt maximaal 500 peeringverbindingen (standaardplatformlimiet). Als u Azure Virtual Network Manager (AVNM) gebruikt met een hub-spoke-connectiviteitsconfiguratie, wordt de limiet verhoogd tot 1000 spokes.

Hub-and-spoke met directe peering

In sommige architecturen hebben specifieke spoke-paren communicatie met lage latentie nodig zonder de hubfirewall te doorlopen. Voeg voor deze gevallen directe VNet-peering toe tussen het spoke-paar, of gebruik gekoppelde AVNM-groepen.

Gebruik directe spoke-peering wanneer:

• Twee workloads wisselen gegevens met een hoge doorvoersnelheid uit (bijvoorbeeld databasereplicatie tussen spokes).
• Latentie van de firewallhop is onaanvaardbaar voor een specifiek gegevenspad.
• U accepteert dat rechtstreeks gekoppeld verkeer de centrale firewallinspectie omzeilt.

Stempelpatroon (volledig geïsoleerd)

Het Stamps-patroon is een alternatief voor scenario's die strikte blast-radiusisolatie vereisen. Elke workload wordt geïmplementeerd in een volledig onafhankelijk virtueel netwerk zonder hub en geen peering naar andere workloads.

Wanneer gebruikt u stempels:

• Naleving van regelgeving vereist geen netwerkpad tussen workloads.
• Multitenant SaaS waarbij elke tenant een onafhankelijke stack heeft.
• Maximale foutisolatie: een fout in één stempel kan niet worden doorgegeven aan anderen.

Voorbeeld: Multitenant SaaS-isolatie

Een SaaS-provider host elke zakelijke klant in een toegewezen stempel. Elke stempel bevat een eigen VNet (10.x.0.0/16), toepassingsgateway, rekenlaag en database. Er bestaat geen VNet-peering tussen stamps, dus een onjuist geconfigureerde NSG of gecompromitteerde workload in de stamp van tenant A kan de resources van tenant B niet via het netwerk bereiken. De provider beheert stempels via Azure Resource Manager sjablonen en implementeert deze in afzonderlijke resourcegroepen of afzonderlijke abonnementen voor grote tenants. Gegevensuitwisseling tussen tenants maakt, indien nodig, gebruik van een gedeelde Azure Service Bus naamruimte. Elke stempel heeft toegang tot deze naamruimte via privé-eindpunten.

Compromissen:

• Geen gedeelde services. Elke stempel heeft een eigen firewall, gateway en Bastion-host nodig (indien nodig), waardoor de kosten toenemen.
• Geen communicatie tussen workloads via een privénetwerk.
• Operationele overhead neemt toe omdat u onafhankelijke netwerken beheert in plaats van gecentraliseerde infrastructuur.
• Kosten groeien lineair met het aantal stempels, omdat besparingen op gedeelde services niet van toepassing zijn.

Als uw workloads gedeelde services of communicatie tussen workloads nodig hebben, gebruik dan in plaats daarvan de standaard hub-and-spoke-variant.

Spoke-to-spoke-communicatiepatronen

Omdat VNet-peering niet-transitief is, vereist spoke-to-spoke-communicatie expliciete routering. In deze sectie wordt uitgelegd hoe verkeer tussen spokes stroomt met behulp van de hubfirewall.

Verkeersstroom: Spoke A naar Spoke B via de hub-firewall

De volgende reeks beschrijft hoe een pakket zich verplaatst van een VM in Spoke A (10.1.0.4) naar een VM in Spoke B (10.2.0.4):

1. Spoke A VM verzendt een pakket dat is bestemd voor 10.2.0.4. De effectieve routetabel van de virtuele machine bevat een UDR met 0.0.0.0/0 → 10.0.1.4 (de Azure Firewall privé-IP).
2. Het pakket gaat over de VNet-peeringverbinding van Spoke A naar de hub-VNet. Met peering kan verkeer het subnet van de firewall bereiken.
3. Azure Firewall ontvangt het pakket op de interne interface. Het pakket wordt geëvalueerd op basis van netwerkregels en toepassingsregels in volgorde van prioriteit.
4. Als een regel de stroom toestaat, stuurt de firewall het pakket door naar 10.2.0.4. Het pakket gaat over de peeringverbinding van hub naar Spoke-B.
5. Spoke B VM ontvangt het pakket. Het retourverkeer volgt hetzelfde pad in omgekeerde richting. De UDR van Spoke B stuurt het antwoord terug via de firewall.

De routetabellen configureren

Pas deze routetabellen toe om het voorgaande patroon in te schakelen:

1. Maak een routetabel voor spoke-subnetten. Schakel doorgifte van BGP-routes uit als u wilt voorkomen dat on-premises routes uw UDR's overschrijven.
2. Voeg een standaardroute (0.0.0.0/0) toe met het volgende hoptype VirtualAppliance en het volgende hopadres dat is ingesteld op het Azure Firewall privé-IP-adres.
3. Koppel de routetabel aan elk spoke-subnet dat andere spokes of internet moet bereiken.
4. Maak firewallnetwerkregels die het specifieke spoke-to-spoke-verkeer toestaan. Sta bijvoorbeeld 10.1.0.0/16 → 10.2.0.0/16 toe op poorten 443 en 1433.

Alternatief: met AVNM verbonden groepen voor rechtstreekse spoke-naar-spoke

Als u geen firewallinspectie tussen specifieke spokes nodig hebt, bieden verbonden AVNM-groepen een mesh-connectiviteitsmodel. Spokes in dezelfde verbonden groep communiceren rechtstreeks zonder de hub te doorlopen. Dit vermindert de vereisten voor latentie en firewalldoorvoer, maar omzeilt gecentraliseerde inspectie.

Gatewaydoorgang

Met gatewayoverdracht kunnen alle spokes één VPN- of ExpressRoute-gateway delen die in de hub is geïmplementeerd. Zonder gatewayoverdracht heeft elke spoke een eigen gateway nodig om on-premises netwerken te bereiken.

Configuratiestappen

1. Implementeer een VPN- of ExpressRoute-gateway in de hub GatewaySubnet.
2. Schakelt u op de peeringverbinding aan de hubzijde (hub → spoke) Gatewaytransit toestaan in.
3. Schakel op de peeringverbinding aan de spoke-zijde (spoke → hub) Externe gateways gebruiken in.
4. Routepropagatie controleren. Controleer na de configuratie de effectieve routes op een spoke-VM-NIC. In de routetabel ziet u on-premises voorvoegsels die zijn geleerd via de hubgateway met een volgend hoptype VNetGlobalPeering of VNetPeering.

Wanneer dit is geconfigureerd, worden routes die de hubgateway heeft geleerd (bijvoorbeeld on-premises prefixen van ExpressRoute) automatisch doorgegeven aan de routeringstabellen van spokes.

Beperkingen van Gateway-doorvoer

• Gatewayoverdracht werkt met alle VPN Gateway lagen behalve de Basic-laag. Als u de Basic-VPN Gateway gebruikt, kunt u deze niet delen met gekoppelde virtuele netwerken.
• Een virtueel spoke-netwerk kan slechts één externe gateway gebruiken. U kunt Use remote gateways niet inschakelen op een spoke die met meerdere hubs is gekoppeld.
• Als u UDR's gebruikt om verkeer via de firewall af te dwingen, moet u ervoor zorgen dat UDR de on-premises routes die door de gateway worden doorgegeven niet per ongeluk overschrijft. Stel indien nodig specifiekere routes in voor on-premises-prefixen.

Azure Virtual Network Manager op schaal

Wanneer uw omgeving uitgroeit tot meer dan een handvol spoke-netwerken, wordt het handmatig beheren van peeringverbindingen en routetabellen ingewikkeld. AVNM biedt automatisering voor hub-spoke-topologieën:

AVNM is vooral waardevol wanneer u hub-spoke-topologieën in meerdere regio's beheert of dynamisch lidmaatschap nodig hebt wanneer nieuwe virtuele spoke-netwerken online komen.

Overwegingen met betrekking tot schaalvergroting

Naarmate uw hub-spoke-topologie groeit, houdt u rekening met de volgende platformlimieten en organisatiepatronen:

Peering- en connectiviteitslimieten

Abonnementsorganisatie

• Verdeel spokes over workload-specifieke abonnementen voor omgevingen met meer dan 10 spokes. Hiermee worden facturerings-, RBAC- en quotumlimieten per workloadteam geïsoleerd.
• Gebruik een toegewezen connectiviteitsabonnement voor het hub-VNet, gateways en de firewall. Dit is het patroon dat wordt aanbevolen door Azure landingszones (platformabonnement).
• Groepsabonnementen onder een beheergroep, zodat AVNM spoke-VNets dynamisch kan detecteren en beheren in verschillende abonnementen met behulp van Azure Policy voorwaarden.

Topologie afdwingen met Azure Policy

Gebruik Azure Policy om configuratiedrift te voorkomen:

• Peering weigeren naar VNets die geen hub zijn. Wijs op beheergroepniveau een beleid toe dat het maken van VNet-peering blokkeert, tenzij het doelnetwerk het aangewezen hub-VNet is.
• Een UDR-koppeling vereisen Wijs een beleid toe dat spoke-subnetten controleert (of weigert) zonder een routetabel die de 0.0.0.0/0 → Firewall route bevat.
• AVNM-groepslidmaatschap afdwingen. Gebruik dynamische lidmaatschapsregels in AVNM op basis van tags (bijvoorbeeld NetworkRole:Spoke) zodat nieuwe VNets automatisch worden ingeschreven.

Migratiepad van een vlakke naar een hub-spoke-architectuur

Als u bent begonnen met een platte netwerktopologie en uw omgeving is uitgegroeid tot gedeelde services of segmentatie tussen werkbelastingen, volgt u dit migratiepad:

Stap 1: Het hub-VNet plannen

1. Wijs een nieuwe adresruimte toe voor de hub (bijvoorbeeld 10.0.0.0/16) die niet overlapt met uw bestaande platte VNet.
2. Bepaal welke gedeelde services moeten worden geïmplementeerd: firewall, gateway, Bastion, DNS-resolver.
3. Grootte van hubsubnetten per de indelingstabel van het hubsubnet .

Stap 2: Gedeelde services implementeren in de hub

1. Maak het hub-VNet en implementeer Azure Firewall (of de door u gekozen NVA).
2. Implementeer de VPN/ExpressRoute-gateway als u hybride connectiviteit nodig hebt.
3. Implementeer Azure Bastion voor beveiligde VM-toegang.
4. Configureer Privé-DNS Resolver als u aangepaste DNS gebruikt.

Stap 3: Werklasten naar spokes migreren

1. Maak spoke-VNets met nieuwe adresruimten voor elke workload. Als u de IP-adressen niet kunt wijzigen, kunt u de bestaande IP-bereiken behouden zolang ze niet overlappen met de hub.
2. Koppel elke spoke aan de hub. Schakel gatewayoverdracht aan de hubzijde in en gebruik externe gateways aan de spoke-zijde.
3. UDR's toepassen op spoke-subnetten met de standaardroute die verwijst naar de hubfirewall.
4. Verplaats of implementeer VM's en services opnieuw van het vlakke VNet naar de geschikte spoke. Gebruik Azure Resource Mover of opnieuw implementeren, afhankelijk van de complexiteit van de werkbelasting.
5. Maak firewallregels om de inter-spoke- en spoke-to-internet-verkeerspatronen toe te laten die u eerder in het platte VNet hebt toegestaan.

Stap 4: Het platte VNet buiten gebruik stellen

1. Controleer of alle workloads bereikbaar zijn via de nieuwe hub-spoke-topologie.
2. Werk DNS-records bij als privé-IP-adressen zijn gewijzigd.
3. Verwijder het oude platte VNet zodra u alle verkeer migreert en valideert.

Wanneer u in plaats daarvan rekening moet houden met Virtual WAN

Als uw hub-spoke-topologie steeds complexer wordt, beoordeel dan of Azure Virtual WAN beter aansluit:

Zie Azure Virtual WAN topologie voor een gedetailleerde vergelijking.

Ontwerpoverwegingen

Prerequisites

Voordat u een hub-and-spoke-netwerk ontwerpt:

• Voltooi uw virtuele netwerk- en subnetplan. Weet hoeveel spokes u nodig hebt en welke subnetten elke spoke nodig heeft.
• Definieer uw IP-adresschema. Hub- en spoke-adresruimten mogen niet overlappen.
• Begrijp dat VNet-peering niet transitief is: spokes nemen geen connectiviteit over met andere spokes via de hub.

Beveiligingsoverwegingen

Een hub-and-spoke-topologie centraliseert beveiligingsafdwinging in de hub. Pas deze principes toe:

• Routeer al het spoke-verkeer via de hubfirewall. Gebruik UDR's met de standaardroute die verwijst naar de firewall. Deze configuratie zorgt ervoor dat de firewall elke spoke-to-spoke- en spoke-to-internet-stroom inspecteert en registreert.
• Gebruik NSG's op spoke-subnetten als extra verdedigingslaag. Zelfs met een centrale firewall bieden netwerkbeveiligingsgroepen in spoke-subnetten een extra segmentatielaag. Onverwacht lateraal verkeer weigeren op subnetniveau. Zie Netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen voor richtlijnen voor het ontwerpen van NSG's.
• Schakel gatewayoverdracht met zorg in. Gatewaytransit stelt routes van het on-premises netwerk beschikbaar aan alle spokes. Zorg ervoor dat de firewallregels rekening houden met de uitgebreide verbindingsmogelijkheden.
• Verwijder openbare IP-adressen op spoke-VM's. Azure Bastion in de hub biedt beveiligde beheertoegang zonder vm's bloot te stellen aan internet.
• Beschouw elke spoke als een beveiligingsgrens. Werklasten in verschillende spokes blijven standaard geïsoleerd. Voor connectiviteit tussen spokes zijn expliciete routerings- en firewallregels vereist.

Verwante artikelen

• Platte netwerktopologie: voor individuele workloads die geen gedeelde services nodig hebben
• Azure Virtual WAN topologie: voor beheerde routering en connectiviteit op schaal
• Netwerken met meerdere regio's: voor workloads die meerdere Azure regio's omvatten
• VNets en subnetten: subnetgrootte voor hubonderdelen
• Planning van IP-adressen: CIDR-planning voor hub en spaken
• Netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen: diepgaande verdediging van spoke-subnetten

Meer informatie

• Hub-spoke-netwerktopologie in Azure
• Peering op virtueel netwerk
• Overzicht van Azure Firewall
• Overzicht van Azure Virtual Network Manager
• VPN Gateway doorvoer voor peering
• Azure Bastion en VNet-peering

Volgende stappen