Designfas 1: Anslut ivitet med lokala platser

Artikel
09/30/2023

Anslut ivity med lokala datacenter är det mest kritiska designområdet för Azure VMware Solution-nätverk. De viktigaste kraven som måste åtgärdas är:

Högt dataflöde: Migreringar från lokala vSphere-miljöer och haveriberedskapslösningar kräver att stora mängder data flyttas mellan lokala platser och privata Moln i Azure VMware Solution snabbt.
Låg svarstid: Distribuerade program kan kräva låg svarstid för anslutningar mellan virtuella Azure VMware Solution-datorer och lokala system.
Prestandaförutsägbarhet: För att uppnå förutsägbart dataflöde och svarstider kan affärskritiska program som distribueras i Azure VMware Solution kräva dedikerade anslutningstjänster (Azure ExpressRoute) mellan lokala platser och Microsoft-nätverket.

I den här artikeln beskrivs de alternativ som stöds av Azure VMware Solution för anslutning till lokala platser:

ExpressRoute Global Reach
IPSec-VPN:er
Överföring över privat ExpressRoute-peering

Alternativen presenteras i ordning för att minska möjligheten att uppfylla de viktigaste kraven som angavs tidigare. Ett alternativ bör ignoreras och nästa alternativ bör endast tas bort om det står i konflikt med de icke-förhandlingsbara begränsningarna i ett specifikt scenario.

Det här flödesschemat sammanfattar processen för att välja ett hybridanslutningsalternativ för Azure VMware Solution:

ExpressRoute Global Reach

ExpressRoute Global Reach är standardalternativet för hybridanslutning som stöds av Azure VMware Solution. Den ger, med minimal komplexitet, Layer 3-anslutning mellan ett privat Azure VMware Solution-moln och en fjärrplats som är ansluten till en kundhanterad ExpressRoute-krets. Du kan också använda den kundhanterade ExpressRoute-kretsen för att ansluta till inbyggda Azure-tjänster. För att förbättra säkerheten eller reservera bandbredden kan du även distribuera en separat kundhanterad krets som uteslutande är dedikerad till Azure VMware Solution-trafik.

Följande diagram visar en nätverkstopologi som använder Global Reach för anslutning till lokala platser. Trafik mellan privata Azure VMware Solution-moln och lokala platser passerar inte virtuella Azure-nätverk.

Kommentar

För maximal återhämtning bör två kundhanterade ExpressRoute-kretsar på olika peeringplatser användas för att ansluta lokala datacenter till Microsofts stamnät. I det här fallet bör varje kundhanterad ExpressRoute-krets ha en Global Reach-anslutning till det privata Azure VMware Solution-molnet (och till Azure Virtual Networks). Läs den här artikeln om du vill ha vägledning om elastiska ExpressRoute-implementeringar.

Anvisningar om hur du ansluter ett privat Azure VMware Solution-moln till en kundhanterad ExpressRoute-krets med hjälp av Global Reach finns i Peer on-premises environments to Azure VMware Solution (Peer on-premises environments to Azure VMware Solution).

Global Reach-anslutning uppfyller helt de tre nyckelkraven:

Högt dataflöde: Med ExpressRoute kan du ansluta till Microsoft-nätverket från din lokala plats via dedikerade linjer (upp till 10 Gbit/s för providerbaserad ExpressRoute eller 100 Gbit/s för ExpressRoute Direct).
Låg svarstid: Med Global Reach kan du dirigera trafik direkt från gränsen för Microsoft-nätverket till Azure VMware Solution vSphere-kluster. Global Reach minimerar antalet nätverkshopp mellan lokala platser och privata moln.
Förutsägbar prestanda: När du använder ExpressRoute Global Reach dirigeras trafiken via länkar som inte drabbas av överbelastningsproblem (upp till den maximala etablerade kapaciteten). Därför förblir rtt-tiden (round-trip time) mellan virtuella datorer som körs på Azure VMware Solution och lokala värdar konstant över tid.

Du kan inte använda Global Reach i scenarier där en eller flera av följande begränsningar gäller:

ExpressRoute Global Reach är inte tillgängligt i Azure-regionen i det privata Azure VMware Solution-molnet eller platsen för den kundhanterade ExpressRoute-kretsen. Det finns inga lösningar för den här begränsningen. Mer uppdaterad information om global räckvidd finns i Om ExpressRoute Global Reach .
Det finns icke-förhandlingsbara krav på nätverkssäkerhet. Om en brandväggsenhet inte kan distribueras på den lokala sidan av den kundhanterade ExpressRoute-kretsen exponerar Global Reach alla Azure VMware Solution-nätverkssegment, inklusive hanteringsnätverk (vCenter Server och NSX-T-hantering), för hela nätverket som är anslutet till kretsen. Det vanligaste scenariot där det här problemet uppstår är när kundhanterade ExpressRoute-kretsar implementeras ovanpå MPLS-nätverkstjänster (kallas även ExpressRoute any-to-any-anslutningsmodell). Det här scenariot visas här:

När ExpressRoute-anslutningen implementeras ovanpå MPLS IPVPN är det omöjligt att distribuera brandväggar på en enda plats för att inspektera all trafik till och från Azure VMware Solution. Vanligtvis distribuerar organisationer som använder MPLS-nätverk brandväggar i stora datacenter, inte på alla sina platser (som kan vara små grenar, kontor eller butiker).

IPSec-VPN:er

Du kan implementera anslutningen mellan privata Moln i Azure VMware Solution och lokala platser genom att dirigera trafik via ett virtuellt transitnätverk i Azure. Överföringsnätverket är anslutet till det privata Azure VMware Solution-molnet via den hanterade ExpressRoute-kretsen. Det virtuella överföringsnätverket är anslutet till den lokala platsen via en IPSec VPN, som du ser här:

Du kan tillämpa säkerhetsprinciper för anslutningar mellan lokala platser och det privata Azure VMware Solution-molnet (den streckade linjen i diagrammet) genom att dirigera trafik via en brandvägg, om VPN-enheten inte tillhandahåller brandväggsfunktioner. Den här konfigurationen kräver Azure Virtual WAN med routnings avsikt, enligt beskrivningen i avsnittet Bestäm var de virtuella enheterna ska finnas i Azure i den här artikeln.

Innan du implementerar IPSec-anslutning mellan lokala platser och överföring av virtuella nätverk måste du fatta tre designbeslut:

Ta reda på vilken nätverkstjänst som ska användas som underlägg för IPSec-tunneln. De tillgängliga alternativen är Internetanslutning, ExpressRoute Microsoft-peering och privat ExpressRoute-peering.
Ta reda på var de virtuella enheter som avslutar IPSec-tunneln på Azure-sidan ska hanteras. Bland de tillgängliga alternativen finns kundhanterade virtuella nätverk och Virtual WAN-hubbar.
Ta reda på vilken virtuell enhet som avslutar IPSec-tunneln på Azure-sidan. Valet av enhet avgör också vilken Azure-konfiguration som krävs för att dirigera trafik mellan IPSec-tunneln och den hanterade Azure VMware Solution-kretsen. De tillgängliga alternativen är inbyggd Azure VPN Gateway och IPSec NVA från tredje part (virtuella nätverksinstallationer).

Det här flödesschemat sammanfattar beslutsprocessen:

Kriterierna för att fatta dessa beslut beskrivs i följande avsnitt.

Välj en underläggsnätverkstjänst

Vi rekommenderar starkt att du överväger de tre alternativen för VPN-underlägget i den ordning som visas här:

Internetanslutning. Den offentliga IP-adress som tilldelats vpn-enheten som finns i det virtuella transitnätverket fungerar som fjärrslutpunkt för IPSec-tunneln. På grund av dess låga komplexitet och kostnad bör du alltid testa och utvärdera Internetanslutningen för prestanda (uppnåeligt IPSec-dataflöde). Du bör bara stänga det här alternativet när den observerade prestandan är för låg eller inkonsekvent. Följande diagram illustrerar det här alternativet.
ExpressRoute Microsoft-peering. Det här alternativet ger Layer 3-anslutning till offentliga Azure-slutpunkter via dedikerade länkar. Precis som internetanslutningar kan du nå den offentliga IP-adressen för en VPN-enhet som fungerar som fjärrslutpunkt för IPSec-tunneln och som finns i det virtuella transitnätverket. Du bör bara stänga det här alternativet när Microsoft-peeringens routningskrav inte kan uppfyllas. Följande diagram illustrerar det här alternativet.
Privat ExpressRoute-peering. Det här alternativet ger Layer 3-anslutning mellan en lokal plats och virtuella Azure-nätverk via dedikerade länkar. Därför kan du upprätta en IPSec-tunnel från den lokala platsen till den privata IP-adressen för en VPN-enhet som finns i ett virtuellt nätverk. Privat ExpressRoute-peering kan medföra bandbreddsbegränsningar eftersom ExpressRoute-gatewayen finns i datasökvägen. Du kan använda ExpressRoute FastPath för att lösa det här problemet. Privat peering kräver också mer komplex routningskonfiguration på den lokala sidan. Mer information finns i Konfigurera en plats-till-plats-VPN-anslutning via privat ExpressRoute-peering. Följande diagram illustrerar det här alternativet.

Bestämma var de virtuella enheterna ska finnas i Azure

Bland de tillgängliga alternativen finns kundhanterade virtuella nätverk och Virtual WAN-hubbar. För att fatta det här beslutet bör du överväga egenskaperna för den befintliga Azure-miljön, om det finns en, och hur du vill prioritera att minska hanteringsarbetet jämfört med din förmåga att skräddarsy konfigurationen efter specifika behov. Följande är några viktiga överväganden.

Du bör använda befintlig Azure-nätverksinfrastruktur för Azure VMware Solution-anslutning. Om det redan finns ett kundhanterat hub-spoke-nätverk i samma region som det privata Azure VMware Solution-molnet bör du distribuera IPSec-avslutningsenheterna i den befintliga hubben. Om det finns ett hub-spoke-nätverk som baseras på Virtual WAN i samma region som det privata Azure VMware Solution-molnet bör du använda Virtual WAN-hubben för IPSec-avslutning.
För att dirigera trafik mellan en IPSec-tunnel och den hanterade ExpressRoute-kretsen i ett kundhanterat hub-spoke-nätverk måste du distribuera en Azure Route Server-instans i det virtuella hubbnätverket och konfigurera den för att tillåta trafik från gren till gren. Det går inte att dirigera trafik mellan privata Azure VMware Solution-moln och lokala platser via brandväggsenheter som distribueras i det virtuella nätverket.
Virtual WAN-hubbar har inbyggt stöd för routning av trafik mellan IPSec-tunneln som är ansluten till den lokala platsen och Azure VMware Solution-hanterade ExpressRoute-kretsen.
Om du använder Virtual WAN kan du konfigurera routnings- och routningsprinciper för trafikkontroll. Du kan använda Azure Firewall eller säkerhetslösningar från tredje part som stöds av Virtual WAN. Vi rekommenderar att du granskar den regionala tillgängligheten och begränsningarna för routnings avsikten.

Bestäm vilken virtuell enhet som avslutar IPSec-tunneln

IPSec-tunneln som tillhandahåller anslutning till den lokala platsen kan avslutas av Azure VPN Gateway eller av nva:er från tredje part. För att fatta det här beslutet bör du överväga egenskaperna för den befintliga Azure-miljön, om det finns en, och hur du vill prioritera att minska hanteringsarbetet jämfört med din förmåga att skräddarsy konfigurationen efter specifika behov. Följande är några viktiga överväganden.

I både hub-spoke-nätverk som är kundhanterade nätverk och hub-spoke-nätverk som baseras på Virtual WAN kan du använda Azure VPN Gateway för att avsluta IPSec-tunnlar som är anslutna till lokala platser. Eftersom de är plattformshanterade kräver Azure VPN-gatewayer minimal hantering. Du kan använda befintliga gatewayer även om de stöder andra anslutningsscenarier. Du bör läsa de här artiklarna om du vill ha information om inställningar som stöds och förväntade prestanda:
Nva från tredje part används vanligtvis för att avsluta tunnlar från lokala platser i följande situationer:
- NVA är CPE (kundlokal utrustning) för en SDWAN-lösning som distribueras både på Azure och på den lokala platsen.
- NVA är en brandvägg som tillämpar den nödvändiga säkerhetsprincipen för anslutningar mellan den lokala platsen och Azure VMware Solution.

Att använda enheter från tredje part kan ge mer flexibilitet och åtkomst till avancerade nätverksfunktioner som inte stöds av interna VPN-gatewayer, men det ökar komplexiteten. Hög tillgänglighet blir ditt ansvar. Du bör distribuera flera instanser.

Överföring över privat ExpressRoute-peering

Privat ExpressRoute-peering är det vanligaste valet för att ansluta en lokal plats till ett virtuellt Azure-nätverk (eller hub-spoke-nätverk) i företagsscenarier. Det virtuella Azure-nätverket, eller det virtuella hubbnätverket i hub-spoke-topologier, innehåller en ExpressRoute-gateway som har konfigurerats med en anslutning till ExpressRoute-kretsen. Den här konfigurationen ger Layer 3-anslutning mellan det virtuella nätverket (eller hela hub-spoke-nätverket) och den lokala platsens nätverk. Den tillhandahåller dock inte inbyggt Layer 3-anslutning till privata Azure VMware Solution-moln som är anslutna till samma virtuella nätverk (eller virtuella hubbnätverk) via en hanterad ExpressRoute-krets. (Se Privata moln för ExpressRoute Global Reach och Azure VMware Solution.)

Du kan kringgå den här begränsningen genom att distribuera fler routningsenheter i det virtuella Azure-nätverket. På så sätt kan du dirigera trafik via brandväggs-NVA:er som finns i det virtuella nätverket.

Överföring över privat ExpressRoute-peering kan verka önskvärd, men det ger komplexitet och påverkar prestanda. Du bör bara tänka på det när ExpressRoute Global Reach och IPSec VPN(beskrivs i föregående avsnitt) inte är tillämpliga.

Det finns två implementeringsalternativ:

Enskilt virtuellt nätverk. När du använder det här alternativet är de kundhanterade och Azure VMware Solution-hanterade kretsarna anslutna till samma ExpressRoute-gateway.
Extra överföring av virtuellt nätverk. När du använder det här alternativet är den kundhanterade ExpressRoute-kretsen som tillhandahåller anslutning till den lokala platsen ansluten till (vanligtvis befintlig) ExpressRoute-gatewayen i det virtuella hubbnätverket. Den hanterade Azure VMware Solution-kretsen är ansluten till en annan ExpressRoute-gateway som distribueras i ett extra virtuellt transitnätverk.

Följande avsnitt innehåller information om de två implementeringsalternativen, inklusive:

Kompromisser mellan prestanda, kostnad (nödvändiga Azure-resurser) och hanteringskostnader.
Implementering av kontrollplan (hur vägar utbyts mellan den lokala platsen och det privata molnet).
Implementering av dataplan (hur nätverkspaket dirigeras mellan den lokala platsen och det privata molnet).

Enskilt virtuellt nätverk

När du använder metoden för ett virtuellt nätverk ansluts både det privata molnets hanterade krets i Azure VMware Solution och den kundägda kretsen till samma ExpressRoute-gateway, vanligtvis hubbnätverket. Trafik mellan det privata molnet och den lokala platsen kan dirigeras via brandväggs-NVA:er som distribueras i hubbnätverket. Arkitekturen för ett virtuellt nätverk visas här:

Kontrollplanet och dataplanet implementeras enligt beskrivningen här:

Kontrollplan. En ExpressRoute-gateway som distribueras i det virtuella Azure-nätverket kan inte sprida vägar mellan den hanterade Azure VMware Solution-kretsen och den kundhanterade ExpressRoute-kretsen. Azure Route Server, med inställningen branch-to-branch aktiverad, används för att i båda kretsarna mata in vägar för supernät som inkluderar det privata molnets adressutrymme i Azure VMware Solution (hanteringsnätverk och arbetsbelastningssegment) och det lokala adressutrymmet.

Supernät, i stället för de exakta prefix som utgör dessa adressutrymmen, måste tillkännages, eftersom de exakta prefixen redan har meddelats i motsatt riktning av det privata Azure VMware Solution-molnet och den lokala platsen. Du kan använda supernät så stora som RFC 1918-prefix om de är kompatibla med nätverkskonfigurationen på de lokala platserna. I de flesta fall bör du i stället använda de minsta supernäten som innehåller det privata molnets adressutrymme för Azure VMware Solution och det lokala adressutrymmet. På så sätt minimeras risken för konflikter med routningskonfigurationen för de lokala platserna.

Vägarna för supernäten kommer från BGP-kompatibla NVA:er. NVA:erna är konfigurerade för att upprätta en BPG-session med Azure Route Server. NVA:erna är bara en del av kontrollplanet och dirigerar inte faktisk trafik mellan den lokala platsen och det privata Azure VMware Solution-molnet. Implementeringen av kontrollplanet representeras av de streckade linjerna i föregående bild.
Dataplan. Implementeringen av kontrollplanet som beskrivs tidigare lockar följande trafik till ExpressRoute-gatewayen:
- Trafik från den lokala platsen som är avsedd för det privata azure VMware Solution-molnet.
- Trafik från det privata Azure VMware Solution-molnet som är avsett för den lokala platsen.
Om inga UDR:er tillämpas på GatewaySubnet flödar trafiken direkt mellan den lokala platsen och det privata Azure VMware Solution-molnet. Du kan dirigera trafik till ett mellanliggande nästa hopp genom att tillämpa UDR på GatewaySubnet. Brandväggs-NVA:er som tillämpar nätverkssäkerhetsprinciper på anslutningar mellan lokala platser och privata moln är ett typiskt exempel. Implementeringen av dataplanet representeras av den fasta linjen i föregående bild.

Extra virtuellt nätverk

Du kan använda ett extra virtuellt nätverk för att vara värd för en andra ExpressRoute-gateway som endast är ansluten till det privata molnets hanterade Krets i Azure VMware Solution. Om du använder den här metoden ansluter det privata molnets hanterade krets och den kundhanterade kretsen till olika ExpressRoute-gatewayer. Två Azure Route Server-instanser används för att meddela rätt vägar till varje krets och för att styra routningen mellan det privata molnet och den lokala platsen. Du behöver inte meddela supernät, som du gör för det enda virtuella nätverksalternativet som beskrivs i föregående avsnitt. Hanteringskostnader för UDR:er i GatewaySubnet minskar också. Med den här metoden kan du dirigera trafik mellan det privata molnet och den lokala platsen via brandväggs-NVA:er i det virtuella hubbnätverket. Implementeringen av det virtuella nätverket visas i följande diagram:

Kontrollplanet och dataplanet implementeras enligt beskrivningen här:

Kontrollplan. Om du vill aktivera routningsspridning mellan det privata molnets hanterade krets i Azure VMware Solution och den kundägda kretsen behöver du en Azure Route Server-instans i varje virtuellt nätverk. Eftersom de två Azure Route Server-instanserna inte kan upprätta BGP-angränsande, behövs BGP-kompatibla NVA:er för att sprida vägar mellan dem. För hög tillgänglighet bör du distribuera minst två NVA-instanser. Du kan lägga till fler instanser för att öka dataflödet. De BGP-kompatibla NVA:erna måste ha två nätverkskort som är anslutna till olika undernät. BGP-sessioner mot de två routningsservrarna (i det extra virtuella nätverket och det virtuella hubbnätverket) måste upprättas över olika nätverkskort.

Vägar som kommer från det privata Azure VMware Solution-molnet och av den lokala platsen lärs via ExpressRoute-kretsar. Deras AS-sökvägar innehåller ASN 65515 (ett Azure-reserverat ASN som används av ExpressRoute-gatewayer) och ASN 12076 (ett Microsoft-ägt ASN som används av Microsoft Enterprise-gränsroutrarna på alla peeringplatser). De BGP-kompatibla NVA:erna måste ta bort AS-sökvägarna för att förhindra att vägar tas bort av BGP-loopidentifiering. Mer information om den nödvändiga BGP-konfigurationen finns i Implementera Expressroute-anslutning för AVS utan global räckvidd. Implementeringen av kontrollplanet representeras av de streckade linjerna i föregående diagram.
Dataplan. I det virtuella extra nätverket dirigeras trafik mellan det privata Azure VMware Solution-molnet och den lokala platsen via BGP-kompatibla NVA:er. Trafik till och från det privata Azure VMware Solution-molnet lämnar eller anger nva:erna via det nätverkskort som används för BGP-sessionen med det extra virtuella nätverkets routningsserver. Trafik till och från den lokala platsen lämnar eller anger nva:erna via det nätverkskort som används för BGP-sessionen med det virtuella hubbnätverkets routningsserver. Det här nätverkskortet är kopplat till ett undernät som är kopplat till en anpassad routningstabell som:
- Inaktiverar inlärning av BGP-vägar från routningsservern (för att undvika loopar).
- Infogar hubbnätverkets brandvägg i datasökvägen.
För att säkerställa att trafiken dirigeras symmetriskt via hubbens brandvägg måste UDR:er för alla prefix som används i det privata Azure VMware Solution-molnet konfigureras på hubbens GatewaySubnet. Mer information finns i Implementera Expressroute-anslutning för AVS utan global räckvidd. Implementeringen av dataplanet representeras av den fasta linjen i föregående diagram.

Nästa steg

Lär dig mer om anslutning mellan Azure VMware Solution och virtuella Azure-nätverk.

Anslut mellan virtuella Azure VMware-lösningar och virtuella Azure-nätverk

Dela via