Il gateway NCC è un tipo di spoke che può essere collegato all'hub del Network Connectivity Center (NCC). È un prodotto regionale che abilita la sicurezza per il traffico Cross-Cloud Network. Il gateway NCC consente di abilitare le funzionalità di sicurezza, come Security Service Edge (SSE) di terze parti, un componente di sicurezza fornito dal cloud di Secure Access Service Edge (SASE). Gli spoke del gateway NCC supportano la connettività diretta ai collegamenti VLAN di Cloud Interconnect.
Il gateway NCC offre le seguenti funzionalità:
- Integrazione semplificata di SSE: puoi integrare SSE, come Palo Alto Networks Prisma Access e Symantec Cloud Secure Web Gateway (anteprima) senza problemi con lo steering trasparente per migliorare la protezione e il rendimento da utente ad applicazione. Il gateway NCC consente di abilitare le funzionalità di sicurezza per il traffico cross-cloud.
- Alta affidabilità: puoi utilizzare il gateway NCC per uno SLA di uptime del 99,9% per ridurre al minimo le interruzioni.
- Deployment regionale: puoi eseguire il deployment del gateway NCC in una serie di regioni in base alla vicinanza fisica ai data center, ai fornitori di SSE di terze parti o ad altri provider cloud in cui risiedono le tue applicazioni.
- Forza lavoro remota sicura: puoi connettere in modo sicuro le forze lavoro remote, ad esempio quelle di filiali, data center e uffici remoti, ad applicazioni private in Google Cloud, on-premise o altri provider cloud e ad applicazioni pubbliche.
Vantaggi
Il gateway NCC offre i seguenti vantaggi:
Esperienza applicativa ottimale con latenza ridotta: consumo di servizi SSE cloud-first a larghezza di banda elevata con il gateway NCC e prestazioni migliorate grazie al backbone privato di Google.
Sicurezza unificata per tutto il traffico utente: security posture migliorata con un unico stack di sicurezza unificato e superficie di attacco ridotta limitando i punti in entrata e in uscita.
Gestione semplificata tramite NCC.
Termini chiave
Per comprendere il gateway NCC, familiarizza con la seguente terminologia:
Collegamento ibrido: collegamenti VLAN associati a un gateway NCC.
Funzione del servizio di sicurezza: servizi collegati al gateway NCC. Ad esempio, per la protezione da utente ad applicazione, devi collegare un servizio SSE al gateway NCC.
Rete VPC dell'applicazione o del carico di lavoro: una rete VPC del carico di lavoro è in genere una rete che utilizza macchine virtuali (VM) di Compute Engine o container di Google Kubernetes Engine (GKE) come carichi di lavoro. Le reti VPC del carico di lavoro possono essere reti VPC normali o reti VPC condivise con un progetto host e più progetti di servizio. Le reti VPC del carico di lavoro devono essere configurate come spoke nell'hub.
Gruppi di spoke: un modo per raggruppare gli spoke all'interno di un hub NCC. I gruppi di spoke consentono di separare gli spoke in domini di routing diversi. Un gruppo di spoke può contenere più spoke, ma uno spoke può appartenere a un solo gruppo. Per informazioni dettagliate sui gruppi di spoke per topologie diverse, vedi Topologie di connettività preimpostate.
Topologia di ispezione ibrida: consente di aggiungere spoke del gateway NCC a un gruppo per applicare le policy. Per informazioni sulla topologia di ispezione ibrida, vedi Topologia di ispezione ibrida.
Secure Access Connect: consente di connettere prodotti SSE di terze parti al gateway NCC per l'elaborazione della sicurezza e l'uscita sicura da internet. Per informazioni su Secure Access Connect, vedi Panoramica di Secure Access Connect.
Prodotti SSE supportati
Il gateway NCC supporta le connessioni ai seguenti prodotti SSE:
Casi d'uso
Il gateway NCC è ideale per le organizzazioni che vogliono proteggere l'accesso alle applicazioni della forza lavoro ibrida. Il gateway NCC fornisce sicurezza per la forza lavoro ibrida tramite un ecosistema di partner integrato per consentirti di connetterti ai fornitori di SSE di tua scelta. Questo approccio è applicabile sia ai deployment NCC nuovi (greenfield) sia a quelli esistenti (brownfield).
Il gateway NCC consente di proteggere l'accesso ad applicazioni private ospitate in Google Cloud, on-premise, in altri provider cloud e ad applicazioni pubbliche ospitate su internet e applicazioni SaaS. Il gateway NCC consente di creare deployment regionali per una vicinanza ottimale ai data center e di gestire il traffico tra regioni sul backbone privato di Google Cloud.
I casi d'uso per Google Cloud gli utenti includono il supporto per le seguenti modalità di connessione:
- Utenti della filiale a internet
- Utenti della filiale ad applicazioni private
- Applicazioni private a internet
I casi d'uso per alcuni partner supportati includono la connessione di uno o più dei seguenti elementi:
- Utenti di dispositivi mobili a internet
- Utenti di dispositivi mobili ad applicazioni private
- Utenti della filiale ad applicazioni partner
- Applicazioni private ad applicazioni partner
Flussi di traffico
Questa sezione descrive i percorsi del flusso di traffico nel gateway NCC a seconda di ogni caso d'uso.
Flusso di traffico nei casi d'uso per gli Google Cloud utenti
Utenti della filiale a internet
Nel seguente diagramma, il traffico scorre da un utente della filiale on-premise attraverso il gateway NCC e lo stack SSE di terze parti a internet.
Utenti della filiale ad applicazioni private
Nel seguente diagramma, il traffico scorre dall'utente della filiale on-premise attraverso il gateway NCC, attraversa l'SSE di terze parti e poi torna attraverso il gateway NCC a un'applicazione privata.
Applicazioni private a internet
Nel seguente diagramma, il traffico scorre da Google Cloud attraverso il gateway NCC, attraversa l'SSE di terze parti a internet e poi torna al gateway NCC alla VM.
Flusso di traffico nei casi d'uso per i partner supportati
Utenti di dispositivi mobili a internet
Nel seguente diagramma, il traffico scorre dagli utenti di dispositivi mobili attraverso l'SSE di terze parti a internet. In questo caso, il traffico non passa attraverso il gateway NCC.
Utenti di dispositivi mobili ad applicazioni private
Nel seguente diagramma, il traffico scorre dagli utenti di dispositivi mobili attraverso il servizio SSE di terze parti e il gateway NCC a un'applicazione privata ospitata in una rete VPC.
Utenti della filiale ad applicazioni partner
Nel seguente diagramma, il traffico scorre dall'utente della filiale on-premise attraverso il gateway NCC, attraversa l'SSE di terze parti e poi torna attraverso il gateway NCC alla filiale on-premise.
Utenti di dispositivi mobili ad applicazioni private nella filiale
Nel seguente diagramma, il traffico scorre dagli utenti di dispositivi mobili alle applicazioni private nella filiale attraverso il gateway NCC.
Capacità di elaborazione
La capacità di elaborazione di uno spoke del gateway NCC è la larghezza di banda di cui è stato eseguito il provisioning. Devi eseguire il provisioning di una larghezza di banda sufficiente per tenere conto di ogni direzione del flusso di traffico, tenendo presente che i pacchetti potrebbero entrare e uscire dallo spoke del gateway più di una volta per ogni direzione del flusso per alcuni flussi di traffico.
Considera i seguenti esempi per calcolare la capacità di elaborazione richiesta di uno spoke del gateway.
Esempio: utenti della filiale a internet
Supponiamo che la rete on-premise di una filiale sia connessa a internet come mostrato nel caso d'uso Utenti della filiale a internet. I pacchetti attraversano il gateway NCC una volta in ogni direzione e la filiale e internet hanno bisogno di una larghezza di banda full-duplex di 1 Gbps: 1 Gbps per il traffico dalla rete on-premise della filiale a internet e 1 Gbps per il traffico da internet alla rete della filiale. In questo caso, l'utente ha bisogno di 2 Gbps di capacità di elaborazione. Questo esempio presuppone anche che il partner SSE non elimini alcun pacchetto. Se il partner SSE scelto consiglia una larghezza di banda superiore a quella calcolata in questo esempio, segui il consiglio del partner.
Esempio: utenti della filiale ad applicazioni private
Supponiamo che la rete on-premise di una filiale sia connessa a Google Cloud come mostrato nel caso d'uso Utenti della filiale ad applicazioni private e che la filiale e le applicazioni private abbiano bisogno di una larghezza di banda full-duplex di 1 Gbps: 1 Gbps per il traffico dalla filiale alle applicazioni e 1 Gbps per il traffico dalle applicazioni alla filiale. Questo esempio presuppone anche che il partner SSE non elimini alcun pacchetto. Se il partner SSE scelto consiglia una larghezza di banda superiore a quella calcolata in questo esempio, segui il consiglio del partner.
Lo spoke del gateway NCC che connette la rete on-premise della filiale all'hub NCC ha bisogno di due collegamenti VLAN da 1 Gbps per soddisfare i requisiti dello SLA di Cloud Interconnect. In questo modo, è possibile che un collegamento VLAN fornisca 1 Gbps di larghezza di banda full-duplex tra la filiale e le applicazioni private anche quando un collegamento VLAN è offline (ad esempio, a causa della manutenzione della connessione Interconnect).
La capacità di elaborazione richiesta dello spoke del gateway è di 4 Gbps per i seguenti motivi:
Il traffico dalla rete on-premise della filiale all'hub NCC richiede 1 Gbps di larghezza di banda. Questo traffico richiede 2 Gbps di larghezza di banda del gateway perché viene elaborato dal gateway nei due punti seguenti:
- 1 Gbps quando i pacchetti dai collegamenti VLAN che si connettono alla filiale entrano nello spoke del gateway
- 1 Gbps quando i pacchetti lasciano lo spoke del gateway ed entrano nell'hub
Anche il traffico dall'hub NCC alla rete on-premise della filiale richiede 1 Gbps di larghezza di banda. Questo traffico richiede altri 2 Gbps di larghezza di banda del gateway perché viene elaborato dal gateway nei due punti seguenti:
- 1 Gbps quando i pacchetti lasciano l'hub ed entrano nello spoke del gateway
- 1 Gbps quando i pacchetti lasciano lo spoke del gateway e vengono inviati ai collegamenti VLAN che si connettono alla filiale
Ti consigliamo la seguente strategia per configurare la capacità di elaborazione del gateway e la larghezza di banda del collegamento VLAN:
- La capacità di elaborazione del gateway è la somma della larghezza di banda richiesta, in ogni direzione, tra tutte le NIC del gateway.
- A differenza della capacità di elaborazione del gateway, la larghezza di banda del collegamento VLAN è full-duplex. Esegui sempre il provisioning di un numero sufficiente di collegamenti VLAN per supportare la larghezza di banda richiesta, anche se i collegamenti VLAN che utilizzano una connessione Interconnect comune sono inattivi.
Considerazioni
Per utilizzare il gateway NCC, si applicano le seguenti limitazioni:
- Puoi collegare solo i collegamenti VLAN di Cloud Interconnect agli spoke del gateway NCC. I tunnel Cloud VPN e le appliance router non sono supportati.
- Gli spoke del gateway NCC per tutte le regioni devono trovarsi nello stesso gruppo di spoke gateway. Per un deployment greenfield del gateway NCC, gli hub NCC devono utilizzare la topologia di ispezione ibrida preimpostata. Per un deployment brownfield, puoi utilizzare la topologia a stella o full mesh esistente.
- A un gateway NCC può essere collegato un solo servizio alla volta.
- Un router Cloud deve essere collegato a un gateway NCC nella stessa regione.
- Al gateway vengono collegati solo i collegamenti VLAN di Cloud Interconnect creati con un router Cloud collegato a un gateway NCC.
- Puoi avere un solo spoke del gateway NCC per regione per hub.
- Gli spoke e l'hub del gateway NCC devono trovarsi nello stesso progetto.
- Devi specificare la capacità di elaborazione al momento della creazione dello spoke del gateway. Se necessario, la capacità di elaborazione può essere modificata in un secondo momento.
- Non puoi modificare gli intervalli di indirizzi IP assegnati. Alcuni intervalli di indirizzi IP sono riservati ai partner SSE.
- Non esiste una policy di steering del traffico per ignorare un sottoinsieme di traffico dal gateway NCC.
- Se configuri una route annunciata dal gateway nello spoke del gateway, devi creare un gateway SSE attivo per propagare questa route alla tabella di route dell'hub NCC.
- Puoi visualizzare le route annunciate dal gateway nella tabella di route della rete VPC o nella tabella di route dell'hub del gruppo di spoke in cui si trova la rete VPC.
Le route annunciate dal gateway vengono programmate utilizzando la modalità di selezione del percorso migliore standard :
- La priorità delle route annunciate dal gateway nella tabella di route dell'hub riflette la priorità effettiva della route Andromeda, ad esempio
65536o65537. La priorità con cui viene creata la route annunciata dal gateway viene presa in considerazione quando si calcola la priorità effettiva della route Andromeda. - Le route statiche hanno sempre una priorità compresa tra
0-65535e, pertanto, hanno la precedenza sulle route annunciate dal gateway per lo stesso prefisso di destinazione. Pertanto, se vuoi indirizzare il traffico internet al gateway utilizzando una route annunciata dal gateway con una destinazione0/0, potresti dover rimuovere la route predefinita generata dal sistema. Se rimuovi la route predefinita con l'hop successivo del gateway internet predefinito, devi creare route speciali per le API di Google e i servizi o utilizzare gli endpoint Private Service Connect per le API di Google globali.
- La priorità delle route annunciate dal gateway nella tabella di route dell'hub riflette la priorità effettiva della route Andromeda, ad esempio
Limitazioni basate sulla capacità
Le seguenti limitazioni si basano sulla capacità del link disponibile in una regione:
- Alcuni partner potrebbero non supportare 100 Gbps.
- Alcune regioni potrebbero supportare solo 1 Gbps e 10 Gbps, ma non 100 Gbps.
Limitazioni MTU
I collegamenti VLAN di Cloud Interconnect associati a uno spoke del gateway NCC devono utilizzare un MTU di 1500 byte.
Aggiornamenti dell'intervallo di indirizzi IP non supportati
Dopo la creazione dello spoke, non puoi modificare gli indirizzi IP assegnati. Alcuni intervalli di indirizzi IP sono riservati ai partner SSE.
Controlli di integrità
I controlli di integrità forniscono un'indicazione del degrado del servizio in una regione, in modo che tu possa intraprendere le azioni appropriate. Il sistema estrae un segnale di integrità aggregato attivato da uno stato di integrità non ottimale nei componenti chiave, inclusa l'analisi attiva del piano dati per monitorare l'integrità del percorso dei dati end-to-end tramite i servizi partner.
Lo stato di integrità del gateway NCC è disponibile come metrica di monitoraggio con un'etichetta healthy o unhealthy.
Quando viene stabilito che il gateway NCC non è integro, le sessioni BGP sul router Cloud al partner vengono arrestate. Il gateway NCC tenta di ristabilire le sessioni BGP quando torna a uno stato integro.
Puoi configurare gli avvisi in base alla metrica dello stato di integrità del gateway NCC.
Visualizzazione delle route operative per le tabelle di route dei gateway e dell'hub
Quando visualizzi una tabella di route dell'hub, devi selezionare una regione. Le route mostrate in una regione della tabella di route dell'hub includono le priorità che tengono conto dei costi interregionali, se applicabili.
Gli spoke del gateway hanno le proprie tabelle di route in cui devi selezionare un'interfaccia del gateway e una direzione del traffico. Per saperne di più, vedi Visualizzare le route dello spoke del gateway.
Esempio di percorso utente
Se sei un nuovo utente e non hai configurato la connettività preesistente, vedi Configurare il gateway NCC per i nuovi utenti.
Fatturazione
Per informazioni sui prezzi del gateway NCC, vedi Prezzi del gateway NCC.
Passaggi successivi
- Per scoprire come configurare il gateway NCC, vedi Panoramica della configurazione del gateway NCC.
- Per scoprire come configurare Secure Access Connect, vedi Creare un realm
- Per trovare soluzioni ai problemi comuni, vedi Risolvere i problemi di NCC.
- Per informazioni dettagliate sui comandi API e gcloud CLI, vedi API e riferimento.