Distribuire appliance virtuali di rete (NVA) a disponibilità elevata

Questo articolo descrive i modi comuni per distribuire un set di appliance virtuali di rete per la disponibilità elevata in Azure. Un appliance di rete virtuale controlla in genere il flusso del traffico tra segmenti di rete con livelli di sicurezza diversi. Ad esempio, è possibile utilizzare un'Appliance Virtuale di Rete (NVA) tra una rete virtuale perimetrale e la rete pubblica Internet, oppure per collegare sedi esterne ad Azure tramite reti private virtuali (VPN) o appliance WAN definiti dal software (SD-WAN).

Questo articolo presuppone che si abbia una conoscenza di base della rete di Azure, dei servizi di bilanciamento del carico di Azure, del routing del traffico di rete virtuale e delle route definite dall'utente.

Molti modelli di progettazione usano appliance virtuali di rete (NVA) per controllare il traffico tra diverse zone di sicurezza. Questi modelli potrebbero utilizzare le NVAs (appliance virtuali di rete) per i seguenti scopi:

• Per controllare il traffico in uscita dalle macchine virtuali a Internet e impedire l'esfiltrazione dei dati.

• Per controllare il traffico in ingresso da Internet alle macchine virtuali e prevenire gli attacchi.

• Per filtrare il traffico tra macchine virtuali in Azure per impedire spostamenti laterali di sistemi compromessi.

• Per filtrare il traffico tra sistemi locali e macchine virtuali di Azure, soprattutto se appartengono a livelli di sicurezza diversi. Ad esempio, Azure ospita la rete perimetrale, mentre l'ambiente locale ospita le applicazioni interne.

• Per terminare i tunnel VPN o SD-WAN da località esterne, ad esempio reti locali o altri cloud pubblici.

È possibile aggiungere le appliance virtuali di rete seguenti a una progettazione di Azure usando i modelli descritti in questo articolo:

• Firewall di rete
• Reverse proxy di livello 4
• Endpoint VPN di Sicurezza del Protocollo Internet (IPsec)
• elettrodomestici SD-WAN
• Proxy inversi basati sul Web con funzionalità web application firewall
• Proxy Internet per limitare le pagine Internet a cui è possibile accedere da Azure
• Servizi di bilanciamento del carico di livello 7

Le appliance virtuali di rete native di Azure, ad esempio Firewall di Azure e il gateway applicazione di Azure, usano le progettazioni illustrate più avanti in questo articolo. È necessario comprendere queste opzioni dal punto di vista della progettazione e per scopi di risoluzione dei problemi di rete.

Gli NVA (Network Virtual Appliances) richiedono spesso una disponibilità elevata perché controllano la comunicazione tra segmenti di rete. Se le NVA (Network Virtual Appliances) diventano non disponibili, il traffico di rete non può circolare e le applicazioni si interrompono. Le interruzioni pianificate e non pianificate interrompono occasionalmente le istanze di NVA, simili ad altre macchine virtuali in Azure o in altri cloud. Le istanze NVA potrebbero spegnersi anche se vengono configurate con SSD Premium di Azure, che forniscono un accordo sul livello di servizio per istanza singola in Azure. Le applicazioni a disponibilità elevata richiedono almeno due appliance virtuali di rete per contribuire a garantire la connettività.

Quando si sceglie l'opzione migliore per distribuire un'appliance virtuale di rete in una rete virtuale di Azure, l'aspetto più importante è se il fornitore dell'appliance virtuale di rete ha valutato e convalidato la progettazione. Il fornitore deve anche fornire la configurazione dell'appliance virtuale di rete necessaria per integrare l'appliance virtuale di rete in Azure. Se il fornitore dell'appliance virtuale di rete offre più opzioni di progettazione supportate, prendere in considerazione i fattori seguenti per prendere la decisione:

• Tempo di convergenza: Tempo necessario affinché ciascun progetto devii il traffico da un'istanza NVA fallita.

• Supporto della topologia: Le configurazioni NVA supportate da ogni opzione di progettazione, ad esempio attivo/attivo, attivo/standby o cluster di NVA in grado di scalare aumentando l'unità per la ridondanza.

• Simmetria del traffico: Se una particolare progettazione impone all'appliance virtuale di rete di eseguire SNAT (Source Network Address Translation) sui pacchetti per evitare il routing asimmetrico o se la progettazione impone la simmetria del traffico tramite altri mezzi

Annotazioni

Questo articolo è incentrato sui modelli hub-and-spoke. Questo articolo non tratta la rete WAN virtuale di Azure perché include linee guida più prescrittive per la distribuzione di appliance virtuali di rete, a seconda che un hub della rete wan virtuale supporti un'appliance virtuale di rete specifica. Per ulteriori informazioni, vedere dispositivi virtuali di rete in un hub WAN virtuale.

Le sezioni seguenti descrivono le architetture comuni che è possibile usare per integrare appliance virtuali di rete in una rete hub-spoke.

Panoramica delle architetture a disponibilità elevata

Soluzione	Vantaggi	Considerazioni
Azure Load Balancer	Questa soluzione supporta configurazioni attive/attive/standby e appliance virtuali di rete con scalabilità orizzontale con un tempo di convergenza ottimale.	L'appliance virtuale di rete deve fornire una porta per i probe di integrità, in particolare per le distribuzioni attive/standby. Per le appliance con stato, ad esempio i firewall che richiedono la simmetria del traffico, i flussi da e verso Internet richiedono SNAT.
Azure Route Server	L'NVA deve supportare il protocollo BGP (Border Gateway Protocol). Questa soluzione supporta NVAs attive/attive, attive/standby e con scalabilità orizzontale.	La simmetria del traffico richiede SNAT in questa soluzione.
Servizio di bilanciamento del carico del gateway di Azure	La simmetria del traffico è garantita senza SNAT. Le appliance virtuali di rete possono essere condivise tra tenant. Questa soluzione ha un tempo di convergenza ottimale e supporta appliance virtuali di rete attive/attive, attive/standby e con scalabilità orizzontale.	Questa soluzione supporta i flussi da e verso Internet e non supporta i flussi East-West.
Indirizzo IP privato dinamico e UDR	Il dispositivo virtuale di rete non richiede funzionalità speciali. Questa soluzione garantisce il traffico simmetrico.	Questa soluzione è solo per progetti attivi/passivi. Ha un tempo di convergenza elevato da uno a due minuti.

Bilanciatore di carico

La progettazione di Load Balancer usa due servizi di bilanciamento del carico di Azure per esporre un cluster di appliance virtuali di rete al resto della rete. L'approccio è adatto sia alle appliance virtuali di rete con stato che alle appliance virtuali di rete senza stato.

• Un servizio di bilanciamento del carico interno reindirizza il traffico interno da Azure e dalle sedi locali alle NVA. Questo servizio di bilanciamento del carico interno è configurato con regole di porte a disponibilità elevata in modo che ogni porta TCP (Transmission Control Protocol) e UDP (User Datagram Protocol) venga reindirizzata alle istanze dell'appliance virtuale di rete.

• Un servizio di bilanciamento del carico pubblico espone gli NVA a Internet. Le porte a disponibilità elevata sono per il traffico in ingresso, quindi ogni porta TCP/UDP deve essere aperta in una regola di bilanciamento del carico dedicata.

Il diagramma seguente illustra la sequenza di salti che i pacchetti compiono da Internet a un server di applicazioni in una rete virtuale spoke. Questi pacchetti attraversano una rete virtuale NVA del firewall per controllare il traffico da e verso l'Internet pubblica, noto anche come trafficoNorth-South.

Questo diagramma mostra un hub e due raggi. L'hub contiene una subnet gateway e una subnet NVA. La subnet del gateway contiene un gateway VPN o Azure ExpressRoute. La subnet NVA contiene un bilanciamento del carico interno di Azure e appliance virtuali di rete. Ogni spoke contiene un server applicazioni. Spoke2 ha una nota che legge la tabella di route spoke 0.0.0.0/0 a 10.0.0.36 e disabilita la propagazione del gateway. Il traffico in ingresso fluisce dall'Internet pubblico alle NVAs attraverso il load balancer pubblico di Azure. Questo traffico passa quindi al server app in Spoke2. Il traffico di ritorno fluisce da questo server dell'applicazione alle appliance di rete virtuali attraverso il servizio di bilanciamento del carico interno di Azure. Questo traffico passa quindi alla rete Internet pubblica.

Scaricare un file di Visio di questa architettura.

Per inviare il traffico dagli spoke alla rete Internet pubblica tramite le appliance virtuali di rete, questo design utilizza un UDR per 0.0.0.0/0. L'hop successivo è l'indirizzo IP del servizio di bilanciamento del carico interno.

Per il traffico tra Azure e Internet pubblico, ogni direzione del flusso del traffico attraversa un servizio di bilanciamento del carico di Azure diverso. Questo processo si verifica anche se l'appliance virtuale di rete del firewall ha una singola scheda di interfaccia di rete (NIC) per le reti pubbliche e interne perché il pacchetto in ingresso passa attraverso il servizio di bilanciamento del carico pubblico di Azure e il pacchetto in uscita passa attraverso il servizio di bilanciamento del carico interno di Azure. Entrambe le direzioni del flusso passano attraverso diversi servizi di bilanciamento del carico. Pertanto, se è necessaria la simmetria del traffico, le istanze dell'appliance virtuale di rete devono eseguire SNAT per indirizzare il traffico di ritorno e mantenere la simmetria. La maggior parte dei firewall richiede la simmetria del traffico.

Il diagramma seguente illustra come utilizzare la stessa progettazione del bilanciamento del carico per esaminare il traffico tra reti Azure e on-premises, o East-West traffico, che implica solo un bilanciamento del carico interno. È anche possibile usare questo metodo per inviare il traffico tra gli spoke attraverso le appliance virtuali di rete.

Questo diagramma mostra un hub e due raggi. L'hub contiene una subnet gateway e una subnet NVA. La subnet del gateway contiene un gateway VPN o ExpressRoute. La subnet NVA contiene un bilanciamento del carico interno di Azure e appliance virtuali di rete. Ogni spoke contiene un server applicazioni. Spoke2 ha una nota che legge la tabella di route spoke 0.0.0.0/0 a 10.0.0.36 e disabilita la propagazione del gateway. Il traffico in ingresso passa dall'ambiente locale alle appliance virtuali di rete attraverso il gateway VPN o ExpressRoute e quindi il servizio di bilanciamento del carico interno di Azure. Questo traffico passa quindi al server app in Spoke2. Il traffico di ritorno fluisce da questo server dell'applicazione alle appliance di rete virtuali attraverso il servizio di bilanciamento del carico interno di Azure. Questo traffico passa quindi all'ambiente locale tramite la VPN o il gateway ExpressRoute.

Nei diagrammi precedenti, spoke1 non conosce la gamma di spoke2. Di conseguenza, la 0.0.0.0/0 route definita dall'utente invia il traffico destinato allo spoke2 al servizio di bilanciamento del carico interno di Azure dell'appliance virtuale di rete.

Per il traffico tra reti locali e Azure o tra macchine virtuali di Azure, la simmetria del traffico è garantita nelle appliance virtuali di rete a scheda di rete singola dal servizio di bilanciamento del carico interno di Azure. Quando entrambe le direzioni di un flusso di traffico attraversano lo stesso servizio di bilanciamento del carico di Azure, il servizio di bilanciamento del carico seleziona la stessa istanza dell'appliance virtuale di rete per entrambe le direzioni. Se una progettazione di NVA dual-NIC ha un servizio di bilanciamento del carico interno per ogni direzione di comunicazione, SNAT garantisce la simmetria del traffico. Il diagramma North-South precedente fornisce un esempio di questa progettazione.

In questa progettazione, le NVA dual-NIC devono determinare dove inviare le risposte ai controlli dello stato di integrità del servizio di bilanciamento del carico. Load Balancer usa sempre lo stesso indirizzo IP dell'origine per i controlli di integrità, ovvero 168.63.129.16. La NVA deve inviare di nuovo queste risposte di verifica della salute tramite la stessa interfaccia sulla quale sono state ricevute. Questo processo richiede in genere più tabelle di routing in un sistema operativo perché il routing basato su destinazione invia le risposte tramite la stessa scheda di interfaccia di rete.

Il servizio di bilanciamento del carico di Azure ha un buon tempo di convergenza nelle singole interruzioni delle appliance virtuali di rete. È possibile inviare sonde di integrità ogni cinque secondi e sono necessari tre sonde non riuscite per dichiarare un'istanza back-end fuori servizio. Di conseguenza, il servizio di bilanciamento del carico di Azure richiede in genere da 10 a 15 secondi per convergere il traffico verso un'istanza di appliance virtuale di rete diversa.

Questa configurazione supporta sia configurazioni attive/attive che attive/standby. Per le configurazioni attive/standby, le istanze NVA devono fornire una porta TCP o UDP o un endpoint HTTP che risponde esclusivamente ai controlli di stato del bilanciatore del carico per l'istanza che attualmente ricopre il ruolo attivo.

Servizi di bilanciamento del carico di livello 7

Una progettazione specifica per le appliance di sicurezza sostituisce il servizio di bilanciamento del carico pubblico di Azure con un bilanciatore di carico di livello 7, come ad esempio l'Azure Application Gateway, che può essere considerato esso stesso un'appliance virtuale di rete.

In questo scenario, le appliance virtuali di rete richiedono solo un servizio di bilanciamento del carico interno per gestire il traffico proveniente dai sistemi di elaborazione. A volte i dispositivi Dual-NIC usano questo approccio per evitare problemi di routing con i controlli di integrità del servizio di bilanciamento del carico di Azure. Questa progettazione supporta solo i protocolli di livello 7 supportati dal servizio di bilanciamento del carico di livello 7, che in genere è HTTP e HTTPS.

Il NVA dovrebbe gestire il traffico in ingresso per i protocolli non supportati dal bilanciatore del carico di livello 7. L'NVA potrebbe anche gestire il traffico in uscita. Per ulteriori informazioni, vedere Firewall e Gateway delle Applicazioni per le reti virtuali.

Route Server

Route Server è un servizio che consente a un NVA (appliance virtuale di rete) di interagire con la rete definita dal software di Azure tramite BGP. Gli apparati virtuali di rete apprendono quali prefissi di indirizzi IP esistono nelle reti virtuali di Azure. Possono anche aggiungere percorsi nelle tabelle di routing effettive delle macchine virtuali in Azure.

Questo diagramma mostra un hub e due raggi. L'hub contiene una subnet del gateway, una subnet dell'appliance virtuale di rete (NVA), e una subnet del Server di Routing. La subnet del gateway contiene un gateway VPN o ExpressRoute. La subnet NVA contiene due appliance virtuali di rete (NVA). La sottorete del Route Server contiene il Route Server. Ogni spoke contiene un server applicazioni. Spoke2 ha una nota che legge route valide spoke da 0.0.0.0/0 a 10.0.0.37 e 0.0.0.0/0 a 10.0.0.38. Il traffico in ingresso fluisce dalla rete Internet pubblica a NVA1 attraverso il load balancer pubblico di Azure. Questo traffico passa quindi al server app in Spoke2. Il traffico viene restituito da questo server app a NVA1 e quindi verso La rete Internet pubblica. La relazione BGP connette NVA1, NVA2 e il Route Server. NVA2 e Server di route sono connessi tramite eBGP.

Nel diagramma precedente ogni istanza dell'appliance virtuale di rete si connette al server di route tramite BGP. Questa progettazione non richiede una tabella di route nelle subnet spoke perché il server di route programma le route annunciate dalle appliance virtuali di rete. Se due o più route sono configurate nelle macchine virtuali di Azure, usano il routing multi-percorso a costi uguali per scegliere una delle istanze dell'appliance virtuale di rete (NVA) per ogni flusso di traffico. Pertanto, è necessario includere SNAT in questa progettazione se è necessaria la simmetria del traffico.

Questo metodo di inserimento supporta sia configurazioni attive/attive che attive/standby. In una configurazione attiva/attiva, tutte le appliance virtuali di rete annunciano le stesse route al server di route. In una configurazione attiva/standby, un'appliance virtuale di rete (NVA) annuncia le rotte con un percorso AS (Autonomous System) più breve rispetto all'altro. Il Route Server supporta al massimo otto adiacenze BGP. Pertanto, se si usa un cluster di appliance virtuali di rete attive con scalabilità orizzontale, questa progettazione supporta un massimo di otto istanze dell'appliance virtuale di rete.

Questa configurazione ha un tempo di convergenza rapido. I timer keepalive e holdtime dell'adiacenza BGP influenzano il tempo di convergenza. Il server di route ha timer keepalive predefiniti impostati su 60 secondi e timer holdtime impostati su 180 secondi. Tuttavia, le NVAs (Network Virtual Appliances) possono negoziare timer inferiori durante lo stabilimento dell'adiacenza BGP. L'impostazione di questi timer troppo bassa potrebbe causare instabilità BGP.

Questa progettazione è adatta alle appliance virtuali di rete che devono interagire con il routing di Azure. Gli esempi includono SD-WAN o NVAs IPsec, che in genere hanno un buon supporto BGP. Queste appliance virtuali di rete devono apprendere i prefissi configurati nelle reti virtuali di Azure o annunciare determinate route tramite peering privati di ExpressRoute. Questi tipi di dispositivi sono generalmente senza stato, quindi la simmetria del traffico non è un problema e SNAT non è necessario.

Bilanciamento del carico del gateway

Gateway Load Balancer consente di inserire appliance virtuali di rete nel percorso dei dati senza la necessità di instradare il traffico mediante route definite dall'utente (UDR). Per le macchine virtuali che espongono i carichi di lavoro tramite un servizio di bilanciamento del carico di Azure o un indirizzo IP pubblico, è possibile reindirizzare il traffico in ingresso e in uscita in modo trasparente a un cluster di appliance virtuali di rete che si trova in una rete virtuale diversa. Il diagramma seguente illustra il percorso che i pacchetti seguono per il traffico in ingresso da Internet pubblico se i carichi di lavoro espongono l'applicazione tramite un servizio di bilanciamento del carico di Azure.

Questo diagramma mostra una rete virtuale di appliance di rete NVA e una rete virtuale dell'app. La rete virtuale contiene il Bilanciamento del carico del gateway e le appliance virtuali di rete. La rete virtuale dell'app contiene un server Web. Il flusso utente passa da Internet al server Web tramite un servizio di bilanciamento del carico di Azure standard pubblico. Il flusso controllato dal Gateway Load Balancer passa dal bilanciatore di carico standard pubblico di Azure al Gateway Load Balancer e poi ai dispositivi virtuali di rete. Questo flusso inverte la direzione e passa dalle NVAs al servizio di bilanciamento del carico del gateway, per poi andare al servizio di bilanciamento del carico standard pubblico di Azure.

Questo metodo di iniezione del dispositivo virtuale di rete offre i seguenti vantaggi:

• Questo metodo non richiede SNAT per garantire la simmetria del traffico.

• È possibile utilizzare le stesse apparecchiature virtuali di rete per ispezionare il traffico da e verso diverse reti virtuali, fornendo la multi-tenancy dal punto di vista delle apparecchiature virtuali di rete.

• Il peering di rete virtuale non è necessario tra la rete virtuale dell'appliance di rete e le reti virtuali di carico di lavoro, il che semplifica la configurazione.

• Le Route Definite dall'Utente (UDR) non sono necessarie nella rete virtuale del workload, semplificando anche la configurazione.

È possibile usare l'inserimento del servizio tramite Gateway Load Balancer per il traffico in ingresso verso un servizio di bilanciamento del carico pubblico di Azure, il traffico restituito e il traffico in uscita da Azure. East-West Il traffico tra macchine virtuali di Azure non può usare Gateway Load Balancer per l'inserimento di appliance virtuali di rete.

Nel cluster NVA, le sonde di controllo dell'integrità del servizio di bilanciamento del carico di Azure rilevano i guasti nelle singole istanze NVA, offrendo un tempo di convergenza rapido compreso tra 10 e 15 secondi.

Gestione dinamica degli indirizzi IP pubblici e delle rotte definite dall'utente

L'obiettivo di questa progettazione è avere una configurazione che funzioni senza ridondanza dell'appliance virtuale di rete e può essere modificata se l'appliance virtuale di rete riscontra tempi di inattività. Il diagramma seguente illustra come un indirizzo IP pubblico di Azure viene associato a un'appliance virtuale di rete attiva (NVA1) nel diagramma. Le route definite dall'utente (UDR) negli spokes usano l'indirizzo IP della NVA attiva (10.0.0.37) come hop successivo.

Questo diagramma mostra un hub e due raggi. L'hub contiene una subnet gateway e una subnet NVA. La subnet del gateway contiene un gateway VPN o ExpressRoute. La subnet NVA contiene due appliance virtuali di rete (NVA). L'appliance virtuale di rete NVA1 è etichettato come attivo e l'appliance virtuale di rete NVA2 è etichettato come standby. Ogni spoke contiene un server applicazioni. Spoke2 ha una nota che legge la tabella di route spoke 0.0.0.0/0 a 10.0.0.37 e disabilita la propagazione del gateway. Il traffico in ingresso passa da Internet a NVA1 tramite un indirizzo IP pubblico. Questo traffico passa quindi a Spoke2. Il traffico fluisce da Spoke2 a NVA1 e quindi verso internet.

Se l'NVA attiva non è più disponibile, l'NVA di standby chiama l'API di Azure per rimappare l'indirizzo IP pubblico e le UDR spoke a sé, oppure per assumere l'indirizzo IP privato. L'efficacia di queste chiamate API può richiedere alcuni minuti. Questa progettazione offre il peggiore tempo di convergenza tra le opzioni di questo articolo.

Questa progettazione supporta solo configurazioni attive/standby, che possono causare problemi di scalabilità. Se è necessario aumentare la larghezza di banda supportata dalle appliance virtuali di rete, è necessario aumentare le prestazioni di entrambe le istanze.

Questa progettazione non richiede SNAT per garantire la simmetria del traffico perché solo un'appliance virtuale di rete è attiva in qualsiasi momento.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

• Keith Mayer | Principal Cloud Solution Architect
• Telmo Sampaio | Principal Service Engineering Manager
• Jose Moreno | Ingegnere principale

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passo successivo

• Reti perimetrali

Risorsa collegata

• Implementare una rete ibrida sicura usando Firewall di Azure