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

Questo articolo illustra le opzioni più comuni per distribuire un set di appliance virtuali di rete per la disponibilità elevata in Azure. Un'appliance virtuale di rete viene in genere usata per controllare il flusso di traffico tra segmenti di rete classificati con livelli di sicurezza diversi, ad esempio tra una rete virtuale De-Militarized (DMZ) e la rete Internet pubblica o per connettere posizioni esterne ad Azure, ad esempio appliance VPN o SDWAN (Software-Defined WAN).

Esistono molti modelli di progettazione in cui le appliance virtuali di rete vengono usate per controllare il traffico tra zone di sicurezza diverse, ad esempio:

• 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 evitare spostamenti laterali di sistemi compromessi.
• Per filtrare il traffico tra i sistemi locali e le macchine virtuali di Azure, se vengono considerati appartenenti a livelli di sicurezza diversi. Ad esempio, se Azure ospita la rete perimetrale e le applicazioni interne in locale.
• Per terminare tunnel VPN o SDWAN da posizioni esterne, ad esempio reti locali o altri cloud pubblici.

Esistono molti esempi di appliance virtuali di rete, tra cui:

• Firewall di rete
• Proxy di livello 4 inverso
• Endpoint VPN IPsec
• Appliance SDWAN
• 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

Tutte queste appliance virtuali di rete possono essere inserite in una progettazione di Azure con i modelli descritti in questo articolo. Anche le appliance virtuali di rete proprietarie di Azure, ad esempio firewall di Azure e gateway applicazione di Azure usare le progettazioni illustrate più avanti in questo articolo. Comprendere queste opzioni è fondamentale sia dal punto di vista della progettazione che dalla risoluzione dei problemi di rete.

La prima domanda a cui rispondere è il motivo per cui è necessaria la disponibilità elevata per le appliance virtuali di rete. Il motivo è che questi dispositivi controllano la comunicazione tra segmenti di rete. Se non sono disponibili, il traffico di rete non può essere propagato e le applicazioni non funzionano. Le interruzioni pianificate e non pianificate comportano occasionalmente l'arresto delle istanze dell'appliance virtuale di rete (come qualsiasi altra macchina virtuale in Azure o in qualsiasi altro cloud). Le istanze vengono arrestate anche se tali appliance virtuali di rete sono configurate con Managed Disk Premium per fornire un contratto di servizio a istanza singola in Azure. Di conseguenza, le applicazioni a disponibilità elevata richiedono almeno un secondo appliance virtuale di rete in grado di garantire la connettività.

prerequisiti : Questo articolo presuppone una conoscenza di base della rete di Azure, servizi di bilanciamento del carico di Azuree routing del traffico di rete virtuale.

Quando si sceglie l'opzione migliore per distribuire un'appliance virtuale di rete in una rete virtuale di Azure, l'aspetto più importante da considerare è se il fornitore dell'appliance virtuale di rete ha verificato e convalidato tale progettazione specifica. 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 alternative diverse come opzioni di progettazione supportate per un'appliance virtuale di rete, questi fattori possono influenzare la decisione:

• Tempo di convergenza: quanto tempo è necessario in ogni progettazione per allontanare il traffico da un'istanza di appliance virtuale di rete non riuscita?
• Supporto della topologia: quali configurazioni dell'appliance virtuale di rete supportano ogni opzione di progettazione? Cluster di appliance virtuali di rete attivi/attivi, attivi/standby, con scalabilità orizzontale con ridondanza n+1?
• Simmetria del traffico: una particolare progettazione impone all'appliance virtuale di rete di eseguire SNAT (Source Network Address Translation) sui pacchetti per evitare il routing asimmetrico? Oppure la simmetria del traffico viene applicata da altri mezzi?

Le sezioni seguenti del documento descrivono le architetture più comuni usate per integrare appliance virtuali di rete in una rete Hub-Spoke.

Panoramica delle architetture a disponibilità elevata

Le seguenti architetture descrivono le risorse e la configurazione necessarie per le NVAs a disponibilità elevata.

Progettazione di Load Balancer

Questa progettazione usa due servizi di bilanciamento del carico di Azure per esporre un cluster di appliance virtuali di rete al resto della rete. L'approccio viene spesso usato sia per le appliance virtuali di rete con stato che per le appliance virtuali di rete senza stato:

• Un servizio di bilanciamento del carico interno viene usato per reindirizzare il traffico interno da Azure e in locale alle appliance virtuali di rete. Questo servizio di bilanciamento del carico interno viene configurato con le regole porte a disponibilità elevata, in modo che ogni porta TCP/UDP venga reindirizzata alle istanze dell'appliance virtuale di rete.
• Un servizio di bilanciamento del carico pubblico espone le appliance virtuali di rete a Internet. Poiché porte a disponibilità elevata per il traffico in ingresso, ogni singola porta TCP/UDP deve essere aperta in una regola di bilanciamento del carico dedicata.

Il diagramma seguente descrive la sequenza di hop che i pacchetti da Internet a un server applicazioni in una rete virtuale spoke seguiranno l'attraversamento di un'appliance virtuale di rete del firewall per controllare il traffico da/verso Internet pubblico (detto anche traffico nord/sud):

Scarica un file Visio di questa architettura.

Il meccanismo per inviare il traffico dagli spoke alla rete Internet pubblica tramite le appliance virtuali di rete è una route User-Defined per 0.0.0.0/0 con 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'altra istanza di Azure Load Balancer. Ciò si verifica anche se l'appliance virtuale di rete del firewall ha una singola scheda di interfaccia di rete per le reti pubbliche e interne, poiché il pacchetto di ingresso passa attraverso il pacchetto ALB pubblico e il pacchetto in uscita passa attraverso il servizio di bilanciamento del carico interno. Poiché entrambe le direzioni del flusso che passano attraverso servizi di bilanciamento del carico diversi, se è necessaria la simmetria del traffico, come avviene in genere nella maggior parte dei firewall, è necessario eseguire SNAT (Source Network Address Translation) dalle istanze dell'appliance virtuale di rete per attirare il traffico di ritorno ed evitare l'asimmetria del traffico.

La stessa progettazione con i servizi di bilanciamento del carico può essere usata anche per esaminare il traffico tra le reti di Azure e locali (Est/Ovest), in cui è coinvolto solo un servizio di bilanciamento del carico interno:

Il meccanismo per inviare il traffico tra spoke attraverso le appliance virtuali di rete è esattamente lo stesso, quindi non viene fornito alcun altro diagramma. Nei diagrammi di esempio precedenti, poiché spoke1 non conosce l'intervallo spoke2, il 0.0.0.0/0 route definita dall'utente invia il traffico indirizzato a spoke2 all'appliance virtuale di rete interna di Azure Load Balancer.

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 la stessa istanza di Azure Load Balancer, la stessa istanza dell'appliance virtuale di rete verrà scelta dal servizio di bilanciamento del carico. Nel caso di appliance virtuali di rete dual-NIC in cui è presente un servizio di bilanciamento del carico interno per ogni senso della comunicazione, la simmetria del traffico deve essere fornita tramite SNAT come nell'esempio nord/sud precedente.

Un'altra sfida che le appliance virtuali di rete dual-NIC affrontano in questa progettazione è la posizione in cui inviare le risposte ai controlli di integrità del servizio di bilanciamento del carico. Azure Load Balancer usa sempre lo stesso indirizzo IP dell'origine per i controlli di integrità (168.63.129.16). L'appliance virtuale di rete deve essere in grado di inviare la risposta all'origine del controllo integrità da questo indirizzo IP nella stessa interfaccia ricevuta. Questo richiede in genere più tabelle di routing in un sistema operativo, poiché il routing basato su destinazione invierebbe sempre la risposta ai controlli di integrità tramite la stessa scheda di interfaccia di rete.

Azure Load Balancer ha un buon tempo di convergenza nelle singole interruzioni dell'appliance virtuale di rete. Poiché i probe di integrità possono essere inviati ogni 5 secondi e sono necessari 3 probe non riusciti per dichiarare un'istanza back-end fuori servizio, in genere sono necessari 10-15 secondi per il bilanciamento del carico di Azure 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 dell'appliance virtuale di rete devono offrire una porta TCP/UDP o un endpoint HTTP che risponde solo ai probe di integrità di Load Balancer per l'istanza del ruolo attivo.

Uso dei servizi di bilanciamento del carico L7

Un caso specifico di questa progettazione per le appliance di sicurezza consiste nel sostituire Il servizio di bilanciamento del carico pubblico di Azure con un servizio di bilanciamento del carico di livello 7, ad esempio il gateway applicazione di Azure (che può essere considerato come un'appliance virtuale di rete da sola). In questo caso, le appliance virtuali di rete richiedono solo un servizio di bilanciamento del carico interno per il traffico proveniente dai sistemi del carico di lavoro. Questo meccanismo viene talvolta usato dai dispositivi dual-NIC per evitare il problema di routing con i controlli di integrità di Azure Load Balancer descritti nella sezione precedente. Una restrizione di questa progettazione è che supporta solo i protocolli di livello 7 supportati dal servizio di bilanciamento del carico di livello 7, in genere HTTP(S).

L'appliance virtuale di rete deve eseguire il traffico in ingresso per i protocolli non supportati dal servizio di bilanciamento del carico di livello 7, oltre a tutto il traffico in uscita. Per altre informazioni su questa configurazione quando si usa Firewall di Azure come appliance virtuale di rete e il gateway applicazione di Azure come proxy inverso Web di livello 7, vedere Firewall e gateway applicazione per le reti virtuali.

Azure Route Server

server di route di Azure è un servizio che consente a un'appliance virtuale di rete di interagire con SDN di Azure tramite BGP (Border Gateway Protocol). Non solo le appliance virtuali di rete apprendono quali prefissi IP esistono nelle reti virtuali di Azure, ma sono in grado di inserire route nelle tabelle di route valide delle macchine virtuali in Azure.

Nel diagramma precedente ogni istanza dell'appliance virtuale di rete viene eseguito il peering su BGP con il server di route di Azure. Nelle subnet spoke non è necessaria alcuna tabella di route, perché il server di route di Azure programma le route annunciate dalle appliance virtuali di rete. Se due o più route sono programmate nelle macchine virtuali di Azure, usano Equal Cost MultiPathing (ECMP) per scegliere una delle istanze dell'appliance virtuale di rete per ogni flusso di traffico. Di conseguenza, SNAT è un must in questa progettazione se la simmetria del traffico è un requisito.

Questo metodo di inserimento supporta entrambe le appliance virtuali di rete attive/attive (tutte le appliance virtuali di rete annunciano le stesse route al server di route di Azure) e attivo/standby (un'appliance virtuale di rete annuncia le route con un percorso AS più breve rispetto all'altro). Il server di route di Azure supporta un massimo di 8 ajacenci BGP. Pertanto, se si usa un cluster di appliance virtuali di rete attive con scalabilità orizzontale, questa progettazione supporta un massimo di 8 istanze di appliance virtuali di rete.

Il tempo di convergenza è veloce in questa configurazione ed è influenzato dai timer keepalive e holdtime dell'adiacenza BGP. Mentre il server di route di Azure ha timer keepalive e holdtime predefiniti (rispettivamente 60 secondi e 180 secondi), le appliance virtuali di rete possono negoziare timer inferiori durante l'impostazione dell'adiacenza BGP. L'impostazione di questi timer troppo bassa potrebbe causare instabilità BGP.

Questa progettazione è l'opzione più comune per le appliance virtuali di rete che devono interagire con il routing di Azure, ad esempio le appliance virtuali di rete SDWAN o IPsec che in genere hanno un buon supporto BGP e devono apprendere i prefissi configurati nelle reti virtuali di Azure o annunciare determinate route tramite peering privati ExpressRoute. Questo tipo di appliance è in genere senza stato, in modo che la simmetria del traffico non sia un problema e quindi SNAT non è necessario.

Bilanciamento del carico del gateway

servizio di bilanciamento del carico del gateway di Azure è un nuovo modo per inserire appliance virtuali di rete nel percorso dati senza dover indirizzare il traffico con route User-Defined. Per le macchine virtuali che espongono i carichi di lavoro tramite azure Load Balancer o un indirizzo IP pubblico, il traffico in ingresso e in uscita può essere reindirizzato in modo trasparente a un cluster di appliance virtuali di rete che si trova in una rete virtuale diversa. Il diagramma seguente descrive il percorso che i pacchetti seguono per il traffico in ingresso da Internet pubblico nel caso in cui i carichi di lavoro espongono l'applicazione tramite Azure Load Balancer:

Uno dei principali vantaggi di questo metodo di inserimento dell'appliance virtuale di rete è che SNAT (Source Network Address Translation) non è necessario per garantire la simmetria del traffico. Un altro vantaggio di questa opzione di progettazione è che è possibile usare le stesse appliance virtuali di rete per controllare il traffico da e verso reti virtuali diverse, ottenendo così la multi-tenancy dal punto di vista dell'appliance virtuale di rete. Non è necessario alcun peering reti virtuali tra la rete virtuale di appliance virtuale di rete e le reti virtuali del carico di lavoro e non sono necessarie User-Defined route nella rete virtuale del carico di lavoro, che semplifica notevolmente la configurazione.

L'inserimento del servizio con Il servizio di bilanciamento del carico gateway può essere usato per i flussi in ingresso che colpiscono un servizio di bilanciamento del carico pubblico di Azure (e il relativo traffico restituito) e per i flussi in uscita originati in Azure. East-West traffico tra macchine virtuali di Azure non può sfruttare il servizio di bilanciamento del carico del gateway per l'inserimento di appliance virtuali di rete.

Nel cluster appliance virtuale di rete i probe di controllo dell'integrità di Azure Load Balancer vengono usati per rilevare singoli errori dell'istanza dell'appliance virtuale di rete, ottenendo un tempo di convergenza rapido (10-15 secondi).

Modifica PIP-UDR

L'idea alla base di questa progettazione è avere la configurazione necessaria senza ridondanza dell'appliance virtuale di rete e modificarla nel caso in cui l'appliance virtuale di rete subisca tempi di inattività. Il diagramma seguente mostra come un indirizzo IP pubblico di Azure è associato all'appliance virtuale di rete attiva (NVA1) e le route User-Defined negli spoke hanno l'indirizzo IP dell'appliance virtuale di rete attiva come hop successivo (10.0.0.37).

Se l'appliance virtuale di rete attiva non è più disponibile, l'appliance virtuale di rete di standby chiamerà l'API di Azure per eseguire nuovamente il mapping dell'indirizzo IP pubblico e l'User-Defined route spoke a se stessa (o spostare anche l'indirizzo IP privato). Queste chiamate API possono richiedere alcuni minuti per essere efficaci, motivo per cui questa progettazione offre il peggiore tempo di convergenza di tutte le opzioni in questo documento.

Un'altra limitazione di questa progettazione è che sono supportate solo configurazioni attive/standby, che possono causare problemi di scalabilità: se è necessario aumentare la larghezza di banda supportata dalle appliance virtuali di rete, l'unica opzione con questa progettazione è aumentare le istanze di entrambe le istanze.

Uno dei vantaggi di questa progettazione è che non è necessaria alcuna SNAT (Source Network Address Translation) per garantire la simmetria del traffico, poiché è presente una sola appliance virtuale di rete attiva in un determinato momento.

Contributori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

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.

Passaggi successivi

• Informazioni su come implementare una rete ibrida sicura usando Firewall di Azure.
• reti perimetrali - Cloud Adoption Framework
• rete perimetrale cloud - Cloud Adoption Framework