Il cloud sta cambiando il modo in cui viene progettata l'infrastruttura, inclusi i firewall, poiché la rete non è più fisica o interna a LAN virtuali. In una rete virtuale non sono disponibili tutte le funzionalità di una rete fisica, ad esempio l'uso di indirizzi IP mobili o il traffico trasmesso, il che influisce sull'implementazione di architetture a disponibilità elevata. I sistemi di bilanciamento del carico per appliance virtuali di rete possono o devono essere implementati in un certo modo per ottenere un'architettura a disponibilità elevata all'interno di una rete virtuale. Questa guida presenta un approccio strutturato per la progettazione di firewall a disponibilità elevata in Azure tramite appliance virtuali di terze parti.
Opzioni per la progettazione di appliance virtuali a disponibilità elevata
Quando si distribuiscono architetture a disponibilità elevata, esistono alcune opzioni per fornire il failover:
- Tabelle di route gestite da API di Azure: questa opzione prevede l'uso di due tabelle di route, una attiva e l'altra passiva, per cambiare l'indirizzo IP gateway attivo per tutti i servizi in esecuzione in una rete virtuale o in una subnet.
- Indirizzo IP mobile gestito da API di Azure: questa opzione prevede l'uso di un indirizzo IP secondario sui firewall che può essere spostato tra un firewall attivo e uno in standby.
- Load Balancer gestito: questa opzione prevede l'uso di un servizio Azure Load Balancer che funga da indirizzo IP gateway per la subnet, che poi inoltra il traffico al firewall attivo. Può anche inoltrare il traffico attivo-attivo per fornire un bilanciamento del carico effettivo.
Il problema con le prime due opzioni è che il failover è lento. Il firewall deve istruire il failover, che è essenzialmente una "riconfigurazione" dei servizi di Azure tramite una nuova distribuzione. A seconda della velocità con cui viene completata la distribuzione, i flussi di traffico saranno inattivi per diversi minuti. Inoltre, la configurazione attiva-attiva, in cui entrambi i firewall funzionano contemporaneamente, non è consentita.
Ecco perché è preferibile scegliere la terza opzione. Il tempo di inattività è ridotto al minimo perché il servizio di bilanciamento del carico può effettuare il failover quasi immediatamente al firewall in standby (attivo-passivo) o semplicemente rimuovere il carico dal firewall in errore (attivo-attivo). Non è possibile tuttavia usare i sistemi di bilanciamento del carico come "gateway predefiniti", poiché influiscono sul flusso del traffico e i pacchetti TCP devono essere con stato.
Firewall a due connessioni
L'immagine seguente inizia con due firewall (FW-1 e FW-2) con un servizio di bilanciamento del carico esterno e un server back-end S1.
Questa architettura rappresenta una configurazione semplice, usata per il traffico in ingresso. Un pacchetto raggiunge il servizio di bilanciamento del carico, che sceglie il firewall di destinazione dalla relativa configurazione. Il firewall scelto invia quindi il traffico al server back-end (Web). Se per FW-1 è abilitato SNAT, il server S1 vedrà il traffico proveniente dall'indirizzo IP interno di FW-1 e invierà quindi anche la risposta al pacchetto a FW-1. In questo scenario il failover a FW-2 può avvenire rapidamente. Per il traffico in uscita, si potrebbe aggiungere un altro servizio di bilanciamento del carico sul lato interno. Quando il server S1 avvia il traffico, verrebbe applicato lo stesso principio. Il traffico raggiunge il sistema di bilanciamento del carico interno (iLB) che quindi sceglie un firewall che esegue la conversione NAT per la risoluzione esterna.
Firewall a tre connessioni
Si verifica un problema quando si aggiunge un'altra interfaccia al firewall ed è necessario disabilitare la conversione NAT tra zone interne. In questo caso, vedere le Subnet-B e Subnet-C:
Il routing L3 tra le zone interne (Subnet-B e Subnet-C) sarà sottoposto a bilanciamento del carico senza NAT. Questa configurazione diventa più chiara se si esaminano i flussi del traffico che includono i sistemi di bilanciamento del carico in una visualizzazione diversa. Il diagramma seguente mostra la visualizzazione in cui i sistemi di bilanciamento del carico interno [iLB] sono collegati a una scheda di interfaccia di rete specifica nei firewall:
Con il traffico L3 (senza NAT), S2 visualizzerà l'indirizzo IP S1 come indirizzo di origine. S2 invierà quindi il traffico di ritorno della subnet B (a cui appartiene l'IP di S1) a iLB nella Subnet-C. Poiché iLB nella Subnet-B e iLB nella Subnet-C non sincronizzano i loro stati sessione, a seconda dell'algoritmo di bilanciamento del carico, il traffico potrebbe finire in FW-2. FW-2, per impostazione predefinita, non riconosce niente del pacchetto iniziale (verde) e pertanto interromperà la connessione.
Alcuni fornitori di firewall provano a mantenere uno stato di connessione tra i firewall, ma dovranno avere una sincronizzazione quasi istantanea per essere aggiornati sullo stato delle connessioni. Verificare con il fornitore del firewall se questa configurazione è consigliata.
Il modo migliore per risolvere questo problema consiste nell'eliminarlo. Nell'esempio precedente questa soluzione implicherebbe l'eliminazione di Subnet-C, che offre i vantaggi delle reti virtuali.
Isolare gli host in una subnet con gruppi di sicurezza di rete
Se sono presenti due VM in una singola subnet, è possibile applicare un gruppo di sicurezza di rete che isola il traffico tra le due. Per impostazione predefinita, tutto il traffico all'interno di una rete virtuale è autorizzato. L'aggiunta di una regola Rifiuta tutto nel gruppo di sicurezza di rete isola tutte le VM l'una dall'altra.
Le reti virtuali usano gli stessi router virtuali back-end
Le reti virtuali e le subnet usano un singolo sistema di router back-end di Azure e, pertanto, non è necessario specificare un indirizzo IP del router per ogni subnet. La destinazione della route può essere un punto qualsiasi della stessa rete virtuale o anche all'esterno.
Con le reti virtuali, è possibile controllare le route in ogni subnet. Queste route possono anche puntare a un singolo indirizzo IP di un'altra subnet. Nell'immagine precedente, si tratta del sistema iLB in Subnet-D, che bilancia il carico dei due firewall. Quando S1 avvia il traffico (verde), il carico verrà bilanciato, ad esempio, in FW-1. FW-1 si connette quindi a S2 (sempre verde). S2 invierà il traffico di risposta all'indirizzo IP di S1 (poiché NAT è disabilitato) e, a causa delle tabelle di route, S2 usa lo stesso indirizzo IP di iLB del gateway. Il sistema iLB potrà far corrispondere il traffico alla sessione iniziale e, di conseguenza, punterà sempre il traffico a FW-1, che quindi lo invierà a S1, stabilendo un flusso di traffico sincrono.
Per ottenere questo risultato, però, il firewall deve avere una tabella di route (internamente) che punta Subnet-B e a Subnet-C al proprio gateway di subnet predefinito, ovvero il primo indirizzo IP disponibile a livello logico nell'intervallo della subnet in tale rete virtuale.
Impatto sui servizi di proxy inverso
Un servizio di proxy inverso distribuito si trova in genere dietro al firewall, ma è anche possibile inserirlo in linea con il firewall e instradarvi effettivamente il traffico. Il vantaggio di questa configurazione è che il servizio di proxy inverso vede l'indirizzo IP originale del client connesso:
Per questa configurazione, le tabelle di route in Subnet-E devono puntare Subnet-B e Subnet-C tramite il servizio di bilanciamento del carico interno. Alcuni servizi di proxy inverso incorporano firewall che consentono di rimuovere completamente il firewall in questo flusso di rete e di puntare dal proxy inverso direttamente ai server di Subnet-B/C.
In questo scenario, SNAT sarà necessario anche nel proxy inverso, per evitare che il traffico di ritorno attraversi e venga negato dai firewall in Subnet-A.
VPN/ER
Azure fornisce servizi VPN/ER abilitati per BGP e a disponibilità elevata tramite i gateway di rete virtuale di Azure. La maggior parte degli architetti li mantiene per le connessioni back-end o non Internet. Questa configurazione implica che la tabella di routing deve supportare le subnet anche dietro a queste connessioni. Nella connettività di Subnet-B/C non esiste una grande differenza, ma esiste invece nel modello del traffico di ritorno. Per completare l'immagine:
In questa architettura il traffico che raggiunge il firewall, ad esempio, da Subnet-B a Subnet-X, verrà inviato al sistema iLB, che a sua volta lo invia a uno dei firewall. La route interna del firewall rinvierà in traffico a Subnet-GW (primo indirizzo IP disponibile in Subnet-D). Non è necessario inviare il traffico direttamente all'appliance del gateway, perché Subnet-D avrà un'altra route per Subnet-X che la punta al gateway di rete virtuale. La rete di Azure si occuperà del routing effettivo.
Il traffico di ritorno proveniente da Subnet-X verrà inoltrato al sistema iLB in Subnet-D. Anche GatewaySubnet avrà una route personalizzata che punta Subnet-B-C al sistema iLB. Subnet-D non attraversa invece il sistema iLB. Questa operazione verrà trattata come normale routing tra reti virtuali.
Anche se non illustrato nel disegno, sarebbe opportuno che Subnet-B/C/D/Gateway includano anche una route per Subnet-A che punta al sistema iLB. Questo per evitare che il routing di rete virtuale "regolare" ignori i firewall. Il motivo è che Subnet-A è solo un'altra subnet della rete virtuale, secondo lo stack di rete di Azure. Non tratta subnet-A diversa, anche se la si considera come rete perimetrale, Internet e così via.
Riepilogo
In breve, i firewall nelle reti locali (fisiche/basate su VLAN), con lo stesso numero di interfacce (virtuali o fisiche), non vengono considerati allo stesso modo dei firewall in Azure. Se necessario, è comunque possibile (in una certa misura), ma esistono modi migliori per ridurre al minimo i tempi di inattività di failover, ossia con implementazioni attive-attive e tabelle di route pulite.
Altre informazioni sull'uso dei sistemi di bilanciamento del carico come gateway per tutto il traffico sono reperibili in Panoramica delle porte a disponibilità elevata.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Roelf Zomerman | Senior Cloud Solution Architect
Passaggi successivi
Altre informazioni sulle tecnologie dei componenti:
Risorse correlate
Esplorare le architetture correlate: