Il Virtual Network Peering (VNet Peering) permette di collegare tra loro due Virtual Network (VNet) Azure, consentendo alle risorse presenti nelle diverse reti di comunicare utilizzando indirizzi IP privati.
Il traffico tra VNet collegate tramite peering rimane sulla rete privata Microsoft (Microsoft backbone) e non transita attraverso Internet pubblico.
Azure supporta due principali tipologie di Virtual Network Peering:
- Regional Virtual Network Peering
- Global Virtual Network Peering
Regional Virtual Network Peering
Il Regional Virtual Network Peering permette di collegare due Virtual Network che si trovano nella stessa regione Azure.
Ad esempio:
VNet-A – West Europe ↔ VNet-B – West Europe
Le due VNet possono appartenere anche a subscription Azure differenti.
Global Virtual Network Peering
Il Global Virtual Network Peering permette di collegare Virtual Network situate in regioni Azure differenti supportate.
Ad esempio:
VNet-A – West Europe ↔ VNet-B – North Europe
Anche in questo caso il traffico tra le reti utilizza il backbone privato Microsoft e non Internet pubblico.
Il Global VNet Peering è disponibile tra regioni supportate, tenendo conto delle limitazioni esistenti tra Azure Public Cloud e i cloud nazionali o sovrani.
Peering tra subscription
Il Virtual Network Peering può essere configurato anche tra VNet appartenenti a subscription Azure differenti.
A seconda dello scenario, le subscription possono inoltre appartenere a tenant Microsoft Entra differenti, purché siano configurati correttamente i permessi necessari per creare il peering.
Il VNet Peering non è transitivo
Una caratteristica molto importante del Virtual Network Peering è che il peering non è transitivo.
Consideriamo questo scenario:
VNet A ↔ HUB ↔ VNet B
VNet A è collegata tramite peering all’Hub e VNet B è anch’essa collegata tramite peering all’Hub.
Questo non significa automaticamente che VNet A possa comunicare con VNet B.
Il peering:
VNet A ↔ HUB
non rende transitivo il peering:
HUB ↔ VNet B
Per permettere la comunicazione tra gli spoke è necessario progettare opportunamente il routing, ad esempio utilizzando una Network Virtual Appliance (NVA), Azure Firewall, un gateway oppure, quando appropriato, creando un peering diretto tra le VNet.
Gateway Transit
Il Gateway Transit permette a una Virtual Network collegata tramite peering di utilizzare il Virtual Network Gateway presente in un’altra VNet.
È una configurazione particolarmente utilizzata nelle architetture Hub & Spoke.
Consideriamo tre Virtual Network:
- Hub VNet
- Spoke VNet A
- Spoke VNet B
Le due VNet spoke sono collegate tramite peering alla VNet Hub.
La VNet Hub contiene una subnet dedicata:
GatewaySubnet
all’interno della quale è distribuito un Azure VPN Gateway.
Grazie al Gateway Transit, gli spoke possono utilizzare il VPN Gateway presente nell’Hub senza dover distribuire un gateway in ogni singola VNet.
Configurazione del Gateway Transit
La configurazione viene effettuata sui due lati del peering.
Sul peering:
Hub → Spoke
deve essere abilitata l’opzione:
Allow gateway transit
Sul peering:
Spoke → Hub
deve essere abilitata l’opzione:
Use remote gateways
In questo modo lo spoke può utilizzare il Virtual Network Gateway presente nell’Hub.
Un solo VPN Gateway per Virtual Network
Una Virtual Network può avere un solo Azure VPN Gateway.
Inoltre, una VNet configurata per utilizzare il gateway remoto attraverso l’opzione Use remote gateways non può contemporaneamente utilizzare un proprio Virtual Network Gateway.
In una tipica architettura Hub & Spoke avremo quindi:
Hub VNet → VPN Gateway
Spoke VNet → Use Remote Gateway
Gli spoke condividono quindi il gateway presente nell’Hub.
Gateway Transit con Regional e Global Peering
Il Gateway Transit è supportato sia con Regional Virtual Network Peering sia con Global Virtual Network Peering.
Questo permette di realizzare architetture Hub & Spoke anche quando le Virtual Network si trovano in regioni Azure differenti, nel rispetto delle funzionalità e delle limitazioni previste dal servizio.
Accesso alle reti esterne tramite Gateway Transit
Quando il Gateway Transit è abilitato, una VNet può utilizzare il gateway della VNet in peering per raggiungere reti esterne.
Uno degli scenari più comuni è la connessione con una rete aziendale on-premises.
Ad esempio:
Rete On-Premises → Site-to-Site VPN → VPN Gateway della Hub VNet → VNet Peering → Spoke VNet
Una VM presente nella Spoke VNet può quindi raggiungere la rete on-premises sfruttando il VPN Gateway presente nell’Hub.
Il gateway può essere utilizzato per diversi tipi di connettività, tra cui:
- Site-to-Site VPN (S2S) per collegare reti on-premises;
- Point-to-Site VPN (P2S) per consentire l’accesso a client remoti;
- VNet-to-VNet per collegare Virtual Network attraverso VPN Gateway.
Esempio di architettura Hub & Spoke
Una configurazione tipica può essere rappresentata in questo modo:
In questa architettura l’Hub centralizza i servizi di connettività, mentre gli spoke ospitano workload e applicazioni.
Il modello consente di evitare la distribuzione di un VPN Gateway in ogni singola VNet e permette di centralizzare maggiormente la gestione della connettività.
In sintesi
Il Virtual Network Peering consente di collegare Virtual Network Azure attraverso il backbone privato Microsoft.
Il Regional Peering collega VNet nella stessa regione, mentre il Global Peering permette di collegare VNet situate in regioni differenti supportate.
Il peering non è transitivo: due VNet collegate alla stessa Hub VNet non possono automaticamente comunicare tra loro.
Il Gateway Transit permette invece alle VNet spoke di utilizzare il Virtual Network Gateway presente nell’Hub.
Questa combinazione costituisce uno degli elementi fondamentali delle architetture di rete Hub & Spoke in Microsoft Azure.
Documentazione Microsoft
Microsoft Learn – Virtual Network Peering Overview
https://learn.microsoft.com/azure/virtual-network/virtual-network-peering-overview
Microsoft Learn – Configure VPN Gateway Transit for Virtual Network Peering
https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-peering-gateway-transit