Peering de rede VPC

O peering de rede VPC do Google Cloud conecta duas redes de nuvem privada virtual (VPC) para que os recursos de cada rede possam se comunicar entre si: As redes VPC com peering podem estar no mesmo projeto, em projetos diferentes da mesma organização ou em projetos diferentes de organizações diferentes.

Especificações

Com o peering de rede VPC, é possível:

• Publique ofertas de software como serviço (SaaS) entre redes VPC.
• O peering de rede VPC funciona com o Compute Engine, o GKE e o ambiente flexível do App Engine.
  • O peering de rede VPC oferece suporte a clusters do GKE nativos de VPC com a troca de rotas de sub-rede.
  • O peering de rede VPC é compatível com clusters do GKE baseados em rotas quando configurados para trocar rotas estáticas.

Conectividade

• O peering de rede VPC é compatível com a conexão de redes VPC, e não de redes legadas.
• O peering de rede VPC fornece IPv4 e IPv6 internos a conectividade entre pares de redes VPC. Tráfego de peering (tráfego que flui entre redes em peering) tem a mesma a latência, a capacidade de processamento e a disponibilidade como tráfego dentro da mesma rede VPC.
  • O peering de rede VPC não fornece roteamento transitivo. Por exemplo, se as redes VPC net-a e net-b forem conectadas usando o peering de rede VPC, e as redes VPC net-a e net-c também estiverem conectadas usando o peering de rede VPC, o peering de rede VPC não fornece conectividade entre net-b e net-c.
  • Não é possível conectar duas redes VPC de modo automático usando o peering de rede VPC. Isso ocorre porque as redes VPC com peering sempre trocam rotas de sub-rede que usam endereços IPv4 internos particulares, e cada sub-rede em uma rede VPC de modo automático usa um intervalo de endereços IP de sub-rede que se encaixa no bloco CIDR 10.128.0.0/9.
  • É possível conectar uma rede VPC de modo personalizado a uma rede VPC de modo automático, desde que essa rede não tenha nenhum intervalo de endereços IP de sub-rede que se enquadre em 10.128.0.0/9:
• O peering de rede VPC também fornece determinada conectividade IPv6 externa para os intervalos de endereços IPv6 externos de destino dos recursos a seguir quando as rotas para esses endereços IPv6 externos de destino são trocadas pela rede VPC com peering:
  • Interfaces de rede da instância de máquina virtual (VM) de pilha dupla
  • Regras de encaminhamento para encaminhamento de protocolo externo
  • Regras de encaminhamento para balanceadores de carga de rede de passagem externa.
• O peering de rede VPC é compatível com conectividade IPv4 e IPv6. É possível configurar o peering de rede VPC em uma rede VPC que contenha sub-redes de pilha dupla.

Administração

• As redes VPC com peering permanecem separadas administrativamente. Somente as rotas são trocadas, de acordo com a configuração de peering.
• Para estabelecer a conectividade de peering, um administrador de rede para cada rede VPC precisa criar uma conexão de peering com a outra rede VPC. Um administrador de rede para qualquer rede VPC pode desconectar uma conexão de peering.
• Cada lado de uma associação por peering é configurado de modo independente. O peering estará ativo apenas quando a configuração de ambos os lados for correspondente. Qualquer um dos lados pode optar por excluir a associação a qualquer momento.
• A criação de uma conexão de peering não concede papéis de Identity and Access Management (IAM) na outra rede VPC. Por exemplo, se tiver o papel de Administrador de rede do Compute ou de Administrador de segurança do Compute em uma rede, você não se tornará Administrador da rede ou Administrador de segurança na outra rede.

Permissões do IAM

• As permissões do IAM para criar e excluir o peering de redes VPC estão incluídas como parte do papel de Administrador de rede do Compute (roles/compute.networkAdmin).
• É possível usar um papel personalizado se ele incluir as seguintes permissões:
  • compute.networks.addPeering
  • compute.networks.updatePeering
  • compute.networks.removePeering
  • compute.networks.listPeeringRoutes

Segurança de rede

Redes VPC conectadas somente por peering de rede VPC de troca de rotas, com base no tipo de troca de rotas padrão configuradas por uma administrador da rede de cada VPC em uma rede VPC.

O peering de rede VPC não troca regras de firewall de VPC ou políticas de firewall.

Para regras de firewall de VPC:

• Regras de firewall com destinos definidos usando tags de rede são resolvidas apenas para instâncias na rede VPC da regra de firewall. Ainda que um administrador de segurança de uma rede VPC com peering possa usar a mesma tag de rede para definir destinos de regras de firewall em uma rede VPC com peering, os destinos das regras de firewall na VPC com peering não incluem instâncias na sua rede VPC. Da mesma forma, as regras de firewall de entrada com origens definidas usando tags de rede são resolvidas apenas para instâncias na rede VPC da regra de firewall.

• As regras de firewall com destinos definidos usando contas de serviço são resolvidas somente em instâncias na rede VPC da regra de firewall. Sujeito a permissões do IAM, um administrador de segurança de uma rede VPC com peering pode usar a mesma conta de serviço para definir destinos de regras de firewall em uma rede VPC com peering, mas os destinos das regras de firewall. na rede VPC com peering não incluem instâncias na sua rede VPC. Da mesma forma, as regras de firewall de entrada com origens definidas usando contas de serviço são resolvidas apenas para instâncias na rede VPC da regra de firewall.

As regras em políticas de firewall de rede podem usar tags seguras, que são diferentes das tags de rede, para identificar destinos e origens:

• Quando usada para especificar um destino de uma regra de entrada ou saída em uma política de firewall da rede, uma tag só pode identificar destinos na rede VPC em que ela está com escopo.

• Quando usada para especificar uma origem de uma regra de entrada em uma política de firewall de rede, uma tag pode identificar origens na rede VPC em que a tag está com escopo e em qualquer rede VPC com peering conectada à rede VPC que tem o escopo da tag. Para mais informações, consulte Tags para firewalls.

Toda rede VPC tem regras de firewall implícitas. Devido às regras de firewall de entrada de negação implícitas, os administradores de segurança para cada rede VPC precisam criar regras de firewall de permissão de entrada ou regras em de firewall hierárquicas. As origens dessas regras podem incluir intervalos de endereços IP de uma rede VPC com peering.

Devido às regras de firewall de permissão de saída implícitas, não é necessário criar regras de permissão de saída ou regras em políticas de firewall para permitir pacotes para destinos na VPC com peering. a menos que as redes incluam regras de negação de saída.

Suporte DNS

Os recursos em uma rede VPC com peering não podem usar nomes DNS internos do Compute Engine criados por uma rede VPC local.

Uma rede VPC com peering não pode usar zonas particulares gerenciadas pelo Cloud DNS que estejam autorizadas apenas para uma rede VPC local. Para disponibilizar os nomes DNS para os recursos em uma rede VPC com peering, use uma das seguintes técnicas:

• Use zonas de peering do Cloud DNS.
• Autorize (deixe visível) a mesma zona particular gerenciada para todas as redes VPC com peering.

Suporte ao balanceador de carga interno

Os clientes em uma rede VPC local podem acessar balanceadores de carga de aplicativo internos em uma rede VPC com peering. Para mais informações, consulte as seções Usar peering de rede VPC da documentação do balanceador de carga a seguir:

• Balanceadores de carga de rede e redes conectadas de passagem
• Balanceadores de carga de rede de proxy interna e redes conectadas
• Balanceadores de carga de aplicativos internos e redes conectadas

As redes com peering podem trocar rotas estáticas que usam balanceadores de carga de rede de passagem interna como próximos saltos. Para mais informações, consulte Opções de troca de rota.

Cotas e grupo de peering

Os limites de peering de VPC dependem de um conceito chamado grupo de peering. Cada rede VPC tem o próprio grupo de peering, que consiste nela mesma e em todas as outras redes VPC conectadas a ela usando o peering de rede VPC. No cenário mais simples, se duas redes VPC, net-a e net-b, estiverem em peering entre si, haverá dois grupos de peering: um da perspectiva de net-a e outro da perspectiva de net-b.

Para mais informações sobre as cotas de peering de rede VPC, consulte:

• Cotas por rede
• Limites efetivos de cotas de grupos de peering

Limitações

O peering de rede VPC tem as seguintes limitações.

Os intervalos de IP de sub-redes não podem se sobrepor em redes VPC com peering

Nenhum intervalo de IP de sub-rede pode corresponder, conter ou caber exatamente em outro IP de sub-rede do intervalo de endereços IP em uma rede VPC com peering. No momento do peering, o Google Cloud verifica se existem sub-redes com intervalos de IP sobrepostos. Em caso afirmativo, o peering falhará. Para redes já com peering, se você executar uma ação que resulta na criação de uma nova rota de sub-rede, O Google Cloud exige que a nova rota de sub-rede tenha um IP de destino exclusivo do intervalo de endereços IP.

Antes de criar novas sub-redes, é possível listar as rotas de peering conexões de rede para garantir que as novo intervalo de endereços IPv4 da sub-rede ainda não tenha sido usado.

Essa limitação e as verificações correspondentes do Google Cloud também se aplicam cenários como os seguintes:

• Sua rede VPC, network-1, está em peering com uma segunda VPC rede, network-2.
• network-2 também faz peering com uma terceira rede VPC, network-3.
• network-3 não está em peering com network-1.

Nesse cenário, você deve coordenar com um administrador de rede para a network-2: Solicitar network-2 ao administrador da rede para listar rotas de peering na rede VPC.

Para mais informações sobre as verificações de sobreposição, consulte Interações de rota de sub-rede e peering de sub-rede.

Nomes de DNS internos não são resolvidos em redes com peering

Nomes de DNS interno do Compute Engine criados em uma rede não são acessíveis para redes em peering. Para acessar as instâncias de VM na rede com peering, utilize o endereço IP da VM.

Tags e contas de serviço não são utilizáveis em redes pares

Não é possível referenciar uma tag ou uma conta de serviço pertencente a uma VM de uma rede com peering em uma regra de firewall em outra rede com peering. Por exemplo, se uma regra de entrada em uma rede com peering filtrar a origem com base em uma tag, ela só se aplicará ao tráfego da VM proveniente dessa rede, não dos pares dela, mesmo que uma VM de uma rede com peering tiver essa tag. Essa situação é semelhante para contas de serviço.

Opções de troca de rota

Quando uma rede VPC compartilha rotas locais com uma rede VPC com peering, ela exporta as rotas. A rede VPC com peering pode importar as rotas. As rotas de sub-rede, exceto as rotas de sub-rede IPv4 que usam endereços IPv4 públicos usados de modo particular, são sempre trocadas.

A configuração de peering de rede VPC permite controlar o seguinte:

• Se as rotas IPv6 foram trocadas.
• Se as rotas para sub-redes que usam endereços IPv4 públicos usados de modo particular são exportadas ou importadas.
• Se as rotas personalizadas estáticas e dinâmicas são exportadas ou importadas.

É possível atualizar a configuração antes que o peering seja estabelecido ou enquanto a conectividade de peering estiver ativa.

O peering de rede VPC não oferece o seguinte:

• Um método granular para controlar a troca de rotas de sub-rede específicas, rotas estáticas e rotas dinâmicas.
• Suporte à troca de rotas com base em políticas.

Opções para troca de rotas de sub-rede

A tabela a seguir descreve as opções de troca de rota para rotas de sub-rede:

Tipo de rota	Condições de exportação de rota	Condições de importação de rota
Rotas de sub-redes IPv4 (intervalos de sub-redes IPv4 principais e secundárias) usando intervalos de endereços IPv4 particulares	Sempre exportado Não pode ser desativado	Sempre importado Não pode ser desativado
Rotas de sub-redes IPv4 (intervalos de sub-redes IPv4 principais e secundárias) usando intervalos de endereços IPv4 públicos usados de modo particular	Exportado por padrão A exportação é controlada usando a sinalização --export-subnet-routes-with-public-ip	Não importado por padrão A importação é controlada usando a sinalização --import-subnet-routes-with-public-ip
Intervalos de sub-rede IPv6 internos (ipv6-access-type=INTERNAL)	Não exportado por padrão A exportação é ativada ao configurar --stack-type=IPV4_IPV6	Não importado por padrão A importação é ativada ao configurar --stack-type=IPV4_IPV6
Intervalos de sub-rede IPv6 externos (ipv6-access-type=EXTERNAL)	Não exportado por padrão A exportação é ativada ao configurar --stack-type=IPV4_IPV6	Não importado por padrão A importação é ativada ao configurar --stack-type=IPV4_IPV6

Opções para trocar rotas estáticas

A tabela a seguir descreve as opções de troca de rota para rotas estáticas personalizadas.

Tipo de rota	Condições de exportação de rota	Condições de importação de rota
Rotas estáticas personalizadas com tags de rede (todos os tipos de próximo salto)	Não é possível exportar	Não é possível importar
Rotas estáticas que usam (próximo salto de gateway de Internet padrão)	Não é possível exportar	Não é possível importar
Rotas estáticas IPv4, sem tags de rede, que usam um próximo salto diferente do gateway de Internet padrão	Não exportado por padrão A exportação é controlada usando a sinalização --export-custom-routes	Não importado por padrão A importação é controlada usando a sinalização --import-custom-routes
Rotas estáticas IPv6 personalizadas, sem tags de rede, que usam uma instância de VM como o próximo salto	Não exportado por padrão A exportação é controlada usando a sinalização --export-custom-routes quando o tipo de pilha do peering é definido como --stack-type=IPV4_IPV6	Não importado por padrão A importação é controlada usando a sinalização --import-custom-routes quando o tipo de pilha do peering é definido como --stack-type=IPV4_IPV6

Opções para troca de rotas dinâmicas

A tabela a seguir descreve as opções de troca de rota para rotas dinâmicas.

Tipo de rota	Condições de exportação de rota	Condições de importação de rota
Rotas IPv4 dinâmicas	Não exportado por padrão A exportação é controlada usando a sinalização --export-custom-routes	Não importado por padrão A importação é controlada usando a sinalização --import-custom-routes
Rotas IPv6 dinâmicas	Não exportado por padrão A exportação é controlada usando a sinalização --export-custom-routes quando o tipo de pilha do peering é definido como --stack-type=IPV4_IPV6	Não importado por padrão A importação é controlada usando a sinalização --import-custom-routes quando o tipo de pilha do peering é definido como --stack-type=IPV4_IPV6

Benefícios da troca de rotas estáticas e dinâmicas

Quando uma rede VPC exporta rotas estáticas e dinâmicas e a outra rede VPC importa essas rotas, a rede de importação pode enviar pacotes diretamente para o próximo salto de cada rota estática ou dinâmica importada com o próximo salto em a rede VPC de peering.

Um administrador de rede de uma rede VPC local controla a exportação das rotas estáticas e dinâmicas dessa rede usando a sinalização --export-custom-routes. Um administrador da rede VPC com peering correspondente controla a importação dessas rotas estáticas e dinâmicas usando a sinalização --import-custom-routes. Para mais informações, consulteRotas ignoradas ,Interações de rota de sub-rede e de peering eInterações de sub-rede e rota estática de dois minutos.

A importação de rotas estáticas e dinâmicas de uma rede VPC em peering pode ser útil nos seguintes cenários:

• Se a rede VPC com peering tiver clusters do GKE baseados em rotas e você precisar enviar pacotes para os pods nesses clusters: os endereços IP do pod serão implementados como intervalos de destino para rotas estáticas personalizadas localizadas na rede VPC com peering.

• Se você precisar fornecer conectividade entre uma rede local e uma rede VPC com peering. Suponha que uma rede VPC local contenha rotas dinâmicas com um túnel do Cloud VPN de próximo salto, um anexo do Cloud Interconnect (VLAN) ou um dispositivo roteador que se conecta a uma rede local. Para fornecer um caminho da rede VPC com peering até a rede local, um administrador da rede VPC local ativa a exportação de rota personalizada e um administrador da rede VPC com peering ativa a importação de rotas personalizadas. Para fornecer um caminho da rede local para a rede VPC com peering, um administrador da rede VPC local configura Anúncio personalizado do Cloud Router modo no Cloud Router que gerencia a sessão do BGP para o túnel do Cloud VPN, o anexo do Cloud Interconnect (VLAN) ou dispositivo de roteador que se conecta à rede local. O conteúdo dessas rotas divulgadas personalizadas precisam incluir o endereço IP da sub-rede aos intervalos de IP da rede VPC com peering.

Importante: os Cloud Routers não divulgam rotas de sub-rede de peering recebidas ao usar o modo de divulgação padrão. Para divulgar rotas de sub-rede de peering ou intervalos agregados de rotas de sub-rede de peering, ative o modo anunciado personalizado e garanta que o objeto as rotas incluem os intervalos de endereços IP das sub-redes rede VPC.

Rotas ignoradas

Mesmo quando uma rede VPC importa uma rota, ela pode ignorar a rota importada em situações como as seguintes:

• Quando a rede VPC local tem uma rota com um destino idêntico ou mais específico (máscara de sub-rede mais longa), a rede VPC local sempre usa a rota local dela.

• Quando a rede VPC local não contém a rota mais específica para o destino de um pacote, mas duas ou mais redes VPC com peering têm o mesmo destino mais específico para o pacote, o Google Cloud usa um algoritmo interno para selecionar um próximo salto de apenas uma das redes VPC com peering. Essa seleção ocorre antes de a prioridade da rota ser considerada e não é possível configurar o comportamento. Como prática recomendada, evite essa configuração porque adicionar ou remover redes VPC com peering pode levar a alterações não intencionais na ordem de roteamento.

Para mais detalhes sobre as situações anteriores, consulte Ordem de roteamento.

Para peerings de pilha dupla, se uma rede VPC local que importa rotas IPv6 não tiver sub-redes de pilha dupla, nenhuma das rotas IPv6 que ela recebe de redes VPC com peering poderá ser usada. Além disso, se a restrição da política da organização constraints/compute.disableAllIpv6 tiver sido definida, um administrador de rede talvez não consiga criar sub-redes de pilha dupla.

Interações com rotas de sub-rede e sub-rede de peering

As rotas de sub-rede IPv4 em redes VPC com peering não podem se sobrepor:

• O peering proíbe rotas de sub-rede IPv4 idênticas. Por exemplo, duas redes VPC com peering não podem ter uma rota de sub-rede IPv4 com o destino 100.64.0.0/10.
• O peering proíbe que uma rota de sub-rede esteja contida em uma rota de sub-rede de peering. Por exemplo, se a rede VPC local tiver uma rota de sub-rede com destino 100.64.0.0/24, nenhuma das redes VPC com peering poderá ter uma rota de sub-rede com destino 100.64.0.0/10.

O Google Cloud aplica as condições anteriores para rotas de sub-rede IPv4 nos seguintes casos:

• Ao conectar redes VPC pela primeira vez usando peering de rede VPC.
• Enquanto as redes estiverem com peering.
• Quando você faz uma alteração na configuração de peering, por exemplo, ativando a importação de rotas IPv4 da sub-rede com endereços IP públicos usados de modo particular.

Enquanto você faz o peering das redes, o Google Cloud retorna um erro se alguma das operações a seguir resultar em uma sobreposição:

• Adição de uma nova sub-rede.

• Adição de um intervalo de endereços IPv4 secundário da sub-rede.

• Expansão do intervalo de endereços IPv4 principal da sub-rede.

As rotas de sub-rede IPv6 (internas e externas) são exclusivas por definição. Nenhuma das duas redes VPC pode usar os mesmos intervalos de sub-redes IPv6 internas ou externas. Por exemplo, se uma rede VPC usar fc:1000:1000:1000::/64 como um intervalo de sub-rede IPv6, nenhuma outra rede VPC no Google Cloud poderá usar fc:1000:1000:1000::/64, independentemente das redes VPC estão conectados usando peering de rede VPC.

Interações de sub-rede e rotas estáticas

O Google Cloud exige que as rotas de sub-rede e as rotas de sub-rede de peering tenham os intervalos de IPv4 ou IPv6 de destino mais específicos. Em qualquer rede VPC, uma rota estática local não pode ter um destino que corresponda exatamente ou se ajuste a uma rota de sub-rede local. Para uma discussão mais detalhada sobre esse cenário, consulte Interações com rotas estáticas personalizadas.

Esse conceito é estendido para o peering de rede VPC pelas duas regras a seguir:

• Uma rota estática local não pode ter um destino que corresponda exatamente ou se ajuste em uma rota de sub-rede com peering. Se existir uma rota estática local, o Google Cloud aplicará o seguinte:

  • Não é possível estabelecer uma nova conexão de peering com uma rede VPC que já tenha uma rota de sub-rede que corresponda exatamente ou tenha o destino da rota estática local, se a configuração de peering resultar na importação da rota de sub-rede conflitante. Exemplo:

    • Se existir uma rota estática local com o destino 10.0.0.0/24, não será possível estabelecer uma nova conexão de peering com uma rede VPC que contenha uma rota de sub-rede IPv4 cujo destino corresponda exatamente a 10.0.0.0/24 ou contém 10.0.0.0/24 (por exemplo, 10.0.0.0/8).

    • Quando o tipo de pilha de peering pretendido for IPV4_IPV6, se uma rota estática local com o destino 2001:0db8:0a0b:0c0d::/96 existir, não será possível estabelecer uma nova conexão de peering com uma rede VPC que contenha uma rota de sub-rede IPv6 cujo destino corresponde exatamente ou contém 2001:0db8:0a0b:0c0d::/96. Nessa situação, o único intervalo de endereços de sub-rede IPv6 possível é 2001:0db8:0a0b:0c0d::/64 porque os intervalos de endereços IPv6 da sub-rede no Google Cloud precisam usar comprimentos de máscara de sub-rede de 64 bits.

  • Não será possível atualizar uma conexão de peering já existente se a configuração de peering atualizada resultar na importação da rota de sub-rede conflitante. Exemplo:

    • Suponha que duas redes VPC já tenham peering, mas elas não exportam nem importam rotas de sub-rede IPv4 usando intervalos de endereços IPv4 públicos usados de modo particular. Há uma rota estática local com o destino 11.0.0.0/24 na primeira rede VPC, e uma rota de sub-rede com o destino 11.0.0.0/8 existe na rede VPC com peering. Não é possível configurar simultaneamente a rede VPC com peering para exportar rotas de sub-rede usando endereços IPv4 públicos utilizados de modo privado e configurar a primeira rede VPC para importar rotas de sub-rede usando de maneira particular usaram endereços IPv4 públicos.

    • Suponha que duas redes VPC já tenham peering e o tipo de pilha de peering seja apenas IPv4. Existe uma rota estática local com o destino 2001:0db8:0a0b:0c0d::/96 na primeira rede VPC, e uma rota de sub-rede IPv6 com o destino 2001:0db8:0a0b:0c0d::/64 existe na rede VPC com peering. Não é possível alterar o tipo de pilha de peering para IPV4_IPV6.

  • Por outro lado, se as redes VPC já estiverem conectadas usando o peering de rede VPC, não será possível realizar as seguintes operações:

    • Crie uma nova rota estática local cujo destino corresponda exatamente ou se ajuste a uma rota de sub-rede de peering importada.

    • Crie um novo intervalo de endereços de sub-rede na rede VPC com peering se esse intervalo corresponder exatamente ou tiver uma rota estática local atual.

• Uma rota estática com peering não pode ter um destino que corresponda exatamente ou se ajuste a uma rota de sub-rede local. Se houver uma rota de sub-rede local, o Google Cloud proibirá o seguinte:

  • Não é possível estabelecer uma nova conexão de peering com uma rede VPC que já contenha uma rota estática que corresponda exatamente ou se ajuste ao destino da rota de sub-rede da rede VPC local, se a configuração de peering resultar em importação da rota personalizada do peering. Por exemplo:

    • Se existir uma rota de sub-rede local para 10.0.0.0/8, não será possível estabelecer uma conexão de peering com uma rede VPC com uma rota estática cujo destino corresponda exatamente a 10.0.0.0/8 ou se ajuste a 10.0.0.0/8 (por exemplo, 10.0.0.0/24).

    • Quando o tipo de pilha de peering pretendido forIPV4_IPV6, se uma rota de sub-rede local para 2001:0db8:0a0b:0c0d::/64 não for possível estabelecer uma conexão de peering com uma rede VPC com uma rota estática cujo destino corresponda exatamente a 2001:0db8:0a0b:0c0d::/64 ou que se encaixa em 2001:0db8:0a0b:0c0d::/64 (por exemplo, 2001:0db8:0a0b:0c0d::/96).

  • Não será possível atualizar uma conexão de peering já existente se a configuração de peering atualizada resultar na importação da rota estática conflitante.

  • Por outro lado, se as redes VPC já estiverem conectadas usando o peering de rede VPC, não será possível realizar as seguintes operações:

    • Crie uma nova rota de sub-rede local com um destino que corresponda exatamente ou tenha uma rota estática de peering importada.
    • Crie uma nova rota estática na rede VPC com peering cujo destino corresponderia exatamente ou se ajustaria a uma rota de sub-rede local atual.

Efeitos do modo de roteamento dinâmico

O modo de roteamento dinâmico de uma rede VPC determina as regiões em que os prefixos aprendidos dos Cloud Routers dessa rede são aplicados como rotas dinâmicas personalizadas locais. Para mais detalhes sobre esse comportamento, consulte Efeitos do modo de roteamento dinâmico.

Este conceito é estendido para o peering de rede VPC. O modo de roteamento dinâmico da rede VPC exportadora, que contém os Cloud Routers que aprenderam os prefixos para essas rotas dinâmicas, determina as regiões em que as rotas dinâmicas com peering podem ser programadas em redes de peering:

• Se o modo de roteamento dinâmico da rede VPC exportadora for regional, essa rede exportará rotas dinâmicas apenas na mesma região dos Cloud Routers que aprenderam os prefixos.

• Se o modo de roteamento dinâmico da rede VPC exportadora for global, essa rede exportará rotas dinâmicas em todas as regiões.

Em ambos os casos, o modo de roteamento dinâmico da rede VPC importadora não é relevante.

Para um exemplo que ilustra esse comportamento, consulte Rede VPC local e rede VPC de peering com conectividade local.

Interações de sub-rede e rota dinâmica

Os conflitos entre rotas de sub-rede locais ou de peering e rotas dinâmicas são resolvidos conforme descrito em Interações com rotas dinâmicas personalizadas.

Exemplos de peering de rede VPC

Os exemplos a seguir demonstram dois cenários comuns de peering de rede VPC.

Rede VPC local e rede VPC de peering com conectividade local

Neste exemplo, o peering de rede a seguir está configurado:

• network-a está em peering com network-b, e network-b está em peering com network-a.
• network-a contém duas sub-redes em que cada sub-rede está em uma região separada. network-b contém uma única sub-rede.
• network-b está conectado a uma rede local com túneis do Cloud VPN usando roteamento dinâmico. Os mesmos princípios se aplicam caso os túneis sejam substituídos por anexos da VLAN do Cloud Interconnect.
• A conexão de peering para network-b é configurada com a sinalização --export-custom-routes, e a conexão de peering para network-a é configurada com a sinalização --import-custom-routes.

Rede com peering e acesso à rede local com roteamento dinâmico global (clique para ampliar).

Para fornecer conectividade do local às sub-redes em network-a e network-b, o Cloud Router em network-b precisa ser configurado para usar modo de anúncio personalizado. Por exemplo, o Cloud Router anuncia apenas o prefixo personalizado custom-prefix-1, que inclui o intervalo de sub-rede network-b e os intervalos de sub-rede de network-a.

O Cloud Router em us-west1 aprende on-premises-prefix com um roteador local. on-premises-prefix não cria conflitos porque é mais ampla do que as rotas de sub-rede e de sub-rede de peering. Em outras palavras, on-premises-prefix não corresponde exatamente e não se ajusta a nenhuma rota de sub-rede ou de sub-rede de peering.

A tabela a seguir resume a configuração de rede especificada no exemplo anterior:

Nome da rede	Componente de rede	Intervalo IPv4	Intervalo IPv6	Região
network-a	subnet-a	10.0.0.0/24	fc:1000:1000:1000::/64	us-west1
network-a	subnet-b	10.0.1.0/24	fc:1000:1000:1001::/64	europe-north 1
network-b	subnet-c	10.0.2.0/23	fc:1000:1000:1002::/64	us-west1
network-b	Cloud Router	10.0.0.0/22	fc:1000:1000:1000::/64	us-west1
Rede local	Roteador local	10.0.0.0/8	fc:1000:1000:1000::/56	N/A

Independentemente do modo de roteamento dinâmico de network-a, as seguintes características de roteamento se aplicam:

• Quando o modo de roteamento dinâmico de network-b é global, os On-premises prefix aprendidos pelo Cloud Router em network-b são adicionados como rotas dinâmicas em todas as regiões de network-b e como rotas dinâmicas de peering em todas as regiões de network-a. Se as regras de firewall forem configuradas corretamente, vm-a1, vm-a2 e vm-b podem se comunicar com um recurso local com endereço IPv4 10.5.6.7 (ou endereço IPv6 fc:1000:1000:10a0:29b::).

• Se o modo de roteamento dinâmico de network-b for alterado para regional, os On-premises prefix aprendidos pelo Cloud Router em network-b serão adicionados apenas como rotas dinâmicas na região us-west1 de network-b e como rotas dinâmicas de peering na região us-west1 de network-a. Se as regras de firewall estiverem configuradas corretamente, apenas vm-a1 e vm-b poderão se comunicar com um recurso local com o endereço IPv4 10.5.6.7 (ou o endereço IPv6 fc:1000:1000:10a0:29b::) porque essa é a única VM na mesma região do Cloud Router.

Rede de transporte público com vários peerings

Considere um cenário em que network-b está conectado a uma rede local e atua como uma rede de trânsito para duas outras redes, network-a e network-c. Para permitir que as VMs dessas duas redes acessar network-b e a rede local conectada usando apenas endereços IP internos endereços IP, a seguinte configuração é necessária:

• network-a está em peering com network-b, e network-b está em peering com network-a.
• network-c está em peering com network-b, e network-b está em peering com network-c.
• network-b está conectado a uma rede local com túneis do Cloud VPN usando roteamento dinâmico. Os mesmos princípios se aplicam caso os túneis sejam substituídos por anexos da VLAN do Cloud Interconnect.
  • Para fornecer conectividade do local às sub-redes em network-a, network-b e network-c, o Cloud Router em network-b precisa ser configurado para usar modo de anúncio personalizado. Por exemplo, o Cloud Router divulga rotas de sub-redes de network-b e prefixos personalizados que abrangem rotas de sub-rede em network-a e network-c.
  • Sujeito às interações de sub-rede e rota dinâmica, o Cloud Router em network-b aprende os prefixos locais e cria rotas dinâmicas em network-b.
• As conexões de peering entre network-b e network-a e de network-b para network-c são configuradas com a sinalização --export-custom-routes. As conexões de peering entre network-a e network-b e de network-c para network-b são configuradas com a sinalização --import-custom-routes.
  • Sujeito às interações de sub-rede e rota dinâmica, o Cloud Router em network-b também cria rotas dinâmicas de peering em network-a e network-c.

Rede VPC de trânsito (clique para ampliar).

Se os firewalls estiverem configurados corretamente, os seguintes cenários de conectividade podem acontecer:

• As instâncias de VM em network-a podem alcançar outras VMs em network-b e sistemas locais.
• As instâncias de VM em network-c podem alcançar outras VMs em network-b e sistemas locais.
• As instâncias de VM em network-b podem acessar outras VMs em network-a e network-c, bem como em sistemas na rede local.

Como o peering de rede VPC não é transitivo, as instâncias de VM em network-a e network-c não podem se comunicar, a menos que você também conecte as redes network-a e network-c usando o peering de rede VPC.

Preços

Os preços normais da rede se aplicam ao peering de rede VPC.

A seguir

• Para configurar e solucionar problemas do peering de rede VPC, consulte Configurar e gerenciar peering de rede VPC.