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 det globala Microsoft-nätverket. Den här artikeln innehåller teknisk information för företag som vill migrera från en befintlig kundhanterad hub-and-spoke-topologi till en design som utnyttjar Microsoft-hanterade Virtual WAN-hubbar.
Information om fördelarna med Azure Virtual WAN för företag som använder ett molnbaserat globalt företagsnätverk finns i Global transit network architecture and Virtual WAN (Global transitnätverksarkitektur och Virtual WAN).
Bild: Azure Virtual WAN
Azure Hub-and-spoke-anslutningsmodellen har antagits av tusentals av våra kunder för att utnyttja standardbeteendet för transitiv routning i Azure Networking för att skapa enkla och skalbara molnnätverk. Azure Virtual WAN bygger vidare på dessa begrepp och introducerar nya funktioner som tillåter globala anslutningstopologier, inte bara mellan lokala platser och Azure, utan även gör det möjligt för kunder att utnyttja Microsoft-nätverkets skala 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 hybridanslutning. 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 översikt ö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 hub-and-spoke-topologi används i flera regioner, inklusive ExpressRoute-kretsar för anslutning tillbaka till ett gemensamt privat WIDE Area Network (WAN).
Vissa av dessa platser har också 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 när det gäller kostnader, skala och prestanda. Sammanfattningsvis ska följande krav uppfyllas:
- Ge både huvudkontor och avdelningskontor optimerad väg till molnbaserade program.
- Ta bort beroendet av befintliga lokala datacenter (DC) för VPN-avslutning samtidigt som du behåller följande anslutningsvägar:
- Branch-to-VNet: VPN-anslutna kontor måste kunna komma åt program som migrerats till molnet i den lokala Azure-regionen.
- Branch-to-Hub to 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 to Hub-to-branch: Globalt avgränsade VPN-anslutna kontor måste kunna kommunicera med varandra och alla ExpressRoute-anslutna HQ/DC-platser.
- Branch-to-Internet: Anslutna webbplatser måste kunna kommunicera med Internet. Den här trafiken måste filtreras och loggas.
- VNet-till-VNet: Virtuella ekernätverk i samma region måste kunna kommunicera med varandra.
- VNet-to-Hub till Hub-to-VNet: Virtuella ekernätverk i de olika regionerna måste kunna kommunicera med varandra.
- Ge Contoso roaminganvändare (bärbar dator och telefon) möjlighet att komma åt företagets resurser utan företagsnätverk.
Azure Virtual WAN-arkitektur
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 har nu inaktiverats.
- Asia DC och HQ förblir anslutna till Private WAN. Azure Virtual WAN används nu för att utöka det lokala operatörsnätverket och tillhandahålla global anslutning.
- Azure Virtual WAN-hubbar distribuerade i azure-regioner i både Europa, västra och Sydostasien för att tillhandahålla anslutningshubben för ExpressRoute- och VPN-anslutna enheter.
- Hubbar tillhandahåller också VPN-avslutning för roaminganvändare över flera klienttyper med OpenVPN-anslutning till det globala mesh-nä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. Lokalt internetutbrott 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 spoke-to-spoke layer-3.
- Internetingress-/utgående tjä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 virtuella 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
Kommentar
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-and-spoke till Virtual WAN-migrering
Steg 3: Ansluta fjärrplatser (ExpressRoute och VPN) till Virtual WAN
Anslut Virtual WAN-hubben till de befintliga ExpressRoute-kretsarna och konfigurera plats-till-plats-VPN via Internet till alla fjärrgrenar.
Bild 3: Kundhanterad hubb-and-spoke till Virtual WAN-migrering
Nu börjar den lokala nätverksutrustningen ta emot vägar som återspeglar DET IP-adressutrymme som tilldelats det virtuella WAN-hanterade hubbens virtuella nätverk. 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 hybridanslutning via Virtual WAN
Innan du använder den hanterade Virtual WAN-hubben för produktionsanslutning rekommenderar vi att du konfigurerar ett virtuellt test ekernätverk och en virtuell 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.
Bild 4: Kundhanterad hubb-and-spoke till Virtual WAN-migrering
I det här skedet är det viktigt att känna igen att både det ursprungliga kundhanterade virtuella hubbnätverket och den nya Virtual WAN Hub båda är anslutna till samma ExpressRoute-krets. Därför har vi en trafiksökväg som kan användas för att aktivera ekrar i båda miljöerna för kommunikation. Till exempel kommer trafik från en eker som är kopplad till det kundhanterade virtuella hubbnätverket att passera 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 stegvis migrering av ekrar i steg 5.
Steg 5: Övergå till anslutning till virtuell WAN-hubb
Bild 5: Kundhanterad hubb-and-spoke till Virtual WAN-migrering
a. Ta bort befintliga peering-anslutningar från virtuella Spoke-nätverk till den gamla kundhanterade hubben. Åtkomst till program i virtuella ekernätverk är inte tillgänglig förrän a-c-stegen har slutförts.
b. Anslut de virtuella ekernätverken till Virtual WAN-hubben via VNet-anslutningar.
c. Ta bort alla användardefinierade vägar (UDR) som tidigare användes 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: Gammal hubb 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-and-spoke 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 värdfunktioner som ingress via Azure Application Gateway eller nätverksvirtualiserade installationer. Trafik mellan miljön för delade tjänster och virtuella serverdelsdatorer överför nu den Virtual WAN-hanterade hubben.
Steg 7: Optimera lokal anslutning för att fullt ut använda Virtual WAN
I det här skedet har Contoso mestadels slutfört sina migreringar av affärsprogram i Microsoft Cloud, med bara några äldre program kvar i den lokala domänkontrollanten.
Bild 7: Kundhanterad hubb-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.
Kommentar
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 trafiksökvägar
Bild: Virtuellt WAN med dubbla regioner
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 på följande sätt:
Asien-grenen är ansluten via motståndskraftiga S2S BGP-aktiverade tunnlar till South East Asia Virtual WAN Hub.
Asia Virtual WAN Hub 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 på följande sätt:
Det europeiska huvudkontoret är anslutet via ExpressRoute-kretsen till Virtual WAN-hubben i Europa, västra.
Virtuell WAN hub-to-hub global anslutning möjliggör överföring av trafik till VNet som är anslutet i en fjärrregion.
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 på följande sätt:
Asia DC är anslutet till det lokala privata WAN-operatören.
ExpressRoute-kretsen avslutas lokalt i Private WAN ansluter till Virtual WAN-hubben i Sydostasien.
Virtuell WAN hub-to-hub global 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 regionen Europa, västra.
Trafiken dirigeras på följande sätt:
- Virtuell WAN hub-to-hub global 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 roaming-VPN-användare (P2S) till ett virtuellt Azure-nätverk i regionen Europa, västra.
Trafiken dirigeras på följande sätt:
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.
West Europe Virtual WAN Hub 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 inbyggda Azure-tjänster för utgående Internetfiltrering.
Bild: 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 aktivera 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-hubben. 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.
Kommentar
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 aktiveras 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 på följande sätt:
Virtuella nätverk som är anslutna till samma säkra virtuella hubb dirigerar nu trafik till via Azure Firewall.
Azure Firewall kan tillämpa principen 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 säkerhetstjänsten från tredje part.
Trafiken dirigeras på följande sätt:
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 plats för Internetåtkomst.
Den här trafiken kan filtreras lokalt med hjälp av FQDN-regler för Azure Firewall 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 avdelning till Internet eller säkerhetstjänst från tredje part.
Trafiken dirigeras på följande sätt:
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 FQDN-regler för Azure Firewall eller skickas till en säkerhetstjänst från tredje part för inspektion.
