• Cloud, Guide, Sicurezza
• 12 Novembre 2026

Proteggere un’applicazione in cloud significa spesso far passare il traffico da firewall, sistemi IDS/IPS o altre appliance di sicurezza. In pratica, però, inserirle nel percorso dei dati è tutt’altro che semplice: servono route personalizzate (UDR), si rischiano indirizzi IP modificati dal NAT, ogni nuova applicazione richiede interventi sulla rete e la scalabilità e l’alta disponibilità delle appliance diventano un problema da gestire a parte.

Azure Gateway Load Balancer risolve questo problema in modo elegante. Invece di bilanciare il traffico tra i server applicativi, lo distribuisce tra più Network Virtual Appliance (NVA), inserendole nel flusso in modo trasparente: le applicazioni non vengono modificate, gli indirizzi IP dei client restano invariati e le appliance possono essere aggiunte o sostituite senza interrompere il servizio. Grazie al Service Chaining, basta collegarlo al frontend di un Public Load Balancer esistente per far passare il traffico dalle appliance.

Il vero valore di questa risorsa sta nel separare i servizi di sicurezza dalle applicazioni: il team di rete può gestire e far evolvere le NVA in modo centralizzato, mentre i team applicativi continuano a pubblicare i propri servizi come sempre. Il tutto con i vantaggi di un load balancer: alta disponibilità, controlli di integrità e simmetria del traffico, requisito indispensabile per i firewall stateful.

Architettura di Azure Gateway Load Balancer

L’architettura di Azure Gateway Load Balancer prevede la separazione tra le risorse che ospitano le applicazioni e quelle dedicate all’elaborazione del traffico di rete.

Come mostrato nella figura 1, le applicazioni possono risiedere in diverse reti virtuali, mentre le Network Virtual Appliance vengono distribuite in una rete virtuale dedicata. Attraverso il Service Chaining, il traffico destinato alle applicazioni viene indirizzato al Gateway Load Balancer, che lo distribuisce alle appliance disponibili.

Le NVA possono quindi analizzare, filtrare o elaborare i pacchetti e, se il traffico viene autorizzato, inoltrarlo verso la destinazione originale. Questo meccanismo permette di centralizzare le funzionalità di sicurezza e ispezione, mantenendo separate le risorse applicative da quelle dedicate ai servizi di rete.

Nell’architettura rappresentata, il traffico web in ingresso viene intercettato prima di raggiungere l’applicazione, inviato a una delle NVA e successivamente restituito al percorso di rete per essere consegnato ai server di destinazione.

Un altro aspetto importante è la simmetria del traffico: Gateway Load Balancer assicura che i pacchetti appartenenti alla stessa connessione attraversino la medesima appliance anche nel percorso di ritorno, caratteristica fondamentale per il corretto funzionamento dei firewall stateful.

Figura 1: Architettura di Azure Gateway Load Balancer con Service Chaining e Network Virtual Appliance per l’ispezione del traffico applicativo

Creazione della rete virtuale

Per prima cosa dobbiamo creare la rete virtuale che ospiterà le macchine virtuali e il Load Balancer. Colleghiamoci al portale di Microsoft Azure all’indirizzo https://portal.azure.com e, dalla sezione Network foundation, selezioniamo Virtual networks. Facciamo quindi clic sul pulsante Create per avviare la procedura di creazione di una nuova rete virtuale.

Figura 2: Avvio della creazione di una nuova rete virtuale dal portale di Microsoft Azure

Nella scheda Basics selezionatela sottoscrizione Azure che vogliamo utilizzare e creiamo un nuovo Resource Group denominato IntLB-RG, nel quale verranno raggruppate le risorse necessarie per la nostra infrastruttura.

Assegnate alla rete virtuale il nome IntLB-VNet e selezionate Italy North come Region. In questo modo tutte le risorse che creeremo successivamente potranno essere distribuite nella stessa area geografica.

Figura 3: Configurazione delle impostazioni di base della rete virtuale IntLB-VNet

Nella scheda Security potete configurare alcune funzionalità aggiuntive per migliorare la sicurezza della rete virtuale. Per questa esercitazione lasciate disabilitata l’opzione Virtual network encryption e abilitate Azure Bastion, che vi permetterà di collegarvi alle macchine virtuali tramite RDP direttamente dal portale Azure, senza dover assegnare loro un indirizzo IP pubblico.

Assegnate al servizio Bastion il nome IntLB-VNet-Bastion e create un nuovo indirizzo IP pubblico denominato intlb-vnet-bastion.

Figura 4: Configurazione di Azure Bastion per l’accesso sicuro alle macchine virtuali

Nella scheda IP addresses configurate lo spazio di indirizzamento della rete virtuale, utilizzando la rete 10.0.0.0/16. Create quindi una subnet denominata MyBackendSubnet, alla quale assegnate l’intervallo di indirizzi 10.0.2.0/24.

Questa subnet verrà utilizzata per ospitare le macchine virtuali che fungeranno da server di backend del Load Balancer. La separazione delle risorse in subnet differenti permetterà di organizzare meglio l’infrastruttura di rete e di isolare logicamente i server che ospiteranno il servizio web.

Lasciate le altre impostazioni ai valori predefiniti e fate clic su Add per confermare la configurazione.

Figura 5: Configurazione dello spazio di indirizzamento IP e della subnet MyBackendSubnet

Dopo aver configurato la subnet destinata ai server web, creiamo una seconda subnet che utilizzeremo per ospitare le Network Virtual Appliance (NVA).

Nella scheda Address space fate clic su Add a subnet e assegnate alla nuova subnet il nome MyNVASubnet. Configurate l’intervallo di indirizzi 10.0.3.0/24, appartenente allo spazio di indirizzamento della rete virtuale 10.0.0.0/16.

Questa subnet ospiterà le due macchine virtuali MyNVA1 e MyNVA2, che utilizzeremo per simulare le appliance di rete associate ad Azure Gateway Load Balancer.

Mantenete le altre impostazioni ai valori predefiniti, inclusa l’opzione Enable private subnet (no default outbound access), e fate clic su Add per confermare la configurazione.

Figura 6: Creazione della subnet MyNVASubnet dedicata alle Network Virtual Appliance

Figura 7: Riepilogo dello spazio di indirizzamento e delle subnet configurate nella rete virtuale

Dopo aver configurato le subnet, selezionate Review + create e verificate il riepilogo delle impostazioni della rete virtuale IntLB-VNet.

Come potete osservare, abbiamo predisposto una subnet per i server applicativi (myBackendSubnet, 10.0.2.0/24) e una dedicata alle Network Virtual Appliance (MyNVASubnet, 10.0.3.0/24). Abbiamo inoltre abilitato Azure Bastion per consentire l’accesso sicuro alle macchine virtuali.

Una volta completata la validazione, fate clic su Create per avviare la distribuzione della rete virtuale.

Figura 8: Schermata finale del riepilogo della creazione della VNET

Verifica della distribuzione della rete virtuale

Attendete il completamento della distribuzione della rete virtuale e, dal portale Azure, aprite la risorsa IntLB-VNet appena creata. Nella sezione Settings, selezionate Subnets e fate clic sulla subnet MyBackendSubnet per modificarne la configurazione.

Verificate che l’opzione Enable private network (no default outbound access) sia disabilitata. Questa impostazione consente di non escludere a livello di subnet il meccanismo di accesso in uscita predefinito di Azure. Ricordate tuttavia che la connettività Internet delle macchine virtuali non è garantita da questa impostazione, soprattutto quando i server vengono associati al backend pool di uno Standard Load Balancer.

Fate clic su Save per confermare le impostazioni.

Figura 9: Verifica delle impostazioni di connettività in uscita della subnet MyBackendSubnet

Creazione delle macchine virtuali di backend

Dopo aver configurato la rete virtuale, procedete con la creazione delle tre macchine virtuali Windows Server che utilizzeremo come server di backend del Load Balancer.

Per velocizzare la distribuzione dell’infrastruttura, utilizzate un template ARM, che vi permetterà di creare le tre macchine virtuali con una configurazione omogenea, collegandole alla subnet MyBackendSubnet della rete virtuale IntLB-VNet.

Una volta completata la distribuzione, installate su ciascuna macchina virtuale il ruolo Web Server (IIS), che utilizzeremo per pubblicare una semplice pagina web e verificare successivamente la distribuzione del traffico da parte del Load Balancer.

Figura 10: Creazione delle tre macchine virtuali Windows Server che costituiranno il backend del Load Balancer

Figura 11: Risorse create e verifica delle tre macchine virtuali che costituiranno il backend pool del Load Balancer

Al termine della distribuzione, accedete alla sezione Virtual machines del portale Azure e verificate che le tre macchine virtuali siano state create correttamente e che il loro stato sia Running.

Le macchine virtuali MyVM1, MyVM2 e MyVM3 costituiranno il backend pool del Load Balancer, ovvero il gruppo di server tra i quali verranno distribuite le richieste dei client.

Verificate inoltre che tutte e tre le macchine virtuali siano collegate alla subnet MyBackendSubnet e che dispongano di un indirizzo IP privato.

Creazione di Azure Public Load Balancer

Dopo aver predisposto le macchine virtuali che ospiteranno il servizio web, possiamo procedere con la creazione del Load Balancer, che si occuperà di distribuire il traffico tra i tre server di backend.

Dal portale di Microsoft Azure, accedete alla sezione Load balancing and content delivery e selezionate Load balancers. Fate quindi clic su Create e scegliete Standard Load balancer.

Utilizzeremo lo SKU Standard, che offre funzionalità avanzate di bilanciamento del carico, supporto alle Availability Zone e una maggiore flessibilità nella configurazione delle regole di distribuzione del traffico. La SKU Basic è stata ritirata il 30 settembre 2025.

Figura 12: Avvio della creazione di un Azure Standard Load Balancer

Nella scheda Basics selezionate la sottoscrizione Azure che volete utilizzare e create un nuovo Resource Group denominato ExtLB-RG.

Assegnate al Load Balancer il nome myExtLoadBalancer e selezionate Italy North come Region. Mantenete lo SKU Standard e scegliete Public come tipologia di Load Balancer, lasciando selezionata l’opzione Regional.

Figura 13: Configurazione delle impostazioni di base di Azure Public Load Balancer

Nella scheda Frontend IP configuration fate clic su Add a frontend IP configuration per configurare l’indirizzo IP pubblico attraverso il quale il Load Balancer riceverà le richieste provenienti da Internet.

Assegnate alla configurazione il nome myExtLoadBalancer, selezionate IPv4 come versione IP e mantenete IP address come tipologia. Nel campo Public IP address fate clic su Create new per creare un nuovo indirizzo IP pubblico denominato myExtLoadBalancer-PIP.

Mantenete lo SKU Standard, il livello Regional e l’assegnazione Static, che garantirà al Load Balancer un indirizzo IP pubblico stabile. Selezionate Zone-redundant come Availability zone, per rendere l’indirizzo IP resiliente ai guasti di una singola zona di disponibilità, e lasciate Microsoft network come Routing preference.

Fate clic su Save per creare l’indirizzo IP pubblico.

Figura 14: Configurazione dell’indirizzo IP pubblico di frontend del Load Balancer

Dopo aver creato l’indirizzo IP pubblico myExtLoadBalancer-PIP, verificate che sia correttamente selezionato nel campo Public IP address.

Lasciate il campo Gateway Load balancer impostato su None per il momento.

Fate quindi clic su Save per confermare la configurazione e associare l’indirizzo IP pubblico al frontend del Load Balancer.

Figura 15: Frontend IP configuration

Una volta completata la configurazione, verificate che nella scheda Frontend IP configuration sia presente la voce LoadBalancerFrontEnd, associata a un indirizzo IP di tipo Dynamic.

L’indirizzo IP pubblico verrà assegnato automaticamente da Azure durante la creazione del Load Balancer e sarà utilizzato dai client per raggiungere il servizio web ospitato sulle macchine virtuali di backend.

Dopo aver verificato la correttezza delle impostazioni, selezionate Next: Backend pools per proseguire con la configurazione.

Figura 16: Verifica della configurazione IP di frontend dell’External Load Balancer

Nella scheda Backend pools fate clic su Add a backend pool per creare il gruppo di server ai quali il Load Balancer distribuirà il traffico in ingresso.

Il backend pool rappresenta l’insieme delle risorse che riceveranno le richieste inoltrate dal Load Balancer. Nel nostro caso sarà composto dalle tre macchine virtuali Windows Server sulle quali abbiamo precedentemente installato Internet Information Services (IIS).

La configurazione del backend pool permetterà al Load Balancer di identificare i server disponibili ai quali inoltrare le connessioni, in base alle regole di bilanciamento che definiremo successivamente.

Figura 17: Avvio della creazione del backend pool dell’External Load Balancer

Nella finestra Add backend pool assegnate al nuovo pool il nome myBackendPool e selezionate la rete virtuale IntLB-VNet, nella quale abbiamo precedentemente distribuito le macchine virtuali.

Come modalità di configurazione selezionate NIC, che permette di associare al backend pool le interfacce di rete delle macchine virtuali. Fate quindi clic su Add nella sezione IP configurations per selezionare i server che faranno parte del pool.

Nella finestra Add IP configurations to backend pool selezionate le tre macchine virtuali MyVM1, MyVM2 e MyVM3, che abbiamo precedentemente creato nella subnet MyBackendSubnet.

Per ciascuna macchina virtuale verrà utilizzata la relativa configurazione IP dell’interfaccia di rete (NIC), che consentirà al Load Balancer di inoltrare il traffico verso il server corrispondente.

Dopo aver selezionato tutte e tre le macchine virtuali, fate clic su Add per associarle al backend pool.

Figura 18: Configurazione del backend pool e selezione delle interfacce di rete delle macchine virtuali

Fate clic su Save per salvare la configurazione del backend pool.

Figura 19: Verifica delle tre macchine virtuali associate al backend pool myBackendPool

Dopo aver salvato la configurazione, verificate che nella scheda Backend pools sia presente il pool myBackendPool, associato alla rete virtuale IntLB-VNet e alle tre macchine virtuali myVM1, myVM2 e myVM3.

Selezionate quindi Next: Inbound rules per procedere con la creazione delle regole di bilanciamento.

Figura 20: Verifica del backend pool myBackendPool e delle tre macchine virtuali associate

Nella scheda Inbound rules fate clic su Add a load balancing rule per configurare la regola che permetterà al Load Balancer di distribuire le richieste dei client tra le tre macchine virtuali del backend pool.

Le Load balancing rules definiscono come il traffico ricevuto sull’indirizzo IP di frontend e su una determinata porta debba essere inoltrato ai server di backend. Nel nostro caso configureremo una regola per distribuire il traffico HTTP sulla porta TCP 80, utilizzata dal servizio IIS installato sulle macchine virtuali.

La regola utilizzerà anche un Health Probe per verificare quali server siano effettivamente disponibili e impedire l’inoltro di nuove connessioni verso quelli che non rispondono ai controlli di integrità.

Figura 21: Avvio della creazione di una regola di bilanciamento del traffico HTTP

Durante la creazione della regola di bilanciamento, configurate un Health Probe, che permetterà al Load Balancer di verificare periodicamente lo stato di disponibilità delle macchine virtuali presenti nel backend pool.

Create un nuovo Health Probe denominato myHealthProbe, selezionate il protocollo HTTP e impostate la porta 80, sulla quale è in ascolto il servizio IIS. Configurate inoltre il percorso /, che verrà utilizzato per verificare la risposta del server web.

Il Load Balancer eseguirà controlli periodici sui server e considererà disponibili quelli che restituiscono una risposta HTTP 200 (OK). Se una macchina virtuale non supera i controlli di integrità, il Load Balancer interromperà l’inoltro delle nuove connessioni verso quel server, continuando a distribuire il traffico tra quelli disponibili.

Confermate la configurazione dell’Health Probe per associarlo alla regola di bilanciamento.

Figura 22: Configurazione dell’Health Probe per verificare la disponibilità dei server web

Lasciate Session persistence impostato su None, in modo che le connessioni di uno stesso client non debbano necessariamente essere indirizzate alla stessa macchina virtuale. Mantenete il valore di Idle timeout a 15 minuti e lasciate disabilitate le opzioni High availability ports, Enable TCP Reset ed Enable Floating IP.

Fate infine clic su Save per salvare la regola di bilanciamento.

Figura 23: Configurazione della regola myHTTPRule per la distribuzione del traffico HTTP tra i server di backend

Dopo aver salvato la configurazione, verificate che nella scheda Inbound rules sia presente la regola myHTTPRule, associata all’indirizzo IP di frontend LoadBalancerFrontEnd e al backend pool myBackendPool.

La regola utilizzerà l’Health Probe myHealthProbe per verificare la disponibilità dei server e distribuire le nuove connessioni HTTP soltanto alle macchine virtuali che superano i controlli di integrità.

Non è necessario configurare regole Inbound NAT, perché in questo scenario vogliamo distribuire il traffico tra più server e non inoltrare le connessioni verso una specifica macchina virtuale.

Dopo aver verificato la configurazione, fate clic su Review + create per procedere con la creazione del Load Balancer.

Figura 24: Verifica della regola di bilanciamento HTTP e dell’Health Probe associato

Nella scheda Review + create verificate il riepilogo delle impostazioni configurate e assicuratevi che la validazione sia stata completata correttamente.

Se tutte le impostazioni sono corrette, fate clic su Create per avviare la distribuzione del Load Balancer e attendete il completamento dell’operazione.

Figura 25: Riepilogo e validazione della configurazione di Azure Public Load Balancer

Al termine della distribuzione, accedete alla risorsa myExtLoadBalancer e verificate nella pagina Overview che il Load Balancer sia stato creato correttamente.

Dal menu Settings potete accedere alle diverse sezioni di configurazione, tra cui Frontend IP configuration, Backend pools, Health probes e Load balancing rules, per verificare o modificare le impostazioni definite durante la creazione.

Figura 26: Verifica della creazione del Public Load Balancer myExtLoadBalancer nel portale Azure

Configurazione del Network Security Group

Prima di verificare il funzionamento del Public Load Balancer, dobbiamo assicurarci che il traffico HTTP proveniente da Internet possa raggiungere le macchine virtuali del backend pool.

Anche se il traffico arriva inizialmente al Load Balancer, le regole del Network Security Group (NSG) continuano a essere applicate alle macchine virtuali di destinazione. Il Load Balancer, infatti, mantiene l’indirizzo IP sorgente del client e modifica soltanto quello di destinazione, inoltrando la connessione al server selezionato.

Per questo motivo, è necessario autorizzare esplicitamente il traffico HTTP sulla porta TCP 80, altrimenti le richieste verrebbero bloccate dal Network Security Group, anche in presenza di una regola di bilanciamento correttamente configurata.

Dal portale Azure accedete alla sezione Network foundation, selezionate Network security groups e aprite il Network Security Group myNSG, associato alle macchine virtuali del backend pool. Aggiungete una inbound rule per permettere il traffico HTTP.

Figura 27: Accesso al Network Security Group myNSG per autorizzare il traffico HTTP verso i server di backend

Nota: Nel caso dell’Internal Load Balancer non è stato necessario creare una regola aggiuntiva perché i Network Security Group di Azure includono alcune regole di sicurezza predefinite. In particolare, la regola AllowVNetInBound, con priorità 65000, consente il traffico tra le risorse appartenenti alla stessa rete virtuale e alle reti incluse nel service tag VirtualNetwork. Per questo motivo, le richieste provenienti dalla macchina virtuale di test erano già autorizzate.

La regola predefinita AllowAzureLoadBalancerInBound, con priorità 65001, consente invece il traffico proveniente dal service tag AzureLoadBalancer, utilizzato per gli Health Probe, ma non autorizza automaticamente le connessioni applicative provenienti da Internet. Infine, la regola DenyAllInBound, con priorità 65500, blocca tutto il traffico in ingresso che non è stato esplicitamente autorizzato dalle regole precedenti.

Verifica del funzionamento del Public Load Balancer

Dopo aver configurato la regola di sicurezza sul Network Security Group, possiamo verificare il funzionamento del Public Load Balancer.

Aprite un browser da un computer connesso a Internet e digitate l’indirizzo IP pubblico associato al frontend del Load Balancer.

Come potete osservare, il servizio web è raggiungibile correttamente e la richiesta HTTP viene inoltrata a una delle macchine virtuali presenti nel backend pool. Nel mio caso ha risposto myVM1, come indicato dal nome visualizzato nella pagina.

Anche in questo scenario potete effettuare ulteriori richieste HTTP per verificare la distribuzione del traffico tra i server. Ricordate che Azure Load Balancer opera a livello 4 e utilizza un algoritmo di hashing per distribuire le connessioni; quindi, aggiornare ripetutamente la pagina non garantisce che venga selezionata una macchina virtuale diversa.

Il test conferma che il Public Load Balancer è raggiungibile da Internet e inoltra correttamente il traffico HTTP ai server del backend pool, senza che sia necessario assegnare un indirizzo IP pubblico alle singole macchine virtuali.

Figura 28: Verifica dell’accesso al servizio web tramite l’indirizzo IP pubblico del Load Balancer

Considerazioni sulla connettività in uscita

Un aspetto importante da considerare riguarda la connettività in uscita verso Internet delle macchine virtuali associate al backend pool di Azure Load Balancer.

La presenza di un indirizzo IP pubblico sul frontend del Load Balancer non significa necessariamente che le macchine virtuali possano utilizzare lo stesso indirizzo per accedere a Internet.

In particolare, quando una macchina virtuale viene associata al backend pool di uno Standard Load Balancer, Azure disabilita il meccanismo di Default Outbound Access, che in alcune configurazioni permette alle macchine virtuali prive di indirizzo IP pubblico di accedere a Internet.

Se i server del backend devono effettuare connessioni verso Internet, ad esempio per scaricare aggiornamenti o comunicare con servizi esterni, è quindi necessario prevedere una soluzione per la connettività in uscita, come Azure NAT Gateway oppure una configurazione esplicita di outbound access.

Azure NAT Gateway rappresenta una soluzione particolarmente indicata, perché permette alle macchine virtuali di una subnet di effettuare connessioni verso Internet utilizzando uno o più indirizzi IP pubblici dedicati, senza dover assegnare un indirizzo IP pubblico a ciascun server. Ne ho già parlato nella mia guida Azure NAT Gateway – Gestione del traffico in uscita dalle VM eseguite in Azure – ICT Power

È quindi importante distinguere il bilanciamento del traffico in ingresso, che abbiamo configurato in questa esercitazione, dalla gestione delle connessioni in uscita, che richiede una configurazione specifica.

Creazione delle Network Virtual Appliance (NVA)

Dopo aver verificato il corretto funzionamento del Public Load Balancer, possiamo procedere con la creazione delle due Network Virtual Appliance (NVA) che utilizzeremo per configurare Azure Gateway Load Balancer.

Per velocizzare la preparazione dell’ambiente di laboratorio, ho utilizzato un template ARM che permette di distribuire automaticamente due macchine virtuali Linux, denominate MyNVA1 e MyNVA2, nella subnet MyNVASubnet della rete virtuale IntLB-VNet. Le due macchine virtuali non dispongono di un indirizzo IP pubblico

Le due macchine virtuali verranno utilizzate per simulare la presenza di appliance di rete. In questo laboratorio, infatti, ci concentreremo sulla configurazione di Azure Gateway Load Balancer e non sull’implementazione delle funzionalità di ispezione del traffico.

Naturalmente, in uno scenario reale potete scegliere di distribuire Network Virtual Appliance commerciali, come quelle disponibili in Azure Marketplace, utilizzando soluzioni firewall o IDS/IPS compatibili con Azure Gateway Load Balancer. In questo caso sarà necessario seguire le indicazioni del produttore per configurare correttamente le interfacce di rete, i tunnel VXLAN e l’inoltro del traffico.

Figura 29: Verifica della creazione delle macchine virtuali Linux MyNVA1 e MyNVA2 nel portale Azure

Abilitazione dell’IP forwarding sulle Network Virtual Appliance

Una delle caratteristiche delle Network Virtual Appliance è la capacità di ricevere e inoltrare pacchetti destinati ad altre risorse. Per consentire questo comportamento, Azure mette a disposizione l’impostazione IP forwarding, che permette a un’interfaccia di rete di gestire traffico il cui indirizzo IP di destinazione non corrisponde necessariamente a quello assegnato all’interfaccia stessa.

Dal portale Azure accedete alla sezione Virtual machines, selezionate MyNVA1 e aprite Networking > Network settings. Fate clic sull’interfaccia di rete associata alla macchina virtuale e, nella sezione Settings, selezionate IP configurations.

Individuate l’opzione Enable IP forwarding, abilitatela e salvate la configurazione. Ripetete la stessa operazione per MyNVA2.

Ricordate che l’abilitazione dell’IP forwarding nel portale Azure non configura automaticamente l’inoltro dei pacchetti all’interno del sistema operativo Linux. In uno scenario reale sarà necessario configurare anche le funzionalità di routing e le interfacce VXLAN previste dalla soluzione NVA utilizzata.

Figura 30: Abilitazione dell’IP forwarding sull’interfaccia di rete della macchina virtuale MyNVA1

Figura 31: Abilitazione dell’IP forwarding sull’interfaccia di rete della macchina virtuale MyNVA2

È importante ricordare che l’abilitazione dell’IP forwarding nel portale Azure non è sufficiente per garantire il corretto inoltro del traffico. È necessario configurare opportunamente anche il sistema operativo o il software della NVA.

In particolare, le appliance devono essere predisposte per ricevere e decapsulare il traffico VXLAN inviato da Gateway Load Balancer, elaborare i pacchetti secondo le regole di sicurezza previste e inoltrarli nuovamente attraverso i tunnel VXLAN. Occorre inoltre configurare correttamente il routing, verificare il supporto all’MTU richiesto dall’incapsulamento e assicurarsi che le appliance rispondano agli Health Probe del Load Balancer.

Le operazioni specifiche dipendono dalla soluzione utilizzata. Nel caso di appliance commerciali, è quindi necessario fare riferimento alla documentazione del produttore per configurare le interfacce di rete, i tunnel VXLAN e le funzionalità di inoltro del traffico.

Creazione di Azure Gateway Load Balancer

Dopo aver abilitato l’IP forwarding sulle interfacce di rete delle due Network Virtual Appliance, possiamo procedere con la creazione di Azure Gateway Load Balancer.

A differenza del Public Load Balancer configurato in precedenza, Gateway Load Balancer non viene utilizzato per distribuire direttamente le richieste HTTP tra i server web, ma per indirizzare il traffico verso le Network Virtual Appliance, che possono eseguire operazioni di ispezione, filtraggio e sicurezza.

Nel nostro laboratorio creeremo un Gateway Load Balancer denominato myGatewayLB, al quale assoceremo successivamente le macchine virtuali MyNVA1 e MyNVA2.

Figura 32: Architettura logica del laboratorio con Public Load Balancer, Gateway Load Balancer e due Network Virtual Appliance

Dal portale Azure accedete alla sezione Load balancing and content delivery, selezionate Load balancers e fate clic su Create > Gateway Load balancer.

Figura 33: Avvio della creazione di un Azure Gateway Load Balancer

Nella scheda Basics SELEZIONATE il Resource Group IntLB-RG, assegnate il nome myGatewayLB e scegliete la regione Italy North, la stessa in cui abbiamo distribuito le macchine virtuali e gli altri componenti del laboratorio.

Nella sezione Instance details, selezionate Gateway come SKU. A differenza dello SKU Standard, questa opzione permette di utilizzare il Load Balancer per indirizzare il traffico verso le Network Virtual Appliance, attraverso la funzionalità di Service Chaining.

Come potete osservare, selezionando lo SKU Gateway, Azure imposta automaticamente Internal come tipo di Load Balancer e Regional come livello del servizio.

Una volta completata la configurazione, fate clic su Next: Frontend IP configuration per procedere.

Figura 34: Configurazione delle impostazioni di base di Azure Gateway Load Balancer con SKU Gateway

Nella scheda Frontend IP configuration fate clic su Add a frontend IP configuration per configurare l’indirizzo IP privato che verrà utilizzato da Azure Gateway Load Balancer.

Assegnate alla configurazione il nome GatewayFrontEnd, selezionate il protocollo IPv4 e scegliete la rete virtuale IntLB-VNet. Nel campo Subnet selezionate MyNVASubnet (10.0.3.0/24), nella quale abbiamo distribuito le due Network Virtual Appliance.

Mantenete l’assegnazione dell’indirizzo IP su Dynamic e selezionate Zone-redundant nel campo Availability zone.

A differenza del Public Load Balancer, Gateway Load Balancer utilizza un frontend privato, che verrà successivamente associato al frontend del Public Load Balancer attraverso il Service Chaining. Il traffico verrà quindi indirizzato alle NVA senza che sia necessario esporre direttamente le appliance su Internet.

Fate clic su Save per confermare la configurazione.

Figura 35: Configurazione del frontend privato GatewayFrontEnd di Azure Gateway Load Balancer nella subnet MyNVASubnet

Verificate che le impostazioni siano corrette e fate clic su Next: Backend pools per procedere con la configurazione del pool che conterrà le due Network Virtual Appliance MyNVA1 e MyNVA2.

Figura 36: Configurazione del frontend GatewayFrontEnd di Azure Gateway Load Balancer

Fate clic su Add a backend pool per avviare la configurazione del pool e associare le interfacce di rete delle due NVA.

Figura 37: Avvio della configurazione del backend pool di Azure Gateway Load Balancer

Nella finestra Add backend pool assegnate il nome NVABackendPool e selezionate la rete virtuale IntLB-VNet. Mantenete NIC come modalità di configurazione del backend pool.

Nella sezione Gateway load balancer configuration, il protocollo utilizzato è VXLAN, che permette di incapsulare il traffico originale e trasportarlo verso le Network Virtual Appliance.

Selezionate Internal and External e configurate i due tunnel utilizzando la porta 10800 con identificatore 800 per il tunnel interno e la porta 10801 con identificatore 801 per quello esterno. Questi parametri dovranno essere configurati in modo coerente anche sulle appliance.

Nella sezione IP configurations fate clic su Add e selezionate le configurazioni IP delle due macchine virtuali MyNVA1 (10.0.3.4) e MyNVA2 (10.0.3.5), escludendo i tre server IIS che appartengono al backend pool del Public Load Balancer.

Confermate la selezione facendo clic su Add e successivamente su Save per completare la configurazione.

Figura 38: Configurazione del backend pool NVABackendPool, dei tunnel VXLAN e associazione delle Network Virtual Appliance MyNVA1 e MyNVA2

Dopo aver salvato la configurazione, nella scheda Backend pools viene visualizzato il pool NVABackendPool, associato alla rete virtuale IntLB-VNet.

Verificate che entrambe le NVA siano presenti nel backend pool e fate clic su Next: Inbound rules per procedere con la configurazione della regola di bilanciamento e dell’Health Probe.

Figura 39: Verifica dell’associazione delle Network Virtual Appliance MyNVA1 e MyNVA2 al backend pool NVABackendPool

Nella scheda Inbound rules fate clic su Add a load balancing rule per configurare la regola che permetterà ad Azure Gateway Load Balancer di distribuire il traffico tra le due Network Virtual Appliance.

Assegnate alla regola il nome GatewayHTTPRule, selezionate IPv4 e associate il frontend GatewayFrontEnd e il backend pool NVABackendPool.

L’opzione High availability ports risulta abilitata e permette di gestire il traffico indipendentemente dalle porte e dai protocolli utilizzati. Nonostante il nome della regola, quindi, il bilanciamento non sarà limitato al solo traffico HTTP.

Per verificare la disponibilità delle appliance, fate clic su Create new nella sezione Health probe e create un probe denominato NVAHealthProbe, utilizzando il protocollo TCP, la porta 8080 e un intervallo di verifica di 5 secondi.

La porta 8080 verrà utilizzata esclusivamente per i controlli di disponibilità delle NVA e dovrà corrispondere a un servizio TCP in ascolto su entrambe le appliance. Nel caso di soluzioni commerciali, utilizzate la porta e il protocollo indicati dal produttore.

Fate clic su Save per salvare l’Health Probe e associarlo alla regola di bilanciamento.

Figura 40: Configurazione della regola GatewayHTTPRule e creazione dell’Health Probe TCP sulla porta 8080

Dopo aver creato l’Health Probe, completate la configurazione della regola GatewayHTTPRule, verificando che siano selezionati il frontend GatewayFrontEnd, il backend pool NVABackendPool e il probe NVAHealthProbe (TCP:8080).

Mantenete Session persistence su None e lasciate le altre impostazioni ai valori predefiniti. L’opzione High availability ports, abilitata automaticamente, permette di distribuire il traffico verso le Network Virtual Appliance indipendentemente dal protocollo e dalle porte utilizzate.

Questa configurazione è particolarmente importante per Gateway Load Balancer, perché le appliance devono poter elaborare diversi tipi di traffico e non soltanto le connessioni HTTP.

Fate clic su Save per aggiungere la regola di bilanciamento.

Figura 41: Completamento della configurazione della regola GatewayHTTPRule

Come potete osservare, le colonne Frontend Port e Backend port riportano entrambe il valore 0. Questo comportamento è previsto quando viene utilizzata l’opzione High availability ports, che permette al Gateway Load Balancer di gestire il traffico su tutte le porte, senza limitarlo a uno specifico servizio applicativo.

Non è necessario configurare ulteriori regole di bilanciamento o regole Inbound NAT per il nostro scenario.

Figura 42: Verifica della regola GatewayHTTPRule

Terminata la configurazione, raggiungete la scheda Review + create e fate clic su Create per avviare la distribuzione di Azure Gateway Load Balancer.

Figura 43: Verifica delle impostazioni e avvio della creazione di Azure Gateway Load Balancer

Al termine della distribuzione, aprite la risorsa myGatewayLB dal portale Azure e verificate le informazioni riportate nella pagina Overview.

Figura 44: Panoramica di Azure Gateway Load Balancer myGatewayLB dopo il completamento della distribuzione

Configurazione del Service Chaining

Dopo aver creato Azure Gateway Load Balancer, dobbiamo collegarlo al Public Load Balancer myExtLoadBalancer, già configurato per distribuire il traffico HTTP verso i tre server IIS.

Questa operazione viene chiamata Service Chaining e permette di inserire le Network Virtual Appliance nel percorso del traffico, senza modificare il backend pool o le regole di bilanciamento del Public Load Balancer.

Dal portale Azure accedete alla sezione Load balancing and content delivery, selezionate Load balancers e aprite myExtLoadBalancer.

Nel menu Settings, selezionate Frontend IP configuration e fate clic sulla configurazione frontend myExtLoadBalancer, associata all’indirizzo IP pubblico

Figura 45: Accesso alla configurazione frontend del Public Load Balancer myExtLoadBalancer per impostare il Service Chaining

Nella schermata di configurazione del frontend myExtLoadBalancer, individuate il campo Gateway Load balancer e selezionate GatewayFrontEnd (10.0.3.6), corrispondente al frontend privato di myGatewayLB.

Questa associazione permette di configurare il Service Chaining tra il Public Load Balancer e il Gateway Load Balancer. Il traffico diretto all’indirizzo IP pubblico 9.235.156.68 potrà così essere reindirizzato verso le Network Virtual Appliance MyNVA1 e MyNVA2 attraverso i tunnel VXLAN, prima di raggiungere i server IIS del backend pool.

Come potete osservare, la regola di bilanciamento MyHTTPRule rimane associata al frontend pubblico. Non è quindi necessario modificare il backend pool o le regole di bilanciamento già configurate per i tre server web.

Fate clic su Save per confermare il collegamento tra i due Load Balancer.

Figura 46: Configurazione del Service Chaining tra il Public Load Balancer myExtLoadBalancer e il Gateway Load Balancer myGatewayLB

Da questo momento, il traffico diretto ai nostri web server viene instradato attraverso il Gateway Load Balancer e le Network Virtual Appliance presenti nel relativo backend pool, prima di raggiungere le macchine virtuali di destinazione.

Considerazioni sulla configurazione delle Network Virtual Appliance

Dopo aver associato il Gateway Load Balancer al frontend del Public Load Balancer, possiamo provare nuovamente a raggiungere il servizio web utilizzando l’indirizzo IP pubblico 9.235.156.68.

Come potete osservare, questa volta il browser restituisce l’errore ERR_CONNECTION_TIMED_OUT e i server IIS non risultano più raggiungibili.

Figura 47: Errore di connessione al servizio web dopo l’associazione del Gateway Load Balancer, in assenza di una configurazione completa delle NVA

Questo comportamento evidenzia un aspetto importante: la sola creazione del Gateway Load Balancer e l’associazione delle NVA al backend pool non sono sufficienti a garantire il corretto inoltro del traffico.

È infatti necessario configurare opportunamente entrambe le Network Virtual Appliance, predisponendo le interfacce di rete, la gestione dei tunnel VXLAN, le regole di routing e forwarding e le eventuali policy di sicurezza. Le appliance devono essere in grado di ricevere il traffico incapsulato dal Gateway Load Balancer, elaborarlo e reinstradarlo correttamente nel percorso previsto, sia in ingresso sia in uscita.

Le operazioni necessarie dipendono dal prodotto utilizzato e devono essere effettuate seguendo le indicazioni del relativo produttore. È inoltre importante verificare che gli Health Probe siano gestiti correttamente, affinché Azure possa individuare le appliance disponibili.

Fino a quando questa configurazione non sarà completata, il traffico applicativo potrebbe essere interrotto e i web server, pur essendo operativi, potrebbero non risultare raggiungibili da Internet.

Una volta completata correttamente la configurazione delle Network Virtual Appliance, sarà possibile accedere nuovamente ai web server attraverso l’indirizzo IP pubblico del Load Balancer.

Il traffico verrà instradato attraverso il Gateway Load Balancer e le NVA, che potranno applicare le regole di sicurezza e le funzionalità di ispezione previste, prima di consentire alle richieste di raggiungere i server di destinazione.

Nell’esempio mostrato sotto, il servizio web risulta nuovamente raggiungibile e la richiesta HTTP viene gestita dalla macchina virtuale myVM3.

Figura 48: Accesso al servizio web attraverso il Public Load Balancer dopo la corretta configurazione delle Network Virtual Appliance

Conclusioni

Azure Gateway Load Balancer permette di inserire in modo semplice e trasparente firewall, IDS/IPS e altre appliance di rete nel percorso del traffico, senza modificare le applicazioni né gli indirizzi IP usati dai client. Con il Service Chaining basta collegare il Gateway Load Balancer al frontend di un Public Load Balancer esistente per far passare il traffico dalle appliance.