Nätverkstopologi med hub-spoke i Azure

Denna referensarkitektur beskriver en hub-spoke-topologi i Azure. Det virtuella hubbnätverket fungerar som en central anslutningspunkt för många virtuella spoke-nätverk. Navet kan också användas som anslutningspunkt till dina lokala nätverk. De virtuella spoke-nätverken är jämbördiga med hubben och kan användas för att isolera arbetsbelastningar.

Fördelarna med att använda en hubb- och spoke-konfiguration är bland annat kostnadsbesparingar, övervinnande av abonnemangsgränser och isolering av arbetsbelastningar.

Referensutplacering

Den här utplaceringen innehåller ett virtuellt nätverk med hubb och två spokes med jämbördiga nätverk. En Azure-brandvägg och en Azure Bastion-värd finns också installerade. Eventuellt kan distributionen inkludera virtuella maskiner i det första spaknätverket och en VPN-gateway.

az group create --name hub-spoke --location eastus

az deployment group create --resource-group hub-spoke \ --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/azure-hub-spoke/azuredeploy.json

New-AzResourceGroup -Name hub-spoke -Location eastus

New-AzResourceGroupDeployment -ResourceGroupName hub-spoke ` -TemplateUri https://raw.githubusercontent.com/mspnp/samples/master/solutions/azure-hub-spoke/azuredeploy.json

För detaljerad information och ytterligare distributionsalternativ, se ARM-mallarna som används för att distribuera den här lösningen.

Användningsfall

Typiska användningsområden för den här arkitekturen är:

• Arbetsbelastningar som distribueras i olika miljöer, t.ex. utveckling, testning och produktion, och som kräver delade tjänster som DNS, IDS, NTP eller AD DS. Delade tjänster placeras i det virtuella nätverket i navet, medan varje miljö distribueras till en spak för att upprätthålla isoleringen.
• Arbetsbelastningar som inte kräver konnektivitet med varandra men som kräver tillgång till delade tjänster.
• Företag som kräver central kontroll över säkerhetsaspekter, t.ex. en brandvägg i hubben som en DMZ, och segregerad hantering för arbetsbelastningarna i varje spoke.

Arkitektur

Arkitekturen består av följande komponenter.

Virtuellt hubbnät: Det virtuella hub-nätverket är den centrala anslutningspunkten till ditt lokala nätverk och en plats för att hysa tjänster som kan användas av de olika arbetsbelastningarna i de virtuella spoke-nätverken.

Virtuella spoke-nätverk: De virtuella nätverk som används för att hantera olika arbetsbelastningar är de virtuella nätverken: Spoke virtuella nätverk används för att isolera arbetsbelastningar i egna virtuella nätverk som hanteras separat från andra spokes. Varje arbetsbelastning kan innehålla flera nivåer, med flera undernät som är anslutna via Azure-lastutjämnare.

Virtuella nätverk med peering: Två virtuella nätverk kan anslutas med hjälp av en peering-anslutning. Peering-anslutningar är icke-transitiva anslutningar med låg latenstid mellan virtuella nätverk. När de virtuella nätverken väl är peered utbyter de virtuella nätverken trafik genom att använda Azures backbone utan behov av en router.

Bastion Host: Azure Bastion: Med Azure Bastion kan du säkert ansluta till en virtuell maskin med hjälp av din webbläsare och Azure-portalen. En Azure Bastion-värd distribueras i ett Azure Virtual Network och kan få tillgång till virtuella maskiner i VNet eller virtuella maskiner i peered VNets.

Azure Firewall: Azure Firewall är en hanterad brandvägg som en tjänst. Brandväggsinstansen placeras i ett eget subnät.

VPN virtuell nätverksgateway eller ExpressRoute-gateway. Den virtuella nätverksgatewayen gör det möjligt för det virtuella nätverket att ansluta till VPN-enheten, eller ExpressRoute-kretsen, som används för anslutning till ditt lokala nätverk. Mer information finns i Anslut ett lokalt nätverk till ett virtuellt Microsoft Azure-nätverk.

VPN-enhet. En enhet eller tjänst som tillhandahåller extern konnektivitet till det lokala nätverket. VPN-enheten kan vara en maskinvaruenhet eller en programvarulösning som RRAS-tjänsten (Routing and Remote Access Service) i Windows Server 2012. Mer information finns i Om VPN-enheter för Site-to-Site VPN Gateway-anslutningar.

Rekommendationer

Följande rekommendationer gäller för de flesta scenarier. Följ rekommendationerna om du inte har ett specifikt krav som åsidosätter dem.

Resursgrupper

Den exempellösning som ingår i det här dokumentet använder en enda Azure-resursgrupp. I praktiken kan hubben och varje spoke implementeras i olika resursgrupper och till och med i olika prenumerationer. När du peer virtuella nätverk i olika prenumerationer kan båda prenumerationerna associeras med samma eller olika Azure Active Directory-hyresgäster. Detta möjliggör decentraliserad hantering av varje arbetsbelastning samtidigt som tjänster som underhålls i navet delas.

Virtuellt nätverk och GatewaySubnet

Skapa ett undernät som heter GatewaySubnet, med ett adressintervall på /27. Det virtuella nätverkets gateway kräver det här undernätet. Genom att allokera 32 adresser till det här undernätet kan du undvika att nå begränsningar för gatewaystorlek i framtiden.

För mer information om hur du konfigurerar gatewayen, se följande referensarkitekturer, beroende på anslutningstyp:

• Hybridnätverk som använder ExpressRoute
• Hybridnätverk som använder en VPN-gateway

För högre tillgänglighet kan du använda ExpressRoute plus en VPN för växling. Se Anslut ett lokalt nätverk till Azure med ExpressRoute med VPN-failover.

En hub-spoke-topologi kan också användas utan en gateway om du inte behöver konnektivitet med ditt lokala nätverk.

Virtuellt nätverks peering

Virtuellt nätverks peering är en icke-transitiv relation mellan två virtuella nätverk. Om du vill att spokes ska ansluta till varandra kan du överväga att lägga till en separat peering-anslutning mellan dessa spokes.

Antag att du har flera spokes som behöver ansluta till varandra. I det fallet kommer du att få slut på möjliga peering-anslutningar mycket snabbt på grund av begränsningen av antalet virtuella nätverksjämförelser per virtuellt nätverk. (Mer information finns i Begränsningar för nätverk. I det här scenariot kan du överväga att använda användardefinierade rutter (UDR) för att tvinga trafik som är avsedd för en spoke att skickas till Azure Firewall eller en virtuell nätverksenhet som fungerar som en router vid hubben. På så sätt kan spokes ansluta till varandra.

Du kan också konfigurera spokes så att de använder hub-gatewayen för att kommunicera med fjärrnätverk. För att tillåta gateway-trafik att flöda från spoke till hubb och ansluta till fjärrnätverk måste du:

• Konfigurera peering-anslutningen i hubben så att gateway-transit tillåts.
• Konfigurera peering-anslutningen i varje spoke så att den använder fjärr-gateways.
• Konfigurera alla peering-anslutningar så att vidarebefordrad trafik tillåts.

För ytterligare information om hur du skapar peering av virtuella nätverk, se Skapa VNet peerings.

Spoke connectivity

Om du behöver konnektivitet mellan spokes, kan du överväga att distribuera en Azure-brandvägg eller en annan virtuell nätverksenhet och skapa rutter för att vidarebefordra trafiken från spoken till brandväggen/nätverksvirtuella enheten, som sedan kan dirigera till den andra spoke. I det här scenariot måste du konfigurera peering-anslutningarna så att de tillåter vidarebefordrad trafik.

Du kan också använda en VPN-gateway för att dirigera trafiken mellan spokes, även om detta kommer att påverka latenstid och genomströmning. Se Konfigurera VPN-gateway transit för peering av virtuella nätverk för konfigurationsuppgifter.

Konsultera vilka tjänster som delas i hubben för att se till att hubben skalar för ett större antal spokes. Om hubben till exempel tillhandahåller brandväggstjänster ska du ta hänsyn till brandväggslösningens bandbreddsgränser när du lägger till flera spokes. Du kanske vill flytta några av dessa delade tjänster till en andra nivå av hubbar.

Operationella överväganden

Tänk på följande när du distribuerar och hanterar hubb- och spoke-nätverk.

Nätverksövervakning

Använd Azure Network Watcher för att övervaka och felsöka nätverkskomponenterna.Verktyg som Traffic Analytics visar vilka system i dina virtuella nätverk som genererar mest trafik, så att du visuellt kan identifiera flaskhalsar innan de urartar till problem. Network Performance Manager är rätt verktyg för att övervaka information om Microsoft ExpressRoute-kretsar. VPN-diagnostik är ett annat verktyg som kan hjälpa dig att felsöka site-to-site VPN-anslutningar som ansluter dina program till användare på plats.

För mer information, se Azure Network Watcher i Azure Well-Architected Framework.

Kostnadsöverväganden

Tänk på följande kostnadsrelaterade punkter när du distribuerar och hanterar hubb- och spoke-nätverk.

Azure Firewall

I den här arkitekturen distribueras en Azure Firewall i hubbnätverket. När en Azure Firewall används som en delad lösning och konsumeras av flera arbetsbelastningar kan den spara upp till 30-50 % jämfört med andra virtuella nätverksapparater. Mer information finns i Azure Firewall vs network virtual appliance.

Virtuellt nätverk peering

Du kan använda virtuellt nätverk peering för att dirigera trafik mellan virtuella nätverk genom att använda privata IP-adresser. Här är några punkter:

• Ingress- och egress-trafik debiteras i båda ändarna av de peered-nätverken.
• Olika zoner har olika överföringshastigheter.

För dataöverföring från ett virtuellt nätverk i zon 1 till ett annat virtuellt nätverk i zon 2 till exempel, kommer det att uppstå en utgående överföringshastighet för zon 1 och en inkommande hastighet för zon 2. Mer information finns i Prissättning av virtuella nätverk.