Questo articolo confronta due modi per connettere reti virtuali in Azure: peering di reti virtuali e gateway VPN.
Una rete virtuale è una parte virtuale, isolata della rete pubblica di Azure. Per impostazione predefinita, il traffico non può essere instradato tra due reti virtuali. Tuttavia, è possibile connettere reti virtuali, all'interno di una singola area o tra due aree, in modo che il traffico possa essere instradato tra di essi.
Tipi di connessione di rete virtuale
Peering di reti virtuali. Il peering di rete virtuale connette due reti virtuali di Azure. Dopo avere eseguito il peering, le reti virtuali vengono visualizzate come una sola dal punto di vista della connettività. Il traffico tra macchine virtuali nelle reti virtuali con peering viene instradato attraverso l'infrastruttura backbone Microsoft, solo tramite indirizzi IP privati. Non è coinvolta alcuna rete Internet pubblica. È anche possibile eseguire il peering di reti virtuali tra aree di Azure (peering globale).
Gateway VPN. Un gateway VPN è un tipo specifico di gateway di rete virtuale, usato per inviare traffico tra una rete virtuale di Azure e una posizione locale attraverso la rete Internet pubblica. È anche possibile usare un gateway VPN per inviare traffico tra reti virtuali di Azure. Ogni rete virtuale può avere al massimo un gateway VPN. È consigliabile abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.
Il peering di rete virtuale offre una connessione a bassa latenza e larghezza di banda elevata. Non è presente alcun gateway nel percorso, quindi non sono presenti hop aggiuntivi, garantendo connessioni a bassa latenza. È utile in scenari come la replica dei dati tra aree e il failover del database. Poiché il traffico è privato e rimane sul backbone Microsoft, prendere in considerazione anche il peering di rete virtuale se si dispone di criteri di dati rigorosi e si vuole evitare l'invio di traffico su Internet.
I gateway VPN forniscono una connessione con larghezza di banda limitata e sono utili negli scenari in cui è necessaria la crittografia, ma possono tollerare restrizioni di larghezza di banda. In questi scenari, anche i clienti non sono sensibili alla latenza.
Transito gateway
Il peering di rete virtuale e le Gateway VPN possono coesistere anche tramite il transito del gateway
Il transito del gateway consente di usare il gateway di una rete virtuale con peering per la connessione all'ambiente locale, invece di creare un nuovo gateway per la connettività. Per adeguarti all'incremento continuo dei carichi di lavoro in Azure devi ridimensionare le reti in diverse aree geografiche e in diverse reti virtuali. Il transito del gateway consente di condividere un gateway ExpressRoute o VPN con tutte le reti virtuali con peering e di gestire la connettività in un'unica posizione. La condivisione consente risparmi sui costi e riduzione del sovraccarico di gestione.
Con il transito del gateway abilitato nel peering di rete virtuale, è possibile creare una rete virtuale di transito contenente il gateway VPN, l'appliance virtuale di rete e altri servizi condivisi. Man mano che l'organizzazione cresce con nuove applicazioni o business unit e man mano che si avviano nuove reti virtuali, è possibile connettersi alla rete virtuale di transito usando il peering. Ciò impedisce l'aggiunta di complessità alla rete e riduce il sovraccarico di gestione della gestione di più gateway e altre appliance.
Configurazione delle connessioni
Il peering di rete virtuale e i gateway VPN supportano entrambi i tipi di connessione seguenti:
- Reti virtuali in aree diverse.
- Reti virtuali in diversi tenant di Microsoft Entra.
- Reti virtuali in sottoscrizioni di Azure diverse.
- Reti virtuali che usano una combinazione di modelli di distribuzione di Azure (Resource Manager e versione classica).
Per altre informazioni, vedere gli articoli seguenti:
- Creare un peering di rete virtuale - Resource Manager, sottoscrizioni diverse
- Creare un peering di rete virtuale: modelli di distribuzione diversi, stessa sottoscrizione
- Configurare una connessione gateway VPN da rete virtuale a rete virtuale usando il portale di Azure
- Connessione reti virtuali da modelli di distribuzione diversi usando il portale
- Domande frequenti sul gateway VPN
Confronto tra peering di rete virtuale e gateway VPN
| Articolo | Peering di rete virtuale | Gateway VPN |
|---|---|---|
| Limiti | Fino a 500 peering di rete virtuale per rete virtuale (vedere Limiti di rete). | Un gateway VPN per rete virtuale. Il numero massimo di tunnel per gateway dipende dallo SKU del gateway. |
| Modello di determinazione prezzi | Ingresso/uscita | Hourly + Egress |
| Crittografia | È possibile sfruttare Crittografia Rete virtuale di Azure. | I criteri IPsec/IKE personalizzati possono essere applicati alle connessioni nuove o esistenti. Vedere Informazioni sui requisiti di crittografia e sui gateway VPN di Azure. |
| Limitazioni della larghezza di banda | Nessuna limitazione della larghezza di banda. | Varia in base alla SKU. Vedere SKU del gateway per tunnel, connessione e velocità effettiva. |
| Privato? | Sì. Instradato attraverso il backbone Microsoft e privato. Nessuna rete Internet pubblica coinvolta. | Ip pubblico interessato, ma indirizzato attraverso il backbone Microsoft se è abilitata la rete globale Microsoft. |
| Relazione transitiva | Le connessioni di peering non sono transitive. La rete transitiva può essere ottenuta usando appliance virtuali di rete o gateway nella rete virtuale hub. Per un esempio, vedere Topologia di rete hub-spoke. | Se le reti virtuali sono connesse tramite gateway VPN e BGP è abilitato nelle connessioni di rete virtuale, funziona la transitività. |
| Tempo di configurazione iniziale | Veloce | ~30 minuti |
| Scenari tipici | La replica dei dati, il failover del database e altri scenari richiedono backup frequenti di dati di grandi dimensioni. | Scenari specifici della crittografia che non sono sensibili alla latenza e che non richiedono un elevato utilizzo. |
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Anavi Nahar | Principal PDM Manager