Panoramica di NCC Gateway

NCC Gateway è un tipo di spoke che può essere collegato all'hub Network Connectivity Center (NCC). Si tratta di un prodotto regionale che consente la sicurezza per il traffico di Cross-Cloud Network. NCC Gateway consente di attivare funzioni 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 Cloud Interconnect.

NCC Gateway offre le seguenti funzionalità:

  • Integrazione semplificata di SSE: puoi integrare SSE, come Palo Alto Networks Prisma Access e Symantec Cloud Secure Web Gateway (anteprima), in modo semplice con lo steering trasparente per migliorare la protezione e le prestazioni da utente ad applicazione. NCC Gateway ti consente di attivare funzioni di sicurezza per il traffico cross-cloud.
  • Alta affidabilità: puoi utilizzare NCC Gateway per uno SLA di uptime del 99,9% per ridurre al minimo le interruzioni.
  • Deployment regionale: puoi eseguire il deployment di NCC Gateway in una varietà di regioni in base alla vicinanza fisica ai data center, ai fornitori SSE di terze parti o ad altri fornitori di servizi 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

NCC Gateway offre i seguenti vantaggi:

  • Esperienza ottimale dell'applicazione con latenza ridotta: consumo cloud-first del servizio SSE con NCC Gateway e prestazioni migliorate tramite il backbone privato di Google.

  • Sicurezza unificata per tutto il traffico utente: migliore strategia di sicurezza con un unico stack di sicurezza unificato e superficie di attacco ridotta limitando i punti di ingresso e uscita.

  • Gestione semplificata tramite NCC.

Termini chiave

Per comprendere NCC Gateway, acquisisci familiarità con la seguente terminologia:

Collegamento ibrido: collegamenti VLAN che associ a un gateway NCC.

Funzione del servizio di sicurezza: servizi collegati a NCC Gateway. Ad esempio, per la protezione da utente ad applicazione, devi collegare un servizio SSE a NCC Gateway.

Rete Virtual Private Cloud (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 workload possono essere reti VPC regolari o reti VPC condivise con un progetto host e più progetti di servizio. Le reti VPC del workload devono essere configurate come spoke nell'hub.

Gruppi di spoke: un modo per raggruppare gli spoke all'interno di un hub NCC. I gruppi spoke consentono di separare gli spoke in domini di routing diversi. Un gruppo spoke può contenere più spoke, ma uno spoke può appartenere a un solo gruppo. Per informazioni dettagliate sui gruppi di spoke per diverse topologie, vedi Topologie di connettività preimpostate.

Topologia di ispezione ibrida: ti consente di aggiungere spoke gateway NCC a un gruppo per applicare i criteri. Per informazioni sulla topologia di ispezione ibrida, vedi Topologia di ispezione ibrida.

Secure Access Connect: consente di connettere prodotti SSE di terze parti a NCC Gateway 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

NCC Gateway supporta le connessioni ai seguenti prodotti SSE:

Casi d'uso

NCC Gateway è ideale per le organizzazioni che vogliono proteggere l'accesso alle applicazioni per la forza lavoro ibrida. NCC Gateway fornisce sicurezza per la forza lavoro ibrida attraverso un ecosistema di partner integrato per consentirti di connetterti ai fornitori di SSE che preferisci. Questo approccio è applicabile sia ai deployment NCC nuovi (greenfield) sia a quelli esistenti (brownfield).

NCC Gateway ti consente di proteggere l'accesso alle applicazioni private ospitate in Google Cloud, on-premise, in altri provider cloud e alle applicazioni pubbliche ospitate su internet e alle applicazioni SaaS. NCC Gateway consente di creare deployment regionali per una prossimità ottimale del data center e gestire il traffico tra regioni sul backbone privato di Google Cloud.

I casi d'uso per gli utenti di Google Cloud includono il supporto per le seguenti modalità di connessione:

  • Dirigere gli utenti della filiale a internet
  • Dirigere gli utenti verso 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
  • Dirigi gli utenti verso le applicazioni partner
  • Applicazioni private ad applicazioni partner

Flussi di traffico

Questa sezione descrive i percorsi del flusso di traffico in NCC Gateway a seconda di ogni caso d'uso.

Flusso di traffico nei casi d'uso per gli utenti Google Cloud

Dirigere gli utenti della filiale a internet

Nel seguente diagramma, il traffico scorre da un utente della filiale on-premise tramite NCC Gateway e lo stack SSE di terze parti a internet.

Dirigi gli utenti al flusso di traffico internet.
Dirigi gli utenti delle filiali al flusso di traffico internet (fai clic per ingrandire).

Dirigere gli utenti verso applicazioni private

Nel seguente diagramma, il traffico scorre dall'utente della filiale on-premise tramite il gateway NCC, attraversa l'SSE di terze parti e poi torna tramite il gateway NCC a un'applicazione privata.

Dirigi gli utenti verso un flusso di traffico dell'applicazione privato.
Dirigi gli utenti verso un flusso di traffico dell'applicazione privata (fai clic per ingrandire).

Applicazioni private a internet

Nel seguente diagramma, il traffico scorre da Google Cloud attraverso il gateway NCC, attraversa l'SSE di terze parti fino a internet, quindi torna al gateway NCC alla VM.

Applicazioni private al flusso di traffico internet.
Flusso di traffico da applicazioni private a internet (fai clic per ingrandire).

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 tramite l'SSE di terze parti a internet. In questo caso, il traffico non passa attraverso il gateway NCC.

Utenti di dispositivi mobili al flusso di traffico internet.
Flusso di traffico da utenti di dispositivi mobili a internet (fai clic per ingrandire).

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 di dispositivi mobili a un flusso di traffico dell'applicazione privata.
Flusso di traffico di un'applicazione privata per utenti di dispositivi mobili (fai clic per ingrandire).

Dirigi gli utenti verso le 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.

Dirigi gli utenti verso il flusso di traffico delle applicazioni partner.
Flusso di traffico degli utenti di Branch verso le applicazioni partner (fai clic per ingrandire).

Utenti di dispositivi mobili ad applicazioni private nel ramo

Nel seguente diagramma, il traffico scorre dagli utenti di dispositivi mobili alle applicazioni private nella filiale tramite NCC Gateway.

Flusso di traffico dalle applicazioni private alle applicazioni partner.
Utenti di dispositivi mobili per applicazioni private nel ramo (fai clic per ingrandire).

Capacità di elaborazione

La capacità di elaborazione di uno spoke gateway NCC è la sua 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 traffico moderato.

Prendi in esame gli esempi seguenti per calcolare la capacità di elaborazione richiesta di uno spoke del gateway.

Esempio: indirizzare gli utenti 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 NCC Gateway una volta in ogni direzione e la succursale e internet hanno bisogno di una larghezza di banda full-duplex di 1 Gbps: 1 Gbps per il traffico dalla rete on-premise della succursale a internet e 1 Gbps per il traffico da internet alla rete della succursale. In questo caso, l'utente ha bisogno di 2 Gbps di capacità di elaborazione. Questo esempio presuppone anche che il partner SSE non elimini pacchetti. Se il partner SSE che hai scelto consiglia una larghezza di banda superiore a quella calcolata in questo esempio, segui il consiglio del partner.

Esempio: indirizzare gli utenti a rami di applicazioni privati

Supponiamo che la rete on-premise di una filiale sia connessa a Google Cloud come mostrato nel caso d'uso Utenti della filiale alle applicazioni private e che la filiale e le applicazioni private richiedano 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 pacchetti. Se il partner SSE che hai 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 richiede 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 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 luoghi seguenti:

    • 1 Gbps quando i pacchetti dei collegamenti VLAN che si connettono alla filiale entrano nello spoke gateway
    • 1 Gbps quando i pacchetti escono dallo 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 2 Gbps aggiuntivi di larghezza di banda del gateway perché viene elaborato dal gateway nei seguenti due punti:

    • 1 Gbps quando i pacchetti escono dall'hub ed entrano nello spoke del gateway
    • 1 Gbps quando i pacchetti escono dallo spoke 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 non sono attivi.

Considerazioni

Per utilizzare NCC Gateway, si applicano le seguenti limitazioni:

  • Puoi collegare solo i collegamenti VLAN Cloud Interconnect agli spoke gateway NCC. I tunnel Cloud VPN e le appliance router non sono supportati.
  • Gli spoke 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 mesh completa esistente.
  • È possibile collegare un solo servizio a un gateway NCC alla volta.
  • Un router Cloud deve essere collegato a un gateway NCC nella stessa regione.
  • Al gateway sono collegati solo i collegamenti VLAN Cloud Interconnect creati con un router Cloud collegato a un gateway NCC.
  • Puoi avere un solo spoke 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 indirizzamento del traffico per bypassare un sottoinsieme di traffico dal gateway NCC.
  • Se configuri una route pubblicizzata dal gateway nello spoke 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.
  • Se lo stesso prefisso on-premise viene pubblicizzato agli spoke del gateway NCC in più di una regione, devi impostare una regione come regione preferita. Pubblica l'annuncio del prefisso con un valore MED inferiore (che indica una priorità più elevata) dalla regione in cui vuoi che entri il traffico Google Cloude con un valore MED superiore (che indica una priorità più bassa) dalle altre regioni. Il traffico di ritorno per un prefisso segue la regione preferita indipendentemente dalla regione in cui è entrato il traffico. La pubblicità dello stesso prefisso con valori MED uguali da più regioni può causare routing asimmetrico e interruzione delle sessioni stateful.

    Per informazioni su come modificare i valori MED, consulta Modificare i valori MED per tutte le route apprese personalizzate in una sessione BGP.

  • Le route annunciate del gateway vengono programmate utilizzando la modalità di selezione del percorso migliore standard:

    • La priorità delle route annunciate del gateway nella tabella delle route hub riflette la priorità effettiva della route Andromeda, ad esempio 65536 o 65537. La priorità con cui viene creata la route annunciata del gateway viene presa in considerazione durante il calcolo della priorità della route Andromeda effettiva.
    • Le route statiche hanno sempre una priorità compresa tra 0-65535 e pertanto hanno la precedenza sulle route annunciate del gateway per lo stesso prefisso di destinazione. Pertanto, se vuoi indirizzare il traffico internet al gateway utilizzando una route annunciata dal gateway con una destinazione 0/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 e i servizi Google o utilizzare gli endpoint Private Service Connect per le API di Google globali.

Limitazioni basate sulla capacità

Le seguenti limitazioni si basano sulla capacità di collegamento 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 Cloud Interconnect associati a uno spoke del gateway NCC devono utilizzare una 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 da poter intraprendere le azioni appropriate. Il sistema estrae un segnale di integrità aggregato attivato da problemi di integrità nei componenti chiave, inclusi i test del piano dati attivo per monitorare l'integrità del percorso dei dati end-to-end tramite i servizi partner.

Lo stato di integrità di NCC Gateway è disponibile come metrica di monitoraggio con un'etichetta che indica se è integro o non integro.

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 avvisi in base alla metrica dello stato di integrità del gateway NCC.

Vista delle route effettive per i gateway e le tabelle di route hub

Quando visualizzi una tabella delle route hub, devi selezionare una regione. Le route mostrate in una regione della tabella di routing hub includono priorità che tengono conto dei costi tra regioni, se applicabili.

Gli spoke del gateway hanno tabelle di routing proprie in cui devi selezionare un'interfaccia gateway e la direzione del traffico. Per saperne di più, consulta la sezione Visualizzare le route spoke del gateway.

Esempio di percorso dell'utente

Se sei un nuovo utente e non hai configurato una connettività preesistente, consulta la sezione Configurare NCC Gateway per i nuovi utenti.

Fatturazione

Per informazioni sui prezzi di NCC Gateway, consulta Prezzi di NCC Gateway.

Passaggi successivi