Fase di progettazione 1: Connessione ivity con siti locali

Articolo
09/30/2023

Connessione ivity con i data center locali è l'area di progettazione più critica per la rete soluzione Azure VMware. I requisiti chiave che devono essere risolti includono:

Velocità effettiva elevata: le migrazioni da ambienti vSphere locali e soluzioni di ripristino di emergenza richiedono lo spostamento rapido di grandi volumi di dati tra siti locali e soluzione Azure VMware cloud privati.
Bassa latenza: le applicazioni distribuite potrebbero richiedere una bassa latenza per le connessioni tra soluzione Azure VMware macchine virtuali e sistemi locali.
Prevedibilità delle prestazioni: per ottenere velocità effettiva e latenza prevedibili, le applicazioni business critical distribuite in soluzione Azure VMware potrebbero richiedere servizi di connettività dedicati (Azure ExpressRoute) tra i siti locali e la rete Microsoft.

Questo articolo descrive le opzioni supportate da soluzione Azure VMware per la connettività con siti locali:

Copertura globale di ExpressRoute
VPN IPSec
Transito su peering privato expressRoute

Le opzioni vengono presentate in ordine di riduzione della capacità di soddisfare i requisiti chiave elencati in precedenza. Un'opzione deve essere eliminata e quella successiva considerata, solo se è in conflitto con i vincoli non negoziabili di uno scenario specifico.

Questo diagramma di flusso riepiloga il processo per la scelta di un'opzione di connettività ibrida per soluzione Azure VMware:

Copertura globale di ExpressRoute

Copertura globale di ExpressRoute è l'opzione di connettività ibrida predefinita supportata da soluzione Azure VMware. Offre, con complessità minima, la connettività di livello 3 tra un cloud privato soluzione Azure VMware e un sito remoto connesso a un circuito ExpressRoute gestito dal cliente. È anche possibile usare il circuito ExpressRoute gestito dal cliente per connettersi ai servizi nativi di Azure. Per migliorare la sicurezza o la larghezza di banda riservata, è anche possibile distribuire un circuito gestito dal cliente separato dedicato esclusivamente al traffico soluzione Azure VMware.

Il diagramma seguente illustra una topologia di rete che usa Copertura globale per la connettività con i siti locali. Il traffico tra soluzione Azure VMware cloud privati e siti locali non attraversa le reti virtuali di Azure.

Nota

Per garantire la resilienza massima, è consigliabile usare due circuiti ExpressRoute gestiti dal cliente in posizioni di peering diverse per connettere i data center locali al backbone Microsoft. In questo caso, ogni circuito ExpressRoute gestito dal cliente deve avere una connessione Copertura globale al cloud privato soluzione Azure VMware (e alle Rete virtuale di Azure). Per indicazioni sulle implementazioni resilienti di ExpressRoute, vedere questo articolo .

Per istruzioni su come connettere un cloud privato soluzione Azure VMware a un circuito ExpressRoute gestito dal cliente tramite Copertura globale, vedere Eseguire il peering di ambienti locali a soluzione Azure VMware.

La connettività Copertura globale soddisfa completamente i tre requisiti principali:

Velocità effettiva elevata: ExpressRoute consente di connettersi alla rete Microsoft dall'ambiente locale tramite linee dedicate (fino a 10 Gbps per ExpressRoute basato su provider o 100 Gbps per ExpressRoute Direct).
Bassa latenza: Copertura globale consente di instradare il traffico direttamente dalla rete Perimetrale della rete Microsoft a soluzione Azure VMware cluster vSphere. Copertura globale riduce al minimo il numero di hop di rete tra siti locali e cloud privati.
Prestazioni prevedibili: quando si usa Copertura globale di ExpressRoute, il traffico viene instradato su collegamenti che non riscontrano problemi di congestione (fino alla capacità massima di cui è stato effettuato il provisioning). Di conseguenza, il tempo di round trip (RTT) tra le macchine virtuali in esecuzione in soluzione Azure VMware e gli host locali rimane costante nel tempo.

Non è possibile usare Copertura globale negli scenari in cui si applicano uno o più dei vincoli seguenti:

Copertura globale di ExpressRoute non è disponibile nell'area di Azure del cloud privato soluzione Azure VMware o nella posizione meet-me del circuito ExpressRoute gestito dal cliente. Non esistono soluzioni alternative per questa limitazione. Vedere Informazioni su Copertura globale di ExpressRoute per informazioni aggiornate sulla disponibilità di Copertura globale.
Esistono requisiti di sicurezza di rete non negoziabili. Se non è possibile distribuire un dispositivo firewall sul lato locale del circuito ExpressRoute gestito dal cliente, l'uso di Copertura globale espone tutti i segmenti di rete soluzione Azure VMware, incluse le reti di gestione (gestione del server vCenter e NSX-T), all'intera rete connessa al circuito. Lo scenario più tipico in cui questo problema si verifica è quando i circuiti ExpressRoute gestiti dal cliente vengono implementati sui servizi di rete MPLS (noto anche come modello di connettività any-to-any di ExpressRoute). Questo scenario è illustrato di seguito:

Quando la connettività ExpressRoute viene implementata su IPVPN MPLS, è impossibile distribuire i firewall in un'unica posizione per controllare tutto il traffico da e verso soluzione Azure VMware. In genere, le organizzazioni che usano reti MPLS distribuiscono firewall in data center di grandi dimensioni, non in tutti i siti (che possono essere piccole succursali, uffici o negozi).

VPN IPSec

È possibile implementare la connettività tra soluzione Azure VMware cloud privati e siti locali instradando il traffico attraverso una rete virtuale di transito in Azure. La rete di transito è connessa al cloud privato soluzione Azure VMware tramite il circuito ExpressRoute gestito. La rete virtuale di transito è connessa al sito locale tramite una VPN IPSec, come illustrato di seguito:

È possibile applicare criteri di sicurezza per le connessioni tra siti locali e il cloud privato soluzione Azure VMware (la linea tratteggiata nel diagramma) instradando il traffico attraverso un firewall, se il dispositivo VPN non fornisce funzionalità del firewall. Questa configurazione richiede azure rete WAN virtuale con finalità di routing, come descritto nella sezione Decidere dove ospitare i dispositivi virtuali in Azure di questo articolo.

Prima di implementare la connettività IPSec tra siti locali e reti virtuali di transito, è necessario prendere tre decisioni di progettazione:

Determinare il servizio di rete da usare come sottofondo per il tunnel IPSec. Le opzioni disponibili sono la connettività Internet, il peering Microsoft ExpressRoute e il peering privato expressRoute.
Determinare dove ospitare i dispositivi virtuali che terminano il tunnel IPSec sul lato Azure. Le opzioni disponibili includono reti virtuali gestite dal cliente e hub rete WAN virtuale.
Determinare il dispositivo virtuale che termina il tunnel IPSec sul lato Azure. La scelta del dispositivo determina anche la configurazione di Azure necessaria per il routing del traffico tra il tunnel IPSec e il circuito gestito soluzione Azure VMware. Le opzioni disponibili sono native di Azure Gateway VPN e appliance virtuali di rete IPSec di terze parti.

Questo diagramma di flusso riepiloga il processo decisionale:

I criteri per prendere queste decisioni sono descritti nelle sezioni seguenti.

Scegliere un servizio di rete sottostante

È consigliabile prendere in considerazione le tre opzioni per la sottoscrizione VPN nell'ordine presentato qui:

Connessione Internet. L'indirizzo IP pubblico assegnato al dispositivo VPN ospitato nella rete virtuale di transito funge da endpoint remoto del tunnel IPSec. A causa della bassa complessità e dei costi, è consigliabile testare e valutare sempre la connettività Internet per ottenere prestazioni (velocità effettiva IPSec ottenibile). È consigliabile ignorare questa opzione solo quando le prestazioni osservate sono troppo basse o incoerenti. Il diagramma seguente illustra questa opzione.
Peering Microsoft di ExpressRoute. Questa opzione fornisce la connettività di livello 3 agli endpoint pubblici di Azure tramite collegamenti dedicati. Come le connessioni Internet, consente di raggiungere l'indirizzo IP pubblico di un dispositivo VPN che funge da endpoint remoto del tunnel IPSec ed è ospitato nella rete virtuale di transito. È consigliabile ignorare questa opzione solo quando non è possibile soddisfare i requisiti di routing del peering Microsoft. Il diagramma seguente illustra questa opzione.
Peering privato di ExpressRoute. Questa opzione offre connettività di livello 3 tra un sito locale e reti virtuali di Azure tramite collegamenti dedicati. Consente quindi di stabilire un tunnel IPSec dal sito locale all'indirizzo IP privato di un dispositivo VPN ospitato in una rete virtuale. Il peering privato di ExpressRoute potrebbe introdurre limitazioni della larghezza di banda perché il gateway ExpressRoute si trova nel percorso dati. È possibile usare ExpressRoute FastPath per risolvere questo problema. Il peering privato richiede anche una configurazione di routing più complessa sul lato locale. Per altre informazioni, vedere Configurare una connessione VPN da sito a sito tramite peering privato ExpressRoute. Il diagramma seguente illustra questa opzione.

Decidere dove ospitare i dispositivi virtuali in Azure

Le opzioni disponibili includono reti virtuali gestite dal cliente e hub rete WAN virtuale. Per prendere questa decisione, prendere in considerazione le caratteristiche dell'ambiente Di Azure preesistente, se presente, e come assegnare priorità alla riduzione delle attività di gestione rispetto alla possibilità di personalizzare la configurazione in base a esigenze specifiche. Di seguito sono riportate alcune considerazioni chiave.

È consigliabile usare l'infrastruttura di rete di Azure preesistente per la connettività soluzione Azure VMware. Se esiste già una rete hub-spoke gestita dal cliente nella stessa area del cloud privato soluzione Azure VMware, è necessario distribuire i dispositivi di terminazione IPSec nell'hub esistente. Se una rete hub-spoke basata su rete WAN virtuale esiste nella stessa area del cloud privato soluzione Azure VMware, è consigliabile usare l'hub rete WAN virtuale per la terminazione IPSec.
In una rete hub-spoke gestita dal cliente, per instradare il traffico tra un tunnel IPSec e il circuito gestito expressRoute, è necessario distribuire un'istanza del server di route di Azure nella rete virtuale hub e configurarla per consentire il traffico da ramo a ramo. Non è possibile instradare il traffico tra soluzione Azure VMware cloud privati e siti locali tramite dispositivi firewall distribuiti nella rete virtuale.
rete WAN virtuale hub supportano in modo nativo il routing del traffico tra il tunnel IPSec connesso al sito locale e il circuito ExpressRoute gestito soluzione Azure VMware.
Se si usa rete WAN virtuale, è possibile configurare le finalità di routing e i criteri di routing per l'ispezione del traffico. È possibile usare Firewall di Azure o soluzioni di sicurezza di terze parti supportate da rete WAN virtuale. È consigliabile esaminare la disponibilità a livello di area e le limitazioni della finalità di routing.

Decidere quale dispositivo virtuale termina il tunnel IPSec

Il tunnel IPSec che fornisce la connettività al sito locale può essere terminato da Azure Gateway VPN o da appliance virtuali di rete di terze parti. Per prendere questa decisione, prendere in considerazione le caratteristiche dell'ambiente Di Azure preesistente, se presente, e come assegnare priorità alla riduzione delle attività di gestione rispetto alla possibilità di personalizzare la configurazione in base a esigenze specifiche. Di seguito sono riportate alcune considerazioni chiave.

In entrambe le reti hub-spoke gestite dal cliente e in reti hub-spoke basate su rete WAN virtuale, è possibile usare Azure Gateway VPN per terminare i tunnel IPSec connessi ai siti locali. Poiché sono gestiti dalla piattaforma, i gateway VPN di Azure richiedono un lavoro di gestione minimo. È possibile usare gateway preesistenti anche se supportano altri scenari di connettività. Per informazioni sulle impostazioni supportate e sulle prestazioni previste, vedere questi articoli:
Le appliance virtuali di rete di terze parti vengono in genere usate per terminare i tunnel dai siti locali nelle situazioni seguenti:
- L'appliance virtuale di rete è l'attrezzatura CPE (customer premises equipment) di una soluzione SDWAN distribuita sia in Azure che nel sito locale.
- L'appliance virtuale di rete è un firewall che applica i criteri di sicurezza necessari per le connessioni tra il sito locale e soluzione Azure VMware.

L'uso di dispositivi di terze parti potrebbe offrire maggiore flessibilità e accesso alle funzioni di rete avanzate non supportate dai gateway VPN nativi, ma aumenta la complessità. La disponibilità elevata diventa responsabilità dell'utente. È consigliabile distribuire più istanze.

Transito su peering privato expressRoute

Il peering privato di ExpressRoute è la scelta più comune per la connessione di un sito locale a una rete virtuale di Azure (o rete hub-spoke) in scenari aziendali. La rete virtuale di Azure o la rete virtuale hub nelle topologie hub-spoke contiene un gateway ExpressRoute configurato con una connessione al circuito ExpressRoute. Questa configurazione fornisce la connettività di livello 3 tra la rete virtuale (o l'intera rete hub-spoke) e la rete del sito locale. Tuttavia, non fornisce in modo nativo la connettività di livello 3 a soluzione Azure VMware cloud privati connessi alla stessa rete virtuale (o rete virtuale hub) tramite un circuito ExpressRoute gestito. (Vedere Copertura globale di ExpressRoute e soluzione Azure VMware cloud privati.

È possibile ovviare a questa limitazione distribuendo più dispositivi di routing nella rete virtuale di Azure. In questo modo è possibile instradare il traffico attraverso appliance virtuali di rete del firewall ospitate nella rete virtuale.

Il transito su peering privato expressRoute potrebbe sembrare auspicabile, ma aggiunge complessità e influisce sulle prestazioni. È consigliabile prenderlo in considerazione solo quando la copertura globale di ExpressRoute e le VPN IPSec (descritte nelle sezioni precedenti) non sono applicabili.

Esistono due opzioni di implementazione:

Rete virtuale singola. Quando si usa questa opzione, i circuiti gestiti dal cliente e soluzione Azure VMware gestiti vengono connessi allo stesso gateway ExpressRoute.
Rete virtuale di transito ausiliaria. Quando si usa questa opzione, il circuito ExpressRoute gestito dal cliente che fornisce connettività al sito locale è connesso al gateway ExpressRoute (in genere preesistente) nella rete virtuale hub. Il circuito gestito soluzione Azure VMware è connesso a un gateway ExpressRoute diverso distribuito in una rete virtuale di transito ausiliaria.

Le sezioni seguenti forniscono informazioni dettagliate sulle due opzioni di implementazione, tra cui:

Compromessi tra prestazioni, costi (risorse di Azure necessarie) e overhead di gestione.
Implementazione del piano di controllo (modalità di scambio delle route tra il sito locale e il cloud privato).
Implementazione del piano dati (modalità di instradamento dei pacchetti di rete tra il sito locale e il cloud privato).

Rete virtuale singola

Quando si usa l'approccio alla rete virtuale singola, sia il circuito gestito del cloud privato soluzione Azure VMware che il circuito di proprietà del cliente sono connessi allo stesso gateway ExpressRoute, in genere la rete hub. Il traffico tra il cloud privato e il sito locale può essere instradato tramite appliance virtuali di rete del firewall distribuite nella rete hub. L'architettura di rete virtuale singola è illustrata di seguito:

Il piano di controllo e il piano dati vengono implementati come descritto di seguito:

Piano di controllo. Un gateway ExpressRoute distribuito nella rete virtuale di Azure non può propagare le route tra il circuito gestito soluzione Azure VMware e il circuito ExpressRoute gestito dal cliente. Il server di route di Azure, con l'impostazione da ramo a ramo abilitata, viene usato per inserire, in entrambi i circuiti, route per le supernet che includono lo spazio indirizzi del cloud privato soluzione Azure VMware (reti di gestione e segmenti di carico di lavoro) e lo spazio indirizzi locale.

Le supernet, anziché i prefissi esatti che comprendono tali spazi indirizzi, devono essere annunciati perché i prefissi esatti sono già annunciati nella direzione opposta dal cloud privato soluzione Azure VMware e dal sito locale. È possibile usare supernet di grandi dimensioni come i prefissi RFC 1918 se sono compatibili con la configurazione di rete dei siti locali. Nella maggior parte dei casi, è consigliabile usare invece le supernet più piccole che includono lo spazio indirizzi del cloud privato soluzione Azure VMware e lo spazio indirizzi locale. In questo modo si riducono al minimo i rischi di conflitti con la configurazione di routing dei siti locali.

Le route per le supernet sono originati da appliance virtuali di rete con supporto BGP. Le appliance virtuali di rete sono configurate per stabilire una sessione BPG con il server di route di Azure. Le appliance virtuali di rete fanno solo parte del piano di controllo e non instradano il traffico effettivo tra il sito locale e il cloud privato soluzione Azure VMware. L'implementazione del piano di controllo è rappresentata dalle linee tratteggiate nella figura precedente.
Piano dati. L'implementazione del piano di controllo descritta in precedenza attira il traffico seguente verso il gateway ExpressRoute:
- Traffico dal sito locale destinato al cloud privato soluzione Azure VMware.
- Traffico dal cloud privato soluzione Azure VMware destinato al sito locale.
Se non vengono applicate route definite dall'utente a GatewaySubnet, il traffico passa direttamente tra il sito locale e il cloud privato soluzione Azure VMware. È possibile instradare il traffico a un hop successivo intermedio applicando le route definite dall'utente a GatewaySubnet. Le appliance virtuali di rete firewall che applicano criteri di sicurezza di rete alle connessioni tra siti locali e cloud privati sono un esempio tipico. L'implementazione del piano dati è rappresentata dalla linea continua nella figura precedente.

Rete virtuale ausiliaria

È possibile usare una rete virtuale ausiliaria per ospitare un secondo gateway ExpressRoute connesso solo al circuito gestito del cloud privato soluzione Azure VMware. Se si usa questo approccio, il circuito gestito del cloud privato e il circuito gestito dal cliente si connettono a gateway ExpressRoute diversi. Due istanze del server di route di Azure vengono usate per annunciare le route appropriate a ogni circuito e per controllare la propagazione delle route tra il cloud privato e il sito locale. Non è necessario annunciare le supernet, come si fa per l'opzione di rete virtuale singola descritta nella sezione precedente. Anche il sovraccarico di gestione per le route definite dall'utente in GatewaySubnet è ridotto. Questo approccio consente di instradare il traffico tra il cloud privato e il sito locale tramite appliance virtuali di rete del firewall nella rete virtuale hub. L'implementazione della rete virtuale ausiliaria è illustrata nel diagramma seguente:

Il piano di controllo e il piano dati vengono implementati come descritto di seguito:

Piano di controllo. Per abilitare la propagazione delle route tra il circuito gestito del cloud privato soluzione Azure VMware e il circuito di proprietà del cliente, è necessaria un'istanza del server di route di Azure in ogni rete virtuale. Poiché le due istanze del server di route di Azure non possono stabilire un'adiacenza BGP, sono necessarie appliance virtuali di rete con supporto BGP per propagare le route tra di esse. Per la disponibilità elevata, è necessario distribuire almeno due istanze dell'appliance virtuale di rete. È possibile aggiungere altre istanze per aumentare la velocità effettiva. Le appliance virtuali di rete che supportano BGP devono avere due schede di interfaccia di rete collegate a subnet diverse. Le sessioni BGP verso i due server di route (nella rete virtuale ausiliaria e nella rete virtuale hub) devono essere stabilite su schede di interfaccia di rete diverse.

Le route originate dal cloud privato soluzione Azure VMware e dal sito locale vengono apprese sui circuiti ExpressRoute. I percorsi AS contengono ASN 65515 (un ASN riservato di Azure usato dai gateway ExpressRoute) e ASN 12076 (un ASN di proprietà di Microsoft usato dai router perimetrali Microsoft Enterprise in tutte le posizioni di peering). Le appliance virtuali di rete con supporto BGP devono rimuovere i percorsi AS per impedire che le route vengano eliminate dal rilevamento del ciclo BGP. Per altre informazioni sulla configurazione BGP necessaria, vedere Implementare la connettività Expressroute per AVS senza Copertura globale. L'implementazione del piano di controllo è rappresentata dalle linee tratteggiate nel diagramma precedente.
Piano dati. Nella rete virtuale ausiliaria il traffico tra il cloud privato soluzione Azure VMware e il sito locale viene instradato attraverso le appliance virtuali di rete con supporto BGP. Il traffico da e verso il cloud privato soluzione Azure VMware esce o passa alle appliance virtuali di rete tramite la scheda di interfaccia di rete usata per la sessione BGP con il server di route della rete virtuale ausiliaria. Il traffico da e verso il sito locale esce o passa alle appliance virtuali di rete tramite la scheda di interfaccia di rete usata per la sessione BGP con il server di route della rete virtuale hub. Questa scheda di interfaccia di rete è collegata a una subnet associata a una tabella di route personalizzata che:
- Disabilita le route BGP di apprendimento dal server di route (per evitare cicli).
- Inserisce il firewall della rete hub nel percorso dati.
Per assicurarsi che il traffico venga instradato simmetricamente tramite il firewall dell'hub, le route definite dall'utente per tutti i prefissi usati nel cloud privato soluzione Azure VMware devono essere configurate nella gatewaySubnet dell'hub. Per altre informazioni, vedere Implementare la connettività Expressroute per AVS senza Copertura globale. L'implementazione del piano dati è rappresentata dalla linea continua nel diagramma precedente.

Passaggi successivi

Informazioni sulla connettività tra soluzione Azure VMware e reti virtuali di Azure.

Connessione ivity tra soluzione Azure VMware e reti virtuali di Azure

Share via