Nätverkstopologi med nav och ekrar

Den här artikeln beskriver hur du utformar ett nav-och-ekernätverk i Azure. Ett centralt hubbvirtuellt nätverk hyser delade tjänster, medan isolerade virtuella ekernätverk hyser enskilda arbetsbelastningar.

Vad den här artikeln beskriver

Den här artikeln beskriver hubbbaserade delade tjänster för virtuella nätverk, ekerisolering och routningsmönster (standard, direkt peering och stämpelbaserad). Den omfattar även gatewayöverföring för hybridanslutningar och skalning av hub-spoke-topologier med Azure Virtual Network Manager.

Vem behöver den här artikeln

Läs den här artikeln om ett eller flera av dessa villkor gäller:

• Du behöver delade nätverkstjänster som brandvägg, DNS, Bastion, VPN Gateway eller ExpressRoute för flera arbetsbelastningar.
• Du vill centralisera trafikinspektion, routningskontroll eller administration i stället för att upprepa tjänsterna i varje virtuellt nätverk.
• Du behöver en upprepningsbar topologi för att separera delade plattformstjänster från arbetsbelastnings-VNets.
• Du vill jämföra hub-and-spoke med andra transitmodeller innan du standardiserar topologin.

Om du har en enda arbetsbelastning utan krav på delad tjänst börjar du med en platt nätverkstopologi i stället.

Azure tjänster och funktioner

I följande tabell visas de Azure tjänster och funktioner som stöder en topologi med nav och eker:

Så här fungerar det

I en topologi med nav och eker:

1. Ett virtuellt navnätverk fungerar som den centrala anslutningspunkten. Den innehåller delade nätverkstjänster som en brandvägg, gateway och Bastion-värd.
2. Virtuella spoke-nätverk är peerkopplade med hubben. Varje spoke innehåller en arbetsbelastning: en applikation, en teammiljö eller en isolerad tjänst.
3. VNet-peering är inte transitivt. Ekrar kan nå hubben, men de kan inte nå varandra direkt via hubben om du inte konfigurerar routning eller direkt sammankoppling mellan dem.

Vad som händer i det virtuella hubbnätverket

Använd följande tabell för att avgöra vilka tjänster som ska placeras i hubben:

Layout för hub-undernät

Ett väldesignad virtuellt hubbnätverk innehåller vanligtvis följande undernät:

Detaljerade riktlinjer för undernätsstorlek finns i VNet och undernät.

Så här väljer du en variant

Hub-and-spoke har tre vanliga varianter. Välj baserat på dina isolerings- och kommunikationskrav:

Standardnav-och-ekrar

Den här varianten är den vanligaste. All eker-till-eker-trafik passerar genom hubbens brandvägg för inspektion. Ekrar kommunicerar endast via hubben, aldrig direkt.

Routningsmönster: Tillämpa en användardefinierad väg (UDR) på varje ekerundernät med standardvägen (0.0.0.0/0) som pekar på hubbens brandväggs privata IP-adress. Detta tvingar all utgående trafik, inklusive spoke-till-spoke-trafik, genom brandväggen för loggning och filtrering.

Gränsen för peering: Ett virtuellt hubbnätverk stöder upp till 500 peeringanslutningar (standardplattformsgräns). Om du använder Azure Virtual Network Manager (AVNM) med en konnektivitetskonfiguration av typen hub-spoke höjs gränsen till 1 000 spokes.

Hub-and-spoke med direkt peer-koppling

I vissa arkitekturer behöver specifika ekerpar kommunikation med låg svarstid utan att behöva passera hubbens brandvägg. I dessa fall lägger du till direkt VNet-peering mellan ekerparet eller använder AVNM-anslutna grupper.

Använd direkt ekerpeering när:

• Två arbetslaster utbyter data med hög genomströmning (till exempel databasreplikering mellan spokes).
• Latensen från hoppet via brandväggen är oacceptabel för en specifik dataväg.
• Du godkänner att trafik via direkt peering kringgår inspektion i den centrala brandväggen.

Mönster för stämplar (helt isolerat)

Stamps-mönstret är ett alternativ för scenarier som kräver strikt isolering för att begränsa påverkan. Varje arbetsbelastning distribueras till ett helt oberoende virtuellt nätverk utan hubb och ingen peering till andra arbetsbelastningar.

När du ska använda stämplar:

• Regelefterlevnad kräver att det inte finns någon nätverksförbindelse mellan arbetsbelastningar.
• Multitenant-SaaS där varje hyresgäst har en oberoende stack.
• Maximal felisolering: ett fel i en stämpel kan inte spridas till andra.

Exempel: SaaS-isolering i flerklientmiljö

En SaaS-provider är värd för varje företagskund i en dedikerad stämpel. Varje stämpel innehåller ett eget VNet (10.x.0.0/16), en programgateway, en beräkningsnivå och en databas. Det finns ingen VNet-peering mellan distributioner, så en felkonfigurerad NSG eller en komprometterad arbetslast i Tenant A:s distribution kan inte nå Tenant B:s resurser via nätverket. Providern hanterar stämplar via Azure Resource Manager mallar och distribuerar dem till separata resursgrupper eller separata prenumerationer för stora klienter. Datautbyte mellan klientorganisationer, där det behövs, använder ett delat Azure Service Bus namnområde. Varje stamp får åtkomst till detta namnområde via privata slutpunkter.

Kompromisser:

• Inga delade tjänster. Varje stämpel behöver en egen brandvägg, gateway och Bastion-värd (om det behövs), vilket ökar kostnaden.
• Ingen kommunikation mellan arbetsbelastningar via privata nätverk.
• Driftkostnaderna ökar eftersom du hanterar oberoende nätverk i stället för centraliserad infrastruktur.
• Kostnaden växer linjärt med stämpelantal eftersom besparingar för delade tjänster inte gäller.

Om dina arbetsbelastningar behöver några delade tjänster eller kommunikation mellan olika arbetsbelastningar ska du i stället använda hub-and-spoke-standardvarianten.

Kommunikationsmönster mellan grennoder

Eftersom VNet-peering inte är transitiv kräver eker-till-eker-kommunikation explicit routning. Det här avsnittet går igenom hur trafiken flödar mellan spoke-nätverk med hjälp av hubbens brandvägg.

Trafikflöde: Eker A till eker B via hubbens brandvägg

I följande sekvens beskrivs hur ett paket överförs från en virtuell dator i Spoke A (10.1.0.4) till en virtuell dator i Spoke B (10.2.0.4):

1. VM:n i Spoke A skickar ett paket avsett för 10.2.0.4. Den virtuella datorns effektiva routningstabell innehåller en UDR med 0.0.0.0/0 → 10.0.1.4 (den Azure Firewall privata IP-adressen).
2. Paketet passerar över VNet-peeringlänken från Spoke A till hubb-VNetet. Peering gör att trafik kan nå brandväggens undernät.
3. Azure Firewall tar emot paketet i det interna gränssnittet. Det utvärderar paketet mot nätverksregler och programregler i prioritetsordning.
4. Om en regel tillåter flödet vidarebefordrar brandväggen paketet till 10.2.0.4. Paketet passerar hub-to-Spoke-B-peeringlänken.
5. Spoke B-VM:en tar emot paketet. Returtrafiken följer samma väg i omvänd riktning. Spoke B:s UDR skickar tillbaka svaret genom brandväggen.

Konfigurera routningstabellerna

Använd dessa routningstabeller för att aktivera föregående mönster:

1. Skapa en ruttabell för spoke-undernät. Inaktivera spridning av BGP-rutter om du vill förhindra att rutter från det lokala nätverket åsidosätter dina UDR:er.
2. Lägg till en standardväg (0.0.0.0/0) med nästa hopptyp VirtualAppliance och nästa hoppadress inställd på den Azure Firewall privata IP-adressen.
3. Associera routningstabellen med varje ekerundernät som behöver nå andra ekrar eller Internet.
4. Skapa nätverksregler för brandväggen som tillåter den specifika trafiken mellan ekrar. Tillåt till exempel 10.1.0.0/16 → 10.2.0.0/16 på portarna 443 och 1433.

Alternativ: AVNM-anslutna grupper för direkt eker-till-eker

Om du inte behöver brandväggsinspektion mellan specifika spokes erbjuder AVNM-anslutna grupper en mesh-anslutningsmodell. Spoke i samma sammankopplade grupp kommunicerar direkt utan att gå via hubben. Detta minskar kraven på svarstid och brandväggsdataflöde, men kringgår centraliserad inspektion.

Gatewaytransit

Med gatewayöverföring kan alla ekrar dela en enda VPN- eller ExpressRoute-gateway som distribueras i hubben. Utan gatewaytransit behöver varje spoke en egen gateway för att nå on-premises-nätverk.

Konfigurationssteg

1. Distribuera en VPN- eller ExpressRoute-gateway i hubbens GatewaySubnet.
2. På peeringanslutningen på hubbsidan (hubb → eker): aktivera Tillåt gatewaytransit.
3. På peeringanslutningen på ekersidan (eker → hubb): aktivera Använd fjärrgatewayer.
4. Kontrollera spridning av rutter. När konfigurationen är klar kontrollerar du de gällande routterna på nätverkskortet för en virtuell spoke-dator. Ruttabellen visar prefix från det lokala nätverket som har hämtats via hubbgatewayen med nästa hopptypen VNetGlobalPeering eller VNetPeering.

När de har konfigurerats sprids rutter som hubbgatewayen har lärt sig (till exempel prefix från det lokala nätverket via ExpressRoute) automatiskt till spoke-routingtabeller.

Begränsningar för gatewayöverföring

• Gatewayöverföring fungerar med alla VPN Gateway nivåer utom Basic-nivån. Om du använder Basic VPN Gateway kan du inte dela den med peerkopplade virtuella nätverk.
• Ett virtuellt spoke-nätverk kan bara använda en fjärrgateway. Du kan inte aktivera Use remote gateways på en spoke som peeras med flera hubbar.
• Om du använder UDR:er för att tvinga trafik genom brandväggen, se till att UDR inte oavsiktligt åsidosätter de gatewaypropagerade lokala nätverksrutterna. Ange mer specifika vägar för lokala prefix om det behövs.

Azure Virtual Network Manager i stor skala

När din miljö växer till fler än ett fåtal spokes blir det komplicerat att hantera peeringanslutningar och routningstabeller manuellt. AVNM tillhandahåller automatisering för hub-spoke-topologier:

AVNM är särskilt värdefullt när du hanterar hub-spoke-topologier i flera regioner eller behöver dynamiskt medlemskap när nya virtuella ekernätverk är online.

Skalningsöverväganden

När hub-spoke-topologin växer planerar du för följande plattformsgränser och organisationsmönster:

Gränser för peering och anslutning

Prenumerationsorganisation

• Dela upp ekrar i arbetsbelastningsspecifika prenumerationer för miljöer med fler än 10 ekrar. Detta isolerar fakturerings-, RBAC- och kvotgränser per arbetsbelastningsteam.
• Använd en dedikerad anslutningsprenumeration för hubbens virtuella nätverk, gatewayer och brandvägg. Det här är det mönster som rekommenderas av Azure landing zones (plattformsprenumeration).
• Gruppera prenumerationerna under en hanteringsgrupp så att AVNM dynamiskt kan upptäcka och hantera spoke-virtuella nätverk i flera prenumerationer med hjälp av villkor i Azure Policy.

Framtvinga topologi med Azure Policy

Använd Azure Policy för att förhindra konfigurationsavdrift:

• Neka peering till virtuella nätverk som inte är hubbar. Tilldela en princip på hanteringsgruppsnivå som blockerar skapande av VNet-peering om inte målet är det avsedda virtuella hubbnätverket.
• Kräv UDR-koppling. Tilldela en policy som granskar (eller nekar) spoke-undernät utan en routningstabell som innehåller rutten 0.0.0.0/0 → Firewall.
• Framtvinga AVNM-gruppmedlemskap. Använd regler för dynamiskt medlemskap i AVNM baserat på taggar (till exempel NetworkRole:Spoke) så att nya virtuella nätverk registreras automatiskt.

Migreringsväg från en platt struktur till en hubb-eker-modell

Om du började med en platt nätverkstopologi och din miljö har vuxit till att kräva delade tjänster eller segmentering mellan arbetsbelastningar följer du den här migreringsvägen:

Steg 1: Planera det virtuella hubbnätverket

1. Allokera ett nytt adressutrymme för hubben (till exempel 10.0.0.0/16) som inte överlappar ditt befintliga platta virtuella nätverk.
2. Avgör vilka delade tjänster som ska distribueras: brandvägg, gateway, Bastion, DNS-resolver.
3. Dimensionera undernäten i hubben enligt tabellen för hubbundernätets layout.

Steg 2: Distribuera delade tjänster i hubben

1. Skapa det virtuella hubbnätverket och distribuera Azure Firewall (eller din valda NVA).
2. Distribuera VPN/ExpressRoute-gatewayen om du behöver hybridanslutning.
3. Distribuera Azure Bastion för säker åtkomst till virtuella datorer.
4. Konfigurera Private DNS Resolver om du använder anpassad DNS.

Steg 3: Migrera arbetsbelastningar till ekrar

1. Skapa virtuella ekernätverk med nya adressutrymmen för varje arbetsbelastning. Om du inte kan re-IP kan du behålla befintliga intervall så länge de inte överlappar med hubben.
2. Anslut varje spoke till hubben. Aktivera gatewayöverföring på hubbsidan och använd fjärrgatewayer på ekersidan.
3. Använd UDR på ekerundernät med standardvägen som pekar på hubbens brandvägg.
4. Flytta eller omdistribuera virtuella datorer och tjänster från det platta VNet-et till den lämpliga spoken. Använd Azure Resource Mover eller omdistribuering, beroende på arbetsbelastningens komplexitet.
5. Skapa brandväggsregler för att tillåta de trafikmönster mellan spokes och från spoke till Internet som du tidigare tillät i det platta virtuella nätet.

Steg 4: Inaktivera det platta virtuella nätverket

1. Kontrollera att alla arbetslaster kan nås via den nya nav-ekertopologin.
2. Uppdatera DNS-poster om privata IP-adresser har ändrats.
3. Ta bort det gamla platta virtuella nätverket när du migrerar och verifierar all trafik.

När du ska överväga Virtual WAN i stället

Om din hub-spoke-topologi växer i komplexitet utvärderar du om Azure Virtual WAN erbjuder en bättre passform:

En detaljerad jämförelse finns i Azure Virtual WAN topologi.

Designöverväganden

Förutsättningar

Innan du utformar ett nav-och-ekernätverk:

• Slutför ditt virtuella nätverk och din undernätsplan. Vet hur många ekrar du behöver och vilka undernät varje eker kräver.
• Definiera ditt IP-adressschema. Adressutrymmena för hubb och ekrar får inte överlappa varandra.
• Förstå att VNet-peering inte är transitivt: ekrar ärver inte anslutning till andra ekrar via hubben.

Säkerhetsfrågor

En topologi med nav och eker centraliserar säkerhetstillämpningen i hubben. Tillämpa följande principer:

• Dirigera all trafik från spokarna genom hubbbrandväggen. Använd UDR:er med standardvägen som pekar på brandväggen. Den här konfigurationen säkerställer att brandväggen inspekterar och loggar varje trafikflöde mellan spokes och från spokes till internet.
• Använd NSG:er på undernät i ekrarna som ett extra skyddslager. Även med en central brandvägg ger nätverkssäkerhetsgrupper i ekerundernät ett extra segmenteringslager. Neka oväntad lateral trafik på undernätsnivå. Vägledning för NSG-design finns i Nätverkssäkerhetsgrupper och programsäkerhetsgrupper.
• Aktivera gatewaytransit med varsamhet. Gatewaytransit exponerar rutter i det lokala nätverket för alla spoke-nätverk. Kontrollera att brandväggsreglerna tar hänsyn till den utökade konnektiviteten.
• Ta bort offentliga IP-adresser på virtuella datorer i spoke-nätverket. Azure Bastion i hubben ger säker hanteringsåtkomst utan att exponera virtuella datorer för Internet.
• Behandla varje eker som en säkerhetsgräns. Arbetsbelastningar i olika ekrar förblir isolerade som standard. Anslutning mellan ekrar kräver explicit routning och brandväggsregler.

Relaterade artiklar

• Platt nätverkstopologi: för enskilda arbetsbelastningar som inte behöver delade tjänster
• Azure Virtual WAN topologi: för hanterad routning och anslutning i stor skala
• Nätverk i flera regioner: för arbetsbelastningar som sträcker sig över flera Azure regioner
• Virtuella nätverk och undernät: storlek på undernät för hubbkomponenter
• Planering av IP-adresser: CIDR-planering för hubbar och ekrar
• Nätverkssäkerhetsgrupper och programsäkerhetsgrupper: skiktat skydd på spoke-undernät

Learn more

• Nätverkstopologi av typen hub-spoke i Azure
• Peering för virtuella nätverk
• Översikt över Azure Firewall
• Översikt över Azure Virtual Network Manager
• VPN Gateway överföring för peering
• Azure Bastion- och VNet-peering

Nästa steg