Visão geral da administração spoke

Nesta página, você terá uma visão geral da perspectiva de um administrador spoke da nuvem privada virtual (VPC).

Se o hub do Network Connectivity Center e o spoke VPC estiverem no mesmo projeto, os administradores spoke da VPC precisarão ter as seguintes vinculações do Identity and Access Management (IAM) nesse projeto:

Se o hub do Network Connectivity Center e o spoke VPC estiverem em projetos diferentes, as políticas do IAM precisarão ter as vinculações a seguir.

Também é possível usar papéis personalizados, desde que eles incluam as mesmas permissões dos papéis predefinidos listados anteriormente.

Quando uma rede VPC e o hub do Network Connectivity Center estão localizados em projetos diferentes, um administrador spoke da VPC precisa criar uma proposta spoke para solicitar que uma rede VPC entre no hub. Um administrador do hub analisa a proposta. Se o administrador do hub aceitar a proposta, a rede VPC vai ser conectada ao hub. Um administrador de hub também pode rejeitar propostas de spoke. Os administradores do Spoke podem verificar o status de uma proposta de spoke VPC a qualquer momento.

Para saber mais, consulte as seguintes seções.

Exclusividade da rota de sub-rede

Assim como o peering de rede VPC, o Google Cloud proíbe conflitos de intervalos de endereços IP de sub-rede entre spokes VPC conectados a um hub do Network Connectivity Center. Um intervalo de endereços IP da sub-rede entra em conflito com outro intervalo de endereços IP da sub-rede quando uma das seguintes condições é verdadeira:

  • Um intervalo de endereços IP de sub-rede em uma rede VPC corresponde exatamente a um intervalo de endereços IP de sub-rede em outra rede VPC.
  • Um intervalo de endereços IP de sub-rede em uma rede VPC se encaixa em um intervalo de endereços IP de sub-rede em outra rede VPC.
  • Um intervalo de endereços IP de sub-rede em uma rede VPC contém um intervalo de endereços IP de sub-rede em outra rede VPC.

Os spokes VPC não podem exportar intervalos de endereços IP de sub-redes conflitantes para o mesmo hub do Network Connectivity Center. Use a flag exclude-export-ranges na CLI do Google Cloud ou o campo excludeExportRanges na API para impedir que um intervalo de endereços IP de sub-rede seja compartilhado de um spoke VPC em um hub do Network Connectivity Center. Por exemplo, suponha que você tenha duas redes VPC que quer conectar ao mesmo hub do Network Connectivity Center:

  • A primeira rede VPC tem uma sub-rede com o intervalo de endereços IPv4 interno principal 100.64.0.0/16, resultando em uma rota de sub-rede para 100.64.0.0/16.
  • A segunda rede VPC tem uma sub-rede com um intervalo de endereços IPv4 interno secundário de 100.64.0.0/24, resultando em uma rota de sub-rede para 100.64.0.0/24.

As duas rotas de sub-rede têm intervalos de endereços IP de sub-rede conflitantes porque 100.64.0.0/24 se encaixa em 100.64.0.0/16. Não é possível conectar ambas as redes como spokes VPC ao mesmo hub do Network Connectivity Center, a menos que você resolva o conflito. Use uma das seguintes estratégias para resolver o conflito:

  • Exclua o intervalo de endereços IP 100.64.0.0/16 ao anexar a primeira rede VPC ao hub ou exclua o intervalo de endereços IP 100.64.0.0/24 ao anexar a segunda rede VPC ao hub.
  • Exclua 100.64.0.0/16 ou todo o espaço RFC 6598, 100.64.0.0/10, ao anexar cada rede VPC.

Interação com rotas de sub-rede de peering de rede VPC

As rotas de sub-rede com peering são aquelas que são trocadas entre redes VPC conectadas usando o peering de rede VPC. Embora as rotas de sub-rede de peering nunca sejam trocadas entre spokes VPC conectados a um hub do Network Connectivity Center, você ainda precisará considerar as rotas de sub-rede de peering. Da perspectiva de cada spoke VPC, todas as rotas de sub-rede locais, rotas de sub-rede de peering importadas e rotas de sub-redes importadas do Network Connectivity Center não podem entrar em conflito.

Para ilustrar esse conceito, considere a seguinte configuração:

  • A rede VPC net-a é um spoke VPC conectado a um hub do Network Connectivity Center.
  • A rede VPC net-b é um spoke VPC conectado ao mesmo hub do Network Connectivity Center.
  • As redes VPC net-b e net-c são conectadas umas às outras usando o peering de rede VPC.

Suponha que haja um intervalo de endereços IP de sub-rede local para 100.64.0.0/24 em net-c. Isso cria uma rota de sub-rede local em net-c e uma rota de sub-rede de peering em net-b. Mesmo que a rota de sub-rede de peering para o intervalo de endereços IP 100.64.0.0/24 não seja exportada para o hub do Network Connectivity Center, a existência dela em net-b impede que net-b importe uma rota do Network Connectivity Center com um destino que corresponde exatamente a 100.64.0.0/24, se encaixa em 100.64.0.0/24 ou contém 100.64.0.0/24. Consequentemente, nenhuma rota de sub-rede local para 100.64.0.0/24, 100.64.0.0/25 ou 100.64.0.0/16 pode existir em net-a, a menos que você configure net-a para não exportar o intervalo conflitante.

Tabelas de rotas que mostram rotas de sub-rede

O Google Cloud mostra as rotas de sub-rede do Network Connectivity Center importadas de spokes VPC em duas tabelas de rotas:

O Google Cloud atualiza automaticamente a tabela de rota da rede VPC de cada spoke VPC e a tabela de rota do hub do Network Connectivity Center quando uma das seguintes condições é atendida:

Nas tabelas de rotas de rede VPC, cada rota importada de outros spokes da VPC aparece como uma rota de sub-rede do Network Connectivity Center, cujo próximo salto é o hub do Network Connectivity Center. Essas rotas de sub-rede do Network Connectivity Center têm nomes que começam com o prefixo ncc-subnet-route-. Para ver o próximo salto real de uma rota de sub-rede importada do Network Connectivity Center, consulte a tabela de rotas do hub do Network Connectivity Center ou consulte a tabela de rotas da rede VPC do spoke VPC que exporta a rota da sub-rede para o hub do Network Connectivity Center.

Para mais informações sobre rotas VPC, consulte Rotas, na documentação da VPC.

A seguir