Migrera till Azure Virtual WAN

Azure Virtual WAN företag förenklar sina globala anslutningar för att kunna dra nytta av det globala Microsoft-nätverkets skala. Den här artikeln innehåller teknisk information för företag som vill migrera från en befintlig kundstyrd topologi med nav och ekrar till en design som utnyttjar Microsoft-hanterade Virtual WAN hubbar.

Information om de fördelar som Azure Virtual WAN gör det möjligt för företag att använda ett molncentrerat modernt globalt företagsnätverk finns i Global transit network architecture and Virtual WAN.

nav och ekrar Bild: Azure Virtual WAN

Anslutningsmodellen azure hub-and-spoke har använts av tusentals kunder för att utnyttja standardbeteendet för transitiv routning i Azure-nätverkstjänster 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 anslutnings topologier, 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 kund hanterad 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 som baseras på den kund hanterade nav-och-eker-arkitekturen, inklusive regionala virtuella hubbnätverk för hybridanslutningar. Som en del av flytten 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.

Contosos befintliga nätverkstopologi Bild: Contosos befintliga nätverkstopologi

Följande punkter kan tolkas 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 också VPN-tunnlar direkt till 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 Contosos migrering till molnet och som måste optimeras vad gäller kostnad, skalning och prestanda. Sammanfattningsvis måste följande krav uppfyllas:

  • Tillhandahålla både huvudkontor (HQ) och avdelningskontor med optimerad sökvä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:
    • Gren-till-VNet: VPN-anslutna kontor måste kunna komma åt program som migrerats till molnet i den lokala Azure-regionen.
    • Gren-till-hubb till hubb-till-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.
    • Avdelning-till-hubb till hubb-till-gren: Globalt separerade VPN-anslutna kontor måste kunna kommunicera med varandra och alla ExpressRoute-anslutna HQ/DC-platser.
    • Gren-till-Internet: Anslutna platser 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-till-Hub till hub-to-VNet: Virtuella spoke-nätverk i de olika regionerna måste kunna kommunicera med varandra.
  • Ge Contosos roaminganvändare (bärbara datorer och telefoner) möjlighet att komma åt företagets resurser utan att använda företagsnätverket.

Azure Virtual WAN arkitektur

Följande bild visar en högnivåvy över den uppdaterade måltopologin med hjälp Azure Virtual WAN för att uppfylla kraven som beskrivs i föregående avsnitt.

Contosos virtual WAN-arkitektur Bild: Azure Virtual WAN arkitektur

Sammanfattning:

  • HQ i Europa förblir ExpressRoute-anslutet. Den lokala domänkontrollanten i Europa migreras helt till Azure och inaktiveras nu.
  • Asien 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 som distribuerats i både Europa, västra och Asien, sydöstra Azure-regioner för att tillhandahålla anslutningshubb för ExpressRoute- och VPN-anslutna enheter.
  • Hubbar tillhandahåller även VPN-avslutning för roaminganvändare över flera klienttyper med Hjälp av 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 som också tillhandahålls av Azure Virtual WAN. Lokal Internet-utbrytning 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: Kund managed hub-and-spoke i en region

Följande bild visar en enda regiontopologi för Contoso före Azure Virtual WAN:

Topologi för en region Bild 1: En manuell nav-och-eker för en enskild region

I enlighet med nav-och-eker-metoden innehåller det kund-hanterade 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/Routning av brandväggstjänster tillhandahålls av en virtuell nätverksinstallation från tredje part, vilket möjliggör LAYER-3 IP-routning av eker-till-eker-nivå 3.
  • Inkommande/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 en Virtual WAN med VPN- och ExpressRoute-funktioner enligt beskrivningen i följande artiklar:

Anteckning

Azure Virtual WAN måste använda standard-SKU:n för att aktivera några av de trafikvägar som visas i den här artikeln.

Distribuera Virtual WAN-hubbar Bild 2: Kund managed hub-and-spoke to Virtual WAN migration

Steg 3: Anslut fjärrplatser (ExpressRoute och VPN) till Virtual WAN

Anslut Virtual WAN till befintliga ExpressRoute-kretsar och konfigurera PLATS-till-plats-VPN via Internet till eventuella fjärrgrenar.

Ansluta fjärrplatser till Virtual WAN Bild 3: Kundstyrd nav-och-eker till Virtual WAN migrering

Nu börjar lokal nätverksutrustning ta emot vägar som återspeglar IP-adressutrymmet som tilldelats det virtuella Virtual WAN-hanterade hubbnätverket. Fjärranslutna VPN-anslutna grenar i det här skedet ser två vä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 kund hanterade 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 för produktionsanslutning rekommenderar vi att du ställer in ett virtuellt test-ekernätverk 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.

Testa hybridanslutning via Virtual WAN Bild 4: Kundstyrd nav-och-eker till Virtual WAN migrering

I det här skedet är det viktigt att känna till att både det ursprungliga kund-hanterade virtuella hubbnätverket och det nya Virtual WAN Hub är anslutna till samma ExpressRoute-krets. På grund av detta har vi en trafikväg som kan användas för att möjliggöra kommunikation med ekrar i båda miljöerna. Trafik från en eker som är kopplad till det kund-hanterade hubbens virtuella nätverk passerar till exempel MSEE-enheter som används för ExpressRoute-kretsen för att nå en eker som är ansluten via en VNet-anslutning till den nya Virtual WAN-hubben. Detta möjliggör stegvis migrering av ekrar i steg 5.

Steg 5: Övergå från anslutning till en virtuell WAN-hubb

Övergå från anslutning till Virtual WAN hubb Bild 5: Kundstyrd nav-och-eker till Virtual WAN migrering

en. Ta bort befintliga peering-anslutningar från virtuella spoke-nätverk till den gamla kund hanterade hubben. Åtkomst till program i virtuella ekernätverk är inte tillgänglig förrän steg a-c har slutförts.

b. Anslut de virtuella ekernätverken till Virtual WAN 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 av dynamisk routning som är tillgänglig Virtual WAN hubben.

d. Befintliga ExpressRoute- och VPN-gatewayer i den kund hanterade hubben inaktiveras nu för att tillåta nästa steg (e).

e. Anslut den gamla kund hanterade hubben (virtuellt hubbnätverk) till Virtual WAN via en ny VNet-anslutning.

Steg 6: Gammal hubb blir eker för delade tjänster

Vi har nu gjort om vårt Azure-nätverk för att Virtual WAN navet till den centrala punkten i vår nya topologi.

Den gamla hubben blir Shared Services-eker Bild 6: Kundstyrd nav-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 internetingress via Azure Application Gateway eller en virtualiserad nätverksinstallation. Trafik mellan miljön för delade tjänster och virtuella datorer i serversidan överförs nu Virtual WAN den hanterade hubben.

Steg 7: Optimera lokal anslutning för att utnyttja Virtual WAN

I det här skedet har Contoso huvudsakligen slutfört migreringen av affärsprogram till Microsoft Cloud, med bara några få äldre program kvar i den lokala domänkontrollanten.

Optimera lokal anslutning för att utnyttja Virtual WAN Bild 7: Kundstyrd nav-och-eker till Virtual WAN migrering

För att dra nytta av Azure Virtual WAN funktioner bestämmer sig Contoso för att inaktivera sina äldre lokala VPN-anslutningar. Alla grenar som fortsätter att få åtkomst till HQ- eller DC-nätverk kan överförs i Microsofts globala nätverk med hjälp av den inbyggda överföringsroutning som 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

Sluttillståndsarkitektur och trafikvägar Bild: Dubbla 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 azure-VNet i Asien, sydöstra region.

Trafiken dirigeras på följande sätt:

  • Asien-grenen är ansluten via motståndskraftiga S2S BGP-aktiverade tunnlar till Asien, sydöstra Virtual WAN hubb.

  • Asien Virtual WAN dirigerar trafik lokalt till det anslutna virtuella nätverket.

Flöde 1

Sökväg 2

Sökväg 2 visar trafikflödet från det ExpressRoute-anslutna europeiska HQ:et till ett azure-VNet i Asien, sydöstra regionen.

Trafiken dirigeras på följande sätt:

  • Europeiska HQ är anslutet via ExpressRoute-krets till Europa, västra Virtual WAN navet.

  • Virtual WAN global anslutning mellan hubbar möjliggör överföring av trafik till VNet som är anslutet i en fjärrregion.

Flöde 2

Sökväg 3

Sökväg 3 visar trafikflödet från den lokala Asien-domänkontrollanten som är ansluten till Private WAN till en europeiska S2S-ansluten gren.

Trafiken dirigeras på följande sätt:

  • Asien dc är ansluten till lokala Private WAN-transportföretag.

  • ExpressRoute-kretsen avslutas lokalt i privat WAN-anslutning till Asien, sydöstra Virtual WAN hubben.

  • Virtual WAN global anslutning mellan hubbar möjliggör överföring av trafik.

Flöde 3

Sökväg 4

Sökväg 4 visar trafikflödet från ett azure-VNet i Asien, sydöstra region till ett azure-VNet i regionen Europa, västra.

Trafiken dirigeras på följande sätt:

  • Virtual WAN global anslutning mellan hubbar möjliggör intern överföring av alla anslutna virtuella Azure-nätverk utan ytterligare användarkonfiguration.

Flöde 4

Sökväg 5

Sökväg 5 visar trafikflödet från roaming-VPN-användare (P2S) till ett azure-VNet 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.

  • Europa, västra Virtual WAN dirigerar trafik lokalt till det anslutna virtuella nätverket.

Flöde 5

Säkerhets- och principkontroll via Azure Firewall

Contoso har nu verifierat anslutningen mellan alla grenar och virtuella nätverk i enlighet med de krav som beskrivs tidigare i den här artikeln. För att uppfylla kraven på säkerhetskontroll och nätverksisolering måste de fortsätta att separera och logga trafik via navnä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.

Säkerhets- och principkontroll via Azure Firewall Bild: Azure Firewall i Virtual WAN (skyddad virtuell hubb)

Följande avancerade steg krävs för att introducera Azure Firewall i Virtual WAN 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.

  1. Skapa Azure Firewall princip.
  2. Länka brandväggsprincipen till Azure Virtual WAN hubb. I det här steget kan Virtual WAN befintliga hubben fungera som en skyddad virtuell hubb och distribuera de 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 de anslutningsvägar 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 på följande sätt:

  • Virtuella nätverk som är anslutna till samma skyddade virtuella hubb dirigerar nu trafik till via Azure Firewall.

  • Azure Firewall kan tillämpa en princip på dessa flöden.

Flöde 6

Sökväg 7

Sökväg 7 visar trafikflödet från ett azure-VNet 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 punkt för Internetåtkomst.

  • Trafiken kan filtreras lokalt med hjälp Azure Firewall FQDN-regler eller skickas till en säkerhetstjänst från tredje part för granskning.

Flöde 7

Sökväg 8

Sökväg 8 visar trafikflödet från gren-till-Internet eller tredje parts säkerhetstjänst.

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 Säker hubb som en central punkt för Internetåtkomst.

  • Trafiken kan filtreras lokalt med hjälp Azure Firewall FQDN-regler eller skickas till en säkerhetstjänst från tredje part för granskning.

Flöde 8

Nästa steg

Läs mer om Azure Virtual WAN.