Migreren naar Azure Virtual WAN

Azure Virtual WAN kunnen bedrijven hun wereldwijde connectiviteit vereenvoudigen om te profiteren van de schaal van het wereldwijde netwerk van Microsoft. Dit artikel bevat technische details voor bedrijven die willen migreren van een bestaande door de klant beheerde hub-and-spoke-topologie naar een ontwerp dat gebruik maakt van door Microsoft beheerde Virtual WAN hubs.

Zie Wereldwijde architectuur voor doorvoernetwerk en Azure Virtual WAN voor meer informatie over de voordelen die Azure Virtual WAN biedt voor ondernemingen die over willen gaan op een Virtual WAN cloudgericht modern bedrijfsnetwerk.

Afbeelding: Azure Virtual WAN

Het azure hub-and-spoke-connectiviteitsmodel is door duizenden klanten gebruikt om gebruik te maken van het standaard transitieve routeringsgedrag van Azure-netwerken om eenvoudige en schaalbare cloudnetwerken te bouwen. Azure Virtual WAN bouwt voort op deze concepten en introduceert nieuwe mogelijkheden die wereldwijde connectiviteits topologies mogelijk maken, niet alleen tussen on-premises locaties en Azure, maar ook zodat klanten de schaal van het Microsoft-netwerk kunnen benutten om hun bestaande wereldwijde netwerken te verbeteren.

In dit artikel wordt beschreven hoe u een bestaande door de klant beheerde hub-and-spoke-omgeving migreert naar een topologie die is gebaseerd op Azure Virtual WAN.

Scenario

Contoso is een wereldwijde financiële organisatie met kantoren in Europa en Azië. Ze zijn van plan om hun bestaande toepassingen te verplaatsen van een on-premises datacenter in naar Azure en hebben een basisontwerp gebouwd op basis van de door de klant beheerde hub-and-spoke-architectuur, met inbegrip van regionale virtuele hubnetwerken voor hybride connectiviteit. Als onderdeel van de overstap naar cloudtechnologieën heeft het netwerkteam de taak om ervoor te zorgen dat de connectiviteit wordt geoptimaliseerd voor het bedrijf.

In de volgende afbeelding ziet u een algemeen overzicht van het bestaande wereldwijde netwerk, inclusief connectiviteit met meerdere Azure-regio's.

Afbeelding: Bestaande netwerktopologie van Contoso

De volgende punten kunnen worden begrepen uit de bestaande netwerktopologie:

• Een hub-and-spoke-topologie wordt gebruikt in meerdere regio's, waaronder ExpressRoute-circuits, voor connectiviteit met een gemeenschappelijk wan (Private Wide Area Network).

• Sommige van deze sites hebben ook VPN-tunnels rechtstreeks in Azure om toepassingen te bereiken die in de cloud worden gehost.

Vereisten

Het netwerkteam is belast met het leveren van een wereldwijd netwerkmodel dat de Contoso-migratie naar de cloud kan ondersteunen en moet optimaliseren op het gebied van kosten, schaal en prestaties. Kortom, aan de volgende vereisten moet worden voldaan:

• Bied zowel het hoofdkantoor (HQ) als de filialen een geoptimaliseerd pad naar in de cloud gehoste toepassingen.
• Verwijder de afhankelijkheid van bestaande on-premises datacenters (DC) voor VPN-beëindiging terwijl de volgende verbindingspaden behouden blijven:
  • Vertakking naar VNet: met VPN verbonden kantoren moeten toegang hebben tot toepassingen die zijn gemigreerd naar de cloud in de lokale Azure-regio.
  • Vertakking-naar-hub naar hub-naar-VNet: met VPN verbonden kantoren moeten toegang hebben tot toepassingen die zijn gemigreerd naar de cloud in de externe Azure-regio.
  • Vertakking-naar-vertakking: regionale met VPN verbonden kantoren moeten met elkaar kunnen communiceren en expressRoute verbonden HQ/DC-sites.
  • Vertakking naar hub naar vertakking: wereldwijd gescheiden VPN-verbonden kantoren moeten met elkaar en met ExpressRoute verbonden HQ/DC-sites kunnen communiceren.
  • Vertakking naar internet: verbonden sites moeten kunnen communiceren met internet. Dit verkeer moet worden gefilterd en geregistreerd.
  • VNet-naar-VNet: virtuele spoke-netwerken in dezelfde regio moeten met elkaar kunnen communiceren.
  • VNet-naar-hub naar hub-naar-VNet: virtuele spoke-netwerken in de verschillende regio's moeten met elkaar kunnen communiceren.
• Bied Contoso-zwervende gebruikers (laptop en telefoon) de mogelijkheid om toegang te krijgen tot bedrijfsresources, maar niet op het bedrijfsnetwerk.

Azure Virtual WAN architectuur

In de volgende afbeelding ziet u een weergave op hoog niveau van de bijgewerkte doeltopologie met behulp van Azure Virtual WAN om te voldoen aan de vereisten die in de vorige sectie zijn beschreven.

Afbeelding: Azure Virtual WAN architectuur

Samenvatting:

• Het hoofdkantoor in Europa blijft ExpressRoute verbonden, de on-premises DC in Europa wordt volledig gemigreerd naar Azure en nu buiten gebruik gesteld.
• Azië DC en hoofdkantoor blijven verbonden met Private WAN. Azure Virtual WAN nu gebruikt om het lokale netwerk van de provider uit te breiden en wereldwijde connectiviteit te bieden.
• Azure Virtual WAN-hubs die zijn geïmplementeerd in zowel azure Europa - west- als Azië - oost Azure-regio's om connectiviteitshubs te bieden voor ExpressRoute- en VPN-verbonden apparaten.
• Hubs bieden ook VPN-beëindiging voor zwervende gebruikers voor meerdere clienttypen met behulp van OpenVPN-connectiviteit met het wereldwijde mesh-netwerk, waardoor niet alleen toepassingen die zijn gemigreerd naar Azure, maar ook alle resources die on-premises blijven, toegang krijgen.
• Internetverbinding voor resources binnen een virtueel netwerk dat wordt geleverd door Azure Virtual WAN.

Internetverbinding voor externe sites wordt ook geleverd door Azure Virtual WAN. Lokale internetproviders die via partnerintegratie worden ondersteund voor geoptimaliseerde toegang tot SaaS-services, zoals Microsoft 365.

Migreren naar Virtual WAN

Deze sectie bevat de verschillende stappen voor het migreren naar Azure Virtual WAN.

Stap 1: door de klant beheerde hub en spoke in één regio

In de volgende afbeelding ziet u één regiotopologie voor Contoso vóór de implementatie van Azure Virtual WAN:

Afbeelding 1: Handmatige hub-and-spoke voor één regio

In overeenstemming met de hub-and-spoke-benadering bevat het door de klant beheerde virtuele hubnetwerk verschillende functieblokken:

• Gedeelde services (elke algemene functie die vereist is voor meerdere spokes). Voorbeeld: Contoso gebruikt Windows Server-domeincontrollers op virtuele IaaS-machines (Infrastructure-as-a-Service).
• Ip-/routeringsfirewallservices worden geleverd door een virtueel netwerkapparaat van derden, waardoor spoke-to-spoke layer-3 IP-routering mogelijk is.
• Inkomende/uitgaande internetservices, waaronder Azure Application Gateway voor inkomende HTTPS-aanvragen en proxyservices van derden die worden uitgevoerd op virtuele machines voor gefilterde uitgaande toegang tot internetbronnen.
• Virtuele ExpressRoute- en VPN-netwerkgateway voor connectiviteit met on-premises netwerken.

Stap 2: implementatie Virtual WAN hubs

Implementeer Virtual WAN hub in elke regio. Stel de Virtual WAN hub in met VPN- en ExpressRoute-functionaliteit, zoals beschreven in de volgende artikelen:

• Zelfstudie: Een site-naar-site-verbinding maken met Azure Virtual WAN
• Zelfstudie: Een ExpressRoute-koppeling maken met behulp van Azure Virtual WAN

Afbeelding 2: Door de klant beheerde hub en spoke naar Virtual WAN migratie

Stap 3: externe sites (ExpressRoute en VPN) verbinden met Virtual WAN

Verbind de Virtual WAN-hub met de bestaande ExpressRoute-circuits en stel site-naar-site-VPN's via internet in op externe vertakkingen.

Afbeelding 3: Door de klant beheerde hub en spoke naar Virtual WAN migratie

Op dit moment ontvangen on-premises netwerkapparatuur routes die de IP-adresruimte weerspiegelen die is toegewezen aan Virtual WAN beheerde hub-VNet. Externe met VPN verbonden vertakkingen in deze fase zien twee paden naar bestaande toepassingen in de virtuele spoke-netwerken. Deze apparaten moeten worden geconfigureerd om de tunnel naar de door de klant beheerde hub te blijven gebruiken om symmetrische routering te garanderen tijdens de overgangsfase.

Stap 4: Hybride connectiviteit testen via Virtual WAN

Voordat u de beheerde Virtual WAN hub voor productieconnectiviteit gebruikt, raden we u aan om een virtueel test spoke-netwerk in te stellen en Virtual WAN VNet-verbinding. Controleer of verbindingen met deze testomgeving werken via ExpressRoute en site-naar-site-VPN voordat u doorgaat met de volgende stappen.

Afbeelding 4: Door de klant beheerde hub en spoke naar Virtual WAN migratie

In deze fase is het belangrijk te weten dat zowel het oorspronkelijke door de klant beheerde hub-netwerk als de nieuwe Virtual WAN Hub beide zijn verbonden met hetzelfde ExpressRoute-circuit. Daarom hebben we een verkeerspad dat kan worden gebruikt om spokes in beide omgevingen te laten communiceren. Verkeer van een spoke die is gekoppeld aan het virtuele netwerk van de door de klant beheerde hub gaat bijvoorbeeld via de MSEE-apparaten die worden gebruikt voor het ExpressRoute-circuit om een spoke te bereiken die is verbonden via een VNet-verbinding met de nieuwe Virtual WAN-hub. Hierdoor kan een gefaseerd migreren van spokes in stap 5.

Stap 5: Connectiviteit overstappen naar een virtuele WAN-hub

Afbeelding 5: Door de klant beheerde hub-and-spoke naar Virtual WAN migratie

een. Verwijder de bestaande peeringverbindingen van virtuele Spoke-netwerken naar de oude door de klant beheerde hub. Toegang tot toepassingen in virtuele spoke-netwerken is pas beschikbaar als de stappen a-c zijn voltooid.

b. Verbind de virtuele spoke-netwerken met Virtual WAN hub via VNet-verbindingen.

c. Verwijder alle door de gebruiker gedefinieerde routes (UDR) die eerder in virtuele spoke-netwerken werden gebruikt voor spoke-to-spoke-communicatie. Dit pad is nu ingeschakeld door dynamische routering die beschikbaar is in Virtual WAN hub.

d. Bestaande ExpressRoute- en VPN-gateways in de door de klant beheerde hub worden nu buiten gebruik gesteld om de volgende stap (e) toe te staan.

e. Verbind de oude door de klant beheerde hub (virtueel hubnetwerk) met Virtual WAN hub via een nieuwe VNet-verbinding.

Stap 6: Oude hub wordt een spoke voor gedeelde services

We hebben ons Azure-netwerk nu opnieuw ontworpen om van de Virtual WAN hub het centrale punt in onze nieuwe topologie te maken.

Afbeelding 6: Door de klant beheerde hub en spoke naar Virtual WAN migratie

Omdat de Virtual WAN-hub een beheerde entiteit is en de implementatie van aangepaste resources, zoals virtuele machines, niet toestaat, bestaat het blok met gedeelde services nu als een virtueel spoke-netwerk en host het functies zoals internetingressie via Azure Application Gateway of een gevirtualiseerd netwerkapparaat. Verkeer tussen de omgeving met gedeelde services en virtuele back-en-machine wordt nu Virtual WAN beheerde hub.

Stap 7: on-premises connectiviteit optimaliseren om volledig gebruik te Virtual WAN

In deze fase heeft Contoso de migratie van zakelijke toepassingen in naar de Microsoft Cloud grotendeels voltooid, met nog maar enkele verouderde toepassingen binnen de on-premises dc.

Afbeelding 7: Door de klant beheerde hub en spoke naar Virtual WAN migratie

Om gebruik te maken van de volledige Azure Virtual WAN, besluit Contoso om hun verouderde on-premises VPN-verbindingen buiten gebruik te stellen. Vertakkingen die nog steeds toegang hebben tot het hoofdkantoor of DC-netwerken, kunnen het wereldwijde netwerk van Microsoft doorvoeren met behulp van de ingebouwde transitroutering van Azure Virtual WAN.

End-state architectuur en verkeerspaden

Afbeelding: Dubbele regio-Virtual WAN

In deze sectie vindt u een overzicht van hoe deze topologie voldoet aan de oorspronkelijke vereisten door enkele voorbeeldverkeersstromen te bekijken.

Pad 1

Pad 1 toont de verkeersstroom van een met S2S VPN verbonden vertakking in Azië naar een Azure-VNet in Azië - oost regio.

Het verkeer wordt als volgt gerouteerd:

• De Azië-vertakking is verbonden via flexibele tunnels met S2S BGP in South Azië - oost Virtual WAN hub.

• Azië Virtual WAN hub verkeer lokaal doorgestuurd naar verbonden VNet.

Pad 2

Pad 2 toont de verkeersstroom van het expressroute verbonden Europese hoofdkantoor naar een Azure-VNet in Azië - oost zuid-regio.

Het verkeer wordt als volgt gerouteerd:

• Europese hoofdkantoor is via het ExpressRoute-circuit verbonden met Europa - west Virtual WAN hub.

• Virtual WAN wereldwijde connectiviteit tussen hubs zorgt voor doorvoer van verkeer naar een VNet dat is verbonden in een externe regio.

Pad 3

Pad 3 toont de verkeersstroom van de on-premises DC Azië die is verbonden met Private WAN met een Europese S2S-verbonden vertakking.

Het verkeer wordt als volgt gerouteerd:

• Azië DC is verbonden met de lokale Private WAN-provider.

• Het ExpressRoute-circuit wordt lokaal beëindigd in Private WAN en maakt verbinding met de hub South Azië - oost Virtual WAN.

• Virtual WAN wereldwijde connectiviteit tussen hubs zorgt voor doorvoer van verkeer.

Pad 4

Pad 4 toont de verkeersstroom van een Azure-VNet in south Azië - oost naar een Azure VNet in Europa - west regio.

Het verkeer wordt als volgt gerouteerd:

• Virtual WAN hub-to-hub wereldwijde connectiviteit systeemeigen doorvoer van alle verbonden Azure VNets mogelijk zonder verdere configuratie van de gebruiker.

Pad 5

Pad 5 toont de verkeersstroom van zwervende VPN-gebruikers (P2S) naar een Azure VNet in Europa - west regio.

Het verkeer wordt als volgt gerouteerd:

• Gebruikers van laptop- en mobiele apparaten gebruiken de OpenVPN-client voor transparante connectiviteit met de P2S VPN-gateway in Europa - west.

• Europa - west Virtual WAN hub routeert verkeer lokaal naar verbonden VNet.

Beveiligings- en beleidsbeheer via Azure Firewall

Contoso heeft nu de connectiviteit tussen alle vertakkingen en VNets gevalideerd overeenkomstig de vereisten die eerder in dit artikel zijn besproken. Om te voldoen aan hun vereisten voor beveiligingsbeheer en netwerkisolatie, moeten ze verkeer via het hubnetwerk blijven scheiden en in een logboek houden. Voorheen werd deze functie uitgevoerd door een virtueel netwerkapparaat (NVA). Contoso wil ook hun bestaande proxyservices buiten gebruik stellen en systeemeigen Azure-services gebruiken voor uitgaande internetfilters.

Afbeelding: Azure Firewall in Virtual WAN (beveiligde virtuele hub)

De volgende stappen op hoog niveau zijn vereist om de Azure Firewall in Virtual WAN hubs te introduceren om een uniform beheerpunt voor beleid mogelijk te maken. Zie voor meer informatie over dit proces en het concept van Beveiligde virtuele hubs Azure Firewall Manager.

1. Maak Azure Firewall beleid.
2. Firewallbeleid koppelen aan Azure Virtual WAN hub. Met deze stap kan de Virtual WAN hub functioneren als een beveiligde virtuele hub en worden de vereiste Azure Firewall geïmplementeerd.

De volgende paden tonen de connectiviteitspaden die zijn ingeschakeld met behulp van met Azure beveiligde virtuele hubs:

Pad 6

Pad 6 toont een beveiligde verkeersstroom tussen VNets binnen dezelfde regio.

Het verkeer wordt als volgt gerouteerd:

• Virtuele netwerken die zijn verbonden met dezelfde beveiligde virtuele hub, routeer nu verkeer naar via de Azure Firewall.

• Azure Firewall kunt beleid toepassen op deze stromen.

Pad 7

Pad 7 toont de verkeersstroom van een Azure-VNet naar internet of de beveiligingsservice van derden.

Het verkeer wordt als volgt gerouteerd:

• Virtuele netwerken die zijn verbonden met de beveiligde virtuele hub kunnen verkeer verzenden naar openbare bestemmingen op internet, met behulp van de beveiligde hub als een centraal punt van internettoegang.

• Dit verkeer kan lokaal worden gefilterd met behulp Azure Firewall FQDN-regels of worden verzonden naar een externe beveiligingsservice voor inspectie.

Pad 8

Pad 8 toont de verkeersstroom van vertakking naar internet of beveiligingsservice van derden.

Het verkeer wordt als volgt gerouteerd:

• Vertakkingen die zijn verbonden met de beveiligde virtuele hub kunnen verkeer verzenden naar openbare bestemmingen op internet met behulp van de beveiligde hub als centraal punt van internettoegang.

• Dit verkeer kan lokaal worden gefilterd met behulp Azure Firewall FQDN-regels of worden verzonden naar een externe beveiligingsservice voor inspectie.

Volgende stappen

Meer informatie over Azure Virtual WAN.