Hub-spoke-netværkstopologi i Azure

Denne referencearkitektur beskriver en hub-spoke-topologi i Azure. Det virtuelle hub-netværk fungerer som et centralt punkt for tilslutning til mange virtuelle spoke-netværk. Navet kan også bruges som forbindelsespunkt til dine lokale netværk. De virtuelle spoke-netværk peerer med hubben og kan bruges til at isolere arbejdsbelastninger.

Fordelene ved at bruge en hub- og spoke-konfiguration omfatter omkostningsbesparelser, overvindelse af abonnementsgrænser og isolering af arbejdsbelastninger.

Referenceimplementering

Denne implementering omfatter et virtuelt hub-netværk og to peered spokes. Der er også implementeret en Azure Firewall og en Azure Bastion-vært. Eventuelt kan implementeringen omfatte virtuelle maskiner i det første spoke-netværk og 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

For detaljerede oplysninger og yderligere implementeringsmuligheder henvises til ARM-skabelonerne, der bruges til at implementere denne løsning.

Anvendelsestilfælde

Typiske anvendelser for denne arkitektur omfatter:

• Arbejdsmængder, der implementeres i forskellige miljøer, f.eks. udvikling, test og produktion, og som kræver delte tjenester som f.eks. DNS, IDS, NTP eller AD DS. Delte tjenester er placeret i det virtuelle hub-netværk, mens hvert miljø er implementeret i en spoke for at opretholde isolationen.
• Arbejdspakker, der ikke kræver forbindelse til hinanden, men som kræver adgang til delte tjenester.
• Virksomheder, der kræver central kontrol over sikkerhedsaspekter, f.eks. en firewall i hubben som en DMZ, og adskilt administration for arbejdsbelastningerne i hver spoke.

Arkitektur

Arkitekturen består af følgende komponenter.

Hub virtuelt netværk: Det virtuelle hub-netværk er det centrale punkt for tilslutning til dit lokale netværk og et sted at hoste tjenester, der kan bruges af de forskellige arbejdsbelastninger, der hostes i de virtuelle spoke-netværk.

Spoke virtuelle netværk: Spoke virtuelle netværk bruges til at isolere arbejdsbelastninger i deres egne virtuelle netværk, der administreres separat fra andre spokes. Hver arbejdsbelastning kan omfatte flere niveauer med flere undernet, der er forbundet via Azure load balancers.

Virtuelle netværks peering: To virtuelle netværk kan være forbundet ved hjælp af en peering-forbindelse. Peering-forbindelser er ikke-transitive forbindelser med lav latenstid mellem virtuelle netværk. Når de virtuelle netværk har peering-forbindelser, udveksler de virtuelle netværk trafik ved hjælp af Azure-backbone uden brug af en router.

Bastion Host: Azure Bastion: Med Azure Bastion kan du oprette sikker forbindelse til en virtuel maskine ved hjælp af din browser og Azure-portalen. En Azure Bastion-vært er implementeret i et Azure Virtual Network og kan få adgang til virtuelle maskiner i VNet’et eller virtuelle maskiner i peered VNets.

Azure Firewall: Azure Firewall er en administreret firewall som en tjeneste. Firewallinstansen er placeret i sit eget undernet.

VPN virtuel netværksgateway eller ExpressRoute-gateway. Den virtuelle netværksgateway gør det muligt for det virtuelle netværk at oprette forbindelse til den VPN-enhed eller det ExpressRoute-kredsløb, der bruges til at oprette forbindelse til dit lokale netværk. Du kan finde flere oplysninger under Opret forbindelse mellem et lokalt netværk og et virtuelt Microsoft Azure-netværk.

VPN-enhed. En enhed eller tjeneste, der leverer ekstern konnektivitet til det lokale netværk. VPN-enheden kan være en hardwareenhed eller en softwareløsning som f.eks. RRAS-tjenesten (Routing and Remote Access Service) i Windows Server 2012. Du kan finde flere oplysninger under Om VPN-enheder til Site-to-Site VPN Gateway-forbindelser.

Anbefalinger

De følgende anbefalinger gælder for de fleste scenarier. Følg disse anbefalinger, medmindre du har et specifikt krav, der tilsidesætter dem.

Ressourcegrupper

Den eksempelopløsning, der er medtaget i dette dokument, bruger en enkelt Azure-ressourcegruppe. I praksis kan hubben og hver spoke implementeres i forskellige ressourcegrupper og endda i forskellige abonnementer. Når du peer virtuelle netværk i forskellige abonnementer, kan begge abonnementer være tilknyttet den samme eller forskellige Azure Active Directory-forpagter. Dette giver mulighed for decentraliseret administration af hver arbejdsbyrde, mens du deler tjenester, der vedligeholdes i hubben.

Virtuelt netværk og GatewaySubnet

Opret et undernet med navnet GatewaySubnet med et adresseområde på /27. Gatewayen til det virtuelle netværk kræver dette undernet. Hvis du tildeler 32 adresser til dette undernet, kan du undgå at nå grænserne for gatewaystørrelsen i fremtiden.

For yderligere oplysninger om konfiguration af gatewayen kan du se følgende referencearkitekturer, afhængigt af din forbindelsestype:

• Hybridnetværk ved hjælp af ExpressRoute
• Hybridnetværk ved hjælp af en VPN-gateway

For at opnå højere tilgængelighed kan du bruge ExpressRoute plus en VPN til failover. Se Opret forbindelse mellem et lokalt netværk og Azure ved hjælp af ExpressRoute med VPN-failover.

En hub-spoke-topologi kan også bruges uden en gateway, hvis du ikke har brug for konnektivitet med dit lokale netværk.

Virtuel netværkspejling

Virtuel netværkspejling er et ikke-transitivt forhold mellem to virtuelle netværk. Hvis du har brug for, at spokes skal oprette forbindelse til hinanden, skal du overveje at tilføje en separat peering-forbindelse mellem disse spokes.

Men lad os antage, at du har flere spokes, der skal oprette forbindelse til hinanden. I det tilfælde vil du meget hurtigt løbe tør for mulige peering-forbindelser på grund af begrænsningen på antallet af peering-forbindelser pr. virtuelt netværk pr. virtuelt netværk. (Du kan finde flere oplysninger under Begrænsninger for netværk. I dette scenarie kan du overveje at bruge brugerdefinerede ruter (UDR’er) for at tvinge trafik, der er bestemt til en spoke, til at blive sendt til Azure Firewall eller en virtuel netværksappliance, der fungerer som router i hubben. Dette vil gøre det muligt for spokes at oprette forbindelse til hinanden.

Du kan også konfigurere spokes til at bruge hub-gatewayen til at kommunikere med fjernnetværk. For at tillade gateway-trafik at strømme fra spoke til hub og oprette forbindelse til fjernnetværk skal du:

• Konfigurere peering-forbindelsen i hubben til at tillade gateway-transit.
• Konfigurere peering-forbindelsen i hver spoke til at bruge fjerngateways.
• Konfigurere alle peering-forbindelser til at tillade videresendt trafik.

For yderligere oplysninger om oprettelse af peering af virtuelle netværk, se Opret VNet peerings.

Spoke-forbindelse

Hvis du har brug for forbindelse mellem spokes, skal du overveje at installere en Azure Firewall eller et andet virtuelt netværksapparat og oprette ruter til at videresende trafik fra spoke til firewallen/det virtuelle netværksapparat, som derefter kan videresende trafik til den anden spoke. I dette scenarie skal du konfigurere peering-forbindelserne til at tillade videresendt trafik.

Du kan også bruge en VPN-gateway til at videresende trafik mellem spokes, selv om dette vil påvirke latenstid og gennemstrømning. Se Konfigurer VPN-gatewaytransit til virtuel netværkspejling for at få konfigurationsoplysninger.

Overvej hvilke tjenester der deles i hubben for at sikre, at hubben skaleres til et større antal eger. Hvis din hub f.eks. leverer firewalltjenester, skal du overveje din firewallløsnings båndbreddebegrænsninger, når du tilføjer flere spokes. Du kan måske flytte nogle af disse delte tjenester til et andet niveau af hubs.

Operationelle overvejelser

Tænk på følgende, når du implementerer og administrerer hub- og spoke-netværk.

Netværksovervågning

Brug Azure Network Watcher til at overvåge og fejlfinde netværkskomponenterne, værktøjer som Traffic Analytics vil vise dig de systemer i dine virtuelle netværk, der genererer mest trafik, så du visuelt kan identificere flaskehalse, før de udarter til problemer. Network Performance Manager er det rette værktøj til at overvåge oplysninger om Microsoft ExpressRoute-kredsløb. VPN-diagnostik er et andet værktøj, der kan hjælpe med at fejlfinding af site-to-site VPN-forbindelser, der forbinder dine programmer med brugere på stedet.

Fors yderligere oplysninger kan du se Azure Network Watcher i Azure Well-Architected Framework.

Kostovervejelser

Tænk på følgende omkostningsrelaterede elementer, når du implementerer og administrerer hub- og spoke-netværk.

Azure Firewall

I denne arkitektur implementeres en Azure Firewall i hub-netværket. Når en Azure Firewall bruges som en delt løsning og forbruges af flere arbejdsbelastninger, kan en Azure Firewall spare op til 30-50 % i forhold til andre virtuelle netværksapparat. Du kan finde flere oplysninger under Azure Firewall vs. virtuel netværksappliance.

Virtuel netværkspejling

Du kan bruge virtuel netværkspejling til at dirigere trafik mellem virtuelle netværk ved hjælp af private IP-adresser. Her er nogle punkter:

• Ingress- og egress-trafik opkræves i begge ender af de peered netværk.
• De forskellige zoner har forskellige overførselshastigheder.

For eksempel vil dataoverførsel fra et virtuelt netværk i zone 1 til et andet virtuelt netværk i zone 2 medføre en udgående overførselshastighed for zone 1 og en indgående hastighed for zone 2. Du kan finde flere oplysninger under Prissætning af virtuelle netværk.