Visão geral do gateway do NCC

O gateway do NCC é um tipo de spoke que pode ser anexado ao hub do Network Connectivity Center (NCC). É um produto regional que permite a segurança do tráfego da Cross-Cloud Network. O gateway do NCC permite ativar funções de segurança, como o Security Service Edge (SSE) de terceiros, um componente de segurança fornecido na nuvem do Secure Access Service Edge (SASE). Os spokes do gateway do NCC são compatíveis com a conectividade direta com anexos da VLAN do Cloud Interconnect.

O gateway do NCC oferece os seguintes recursos:

  • Integração simplificada de SSE: é possível integrar o SSE, como o Prisma Access da Palo Alto Networks e o Symantec Cloud Secure Web Gateway (pré-lançamento), de maneira simples com direcionamento transparente para melhorar a proteção e o desempenho de usuário para aplicativo. O gateway do NCC permite ativar funções de segurança para o tráfego entre nuvens.
  • Alta disponibilidade: use o gateway do NCC para um SLA de tempo de atividade de 99,9% para minimizar interrupções.
  • Implantação regional: é possível implantar o gateway do NCC em várias regiões com base na proximidade física de data centers, provedores de SSE de terceiros ou outros provedores de nuvem em que seus aplicativos estão.
  • Força de trabalho remota segura: é possível conectar com segurança forças de trabalho remotas, como as de filiais, data centers e escritórios remotos, a aplicativos particulares no Google Cloud, no local ou em outros provedores de nuvem e a aplicativos públicos.

Vantagens

O gateway do NCC oferece os seguintes benefícios:

  • Experiência de aplicativo ideal com latência reduzida: consumo de alta largura de banda com priorização da nuvem do serviço SSE com o gateway do NCC e desempenho aprimorado pelo backbone privado do Google.

  • Segurança unificada para todo o tráfego de usuários: postura de segurança aprimorada com uma única pilha de segurança unificada e superfície de ataque reduzida ao limitar os pontos de entrada e saída.

  • Gerenciamento simplificado pelo NCC.

Termos-chave

Para entender o gateway do NCC, familiarize-se com a seguinte terminologia:

Anexo híbrido: anexos da VLAN que você associa a um gateway do NCC.

Função de serviço de segurança: serviços anexados ao gateway do NCC. Por exemplo, para proteção de usuário para aplicativo, é necessário anexar um serviço SSE ao gateway do NCC.

Rede de nuvem privada virtual (VPC) de aplicativo ou carga de trabalho: uma rede VPC de carga de trabalho normalmente é uma rede que usa máquina virtual (VM) do Compute Engine ou contêineres do Google Kubernetes Engine (GKE) como cargas de trabalho. As redes VPC de carga de trabalho podem ser redes VPC comuns ou redes VPC compartilhadas com um projeto host e vários projetos de serviço. As redes VPC de carga de trabalho precisam ser configuradas como spokes no hub.

Grupos de spoke: uma maneira de agrupar spokes em um hub do NCC. Com os grupos de spoke, é possível separar os spokes em diferentes domínios de roteamento. Um grupo de spokes pode conter vários spokes, mas um spoke só pode pertencer a um grupo. Para informações detalhadas sobre grupos de spoke para diferentes topologias, consulte Topologias de conectividade predefinidas.

Topologia de inspeção híbrida: permite adicionar spokes de gateway do NCC a um grupo para aplicar políticas. Para informações sobre a topologia de inspeção híbrida, consulte Topologia de inspeção híbrida.

Secure Access Connect: permite conectar produtos de SSE de terceiros ao gateway do NCC para processamento de segurança e saída de dados para a internet segura. Para informações sobre o Secure Access Connect, consulte Visão geral do Secure Access Connect.

Produtos SSE compatíveis

O gateway do NCC é compatível com conexões com os seguintes produtos de SSE:

Casos de uso

O gateway do NCC é ideal para organizações que querem proteger o acesso da força de trabalho híbrida aos aplicativos. O NCC Gateway oferece segurança para colaboradores híbridos com um ecossistema de parceiros de integração integrado para que você possa se conectar aos provedores de SSE de sua preferência. Essa abordagem é aplicável a implantações novas (greenfield) e atuais (brownfield) do NCC.

Com o NCC Gateway, é possível proteger o acesso a aplicativos particulares hospedados no Google Cloud, no local, em outros provedores de nuvem e a aplicativos públicos hospedados na Internet e em aplicativos SaaS. Com o gateway do NCC, é possível criar implantações regionais para otimizar a proximidade do data center e gerenciar o tráfego entre regiões no backbone particular do Google Cloud.

Os casos de uso para usuários do Google Cloud incluem suporte para os seguintes modos de conexão:

  • Usuários da filial para a Internet
  • Usuários de filiais para aplicativos particulares
  • Aplicativos privados para a Internet

Os casos de uso de alguns parceiros compatíveis incluem a conexão de um ou mais dos seguintes:

  • Usuários de dispositivos móveis para a Internet
  • Usuários de dispositivos móveis para aplicativos particulares
  • Direcionar usuários para aplicativos de parceiros
  • Aplicativos particulares para aplicativos de parceiros

Fluxos de tráfego

Nesta seção, descrevemos os caminhos de fluxo de tráfego no gateway do NCC, dependendo de cada caso de uso.

Fluxo de tráfego nos casos de uso para usuários do Google Cloud

Usuários da filial para a Internet

No diagrama a seguir, o tráfego flui de um usuário de filial local pelo gateway do NCC e pela pilha de SSE de terceiros para a Internet.

Usuários da filial para o fluxo de tráfego da Internet.
Usuários da filial para o fluxo de tráfego da Internet (clique para ampliar).

Usuários de filiais para aplicativos particulares

No diagrama a seguir, o tráfego flui do usuário da filial local pelo gateway do NCC, atravessa o SSE de terceiros e, em seguida, volta pelo gateway do NCC para um aplicativo particular.

Direcionar os usuários para um fluxo de tráfego de aplicativo particular.
Usuários de filiais para um fluxo de tráfego de aplicativo particular (clique para ampliar).

Aplicativos privados para a Internet

No diagrama a seguir, o tráfego flui de Google Cloud pelo gateway do NCC, atravessa o SSE de terceiros até a Internet e, em seguida, volta para o gateway do NCC até a VM.

Fluxo de tráfego de aplicativos privados para a Internet.
Aplicativos particulares para o fluxo de tráfego da Internet (clique para ampliar).

Fluxo de tráfego nos casos de uso para parceiros compatíveis

Usuários de dispositivos móveis para a Internet

No diagrama a seguir, o tráfego flui de usuários de dispositivos móveis pela SSE de terceiros para a Internet. Nesse caso, o tráfego não passa pelo gateway do NCC.

Usuários de dispositivos móveis para o fluxo de tráfego da Internet.
Usuários de dispositivos móveis para o fluxo de tráfego da Internet (clique para ampliar).

Usuários de dispositivos móveis para aplicativos particulares

No diagrama a seguir, o tráfego flui de usuários de dispositivos móveis pelo serviço SSE de terceiros e pelo gateway do NCC para um aplicativo particular hospedado em uma rede VPC.

Usuários de dispositivos móveis para um fluxo de tráfego de aplicativo particular.
Usuários de dispositivos móveis para um fluxo de tráfego de aplicativo privado (clique para ampliar).

Direcionar usuários para aplicativos de parceiros

No diagrama a seguir, o tráfego flui do usuário da filial local pelo gateway do NCC, atravessa o SSE de terceiros e, em seguida, volta pelo gateway do NCC para a filial local.

Fluxo de tráfego de usuários de agências para aplicativos de parceiros.
Fluxo de tráfego de usuários da filial para aplicativos de parceiros (clique para ampliar).

Usuários de dispositivos móveis para aplicativos particulares na filial

No diagrama a seguir, o tráfego flui de usuários de dispositivos móveis para aplicativos particulares na filial por meio do gateway do NCC.

Fluxo de tráfego de aplicativos particulares para aplicativos de parceiros.
Usuários de dispositivos móveis para aplicativos particulares na filial (clique para ampliar).

Capacidade de processamento

A capacidade de processamento de um spoke de gateway do NCC é a largura de banda provisionada. É necessário provisionar largura de banda suficiente para cada direção de fluxo de tráfego, considerando que os pacotes podem entrar e sair do spoke do gateway mais de uma vez para cada direção de fluxo em alguns fluxos de tráfego.

Considere os exemplos a seguir para calcular a capacidade de processamento necessária de um spoke de gateway.

Exemplo: usuários da filial para a Internet

Suponha que a rede local de uma filial esteja conectada à Internet, conforme mostrado no caso de uso Usuários da filial para a Internet. Os pacotes estão atravessando o gateway do NCC uma vez em cada direção, e a filial e a Internet precisam de 1 Gbps de largura de banda full-duplex: 1 Gbps para o tráfego da rede local da filial para a Internet e 1 Gbps para o tráfego da Internet para a rede da filial. Nesse caso, o usuário precisa de 2 Gbps de capacidade de processamento. Este exemplo também pressupõe que o parceiro de SSE não descarta nenhum pacote. Se o parceiro de SSE escolhido recomendar uma largura de banda maior do que a calculada neste exemplo, siga a recomendação do parceiro.

Exemplo: usuários de filiais para aplicativos particulares

Suponha que a rede local de uma filial esteja conectada ao Google Cloud , conforme mostrado no caso de uso Usuários da filial para aplicativos particulares, e que a filial e os aplicativos particulares precisem de 1 Gbps de largura de banda full-duplex: 1 Gbps para o tráfego da filial para os aplicativos e 1 Gbps para o tráfego dos aplicativos para a filial. Este exemplo também pressupõe que o parceiro de SSE não descarta nenhum pacote. Se o parceiro de SSE escolhido recomendar uma largura de banda maior do que a calculada neste exemplo, siga a recomendação do parceiro.

O spoke do gateway do NCC que conecta a rede local da filial ao hub do NCC precisa de dois anexos de VLAN de 1 Gbps para atender aos requisitos de SLA do Cloud Interconnect. Dessa forma, é possível que um anexo da VLAN forneça 1 Gbps de largura de banda full-duplex entre a filial e os aplicativos particulares, mesmo quando um anexo da VLAN estiver off-line (por exemplo, devido à manutenção da conexão de interconexão).

A capacidade de processamento necessária do spoke do gateway é de 4 Gbps pelos seguintes motivos:

  • O tráfego da rede local da filial para o hub do NCC requer 1 Gbps de largura de banda. Esse tráfego requer 2 Gbps de largura de banda do gateway porque é processado pelo gateway nos dois lugares a seguir:

    • 1 Gbps, já que os pacotes dos anexos da VLAN que se conectam à filial entram no spoke do gateway
    • 1 Gbps quando os pacotes saem do spoke de gateway e entram no hub
  • O tráfego do hub do NCC para a rede local da filial também requer 1 Gbps de largura de banda. Esse tráfego requer mais 2 Gbps de largura de banda do gateway, porque é processado pelo gateway nos dois lugares a seguir:

    • 1 Gbps quando os pacotes saem do hub e entram no spoke de gateway
    • 1 Gbps quando os pacotes saem do spoke do gateway e são enviados para os anexos da VLAN que se conectam à filial

Recomendamos a seguinte estratégia para configurar a capacidade de processamento do gateway e a largura de banda do anexo da VLAN:

  • A capacidade de processamento do gateway é a soma da largura de banda necessária, em cada direção, entre todas as NICs do gateway.
  • Ao contrário da capacidade de processamento do gateway, a largura de banda do anexo da VLAN é full-duplex. Sempre provisione um número suficiente de anexos da VLAN para atender à largura de banda necessária, mesmo que os anexos da VLAN que usam uma conexão de interconexão comum estejam inativos.

Considerações

Para usar o gateway do NCC, as seguintes limitações se aplicam:

  • Só é possível anexar anexos da VLAN do Cloud Interconnect a spokes do gateway do NCC. Os túneis do Cloud VPN e os dispositivos roteadores não são compatíveis.
  • Os spokes de gateway do NCC para todas as regiões precisam estar no mesmo grupo de spokes de gateways. Para uma implantação greenfield do gateway do NCC, os hubs do NCC precisam usar a topologia de inspeção híbrida predefinida. Para uma implantação brownfield, use a topologia em estrela ou de malha completa.
  • Apenas um serviço pode ser anexado a um gateway do NCC por vez.
  • Um Cloud Router precisa estar vinculado a um gateway do NCC na mesma região.
  • Somente os anexos da VLAN do Cloud Interconnect criados com um Cloud Router vinculado a um gateway do NCC são anexados ao gateway.
  • Só é possível ter um spoke de gateway do NCC por região e por hub.
  • Os spokes e o hub do gateway do NCC precisam estar no mesmo projeto.
  • É preciso especificar a capacidade de processamento no momento da criação do spoke do gateway. A capacidade de processamento pode ser alterada posteriormente, se necessário.
  • Não é possível alterar os intervalos de endereços IP atribuídos. Alguns intervalos de endereços IP são reservados para parceiros de SSE.
  • Não há política de direcionamento de tráfego para ignorar um subconjunto de tráfego do gateway do NCC.
  • Se você configurar uma rota anunciada de gateway no spoke de gateway, será necessário criar um gateway SSE ativo para propagar essa rota para a tabela de rotas do hub do NCC.
  • É possível ver as rotas divulgadas do gateway na tabela de rotas da rede VPC ou na tabela de rotas do hub do grupo de spoke em que a rede VPC está.
  • Se o mesmo prefixo local for anunciado para spokes do gateway do NCC em mais de uma região, você precisará definir uma região como a preferencial. Anuncie o prefixo com um valor de MED mais baixo (indicando prioridade mais alta) da região em que você quer que o tráfego entre Google Cloude com um MED mais alto (indicando prioridade mais baixa) das outras regiões. O tráfego de retorno de um prefixo segue a região mais preferida, independentemente da região em que o tráfego entrou. Anunciar o mesmo prefixo com valores MED iguais de várias regiões pode causar roteamento assimétrico e descartar sessões com estado.

    Para saber como alterar os valores de MED, consulte Alterar os valores de MED para todas as rotas aprendidas personalizadas em uma sessão do BGP.

  • As rotas anunciadas do gateway são programadas usando o modo de seleção do melhor caminho padrão:

    • A prioridade das rotas anunciadas pelo gateway na tabela de rotas do hub reflete a prioridade efetiva da rota do Andromeda, como 65536 ou 65537. A prioridade com que a rota anunciada do gateway é criada é considerada ao calcular a prioridade efetiva da rota do Andromeda.
    • As rotas estáticas sempre têm uma prioridade entre 0-65535 e, portanto, têm precedência sobre as rotas anunciadas pelo gateway para o mesmo prefixo de destino. Portanto, se você quiser direcionar o tráfego da Internet para o gateway usando uma rota anunciada pelo gateway com um destino 0/0, talvez seja necessário remover a rota padrão gerada pelo sistema. Se você remover a rota padrão com o gateway de Internet padrão no próximo salto, será necessário criar rotas especiais para as APIs e os serviços do Google ou usar endpoints do Private Service Connect para APIs globais do Google.

Limitações baseadas em capacidade

As limitações a seguir são baseadas na capacidade de link disponível em uma região:

  • Alguns parceiros podem não oferecer suporte a 100 Gbps.
  • Algumas regiões podem aceitar apenas 1 Gbps e 10 Gbps, mas não 100 Gbps.

Limitações de MTU

Os anexos da VLAN do Cloud Interconnect associados a um spoke do gateway do NCC podem usar uma MTU de até 1.460 bytes.

Não é possível atualizar o intervalo de endereços IP

Depois de criar o spoke, não é possível alterar os endereços IP atribuídos. Alguns intervalos de endereços IP são reservados para parceiros de SSE.

Verificações de integridade

As verificações de integridade indicam a degradação do serviço em uma região para que você possa tomar as medidas adequadas. O sistema extrai um sinal de integridade agregado acionado por problemas de integridade em componentes principais, incluindo sondagem ativa do plano de dados para monitorar a integridade do caminho de dados de ponta a ponta por meio de serviços de parceiros.

O status de integridade do gateway do NCC está disponível como uma métrica de monitoramento com um rótulo de íntegro ou não íntegro.

Quando o gateway do NCC é considerado não íntegro, as sessões do BGP no Cloud Router para o parceiro são encerradas. O gateway do NCC tenta restabelecer as sessões do BGP quando retorna a um estado íntegro.

É possível configurar alertas com base na métrica de status de integridade do gateway do NCC.

Visualização de rotas efetivas para gateways e tabelas de rotas de hub

Ao visualizar uma tabela de rotas de hub, é necessário selecionar uma região. As rotas mostradas em uma região da tabela de rotas do hub incluem prioridades que consideram os custos inter-regionais, se aplicável.

Os spokes de gateway têm as próprias tabelas de rotas, em que é necessário selecionar uma interface de gateway e uma direção de tráfego. Para mais informações, consulte Visualizar rotas de spoke de gateway.

Exemplo de jornada do usuário

Se você for um novo usuário e não tiver uma conectividade pré-existente configurada, consulte Configurar o gateway do NCC para novos usuários.

Faturamento

Para informações sobre os preços do gateway do NCC, consulte Preços do gateway do NCC.

A seguir