Connettere una rete locale a Azure

Questo articolo confronta le tre opzioni principali per la connessione di una rete locale a una rete virtuale Azure: Gateway VPN di Azure, Azure ExpressRoute e soluzioni IPsec o SD-WAN non Microsoft ospitate in Azure. Per ogni opzione, riepiloga il modello di connettività, quando l'opzione è appropriata, i vantaggi principali e i compromessi e collegamenti a un'architettura di riferimento dettagliata.

Questo articolo è rivolto ad architetti di rete e cloud che valutano la connettività da sito a sito tra una rete aziendale o un data center e una o più reti virtuali Azure. La documentazione separata illustra la connettività VPN da punto a sito e da rete virtuale a rete virtuale, che qui non sono trattate.

connettività VPN Azure

Un Azure VPN gateway è un tipo di gateway di rete virtuale che invia traffico crittografato tra una rete virtuale Azure e una posizione locale, in genere tramite Internet pubblico.

Questa architettura è adatta alle applicazioni ibride in cui il traffico tra l'ambiente locale e Azure è ridotto o la latenza più elevata è accettabile in cambio di flessibilità e scalabilità cloud.

Diagramma che mostra la connettività ibrida con un gateway VPN.

Azure VPN viene usata più comunemente per la connettività VPN da sito a sito (S2S), che fornisce connettività crittografata e instradata tra una rete locale e Azure reti virtuali tramite tunnel IPsec/IKE. Azure VPN supporta anche scenari point-to-site (P2S) e VNet-to-VNet, ma questi scenari riguardano rispettivamente l'accesso remoto degli utenti e la connettività tra VNet, e non sono l'obiettivo principale qui.

Vantaggi

Le funzionalità seguenti rendono Azure VPN ideale per gli scenari ibridi che non richiedono connettività dedicata.

  • Configurazione più semplice. L'installazione è più semplice rispetto alle opzioni di connettività dedicate, ad esempio ExpressRoute, perché la connessione passa attraverso la rete Internet pubblica e non richiede un provider di connettività o un flusso di lavoro di provisioning del circuito.
  • Crittografato durante il transito. Le connessioni da sito a sito usano tunnel IPsec/IKE, quindi il traffico tra il dispositivo VPN locale e il gateway VPN Azure viene crittografato a livello di rete per impostazione predefinita.
  • Larghezza di banda aggregata elevata. Gateway VPN supporta una larghezza di banda complessiva fino a 10 Gbps nelle topologie hub-and-spoke standard. Con rete WAN virtuale di Azure, ogni hub virtuale supporta fino a 20 Gbps aggregati. Sia la velocità effettiva aggregata che la ridondanza della zona dipendono dallo SKU Gateway VPN scelto, quindi dimensionare lo SKU per la velocità effettiva e la resilienza necessarie. (Vedere Affidabilità.) Per informazioni dettagliate, vedere topologia e progettazione di Gateway VPN e domande frequenti rete WAN virtuale.

Challenges

Prendere in considerazione i vincoli seguenti prima di scegliere Azure VPN per un carico di lavoro ibrido.

  • È necessario un dispositivo VPN locale. Si gestisce e si esegue la manutenzione di un dispositivo VPN locale compatibile, che si trova all'esterno del limite gestito da Azure.
  • Il contratto di servizio copre solo il gateway. Microsoft offre un SLA di disponibilità del 99,9% per Gateway VPN. Lo SLA con disponibilità più elevata dipende dallo SKU. Per informazioni dettagliate a livello di SKU, vedere Affidabilità nei gateway di rete virtuale di Azure. Il contratto di servizio copre solo il gateway VPN e non copre il percorso Internet pubblico tra l'ambiente locale e il gateway.

Architettura di riferimento

Per una procedura dettagliata completa per l'implementazione di questa opzione, vedere l'architettura di riferimento seguente.

connettività Azure ExpressRoute

ExpressRoute è una connessione privata, ridondante e dedicata tra la rete locale dell'utente e Azure. Un provider di connettività non Microsoft fornisce il circuito oppure si usa ExpressRoute Direct per una connessione incrociata diretta tra Microsoft e la rete. Per una panoramica del modo in cui è possibile fornire il circuito, vedere Modelli di connettività ExpressRoute.

ExpressRoute si adatta alle applicazioni ibride che eseguono carichi di lavoro cruciali su larga scala che richiedono una larghezza di banda elevata e prestazioni prevedibili.

Diagramma che mostra la connettività ibrida con un gateway ExpressRoute.

Note

Nel contesto di ExpressRoute, il Microsoft Enterprise Edge (MSEE) fa riferimento ai router perimetrali sul lato Microsoft del circuito ExpressRoute. Questi router sono il punto di ingresso nella rete Microsoft.

ExpressRoute viene usato più comunemente con il peering privato di ExpressRoute, che fornisce connettività privata alle reti virtuali Azure. Supporta anche Microsoft peering per la connettività ai servizi pubblici Microsoft, ad esempio Microsoft 365 e gli endpoint dei servizi pubblici di Azure. Questo articolo è incentrato sul peering privato.

Vantaggi

Le funzionalità seguenti rendono ExpressRoute ideale per i carichi di lavoro ibridi che richiedono connettività dedicata e prevedibile.

  • Larghezza di banda elevata. ExpressRoute offre fino a 10 Gbps per circuito tramite provider di connettività e opzioni di doppia porta da 10 Gbps, 100 Gbps o 400 Gbps con ExpressRoute Direct. La velocità effettiva in-Azure viene controllata anche dallo SKU del gateway di rete virtuale ExpressRoute, che ha un limite di larghezza di banda per SKU specifico, quindi la velocità effettiva del carico di lavoro è il minimo del circuito, dello SKU del gateway e dei dispositivi perimetrali locali.
  • Latenza prevedibile. Un circuito dedicato evita la variabilità del percorso della rete Internet pubblica e il sovraccarico di elaborazione IPsec per pacchetto di un tunnel VPN. Questa progettazione rende la latenza round trip più bassa e più coerente rispetto alle connessioni basate su Internet.
  • Ridimensionamento dinamico della larghezza di banda. È possibile aumentare la larghezza di banda del circuito senza rimuovere la connessione, quando questa funzionalità è supportata dal provider di connettività.
  • Accesso al cloud nazionale. ExpressRoute supporta l'accesso diretto ai cloud nazionali, a seconda del provider di connettività.
  • SLA a livello di circuito. ExpressRoute offre un SLA di disponibilità elevata nel circuito ExpressRoute dedicato tra la rete perimetrale Microsoft e il provider di connettività o l'infrastruttura partner. Lo SLA non copre il percorso locale verso il provider o il gateway di rete virtuale ExpressRoute in Azure.

Challenges

Prendere in considerazione i vincoli seguenti prima di scegliere ExpressRoute per un carico di lavoro ibrido.

  • È necessario il coordinamento del provider. Il provisioning di un circuito diverso da ExpressRoute Direct richiede il coordinamento con un provider di connettività, che aggiunge lead time e una dipendenza al di fuori del perimetro gestito da Azure.
  • Router locali ad alta capacità. È possibile dimensionare i dispositivi perimetrali locali per la larghezza di banda del circuito scelta, incluse le sessioni BGP ridondanti verso entrambi gli MSEE.
  • Peering privato non crittografato per impostazione predefinita. Il peering privato di ExpressRoute fornisce un circuito privato, ma non crittografa il traffico a livello di rete per impostazione predefinita. Per i carichi di lavoro che richiedono la crittografia in transito, usare MACsec in ExpressRoute Direct o IPsec su ExpressRoute per aggiungere un livello di crittografia.

Architettura di riferimento

Per una procedura dettagliata completa per l'implementazione di questa opzione, vedere l'architettura di riferimento seguente.

Connettività SD-WAN o IPsec non Microsoft

Azure supporta l'hosting di soluzioni SD-WAN o IPsec non Microsoft per estendere un'architettura di rete esistente nel cloud. Queste opzioni non native consentono di usare una tecnologia di connettività preferita durante l'integrazione con Azure, in genere eseguendo l'appliance del fornitore come appliance virtuale di rete (NVA) in una rete virtuale hub o collegandola a un hub rete WAN virtuale.

Diagramma che mostra la connettività ibrida con SD-WAN.

Vantaggi

Le funzionalità seguenti rendono una distribuzione non Microsoft SD-WAN o IPsec adatta quando si vuole mantenere uno stack di connettività esistente.

  • Continuità dell'architettura. Estendi un'architettura di rete esistente in Azure usando tecnologie di connettività preferite, affinché gli ambienti on-premises e cloud condividano lo stesso modello operativo e di routing.
  • Copertura e scalabilità di Azure Mantenere una progettazione di rete coerente sfruttando al tempo stesso la portata globale e la scalabilità di Azure.

Challenges

Considerate i vincoli seguenti prima di scegliere una distribuzione non Microsoft SD-WAN o IPsec per un carico di lavoro ibrido.

  • Complessità dell'implementazione. Le soluzioni non native richiedono più passaggi di progettazione e integrazione rispetto alle opzioni di connettività native di Azure. Convalidate le architetture proposte con Microsoft e il partner SD-WAN o IPsec prima della distribuzione.
  • Disponibilità elevata e scalabilità definite dal fornitore. La disponibilità elevata, la velocità effettiva e il comportamento di ridimensionamento dipendono dall'architettura di riferimento del fornitore e dallo SKU e dal dimensionamento dell'istanza dell'appliance virtuale di rete in Azure. I contratti di servizio della piattaforma per Gateway VPN ed ExpressRoute non si estendono a una NVA non Microsoft in esecuzione nell'abbonamento. Il runtime, l'applicazione di patch e il comportamento di failover di tale appliance rimangono sotto la responsabilità dell'utente e del partner.

Architetture di riferimento

Per le procedure dettagliate complete sull'implementazione di queste opzioni, vedere le architetture di riferimento seguenti.

Considerations

Queste considerazioni sull'affidabilità applicano il pilastro Affidabilità di Azure Well-Architected Framework alla connettività ibrida. Gli altri pilastri (Sicurezza, Ottimizzazione costi, Eccellenza operativa ed Efficienza delle prestazioni) hanno le proprie considerazioni per VPN, ExpressRoute e connettività non Microsoft. Per una revisione completa del pilastro, vedere Microsoft Azure Well-Architected Framework.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

L'affidabilità della connettività ibrida dipende dalla resilienza sia del gateway o del circuito lato Azure sia dei percorsi di rete e in locale che vi si collegano.

  • Gateway con ridondanza di zona. Quando l'area supporta le zone di disponibilità, distribuire Gateway VPN e gateway ExpressRoute negli SKU con ridondanza della zona, in modo che Azure distribuisca le macchine virtuali del gateway tra le zone di disponibilità e il gateway superi un'interruzione a zona singola. Per altre informazioni, vedere Affidabilità nei gateway di rete virtuale di Azure (VPN) e Progettare e architettare Azure ExpressRoute per la resilienza.
  • Gateway VPN attivo-attivo. Per i carichi di lavoro che richiedono una maggiore resilienza e una velocità effettiva aggregata da una connessione VPN, distribuire il gateway VPN Azure in modalità attiva-attiva, in modo che entrambe le istanze del gateway portino traffico e che un tunnel da ogni istanza termini nel dispositivo VPN locale. Associare questa configurazione a due dispositivi VPN locali per rimuovere il singolo punto di guasto locale.
  • Sessioni BGP ridondanti per ExpressRoute. ExpressRoute effettua il provisioning di una coppia ridondante di sessioni BGP per peering su due router enterprise Edge (MSEE) Microsoft in una configurazione attiva-attiva. Ridimensionare i dispositivi edge del cliente on-premises per terminare entrambe le sessioni e prendere in considerazione Bidirectional Forwarding Detection (BFD) per abbreviare il rilevamento degli errori di collegamento al di sotto del timeout BGP predefinito.
  • Diversità del provider e del sito per ExpressRoute. Il collegamento integrato e la ridondanza del router non eliminano una dipendenza condivisa da un carrier. Per i carichi di lavoro che devono resistere a un'interruzione a livello di operatore, prendere in considerazione circuiti ridondanti tramite operatori e punti di peering diversi. Verificare la diversità dei percorsi fisici end-to-end con i provider. Per altre informazioni, vedere Considerazioni sull'affidabilità di ExpressRoute.
  • VPN come percorso di failover per ExpressRoute. Per i carichi di lavoro che richiedono un percorso secondario, configurare una VPN da sito a sito come backup coesistente per un circuito di peering privato ExpressRoute. Il circuito ExpressRoute rimane primario e il traffico usa il percorso VPN solo quando il circuito non è disponibile. Configurare il routing locale (ad esempio, preferenza locale) per preferire il percorso ExpressRoute ed evitare il routing asimmetrico.
  • Failover regionale. Gli elementi precedenti indirizzano la resilienza con ambito di zona e con ambito di percorso all'interno di una singola area Azure. I carichi di lavoro che richiedono la continuità durante un'interruzione a livello di area richiedono un secondo gateway o circuito nell'area di failover e la selezione del percorso a livello di DNS o di routing per indirizzare il traffico all'area superstite. Vedere Progettazione per il ripristino di emergenza con il peering privato di ExpressRoute.
  • Componenti che gestisci Il dispositivo VPN locale, i router perimetrali locali e qualsiasi appliance virtuale non Microsoft SD-WAN o IPsec in esecuzione in Azure non rientrano nello SLA della piattaforma Azure. Pianificare la ridondanza a livello di dispositivo, l'applicazione di patch e il failover per tali componenti in linea con la progettazione di riferimento del fornitore.

Contributori

Microsoft mantiene questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Per indicazioni sull'implementazione dell'opzione di connettività selezionata, vedere l'architettura di riferimento corrispondente:

Gli articoli seguenti illustrano le topologie di rete Azure correlate che spesso accompagnano le progettazioni di connettività ibrida:

  • Ultimo aggiornamento: