VNet peering

Il VNet peering collega due virtual network facendo viaggiare il traffico sulla backbone Microsoft: bassa latenza, banda elevata, nessun passaggio da Internet o da un gateway. Si distinguono il regional peering (stessa region) e il global peering (region diverse). I vincoli da memorizzare: gli address space non si devono sovrapporre, il peering va creato su entrambi i lati (finché un lato manca lo stato resta Initiated invece di Connected) e, punto cruciale, il peering non è transitivo. Se la VNet A è in peering con B e B con C, A non raggiunge C passando per B. Questa singola proprietà spiega perché esistono hub-and-spoke, user-defined routes e Virtual WAN.

Contano anche le opzioni per-peering: Allow forwarded traffic consente il transito di pacchetti non originati dalla VNet remota (indispensabile quando un NVA inoltra traffico), mentre Allow gateway transit e Use remote gateways abilitano il gateway transit.

Hub-and-spoke

La topologia hub-and-spoke centralizza nel hub i servizi condivisi — Azure Firewall o un NVA, il VPN/ExpressRoute gateway, il DNS — mentre gli spoke ospitano i workload isolati. Ogni spoke è in peering con il hub, ma gli spoke non sono in peering tra loro. Per la non-transitività il traffico est-ovest spoke-to-spoke non è automatico: va instradato attraverso il hub tramite un NVA/Azure Firewall e delle user-defined routes, oppure con un peering diretto spoke-to-spoke (che però non scala e perde l’ispezione centralizzata). Il pregio del modello è il controllo: policy di sicurezza, logging e connettività ibrida vivono in un unico punto.

User-defined routes e gateway transit

Le user-defined routes (UDR) sono route table associate a subnet che sovrascrivono le route di sistema. Servono soprattutto a forzare il traffico verso un’appliance: si crea una route (es. 0.0.0.0/0 o il prefisso dello spoke remoto) con next hop Virtual appliance puntando all’IP privato dell’NVA/firewall nel hub. I next hop possibili sono Virtual appliance, Virtual network gateway, Virtual network, Internet e None. Con prefissi in conflitto vince il longest prefix match; a parità di prefisso la precedenza è UDR > BGP > route di sistema.

Il gateway transit permette a uno spoke di usare il gateway (VPN o ExpressRoute) che risiede nel hub per raggiungere l’on-premises, evitando un gateway per ogni spoke. Si abilita con Allow gateway transit sul peering lato hub e Use remote gateways sul peering lato spoke. Attenzione: lo spoke non può avere un proprio gateway se usa quello remoto, e le due opzioni vanno impostate in modo coerente sui due lati.

Virtual WAN

Azure Virtual WAN sostituisce il hub self-managed con un hub gestito da Microsoft che fornisce routing transitivo automatico tra VNet, sedi branch (VPN site-to-site), utenti (point-to-site) ed ExpressRoute — connettività any-to-any senza costruire manualmente peering e UDR. Il SKU Standard abilita transito inter-hub, ExpressRoute e le funzioni avanzate; il Basic supporta solo VPN site-to-site. Il secured virtual hub aggiunge Azure Firewall (gestito via Firewall Manager) dentro l’hub per l’ispezione centralizzata. Si sceglie Virtual WAN quando servono scala globale, molti hub o si vuole ridurre l’onere operativo; si resta sull’hub-and-spoke tradizionale quando serve controllo fine sul routing o l’ambiente è piccolo e in una sola region.

Trappole tipiche d’esame

  • Due spoke devono comunicare tra loro → NVA/Azure Firewall nel hub + UDR: il peering non è transitivo, quindi un peering spoke-hub non basta; serve una route con next hop virtual appliance (oppure Virtual WAN, che è transitivo di suo).
  • Spoke deve raggiungere l’on-premises tramite il gateway del hub → gateway transit: Allow gateway transit sul hub e Use remote gateways sullo spoke; lo spoke non deve avere un gateway proprio.
  • Un NVA inoltra traffico ma i pacchetti vengono scartati → Allow forwarded traffic: senza questa opzione sul peering, il traffico non originato dalla VNet remota non transita.
  • Serve connettività transitiva globale con minimo overhead → Virtual WAN Standard: il routing hub-spoke è automatico; l’hub-and-spoke classico richiederebbe UDR e peering manuali.
  • Address space sovrapposti tra due VNet → peering impossibile: il peering esige range non sovrapposti; va ri-indirizzata una delle due VNet, non esiste un override.
  • Peering resta in stato Initiated → configurare entrambi i lati: diventa Connected solo quando è creato su tutte e due le VNet; ricorda che il passing score dell’esame è 700/1000, quindi questi dettagli operativi contano.