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 un Rete virtuale di zona de-militarizzata (DMZ) e Internet pubblico.
Esistono diversi 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.
Esistono molti esempi di appliance virtuali di rete, ad esempio firewall di rete, proxy inverso di livello 4, endpoint VPN IPsec, proxy inverso basati sul Web con funzionalità web application firewall, proxy Internet per limitare quali pagine Internet è possibile accedere da Azure, servizi di bilanciamento del carico di livello 7 e molti altri. Tutti possono essere inseriti 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 app Azure lication Gateway, usano le progettazioni descritte 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 smetteranno di funzionare. Le interruzioni pianificate e non pianificate possono e talvolta comportano 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 richiederanno 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, dei servizi di bilanciamento del carico di Azure e del routing del traffico 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 esaminato 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.
Nota
Questo articolo è incentrato sulle progettazioni hub-spoke. rete WAN virtuale non viene trattato, poiché rete WAN virtuale è molto più prescrittivo sulla modalità di distribuzione delle appliance virtuali di rete, a seconda che un'appliance virtuale di rete specifica sia supportata negli hub rete WAN virtuale. Per altre informazioni, vedere Appliance virtuali di rete nell'hub rete WAN virtuale.
Panoramica delle architetture a disponibilità elevata
Le architetture seguenti descrivono le risorse e la configurazione necessarie per le appliance virtuali di rete a disponibilità elevata:
| Soluzione | Vantaggi | Considerazioni |
|---|---|---|
| Azure Load Balancer | Supporta appliance virtuali di rete attive/attive, attive/standby e con scalabilità orizzontale. Tempo di convergenza molto buono | L'appliance virtuale di rete deve fornire una porta per i probe di integrità, in particolare per le distribuzioni attive/standby. I flussi da/verso Internet richiedono SNAT per la simmetria |
| Azure Route Server | L'appliance virtuale di rete deve supportare BGP. Supporta appliance virtuali di rete attive/attive, attive/standby e con scalabilità orizzontale. | La simmetria del traffico richiede SNAT |
| Bilanciamento del carico del gateway | La simmetria del traffico è garantita senza SNAT. Le appliance virtuali di rete possono essere condivise tra tenant. Tempo di convergenza molto buono. Supporta appliance virtuali di rete attive/attive, attive/standby e con scalabilità orizzontale. | Supporta i flussi da/verso Internet, senza flussi east-west |
| Modifica di PIP/UDR | Nessuna funzionalità speciale richiesta dall'appliance virtuale di rete. Garantisce il traffico simmetrico | Solo per progetti attivi/passivi. Tempo di convergenza elevato di 1-2 minuti |
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:
- 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 è configurato con 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é le porte a disponibilità elevata sono 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 seguono:
Scaricare un file di Visio di questa architettura.
Il meccanismo per inviare il traffico dagli spoke alla rete Internet pubblica tramite le appliance virtuali di rete è una route definita dall'utente 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 di traffico attraverserà un servizio di bilanciamento del carico di Azure diverso (il pacchetto in ingresso attraverso il alB pubblico e il pacchetto in uscita attraverso il servizio di bilanciamento del carico interno). Di conseguenza, se è necessaria la simmetria del traffico, è 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.
Questa progettazione può essere usata anche per esaminare il traffico tra azure e le reti locali:
Il meccanismo per inviare il traffico tra spoke attraverso le appliance virtuali di rete è esattamente lo stesso, quindi non viene fornito alcun diagramma aggiuntivo. Nei diagrammi di esempio precedenti, poiché spoke1 non conosce l'intervallo spoke2, la 0.0.0.0/0 route definita dall'utente invierà 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 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, verrà scelta la stessa istanza dell'appliance virtuale di rete.
Azure Load Balancer ha un tempo di convergenza molto valido in caso di interruzioni delle singole appliance virtuali 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. Tuttavia, per le configurazioni attive/standby, le istanze dell'appliance virtuale di rete devono offrire una porta TCP/UDP o un endpoint HTTP che non risponde ai probe di integrità di Load Balancer, a meno che l'istanza non si trova nel ruolo attivo.
Uso dei servizi di bilanciamento del carico L7
Un caso specifico di questa progettazione consiste nel sostituire Load Balancer pubblico di Azure con un servizio di bilanciamento del carico di livello 7, ad esempio il gateway di app Azure lication ( che può essere considerato come un'appliance virtuale di rete autonomamente). In questo caso, le appliance virtuali di rete richiederanno solo un servizio di bilanciamento del carico interno, poiché il traffico proveniente dalla gateway applicazione verrà originato dall'interno della rete virtuale e l'asimmetria del traffico non è un problema.
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 altri dettagli su questa configurazione quando si usa Firewall di Azure come appliance virtuale di rete e gateway di app Azure lication come proxy inverso Web di livello 7, vedere Firewall e gateway applicazione per le reti virtuali.
Server di route Azure
Il 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 apprenderanno quali prefissi IP esistono nelle reti virtuali di Azure, ma saranno 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, poiché 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, useranno 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), nonché 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 supporterà un massimo di 8 istanze di appliance virtuali di rete.
Il tempo di convergenza è piuttosto veloce in questa configurazione e sarà 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 appliance virtuali di rete di terminazione VPN che devono apprendere i prefissi configurati nelle reti virtuali di Azure o annunciare determinate route tramite peering privati di ExpressRoute.
Load Balancer Gateway
Il 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 definite dall'utente. Per 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 route definite dall'utente 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), nonché per i flussi in uscita originati in Azure. Il traffico east-west 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 NVA i probe di controllo dell'integrità di Azure Load Balancer verranno usati per rilevare i singoli errori dell'istanza dell'appliance virtuale di rete, ottenendo un tempo di convergenza molto rapido (10-15 secondi).
Modifica della route definita dall'utente PIP
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 definite dall'utente negli spoke hanno l'indirizzo IP dell'appliance virtuale di rete attivo 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 le route definite dall'utente spoke verso se stesso (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.
Collaboratori
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
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