Eseguire la migrazione alla rete WAN virtuale di Azure
Azure rete WAN virtuale consente alle aziende di semplificare la connettività globale per trarre vantaggio dalla scalabilità della rete globale Microsoft. Questo articolo fornisce informazioni tecniche per le aziende che vogliono eseguire la migrazione da una topologia hub-spoke gestita dal cliente esistente, a una progettazione che sfrutta hub di rete WAN virtuale gestiti da Microsoft.
Per informazioni sui vantaggi offerti da Azure rete WAN virtuale per le aziende che adottano una rete globale globale globale basata sul cloud, vedere Architettura della rete di transito globale e rete WAN virtuale.
Figura: Azure rete WAN virtuale
Il modello di connettività hub-spoke di Azure è stato adottato da migliaia di clienti per sfruttare il comportamento di routing transitivo predefinito della rete di Azure per creare reti cloud semplici e scalabili. Azure rete WAN virtuale si basa su questi concetti e introduce nuove funzionalità che consentono topologie di connettività globale, non solo tra posizioni locali e Azure, ma anche consentire ai clienti di sfruttare la scalabilità della rete Microsoft per aumentare le reti globali esistenti.
Questo articolo illustra come eseguire la migrazione di un ambiente hub-spoke gestito dal cliente esistente a una topologia basata su Azure rete WAN virtuale.
Scenario
Contoso è un'organizzazione finanziaria globale con uffici sia in Europa che in Asia. Si prevede di spostare le applicazioni esistenti da un data center locale in Azure e di creare una progettazione di base basata sull'architettura hub-spoke gestita dal cliente, incluse le reti virtuali hub regionali per la connettività ibrida. Nell'ambito del passaggio alle tecnologie basate sul cloud, il team di rete ha avuto il compito di garantire che la connettività sia ottimizzata per l'azienda in futuro.
La figura seguente mostra una panoramica generale della rete globale esistente, inclusa la connettività a più aree di Azure.
Figura: Topologia di rete esistente di Contoso
La topologia di rete esistente presenta le caratteristiche seguenti:
Una topologia hub-spoke viene usata in più aree, inclusi i circuiti ExpressRoute per la connettività a una rete WAN (Wide Area Network) privata comune.
Alcuni di questi siti hanno anche tunnel VPN direttamente in Azure per raggiungere le applicazioni ospitate all'interno del cloud.
Requisiti
Il team di rete ha avuto il compito di fornire un modello di rete globale in grado di supportare la migrazione di Contoso al cloud e deve ottimizzare le aree di costo, scalabilità e prestazioni. In breve, devono essere soddisfatti i requisiti seguenti:
- Fornire nelle sedi centrali e nelle filiali un percorso ottimizzato verso le applicazioni ospitate nel cloud.
- Rimuovere la dipendenza dai data center locali esistenti per la terminazione VPN mantenendo i percorsi di connettività seguenti:
- Da succursale a rete virtuale: gli uffici connessi vpn devono essere in grado di accedere alle applicazioni di cui è stata eseguita la migrazione al cloud nell'area di Azure locale.
- Da ramo a hub a rete virtuale: gli uffici connessi vpn devono essere in grado di accedere alle applicazioni di cui è stata eseguita la migrazione al cloud nell'area di Azure remota.
- Da succursale a succursale: gli uffici connessi vpn a livello di area devono essere in grado di comunicare tra loro e i siti HQ/DC connessi con ExpressRoute.
- Da ramo a hub a ramo: gli uffici connessi vpn separati a livello globale devono essere in grado di comunicare tra loro e con qualsiasi sito HQ/DC connesso a ExpressRoute.
- Da ramo a Internet: i siti connessi devono essere in grado di comunicare con Internet. Questo traffico deve essere filtrato e registrato.
- Da rete virtuale a rete virtuale: le reti virtuali spoke nella stessa area devono essere in grado di comunicare tra loro.
- Da rete virtuale a rete virtuale da hub a rete virtuale: le reti virtuali spoke nelle diverse aree devono essere in grado di comunicare tra loro.
- Offrire la possibilità agli utenti mobili di Contoso (portatile e telefono) di accedere alle risorse aziendali, anche se non nella rete aziendale.
Architettura della rete WAN virtuale di Azure
La figura seguente illustra una panoramica generale della topologia di destinazione aggiornata usando Azure rete WAN virtuale per soddisfare i requisiti descritti nella sezione precedente.
Figura: Architettura di Azure rete WAN virtuale
Riepilogo:
- La sede centrale in Europa rimane connessa a ExpressRoute, i controller di dominio locali in Europa vengono completamente trasferiti in Azure e quindi rimossi.
- I controller di dominio e la sede centrale in Asia rimangono connessi alla rete WAN privata. Azure rete WAN virtuale ora usato per aumentare la rete del gestore telefonico locale e fornire connettività globale.
- Hub di Azure rete WAN virtuale distribuiti nelle aree di Azure Europa occidentale e Asia sud-orientale per fornire l'hub di connettività per i dispositivi connessi a ExpressRoute e VPN.
- Gli hub forniscono anche la terminazione VPN per gli utenti in roaming tra più tipi di client tramite connettività OpenVPN alla rete a mesh globale, consentendo l'accesso non solo alle applicazioni trasferite in Azure ma anche alle risorse rimaste nell'ambiente locale.
- Connettività Internet per le risorse interne a una rete virtuale fornita dalla rete WAN virtuale di Azure.
Anche la connettività Internet per i siti remoti è fornita dalla rete WAN virtuale di Azure. Interruzione Internet locale supportata tramite l'integrazione dei partner per l'accesso ottimizzato ai servizi SaaS, ad esempio Microsoft 365.
Eseguire la migrazione alla rete WAN virtuale
Questa sezione illustra i vari passaggi per la migrazione ad Azure rete WAN virtuale.
Passaggio 1: Singola area gestita dal cliente hub-spoke
La figura seguente illustra una topologia a singola area per Contoso prima dell'implementazione di Azure rete WAN virtuale:
Figura 1: Hub-spoke manuale a singola area
In linea con l'approccio hub-spoke, la rete virtuale dell'hub gestito dal cliente contiene diversi blocchi di funzioni:
- Servizi condivisi (qualsiasi funzione comune richiesta da più spoke). Esempio: Contoso usa i controller di dominio Windows Server nelle macchine virtuali IaaS (Infrastructure-as-a-Service).
- I servizi firewall di routing/IP sono forniti da un'appliance virtuale di rete di terze parti, abilitando il routing IP di livello 3 spoke-spoke.
- Servizi in ingresso/uscita Internet, tra cui il gateway applicazione di Azure per le richieste HTTPS in ingresso e servizi proxy di terze parti in esecuzione in macchine virtuali per l'accesso in uscita filtrato alle risorse Internet.
- Gateway di rete virtuale ExpressRoute e VPN per la connettività alle reti locali.
Passaggio 2: Distribuire hub rete WAN virtuale
Distribuire un hub rete WAN virtuale in ogni area. Configurare l'hub rete WAN virtuale con la funzionalità VPN ed ExpressRoute, come descritto negli articoli seguenti:
- Esercitazione: Creare una connessione da sito a sito con la rete WAN virtuale di Azure
- Esercitazione: Creare un'associazione ExpressRoute usando Azure rete WAN virtuale
Nota
Azure rete WAN virtuale deve usare lo SKU Standard per abilitare alcuni dei percorsi di traffico illustrati in questo articolo.
Figura 2: Migrazione da hub e spoke gestiti dal cliente a rete WAN virtuale
Passaggio 3: Connettere siti remoti (ExpressRoute e VPN) a rete WAN virtuale
Connettere l'hub rete WAN virtuale ai circuiti ExpressRoute esistenti e configurare VPN da sito a sito tramite Internet a qualsiasi ramo remoto.
Figura 3: Migrazione da hub e spoke gestiti dal cliente a rete WAN virtuale
A questo punto, le apparecchiature di rete locali inizieranno a ricevere route che riflettono lo spazio di indirizzi IP assegnato alla rete virtuale dell'hub gestito da rete WAN virtuale. In questa fase le filiali remote connesse alla VPN vedranno due percorsi alle applicazioni esistenti nelle reti virtuali spoke. Questi dispositivi devono essere configurati per continuare a usare il tunnel per l'hub gestito dal cliente per garantire il routing simmetrico durante la fase di transizione.
Passaggio 4: Testare la connettività ibrida tramite rete WAN virtuale
Prima di usare l'hub di rete WAN virtuale gestito per la connettività di produzione, è consigliabile configurare una rete virtuale spoke di test e rete WAN virtuale connessione di rete virtuale. Verificare che le connessioni a questo ambiente di test funzionino tramite ExpressRoute e VPN da sito a sito prima di continuare con i passaggi successivi.
Figura 4: Migrazione da hub e spoke gestiti dal cliente a rete WAN virtuale
In questa fase, è importante riconoscere che sia la rete virtuale dell'hub gestito dal cliente originale che la nuova rete WAN virtuale Hub sono entrambi connessi allo stesso circuito ExpressRoute. Per questo motivo, è disponibile un percorso di traffico che può essere usato per consentire agli spoke in entrambi gli ambienti di comunicare. Ad esempio, il traffico proveniente da uno spoke collegato alla rete virtuale dell'hub gestito dal cliente attraversa i dispositivi MSEE usati per il circuito ExpressRoute per raggiungere qualsiasi spoke connesso tramite una connessione di rete virtuale al nuovo hub rete WAN virtuale. In questo modo è possibile eseguire una migrazione a fasi di spoke nel passaggio 5.
Passaggio 5: Eseguire la transizione della connettività all'hub della rete WAN virtuale
Figura 5: Migrazione da hub e spoke gestiti dal cliente a rete WAN virtuale
a. Eliminare le connessioni di peering esistenti dalle reti virtuali Spoke all'hub gestito dal cliente precedente. L'accesso alle applicazioni nelle reti virtuali spoke non è disponibile finché non vengono completati i passaggi a-c.
b. Connettere le reti virtuali spoke all'hub rete WAN virtuale tramite connessioni di rete virtuale.
c. Rimuovere le route definite dall'utente usate in precedenza nelle reti virtuali spoke per le comunicazioni spoke-spoke. Questo percorso è ora abilitato dal routing dinamico disponibile nell'hub della rete WAN virtuale.
d. ExpressRoute e Gateway VPN esistenti nell'hub gestito dal cliente vengono ora rimossi per consentire il passaggio successivo (e).
e. Connettere l'hub gestito dal cliente precedente (rete virtuale hub) all'hub rete WAN virtuale tramite una nuova connessione di rete virtuale.
Passaggio 6: l'hub precedente diventa spoke di servizi condivisi
La rete di Azure è ora stata riprogettata in modo da configurare l'hub della rete WAN virtuale come punto centrale nella nuova topologia.
Figura 6: Migrazione da hub e spoke gestito dal cliente a rete WAN virtuale
Poiché l'hub rete WAN virtuale è un'entità gestita e non consente la distribuzione di risorse personalizzate, ad esempio le macchine virtuali, il blocco di servizi condivisi ora esiste come rete virtuale spoke e funzioni host come l'ingresso Internet tramite gateway di app Azure lication o appliance virtualizzata di rete. Il traffico tra l'ambiente di servizi condivisi e le macchine virtuali back-end ora transita attraverso l'hub gestito dalla rete WAN virtuale.
Passaggio 7: Ottimizzare la connettività locale per usare completamente rete WAN virtuale
In questa fase, Contoso ha quasi completato la migrazione delle applicazioni aziendali al cloud Microsoft, con solo alcune applicazioni legacy rimanenti all'interno del controller di dominio locale.
Figura 7: Migrazione da hub e spoke gestiti dal cliente a rete WAN virtuale
Per sfruttare tutte le funzionalità della rete WAN virtuale di Azure, Contoso decide di rimuovere le connessioni VPN locali legacy. Le filiali che continuano ad accedere alle reti di sedi centrali o data center possono transitare nella rete globale Microsoft tramite il routing di transito predefinito della rete WAN virtuale di Azure.
Nota
Copertura globale di ExpressRoute è necessaria per i clienti che vogliono sfruttare il backbone Microsoft per fornire ExpressRoute al transito ExpressRoute (non illustrato nella figura 7).
Architettura dello stato finale e percorsi di traffico
Figura: Doppia area rete WAN virtuale
Questa sezione include alcuni flussi di traffico di esempio per dimostrare come questa topologia soddisfa i requisiti originali.
Percorso 1
Il percorso 1 mostra il flusso del traffico da un ramo connesso VPN da sito a sito in Asia a una rete virtuale di Azure nell'area Asia sud-orientale.
Il traffico viene instradato come segue:
Il ramo Asia è connesso tramite tunnel BGP S2S resilienti abilitati per l'asia sud-orientale rete WAN virtuale hub.
L'hub della rete WAN virtuale in Asia instrada il traffico in locale alla rete virtuale connessa.
Percorso 2
Il percorso 2 mostra il flusso del traffico dall'HQ europeo connesso expressRoute a una rete virtuale di Azure nell'area Asia sud-orientale.
Il traffico viene instradato come segue:
La sede centrale europea è connessa tramite il circuito ExpressRoute nell'hub rete WAN virtuale Europa occidentale.
La connettività globale da hub a hub della rete WAN virtuale garantisce il transito del traffico verso la rete virtuale connessa nell'area remota.
Percorso 3
Il percorso 3 mostra il flusso del traffico dal controller di dominio locale asiatico connesso alla rete WAN privata a un ramo connesso A2S europeo.
Il traffico viene instradato come segue:
Il controller di dominio in Asia è connesso all'operatore della rete WAN privata locale.
Il circuito ExpressRoute termina localmente nella rete WAN privata si connette all'hub rete WAN virtuale Asia sud-orientale.
rete WAN virtuale connettività globale da hub a hub consente il transito del traffico.
Percorso 4
Il percorso 4 mostra il flusso del traffico da una rete virtuale di Azure nell'area Asia sud-orientale a una rete virtuale di Azure nell'area Europa occidentale.
Il traffico viene instradato come segue:
- La connettività globale da hub a hub della rete WAN virtuale consente il transito nativo di tutte le reti virtuali di Azure connesse senza ulteriori configurazioni dell'utente.
Percorso 5
Il percorso 5 mostra il flusso del traffico dagli utenti VPN mobili (P2S) a una rete virtuale di Azure nell'area Europa occidentale.
Il traffico viene instradato come segue:
Gli utenti di computer portatili e dispositivi mobili usano il client OpenVPN per la connettività trasparente nel gateway VPN da punto a sito in Europa occidentale.
L'hub della rete WAN virtuale in Europa occidentale instrada il traffico in locale alla rete virtuale connessa.
Controllo di sicurezza e criteri tramite Firewall di Azure
Contoso ha ora convalidato la connettività tra tutti i rami e le reti virtuali in linea con i requisiti descritti in precedenza in questo articolo. Per soddisfare i requisiti per il controllo di sicurezza e l'isolamento della rete, è necessario continuare a separare e registrare il traffico tramite la rete hub. In precedenza questa funzione veniva eseguita da un'appliance virtuale di rete. Contoso vuole anche rimuovere le autorizzazioni dei servizi proxy esistenti e usare i servizi nativi di Azure per il filtro Internet in uscita.
Figura: Firewall di Azure in rete WAN virtuale (hub virtuale protetto)
I passaggi generali seguenti sono necessari per introdurre Firewall di Azure negli hub rete WAN virtuale per abilitare un punto unificato di controllo dei criteri. Per altre informazioni su questo processo e sul concetto di Hub virtuali sicuri, vedere Firewall di Azure Manager.
- Creare i criteri di Firewall di Azure.
- Collegare i criteri firewall all'hub della rete WAN virtuale di Azure. Questo passaggio consente all'hub di rete WAN virtuale esistente di funzionare come hub virtuale protetto e distribuisce le risorse Firewall di Azure necessarie.
Nota
Esistono vincoli relativi all'uso di hub virtuali protetti, incluso il traffico tra aree. Per altre informazioni, vedere Gestione firewall - Problemi noti.
I percorsi seguenti mostrano i percorsi di connettività abilitati usando hub virtuali protetti di Azure:
Percorso 6
Il percorso 6 mostra il flusso di traffico sicuro tra reti virtuali all'interno della stessa area.
Il traffico viene instradato come segue:
Le reti virtuali connesse allo stesso hub virtuale protetto ora instradano il traffico tramite Firewall di Azure.
Firewall di Azure può applicare i criteri a questi flussi.
Percorso 7
Il percorso 7 mostra il flusso del traffico da una rete virtuale di Azure a Internet o da un servizio di sicurezza di terze parti.
Il traffico viene instradato come segue:
Le reti virtuali connesse all'hub virtuale protetto possono inviare il traffico a destinazioni pubbliche su Internet, usando l'hub protetto come punto centrale di accesso a Internet.
Questo traffico può essere filtrato in locale usando Firewall di Azure regole FQDN o inviate a un servizio di sicurezza di terze parti per l'ispezione.
Percorso 8
Il percorso 8 mostra il flusso del traffico da ramo a Internet o da un servizio di sicurezza di terze parti.
Il traffico viene instradato come segue:
I rami connessi all'hub virtuale protetto possono inviare traffico a destinazioni pubbliche su Internet usando l'hub protetto come punto centrale di accesso a Internet.
Questo traffico può essere filtrato in locale usando Firewall di Azure regole FQDN o inviate a un servizio di sicurezza di terze parti per l'ispezione.
Passaggi successivi
- Altre informazioni su Azure rete WAN virtuale.
- Configurare la rete WAN virtuale per Azure NetApp Files