Migreren naar Azure Virtual WAN
Met Azure Virtual WAN kunnen bedrijven hun wereldwijde connectiviteit vereenvoudigen om te profiteren van de schaal van het wereldwijde Microsoft-netwerk. Dit artikel bevat technische informatie voor bedrijven die willen migreren van een bestaande door de klant beheerde hub-and-spoke-topologie naar een ontwerp dat gebruikmaakt van door Microsoft beheerde Virtual WAN hubs.
Zie Global transit network architecture and Virtual WAN (Wereldwijde transitnetwerkarchitectuur en Virtual WAN) voor meer informatie over de voordelen die Azure Virtual WAN biedt voor ondernemingen die een cloudgericht, modern ondernemingsnetwerk gebruiken.
spoke-afbeelding: Azure Virtual WAN
Het hub-and-spoke-connectiviteitsmodel van Azure is door duizenden van onze klanten gebruikt om gebruik te maken van het standaardtransitieve routeringsgedrag van Azure Networking om eenvoudige en schaalbare cloudnetwerken te bouwen. Azure Virtual WAN bouwt voort op deze concepten en introduceert nieuwe mogelijkheden die wereldwijde connectiviteitstopologieën mogelijk maken, niet alleen tussen on-premises locaties en Azure, maar ook waarmee klanten de schaal van het Microsoft-netwerk kunnen gebruiken om hun bestaande wereldwijde netwerken uit te breiden.
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 zowel Europa als Azië. Ze zijn van plan om hun bestaande toepassingen van een on-premises datacentrum naar Azure te verplaatsen en hebben een basisontwerp gebouwd op basis van de door de klant beheerde hub-and-spoke-architectuur, inclusief virtuele regionale hubnetwerken voor hybride connectiviteit. Als onderdeel van de overstap naar cloudtechnologieën heeft het netwerkteam de taak gekregen om ervoor te zorgen dat hun connectiviteit wordt geoptimaliseerd voor het bedrijf in de toekomst.
In de volgende afbeelding ziet u een weergave op hoog niveau van het bestaande wereldwijde netwerk, inclusief connectiviteit met meerdere Azure-regio's.
: 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 particulier WAN (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 heeft de taak gekregen om een wereldwijd netwerkmodel te leveren dat de Contoso-migratie naar de cloud kan ondersteunen en moet optimaliseren op het gebied van kosten, schaal en prestaties. Samengevat moet aan de volgende vereisten worden voldaan:
- Bied zowel hoofdkwartaal (HQ) als filialen een geoptimaliseerd pad naar in de cloud gehoste toepassingen.
- Verwijder de afhankelijkheid van bestaande on-premises datacenters (DC) voor VPN-beëindiging met behoud van de volgende verbindingspaden:
- 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.
- Branch-to-branch: regionale VPN verbonden kantoren moeten met elkaar kunnen communiceren en ExpressRoute verbonden HQ/DC-sites.
- Branch-to-Hub naar Hub-to-Branch: Wereldwijd gescheiden VPN-verbonden kantoren moeten met elkaar kunnen communiceren en met alle expressRoute verbonden HQ/DC-sites.
- 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.
- Biedt contoso-zwervende gebruikers (laptop en telefoon) de mogelijkheid om toegang te krijgen tot bedrijfsbronnen terwijl ze zich niet op het bedrijfsnetwerk bevinden.
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.
: Azure Virtual WAN-architectuur
Samenvatting:
- Het hoofdkantoor in Europa blijft verbonden met ExpressRoute, de on-premises DC in Europa is volledig gemigreerd naar Azure en wordt nu buiten gebruik gesteld.
- Asia DC en HQ blijven verbonden met Private WAN. Azure Virtual WAN nu gebruikt om het lokale netwerk van de provider uit te voeren en wereldwijde connectiviteit te bieden.
- Azure Virtual WAN hubs die zijn geïmplementeerd in zowel De Azure-regio's Europa - west als Zuidoost-Azië om connectiviteitshubs te bieden voor ExpressRoute- en VPN-verbonden apparaten.
- Hubs bieden ook VPN-beëindiging voor zwervende gebruikers in meerdere clienttypen met behulp van OpenVPN-connectiviteit met het wereldwijde mesh-netwerk, waardoor toegang wordt geboden tot niet alleen toepassingen die naar Azure zijn gemigreerd, maar ook tot resources die on-premises blijven.
- 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. Lokaal internetonderbreking wordt ondersteund via partnerintegratie voor geoptimaliseerde toegang tot SaaS-services zoals Microsoft 365.
Migreren naar Virtual WAN
In deze sectie ziet u de verschillende stappen voor het migreren naar Azure Virtual WAN.
Stap 1: Door de klant beheerde hub-and-spoke in één regio
In de volgende afbeelding ziet u één regiotopologie voor Contoso voorafgaand aan 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 (alle algemene functies die vereist zijn 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 IP-routering van spoke-naar-spoke laag-3 mogelijk is.
- Services voor inkomend/uitgaand internet, waaronder Azure Application Gateway voor inkomende HTTPS-aanvragen en proxyservices van derden die worden uitgevoerd op virtuele machines voor gefilterde uitgaande toegang tot internetbronnen.
- ExpressRoute- en VPN-gateway voor virtuele netwerken voor connectiviteit met on-premises netwerken.
Stap 2: Virtual WAN hubs implementeren
Implementeer een 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
Notitie
Azure Virtual WAN moet de Standard-SKU gebruiken om een aantal verkeerspaden in te schakelen die in dit artikel worden weergegeven.
Afbeelding 2: Door de klant beheerde hub-and-spoke-migratie naar Virtual WAN
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 in via internet voor externe vertakkingen.
Afbeelding 3: Door de klant beheerde hub-and-spoke voor Virtual WAN migratie
Op dit moment begint de on-premises netwerkapparatuur routes te ontvangen die de IP-adresruimte weerspiegelen die is toegewezen aan het VNet van de Virtual WAN beheerde hub. Externe VPN-verbonden vertakkingen zien in deze fase twee paden naar alle 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 tijdens de overgangsfase te garanderen.
Stap 4: Hybride connectiviteit testen via Virtual WAN
Voordat u de beheerde Virtual WAN-hub gebruikt voor productieconnectiviteit, raden we u aan een virtueel spoke-netwerk te testen en Virtual WAN VNet-verbinding in te stellen. 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-and-spoke naar Virtual WAN-migratie
In deze fase is het belangrijk om te erkennen dat zowel het oorspronkelijke door de klant beheerde virtuele hubnetwerk als het nieuwe Virtual WAN Hub beide zijn verbonden met hetzelfde ExpressRoute-circuit. Hierdoor hebben we een verkeerspad dat kan worden gebruikt om spokes in beide omgevingen te laten communiceren. Verkeer van een spoke dat is gekoppeld aan het door de klant beheerde hubnetwerk, gaat bijvoorbeeld via de MSEE-apparaten die worden gebruikt voor het ExpressRoute-circuit om een spoke te bereiken die via een VNet-verbinding is verbonden met de nieuwe Virtual WAN hub. Hierdoor kan een gefaseerde migratie van spokes in stap 5 worden uitgevoerd.
Stap 5: Connectiviteit overzetten naar virtual WAN-hub
Afbeelding 5: Door de klant beheerde hub-and-spoke-migratie naar Virtual WAN
a. Verwijder de bestaande peeringverbindingen van virtuele Spoke-netwerken naar de oude door de klant beheerde hub. Toegang tot toepassingen in virtuele spoke-netwerken is niet beschikbaar totdat de stappen a-c zijn voltooid.
b. Verbind de virtuele spoke-netwerken met de Virtual WAN hub via VNet-verbindingen.
c. Verwijder alle door de gebruiker gedefinieerde routes (UDR) die eerder zijn gebruikt in virtuele spoke-netwerken voor spoke-to-spoke-communicatie. Dit pad wordt nu ingeschakeld door dynamische routering die beschikbaar is in de 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 de Virtual WAN-hub via een nieuwe VNet-verbinding.
Stap 6: Oude hub wordt shared services spoke
We hebben nu ons Azure-netwerk opnieuw ontworpen om de Virtual WAN hub het centrale punt in onze nieuwe topologie te maken.
Afbeelding 6: Door de klant beheerde hub-and-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 voor gedeelde services nu als een virtueel spoke-netwerk en worden functies zoals inkomend internetverkeer via Azure Application Gateway of gevirtualiseerd netwerkapparaat gehost. Verkeer tussen de omgeving met gedeelde services en virtuele back-endmachines wordt nu door de Virtual WAN beheerde hub geleid.
Stap 7: on-premises connectiviteit optimaliseren om volledig gebruik te maken van Virtual WAN
In deze fase heeft Contoso de migraties van zakelijke toepassingen naar de Microsoft Cloud grotendeels voltooid, met slechts enkele verouderde toepassingen die nog binnen de on-premises domeincontroller zijn.
Afbeelding 7: Door de klant beheerde hub-and-spoke-to-Virtual WAN-migratie
Om de volledige functionaliteit van Azure Virtual WAN te benutten, besluit Contoso hun verouderde on-premises VPN-verbindingen buiten gebruik te stellen. Alle filialen die toegang blijven krijgen tot HQ- of DC-netwerken, kunnen het wereldwijde Microsoft-netwerk doorvoeren met behulp van de ingebouwde transitroutering van Azure Virtual WAN.
Notitie
ExpressRoute Global Reach is vereist voor klanten die gebruik willen maken van de Microsoft-backbone om ExpressRoute naar ExpressRoute-doorvoer te bieden (niet weergegeven in afbeelding 7).
Eindstatusarchitectuur en verkeerspaden
Afbeelding: Dubbele regio Virtual WAN
Deze sectie bevat een overzicht van de wijze waarop 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 de regio Azië - zuidoost.
Het verkeer wordt als volgt gerouteerd:
Asia Branch is verbonden via tolerantE S2S BGP-tunnels in Zuidoost-Azië Virtual WAN hub.
Asia Virtual WAN hub routeert verkeer lokaal naar verbonden VNet.
Pad 2
Pad 2 toont de verkeersstroom van het met ExpressRoute verbonden Europese hoofdkantoor naar een Azure VNet in de regio Azië - zuidoost.
Het verkeer wordt als volgt gerouteerd:
Het Europese hoofdkantoor is via een ExpressRoute-circuit verbonden met West-Europa Virtual WAN hub.
Virtual WAN wereldwijde hub-naar-hub-connectiviteit maakt de overdracht van verkeer naar VNet dat is verbonden in een externe regio mogelijk.
Pad 3
Pad 3 toont de verkeersstroom van de on-premises dc in Azië die is verbonden met private WAN naar een met Europese S2S verbonden vertakking.
Het verkeer wordt als volgt gerouteerd:
Asia DC is verbonden met een lokale privé-WAN-provider.
ExpressRoute-circuit wordt lokaal beëindigd in Private WAN, maakt verbinding met de hub Azië Virtual WAN - zuidoost.
Virtual WAN wereldwijde hub-naar-hub-connectiviteit maakt doorvoer van verkeer mogelijk.
Pad 4
Pad 4 toont de verkeersstroom van een Azure-VNet in de regio Zuidoost-Azië naar een Azure-VNet in de regio Europa - west.
Het verkeer wordt als volgt gerouteerd:
- Virtual WAN wereldwijde hub-naar-hub-connectiviteit maakt systeemeigen overdracht van alle verbonden Azure VNets mogelijk zonder verdere gebruikersconfiguratie.
Pad 5
Pad 5 toont de verkeersstroom van zwervende VPN-gebruikers (P2S) naar een Azure VNet in de regio Europa - west.
Het verkeer wordt als volgt gerouteerd:
Gebruikers van laptops 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 in overeenstemming met de vereisten die eerder in dit artikel zijn besproken. Om te voldoen aan hun vereisten voor beveiligingsbeheer en netwerkisolatie, moeten ze doorgaan met het scheiden en registreren van verkeer via het hubnetwerk. Voorheen werd deze functie uitgevoerd door een virtueel netwerkapparaat (NVA). Contoso wil ook de bestaande proxyservices buiten gebruik stellen en systeemeigen Azure-services gebruiken voor uitgaande internetfilters.
Figure: Azure Firewall in Virtual WAN (beveiligde virtuele hub)
De volgende stappen op hoog niveau zijn vereist om Azure Firewall in de Virtual WAN hubs te introduceren om een uniform beleidsbeheerpunt mogelijk te maken. Zie Azure Firewall Manager voor meer informatie over dit proces en het concept van beveiligde virtuele hubs.
- Maak Azure Firewall beleid.
- Firewallbeleid koppelen aan Azure Virtual WAN hub. Met deze stap kan de bestaande Virtual WAN-hub functioneren als een beveiligde virtuele hub en worden de vereiste Azure Firewall resources geïmplementeerd.
Notitie
Er zijn beperkingen met betrekking tot het gebruik van beveiligde virtuele hubs, waaronder verkeer tussen regio's. Zie Firewall Manager - bekende problemen voor meer informatie.
De volgende paden tonen de connectiviteitspaden die zijn ingeschakeld met behulp van beveiligde virtuele hubs van Azure:
Pad 6
Pad 6 toont de beveiligde verkeersstroom tussen VNets binnen dezelfde regio.
Het verkeer wordt als volgt gerouteerd:
Virtuele netwerken die zijn verbonden met dezelfde beveiligde virtuele hub, routeren 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 het 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 centraal punt voor internettoegang.
Dit verkeer kan lokaal worden gefilterd met behulp van 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 door de Secure Hub te gebruiken als centraal punt voor internettoegang.
Dit verkeer kan lokaal worden gefilterd met behulp van Azure Firewall FQDN-regels of worden verzonden naar een externe beveiligingsservice voor inspectie.
Volgende stappen
- Meer informatie over Azure Virtual WAN.
- Virtual WAN configureren voor Azure NetApp Files