Connettività ibrida: collegare on-premises ad Azure

Questo articolo illustra come scegliere e pianificare l'opzione di connettività appropriata per la connessione della rete locale alle reti virtuali Azure.

Informazioni su questo articolo

Questo articolo illustra le decisioni di progettazione per la connessione delle reti locali alle reti virtuali Azure tramite Gateway VPN di Azure o Azure ExpressRoute. Si apprenderà quando usare ogni opzione, come interagiscono e come pianificare la distribuzione del gateway. Per una panoramica generale dei servizi di connettività ibrida, vedi Cos'è la connettività ibrida?

Chi ha bisogno di questo articolo

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

I carichi di lavoro Azure devono comunicare con sistemi, utenti o data center locali.
È necessario scegliere tra Gateway VPN ed ExpressRoute in base a larghezza di banda, latenza, resilienza o costi.
È necessario un percorso privato o crittografato per identità, dati, gestione o dipendenze dell'applicazione che rimangono al di fuori di Azure.
È necessario pianificare la topologia del gateway, la ridondanza o la coesistenza tra VPN ed ExpressRoute.

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: i carichi di lavoro migrati devono comunicare con i sistemi locali. La connettività ibrida è la dipendenza di migrazione più critica. Senza una connessione VPN o ExpressRoute, le macchine virtuali migrate in Azure non possono raggiungere database locali, condivisioni file o servizi di identità da cui dipendono le applicazioni.

Focus sulla modernizzazione: Le app modernizzate potrebbero comunque richiedere connettività locale durante il periodo di transizione. Durante la migrazione dei carichi di lavoro ai servizi PaaS, alcune dipendenze rimangono in locale fino al completamento della migrazione completa. Pianifica la connettività ibrida come un ponte che puoi ridimensionare o rimuovere man mano che elimini le dipendenze locali.

Focus cross-cloud: Hai bisogno di tunnel VPN IPsec tra Azure e AWS o Google Cloud per il transito cross-cloud cifrato. Le applicazioni con dipendenze tra cloud richiedono percorsi di rete sicuri e affidabili tra provider di servizi cloud. Questo modello di connettività usa Gateway VPN di Azure per terminare i tunnel dai gateway privati virtuali AWS e dagli endpoint VPN di Google Cloud.

Azure servizi e funzionalità

Azure offre diversi servizi per la connettività ibrida. Ogni servizio risolve diversi requisiti di larghezza di banda, latenza, costi e sicurezza.

Service	Elementi forniti	Quando usarlo
Gateway VPN di Azure (da sito a sito)	Tunnel IPsec/IKE crittografato su Internet pubblico. Connette i dispositivi VPN locali a Azure.	Organizzazioni più piccole, ambienti di sviluppo/test, percorso di connettività di backup o scenari ibridi vincolati dal budget.
Gateway VPN di Azure (point-to-site)	Connessioni client singole a una rete virtuale Azure. Supporta i protocolli OpenVPN, SSTP e IKEv2.	Amministratori remoti o sviluppatori che necessitano dell'accesso individuale alle risorse di Azure. Vedere l'articolo sull'accesso remoto per indicazioni dettagliate sul P2S.
Azure ExpressRoute	Connessione dedicata privata tramite un provider di connettività. Il traffico non attraversa la rete Internet pubblica.	Carichi di lavoro ibridi di produzione, applicazioni sensibili alla latenza, trasferimenti di dati di grandi dimensioni e requisiti normativi o di conformità.
ExpressRoute con failover VPN	ExpressRoute come percorso primario con Gateway VPN come backup in caso di failover.	Requisiti di disponibilità elevata in cui il tempo di inattività di ExpressRoute non è tollerabile.
Copertura globale di ExpressRoute	Collega due sedi on-premises tra loro tramite la backbone di Azure utilizzando i rispettivi circuiti ExpressRoute.	Reti aziendali multisito che usano Azure come backbone di transito. Per i dettagli, vedere l'articolo su multi-cloud e tra aree geografiche.
ExpressRoute Direct	Connettività dedicata da 10 Gbps, 100 Gbps o 400 Gbps diretta alla rete perimetrale di Microsoft. Supporta la crittografia MACsec Layer 2.	Requisiti di larghezza di banda più elevati, requisiti di crittografia MACsec o quando è necessario ignorare il sovraccarico del provider di connettività. L'opzione 400 Gbps è disponibile in posizioni limitate e richiede la registrazione.

Note

La VPN point-to-site (P2S) fornisce accesso individuale al client, che si sovrappone all'ambito dell'articolo sull'accesso remoto. Questo articolo è incentrato su P2S come parte del panorama della connettività ibrida. Per indicazioni sulla distribuzione da sito a sito, l'integrazione delle identità e la configurazione client, vedere l'articolo Accesso remoto per sviluppatori e amministratori.

Funzionamento di Gateway VPN

Gateway VPN di Azure crea un tunnel IPsec/IKE crittografato tra il dispositivo VPN locale e un gateway di rete virtuale Azure. I seguenti passaggi descrivono il processo di installazione del tunnel site-to-site (S2S):

Provisioning del gateway: si distribuisce una risorsa Gateway VPN nella rete virtuale dell'hub GatewaySubnet. Azure effettua il provisioning di due o più istanze del gateway (a seconda dello SKU e della configurazione attiva-attiva). Il provisioning richiede circa 30-45 minuti.
Definizione del gateway di rete locale: Si crea una risorsa gateway di rete locale in Azure che rappresenta la rete locale. Questa risorsa specifica l'indirizzo IP pubblico del dispositivo VPN locale e gli intervalli di indirizzi locali che Azure devono instradare attraverso il tunnel.
Creazione della risorsa di connessione: Si crea una risorsa di connessione che collega il Gateway VPN al gateway di rete locale. Specifica la chiave condivisa (chiave precondivisa) e i parametri IPsec/IKE per il tunnel.
Fase IKE 1 (modalità principale): Il gateway Azure e il dispositivo locale negoziano un canale sicuro. Scambiano proposte per algoritmi di crittografia, algoritmi di integrità, gruppi di Diffie-Hellman e metodi di autenticazione. Il risultato è un'associazione di sicurezza IKE (SA).
IKE Fase 2 (Modalità Rapida): Utilizzando il canale sicuro della Fase 1, entrambe le parti negoziano i parametri SA IPsec: algoritmo di cifratura, algoritmo di integrità e durata della chiave. Questo processo stabilisce il tunnel IPsec.
Flussi di traffico: Al termine di entrambe le fasi, il tunnel è attivo. Il traffico che corrisponde agli intervalli di indirizzi definiti viene crittografato, incapsulato nei pacchetti ESP IPsec e inviato attraverso la rete Internet pubblica all'endpoint remoto.

Per le configurazioni attive-attive, Azure effettua il provisioning di due istanze del gateway, ognuna con il proprio indirizzo IP pubblico. Il dispositivo locale stabilisce tunnel con entrambe le istanze, garantendo il failover automatico se una delle istanze diventa indisponibile.

Come funziona ExpressRoute

Azure ExpressRoute crea una connessione privata tra la rete locale e Azure tramite un provider di connettività. A differenza della VPN, il traffico non passa mai attraverso la rete Internet pubblica. Il modello di connettività prevede tre archi di rete:

Edge del cliente (CE): il router locale nel data center o nella struttura di condivisione. Questo dispositivo stabilisce una sessione di peering con il router di confine del provider utilizzando BGP.
Provider edge (PE): Il router del provider di connettività situato presso il suo sito meet-me (struttura di peering). Il fornitore configura una connessione di livello 2 o di livello 3 tra il tuo CE e il proprio PE.
Microsoft edge (MSEE): router Microsoft Enterprise Edge nell'infrastruttura di peering. Il fornitore connette il proprio PE all'MSEE, completando il percorso privato verso Azure.

Quando si esegue il provisioning di un circuito ExpressRoute, il fornitore predispone connessioni ridondanti tra tutti e tre i punti perimetrali. Azure pubblicizza i prefissi di indirizzo della macchina virtuale al router CE tramite BGP e il router CE pubblicizza le route locali ad Azure. Questo scambio bidirezionale di rotte consente al traffico di transitare sul percorso privato.

ExpressRoute supporta due tipi di peering:

Peering privato di Azure: connette alle reti virtuali di Azure (IaaS e PaaS con endpoint privati). Questo tipo di peering è il più comune per la connettività ibrida.
Microsoft peering: si connette ai servizi pubblici di Microsoft 365 e Azure (ad esempio gli endpoint pubblici di Archiviazione di Azure). Richiede filtri di route per selezionare prefissi di servizio specifici.

Confronto tra SKU di ExpressRoute

Feature	Local	Standard	Premium
Località di peering	Una o due località della metropolitana designata	Tutte le località di peering in una regione geopolitica	Tutti i punti di peering globali
Connessioni di rete virtuale per circuito	Dipende dallo SKU del gateway	10	100
Prefissi di instradamento (peering Microsoft)	N/A	4,000	10,000
Connettività tra aree	Solo la stessa area metropolitana	Stessa area geopolitica	Qualsiasi area Azure in tutto il mondo
Supporto di Copertura globale	No	Sì	Sì
Prezzi per il trasferimento dei dati	Traffico in entrata e in uscita illimitato (piano a consumo); incluso con il piano illimitato	Traffico in entrata gratuito; traffico in uscita a consumo in base alla zona	Traffico in entrata gratuito; traffico in uscita a consumo in base alla zona
Migliore per	Carichi di lavoro a larghezza di banda elevata e a singola area vicino a una località di peering	Più siti all'interno di un'area geopolitica	Azienda globale con carichi di lavoro in più aree Azure

Tip

Il Local SKU offre un significativo risparmio sui costi perché il prezzo del circuito include sia il trasferimento di dati in entrata che in uscita. Scegli Locale quando l'area geografica di Azure si trova nella stessa area metropolitana della località di peering o nelle sue vicinanze.

confronto tra SKU Gateway VPN

SKU	Numero massimo di tunnel S2S	Numero massimo di connessioni P2S	Benchmark velocità effettiva aggregata	Con ridondanza della zona
VpnGw1/ VpnGw1AZ	30	250	650 Mbps	Solo la variante AZ
VpnGw2/VpnGw2AZ	30	500	1,0 Gbps	Solo la variante AZ
VpnGw3/VpnGw3AZ	30	1,000	2,0 Gbps	Solo la variante AZ
VpnGw4/VpnGw4AZ	100	5,000	5,0 Gbps	Solo la variante AZ
VpnGw5/VpnGw5AZ	100	10,000	10,0 Gbps	Solo la variante AZ

Note

I benchmark di throughput sono calcolati in forma aggregata su tutti i tunnel e tutte le connessioni. La velocità effettiva dipende dai modelli di traffico, dalle dimensioni dei pacchetti e dal numero di tunnel attivi. Selezionare sempre la variante AZ per le distribuzioni in produzione, in modo da ottenere una disponibilità con ridondanza tra zone.

Come scegliere

Usare le tabelle decisionali seguenti per selezionare l'opzione di connettività corretta e determinare dove posizionare il gateway.

Gateway VPN e ExpressRoute

Consideration	Scegliere Gateway VPN	Scegliere ExpressRoute
Bilancio	Costo inferiore. Tariffa gateway all'ora più addebiti per il trasferimento dei dati.	Costo più elevato. Tariffa del circuito del provider, tariffa gateway e addebiti per il trasferimento dei dati.
Larghezza di banda necessaria	Fino a 10 Gbps di capacità effettiva aggregata (SKU VpnGw5). La velocità effettiva del singolo tunnel è inferiore.	Fino a 100 Gbps per circuito. ExpressRoute Direct supporta fino a 400 Gbps.
Tolleranza di latenza	Latenza più elevata accettabile. Il traffico attraversa la rete Internet pubblica.	È necessaria una latenza bassa e prevedibile. Il traffico segue un percorso privato.
Contratto di servizio per l'affidabilità	Superiore con una configurazione del gateway attiva-attiva.	Più elevato per il circuito e massimo con una distribuzione di gateway con ridondanza di zona (SKU AZ). Vedere i contratti sul livello di servizio di Azure.
Privacy e conformità	Il traffico rimane criptato ma attraversa internet pubblico.	Il traffico non attraversa mai la rete Internet pubblica.
Velocità di implementazione	Da poche ore a diversi giorni. Il processo di provisioning del gateway richiede circa 45 minuti.	Da settimane a mesi. L'approvvigionamento dei circuiti del provider richiede la predisposizione dell'infrastruttura fisica.
Circuito ExpressRoute esistente	Usare Gateway VPN come percorso di backup insieme a ExpressRoute.	Usare come percorso di connettività primario.

Dove si trova il gateway?

Topology	Posizionamento del gateway	Motivazione
Hub-and-spoke	Gateway nella rete virtuale hub	Tutti i carichi di lavoro spoke instradano il traffico locale attraverso l'hub. Centralizza la gestione della connettività. Vedere l'articolo hub-and-spoke.
Carico di lavoro singolo (flat)	Gateway nella rete virtuale del carico di lavoro	Architettura più semplice per carichi di lavoro autonomi che non condividono la connettività con altre reti virtuali.

Opzioni di resilienza di ExpressRoute

La tabella seguente riepiloga come aumentare la disponibilità di ExpressRoute. Per le attuali percentuali SLA, vedere Contratti di servizio di Azure.

Livello di resilienza	Configurazione	SLA
Standard	Singolo circuito ExpressRoute con collegamenti incrociati ridondanti.	Contratto di servizio a livello di circuito
Gateway con ridondanza della zona	Distribuisci un gateway ExpressRoute utilizzando uno SKU AZ (ErGw1AZ, ErGw2AZ o ErGw3AZ). Le istanze si distribuiscono tra le zone di disponibilità.	Contratto di servizio a livello di gateway
Massimo	Circuiti duali in posizioni di peering diverse con gateway con ridondanza della zona, oltre al failover VPN.	Massima disponibilità composita

Decisione di deployment: esempio di posizionamento del gateway

Si consideri un'azienda con una rete hub-and-spoke che dispone di tre reti virtuali spoke per la produzione, la pre-produzione e lo sviluppo. I carichi di lavoro di produzione richiedono ExpressRoute per la replica di database a bassa latenza, mentre lo sviluppo usa Gateway VPN per un'efficienza dei costi.

Posizionamento consigliato:

Distribuire sia un gateway ExpressRoute che un Gateway VPN nel GatewaySubnet dell'hub VNet (richiede una subnet /26 per la coesistenza).
Connettere gli spoke di produzione e staging all'hub tramite peering di rete virtuale, con il transito del gateway abilitato. Questi spoke usano il percorso ExpressRoute per la connettività locale.
Connettere lo spoke di sviluppo all'hub con il transito tramite gateway abilitato. Configurare le tabelle di route in modo che il traffico di sviluppo usi preferibilmente il tunnel VPN, riducendo i costi di trasferimento dei dati di ExpressRoute.
Configurare la connessione VPN come percorso di failover per la produzione in caso di interruzione del circuito ExpressRoute.

Questo approccio centralizza la gestione dei gateway in un unico hub, minimizza il numero di risorse gateway necessarie e abbina ciascun spoke al livello di connettività appropriato per i requisiti del carico di lavoro.

Considerazioni sui costi

Gateway VPN ed ExpressRoute hanno modelli di prezzi diversi. La comprensione di questi modelli consente di ottimizzare la spesa.

Componente di costo	Gateway VPN	ExpressRoute
Tariffa oraria del gateway	Addebito per ora in base allo SKU (VpnGw1 è il meno costoso)	Addebito per ora in base allo SKU del gateway (ErGw1AZ è il meno costoso)
Tariffa circuito/connessione	Nessuna tariffa di circuito; solo il gateway e il trasferimento dei dati	Tariffa di porta mensile pagata per Microsoft, oltre agli addebiti del provider per il circuito fisico
Trasferimento dati: in ingresso	Gratuito	Gratuito
Trasferimento dei dati: in uscita	Addebitato per GB alle tariffe standard per il traffico in uscita di Azure	Piano a consumo: addebitato per GB. Piano illimitato: tariffa mensile fissa. SKU locale: incluso
Addebiti del provider	Nessuno (usa Internet pubblico)	Tariffa mensile per il provider di connettività per la porta e la connessione incrociata
Intervallo mensile tipico	$140–$2.500 (solo il gateway; il trasferimento dei dati varia)	$500–$15.000+ (gateway + circuito + provider; dipende dalla larghezza di banda e dallo SKU)

Suggerimenti per l'ottimizzazione dei costi:

Usare lo SKU locale per ExpressRoute quando i carichi di lavoro si trovano nella stessa area metropolitana della località di peering. Questa scelta elimina gli addebiti per il trasferimento dei dati in uscita.
Scegliere il piano a consumo per ExpressRoute se il trasferimento dati in uscita è inferiore a circa 10 TB/mese. Usare il piano illimitato per carichi di lavoro con volumi più elevati.
Implementa Gateway VPN come failover invece che come secondo circuito ExpressRoute se hai un budget limitato ma hai comunque bisogno di ridondanza.
Scegli le dimensioni appropriate per lo SKU del gateway VPN. Inizia con VpnGw2AZ per la maggior parte dei carichi di lavoro di produzione e passa a un livello superiore solo se osservi una saturazione costante del throughput.
Esaminare l'utilizzo mensile del gateway. Le metriche di Monitoraggio di Azure mostrano il throughput del tunnel e il numero di connessioni, aiutando a identificare i gateway sovradimensionati.

Considerazioni relative alla progettazione

Per le migrazioni lift-and-shift, il gateway VPN nell'hub VNet è in genere la prima risorsa di connettività che si implementa:

Gateway VPN nella rete virtuale dell'hub. Distribuisci Gateway VPN nell'GatewaySubnet dell'hub. Tutti i carichi di lavoro spoke accedono alle risorse locali con transito tramite gateway. La VPN site-to-site è la tipica prima scelta perché viene distribuita in poche ore invece delle settimane che richiede il provisioning dei circuiti ExpressRoute.
Dimensionamento della larghezza di banda in base ai requisiti dell'applicazione. Raccogli i requisiti di larghezza di banda da ciascun carico di lavoro da migrare. Sommare le simultanee esigenze di capacità effettiva di picco e selezionare uno SKU Gateway VPN che supporta l'aggregazione. Iniziare con VpnGw2AZ per la maggior parte dei carichi di lavoro di produzione. Se l'aggregazione supera i 1 Gbps, valutare ExpressRoute o un livello di Gateway VPN superiore.
Pianificare ExpressRoute come passaggio successivo. Molte organizzazioni iniziano con VPN durante le fasi iniziali della migrazione, quindi aggiungono ExpressRoute per carichi di lavoro di produzione che richiedono una latenza prevedibile o una larghezza di banda superiore. L'hub GatewaySubnet supporta entrambi i tipi di gateway contemporaneamente.

Per le architetture modernizzate con distribuzioni in più aree, pianificare i gateway con ridondanza della zona in entrambe le aree:

Gateway VPN con ridondanza di zona in entrambe le regioni. Distribuire Gateway VPN con SKU AZ (VpnGw2AZ o superiore) in entrambi gli hub dell'area geografica primaria e di quella di backup. La distribuzione con ridondanza tra zone distribuisce le istanze del gateway tra le zone di disponibilità, offrendo uno SLA di disponibilità più elevato per il componente gateway. Per le percentuali SLA specifiche, vedi Contratti di servizio di Azure.
Capacità di gestire il guasto di una singola area geografica. Ridimensionare ogni gateway a livello di area per gestire il carico di traffico completo in modo indipendente. Se un'area ha esito negativo, tutto il traffico ibrido viene instradato attraverso il gateway dell'area rimanente. Evitare il sottodimensionamento del gateway della regione di backup.
Pianificazione della transizione. La connettività ibrida in uno scenario di modernizzazione è spesso temporanea. Poiché i servizi PaaS sostituiscono le dipendenze locali, è possibile ridurre la capacità del gateway o rimuovere i gateway una volta che tutti i carichi di lavoro sono nativi del cloud.

Per la connettività tra cloud, Gateway VPN stabilisce tunnel crittografati ad altri provider di servizi cloud:

Connessioni VPN al gateway privato virtuale AWS. Creare connessioni VPN site-to-site da Gateway VPN di Azure a gateway privati virtuali di AWS. Configurare BGP per lo scambio di route dinamiche tra Azure reti virtuali e VPN AWS. Ogni tunnel VPN AWS supporta fino a 1,25 Gbps (limite lato AWS); usare più tunnel o ECMP per una maggiore velocità effettiva aggregata.
Connessioni VPN verso Google Cloud VPN. Creare connessioni VPN da sito a sito da Gateway VPN di Azure a GOOGLE Cloud VPN (VPN a disponibilità elevata). Google Cloud HA VPN offre due estremità del tunnel per la ridondanza. Configurare il peering BGP per la propagazione automatica delle route tra Azure e Google Cloud.
Eseguire la distribuzione all'interno della rete WAN virtuale o dell'hub. Se si sceglie rete WAN virtuale come modello di transito, distribuire le connessioni VPN dall'hub rete WAN virtuale anziché un Gateway VPN autonomo. Se hai scelto la topologia hub-and-spoke tradizionale, distribuisci nell'GatewaySubnet dell'hub. Entrambi gli approcci supportano gli stessi tunnel IPsec/IKE verso AWS e Google Cloud.

Prerequisiti

Prima di implementare la connettività ibrida, verificare che siano soddisfatti i requisiti seguenti:

Rete virtuale con gatewaySubnet: La rete virtuale deve includere una subnet dedicata denominata GatewaySubnet con una dimensione minima di /27 (o /26 se si prevede di coesistere i gateway ExpressRoute e VPN). Per indicazioni sulla pianificazione della rete virtuale e della subnet, vedere l'articolo Reti virtuali e subnet.
Dispositivo VPN locale (per Gateway VPN): dispositivo VPN compatibile che supporta IKEv2 e IPsec. Microsoft gestisce un elenco di dispositivi VPN convalidati.
Relazione tra provider di connettività (per ExpressRoute): Contratto con un provider di connettività ExpressRoute o allocazione di porte ExpressRoute Direct. Il provisioning del fornitore richiede uno scambio della chiave di servizio e la configurazione della connessione incrociata fisica.
Pianificazione degli indirizzi IP: Spazi indirizzi non sovrapposti tra reti locali e Azure. Pianificate gli indirizzi della subnet del gateway nell'ambito della strategia IP complessiva. Vedere l'articolo Sulla pianificazione IP.
Supporto del Border Gateway Protocol (BGP): ExpressRoute richiede BGP ed è consigliato per il routing dinamico Gateway VPN. Verificare che l'attrezzatura locale supporti BGP.

Considerazioni relative alla sicurezza

La connettività ibrida introduce limiti di sicurezza che richiedono un'attenta pianificazione. Ogni tipo di connettività ha profili di minaccia e strategie di mitigazione diversi.

Il traffico ExpressRoute non è crittografato per impostazione predefinita

ExpressRoute fornisce un percorso privato, ma non cripta il traffico a livello di rete di default. Questa mancanza di crittografia significa che chiunque abbia accesso fisico all'infrastruttura del provider potrebbe teoricamente intercettare il traffico. Prendere in considerazione le opzioni di crittografia seguenti in base al profilo di rischio:

MACsec (livello 2): Disponibile solo in ExpressRoute Direct. Crittografa il traffico sul collegamento fisico tra i router perimetrali e la rete perimetrale di Microsoft. Devi abilitare esplicitamente MACsec dopo il provisioning delle porte. Questa opzione offre la crittografia a velocità di trasmissione con un sovraccarico di latenza minimo.
IPsec su ExpressRoute (livello 3): Esegui un tunnel VPN tramite la connessione di peering privato di ExpressRoute per la crittografia end-to-end. Questo approccio funziona con qualsiasi circuito ExpressRoute e crittografa il traffico attraverso la rete del provider e il backbone Microsoft. Lo SKU del Gateway VPN limita il throughput.
Crittografia a livello di applicazione: Usare TLS/HTTPS a livello di applicazione. Questo approccio è indipendente dal tipo di connettività e protegge i dati indipendentemente dal trasporto sottostante. È la crittografia minima più comune e consigliata per tutti i carichi di lavoro ibridi.

Per la maggior parte delle organizzazioni, la combinazione del percorso privato ExpressRoute più TLS a livello di applicazione offre una protezione sufficiente. Aggiungere MACsec o IPsec su ExpressRoute solo quando i requisiti normativi impongono la crittografia a livello di rete per i dati in transito.

Il routing asimmetrico interrompe i firewall con stato

Quando si usano più percorsi di connettività, ad esempio ExpressRoute e VPN, il traffico può seguire percorsi in ingresso e in uscita diversi. I firewall con stato eliminano il traffico restituito che arriva su un'interfaccia diversa rispetto alla richiesta originale. Pianificare il routing per garantire percorsi simmetrici o usare tabelle di route e attributi BGP per controllare il flusso del traffico.

Le strategie di mitigazione includono:

Impostare il prepending del percorso AS BGP sul percorso di backup per renderlo meno preferito.
Usare le tabelle di routing (UDRs) sulle subnet per instradare il traffico attraverso un gateway specifico.
Configurare le community BGP e le preferenze locali per influenzare in modo deterministico la selezione delle route.
Testare gli scenari di failover per verificare che il traffico ritorni attraverso lo stesso percorso da cui è arrivato.

Avviso relativo a NSG di GatewaySubnet

Attenzione

Non applicare gruppi di sicurezza di rete (NSG) a GatewaySubnet, a meno che non si comprenda appieno l'impatto. Regole NSG configurate in modo errato nella GatewaySubnet possono interrompere l'intera connettività ibrida. Il gateway richiede specifiche comunicazioni del piano di controllo che le regole NSG possono bloccare inavvertitamente.

Se è necessario applicare NSG alla GatewaySubnet, consentire come minimo il traffico dai tag di servizio GatewayManager e AzureLoadBalancer. Esaminare la documentazione del gateway per l'elenco completo delle regole necessarie prima di apportare modifiche.

Crittografia VPN site-to-site

IKEv2/IPsec cripta sempre il traffico VPN site-to-site durante il transito. Gli algoritmi di crittografia e i punti di forza della chiave vengono configurati come parte dei criteri IPsec/IKE nella connessione. Usare criteri personalizzati per applicare algoritmi di crittografia specifici anziché basarsi sulle impostazioni predefinite.

Impostazioni consigliate dei criteri personalizzati per i carichi di lavoro di produzione:

Fase 1 IKE: crittografia AES-256, integrità SHA-256, gruppo DH 14 o versione successiva
IKE Fase 2 (IPsec): crittografia AES-256-GCM, gruppo PFS 14 o versione successiva
Durata sa predefinita: 28.800 secondi (IKE), 3.600 secondi (IPsec)

Evitare di usare algoritmi deprecati (DES, 3DES, MD5, SHA-1, DH Group 1/2) anche se Azure li supporta ancora per la compatibilità con le versioni precedenti.

Autenticazione VPN da punto a sito

La VPN P2S supporta l'autenticazione di Microsoft Entra ID con integrazione dell'autenticazione a più fattori (MFA). Questa opzione fornisce il controllo degli accessi in base all'identità per i singoli client che si connettono a Azure. La VPN P2S supporta anche l'autenticazione basata su certificati e RADIUS.

Scegliere il metodo di autenticazione in base ai requisiti:

Method	Ideale per	Postura di sicurezza
Microsoft Entra ID	Organizzazioni che usano già Microsoft Entra ID con Accesso condizionale di Microsoft Entra	Più sicuro: supporta mfa, conformità dei dispositivi e criteri basati sui rischi
Basato su certificati	Ambienti senza Microsoft Entra ID o per connessioni da computer a computer	Avanzata: richiede l'infrastruttura PKI e la gestione del ciclo di vita dei certificati
RADIUS	Integrazione con sistemi di identità locali esistenti (NPS, terze parti)	Varia: dipende dalla configurazione del server RADIUS e dall'autenticazione back-end

Cos'è la connettività ibrida?: Panoramica dei servizi di connettività ibrida di Azure e quando utilizzare ciascuno.
Reti virtuali e subnet: prerequisiti per il ridimensionamento di GatewaySubnet e la rete virtuale per la connettività ibrida.
Tunneling forzato e controllo del traffico in uscita: come il tunneling forzato instrada il traffico diretto a Internet da Azure di nuovo all'ambiente locale.
Accesso privato ai servizi PaaS: rendere gli endpoint privati raggiungibili dalle reti locali tramite connettività ibrida.
Accesso remoto per sviluppatori e amministratori: distribuzione VPN point-to-site, integrazione dell'identità e dettagli sulla configurazione del client.
Connettività multicloud e tra regioni: scenari di ExpressRoute Global Reach e di connettività tra cloud.
Topologia hub-and-spoke: posizionamento del gateway nella rete virtuale hub e configurazione del routing spoke.

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:

Configurare l'accesso amministratore sicuro alle macchine virtuali: distribuire Azure Bastion nella rete virtuale dell'hub in modo che gli amministratori possano eseguire rdp/SSH per eseguire la migrazione di macchine virtuali senza esposizione di indirizzi IP pubblici.

Nel prossimo percorso di modernizzazione:

Progetta i tuoi modelli di traffico in ingresso da Internet: stabilisci come il traffico rivolto ai clienti raggiunge gli endpoint di Front Door, Traffic Manager e Application Gateway.

Il prossimo passo nel tuo percorso multicloud:

Pianificare il cutover del DNS e la risoluzione dei nomi DNS: mappa i record DNS esistenti, riduci i valori TTL e configura DNS privato Resolver per la risoluzione dei nomi tra ambienti cloud.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-07-01