Usare Firewall di Azure per instradare una topologia multi gruppo a ruota

La topologia hub-spoke è un modello di architettura di rete comune in Azure che consolida le risorse di rete e centralizza i servizi di rete. Questa topologia fornisce connettività di rete e sicurezza alle reti virtuali distribuite tra sottoscrizioni o tenant diversi.

È possibile implementare architetture hub-spoke in due modi:

• Gruppo a ruota autogestito (tradizionale): mantenere il controllo completo sulle reti virtuali dell'hub e sulla configurazione del routing dell'hub.
• Rete WAN virtuale: Microsoft gestisce le reti virtuali hub e semplifica l'amministrazione tramite funzionalità come finalità di routing e criteri di routing.

Questo articolo è incentrato sulle topologie hub-and-spoke autogestite in cui si ha visibilità e controllo completi sulla rete virtuale hub e sulla distribuzione di Firewall di Azure.

È possibile ridurre il sovraccarico amministrativo di un'implementazione hub-spoke autogestito usando gestione rete virtuale di Azure (AVNM). AVNM può automatizzare la configurazione delle tabelle di instradamento, ma il design complessivo e le tecniche non cambiano rispetto all'approccio manuale. Il contenuto di questo articolo si applica a prescindere dal fatto che utilizziate AVNM o configuriate manualmente la topologia hub-and-spoke automatica.

Un'alternativa alle tabelle di routing nelle reti virtuali spoke consiste nell'iniettare rotte nelle subnet con Server di route Azure, come documentato in Iniezione della route predefinita nelle reti virtuali spoke. Tuttavia, questo schema non è comunemente utilizzato a causa della complessità che può derivare dalle interazioni tra Server di route Azure e gateway virtuali di rete VPN o ExpressRoute.

In una configurazione hub-and-spoke autogestita

• Hub: una rete virtuale che funge da punto di connettività centrale alla rete aziendale locale tramite VPN, ExpressRoute o Software-Defined Wide Area Network (SD-WAN). Si implementano dispositivi di sicurezza di rete, come firewall, nella rete virtuale dell'hub.
• Spoke: reti virtuali che effettuano il peering con l'hub e ospitano i carichi di lavoro.

Per carichi di lavoro diffusi su più regioni, in genere si distribuisce un hub per ogni regione per aggregare il traffico dagli endpoint in quella regione. Il diagramma seguente illustra un'architettura hub-and-spoke autogestita a due regioni con due reti virtuali spoke in ciascuna regione.

Architettura gruppo a ruota a singola regione

Per comprendere la progettazione in più aree, è prima necessario comprendere i concetti relativi alla singola area. Il diagramma seguente illustra la configurazione della tabella di routing per la prima area:

Prendere in considerazione i requisiti di routing per ogni potenziale flusso di traffico nella progettazione a singola area per comprendere la configurazione della route definita dall'utente:

• Traffico da spoke a spoke: gli spoke non sono associati tra loro e il peering di reti virtuali non è di tipo transitivo. Ogni spoke, per impostazione predefinita, sa come instradare verso la rete virtuale dell'hub, ma non verso altri spoke. Una route per 0.0.0.0/0 applicata a tutte le subnet degli spoke copre il traffico da spoke a spoke.
• Traffico dal spoke a Internet: La 0.0.0.0/0 route nella tabella delle route dello spoke indirizza il traffico destinato a Internet pubblico ad Firewall di Azure. In una sottorete non privata che ha accesso in uscita predefinito, la rotta definita dall'utente sovrascrive la rotta predefinita del sistema Internet. Le nuove reti virtuali create utilizzando versioni API rilasciate dopo il 31 marzo 2026 utilizzano di default subnet private e richiedono un metodo outbound esplicito. In questo design, Firewall di Azure fornisce connettività in uscita esplicita. Per altre informazioni, vedere Accesso in uscita predefinito in Azure.
• Traffico da Internet a spoke: il traffico da Internet allo spoke passa in genere attraverso Firewall di Azure. Firewall di Azure include regole DNAT (Destination Network Address Translation) configurate, che converte anche l'indirizzo IP di origine (Source Network Address Translation o SNAT). I carichi di lavoro dello spoke vedono il traffico proveniente dalla subnet di Firewall di Azure. Il peering di reti virtuali crea le route di sistema all'hub (10.1.0.0/24), in modo che gli spoke sappiano come gestire l'instradamento del traffico di ritorno.
• Traffico da locale a spoke e da spoke a locale: prendere in considerazione ogni direzione separatamente:
  • Traffico da locale a spoke: il traffico arriva dalla rete locale ai gateway VPN o ExpressRoute. Con il routing predefinito in Azure, viene creata una route di sistema in GatewaySubnet (e altre subnet nella rete virtuale hub) per ogni spoke. È necessario eseguire l'override di queste route di sistema impostando l'hop successivo sull'indirizzo IP privato dell'Firewall di Azure. In questo esempio, sono necessari due percorsi in una tabella di route associata alla subnet del gateway, uno per ogni spoke (10.1.1.0/24 e 10.1.2.0/24). L'uso di un sommario, ad esempio 10.1.0.0/16, che include tutte le reti virtuali spoke, non è efficace perché le route di sistema iniettate dai peering di rete virtuale nella subnet del gateway sono più specifiche (/24 rispetto al sommario /16). Questa tabella di route deve avere l'impostazione Propagate gateway routes abilitata (impostata su Sì), altrimenti il routing del gateway può diventare imprevedibile.
  • Traffico da spoke a locale: i peering di rete virtuale tra l'hub e gli spoke devono avere Consentire transito tramite gateway abilitato sul lato hub e Usare gateway remoti abilitato sul lato spoke. Queste impostazioni sono necessarie in modo che i gateway VPN e ExpressRoute pubblicizzino i prefissi spoke tramite Border Gateway Protocol (BGP) alle reti locali. Queste impostazioni fanno sì che gli spoke apprendano, per impostazione predefinita, i prefissi annunciati dall'ambiente locale ad Azure. Poiché i prefissi on-premises sono più specifici della route definita dall'utente 0.0.0.0/0 nella tabella di route dello spoke, il traffico dagli spoke verso l'ambiente on-premises aggira il firewall per impostazione predefinita. Per evitare questa situazione, impostare l'interruttore Propagate gateway routes su No nella tabella di route dello spoke, in modo che i prefissi della rete locale non vengano appresi e la route 0.0.0.0/0 venga utilizzata per il traffico verso l'ambiente locale.

Note

Usare i prefissi IP della rete virtuale spoke esatti nella tabella di route associata alla subnet del gateway anziché un riepilogo di rete. Le route di sistema introdotte dai peering di rete virtuale con gli spoke sostituiscono la route definita dall'utente perché sono più specifiche.

Puoi gestire sia la tabella di route associata alle subnet spoke sia la tabella di route associata alla subnet gateway usando gestione rete virtuale di Azure per ridurre i costi amministrativi. Per altre informazioni, vedere Usare Firewall di Azure come hop successivo.

Carichi di lavoro della rete virtuale hub

La distribuzione di carichi di lavoro nella rete virtuale hub, come controller di dominio Active Directory, server DNS o altre infrastrutture condivise, aumenta la complessità dell'architettura hub-and-spoke. Evita di mettere i carichi di lavoro nell'hub. Invece, distribuiscili in uno spoke dedicato ai servizi condivisi.

Questa sezione descrive la configurazione necessaria per i carichi di lavoro dell'hub per valutare se questa complessità è accettabile per i requisiti. Viene inoltre descritto un errore comune che può causare traffico asimmetrico e perdite di pacchetti.

Il diagramma seguente illustra una progettazione a singola regione con una subnet di carico di lavoro nella rete virtuale hub:

Il dettaglio fondamentale è che le route definite dall'utente configurate sia nella subnet del gateway che nelle subnet degli spoke sono definite in base alla subnet specifica del carico di lavoro e non per l'intero prefisso della rete virtuale hub:

• Configurazione della subnet del gateway: la configurazione di una route nella subnet del gateway per l'intera rete virtuale hub (10.1.0.0/24 in questo esempio) sostituisce la route di sistema per la rete virtuale hub. Ciò causa l'invio del traffico di controllo intra-subnet tra i gateway VPN o ExpressRoute al firewall, potenzialmente interrompendo le operazioni dei gateway.
• Configurazione della subnet spoke: la configurazione di una route nelle subnet spoke per l'intera rete virtuale hub (10.1.0.0/24 in questo esempio) sostituisce la route di sistema creata dal peering con la rete virtuale hub. Tutto il traffico inviato all'hub verrebbe inviato a Firewall di Azure, incluso il traffico proveniente da Firewall di Azure stesso, ad esempio il traffico internet-spoke che passa attraverso SNAT (Source Network Address Translation). Questa configurazione introduce il traffico asimmetrico e causa l'eliminazione di pacchetti.

Note

Se si distribuiscono carichi di lavoro nella rete virtuale hub, non usare l'intero prefisso IP della rete virtuale nelle route definite dall'utente.

Ispezione del traffico tra subnet

Nella configurazione attuale, il firewall gestisce il traffico tra i raggi, ma il traffico intra-spoke rimane all'interno della rete virtuale spoke, dove lo si controlla usando gruppi di sicurezza di rete. Questa progettazione considera le reti virtuali come limite di sicurezza: il firewall controlla solo il traffico che esce o entra in una rete virtuale.

Per esaminare il traffico tra subnet nella stessa rete virtuale spoke, modificare la tabella di route associata alle subnet spoke, come illustrato nel diagramma seguente:

Nel diagramma precedente vengono introdotte due subnet spoke in ogni rete virtuale spoke e vengono descritte le tabelle di route per gli spoke nella rete virtuale A2. L'invio di traffico tra subnet al firewall richiede che ogni subnet disponga di una tabella di route separata perché le route da installare in ogni subnet sono diverse.

Per la subnet A21 sono necessarie queste due route aggiuntive:

• Route a 10.1.2.0/24: esegue l'override della route di sistema per il traffico di rete all'interno della rete virtuale. Senza altre route, tutto il traffico di rete all'interno della rete virtuale viene inviato a Firewall di Azure, anche il traffico tra macchine virtuali nella stessa subnet.
• Route a 10.1.2.0/26 con hop successivo rete virtuale: un'eccezione alla route precedente, quindi il traffico all'interno di questa subnet specifica non viene inviato al firewall ma viene instradato localmente all'interno della rete virtuale. Questa route è specifica per ogni subnet, motivo per cui è necessaria una tabella di route separata per ogni subnet.

SD-WAN dispositivi virtuali di rete

Se si usano le appliance virtuali di rete SD-WAN anziché i gateway VPN o ExpressRoute, la configurazione è simile, come illustrato nel diagramma seguente.

Puoi integrare SD-WAN NVA in Azure in modi diversi. Per ulteriori informazioni, vedere integrazione SD-WAN con le topologie di rete hub-and-spoke di Azure. Questo articolo mostra l'integrazione che utilizza Server di route Azure, uno dei metodi più comuni per instradare il traffico verso SD-WAN reti. I SD-WAN NVA pubblicizzano i prefissi on-premises di Server di route Azure tramite BGP. Il server di route di Azure inserisce questi prefissi nella subnet di Firewall di Azure in modo che Firewall di Azure disponga delle informazioni di routing per le reti locali. Gli spoke non apprendono i prefissi on-premise perché l'opzione "Propagare le route del gateway" è disabilitata nella tabella di route degli spoke.

Se non si desidera configurare il prefisso di ogni rete virtuale spoke nella tabella di route associata alla subnet dell'NVA, è possibile posizionare le NVA SD-WAN nella loro rete virtuale dedicata. La rete virtuale NVA non apprende i prefissi spoke perché non sono direttamente connessi tramite peering e una route riassuntiva è possibile come illustrato nel diagramma seguente.

Architettura di gruppo a ruota multi-area

Dopo aver compreso il funzionamento del traffico all'interno di una singola area hub-spoke, l'estensione della progettazione a un'architettura in più aree è semplice. Il diagramma seguente mostra una progettazione di rete aggiornata con hub in due aree (A e B):

L'unica aggiunta alla configurazione è rappresentato dalle tabelle di route associate alle subnet di Firewall di Azure in ogni area. Ogni rete virtuale hub conosce solo i prefissi delle reti virtuali con peering diretto, quindi non esiste alcun routing per i prefissi degli spoke remoti. Aggiungere route definite dall'utente per ogni subnet di Firewall di Azure in modo che il traffico per ogni area venga instradato al firewall di Azure corrispondente.

In questo esempio ogni area può essere riepilogata facilmente:

• Region A contiene prefissi in 10.1.0.0/16
• L'area B contiene prefissi in 10.2.0.0/16

Definire indirizzi IP nelle varie regioni che possono essere facilmente aggregati semplifica la configurazione del routing. In caso contrario, è necessario creare una rotta per ogni spoke remoto.

Abilitare Propagare le route del gateway nella tabella delle route della subnet del firewall di Azure in modo che il firewall possa apprendere le route locali dai gateway VPN ed ExpressRoute.

Note

Se Firewall di Azure viene distribuito senza scheda di interfaccia di rete di gestione, la subnet di Firewall di Azure richiede una route predefinita con hop successivo "Internet" per aggiungere route più specifiche, come descritto in precedenza.

Per semplificare la gestione delle route definite dall'utente in un ambiente con più aree, è possibile usare Gestione rete virtuale di Azure. Per altre informazioni, vedere Gestire le route definite dall'utente tra più topologie di gruppo a ruota con AVNM.

Passaggi successivi

• Informazioni su come distribuire e configurare Firewall di Azure.