Questo documento è destinato agli amministratori di rete, ai Solutions Architect e ai professionisti operativi che eseguono appliance di rete centralizzate su Google Cloud. È richiesta la conoscenza di Compute Engine e del networking VPC (Virtual Private Cloud) in Google Cloud.
Gli ambienti aziendali spesso devono instradare il traffico a internet, a una rete on-premise, ad altri cloud o anche ad altre parti dello stesso ambiente cloud tramite appliance virtualizzate basate su VM che monitorano, trasformano o bloccano il traffico.
Questo documento illustra diverse opzioni di progettazione che segmentano le reti VPC e le interconnettono con un'appliance di rete virtualizzata e centralizzata. Tutte le comunicazioni tra reti VPC, reti on-premise e internet vengono instradate attraverso il dispositivo centralizzato. Puoi eseguire il deployment di un gruppo di appliance ridondanti per ottenere una configurazione per l'alta disponibilità. Se non hai bisogno di un'alta disponibilità, puoi eseguire il deployment di una singola appliance di rete.
Indirizzare il traffico attraverso appliance virtualizzate può essere difficile. In Google Cloud, ad esempio, puoi sostituire la route che punta a internet e reindirizzare il traffico a un insieme di appliance virtualizzate, ma non è possibile modificare il comportamento di routing tra le subnet all'interno di una rete VPC. Il routing tra subnet è automatico e queste route non possono essere eliminate o sostituite.
Inoltre, dato il ruolo fondamentale delle appliance virtualizzate, il deployment deve avvenire in configurazioni ad alta disponibilità. Si tratta di un'operazione complessa perché devi garantire che tutto il traffico venga instradato attraverso una delle appliance virtuali e che il failover tra queste appliance sia automatico.
Architettura
Il seguente diagramma mostra un caso d'uso tipico di diverse opzioni di progettazione con un'appliance di rete virtualizzata e centralizzata.
Il diagramma precedente mostra i percorsi di comunicazione tra reti VPC segmentate, reti on-premise e internet e il modo in cui vengono instradate attraverso l'appliance di rete virtualizzata e centralizzata.
Casi d'uso principali per questa architettura
Puoi utilizzare questa architettura per più casi d'uso che coinvolgono appliance di rete virtualizzate attraverso cui viene instradato il traffico. Tieni presente le seguenti considerazioni:
- In Google Cloud Marketplace sono disponibili molte appliance di fornitori diversi.
- Alcuni fornitori di appliance offrono anche immagini Compute Engine personalizzate per Google Cloud sul proprio sito web o nelle pagine di assistenza.
- Puoi creare appliance virtualizzate utilizzando un software di rete open source. Puoi anche creare immagini personalizzate.
I fornitori spesso forniscono le proprie architetture di riferimento o guide al deployment per eseguire le appliance virtualizzate in una configurazione ad alta disponibilità. Per ulteriori informazioni, consultare il sito web del fornitore.
Le architetture di riferimento del fornitore potrebbero non comprendere tutte le opzioni presentate in questo documento.
È importante comprendere i vantaggi e gli svantaggi di ogni approccio. I casi d'uso tipici per le appliance virtuali attraverso cui viene instradato il traffico includono:
- Firewall di nuova generazione (NGFW). Un set centralizzato di firewall viene eseguito come macchine virtuali che offrono funzionalità che non sono disponibili se utilizzi le regole firewall VPC. Questo è il caso d'uso più comune. Le caratteristiche tipiche dei prodotti NGFW includono l'ispezione dei pacchetti profonda (DPI) e l'applicazione di firewall a livello di applicazione. Alcuni firewall NGFW forniscono anche l'ispezione del traffico TLS/SSL, nonché altre funzioni di networking descritte nei casi d'uso degli elenchi puntati che seguono.
- Sistema di rilevamento delle intrusioni/sistema di prevenzione delle intrusioni (IDS/IPS). Un IDS basato su rete richiede la visibilità di tutto il traffico potenzialmente dannoso. Per prevenire le intrusioni, il traffico è di solito bloccato direttamente da un IPS nel percorso del traffico.
- proxy trasparente. Un proxy trasparente viene spesso utilizzato per monitorare il traffico HTTP(S) e per applicare restrizioni all'accesso web.
- Gateway NAT (Network Address Translation). Un gateway NAT converte gli indirizzi IP e le porte. Questo consente, ad esempio, di evitare la sovrapposizione di indirizzi IP. Google Cloud offre Cloud NAT come servizio gestito, ma questo servizio è disponibile solo per il traffico Internet, non per il traffico on-premise o per altre reti VPC su Google Cloud.
- Web Application Firewall (WAF). Un WAF blocca il traffico HTTP dannoso indirizzato a un'applicazione web. Google Cloud offre la funzionalità WAF tramite i criteri di sicurezza di Google Cloud Armor. La funzionalità esatta varia a seconda dei fornitori WAF, quindi è importante determinare esattamente ciò di cui hai bisogno.
Requisiti tipici
I requisiti per il routing del traffico attraverso appliance virtuali centralizzate variano in base al caso d'uso specifico. Tuttavia, in genere si applicano i seguenti requisiti:
- Tutto il traffico tra diversi segmenti di rete, ad esempio gli ambienti amministrati da team diversi, con requisiti di sicurezza distinti o tra diversi moduli di un'applicazione, deve passare attraverso un'appliance virtuale centralizzata.
- Tutto il traffico da o verso internet verso ambienti sicuri deve passare attraverso un'appliance virtuale centralizzata.
- Tutto il traffico da o verso i sistemi on-premise connessi a Google Cloud tramite Cloud VPN, Dedicated Interconnect o Partner Interconnect deve passare attraverso un'appliance virtuale centralizzata.
- Più appliance virtuali centralizzate sono configurate in una configurazione ad alta disponibilità in configurazione attiva/attiva o attiva/passiva. Il failover si verifica automaticamente se si verificano problemi di software o hardware in una delle appliance virtualizzate.
- Tutto il traffico viene instradato in modo stateful, in modo che un flusso di traffico tra due macchine virtuali passi sempre attraverso la stessa appliance virtuale.
- La velocità effettiva del sistema di appliance virtuali centralizzate è scalabile in base a una delle due opzioni seguenti:
- Scalabilità verticale delle appliance virtuali, con aumento del numero di core o della quantità di memoria su ogni macchina virtuale.
- Scalabilità orizzontale delle appliance virtuali, con conseguente aumento del numero di appliance virtuali utilizzate per distribuire il traffico.
Opzioni di architettura
Esistono diverse opzioni per ottenere un'alta disponibilità tra appliance virtuali. Esistono anche diverse opzioni per collegare segmenti di rete alle appliance virtuali.
Puoi combinare qualsiasi opzione per l'alta disponibilità con qualsiasi opzione per il collegamento di segmenti di rete. Un'opzione comune descritta più avanti in questo documento è un'architettura che utilizza il peering di rete VPC e il bilanciatore del carico di rete passthrough interno come hop successivo.
Scelta di un'opzione per l'alta disponibilità
Puoi creare un'architettura per ottenere un'alta disponibilità per l'appliance centrale utilizzando più istanze nei due modi seguenti:
Utilizza un bilanciatore del carico di rete passthrough interno come hop successivo. In questo approccio, posizioni più appliance virtuali in un gruppo di istanze gestite dietro un bilanciatore del carico di rete passthrough interno. Questo bilanciatore del carico è utilizzato come hop successivo per una route predefinita che sostituisce la route predefinita nelle reti VPC connesse alle appliance. Puoi utilizzare le appliance in una configurazione attiva/attiva, ovvero la configurazione standard, o in una configurazione attiva/passiva, utilizzando il failover per i bilanciatori del carico di rete passthrough interni. I controlli di integrità indirizzano il traffico a istanze in stato integro. Se vuoi ricreare automaticamente le appliance in caso di errore, puoi utilizzare la autohealing. Se il dispositivo utilizza più interfacce di rete, un bilanciatore del carico di rete passthrough interno come hop successivo può avere backend su qualsiasi interfaccia di rete.
Il seguente diagramma mostra la topologia dell'utilizzo di un bilanciatore del carico di rete passthrough interno come hop successivo.
Il diagramma precedente mostra un gruppo di istanze gestite in una rete VPC, incluse più appliance virtuali che si trovano dietro un bilanciatore del carico di rete passthrough interno, che funge da hop successivo.
Usa i percorsi. In questo approccio, le route Google Cloud indirizzano il traffico alle appliance virtuali dalle reti VPC connesse. Puoi utilizzare le appliance in una configurazione attiva/passiva utilizzando route priorità diverse oppure in una configurazione attiva/attiva quando le route sono configurate con la stessa priorità, nel qual caso utilizzi il routing a percorso multiplo a costo uguale (ECMP) per distribuire il traffico. Puoi utilizzare la riparazione automatica per assicurarti che le appliance si riavviino quando non sono integri.
Il seguente diagramma mostra la topologia di utilizzo del routing.
Il diagramma precedente mostra un gruppo di istanze gestite in una rete VPC con route Google Cloud che indirizzano il traffico alle appliance virtuali dalla rete VPC connessa.
L'utilizzo di un bilanciatore del carico di rete passthrough interno come hop successivo presenta i seguenti vantaggi rispetto all'uso del routing di Google Cloud per l'alta disponibilità:
- I controlli di integrità determinano dove viene inoltrato il traffico, contribuendo a garantire che il traffico venga inoltrato solo a istanze integre. Puoi esporre i controlli di integrità in modo che l'istanza locale venga verificata o un percorso end-to-end.
- Puoi perfezionare i timer del controllo di integrità per un failover più rapido. Questo approccio fornisce i tempi di failover più rapidi in caso di istanze in stato non integro.
- Con l'hashing simmetrico, puoi garantire che il traffico di ritorno venga instradato alla stessa macchina virtuale del traffico in uscita.
L'utilizzo del routing di Google Cloud offre il seguente vantaggio:
- Un hashing simmetrico coerente garantisce che i pacchetti per una determinata connessione vengano elaborati dalla stessa VM di backend, sia per le richieste che per le risposte, a seconda del protocollo e della selezione di affinità sessione. La selezione di protocollo e affinità sessione determina se viene utilizzato o meno il monitoraggio delle connessioni. Tieni presente che alcuni casi d'uso potrebbero trarre vantaggio dall'avere una configurazione NAT (SNAT) di origine nelle istanze di backend; ad esempio, se una connessione delle risposte da una rete a un'altra deve corrispondere a una connessione di richiesta separata nella stessa direzione tra le stesse due reti.
L'utilizzo del routing di Google Cloud presenta i seguenti svantaggi:
- I controlli di integrità eliminano e ricreano le istanze in stato non integro dal pool di istanze. Tuttavia, il flusso di traffico non cambia immediatamente in risposta a controlli di integrità non riusciti perché occorre tempo per eliminare le istanze in stato non integro e crearne di nuove. Questo comporta tempi di failover più lenti.
- Se imposti timer per il controllo di integrità per evitare l'eliminazione e la creazione di istanze non necessarie, i tempi di failover saranno più lenti.
Sia che utilizzi un bilanciatore del carico di rete passthrough interno come hop successivo o il routing di Google Cloud, è supportato tutto il traffico di protocollo. Per informazioni dettagliate su questo supporto, consulta Elaborazione del traffico TCP, UDP e di altro protocollo.
Analogamente, entrambe le soluzioni supportano la limitazione delle route a determinati tag di rete. Ad esempio, le istanze VM possono essere segmentate per regione in modo da utilizzare set diversi di appliance.
Scelta di un'opzione per collegare segmenti di rete
Poiché non è possibile eseguire l'override del routing tra subnet, i segmenti di rete vengono implementati utilizzando reti VPC separate. Il traffico tra queste reti VPC, verso un ambiente on-premise e verso internet deve essere instradato attraverso le appliance centralizzate. Tieni presente che tutti questi segmenti di rete possono essere reti VPC autonome o reti VPC condivise.
Esistono diverse opzioni per il collegamento dei segmenti di rete, come indicato di seguito:
Interfacce di rete multiple. Il modo più semplice per connettere più reti VPC tramite un'appliance virtuale è utilizzare più interfacce di rete, ciascuna delle quali si collega a una delle reti VPC. La connettività internet e on-premise viene fornita su una o due interfacce di rete separate. In molti prodotti NGFW, la connettività a internet è connessa tramite un'interfaccia contrassegnata come non attendibile nel software NGFW.
Il seguente diagramma mostra questa topologia.
Il diagramma precedente mostra più reti VPC che si connettono tramite un'appliance virtuale utilizzando più interfacce di rete. Ogni interfaccia si connette a una delle reti VPC. Il diagramma mostra anche le connessioni internet e on-premise su interfacce di rete separate, tra cui una connessione a internet tramite un'interfaccia attendibile.
Peering di rete VPC. Questa topologia utilizza il concetto di hub e spoke in combinazione con il peering di rete VPC. I segmenti di rete sono implementati come un insieme di reti VPC spoke con peering mediante peering di rete VPC con una rete VPC hub, in cui il traffico viene instradato attraverso il pool centralizzato di appliance virtualizzate. La route predefinita o le route che puntano al bilanciatore del carico di rete passthrough interno come hop successivo, oppure direttamente alle appliance virtuali, vengono esportate come route personalizzate nel peering di rete VPC. La connettività internet e on-premise è fornita su una o due interfacce di rete separate.
Il seguente diagramma mostra questa topologia.
Il diagramma precedente mostra un pool centralizzato di appliance virtualizzate con più interfacce di rete collegate a più reti VPC hub. Ogni rete VPC hub è collegata a più reti VPC tramite il peering di rete VPC. Il traffico tra due reti VPC qualsiasi viene instradato attraverso il pool centralizzato di appliance virtualizzate.
Combinazione di più interfacce di rete e peering di rete VPC. Questo approccio combina le due opzioni precedenti per una maggiore scalabilità. Più interfacce di rete sono collegate a più reti VPC hub, ciascuna delle quali è connessa a reti VPC a più spoke tramite il peering di rete VPC. Per ogni rete VPC hub e spoke, viene utilizzato lo stesso approccio descritto nel caso del peering di rete VPC.
Il seguente diagramma mostra questa topologia.
Il diagramma precedente mostra una rete VPC hub collegata a più reti VPC tramite peering di rete VPC. Il traffico viene instradato attraverso il pool centralizzato di appliance virtualizzate con un'unica interfaccia di rete nella rete hub.
Il seguente albero decisionale può aiutarti a decidere l'approccio migliore per collegare i segmenti di rete.
L'utilizzo di più interfacce di rete, il primo approccio presentato nei casi precedenti, è l'approccio più semplice da implementare.
Tuttavia, l'utilizzo di più interfacce di rete presenta i seguenti svantaggi:
- Hai un limite di 8 interfacce di rete per istanza di macchina virtuale. Se utilizzi un'interfaccia di rete per la connettività internet e una per la connettività on-premise, puoi connettere solo 6 segmenti di rete su Google Cloud. Alcune appliance richiedono un'interfaccia di gestione aggiuntiva, con un limite di 5 segmenti di rete.
- Non puoi aggiungere o rimuovere interfacce di rete dopo aver creato un'istanza.
L'utilizzo del peering di rete VPC offre i seguenti vantaggi:
- Puoi fare lo scale up fino al limite di connessioni di peering di rete VPC da una singola rete VPC. Contatta il team di vendita Google Cloud se hai domande sull'aumento di questo limite.
- È facile aggiungere o rimuovere reti VPC da questa architettura configurando il peering di rete VPC.
Tuttavia, l'utilizzo del peering di rete VPC presenta i seguenti svantaggi:
- Questo approccio è leggermente più complesso rispetto a quello che utilizza più interfacce di rete.
- Il numero di VPC che è possibile connettere è ancora limitato rispetto all'approccio combinato.
L'utilizzo dell'approccio combinato, che prevede interfacce di rete multiple e peering di rete VPC, offre il seguente vantaggio:
- È l'approccio più scalabile perché il limite è un prodotto del limite delle interfacce di rete e del limite delle connessioni in peering VPC. Ad esempio, puoi connettere 6 reti VPC hub a interfacce di rete separate, in cui ogni interfaccia dispone di reti VPC a 25 spoke. Questo ti consente di avere un limite di 150 reti VPC che scambiano traffico attraverso un set di appliance virtuali.
Tuttavia, questo approccio presenta il seguente svantaggio:
- È l'approccio più complesso da implementare.
Architetture di esempio
Di seguito sono riportati due architetture di esempio. La prima architettura di esempio mostra come utilizzare il bilanciatore del carico di rete passthrough interno per l'alta disponibilità, in combinazione con il peering di rete VPC per il collegamento dei segmenti di rete. Il secondo esempio di architettura, un caso d'uso speciale, mostra come instradare il traffico da una singola rete VPC condivisa su Google Cloud verso un ambiente on-premise e verso internet.
Esempio di architettura che utilizza il peering di rete VPC e il bilanciatore del carico di rete passthrough interno come hop successivo
Questa architettura è un caso d'uso tipico per gli ambienti aziendali, che utilizza il bilanciatore del carico di rete passthrough interno per l'alta disponibilità, combinato con il peering di rete VPC per il collegamento di segmenti di rete.
Il seguente diagramma mostra la topologia di questa architettura.
Il diagramma precedente mostra una rete VPC hub e reti VPC a più spoke, connesse in peering con la rete VPC hub tramite peering di rete VPC. La rete VPC dell'hub ha 2 istanze di un'appliance virtuale in un gruppo di istanze gestite dietro un bilanciatore del carico di rete passthrough interno. Una route predefinita statica punta al bilanciatore del carico di rete passthrough interno come hop successivo. Questa route predefinita statica viene esportata nel peering di rete VPC utilizzando le route personalizzate. La route predefinita verso il gateway internet nelle reti VPC spoke viene eliminata.
Puoi soddisfare i requisiti nei seguenti modi:
- La connettività tra spoke viene instradata automaticamente attraverso il firewall poiché il peering di rete VPC non è transitorio, pertanto le reti VPC spoke non possono scambiare dati direttamente tra loro. Puoi configurare le appliance virtuali in modo da impostare le condizioni e i criteri in base ai quali gli spoke possono scambiare il traffico.
- La connettività a internet è possibile solo tramite le appliance virtuali, perché la route predefinita al gateway internet è stata rimossa dalle reti VPC spoke. Le appliance virtuali hanno una route predefinita attraverso un'interfaccia di rete separata, che può essere contrassegnata come non attendibile in caso di NGFW.
- La connettività alle reti on-premise viene raggiunta tramite una rete VPC di connettività connessa all'appliance virtuale su un'interfaccia di rete separata. Una connessione Cloud VPN o Cloud Interconnect termina in questa rete VPC di connettività.
- L'alta disponibilità è ottenuta tramite controlli di integrità personalizzati sul bilanciatore del carico interno. Puoi configurare le appliance come attive/passive utilizzando failover per i bilanciatori del carico di rete passthrough interni. Questo contribuisce a garantire che il traffico passi sempre attraverso una singola appliance virtuale.
Puoi utilizzare questa architettura di esempio se la comunicazione tra le diverse reti VPC è TCP/UDP o altro traffico di protocollo. È scalabile fino al limite di connessioni di peering di rete VPC per rete VPC.
Per un'implementazione di esempio di questa architettura con un gateway NAT come appliance virtuale, consulta Eseguire il deployment di una rete hub e spoke utilizzando un bilanciatore del carico come hop successivo. Puoi utilizzare lo stesso pattern per eseguire il deployment di altre appliance virtuali, come descritto nella sezione precedente sui casi d'uso.
Caso d'uso speciale con una rete VPC condivisa su Google Cloud
In un uso speciale, nessun traffico tra reti VPC diverse deve passare attraverso le appliance virtuali. Piuttosto, solo il traffico proveniente da una singola rete VPC condivisa viene instradato verso un ambiente on-premise e su internet. Puoi implementare questo caso d'uso utilizzando una qualsiasi delle opzioni ad alta disponibilità descritte in precedenza in questo documento, combinata con un'interfaccia di rete ciascuna, per la connettività alla rete VPC condivisa, on-premise e a Google Cloud. Se vuoi avere visibilità sul traffico tra subnet senza eseguirlo tramite appliance centralizzate, Mirroring pacchetto può aiutarti.
Il seguente diagramma mostra questa topologia.
Il diagramma precedente mostra il traffico da una singola rete VPC condivisa con routing verso una rete on-premise e su internet attraverso un pool di appliance virtuali.
Implementazione di un'architettura con appliance virtuali
Per informazioni sull'utilizzo del peering di rete VPC tra i segmenti e di un bilanciatore del carico di rete passthrough interno come opzione ad alta disponibilità, consulta Eseguire il deployment di una rete hub e spoke utilizzando un bilanciatore del carico come hop successivo.
Se vuoi eseguire il deployment di un'appliance da un partner Google Cloud da Cloud Marketplace, contatta il fornitore dell'appliance o cerca sul suo sito web le linee guida su come eseguire il deployment delle sue appliance in Google Cloud.
Passaggi successivi
- Best practice e architetture di riferimento per la progettazione di VPC.
- Topologie di rete ibride e multi-cloud.
- Best practice per la progettazione di rete nel framework dell'architettura Google Cloud.
- Documentazione di VPC.
- Documentazione del bilanciatore del carico di rete passthrough interno.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.