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 dettagli tecnici per le aziende che vogliono eseguire la migrazione da una topologia hub e spoke gestita dal cliente esistente, a una progettazione che sfrutta hub gestiti da Microsoft rete WAN virtuale.

Per informazioni sui vantaggi offerti da Azure rete WAN virtuale per le aziende che adottano una rete globale moderna incentrata sul cloud, vedere Architettura di rete di transito globale e rete WAN virtuale.

figura : Rete WAN virtuale di Azure

Il modello di connettività hub-spoke di Azure è stato adottato da migliaia di clienti per sfruttare il comportamento di routing transitivo predefinito di 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à globali, 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 e spoke gestito dal cliente esistente a una topologia basata su Rete WAN virtuale di Azure.

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 gestito dal cliente e spoke, incluse le reti virtuali dell'hub a livello di area per la connettività ibrida. Nell'ambito del passaggio alle tecnologie basate sul cloud, il team di rete è stato sottoposto a attività per garantire che la connettività sia ottimizzata per l'avanzamento aziendale.

La figura seguente mostra una visualizzazione generale della rete globale esistente, inclusa la connettività a più aree di Azure.

Figura della : topologia di rete esistente 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 dispongono anche di tunnel VPN direttamente in Azure per raggiungere le applicazioni ospitate nel cloud.

Requisiti

Il team di rete è stato sottoposto a attività per distribuire un modello di rete globale che può supportare la migrazione di Contoso al cloud e deve ottimizzare nelle aree dei costi, della scalabilità e delle 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:
  • Branch-to-VNet: le sedi connesse vpn devono essere in grado di accedere alle applicazioni migrate nel cloud nell'area di Azure locale.
  • Branch-to-Hub to Hub to-VNet: le sedi connesse vpn devono essere in grado di accedere alle applicazioni migrate nel cloud nell'area di Azure remota.
  • Branch-to-branch: gli uffici connessi a VPN a livello di area devono essere in grado di comunicare tra loro e i siti HQ/DC connessi a ExpressRoute.
  • Branch-to-Hub to Hub-to-branch: gli uffici connessi a VPN delimitati a livello globale devono essere in grado di comunicare tra loro e qualsiasi sito HQ/DC connesso a ExpressRoute.
  • Branch-to-Internet: i siti connessi devono essere in grado di comunicare con Internet. Questo traffico deve essere filtrato e registrato.
  • Reti virtuali da rete virtuale a rete virtuale: le reti virtuali spoke nella stessa area devono essere in grado di comunicare tra loro.
  • Reti virtuali da rete virtuale a hub a rete virtuale: le reti virtuali spoke nelle diverse aree devono essere in grado di comunicare tra loro.
• Fornire la possibilità agli utenti mobili contoso (portatile e telefono) di accedere alle risorse aziendali mentre non nella rete aziendale.

Architettura della rete WAN virtuale di Azure

La figura seguente mostra una visualizzazione generale della topologia di destinazione aggiornata usando Azure rete WAN virtuale per soddisfare i requisiti dettagliati 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 vettore locale e fornire connettività globale.
• Hub di Azure rete WAN virtuale distribuiti sia nelle aree Europa occidentale che in 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: Area singola gestita dall'hub e spoke gestito dal cliente

La figura seguente mostra una singola topologia di area per Contoso prima dell'implementazione di Azure rete WAN virtuale:

Figura 1 della singola: hub e spoke manuale di un'area singola

In base all'approccio hub-and-spoke, la rete virtuale dell'hub gestito dal cliente contiene diversi blocchi di funzione:

• Servizi condivisi (qualsiasi funzione comune richiesta da più spoke). Esempio: Contoso usa 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 funzionalità VPN e 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 con la rete WAN virtuale di Azure

figura 2: Hub gestito dal cliente e spoke in rete WAN virtuale migrazione

Passaggio 3: Connettere i 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 su Internet a qualsiasi ramo remoto.

Figure 3: Hub gestito dal cliente e spoke alla migrazione rete WAN virtuale

A questo punto, le apparecchiature di rete locali inizieranno a ricevere route che riflettono lo spazio degli indirizzi IP assegnato alla rete virtuale dell'hub gestito 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 alla 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.

Figure 4: Hub gestito dal cliente e spoke per rete WAN virtuale migrazione

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. A causa di questo, è disponibile un percorso di traffico che può essere usato per abilitare i spoke in entrambi gli ambienti per comunicare. Ad esempio, il traffico da un 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 rete virtuale al nuovo hub rete WAN virtuale. In questo modo è possibile eseguire una migrazione in fasi degli spoke nel passaggio 5.

Passaggio 5: Transizione della connettività all'hub WAN virtuale

figura 5: Hub gestito dal cliente e spoke in rete WAN virtuale migrazione

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 le connessioni reti virtuali.

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. I gateway ExpressRoute e VPN esistenti nell'hub gestito dal cliente sono 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 rete virtuale.

Passaggio 6: l'hub precedente diventa spoke dei 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: Hub gestito dal cliente e spoke per rete WAN virtuale migrazione

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 esiste ora come rete virtuale spoke e funzioni host, ad esempio internet in ingresso tramite gateway applicazione di Azure 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 l'utilizzo completo di 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.

Figure 7: Hub gestito dal cliente e spoke per rete WAN virtuale migrazione

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.

Architettura dello stato finale e percorsi del traffico

Architettura 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 BGP S2S resilienti nell'hub rete WAN virtuale asia sud-orientale.

• 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'europa occidentale rete WAN virtuale hub.

• 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.

Figure: Firewall di Azure in rete WAN virtuale (hub virtuale protetto)

I passaggi generali seguenti sono necessari per introdurre Firewall di Azure negli hub di rete WAN virtuale per abilitare un punto di controllo dei criteri unificato. Per altre informazioni su questo processo e sul concetto di Hub virtuali sicuri, vedere Firewall di Azure Manager.

1. Creare i criteri di Firewall di Azure.
2. 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.

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 a 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 sicuro possono inviare traffico a destinazioni pubbliche su Internet usando l'hub sicuro 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 rete WAN virtuale per Azure NetApp Files