topologia di rete rete WAN virtuale di Azure

Questo articolo illustra come progettare una rete con rete WAN virtuale di Azure. rete WAN virtuale offre un'infrastruttura hub gestita da Microsoft con routing automatico, integrazione nativa SD-WAN e transito globale predefinito tra hub.

Informazioni su questo articolo

Questo articolo illustra l'architettura dell'hub di rete WAN virtuale, il routing automatico e la propagazione delle rotte, il confronto tra i livelli Basic e Standard, il routing basato su intenti per l'ispezione del traffico, i modelli di integrazione SD-WAN e il modello di costo di rete WAN virtuale.

Chi ha bisogno di questo articolo

Leggere questo articolo se si applicano una o più di queste condizioni:

  • È necessario il transito gestito tra molti rami, siti, utenti remoti o reti virtuali connesse.
  • Vuoi il routing e la connettività delle filiali gestiti da Microsoft invece di creare e gestire autonomamente un hub di transito personalizzato.
  • È necessario confrontare rete WAN virtuale di Azure con il modello hub-and-spoke prima di scegliere una topologia.
  • Si prevede che la rete cresca oltre un numero ridotto di archi di connettività gestiti manualmente.

Tip

Si segue un percorso di scenario? Selezionare lo scenario nella parte superiore della pagina per indicazioni personalizzate. Le linee guida di base seguenti si applicano a tutti i lettori.

Focus su lift-and-shift: tralasciare questo articolo per una migrazione lift-and-shift standard. La maggior parte degli ambienti lift-and-shift ha meno di 30 connessioni di ramo e opera in una o due aree. Una topologia hub-spoke tradizionale con Gateway VPN offre connettività sufficiente. Prendi in considerazione rete WAN virtuale solo se hai molte sedi secondarie o prevedi una rapida espansione.

Focus sulla modernizzazione: Questo articolo diventa rilevante quando il programma di modernizzazione include requisiti di transito su larga scala o in più regioni. L'architettura dual hub-and-spoke con i gateway VPN in ogni area geografica gestisce la maggior parte degli scenari di modernizzazione. rete WAN virtuale diventa pertinente quando si supera il livello di complessità del routing che la gestione manuale delle route definite dall’utente (UDR) è in grado di sostenere.

Focus sul multi-cloud: la rete WAN virtuale è il modello di transito consigliato quando si dispone di più cloud privati virtuali (VPC), rami, aree o perimetri del cloud. rete WAN virtuale funge da equivalente di Azure a AWS Transit Gateway, fornendo una gestione centralizzata del routing e della connettività su larga scala. Se esegui la migrazione da un ambiente AWS che usa Transit Gateway, rete WAN virtuale si allinea direttamente a questo modello.

Azure servizi e funzionalità

La tabella seguente elenca i servizi e le funzionalità Azure che supportano una topologia rete WAN virtuale:

Servizio o funzionalità Ruolo in rete WAN virtuale Ulteriori informazioni
Rete WAN virtuale di Azure Fornisce la rete di transito globale gestita e l'infrastruttura hub Panoramica di rete WAN virtuale
Hub virtuale Una rete virtuale gestita da Microsoft che ospita servizi di routing e gateway Routing dell'hub virtuale
Gateway VPN (nell'hub) Connettività VPN da sito a sito e da punto a sito per le succursali rete WAN virtuale Gateway VPN
ExpressRoute Gateway (nell'hub) Connettività privata dai data center locali tramite circuiti ExpressRoute rete WAN virtuale ExpressRoute
Gestione firewall di Azure Gestione centralizzata dei criteri di sicurezza per Hub virtuali protetti Panoramica di Gestione firewall
Finalità di routing Gestione automatica del traffico attraverso una soluzione di sicurezza senza tabelle di route personalizzate Intento di routing

Come funziona

Diagramma che mostra una topologia rete WAN virtuale con due hub regionali, reti virtuali spoke, siti di succursali connessi tramite VPN e circuiti ExpressRoute. Il routing tra hub scorre il backbone Microsoft.

In una topologia di rete WAN virtuale:

  1. Una risorsa rete WAN virtuale funge da contenitore di primo livello che raggruppa uno o più hub virtuali tra aree.
  2. Ogni hub virtuale è una rete virtuale gestita da Microsoft. L'hub contiene endpoint di servizio per i servizi VPN, ExpressRoute e firewall. Non si distribuisce o si gestisce direttamente la rete virtuale hub.
  3. Le reti virtuali spoke si connettono a un hub virtuale tramite connessioni VNet (in modo analogo al peering nel modello hub-spoke tradizionale). Il router dell'hub virtuale gestisce automaticamente tutto il routing.
  4. I siti di succursale si connettono tramite vpn da sito a sito o gateway ExpressRoute distribuiti all'interno dell'hub virtuale.
  5. Quando si distribuiscono più hub, si interconnettono automaticamente sul backbone Microsoft, che consente il transito globale senza il routing gestito dal cliente.

Informazioni sul routing dell'hub virtuale

Il router dell'hub virtuale gestisce tutto il routing tra reti virtuali connesse, rami e altri hub. Comportamenti principali:

  • Transito automatico: Le reti virtuali connesse allo stesso hub possono comunicare senza UDR. Il router hub propaga le route tra tutte le connessioni per impostazione predefinita.
  • Transito tra hub: Le route si propagano automaticamente tra hub nella stessa rete WAN virtuale. Il traffico tra le regioni passa attraverso il backbone di Microsoft.
  • Tabelle di route: Per scenari di isolamento avanzati ,ad esempio isolando lo sviluppo dall'ambiente di produzione, è possibile creare tabelle di route personalizzate all'interno dell'hub per controllare la propagazione delle route.
  • Velocità effettiva aggregata: Il router dell'hub virtuale supporta fino a 50 Gbps di velocità effettiva aggregata se configurata con il massimo di 50 unità di infrastruttura di routing. La distribuzione predefinita usa 2 unità di infrastruttura di routing (3 Gbps). È possibile aumentare la velocità effettiva aumentando le unità dell'infrastruttura di routing nelle impostazioni dell'hub.

Note

Il routing automatico si applica alla connettività di transito standard. Gli scenari personalizzati che instradano il traffico attraverso appliance virtuali di rete (NVA) nell'hub potrebbero richiedere tabelle di routing personalizzate.

Come scegliere

Questa sezione illustra come selezionare la topologia e il livello corretti per l'ambiente.

Confronto tra hub-spoke e rete WAN virtuale

Usare questa tabella per determinare se una topologia hub-spoke tradizionale o rete WAN virtuale è la scelta giusta per l'ambiente:

Fattore Hub-and-spoke (tradizionale) Rete WAN virtuale di Azure
Gestione Rete virtuale dell'hub gestito dal cliente infrastruttura dell'hub gestito Microsoft
Migliore per Fino a circa 30 connessioni di ramo VPN Più di 30 rami VPN o più aree Azure
Routing Il cliente configura le UDR per il traffico spoke-to-spoke Routing automatico nell'hub virtuale
integrazione diSD-WAN Distribuzione e configurazione manuale dell'appliance virtuale di rete Integrazione nativa dei partner SD-WAN
Transito globale Richiede il routing tra più regioni gestito dal cliente Integrato: tutti gli hub si interconnettono automaticamente
Modello di costo Risorse della rete virtuale hub pagate separatamente (Firewall, Gateway, Bastion) Prezzi delle unità di distribuzione e delle unità di scalabilità

Tip

rete WAN virtuale è un'alternativa su larga scala a hub-spoke, non un sostituto. Le organizzazioni con meno di 30 rami, una singola area e una necessità di controllo completo sulle risorse hub devono usare una topologia hub-spoke tradizionale.

Considerazioni sulla migrazione: Se si passa da un hub-spoke tradizionale a rete WAN virtuale, pianificare una migrazione in esecuzione parallela. Distribuire un hub rete WAN virtuale insieme all'hub esistente, eseguire la migrazione incrementale delle connessioni spoke e convalidare il routing dopo ogni migrazione della connessione. rete WAN virtuale non supporta l'importazione di configurazioni UDR esistenti, quindi è necessario riprogettare il routing per usare il modello di propagazione automatica del router hub.

Quando rimanere con hub-spoke: Scegliere hub-spoke tradizionale se è necessario un controllo granulare sulla rete virtuale hub (ad esempio, la distribuzione di appliance virtuali di rete personalizzate direttamente nella subnet hub), se l'organizzazione opera in un'unica area con meno di 10 rami o se i requisiti di conformità impongono l'infrastruttura di routing gestita dal cliente.

Standard rispetto al livello Basic

rete WAN virtuale offre due livelli. Scegliere il livello più adatto alle esigenze di routing e connettività:

Feature Basic Standard
VPN da sito a sito ✅ ✅
VPN da punto a sito ❌ ✅
ExpressRoute ❌ ✅
Transito da VNet a VNet ❌ ✅
Transito tra hub ❌ ✅
Firewall di Azure nell'hub ❌ ✅
Appliance virtuale di rete nell'hub ❌ ✅

Importante

È possibile eseguire l'aggiornamento dal livello Basic al livello Standard, ma non è possibile effettuare il downgrade da Standard a Basic. Scegliere Standard se è necessario un routing di transito, una connettività ExpressRoute o un'integrazione della sicurezza.

Modello di costi

rete WAN virtuale usa prezzi basati su unità che differiscono dal tradizionale hub-spoke:

  • Unità di distribuzione (hub): Si paga una tariffa oraria per l'hub virtuale stesso. Questa tariffa è un costo fisso per l'infrastruttura dell'hub gestito.
  • Unità di scala (gateway): I gateway VPN e ExpressRoute vengono fatturati in base al numero di unità di scala di cui si effettua il provisioning. Più unità di scala aumentano la capacità della larghezza di banda e i costi proporzionalmente.
  • Unità di infrastruttura di routing: Il router hub viene fatturato per ogni unità di infrastruttura di routing. La distribuzione predefinita include due unità (3 Gbps). È possibile aumentare fino a 50 unità (50 Gbps) per ambienti con velocità effettiva elevata.
  • Elaborazione dei dati: Si paga per i dati elaborati tramite l'hub, incluso il traffico da VNet a VNet, da filiale a VNet e tra gli hub. Il traffico associato a Internet instradato attraverso Firewall di Azure prevede costi di elaborazione dati separati.
  • Componente aggiuntivo per hub virtuale protetto: Quando si distribuisce Firewall di Azure tramite Firewall Manager, gli addebiti standard di Firewall di Azure si applicano anche ai costi dell'hub di rete WAN virtuale.

Confrontare i costi con una topologia hub-spoke tradizionale. Per le distribuzioni di piccole dimensioni con rami minimi, un hub gestito dal cliente potrebbe risultare più conveniente. Per un numero elevato di filiali (30+), l'automazione e l'infrastruttura gestita di rete WAN virtuale compensano in genere il costo per unità. Per informazioni dettagliate sui prezzi, vedi concetti relativi ai prezzi di rete WAN virtuale.

Hub virtuale protetto: quando usare Gestione firewall

Un Hub virtuale protetto integra Firewall di Azure (o un'appliance virtuale di rete supportata) con Gestione firewall per la gestione centralizzata dei criteri:

Configurazione Usa quando Benefit
Hub virtuale standard (nessun firewall) Connettività solo tra branch e rete virtuale, sicurezza gestita a livello di spoke Distribuzione più semplice, costo più basso
Hub virtuale protetto con Firewall Manager Ispezione centralizzata del traffico per il traffico privato e Internet Criteri coerenti, l'intento di routing rimuove la necessità di route definite dall'utente
Hub virtuale protetto con partner NVA Investimenti di firewall di terze parti esistenti, requisiti di funzionalità specifici Usare gli strumenti e le competenze dei fornitori esistenti

Finalità di routing

L'intento di routing semplifica la gestione del traffico in rete WAN virtuale instradando automaticamente il traffico attraverso una soluzione di sicurezza (Firewall di Azure o un'NVA (appliance virtuale di rete) supportata) senza tabelle di routing personalizzate o UDR.

Quando si abilita la finalità di routing, si dichiarano criteri per due tipi di traffico:

  • Traffico Internet: Tutto il traffico associato a Internet dalle reti virtuali connesse instrada attraverso la soluzione di sicurezza nell'hub.
  • Traffico privato: Tutto il traffico tra reti virtuali, filiali e altri hub passa attraverso la soluzione di sicurezza.

La finalità di routing rimuove la necessità di gestire manualmente le tabelle di route. Il piano di controllo rete WAN virtuale configura automaticamente tutte le route necessarie in tutti gli hub connessi e le reti virtuali spoke.

Note

L'intento di routing richiede un Hub virtuale protetto con Firewall di Azure o un partner NVA supportato. È disponibile solo nel livello Standard.

Avvertimento

Le modifiche apportate alla tabella di route dall'intento di routing sono irreversibili. È possibile rimuovere la finalità di routing, ma la rimozione non ripristina automaticamente la configurazione predefinita di DefaultRouteTable precedente. Salva un'istantanea della configurazione prima di abilitare il routing intent, perché dovrai ripristinare manualmente le route precedentemente configurate se in seguito lo rimuovi.

Limiti di connessione e scalabilità

rete WAN virtuale supporta distribuzioni su larga scala:

  • Fino a 1.000 connessioni VPN da sito a sito per hub virtuale.
  • Più hub per rete WAN virtuale (uno per area o più per area per isolamento).
  • Fino a 50 Gbps di throughput aggregato per router hub (richiede al massimo 50 unità dell'infrastruttura di routing. Il valore predefinito è di 2 unità a 3 Gbps).
  • Connettività da qualsiasi rete a qualsiasi altra tra tutte le connessioni di macchina virtuale, le sedi VPN e i circuiti ExpressRoute all'interno dello stesso hub.

Per le organizzazioni che superano i limiti di un singolo hub, distribuire hub aggiuntivi nelle stesse aree o diverse. Il rete WAN virtuale gestisce automaticamente il routing tra hub.

integrazione dei partner SD-WAN

rete WAN virtuale offre l'integrazione nativa con i dispositivi partner SD-WAN. I dispositivi partner possono:

  • Esportare in Azure, tramite codice, le informazioni sui dispositivi della filiale.
  • Scaricare automaticamente la configurazione Azure.
  • Stabilire la connettività IPsec/IKE all'hub virtuale senza configurazione manuale.

Questa automazione riduce i tempi di distribuzione dei rami da giorni a minuti su larga scala. Per l'elenco corrente dei partner supportati, vedere rete WAN virtuale partner.

Come funziona l'automazione dei partner

SD-WAN partner usano l'API di automazione della connettività rete WAN virtuale per gestire a livello di codice i cicli di vita dei dispositivi branch:

  • Registrazione del dispositivo: Il controller partner registra i dispositivi di succursale con la risorsa rete WAN virtuale, inclusi i metadati del dispositivo e i requisiti di larghezza di banda.
  • Download della configurazione: La piattaforma partner esegue il pull della configurazione del gateway hub (indirizzi IP, chiavi precondi condivise, impostazioni BGP) senza l'interazione manuale del portale.
  • Stabilimento tunnel: Il dispositivo partner stabilisce tunnel IPsec al gateway VPN dell'hub virtuale usando la configurazione scaricata.
  • Monitoraggio continuo dello stato: La piattaforma partner monitora lo stato dei tunnel e può ristabilire la connessione se i tunnel si interrompono.

I partner come VMware SD-WAN, Fortinet SD-WAN, Cisco Viptela e Versa Networks supportano questo modello di automazione. Ogni partner implementa il proprio livello di orchestrazione sopra l'API rete WAN virtuale. Valutare le funzionalità specifiche del partner, ad esempio il routing compatibile con le applicazioni, l'ottimizzazione del traffico e l'interruzione Internet locale prima di selezionare un partner.

Considerazioni relative alla progettazione

Per la maggior parte delle migrazioni di tipo lift-and-shift, rete WAN virtuale non è la topologia di partenza. Valutare quando diventa giustificato:

  • Quando rete WAN virtuale diventa giustificato. Se il tuo ambiente lift-and-shift include più di 30 sedi periferiche, si estende su tre o più regioni di Azure o richiede l'integrazione con SD-WAN, il routing automatizzato di rete WAN virtuale riduce il sovraccarico operativo rispetto alla gestione delle UDR (route definite dall'utente) tra numerosi peering hub-and-spoke.
  • Hub-spoke è sufficiente per i patrimoni più piccoli. Un singolo hub con Gateway VPN gestisce fino a 30 connessioni da sito a sito e 500 peering spoke. Se la migrazione rimane entro questi limiti, il tradizionale modello hub-spoke è più semplice e più conveniente.
  • Il percorso di migrazione esiste. Se si inizia con hub-spoke e in seguito è necessario rete WAN virtuale, è possibile eseguire la migrazione di un hub rete WAN virtuale insieme all'hub esistente e spostare le connessioni spoke in modo incrementale.

Le distribuzioni con più aree non richiedono automaticamente rete WAN virtuale. Valuta la complessità del routing:

  • Il doppio hub-spoke è spesso sufficiente. Per le architetture attive-attive in due aree geografiche, distribuire un hub in ogni area geografica con peering macchine virtuali tra gli hub. Questo modello gestisce la maggior parte degli scenari di modernizzazione senza sovraccarico dei prezzi per unità di rete WAN virtuale.
  • Quando la complessità si spinge verso rete WAN virtuale. Se la modernizzazione si estende oltre due aree geografiche, aggiunge la connettività delle filiali tra aree geografiche o richiede la propagazione automatica delle route tra hub senza dover gestire manualmente le route definite dall'utente (UDR), rete WAN virtuale semplifica le operazioni.
  • Non confondere la multiregione con rete WAN virtuale. La decisione di usare rete WAN virtuale dipende dal numero di rami, dal numero di area e dalla complessità del routing. La distribuzione su più regioni da sola non costituisce una giustificazione sufficiente.

rete WAN virtuale fornisce l'equivalente Azure di AWS Transit Gateway per il transito centralizzato e scalabile:

  • Equivalenza di Transit Gateway L'hub virtuale di rete WAN virtuale funziona come AWS Transit Gateway: instrada automaticamente il traffico tra reti virtuali connesse, filiali e tunnel VPN tra cloud diversi. Se si esegue la migrazione da AWS, questo mapping semplifica la traduzione dell'architettura.
  • Hub virtuale protetto (hub virtuale protetto). Distribuire Firewall di Azure tramite Gestione firewall nell'hub virtuale. Abilitare la finalità di routing per indirizzare tutto il traffico privato e Internet attraverso il firewall. Fornisce un'ispezione centralizzata del traffico intercloud in ingresso in Azure.
  • Connessioni VPN a Google Cloud e AWS. Crea connessioni VPN site-to-site dall'hub rete WAN virtuale verso Google Cloud VPN (HA VPN) e AWS Virtual Private Gateways. rete WAN virtuale supporta fino a 1.000 connessioni VPN per hub, offrendo spazio per la crescita man mano che si esegue la migrazione di più carichi di lavoro.
  • Pianificazione di più aree. Distribuire hub virtuali in ogni area Azure in cui vengono distribuite le applicazioni migrate. Il routing tra hub si propaga automaticamente attraverso il backbone Microsoft, rispecchiando il modello di peering del Transit Gateway in AWS.

Prerequisiti

Prima di implementare una topologia rete WAN virtuale:

  • Informazioni sui concetti hub-spoke. rete WAN virtuale si basa sul modello hub-spoke. Consulta la topologia hub-and-spoke per i concetti di base.
  • Inventario dei siti di succursali. Documentare il numero di rami, la distribuzione geografica e la connettività corrente (VPN, MPLS, SD-WAN).
  • Definire la strategia dell'area. Determinare quali aree Azure ospitano i carichi di lavoro e dove sono necessari hub virtuali.
  • Scegliere il livello. Scegliere tra Basic (solo VPN da sito a sito) e Standard (transito completo, ExpressRoute, firewall) in base alla tabella di confronto dei livelli in questo articolo.
  • Valutare i requisiti di sicurezza. Determinare se l'ispezione centralizzata (hub virtuale protetto) o la sicurezza per spoke è appropriata.

Considerazioni relative alla sicurezza

  • Hub virtuale protetto. Distribuire Firewall di Azure tramite Gestione firewall per applicare criteri di sicurezza coerenti in tutte le reti virtuali e i rami connessi. Gestione firewall offre una gestione centralizzata delle regole tra più hub protetti.
  • Intento di routing. Abilitare la finalità di routing per gestire automaticamente il traffico privato e Internet tramite la soluzione di sicurezza. Questo approccio impedisce al traffico di ignorare l'ispezione eliminando la configurazione manuale del routing.
  • Limitazioni di NVA in hub. Le appliance virtuali di rete distribuite nell'hub hanno funzionalità diverse rispetto a Firewall di Azure. Verifica che le funzionalità siano in linea con i tuoi requisiti di sicurezza prima di scegliere un partner NVA.
  • SD-WAN modello di sicurezza. Integrando SD-WAN dispositivi partner, la sicurezza del traffico dipende dall'implementazione del partner. Valutare le funzionalità di crittografia, autenticazione e ispezione del traffico del partner.
  • Isolamento del traffico tra hub. Il traffico tra hub virtuali passa attraverso il backbone Microsoft e non attraversa la rete Internet pubblica. Il backbone è una rete privata, ma il traffico non viene crittografato a livello di rete per impostazione predefinita. Usare TLS a livello di applicazione per i dati sensibili tra aree.

Ulteriori informazioni

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Connettività ibrida: connettere i carichi di lavoro migrati di nuovo all'ambiente locale tramite Gateway VPN o ExpressRoute.

Nel prossimo percorso di modernizzazione:

Pianificare la distribuzione multi-area: estendere la progettazione tra aree per la resilienza attiva-attiva.

Il prossimo passo nel tuo percorso multicloud:

Progetta le VNets della tua landing zone di Azure: crea le fondamenta della rete virtuale di Azure per i carichi di lavoro connessi e migrati.

  • Last updated on