Använd en Azure VMware Solution-design med dubbla regioner som inte har global räckvidd
Den här artikeln beskriver metodtipsen för anslutning, trafikflöden och hög tillgänglighet när du distribuerar Azure VMware Solution i två regioner och använder säkert Azure Virtual WAN med routningssyfte. Den ger vägledning om hur du använder den här designen utan Global Reach. I den här artikeln beskrivs Virtual WAN med routnings avsiktstopologi för privata Moln i Azure VMware Solution, lokala platser och Azure-inbyggda resurser. Implementeringen och konfigurationen av säkert virtuellt WAN med routnings avsikt ligger utanför omfånget för den här artikeln.
Om du använder en region som inte stöder Global Reach eller om du har ett säkerhetskrav för att inspektera trafik mellan Azure VMware Solution och lokalt i hubbens brandvägg, måste du öppna en supportbegäran för att aktivera ExpressRoute-till-ExpressRoute-transitivitet. Virtual WAN stöder inte ExpressRoute-to-ExpressRoute-transitivitet som standard. Mer information finns i Överföringsanslutning mellan ExpressRoute-kretsar med routningssyfte.
Använda en säker virtual WAN-design med dubbla regioner utan global räckvidd
Endast Virtual WAN Standard SKU stöder säkert virtuellt WAN med routningssyfte. Använd säkert virtuellt WAN med routnings avsikt att skicka all internettrafik och privat nätverkstrafik (RFC 1918) till en säkerhetslösning, till exempel Azure Firewall, en virtuell nätverksinstallation (NVA) som inte kommer från Microsoft eller en saaS-lösning (programvara som en tjänst).
Det här scenariots hubb har följande konfiguration:
Nätverket med dubbla regioner har en Virtual WAN-instans och två hubbar. Varje region har en hubb.
Varje hubb har en egen Azure Firewall-instans distribuerad, vilket gör dem till säkra Virtual WAN-hubbar.
De säkra Virtual WAN-hubbarna har routnings avsikt aktiverad.
I det här scenariot finns även följande komponenter:
Varje region har ett eget privat Azure VMware Solution-moln och ett virtuellt Azure-nätverk.
En lokal plats ansluter till båda regionerna.
Kommentar
Om du använder prefix som inte är RFC 1918 i dina anslutna lokala resurser, virtuella nätverk eller Azure VMware Solution anger du dessa prefix i fältet Privata trafikprefix i routnings avsiktsfunktionen. Ange sammanfattade vägar i fältet Privata trafikprefix för att täcka ditt intervall. Ange inte det exakta intervallet som annonserar till Virtual WAN eftersom den här specifikationen kan leda till routningsproblem. Om Azure ExpressRoute-kretsen till exempel annonserar 192.0.2.0/24 lokalt anger du ett /23 CIDR-intervall (Classless Inter-Domain Routing) eller större, till exempel 192.0.2.0/23. Mer information finns i Konfigurera routnings avsikt och principer via Virtual WAN-portalen.
Kommentar
När du konfigurerar Azure VMware Solution med säkra Virtual WAN-hubbar anger du inställningsalternativet för hubbdirigering till AS-sökväg för att säkerställa optimala routningsresultat på hubben. Mer information finns i Routningsinställningar för virtuell hubb.
Följande diagram visar ett exempel på det här scenariot.
I följande tabell beskrivs topologianslutningen i föregående diagram.
| Connection | beskrivning |
|---|---|
| D | Privat molnanslutning för Azure VMware Solution till den lokala regionala hubben |
| E | Lokal anslutning via ExpressRoute till båda regionala hubbarna |
| Interhub | Logisk interhub-anslutning mellan två hubbar som distribueras under samma virtuella WAN |
Säkerhetsflöden för virtuellt WAN-trafik med dubbla regioner
I följande avsnitt beskrivs trafikflöden och anslutningar för Azure VMware Solution, lokalt, virtuella Azure-nätverk och Internet.
Azure VMware Solution– privat molnanslutning och trafikflöden
Följande diagram visar trafikflöden för både privata Azure VMware Solution-moln.
I följande tabell beskrivs topologianslutningen i föregående diagram.
| Trafikflödesnummer | Källa | Mål | Inspekterar den säkra brandväggen för Virtual WAN-hubben den här trafiken? |
|---|---|---|---|
| 1 | Azure VMware Solution cloud region 1 | Virtuellt nätverk 1 | Ja, via hubb 1-brandväggen |
| 2 | Azure VMware Solution cloud region 1 | Lokal | Ja, via hubb 1-brandväggen |
| 3 | Azure VMware Solution cloud region 1 | Virtuellt nätverk 2 | Ja, via hubb 1-brandväggen och sedan via hubb 2-brandväggen |
| 4 | Azure VMware Solution cloud region 1 | Azure VMware Solution cloud region 2 | Ja, via hubb 1-brandväggen och sedan via hubb 2-brandväggen |
| 5 | Azure VMware Solution cloud region 2 | Virtuellt nätverk 1 | Ja, via hubb 2-brandväggen och sedan via hubb 1-brandväggen |
| 6 | Azure VMware Solution cloud region 2 | Virtuellt nätverk 2 | Ja, via hubb 2-brandväggen |
| 7 | Azure VMware Solution cloud region 2 | Lokal | Ja, via hubb 2-brandväggen |
Varje privat Azure VMware Solution-moln ansluter till hubben via ExpressRoute-anslutning D.
När du aktiverar ExpressRoute-till-ExpressRoute-transitivitet på den säkra hubben och aktiverar routnings avsikten skickar den säkra hubben standardadresserna RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) till Azure VMware Solution via anslutning D. Utöver standardadresserna för RFC 1918 lär sig Azure VMware Solution mer specifika vägar från virtuella Azure-nätverk och grennätverk, till exempel S2S VPN, P2S VPN och SD-WAN, som ansluter till båda hubbarna. Både privata Azure VMware Solution-moln lär sig inte specifika vägar från lokala nätverk.
För att dirigera trafik tillbaka till lokala nätverk använder Azure VMware Solution standardadresserna för RFC 1918 som den lär sig via anslutning D från den lokala regionala hubben. Den här trafiken överförs via den lokala regionala hubbens brandvägg. Hubbens brandvägg använder de specifika vägarna för lokala nätverk för att dirigera trafik mot målen via anslutning E. Trafik som går från antingen ett privat Azure VMware Solution-moln till virtuella nätverk överförs hubbens brandvägg.
Lokal anslutning och trafikflöde
Följande diagram visar trafikflöden för lokal anslutning.
I följande tabell beskrivs topologianslutningen i föregående diagram.
| Trafikflödesnummer | Källa | Mål | Inspekterar den säkra brandväggen för Virtual WAN-hubben den här trafiken? |
|---|---|---|---|
| 2 | Lokal | Azure VMware Solution cloud region 1 | Ja, via hubb 1-brandväggen |
| 7 | Lokal | Azure VMware Solution cloud region 2 | Ja, via hubb 2-brandväggen |
| 8 | Lokal | Virtuellt nätverk 1 | Ja, via hubb 1-brandväggen |
| 9 | Lokal | Virtuellt nätverk 2 | Ja, via hubb 2-brandväggen |
Den lokala platsen ansluter till båda hubbarna via ExpressRoute-anslutning E.
När du aktiverar ExpressRoute-till-ExpressRoute-transitivitet på båda säkra hubbarna och du aktiverar routnings avsikt, skickar varje säker hubb standard RFC 1918-adresser (10.0.0.0/8, 172.16.0.0/12 och 192.168.0.0/16) till lokalt via anslutningen E. Förutom standardadresserna för RFC 1918 lär sig lokala vägar från virtuella Azure-nätverk och grennätverk, till exempel S2S VPN, P2S VPN och SD-WAN, som ansluter till båda hubbarna.
Lokalt lär du dig inte de specifika vägarna för privata Azure VMware Solution-moln. Lokalt lär du dig standardadresserna för RFC 1918 från båda hubbarna via anslutning E. Lokala vägar till både privata Azure VMware Solution-moln via standardadresserna för RFC 1918 som den lär sig via anslutning E.
Kommentar
Du måste lägga till specifika vägar på båda hubbarna. Om du inte lägger till specifika vägar på hubbarna kan du introducera suboptimal routning eftersom lokal användning av ECMP-routning (multi-path) med samma kostnad används mellan E-anslutningarna för trafik som går till ett privat Azure VMware Solution-moln. Därför kan trafik mellan lokalt och ett privat Azure VMware Solution-moln uppleva svarstider, prestandaproblem eller paketförluster.
Om du vill annonsera en mer specifik väg till en lokal plats anger du dessa prefix i fältet Privata trafikprefix för routningsfunktionen. Mer information finns i Konfigurera routnings avsikt och principer via Virtual WAN-portalen. Du måste lägga till en sammanfattad väg som omfattar både ditt Azure VMware Solution /22-block och dina Azure VMware Solution-undernät. Om du lägger till samma exakta prefix eller ett mer specifikt prefix i stället för en sammanfattningsväg introducerar du routningsproblem i Azure-miljön. Inkludera endast sammanfattade vägar i fältet Privata trafikprefix .
Som du ser i diagrammet innehåller Azure VMware Solution private cloud 1 arbetsbelastningsundernät från 10.10.0.0/24 till 10.10.7.0/24. På hubb 1 läggs sammanfattningsvägen 10.10.0.0/21 till i prefix för privat trafik eftersom den omfattar alla åtta undernät. På hubb 1 läggs dessutom sammanfattningsvägen 10.150.0.0/22 till i privata trafikprefix för att täcka hanteringsblocket för Azure VMware Solution. Sammanfattningsvägarna 10.10.0.0/21 och 10.150.0.0/22 annonseras ned till lokalt via anslutning E så att lokala vägar har en mer specifik väg i stället för 10.0.0.0/8.
Azure VMware Solution private cloud 2 innehåller arbetsbelastningsundernät från 10.20.0.0/24 till 10.20.7.0/24. På hubb 2 läggs sammanfattningsvägen 10.20.0.0/21 till i prefix för privat trafik eftersom den omfattar alla åtta undernät. På hubb 2 läggs dessutom sammanfattningsvägen 10.250.0.0/22 till i privata trafikprefix för att täcka hanteringsblocket för Azure VMware Solution. Sammanfattningsvägar 10.20.0.0/21 och 10.250.0.0/22 annonserar ned till lokal via anslutning E så att lokala vägar har en mer specifik väg i stället för 10.0.0.0/8.
Du kan lägga till hela Azure VMware Solution Management /22-blocket i fältet Privata trafikprefix eftersom Azure VMware Solution inte annonserar det exakta /22-blocket tillbaka till Azure. Azure VMware Solution annonserar mer specifika vägar.
När du aktiverar ExpressRoute-till-ExpressRoute-transitivitet på hubben skickar den standardadresserna för RFC 1918 till ditt lokala nätverk. Annonsera inte de exakta RFC 1918-prefixen tillbaka till Azure. Samma exakta vägar kan skapa routningsproblem i Azure. I stället bör du annonsera mer specifika vägar tillbaka till Azure för dina lokala nätverk.
Kommentar
Om du annonserar standardadresserna för RFC 1918 från en lokal plats till Azure och vill fortsätta med den här metoden måste du dela upp varje RFC 1918-intervall i två lika stora underlager och annonsera dessa underordningar tillbaka till Azure. Underordningarna är 10.0.0.0/9, 10.128.0.0/9, 172.16.0.0/13, 172.24.0.0/13, 192.168.0.0/17 och 192.168.128.0/17.
Anslutning och trafikflöde för virtuella Azure-nätverk
Följande diagram visar trafikflöden för virtuella Azure-nätverk.
I följande tabell beskrivs trafikflödet i föregående diagram.
| Trafikflödesnummer | Källa | Mål | Inspekterar den säkra brandväggen för Virtual WAN-hubben den här trafiken? |
|---|---|---|---|
| 1 | Virtuellt nätverk 1 | Azure VMware Solution cloud region 1 | Ja, via hubb 1-brandväggen |
| 3 | Virtuellt nätverk 2 | Azure VMware Solution cloud region 1 | Ja, via hubb 2-brandväggen och sedan hubb 1-brandväggen |
| 5 | Virtuellt nätverk 1 | Azure VMware Solution cloud region 2 | Ja, via hubb 1-brandväggen och sedan hubb 2-brandväggen |
| 6 | Virtuellt nätverk 2 | Azure VMware Solution cloud region 2 | Ja, via hubb 2-brandväggen |
| 8 | Virtuellt nätverk 1 | Lokal | Ja, via hubb 1-brandväggen |
| 9 | Virtuellt nätverk 2 | Lokal | Ja, via hubb 2-brandväggen |
| 10 | Virtuellt nätverk 1 | Virtuellt nätverk 2 | Ja, via hubb 1-brandväggen och sedan hubb 2-brandväggen |
| 10 | Virtuellt nätverk 2 | Virtuellt nätverk 1 | Ja, via hubb 2-brandväggen och sedan hubb 1-brandväggen |
Varje virtuellt nätverk är direkt peer-kopplat till sin regionala hubb.
Diagrammet visar hur alla Azure-inbyggda resurser i båda de virtuella nätverken lär sig sina effektiva vägar. När du aktiverar routnings avsikten skickar hubb 1 och hub 2 standardadresserna RFC 1918 till deras peerkopplade virtuella nätverk. Azure-interna resurser i de virtuella nätverken lär sig inte specifika vägar utanför det virtuella nätverket.
När du aktiverar routnings avsikt lär sig alla resurser i det virtuella nätverket standardadressen RFC 1918 och använder sin regionala hubbbrandvägg som nästa hopp. Privata Azure VMware Solution-moln kommunicerar med varandra via anslutning D via deras lokala regionala hubbbrandvägg. Därifrån passerar de Virtual WAN-interhub och genomgår inspektion vid brandväggen för den tvärregionala hubben. Privata Azure VMware Solution-moln kommunicerar också med lokalt via anslutning D via deras lokala regionala hubbbrandvägg. All trafik som kommer in i och avslutar de virtuella nätverken överförs sina regionala hubbbrandväggar.
Internet-anslutning
I det här avsnittet beskrivs hur du tillhandahåller Internetanslutning för Azure-inbyggda resurser i virtuella nätverk och privata Moln i Azure VMware Solution i båda regionerna. Mer information finns i Designöverväganden för Internetanslutning. Du kan använda följande alternativ för att tillhandahålla Internetanslutning till Azure VMware Solution.
- Alternativ 1: Azure-värdbaserad Internettjänst
- Alternativ 2: Azure VMware Solution-managed Source Network Address Translation (SNAT)
- Alternativ 3: Offentlig IPv4-adress i Azure till NSX-T Data Center-gränsen
En virtuell WAN-design med dubbla regioner som har routnings avsikt stöder alla alternativ, men vi rekommenderar alternativ 1. Scenariot senare i den här artikeln använder alternativ 1 för att tillhandahålla internetanslutning. Alternativ 1 fungerar bäst med säkert Virtuellt WAN eftersom det är enkelt att inspektera, distribuera och hantera.
När du aktiverar routnings avsikt på båda säkra hubbar annonseras RFC 1918 till direkt peer-kopplade virtuella nätverk. Men du kan också annonsera en standardväg 0.0.0.0/0 för internetanslutning till underordnade resurser. När du aktiverar routnings avsikt kan du generera en standardväg från båda hubbbrandväggarna. Den här standardvägen annonserar till sina direkt peerkopplade virtuella nätverk och till den direktanslutna Azure VMware-lösningen.
Azure VMware Solution och internetanslutning för virtuella nätverk
Följande diagram visar trafikflöden för privata moln och virtuella nätverk i Azure VMware Solution.
I följande tabell beskrivs trafikflödet i föregående diagram.
| Trafikflödesnummer | Källa | Mål | Inspekterar den säkra brandväggen för Virtual WAN-hubben den här trafiken? |
|---|---|---|---|
| 11 | Azure VMware Solution cloud region 1 | Internet | Ja, via hubb 1-brandväggen |
| 12 | Virtuellt nätverk 2 | Internet | Ja, via hubb 2-brandväggen |
| 13 | Virtuellt nätverk 1 | Internet | Ja, via hubb 1-brandväggen |
| 14 | Azure VMware Solution cloud region 2 | Internet | Ja, via hubb 2-brandväggen |
När du aktiverar routningssyfte för Internettrafik annonserar den säkra Virtual WAN-hubben som standard inte standardvägen över ExpressRoute-kretsar. För att säkerställa att standardvägen sprids till den direktanslutna Azure VMware-lösningen från Virtual WAN måste du aktivera standardroutningsspridning på Azure VMware Solution ExpressRoute-kretsarna. Mer information finns i Annonsera standardväg 0.0.0.0/0 till slutpunkter.
När du har aktiverat standardflödesspridning annonserar anslutning D standardvägen 0.0.0.0/0 från hubben. Aktivera inte den här inställningen för lokala ExpressRoute-kretsar. Vi rekommenderar att du implementerar ett BGP-filter (Border Gateway Protocol) på din lokala utrustning för att undanta inlärning av standardvägen. Ett BGP-filter lägger till ett extra skyddslager och säkerställer att konfigurationen inte påverkar den lokala Internetanslutningen.
När du aktiverar routningssyfte för Internetåtkomst genererar båda de regionala hubbarna en standardväg och annonserar den till sina hubb-peerkopplade virtuella nätverksanslutningar. Observera att i de virtuella datorernas nätverkskort (NIC) i det virtuella nätverket är nästa hopp 0.0.0.0/0 hubbens brandvägg. Om du vill hitta nästa hopp väljer du Effektiva vägar i nätverkskortet. Standardvägen annonserar inte över regionala hubbar via interhub-länken. Därför använder virtuella nätverk sin lokala regionala hubb för internetåtkomst och de har inte säkerhetskopiering av Internetanslutning till den korsregionala hubben.
Återhämtning av Internetåtkomst för Azure VMware Solution
När du inte använder Global Reach i en design med dubbla regioner har utgående Internetanslutning inte redundans eftersom varje privat Azure VMware Solution-moln lär sig standardvägen från sin lokala regionala hubb och inte är direkt ansluten till sin korsregionala hubb. Om ett regionalt avbrott påverkar den lokala regionala hubben använder du någon av följande manuella konfigurationer för att uppnå internetredundans.
Alternativ 1
Använd det här alternativet endast för utgående internetåtkomst. Om du behöver utgående Internetåtkomst för din Azure VMware Solution-arbetsbelastning under ett lokalt regionalt avbrott använder du Azure VMware Solution-hanterad SNAT. Den här lösningen ger enkel och snabb åtkomst. Mer information finns i Aktivera hanterade SNAT för Azure VMware Solution-arbetsbelastningar.
Alternativ 2
Använd det här alternativet för inkommande och utgående internetåtkomst. Använd följande metod om du behöver både inkommande och utgående Internetåtkomst för ditt Azure VMware Solution-moln under ett lokalt regionalt avbrott.
Ta bort anslutningen som går från Azure VMware Solution till din lokala regionala hubb (anslutning D i diagrammen).
I Azure Portal väljer du Azure VMware Solution och tar bort auktoriseringsnyckeln som du skapade för anslutning D.
Skapa en ny anslutning till den korsregionala hubben.
Om du vill hantera inkommande trafik bör du överväga att använda Azure Front Door eller Azure Traffic Manager för att upprätthålla regional hög tillgänglighet.
Använda VMware HCX Mobility Optimized Networking (MON) utan global räckvidd
Du kan aktivera HCX Mobility Optimized Networking (MON) när du använder HCX-nätverkstillägget. MON tillhandahåller optimal trafikroutning i vissa scenarier för att förhindra att nätverk överlappar eller loopar mellan lokala och molnbaserade resurser i utökade nätverk.
Utgående trafik från Azure VMware Solution
När du aktiverar MON för ett specifikt utökat nätverk och en virtuell dator ändras trafikflödet. När du har implementerat MON går utgående trafik från den virtuella datorn inte tillbaka till den lokala datorn. I stället kringgås IPSec-tunneln för nätverkstillägget. Trafiken för den virtuella datorn avslutas från Azure VMware Solution NSX-T Tier-1-gatewayen, går till NSX-T Tier-0-gatewayen och går sedan till Virtual WAN.
Inkommande trafik till Azure VMware Solution
När du aktiverar MON för ett specifikt utökat nätverk och en virtuell dator introducerar du följande ändringar. Från Azure VMware Solution NSX-T matar MON in en /32-värdväg tillbaka till Virtual WAN. Virtual WAN annonserar den här /32-vägen tillbaka till lokala, virtuella nätverk och grennätverk. Den här /32-värdvägen säkerställer att trafik från lokala, virtuella nätverk och grennätverk inte använder IPSec-tunneln för nätverkstillägget när trafiken går till den MON-aktiverade virtuella datorn. Trafik från källnätverk går direkt till den MON-aktiverade virtuella datorn eftersom den lär sig /32-vägen.
HCX MON-begränsning för säkert virtuellt WAN utan global räckvidd
När du aktiverar ExpressRoute-till-ExpressRoute-transitivitet på den säkra hubben och aktiverar routnings avsikt, skickar den säkra hubben standardadresserna RFC 1918 till både den lokala lösningen och Azure VMware Solution. Förutom standardadresserna för RFC 1918 kan både den lokala lösningen och Azure VMware Solution lära sig mer specifika vägar från virtuella Azure-nätverk och grennätverk som ansluter till hubben.
Men lokala nätverk lär sig inte specifika vägar från Azure VMware Solution och Azure VMware Solution lär sig inte specifika vägar från lokala nätverk. I stället förlitar sig båda miljöerna på standardadresserna för RFC 1918 för att underlätta routning tillbaka till varandra via hubbens brandvägg. Därför annonserar mer specifika vägar, till exempel MON-värdvägar, inte från Azure VMware Solution ExpressRoute till den lokala ExpressRoute-kretsen. Det omvända är också sant. Oförmågan att lära sig specifika vägar introducerar asymmetriska trafikflöden. Trafiken går ut ur Azure VMware Solution via NSX-T Tier-0-gatewayen, men returnerar trafik från lokala returer via IPSec-tunneln för nätverkstillägget.
Korrigera trafikasymmetrin
För att korrigera trafikasymmetrin måste du justera MON-principvägarna. MON-principvägar avgör vilken trafik som går tillbaka till den lokala gatewayen via ett L2-tillägg. De bestämmer också vilken trafik som går via Azure VMware Solution NSX Tier-0-gatewayen.
Om en mål-IP matchar och du anger att den ska tillåtas i MON-principkonfigurationen utförs två åtgärder. Först identifierar systemet paketet. För det andra skickar systemet paketet till den lokala gatewayen via nätverkstilläggsinstallationen.
Om en mål-IP inte matchar eller om du anger att den ska nekas i MON-principen skickar systemet paketet till Azure VMware Solution Tier-0-gatewayen för routning.
I följande tabell beskrivs HCX-principvägar.
| Nätverk | Omdirigera till peer | Kommentar |
|---|---|---|
| Adressutrymme för virtuellt Azure-nätverk | Neka | Inkludera uttryckligen adressintervallen för alla dina virtuella nätverk. Trafik som är avsedd för Azure dirigerar utgående trafik via Azure VMware Solution och återgår inte till det lokala nätverket. |
| Standardadressutrymmen för RFC 1918 | Tillåt | Lägg till standardadresserna för RFC 1918. Den här konfigurationen säkerställer att all trafik som inte matchar föregående villkor omdirigeras tillbaka till det lokala nätverket. Om den lokala installationen använder adresser som inte ingår i RFC 1918 måste du uttryckligen inkludera dessa intervall. |
| 0.0.0.0/0 adressutrymme | Neka | Adresser som RFC 1918 inte täcker, till exempel internetroutningsbara IP-adresser eller trafik som inte matchar de angivna posterna, avsluta direkt via Azure VMware Solution och omdirigera inte tillbaka till det lokala nätverket. |