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 details voor bedrijven die willen migreren van een bestaande door de klant beheerde hub-en-spoke-topologie naar een ontwerp dat gebruikmaakt van door Microsoft beheerde Virtual WAN-hubs.
Zie Global Transit Network Architecture en Virtual WAN voor informatie over de voordelen die Azure Virtual WAN biedt voor ondernemingen die een cloudgericht modern wereldwijd bedrijfsnetwerk gebruiken.
Afbeelding: Azure Virtual WAN
Het Azure Hub-and-Spoke-connectiviteitsmodel is door duizenden klanten gebruikt om gebruik te maken van het standaarddoorgangsgedrag 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 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 zowel Europa als Azië. Ze zijn van plan om hun bestaande toepassingen te verplaatsen van een on-premises datacenter naar Azure en hebben een basisontwerp ontwikkeld op basis van de door de klant beheerde hub-and-spoke-architectuur, waaronder 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 is 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 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 worden gehost in de cloud.
Vereisten
Het netwerkteam is belast met het leveren van een globaal netwerkmodel dat ondersteuning kan bieden voor de Contoso-migratie naar de cloud en moet optimaliseren op het gebied van kosten, schaal en prestaties. Kortom, aan de volgende vereisten moet 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 terwijl u de volgende connectiviteitspaden behoudt:
- Vertakking naar VNet: verbonden VPN-kantoren moeten toegang hebben tot toepassingen die zijn gemigreerd naar de cloud in de lokale Azure-regio.
- Branch-to-Hub naar Hub-naar-VNet: verbonden VPN-kantoren moeten toegang hebben tot toepassingen die zijn gemigreerd naar de cloud in de externe Azure-regio.
- Vertakking naar vertakking: regionale VPN-verbonden kantoren moeten met elkaar kunnen communiceren en verbonden HQ/DC-sites van ExpressRoute.
- Vertakking naar hub naar hub-naar-vertakking: wereldwijd gescheiden VPN-verbonden kantoren moeten met elkaar kunnen communiceren en alle met 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.
- Bieden de mogelijkheid voor Contoso-roaminggebruikers (laptop en telefoon) om toegang te krijgen tot bedrijfsbronnen, terwijl ze zich niet in 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.
Afbeelding: Azure Virtual WAN-architectuur
Summary:
- HQ in Europa blijft Verbonden met ExpressRoute, europa on-premises DC wordt volledig gemigreerd naar Azure en nu buiten gebruik gesteld.
- Asia DC en HQ blijven verbonden met Private WAN. Azure Virtual WAN wordt nu gebruikt om het lokale netwerk van de provider te verbeteren en wereldwijde connectiviteit te bieden.
- Azure Virtual WAN-hubs die zijn geïmplementeerd in zowel Europa - west als Azië - zuid-oost 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 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 dat 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 migratie naar Azure Virtual WAN.
Stap 1: Door de klant beheerde hub en spoke in één regio
In de volgende afbeelding ziet u een topologie van één regio voor Contoso vóór de implementatie van Azure Virtual WAN:
Afbeelding 1: Handmatige hub-en-spoke voor één regio
In overeenstemming met de hub-and-spoke-benadering bevat het virtuele netwerk van de door de klant beheerde hub verschillende functieblokken:
- Gedeelde services (een algemene functie die vereist is voor meerdere spokes). Voorbeeld: Contoso maakt gebruik van 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-laag-3 IP-routering mogelijk is.
- Internetingress-/uitgaande services, waaronder Azure-toepassing Gateway voor binnenkomende 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 gebruikmaken van de Standard-SKU om een deel van de verkeerspaden in te schakelen die in dit artikel worden weergegeven.
Afbeelding 2: Door de klant beheerde hub-and-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-and-spoke-naar Virtual WAN-migratie
Op dit moment begint on-premises netwerkapparatuur routes te ontvangen die de IP-adresruimte weerspiegelen die is toegewezen aan het VNet van de door Virtual WAN beheerde hub. 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 te blijven gebruiken voor de door de klant beheerde hub 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 testnetwerk en een 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-migratie naar Virtual WAN
In deze fase is het belangrijk te herkennen 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 dat is gekoppeld aan het virtuele hubnetwerk dat door de klant wordt beheerd, doorkruist bijvoorbeeld de MSEE-apparaten die voor het ExpressRoute-circuit worden gebruikt om een spoke te bereiken die is verbonden via een VNet-verbinding met de nieuwe Virtual WAN-hub. Hierdoor kan een gefaseerde migratie van spokes in stap 5 worden uitgevoerd.
Stap 5: Connectiviteit met virtual WAN-hub overstappen
Afbeelding 5: Door de klant beheerde hub-and-spoke-naar Virtual WAN-migratie
a. Verwijder de bestaande peeringverbindingen van virtuele Spoke-netwerken met 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 in virtuele spoke-netwerken zijn gebruikt voor spoke-to-spoke-communicatie. Dit pad is 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 gedeelde services spoke
We hebben ons Azure-netwerk nu 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-migratie naar Virtual WAN
Omdat de Virtual WAN-hub een beheerde entiteit is en de implementatie van aangepaste resources zoals virtuele machines niet toestaat, bestaat het blok gedeelde services nu als een virtueel spoke-netwerk en hostfuncties zoals inkomend internet via Azure-toepassing Gateway of gevirtualiseerd netwerkapparaat. Verkeer tussen de omgeving met gedeelde services en virtuele back-endmachines gaat nu door naar de door Virtual WAN beheerde hub.
Stap 7: On-premises connectiviteit optimaliseren om volledig gebruik te maken van Virtual WAN
In deze fase heeft Contoso hun migraties van zakelijke toepassingen in de Microsoft Cloud voornamelijk voltooid, met slechts enkele verouderde toepassingen die binnen de on-premises DC blijven.
Afbeelding 7: Door de klant beheerde hub-and-spoke-migratie naar Virtual WAN
Om gebruik te maken van de volledige functionaliteit van Azure Virtual WAN, besluit Contoso om hun verouderde on-premises VPN-verbindingen buiten gebruik te stellen. Alle vertakkingen die toegang hebben tot HQ- of DC-netwerken, kunnen het wereldwijde Microsoft-netwerk doorsturen met behulp van de ingebouwde routering van Azure Virtual WAN.
Notitie
ExpressRoute Global Reach is vereist voor klanten die de Microsoft-backbone willen gebruiken om ExpressRoute naar ExpressRoute-transit te bieden (niet weergegeven afbeelding 7.).
End-state architectuur en verkeerspaden
Afbeelding: Dual Region Virtual WAN
Deze sectie bevat een overzicht van hoe deze topologie voldoet aan de oorspronkelijke vereisten door een aantal 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:
Azië-vertakking is verbonden via tolerante S2S BGP-tunnels naar de hub South East Asia Virtual WAN.
Asia Virtual WAN-hub routeert verkeer lokaal naar verbonden VNet.
Pad 2
Pad 2 toont de verkeersstroom van de ExpressRoute verbonden Europese HQ naar een Azure-VNet in de regio Azië - zuidoost.
Het verkeer wordt als volgt gerouteerd:
De Europese HQ is via ExpressRoute-circuit verbonden met de Virtual WAN-hub van West-Europa.
Globale connectiviteit van virtual WAN-hub naar hub maakt het doorvoeren van verkeer naar VNet mogelijk dat is verbonden in een externe regio.
Pad 3
Pad 3 toont de verkeersstroom van de on-premises DC van 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 de lokale Private WAN-provider.
Het ExpressRoute-circuit wordt lokaal beëindigd in Private WAN en maakt verbinding met de Virtual WAN-hub zuidoost azië.
Wereldwijde connectiviteit van Virtual WAN-hub naar hub maakt het doorvoeren van verkeer mogelijk.
Pad 4
Pad 4 toont de verkeersstroom van een Azure-VNet in de regio Azië - zuidoost naar een Azure-VNet in de regio Europa - west.
Het verkeer wordt als volgt gerouteerd:
- Globale connectiviteit van Virtual WAN-hub naar hub 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:
Laptop- en mobiele apparaatgebruikers gebruiken de OpenVPN-client voor transparante connectiviteit met de P2S VPN-gateway in Europa - west.
Virtual WAN-hub west europa routeert verkeer lokaal naar verbonden VNet.
Beveiliging 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 verkeer blijven scheiden en vastleggen via het hubnetwerk. 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 internetfiltering.
Afbeelding: Azure Firewall in Virtual WAN (beveiligde virtuele hub)
De volgende stappen op hoog niveau zijn vereist om Azure Firewall te introduceren in de Virtual WAN-hubs om een geïntegreerd beleidspunt in te schakelen. Zie Azure Firewall Manager voor meer informatie over dit proces en het concept van Beveiligde virtuele hubs.
- Azure Firewall-beleid maken.
- Koppel firewallbeleid 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.
In de volgende paden ziet u 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, routeren nu verkeer via de Azure Firewall.
Azure Firewall kan beleid toepassen op deze stromen.
Pad 7
Pad 7 toont de verkeersstroom van een Azure-VNet naar internet of 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 Secure Hub als centraal toegangspunt.
Dit verkeer kan lokaal worden gefilterd met behulp van Azure Firewall-FQDN-regels of worden verzonden naar een beveiligingsservice van derden voor inspectie.
Pad 8
Pad 8 toont de verkeersstroom van branch-to-internet of security service 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 Secure Hub als centraal toegangspunt.
Dit verkeer kan lokaal worden gefilterd met behulp van Azure Firewall-FQDN-regels of worden verzonden naar een beveiligingsservice van derden voor inspectie.
Volgende stappen
- Meer informatie over Azure Virtual WAN.
- Virtual WAN configureren voor Azure NetApp Files