Azure Virtual WAN-nätverkstopologi

Den här artikeln beskriver hur du utformar ett nätverk med Azure Virtual WAN. Virtual WAN tillhandahåller Microsoft hanterad hubbinfrastruktur med automatisk routning, inbyggd SD-WAN-integrering och inbyggd global överföring mellan hubbar.

Vad den här artikeln beskriver

Den här artikeln beskriver Virtual WAN hubbarkitektur, automatisk routning och routningsspridning, nivåjämförelse mellan Basic och Standard, routningssyfte för trafikinspektion, SD-WAN integrationsmönster och Virtual WAN kostnadsmodell.

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 hanterad trafikdirigering mellan många filialer, platser, fjärranvändare eller anslutna virtuella nätverk.
  • Du vill ha Microsoft-hanterad routning och grenanslutning i stället för att skapa och använda en anpassad överföringshubb själv.
  • Du måste jämföra Azure Virtual WAN med hub-and-spoke innan du förbinder dig till en topologi.
  • Du förväntar dig att nätverket växer utöver ett litet antal manuellt hanterade anslutningskanter.

Tip

Följer du en scenarioväg? Välj ditt scenario överst på sidan för skräddarsydd vägledning. Den grundläggande vägledningen som följer gäller för alla läsare.

Fokus för lift-and-shift: Hoppa över den här artikeln för en vanlig lift-and-shift-migrering. De flesta lift-and-shift-miljöer har färre än 30 grenanslutningar och fungerar i en eller två regioner. En traditionell topologi med nav och eker med VPN Gateway ger tillräcklig anslutning. Överväg bara Virtual WAN om du har många filialer eller planerar en snabb expansion.

Moderniseringsfokus: Den här artikeln blir relevant när ditt moderniseringsprogram innehåller transitkrav för grenskala eller flera regioner. En dubbel hubb- och ekertopologi med VPN-gateways i varje region hanterar de flesta moderniseringsscenarier. Virtual WAN blir relevant när du överskrider den routningskomplexitet som manuell UDR-hantering kan upprätthålla.

Fokus mellan moln: Virtual WAN är den rekommenderade överföringsmodellen när du har flera virtuella privata moln (VPN), grenar, regioner eller molnkanter. Virtual WAN fungerar som Azure motsvarar AWS Transit Gateway, vilket ger centraliserad routning och anslutningshantering i stor skala. Om du migrerar från en AWS-miljö som använder Transit Gateway Virtual WAN mappar direkt till den modellen.

Azure tjänster och funktioner

I följande tabell visas de Azure tjänster och funktioner som stöder en Virtual WAN topologi:

Tjänst eller funktion Roll i Virtual WAN Learn more
Azure Virtual WAN Tillhandahåller det hanterade globala överföringsnätverket och hubbinfrastrukturen Översikt över Virtual WAN
Virtuell hubb Microsoft hanterat virtuellt nätverk som är värd för routnings- och gatewaytjänster Routning för virtuell hubb
VPN Gateway (i hubben) Plats-till-plats- och punkt-till-plats-VPN-anslutning för avdelningskontor Virtual WAN VPN Gateway
ExpressRoute Gateway (i hubben) Privat anslutning från lokala datacenter via ExpressRoute-kretsar Virtual WAN ExpressRoute
Azure Brandväggshanterare Centraliserad hantering av säkerhetsprinciper för skyddade virtuella hubbar Översikt över Firewall Manager
Routningsavsikt Automatisk trafikstyrning via en säkerhetslösning utan anpassade routningstabeller Routnings avsikt

Så här fungerar det

Diagram som visar en Virtual WAN-topologi med två regionala hubbar, virtuella ekernät, filialer som är anslutna via VPN och ExpressRoute-kretsar. Trafik mellan hubbar dirigeras via Microsofts stamnät.

I en Virtual WAN topologi:

  1. En Virtual WAN resurs fungerar som en container på den översta nivån som grupperar en eller flera virtuella hubbar mellan regioner.
  2. Varje virtuell hubb är ett Microsoft hanterat virtuellt nätverk. Hubben innehåller tjänstslutpunkter för VPN-, ExpressRoute- och brandväggstjänster. Du distribuerar eller hanterar inte det virtuella hubbnätverket direkt.
  3. Virtuella ekernätverk ansluter till en virtuell hubb via VNet-anslutningar (liknar peering i traditionell hub-spoke). Routern för den virtuella hubben hanterar all routning automatiskt.
  4. Avdelningsplatser ansluter via plats-till-plats-VPN eller ExpressRoute-gatewayer som distribueras i den virtuella hubben.
  5. När du distribuerar flera hubbar ansluter de automatiskt via Microsoft stamnät, vilket möjliggör global överföring utan kundhanterad routning.

Routning av virtuell hubb

Routern för den virtuella hubben hanterar all routning mellan anslutna virtuella nätverk, grenar och andra hubbar. Viktiga beteenden:

  • Automatisk överföring: Virtuella nätverk som är anslutna till samma hubb kan kommunicera utan UDR. Hubbroutern sprider vägar mellan alla anslutningar som standard.
  • Transit mellan hubbar: Rutter sprids automatiskt mellan hubbar i samma Virtual WAN. Trafik mellan regioner flödar över Microsoft stamnät.
  • Routningstabeller: För avancerade isoleringsscenarier (till exempel isolera utveckling från produktion) kan du skapa anpassade routningstabeller i hubben för att styra routningsspridningen.
  • Aggregerat dataflöde: Den virtuella hubbroutern stöder upp till 50 Gbit/s aggregerat dataflöde när det konfigureras med maximalt 50 routningsinfrastrukturenheter. Standarddistributionen använder 2 routningsinfrastrukturenheter (3 Gbit/s). Du kan skala dataflödet genom att öka routningsinfrastrukturenheterna i hubbinställningarna.

Note

Automatisk routning gäller för standardöverföringsanslutning. Anpassade scenarier som dirigerar trafik via virtuella nätverksinstallationer (NVA) i hubben kan kräva anpassade routningstabeller.

Så här väljer du

Det här avsnittet hjälper dig att välja rätt topologi och nivå för din miljö.

Hub-spoke jämfört med Virtual WAN

Använd den här tabellen för att avgöra om en traditionell hub-spoke-topologi eller Virtual WAN är rätt val för din miljö:

Faktor Hub-and-spoke (traditionell) Azure Virtual WAN
Förvaltning Kundhanterat virtuellt hubbnätverk Microsoft-hanterad hubbinfrastruktur
Bäst för Upp till ~30 VPN-grenanslutningar Över 30 VPN-grenar eller många Azure regioner
Routing Kunden konfigurerar UDR för eker-till-eker-trafik Automatisk routning i den virtuella hubben
SD-WAN-integration Manuell NVA-distribution och konfiguration Inbyggd SD-WAN-partnerintegrering
Global överföring Kräver kundhanterad routning mellan regioner Inbyggd: alla hubbar ansluter automatiskt
Kostnadsmodell Hub VNet-resurser debiteras separat (Firewall, Gateway, Bastion) Prissättning för distributionsenhet och skalningsenhet

Tip

Virtual WAN är ett skalningsalternativ till hub-spoke, inte en ersättning. Organisationer med färre än 30 grenar, en enda region och ett behov av fullständig kontroll över hubbresurser bör använda en traditionell topologi med nav och ekrar.

Migreringsöverväganden: Om du flyttar från en traditionell hub-and-spoke-arkitektur till Virtual WAN, planera för en parallell migrering. Distribuera en Virtual WAN hubb tillsammans med din befintliga hubb, migrera ekeranslutningar stegvis och verifiera routning efter varje anslutningsmigrering. Virtual WAN stöder inte import av befintliga UDR-konfigurationer, så du måste göra om routningen för att använda hubbrouterns automatiska spridningsmodell.

När du ska stanna med hub-spoke: Välj traditionell hub-spoke om du behöver detaljerad kontroll över det virtuella hubbnätverket (till exempel distribuera anpassade NVA:er direkt i hubbundernätet), om din organisation arbetar i en enda region med färre än 10 grenar eller om efterlevnadskrav kräver kundhanterad routningsinfrastruktur.

Standard jämfört med Basic-nivån

Virtual WAN erbjuder två nivåer. Välj den nivå som passar dina routnings- och anslutningsbehov:

Feature Grundläggande Standard
Plats-till-plats-VPN ✅ ✅
Punkt-till-plats-VPN ❌ ✅
ExpressRoute ❌ ✅
VNet-till-VNet-överföring ❌ ✅
Överföring mellan hubbar ❌ ✅
Azure Firewall i hub ❌ ✅
NVA i hub ❌ ✅

Important

Du kan uppgradera från Basic till Standard-nivån, men du kan inte nedgradera från Standard till Basic. Välj Standard om du behöver transitroutning, ExpressRoute-anslutning eller säkerhetsintegrering.

Kostnadsmodell

Virtual WAN använder enhetsbaserad prissättning som skiljer sig från traditionell hub-spoke:

  • Distributionsenheter (hubb): Du betalar en avgift per timme för själva den virtuella hubben. Den här avgiften är en fast kostnad för infrastrukturen för den hanterade hubben.
  • Skalningsenheter (gatewayer): VPN- och ExpressRoute-gatewayer faktureras baserat på antalet skalningsenheter som du etablerar. Fler skalningsenheter ökar bandbreddskapaciteten och kostnaderna proportionellt.
  • Routningsinfrastrukturenheter: Hubbrouter debiteras per routningsinfrastrukturenhet. Standarddistributionen innehåller två enheter (3 Gbit/s). Du kan skala upp till 50 enheter (50 Gbit/s) för miljöer med högt dataflöde.
  • Databearbetning: Du betalar för data som bearbetas via hubben, inklusive VNet-till-VNet, branch-to-VNet och trafik mellan hubbar. Internetbunden trafik som dirigeras via Azure Firewall har separata databehandlingsavgifter.
  • Skyddat tillägg för virtuell hubb: När du distribuerar Azure Firewall via Firewall Manager gäller även standardavgifter för Azure Firewall för Virtual WAN hubbkostnader.

Jämför kostnader med en traditionell hub-spoke-topologi. För små driftsättningar med få filialer kan ett kundhanterat nav vara mer kostnadseffektivt. För ett stort antal filialer (30+) uppväger vanligtvis Virtual WAN:s automatisering och hanterade infrastruktur priset per enhet. Detaljerade priser finns i Virtual WAN prissättningsbegrepp.

Säker virtuell hubb: när du ska använda Firewall Manager

En säker virtuell hubb integrerar Azure Firewall (eller en NVA som stöds) med Firewall Manager för centraliserad princip:

Configuration Använd när Förmån
Standard Virtual Hub (ingen brandvägg) Endast anslutning från filial till VNet, säkerhet hanteras på spoke-nivå Enklast distribution, lägsta kostnad
Säker virtuell hubb med Firewall Manager Centraliserad trafikkontroll för privat trafik och Internettrafik Konsekvent policy och routningsavsikt eliminerar behovet av UDR:er
Säker virtuell hubb med NVA-partner Befintlig brandväggsinvestering från tredje part, specifika funktionskrav Använda befintliga leverantörsverktyg och expertis

Routningsavsikt

Routnings avsikt förenklar trafikkontrollen i Virtual WAN genom att automatiskt styra trafiken via en säkerhetslösning (Azure Firewall eller nva som stöds) utan anpassade routningstabeller eller UDR:er.

När du aktiverar routningssyfte deklarerar du principer för två trafiktyper:

  • Internettrafik: All internetbunden trafik från anslutna virtuella nätverk dirigeras via säkerhetslösningen i hubben.
  • Privat trafik: All trafik mellan virtuella nätverk, grenar och andra hubbar dirigerar via säkerhetslösningen.

Routningsavsikt eliminerar behovet av att hantera routningstabeller manuellt. Virtual WAN:s kontrollplan konfigurerar automatiskt alla nödvändiga rutter mellan alla de anslutna hubbarna och de virtuella ekernätverken.

Note

Routningsavsikt kräver en skyddad virtuell hubb med Azure Firewall eller en NVA-partner som stöds. Den är bara tillgänglig på standardnivån.

Varning

De ändringar i routningstabellen som routnings avsikten gör är oåterkalleliga. Du kan ta bort routnings avsikten, men om du tar bort den återställs inte din tidigare defaultRouteTable-konfiguration automatiskt. Spara en ögonblicksbild av konfigurationen innan du aktiverar routnings avsikten, eftersom du måste återställa eventuella tidigare vägar manuellt om du senare tar bort den.

Anslutningsgränser och skalbarhet

Virtual WAN stöder storskaliga distributioner:

  • Upp till 1 000 VPN-anslutningar från plats till plats per virtuell hubb.
  • Flera hubbar per Virtual WAN (en per region eller flera per region för isolering).
  • Upp till 50 Gbit/s aggregerat dataflöde per hubbrouter (kräver högst 50 routningsinfrastrukturenheter. Standardvärdet är 2 enheter på 3 Gbit/s).
  • Alla-till-alla-anslutningar över alla VNet-anslutningar, VPN-grenar och ExpressRoute-kretsar i samma hubb.

För organisationer som överskrider gränserna för en enda hubb distribuerar du ytterligare hubbar i samma eller olika regioner. Virtual WAN hanterar automatiskt routning mellan hubbar.

SD-WAN-partnerintegration

Virtual WAN tillhandahåller intern integrering med SD-WAN partnerenheter. Partnerenheter kan:

  • Exportera information om grenenheter till Azure programmatiskt.
  • Ladda ned Azure konfigurationen automatiskt.
  • Upprätta IPsec/IKE-anslutning till den virtuella hubben utan manuell konfiguration.

Den här automatiseringen minskar driftsättningstiden för grenar från dagar till minuter, även i stor skala. Den aktuella listan över partner som stöds finns i Virtual WAN partner.

Så här fungerar partnerautomatisering

SD-WAN-partner använder API:et för automatisering av Virtual WAN-anslutning för att programmässigt hantera filialenheternas livscykler:

  • Enhetsregistrering: Partnerstyrenheten registrerar grenenheter med den Virtual WAN resursen, inklusive enhetsmetadata och bandbreddskrav.
  • Konfigurationsnedladdning: Partnerplattformen hämtar hubbgatewaykonfiguration (IP-adresser, i förväg delade nycklar, BGP-inställningar) utan manuell portalinteraktion.
  • Tunneletablering: Partnerenheten upprättar IPsec-tunnlar till VPN-gatewayen för virtuell hubb med hjälp av den nedladdade konfigurationen.
  • Löpande hälsoövervakning: Partnerplattformen övervakar tunnlarnas status och kan återansluta om tunnlarna kopplas ner.

Partner som VMware SD-WAN, Fortinet SD-WAN, Cisco Viptela och Versa Networks stöder den här automatiseringsmodellen. Varje partner implementerar ett eget orkestreringslager ovanpå Virtual WAN-API:et. Utvärdera partnerspecifika funktioner, till exempel programmedveten routning, trafikoptimering och lokal Internet-utbrytning innan du väljer en partner.

Designöverväganden

För de flesta lift-and-shift-migreringar är Virtual WAN inte starttopologin. Utvärdera när det blir berättigat:

  • När Virtual WAN blir berättigad. Om din lift-and-shift-miljö omfattar fler än 30 filialkontor, sträcker sig över tre eller fler Azure-regioner eller kräver integrering med SD-WAN, minskar Virtual WAN:s automatiserade routning den operativa belastningen jämfört med att hantera UDR:er över många hub-and-spoke-peerings.
  • Hub-spoke räcker för mindre egendomar. En enda hubb med VPN Gateway hanterar upp till 30 plats-till-plats-anslutningar och 500 eker-peerings. Om migreringen ligger inom dessa gränser är traditionell hub-spoke enklare och mer kostnadseffektiv.
  • En migreringsväg finns. Om du börjar med hub-spoke och senare behöver Virtual WAN kan du migrera genom att distribuera en Virtual WAN hubb tillsammans med din befintliga hubb och flytta ekeranslutningar stegvis.

Distributioner i flera regioner kräver inte automatiskt Virtual WAN. Utvärdera routningskomplexiteten:

  • Dubbel hub-spoke räcker ofta. För aktiva-aktiva arkitekturer med två regioner etablerar du en hubb i varje region med VNet-peering mellan hubbarna. Det här mönstret hanterar de flesta moderniseringsscenarier utan Virtual WAN priskostnader per enhet.
  • När komplexiteten rör sig mot Virtual WAN. Om moderniseringen växer bortom två regioner, lägger till grenanslutningar mellan regioner eller kräver automatisk spridning mellan hubbar utan manuell UDR-hantering Virtual WAN förenklar åtgärderna.
  • Blanda inte ihop flera regioner med Virtual WAN. Beslutet att använda Virtual WAN beror på antalet grenar, antalet regioner och routningskomplexiteten. Enbart flera regioner är inte tillräcklig motivering.

Virtual WAN tillhandahåller den Azure motsvarigheten till AWS Transit Gateway för centraliserad, skalbar överföring:

  • Transit Gateway-ekvivalens. Virtual WAN:s virtuella hubb fungerar som AWS Transit Gateway: den dirigerar automatiskt trafik mellan anslutna virtuella nätverk, filialer och VPN-tunnlar mellan moln. Om du migrerar från AWS förenklar den här mappningen din arkitekturöversättning.
  • Säkert virtuellt nav (Secured Virtual Hub). Distribuera Azure Firewall via Firewall Manager i den virtuella hubben. Aktivera routningsavsikt för att dirigera all privat trafik och internettrafik via brandväggen. Detta ger centraliserad inspektion för trafik mellan moln som går in i Azure.
  • VPN-anslutningar till Google Cloud och AWS. Skapa PLATS-till-plats-VPN-anslutningar från Virtual WAN hubben till Google Cloud VPN (HA VPN) och AWS Virtual Private Gateways. Virtual WAN stöder upp till 1 000 VPN-anslutningar per hubb, vilket ger utrymme för tillväxt när du migrerar fler arbetsbelastningar.
  • Planering för flera regioner. Distribuera virtuella hubbar i varje Azure region där migrerade program landar. Routning mellan hubbar sprids automatiskt över Microsoft stamnät, vilket speglar transitgatewayens peeringmodell i AWS.

Förutsättningar

Innan du implementerar en Virtual WAN-topologi:

  • Förstå hub-spoke-begrepp. Virtual WAN bygger på hub-spoke-modellen. Granska hub-and-spoke-topologi för att få en förståelse för de grundläggande koncepten.
  • Inventera dina avdelningsplatser. Dokumentera antalet grenar, deras geografiska distribution och aktuell anslutning (VPN, MPLS, SD-WAN).
  • Definiera din regionstrategi. Ta reda på vilka Azure regioner som är värdar för arbetsbelastningar och var du behöver virtuella hubbar.
  • Välj din nivå. Bestäm mellan Basic (endast plats-till-plats-VPN) och Standard (fullständig överföring, ExpressRoute, brandvägg) baserat på nivåjämförelsetabellen i den här artikeln.
  • Utvärdera säkerhetskrav. Avgör om centraliserad inspektion (Secured Virtual Hub) eller säkerhet per spoke är lämplig.

Säkerhetsfrågor

  • Säker virtuell hubb. Distribuera Azure Firewall via Firewall Manager för att tillämpa konsekventa säkerhetsprinciper i alla anslutna virtuella nätverk och grenar. Firewall Manager tillhandahåller centraliserad regelhantering över flera säkra hubbar.
  • Routnings avsikt. Aktivera routningsavsikt för att automatiskt styra privat trafik och internettrafik via din säkerhetslösning. Den här metoden förhindrar att trafik kringgår inspektionen genom att eliminera manuell routningskonfiguration.
  • Begränsningar för NVA-in-hub Virtuella nätverksinstallationer som distribueras i hubben har andra funktioner än Azure Firewall. Kontrollera funktionspariteten med dina säkerhetskrav innan du väljer en NVA-partner.
  • SD-WAN säkerhetsmodell. När du integrerar SD-WAN partnerenheter beror trafiksäkerheten på partnerns implementering. Utvärdera partnerns funktioner för kryptering, autentisering och trafikkontroll.
  • Trafikisolering mellan hubbar. Trafik mellan virtuella hubbar flödar över Microsoft stamnät och passerar inte det offentliga Internet. Stamnätet är ett privat nätverk, men trafiken krypteras inte på nätverksskiktet som standard. Använd TLS på programnivå för känsliga data mellan regioner.

Learn more

Nästa steg

Tip

Utforska på egen hand? Gå tillbaka till översiktsnavigatorn för att hitta nästa artikel efter funktion.

Nästa steg i din lift-and-shift-resa:

Hybridanslutning: Anslut dina migrerade arbetsbelastningar tillbaka till den lokala miljön via VPN Gateway eller ExpressRoute.

Nästa steg i moderniseringsresan:

Planera distribution över flera regioner: Utöka din lösning över flera regioner för aktiv-aktiv-resiliens.

Nästa steg i din molnöverskridande resa:

Designa VNets i Azures landningszon: Skapa grunden för det virtuella Azure-nätverket för dina anslutna och migrerade arbetsbelastningar.

  • Last updated on