Migrera till Azure Virtual WAN
Med Azure Virtual WAN kan företag förenkla sin globala anslutning för att dra nytta av omfattningen av Microsofts globala nätverk. Den här artikeln innehåller teknisk information för företag som vill migrera från en befintlig kundhanterad nav- och ekertopologi till en design som utnyttjar Microsoft-hanterade Virtual WAN hubbar.
Information om de fördelar som Azure Virtual WAN möjliggör för företag som använder ett molnbaserat modernt globalt företagsnätverk finns i Global transit network architecture and Virtual WAN (Global transit network architecture and Virtual WAN).
: Azure Virtual WAN
Azure Hub-and-spoke-anslutningsmodellen har implementerats av tusentals av våra kunder för att utnyttja standardbeteendet för transitiv routning i Azure-nätverk för att skapa enkla och skalbara molnnätverk. Azure Virtual WAN bygger vidare på dessa begrepp och introducerar nya funktioner som möjliggör globala anslutningstopologier, inte bara mellan lokala platser och Azure, utan även gör det möjligt för kunder att utnyttja skalan i Microsoft-nätverket för att utöka sina befintliga globala nätverk.
Den här artikeln visar hur du migrerar en befintlig kundhanterad hub-and-spoke-miljö till en topologi som baseras på Azure Virtual WAN.
Scenario
Contoso är en global finansiell organisation med kontor i både Europa och Asien. De planerar att flytta sina befintliga program från ett lokalt datacenter till Azure och har skapat en grundläggande design baserad på den kundhanterade hubb- och ekerarkitekturen, inklusive regionala virtuella hubbnätverk för hybridanslutningar. Som en del av övergången till molnbaserad teknik har nätverksteamet fått i uppgift att se till att deras anslutning optimeras för verksamheten framöver.
Följande bild visar en övergripande vy över det befintliga globala nätverket, inklusive anslutning till flera Azure-regioner.
Bild: Contosos befintliga nätverkstopologi
Följande punkter kan förstås från den befintliga nätverkstopologin:
En topologi av typen hub-and-spoke används i flera regioner, inklusive ExpressRoute-kretsar för anslutning tillbaka till ett gemensamt privat WAN (Wide Area Network).
Vissa av dessa platser har även VPN-tunnlar direkt i Azure för att nå program som finns i molnet.
Krav
Nätverksteamet har fått i uppgift att leverera en global nätverksmodell som kan stödja Contoso-migreringen till molnet och som måste optimeras inom områdena kostnad, skala och prestanda. Sammanfattningsvis måste följande krav uppfyllas:
- Ge både huvudkontor och avdelningskontor optimerad sökväg till molnbaserade program.
- Ta bort beroendet av befintliga lokala datacenter (DC) för VPN-avslutning samtidigt som följande anslutningssökvägar behålls:
- Avdelning-till-VNet: VPN-anslutna kontor måste kunna komma åt program som migrerats till molnet i den lokala Azure-regionen.
- Branch-to-Hub till Hub-to-VNet: VPN-anslutna kontor måste kunna komma åt program som migrerats till molnet i den fjärranslutna Azure-regionen.
- Avdelning-till-gren: Regionala VPN-anslutna kontor måste kunna kommunicera med varandra och ExpressRoute-anslutna HQ/DC-platser.
- Branch-to-Hub till Hub-to-branch: Globalt avgränsade VPN-anslutna kontor måste kunna kommunicera med varandra och alla ExpressRoute-anslutna HQ/DC-platser.
- Förgrening till Internet: Anslutna platser måste kunna kommunicera med Internet. Trafiken måste filtreras och loggas.
- VNet-till-VNet: Virtuella ekernätverk i samma region måste kunna kommunicera med varandra.
- VNet-till-hubb till hubb-till-VNet: Virtuella ekernätverk i olika regioner måste kunna kommunicera med varandra.
- Ge Contoso roaminganvändare (bärbar dator och telefon) möjlighet att komma åt företagets resurser utan att vara i företagsnätverket.
Arkitektur för Azure Virtual WAN
Följande bild visar en övergripande vy över den uppdaterade måltopologin med hjälp av Azure Virtual WAN för att uppfylla kraven som beskrivs i föregående avsnitt.
Bild: Azure Virtual WAN-arkitektur
Sammanfattning:
- HQ i Europa är fortfarande ExpressRoute-anslutet, den lokala domänkontrollanten i Europa migreras helt till Azure och inaktiveras nu.
- Asia DC och HQ förblir anslutna till Private WAN. Azure Virtual WAN används nu för att utöka det lokala transportföretagets nätverk och tillhandahålla global anslutning.
- Azure Virtual WAN hubbar som distribueras i azure-regioner i både Europa, västra och Sydostasien för att tillhandahålla anslutningshubbar för ExpressRoute- och VPN-anslutna enheter.
- Hubbar tillhandahåller även VPN-avslutning för roaminganvändare över flera klienttyper med OpenVPN-anslutning till det globala nätnätverket, vilket ger åtkomst till inte bara program som migreras till Azure, utan även alla resurser som finns kvar lokalt.
- Internetanslutning för resurser i ett virtuellt nätverk som tillhandahålls av Azure Virtual WAN.
Internetanslutning för fjärrplatser tillhandahålls också av Azure Virtual WAN. Lokal internetsession som stöds via partnerintegrering för optimerad åtkomst till SaaS-tjänster som Microsoft 365.
Migrera till Virtual WAN
Det här avsnittet visar de olika stegen för att migrera till Azure Virtual WAN.
Steg 1: Kundhanterad hub-and-spoke för en enskild region
Följande bild visar en topologi för en enda region för Contoso före distributionen av Azure Virtual WAN:
Bild 1: Manuell hub-and-spoke för en region
I enlighet med metoden hub-and-spoke innehåller det kundhanterade virtuella hubbnätverket flera funktionsblock:
- Delade tjänster (alla vanliga funktioner som krävs av flera ekrar). Exempel: Contoso använder Windows Server-domänkontrollanter på virtuella IaaS-datorer (Infrastruktur som en tjänst).
- IP-/routningsbrandväggstjänster tillhandahålls av en virtuell nätverksinstallation från tredje part, vilket möjliggör IP-routning av layer-3-ekrar.
- Ingress-/utgående internettjänster inklusive Azure Application Gateway för inkommande HTTPS-begäranden och proxytjänster från tredje part som körs på virtuella datorer för filtrerad utgående åtkomst till Internetresurser.
- ExpressRoute och virtuell VPN-nätverksgateway för anslutning till lokala nätverk.
Steg 2: Distribuera Virtual WAN hubbar
Distribuera en Virtual WAN hubb i varje region. Konfigurera Virtual WAN hubben med VPN- och ExpressRoute-funktioner enligt beskrivningen i följande artiklar:
- Självstudie: Skapa en plats-till-plats-anslutning med Azure Virtual WAN
- Självstudie: Skapa en ExpressRoute-association med Hjälp av Azure Virtual WAN
Anteckning
Azure Virtual WAN måste använda standard-SKU:n för att aktivera några av de trafiksökvägar som visas i den här artikeln.
Bild 2: Kundhanterad hubb och eker till Virtual WAN migrering
Steg 3: Ansluta fjärrplatser (ExpressRoute och VPN) till Virtual WAN
Anslut Virtual WAN hubben till befintliga ExpressRoute-kretsar och konfigurera plats-till-plats-VPN via Internet till alla fjärrgrenar.
Figur 3: Kundhanterad hubb och eker till Virtual WAN migrering
Nu börjar den lokala nätverksutrustningen ta emot vägar som återspeglar DET IP-adressutrymme som tilldelats det Virtual WAN hanterade virtuella hubbnätverket. Fjärr-VPN-anslutna grenar i det här skedet ser två sökvägar till alla befintliga program i de virtuella ekernätverken. Dessa enheter bör konfigureras för att fortsätta att använda tunneln till den kundhanterade hubben för att säkerställa symmetrisk routning under övergångsfasen.
Steg 4: Testa hybridanslutningen via Virtual WAN
Innan du använder den hanterade Virtual WAN hubben för produktionsanslutning rekommenderar vi att du konfigurerar ett virtuellt testnätverk med ekrar och Virtual WAN VNet-anslutning. Kontrollera att anslutningar till den här testmiljön fungerar via ExpressRoute och plats-till-plats-VPN innan du fortsätter med nästa steg.
Figur 4: Kundhanterad hub-and-spoke till Virtual WAN migrering
I det här skedet är det viktigt att känna till att både det ursprungliga kundhanterade virtuella hubbnätverket och det nya Virtual WAN Hub båda är anslutna till samma ExpressRoute-krets. Därför har vi en trafikväg som kan användas för att aktivera ekrar i båda miljöerna för att kommunicera. Trafik från en eker som är kopplad till det kundhanterade virtuella hubbnätverket passerar till exempel de MSEE-enheter som används för ExpressRoute-kretsen för att nå alla ekrar som är anslutna via en VNet-anslutning till den nya Virtual WAN hubben. Detta möjliggör en mellanlagrad migrering av ekrar i steg 5.
Steg 5: Överföra anslutningen till en virtuell WAN-hubb
bild 5: Kundhanterad hubb och eker till Virtual WAN migrering
a. Ta bort befintliga peering-anslutningar från virtuella ekernätverk till den gamla kundhanterade hubben. Åtkomst till program i virtuella ekernätverk är inte tillgänglig förrän stegen a-c har slutförts.
b. Anslut de virtuella ekernätverken till den Virtual WAN hubben via VNet-anslutningar.
c. Ta bort alla användardefinierade vägar (UDR) som tidigare använts i virtuella ekernätverk för eker-till-eker-kommunikation. Den här sökvägen aktiveras nu genom dynamisk routning som är tillgänglig i Virtual WAN hubben.
d. Befintliga ExpressRoute- och VPN-gatewayer i den kundhanterade hubben har nu inaktiverats för att tillåta nästa steg (e).
e. Anslut den gamla kundhanterade hubben (det virtuella hubbnätverket) till Virtual WAN hubben via en ny VNet-anslutning.
Steg 6: Den gamla hubben blir eker för delade tjänster
Nu har vi gjort om vårt Azure-nätverk för att göra Virtual WAN hubben till den centrala punkten i vår nya topologi.
bild 6: Kundhanterad hubb och eker till Virtual WAN migrering
Eftersom Virtual WAN hubben är en hanterad entitet och inte tillåter distribution av anpassade resurser, till exempel virtuella datorer, finns blocket för delade tjänster nu som ett virtuellt ekernätverk och är värd för funktioner som ingress via internet via Azure Application Gateway eller nätverksvirtualiserad installation. Trafik mellan miljön för delade tjänster och virtuella serverdelsdatorer överför nu den Virtual WAN hanterade hubben.
Steg 7: Optimera den lokala anslutningen för att fullt ut använda Virtual WAN
I det här skedet har Contoso mestadels slutfört sin migrering av affärsprogram till Microsoft Cloud, med bara några äldre program kvar i den lokala domänkontrollanten.
Figur 7: Kundhanterad hub-and-spoke till Virtual WAN migrering
För att utnyttja alla funktioner i Azure Virtual WAN bestämmer sig Contoso för att inaktivera sina äldre lokala VPN-anslutningar. Alla grenar som fortsätter att komma åt HQ- eller DC-nätverk kan överföra det globala Microsoft-nätverket med hjälp av den inbyggda transitroutningen för Azure Virtual WAN.
Anteckning
ExpressRoute Global Reach krävs för kunder som vill utnyttja Microsofts stamnät för att tillhandahålla ExpressRoute till ExpressRoute-överföring (visas inte bild 7.).
Sluttillståndsarkitektur och trafikvägar
Bild: Dubbla regioner Virtual WAN
Det här avsnittet innehåller en sammanfattning av hur den här topologin uppfyller de ursprungliga kraven genom att titta på några exempel på trafikflöden.
Sökväg 1
Sökväg 1 visar trafikflödet från en S2S VPN-ansluten gren i Asien till ett virtuellt Azure-nätverk i regionen Sydostasien.
Trafiken dirigeras enligt följande:
Asien-grenen är ansluten via motståndskraftiga S2S BGP-aktiverade tunnlar till Sydostasien Virtual WAN hubb.
Asien Virtual WAN hubb dirigerar trafik lokalt till anslutna virtuella nätverk.
Sökväg 2
Sökväg 2 visar trafikflödet från det ExpressRoute-anslutna europeiska huvudkontoret till ett virtuellt Azure-nätverk i regionen Sydostasien.
Trafiken dirigeras enligt följande:
European HQ är anslutet via ExpressRoute-kretsen till Europa, västra Virtual WAN hubb.
Virtual WAN globala hubb-till-hubb-anslutning möjliggör överföring av trafik till VNet som är anslutet i en fjärransluten region.
Sökväg 3
Sökväg 3 visar trafikflödet från den lokala domänkontrollanten i Asien som är ansluten till Private WAN till en europeisk S2S-ansluten gren.
Trafiken dirigeras enligt följande:
Asia DC är anslutet till det lokala privata WAN-transportföretaget.
ExpressRoute-kretsen avslutas lokalt i Private WAN ansluter till Sydostasiens Virtual WAN hubb.
Virtual WAN globala hubb-till-hubb-anslutning möjliggör överföring av trafik.
Sökväg 4
Sökväg 4 visar trafikflödet från ett virtuellt Azure-nätverk i regionen Sydostasien till ett virtuellt Azure-nätverk i europa, västra.
Trafiken dirigeras enligt följande:
- Virtual WAN globala hubb-till-hubb-anslutning möjliggör intern överföring av alla anslutna virtuella Azure-nätverk utan ytterligare användarkonfiguration.
Sökväg 5
Sökväg 5 visar trafikflödet från centrala VPN-användare (P2S) till ett virtuellt Azure-nätverk i regionen Europa, västra.
Trafiken dirigeras enligt följande:
Användare av bärbara datorer och mobila enheter använder OpenVPN-klienten för transparent anslutning till P2S VPN-gatewayen i Europa, västra.
Europa, västra Virtual WAN hubb dirigerar trafik lokalt till anslutna virtuella nätverk.
Säkerhets- och principkontroll via Azure Firewall
Contoso har nu verifierat anslutningen mellan alla grenar och virtuella nätverk i enlighet med kraven som beskrivs tidigare i den här artikeln. För att uppfylla kraven för säkerhetskontroll och nätverksisolering måste de fortsätta att separera och logga trafik via hubbnätverket. Tidigare utfördes den här funktionen av en virtuell nätverksinstallation (NVA). Contoso vill också inaktivera sina befintliga proxytjänster och använda interna Azure-tjänster för utgående Internetfiltrering.
Figure: Azure Firewall i Virtual WAN (skyddad virtuell hubb)
Följande övergripande steg krävs för att introducera Azure Firewall i Virtual WAN hubbar för att möjliggöra en enhetlig principkontrollpunkt. Mer information om den här processen och begreppet Säkra virtuella hubbar finns i Azure Firewall Manager.
- Skapa Azure Firewall princip.
- Länka brandväggsprincipen till Azure Virtual WAN hubb. Det här steget gör att den befintliga Virtual WAN hubben kan fungera som en säker virtuell hubb och distribuerar nödvändiga Azure Firewall resurser.
Anteckning
Det finns begränsningar som gäller användningen av skyddade virtuella hubbar, inklusive trafik mellan regioner. Mer information finns i Firewall Manager – kända problem.
Följande sökvägar visar anslutningsvägarna som är aktiverade med hjälp av Azure-skyddade virtuella hubbar:
Sökväg 6
Sökväg 6 visar säkert trafikflöde mellan virtuella nätverk inom samma region.
Trafiken dirigeras enligt följande:
Virtuella nätverk som är anslutna till samma säkra virtuella hubb dirigerar nu trafik till via Azure Firewall.
Azure Firewall kan tillämpa principer på dessa flöden.
Sökväg 7
Sökväg 7 visar trafikflödet från ett virtuellt Azure-nätverk till Internet eller security service från tredje part.
Trafiken dirigeras enligt följande:
Virtuella nätverk som är anslutna till den säkra virtuella hubben kan skicka trafik till offentliga mål på Internet med hjälp av Säker hubb som en central internetåtkomstpunkt.
Den här trafiken kan filtreras lokalt med hjälp av Azure Firewall FQDN-regler eller skickas till en säkerhetstjänst från tredje part för inspektion.
Sökväg 8
Sökväg 8 visar trafikflödet från branch-till-Internet eller security service från tredje part.
Trafiken dirigeras enligt följande:
Grenar som är anslutna till den säkra virtuella hubben kan skicka trafik till offentliga mål på Internet med hjälp av Secure Hub som en central punkt för Internetåtkomst.
Den här trafiken kan filtreras lokalt med hjälp av Azure Firewall FQDN-regler eller skickas till en säkerhetstjänst från tredje part för inspektion.
