Il VPN gateway in Azure

Il VPN gateway è un tipo specifico di virtual network gateway (gatewayType Vpn, distinto da quello ExpressRoute) che stabilisce tunnel cifrati IPsec/IKE tra una virtual network e reti esterne, attraversando la rete pubblica. Va sempre distribuito in una subnet dedicata, la GatewaySubnet, e ogni VNet può avere un solo VPN gateway. Il deployment richiede tempi non trascurabili, quindi nell’esame le scelte di dimensionamento contano più della procedura.

Una distinzione fondamentale è tra VPN policy-based e route-based. La policy-based (routing statico) è legata alla sola SKU Basic, supporta un unico tunnel site-to-site e non offre né point-to-site né BGP: serve solo per interoperare con vecchi device che non gestiscono selettori di traffico dinamici. La route-based è lo standard moderno e abilita multi-site, point-to-site, BGP e coesistenza con ExpressRoute.

Connessioni site-to-site

La connessione site-to-site (S2S) collega un’intera rete on-premises alla VNet via IPsec/IKE (IKEv1 o IKEv2). Richiede tre elementi coordinati: un VPN device on-premises con un IP pubblico, un local network gateway in Azure che rappresenta la rete remota (IP pubblico del device più i suoi address space), e la connection che li lega con una pre-shared key. Con una SKU route-based si possono attestare più tunnel S2S verso sedi diverse (configurazione multi-site). Un caso correlato è la VNet-to-VNet, che usa lo stesso meccanismo per collegare due virtual network.

Connessioni point-to-site

La point-to-site (P2S) collega singoli client (laptop, workstation) direttamente alla VNet senza alcun device VPN on-premises: è la scelta per smart working o per un numero contenuto di utenti. I protocolli disponibili sono OpenVPN (SSL/TLS, cross-platform), IKEv2 (IPsec nativo, cross-platform) e SSTP (SSL, solo Windows). L’autenticazione può basarsi su certificati generati in Azure, su un server RADIUS, oppure su Microsoft Entra ID. È necessario definire un client address pool da cui i client ricevono l’indirizzo.

BGP e routing dinamico

BGP consente lo scambio dinamico delle rotte tra on-premises e Azure, evitando di dichiarare manualmente ogni address space nel local network gateway: le reti si propagano da sole e restano allineate quando cambiano. Ogni VPN gateway espone un ASN (default 65515) e, negli scenari active-active, usa indirizzi APIPA per i BGP peer. BGP è il prerequisito per il transit routing, per la propagazione automatica delle rotte e per le configurazioni active-active ad alta disponibilità. Richiede una VPN route-based e una SKU diversa da Basic.

Scelta della gateway SKU

La SKU si sceglie in base a criteri misurabili: throughput aggregato richiesto, numero di tunnel S2S, numero di connessioni P2S concorrenti, supporto a BGP, supporto ad active-active, zone-redundancy e livello di SLA. La Basic è legacy (policy-based o route-based limitata, circa 100 Mbps, niente BGP né active-active) e va evitata nei nuovi deployment. Le famiglie VpnGw1-5 scalano throughput e connessioni; le varianti con suffisso AZ (VpnGw1AZ-5AZ) aggiungono la ridondanza di zona. Va inoltre considerata la gateway generation (Generation1 vs Generation2), poiché non tutte le SKU sono disponibili in entrambe. L’active-active richiede due IP pubblici sul gateway.

Trappole tipiche d’esame

  • Device on-premises datato che non supporta selettori dinamici → policy-based su SKU Basic: è l’unico caso in cui usare policy-based, ma resta limitato a un solo tunnel S2S e senza BGP né P2S; per più sedi serve comunque route-based.
  • Serve BGP o active-active → mai SKU Basic: Basic non supporta BGP né active-active; scegli una VpnGw route-based.
  • Autenticazione P2S con Microsoft Entra ID → solo OpenVPN: l’autenticazione Entra ID non funziona con SSTP o IKEv2; se il requisito impone Entra ID il protocollo deve essere OpenVPN.
  • Molti client Windows via SSTP → attenzione al limite di 128 connessioni: SSTP tollera al massimo 128 connessioni concorrenti; per numeri maggiori orientati su OpenVPN o IKEv2.
  • Requisito di resilienza a livello di zona → SKU con suffisso AZ: la zone-redundancy si ottiene solo con le SKU AZ, non aumentando genericamente il tier.
  • Molte sedi con subnet che cambiano nel tempo → BGP + route-based: evita la manutenzione manuale degli address space nel local network gateway e riduce il rischio di rotte disallineate.