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.
Os administradores de spoke VPC precisam ter as duas vinculações do IAM a seguir no projeto que contém a rede VPC (spoke):
Os administradores do VPC spoke também precisam ter as duas vinculações do IAM a seguir no hub do Network Connectivity Center ou no projeto que contém o hub do Network Connectivity Center:
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.
É possível propor atualizações em um spoke VPC para mudar o conjunto de intervalos de sub-rede IPv4 exportados para as tabelas de rotas do hub.
Para saber mais, consulte as seguintes seções.
- Propor um spoke VPC em um projeto diferente
- Verificar o status de um spoke VPC
- Conferir a tabela de rotas da VPC
- Visão geral dos spokes VPC
- Mudar os intervalos de endereços IPv4 de sub-redes exportadas (pré-lançamento)
Exclusividade da rota de sub-rede
Assim como o peering de rede VPC, 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 cujo 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-benet-csão conectadas umas às outras usando o peering de rede VPC.
Suponha que um intervalo de endereços IP de sub-rede local para 100.64.0.0/24 exista 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
cuja rota de destino corresponda exatamente a 100.64.0.0/24, se encaixe em
100.64.0.0/24 ou contenha 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 em conflito.
Tabelas de rotas que mostram rotas de sub-rede
Google Cloud mostra as rotas de sub-rede do Network Connectivity Center importadas de spokes da VPC em duas tabelas de rotas:
- A tabela de rotas do hub do Network Connectivity Center.
- A tabela de rotas da rede VPC para cada rede VPC (spoke).
OGoogle Cloud atualiza automaticamente a tabela de rotas da rede VPC de cada spoke VPC e a tabela de rotas do hub do Network Connectivity Center quando uma das seguintes condições é atendida:
- Quando você executa uma atividade de ciclo de vida da rota da sub-rede, como a adição ou exclusão de uma sub-rede.
- Quando spokes VPC são adicionados ou removidos do hub.
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
- Para criar hubs e spokes, consulte Como trabalhar com hubs e spokes.
- Para criar um spoke em um projeto diferente do hub, consulte Propor um spoke VPC em um projeto diferente.
- Para uma lista de parceiros com soluções integradas à Network Connectivity Center, consulte Parceiros da Network Connectivity Center.
- Para encontrar soluções para problemas comuns, consulte Solução de problemas.
- Para ver detalhes sobre os comandos da API e do
gcloud, consulte APIs e referência.