Intercâmbio de redes da VPC

Google Cloud O intercâmbio da rede da VPC liga duas redes da nuvem virtual privada (VPC) de modo que os recursos em cada rede possam 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

O intercâmbio da rede da VPC permite-lhe fazer o seguinte:

• Publicar ofertas de software como serviço (SaaS) entre redes da VPC.
• O intercâmbio da rede da VPC funciona com o Compute Engine, o GKE e o ambiente flexível do App Engine.
  • O intercâmbio da rede da VPC suporta clusters GKE nativos de VPC trocando rotas de sub-rede.
  • O peering de rede VPC suporta clusters do GKE baseados em rotas quando configurados para trocar rotas estáticas.

Conetividade

• O intercâmbio das redes da VPC suporta a ligação de redes da VPC e não de redes antigas.
• O intercâmbio da rede da VPC oferece conetividade IPv4 e IPv6 interna entre pares de redes da VPC. O tráfego de peering (tráfego que flui entre redes com peering) tem a mesma latência, débito e disponibilidade que o tráfego na mesma rede VPC.
  • O intercâmbio da rede da VPC não fornece encaminhamento transitivo. Por exemplo, se as redes da VPC net-a e net-b estiverem ligadas através do intercâmbio das redes da VPC, e as redes da VPC net-a e net-c também estiverem ligadas através do intercâmbio das redes da VPC, o intercâmbio das redes da VPC não fornece conetividade entre net-b e net-c.
  • Não pode ligar duas redes VPC no modo automático através do intercâmbio das redes VPC. Isto deve-se ao facto de as redes VPC com peering trocarem sempre rotas de sub-redes que usam endereços IPv4 internos privados, e cada sub-rede numa rede VPC no modo automático usa um intervalo de endereços IP de sub-rede que se enquadra no bloco 10.128.0.0/9CIDR.
  • Pode ligar uma rede VPC no modo personalizado a uma rede VPC no modo automático, desde que a rede VPC no modo personalizado não tenha intervalos de endereços IP de sub-rede que se enquadrem em 10.128.0.0/9.
• O VPC Network Peering também oferece determinada conetividade IPv6 externa aos intervalos de endereços IPv6 externos de destino dos seguintes recursos quando os trajetos para esses endereços IPv6 externos de destino são trocados pelo VPC Network Peering:
  • Interfaces de rede de instâncias de máquinas virtuais (VMs) de pilha dupla e apenas IPv6
  • Regras de encaminhamento para o encaminhamento de protocolos externos
  • Regras de encaminhamento para balanceadores de carga de rede de passagem externos
• O intercâmbio da rede da VPC suporta a conetividade IPv4 e IPv6. Pode configurar o VPC Network Peering numa rede VPC que contenha sub-redes com intervalos de endereços IPv6.

Administração

• As redes VPC interligadas permanecem administrativamente separadas. Apenas são trocadas rotas, de acordo com a configuração de peering.
• Para estabelecer a conetividade de peering, um administrador de rede de cada rede VPC tem de criar uma ligação de peering à outra rede VPC. Por predefinição, um administrador de rede de qualquer uma das redes VPC pode desassociar uma ligação de peering. Pode alterar este comportamento quando criar ou atualizar a ligação.
• Cada lado de uma associação de peering é configurado de forma independente. A interligação é ativa apenas quando a configuração de ambos os lados corresponde. Qualquer um dos lados pode optar por eliminar a associação de peering em qualquer altura. Pode alterar este comportamento quando criar ou atualizar a ligação.
• A criação de uma ligação de peering não lhe concede funções de gestão de identidade e de acesso (IAM) na outra rede VPC. Por exemplo, se tiver a função de administrador da rede de computação ou a função de administrador de segurança de computação para uma rede, não se torna administrador de rede nem administrador de segurança para a outra rede.

Autorizações de IAM

• As autorizações de IAM para criar e eliminar o peering de redes VPC estão incluídas como parte da função de administrador de rede de computação (roles/compute.networkAdmin).
• Pode usar uma função personalizada se incluir as seguintes autorizações:
  • compute.networks.addPeering
  • compute.networks.updatePeering
  • compute.networks.removePeering
  • compute.networks.listPeeringRoutes

Segurança de redes

As redes VPC ligadas através da interligação de redes VPC apenas trocam rotas com base nas opções de troca de rotas configuradas por um administrador de rede de cada rede VPC.

O intercâmbio da rede da VPC não troca regras de firewall da VPC nem políticas de firewall.

Para regras de firewall da VPC:

• As regras de firewall cujos destinos são definidos através de etiquetas de rede só são resolvidas para instâncias na rede de VPC da regra de firewall. Embora um administrador de segurança de uma rede VPC com peering possa usar a mesma etiqueta de rede para definir destinos de regras de firewall numa rede VPC com peering, 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 cujas origens são definidas através de etiquetas de rede só são resolvidas para instâncias na rede VPC da regra de firewall.

• As regras de firewall cujos destinos são definidos através de contas de serviço só são resolvidas para instâncias na rede VPC da regra de firewall. Sujeito às autorizações da IAM, um administrador de segurança de uma rede VPC com peering pode usar a mesma conta de serviço para definir alvos de regras de firewall numa rede VPC com peering, mas os alvos 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 cujas origens são definidas através de contas de serviço só são resolvidas para instâncias na rede VPC da regra de firewall.

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

• Quando é usada para especificar um destino para uma regra de entrada ou saída numa política de firewall de rede, uma etiqueta só pode identificar destinos na rede VPC no âmbito da qual a etiqueta se encontra.

• Quando usado para especificar uma origem para uma regra de entrada numa política de firewall de rede, uma etiqueta pode identificar origens na rede de VPC à qual a etiqueta está no âmbito e em quaisquer redes de VPC com peering que estejam ligadas à rede de VPC à qual a etiqueta está no âmbito. Para mais informações, consulte o artigo Etiquetas para firewalls.

Todas as redes VPC contêm regras de firewall implícitas. Devido às regras de firewall de negação implícita de entrada, os administradores de segurança de cada rede da VPC têm de criar regras de firewall de permissão de entrada ou regras nas políticas de firewall. As origens dessas regras podem incluir intervalos de endereços IP de uma rede VPC com peering.

Devido às regras de firewall de saída permitida implícitas, não precisa de criar regras de firewall de saída permitida nem regras em políticas de firewall para permitir pacotes para destinos na rede de VPC com peering, a menos que as suas redes incluam regras de saída negada.

Suporte de DNS

Os recursos numa 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 privadas geridas do Cloud DNS que estão autorizadas apenas para uma rede VPC local. Para disponibilizar os nomes DNS aos recursos numa rede VPC com peering, use uma das seguintes técnicas:

• Use zonas de intercâmbio do Cloud DNS.
• Autorize (torne visível) a mesma zona privada gerida a todas as redes VPC com peering.

Apoio técnico para balanceador de carga interno

Os clientes numa rede de VPC local podem aceder a balanceadores de carga internos numa rede de VPC de intercâmbio. Para mais informações, consulte as secções Usar o peering de redes VPC da seguinte documentação do balanceador de carga:

• Balanceadores de carga de rede de encaminhamento interno e redes ligadas
• Balanceadores de carga de rede de proxy internos e redes ligadas
• Balanceadores de carga de aplicações internos e redes ligadas

As redes com peering podem trocar trajetos estáticos que usam equilibradores de carga de rede de passagem interna como saltos seguintes. Para mais informações, consulte as opções de troca de rotas.

Grupo de peering e quotas

As quotas de peering de VPC dependem de um conceito denominado grupo de peering. Cada rede VPC tem o seu próprio grupo de intercâmbio composto por si própria e todas as outras redes VPC ligadas a ela através do intercâmbio das redes VPC. No cenário mais simples, se duas redes VPC, net-a e net-b, estiverem em peering entre si, existem dois grupos de peering: um da perspetiva de net-a e o outro da perspetiva de net-b.

Para mais informações sobre as quotas de intercâmbio da rede da VPC, consulte:

• Quotas por rede
• Limites efetivos para quotas por grupo de peering

Limitações

O intercâmbio da rede da VPC tem as seguintes limitações.

Os intervalos de IP das sub-redes não podem sobrepor-se nas redes da VPC com intercâmbio

Nenhum intervalo de IPs de sub-rede pode corresponder exatamente, conter ou caber noutro intervalo de IPs de sub-rede numa rede VPC com peering. No momento da interligação, Google Cloud verifica se existem sub-redes com intervalos de IP sobrepostos. Se existirem, a interligação falha. Para redes já em peering, se realizar uma ação que resulte na criação de uma nova rota de sub-rede, Google Cloud é necessário que a nova rota de sub-rede tenha um intervalo de endereços IP de destino exclusivo.

Antes de criar novas sub-redes, pode listar as rotas das associações de peering para garantir que o intervalo de endereços IPv4 da nova sub-rede ainda não está a ser usado.

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

• A sua rede da VPC, network-1, está interligada com uma segunda rede da VPC, network-2.
• network-2 também tem intercâmbio com uma rede VPC de terceiros, network-3.
• network-3 não tem peering com network-1.

Neste cenário, tem de coordenar com um administrador de rede para o network-2. Peça ao administrador de rede para network-2 listar as rotas de peering na respetiva rede de VPC.

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

Os nomes DNS internos não são resolvidos em redes com peering

Os nomes DNS internos do Compute Engine criados numa rede não são acessíveis a redes com peering. Para aceder às instâncias de VM na rede com peering, use o endereço IP da VM.

As etiquetas e as contas de serviço não são utilizáveis em redes com peering

Não pode fazer referência a uma etiqueta ou a uma conta de serviço pertencente a uma VM de uma rede com peering numa regra de firewall na outra rede com peering. Por exemplo, se uma regra de entrada numa rede com peering filtrar a respetiva origem com base numa etiqueta, aplica-se apenas ao tráfego de VMs originário dessa rede e não das respetivas redes com peering, mesmo que uma VM numa rede com peering tenha essa etiqueta. Esta situação aplica-se de forma semelhante às contas de serviço.

Opções de troca de trajetos

Quando uma rede VPC partilha trajetos locais com uma rede VPC com peering, exporta os trajetos. A rede VPC com peering pode, em seguida, importar os encaminhamentos. Os trajetos de sub-rede, exceto os trajetos de sub-rede IPv4 que usam endereços IPv4 públicos usados de forma privada, são sempre trocados.

A configuração do intercâmbio da rede da VPC permite-lhe controlar o seguinte:

• Se os trajetos IPv6 forem trocados. A configuração de uma ligação de peering de pilha dupla permite-lhe trocar rotas IPv6 de sub-redes de pilha dupla e apenas IPv6.
• Se os encaminhamentos para sub-redes que usam endereços IPv4 públicos usados de forma privada forem exportados ou importados.
• Se as rotas estáticas e dinâmicas são exportadas ou importadas.

Pode atualizar a configuração antes de o peering ser estabelecido ou enquanto a conetividade de peering estiver ativa.

O intercâmbio da rede da VPC não oferece:

• Um método detalhado para controlar a troca de trajetos de sub-rede específicos, trajetos estáticos e trajetos dinâmicos.
• Suporte para a troca de rotas baseadas em políticas.

Opções para trocar rotas de sub-redes

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

Tipo de trajeto	Condições de exportação de rotas	Condições de importação de rotas
Encaminhamentos de sub-rede IPv4 (intervalos de sub-rede IPv4 primários e secundários) com intervalos de endereços IPv4 privados	Sempre exportado Não é possível desativar	Sempre importado Não é possível desativar
Encaminhamentos de sub-rede IPv4 (intervalos de sub-rede IPv4 primários e secundários) que usam intervalos de endereços IPv4 públicos usados de forma privada	Exportado por predefinição A exportação é controlada através da flag --export-subnet-routes-with-public-ip	Não importado por predefinição A importação é controlada através da flag --import-subnet-routes-with-public-ip
Intervalos de sub-redes IPv6 internas (ipv6-access-type=INTERNAL)	Não exportado por predefinição A exportação é ativada definindo --stack-type=IPV4_IPV6	Não importado por predefinição A importação é ativada definindo --stack-type=IPV4_IPV6
Intervalos de sub-redes IPv6 externas (ipv6-access-type=EXTERNAL)	Não exportado por predefinição A exportação é ativada definindo --stack-type=IPV4_IPV6	Não importado por predefinição A importação é ativada definindo --stack-type=IPV4_IPV6

Opções para trocar rotas estáticas

A tabela seguinte descreve as opções de troca de rotas para rotas estáticas.

Tipo de trajeto	Condições de exportação de rotas	Condições de importação de rotas
Encaminhamentos estáticos com etiquetas de rede (todos os tipos de salto seguinte)	Não é possível exportar	Não é possível importar
Rotas estáticas que usam o próximo salto do gateway da Internet predefinido	Não é possível exportar	Não é possível importar
Rotas estáticas IPv4, sem etiquetas de rede, que usam um salto seguinte diferente do gateway de Internet predefinido	Não exportado por predefinição A exportação é controlada através da flag --export-custom-routes	Não importado por predefinição A importação é controlada através da flag --import-custom-routes
Rotas estáticas IPv6, sem etiquetas de rede, que usam uma instância de VM como o próximo salto	Não exportado por predefinição A exportação é controlada através da flag --export-custom-routes quando o tipo de pilha do peering está definido como --stack-type=IPV4_IPV6	Não importado por predefinição A importação é controlada através da flag --import-custom-routes quando o tipo de pilha da interligação é definido como --stack-type=IPV4_IPV6

Opções para trocar rotas dinâmicas

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

Tipo de trajeto	Condições de exportação de rotas	Condições de importação de rotas
Rotas IPv4 dinâmicas	Não exportado por predefinição A exportação é controlada através da flag --export-custom-routes	Não importado por predefinição A importação é controlada através da flag --import-custom-routes
Rotas IPv6 dinâmicas	Não exportado por predefinição A exportação é controlada através da flag --export-custom-routes quando o tipo de pilha do peering está definido como --stack-type=IPV4_IPV6	Não importado por predefinição A importação é controlada através da flag --import-custom-routes quando o tipo de pilha da interligação é definido como --stack-type=IPV4_IPV6

Vantagens 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 cujo próximo salto esteja na rede VPC de intercâmbio.

Um administrador de rede de uma rede VPC local controla a exportação das rotas estáticas e dinâmicas dessa rede, em conjunto, através da flag --export-custom-routes. Um administrador de rede da rede VPC em peering correspondente controla a importação desses trajetos estáticos e dinâmicos através do sinalizador --import-custom-routes. Para mais informações, consulte os artigos Encaminhamentos ignorados, Interações entre sub-redes e encaminhamentos de sub-redes de peering e Interações entre sub-redes e encaminhamentos estáticos.

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

• Se a rede VPC com peering contiver clusters do GKE baseados em rotas e precisar de enviar pacotes para os pods nesses clusters. Os endereços IP dos pods são implementados como intervalos de destino para rotas estáticas localizadas na rede VPC com peering.

• Se precisar de fornecer conetividade entre uma rede no local e uma rede VPC com intercâmbio. Suponhamos que uma rede VPC local contém rotas dinâmicas com um túnel VPN do Cloud de próximo salto, um anexo do Cloud Interconnect (VLAN) ou um dispositivo de router que se liga a uma rede nas instalações. Para fornecer um caminho da rede da VPC em intercâmbio para a rede no local, um administrador de rede da rede da VPC local ativa a exportação de rotas personalizadas e um administrador de rede da rede da VPC em intercâmbio ativa a importação de rotas personalizadas. Para fornecer um caminho da rede nas instalações para a rede VPC em intercâmbio, um administrador de rede da rede VPC local tem de configurar o modo de anúncio personalizado do Cloud Router no Cloud Router que gere a sessão BGP para o túnel do Cloud VPN, a associação do Cloud Interconnect (VLAN) ou o dispositivo de router que se liga à rede nas instalações. O conteúdo desses caminhos anunciados personalizados tem de incluir os intervalos de endereços IP da sub-rede da rede VPC com peering.

Importante: os Cloud Routers não anunciam rotas de sub-rede de peering recebidas quando usam o modo de anúncio predefinido. Para anunciar rotas de sub-redes de peering ou intervalos agregados de rotas de sub-redes de peering, tem de ativar o modo de anúncio personalizado e garantir que as rotas anunciadas personalizadas incluem os intervalos de endereços IP das sub-redes na rede VPC com peering.

Rotas ignoradas

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

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

• Quando a rede da VPC local não contém a rota mais específica para o destino de um pacote, mas duas ou mais redes da VPC em intercâmbio contêm o mesmo destino mais específico para o pacote, o Google CloudGoogle Cloud usa um algoritmo interno para selecionar um próximo salto apenas de uma das redes da VPC em intercâmbio. Esta seleção ocorre antes de a prioridade do trajeto ser considerada e não pode configurar o comportamento. Como prática recomendada, evite esta configuração, uma vez que a adição ou a remoção de redes VPC com peering pode originar alterações não intencionais à ordem de encaminhamento.

Para mais detalhes sobre as situações anteriores, consulte o artigo Ordem de encaminhamento.

Para intercâmbios de pilha dupla, se uma rede da VPC local que importa rotas IPv6 não tiver sub-redes de pilha dupla ou apenas IPv6, nenhuma das rotas IPv6 que recebe de redes da VPC interligadas pode ser usada. Além disso, se a restrição da política da organização tiver sido definida, um administrador de rede pode não conseguir criar sub-redes com intervalos de endereços IPv6.constraints/compute.disableAllIpv6

Interações de encaminhamento de sub-rede e sub-rede de peering

Os encaminhamentos de sub-rede IPv4 em redes VPC interligadas não podem sobrepor-se:

• O peering proíbe rotas de sub-rede IPv4 idênticas. Por exemplo, duas redes VPC com peering não podem ter ambas uma rota de sub-rede IPv4 cujo destino seja 100.64.0.0/10.
• O peering proíbe que uma rota de sub-rede seja contida numa rota de sub-rede de peering. Por exemplo, se a rede da VPC local tiver um caminho de sub-rede cujo destino seja 100.64.0.0/24, nenhuma das redes da VPC com intercâmbio pode ter um caminho de sub-rede cujo destino seja 100.64.0.0/10.

Google Cloud aplica as condições anteriores aos encaminhamentos de sub-redes IPv4 nos seguintes casos:

• Quando liga redes VPC pela primeira vez através da interligação de redes VPC.
• Enquanto as redes estiverem em peering.
• Quando faz uma alteração à configuração do peering, por exemplo, ativando a importação de trajetos IPv4 de sub-rede com endereços IP públicos usados de forma privada.

Enquanto estabelece relações de intercâmbio entre redes, Google Cloud retorna um erro se alguma das seguintes operações resultar numa sobreposição:

• Adicionar uma nova sub-rede.

• Adicionar um intervalo de endereços IPv4 secundário de sub-rede.

• Expandir o intervalo de endereços IPv4 principal da sub-rede.

Os encaminhamentos de sub-rede IPv6 (internos e externos) são exclusivos por definição. Nenhuma rede VPC pode usar os mesmos intervalos de sub-redes IPv6 internas ou externas. Por exemplo, se uma rede da VPC usar fc:1000:1000:1000::/64 como um intervalo de sub-rede IPv6, nenhuma outra rede da VPC em Google Cloud pode usar fc:1000:1000:1000::/64, independentemente de as redes da VPC estarem ligadas através do intercâmbio das redes da VPC.

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

Google Cloud requer que os encaminhamentos de sub-rede e os encaminhamentos de sub-rede de peering tenham os intervalos 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 enquadre numa rota de sub-rede local. Para uma discussão mais detalhada sobre este cenário, consulte o artigo Interações com rotas estáticas.

Este conceito é alargado ao intercâmbio da rede da VPC pelas duas regras seguintes:

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

  • Não pode estabelecer uma nova ligação de peering a uma rede VPC que já contenha uma rota de sub-rede que corresponda exatamente ou contenha o destino da rota estática local se a configuração de peering resultar na importação da rota de sub-rede em conflito. Por exemplo:

    • Se existir um encaminhamento estático local com o destino 10.0.0.0/24, não pode estabelecer uma nova ligação de peering a uma rede VPC que contenha um encaminhamento de sub-rede IPv4 cujo destino corresponda exatamente a 10.0.0.0/24 ou contenha 10.0.0.0/24 (por exemplo, 10.0.0.0/8).

    • Quando o tipo de pilha de peering pretendido é IPV4_IPV6, se existir um trajeto estático local com o destino 2001:0db8:0a0b:0c0d::/96, não pode estabelecer uma nova ligação de peering a uma rede VPC que contenha um trajeto de sub-rede IPv6 cujo destino corresponda exatamente ou contenha 2001:0db8:0a0b:0c0d::/96. Nesta situação, o único intervalo de endereços IPv6 de sub-rede possível é 2001:0db8:0a0b:0c0d::/64, porque os intervalos de endereços IPv6 de sub-rede em Google Cloud têm de usar comprimentos de máscara de sub-rede de 64 bits.

  • Não pode atualizar uma associação de peering existente se a configuração de peering atualizada resultar na importação da rota de sub-rede em conflito. Por exemplo:

    • Suponhamos que duas redes VPC já estão em peering, mas não exportam nem importam trajetos de sub-rede IPv4 através de intervalos de endereços IPv4 públicos usados de forma privada. Existe 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 na rede VPC com intercâmbio. Não pode configurar simultaneamente a rede VPC com peering para exportar rotas de sub-rede através de endereços IPv4 públicos usados de forma privada e configurar a primeira rede VPC para importar rotas de sub-rede através de endereços IPv4 públicos usados de forma privada.

    • Suponhamos que duas redes VPC já estão em peering e que o tipo de pilha de peering é apenas IPv4. Existe um encaminhamento estático local com o destino 2001:0db8:0a0b:0c0d::/96 na primeira rede VPC e um encaminhamento de sub-rede IPv6 com o destino 2001:0db8:0a0b:0c0d::/64 na rede VPC com intercâmbio. Não pode alterar o tipo de pilha de peering para IPV4_IPV6.

  • Por outro lado, se as redes da VPC já estiverem ligadas através do intercâmbio das redes da VPC, não pode realizar as seguintes operações:

    • Crie um novo encaminhamento estático local cujo destino corresponda exatamente ou se enquadre num encaminhamento de sub-rede de peering importado.

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

• Uma rota estática de peering não pode ter um destino que corresponda exatamente ou se enquadre numa rota de sub-rede local. Se existir um caminho de sub-rede local, Google Cloud proíbe o seguinte:

  • Não pode estabelecer uma nova ligação de peering a uma rede VPC que já contenha uma rota estática que corresponda exatamente ou se enquadre no destino da rota de sub-rede da rede VPC local, se a configuração de peering resultar na importação da rota estática do par. Exemplos:

    • Se existir uma rota de sub-rede local para 10.0.0.0/8, não pode estabelecer uma ligação de peering a uma rede VPC com uma rota estática cujo destino corresponda exatamente a 10.0.0.0/8 ou se enquadre em 10.0.0.0/8 (por exemplo, 10.0.0.0/24).

    • Quando o tipo de pilha de intercâmbio pretendido é IPV4_IPV6, se existir uma rota de sub-rede local para 2001:0db8:0a0b:0c0d::/64, não pode estabelecer uma ligação de intercâmbio a uma rede da VPC com uma rota estática cujo destino corresponda exatamente a 2001:0db8:0a0b:0c0d::/64 ou se enquadre em 2001:0db8:0a0b:0c0d::/64 (por exemplo, 2001:0db8:0a0b:0c0d::/96).

  • Não é possível atualizar uma associação de peering existente se a configuração de peering atualizada resultar na importação da rota estática em conflito.

  • Por outro lado, se as redes da VPC já estiverem ligadas através do intercâmbio das redes da VPC, não pode realizar as seguintes operações:

    • Crie uma nova rota de sub-rede local cujo destino corresponda exatamente ou contenha uma rota estática de peering importada.
    • Crie uma nova rota estática na rede VPC com peering cuja destinação corresponda exatamente ou se enquadre numa rota de sub-rede local existente.

Efeitos do modo de planeamento de trajeto dinâmico

O modo de encaminhamento dinâmico de uma rede VPC determina as regiões nas quais os prefixos aprendidos com os Cloud Routers nessa rede são aplicados como trajetos dinâmicos locais. Para ver detalhes sobre este comportamento, consulte o artigo Efeitos do modo de encaminhamento dinâmico.

Este conceito é alargado ao intercâmbio da rede da VPC. O modo de encaminhamento dinâmico da rede VPC de exportação, a rede que contém os routers do Google Cloud que aprenderam os prefixos para esses trajetos dinâmicos, determina as regiões nas quais os trajetos dinâmicos de intercâmbio podem ser programados em redes de intercâmbio:

• Se o modo de encaminhamento dinâmico da rede VPC de exportação for regional, essa rede exporta trajetos dinâmicos apenas na mesma região que os respetivos Cloud Routers que aprenderam os prefixos.

• Se o modo de encaminhamento dinâmico da rede VPC de exportação for global, essa rede exporta rotas dinâmicas em todas as regiões.

Em ambos os casos, o modo de encaminhamento dinâmico da rede VPC de importação não é relevante.

Para ver um exemplo que ilustra este comportamento, consulte o artigo Rede da VPC local e rede da VPC com intercâmbio com conetividade no local.

Interações de sub-redes e rotas dinâmicas

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.

Exemplos de intercâmbio da rede da VPC

Os exemplos seguintes demonstram dois cenários comuns de intercâmbio da rede da VPC.

Rede da VPC local e rede da VPC com intercâmbio com conetividade nas instalações

Neste exemplo, está configurada a seguinte interligação de redes:

• 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á numa região separada. network-b contém uma única sub-rede.
• network-b está ligada a uma rede no local com túneis do Cloud VPN através do encaminhamento dinâmico. (Os mesmos princípios aplicam-se se os túneis forem substituídos por anexos de VLAN do Cloud Interconnect.)
• A ligação de peering para network-b está configurada com a flag --export-custom-routes e a ligação de peering para network-a está configurada com a flag --import-custom-routes.

Rede com peering com acesso à rede no local com encaminhamento dinâmico global (clique para aumentar).

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

O Cloud Router em us-west1 aprende on-premises-prefix com um router no local. on-premises-prefix não cria nenhum conflito porque é mais abrangente do que as rotas da sub-rede e da sub-rede de peering. Por outras palavras, on-premises-prefix não corresponde exatamente e não se enquadra em nenhuma rota de sub-rede ou sub-rede de peering.

A tabela seguinte resume a configuração da rede especificada no exemplo anterior:

Nome da rede	Componente de rede	Intervalo de IPv4	Intervalo de 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 nas instalações	Router nas instalações	10.0.0.0/8	fc:1000:1000:1000::/56	N/A

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

• Quando o modo de encaminhamento dinâmico de network-b é global, os prefixos 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.On-premises prefix Se as regras da firewall estiverem configuradas corretamente, vm-a1, vm-a2 e vm-b podem comunicar com um recurso no local com o endereço IPv4 10.5.6.7 (ou o endereço IPv6 fc:1000:1000:10a0:29b::).

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

Rede de trânsito com várias interligações

Considere um cenário em que network-b está ligado a uma rede no local e atua como uma rede de trânsito para outras duas redes, network-a e network-c. Para permitir que as VMs nestas duas redes acedam ao network-b e à respetiva rede no local ligada através apenas de endereços IP internos, é necessária a seguinte configuração:

• network-a tem uma relação de intercâmbio com network-b e network-b tem uma relação de intercâmbio com network-a.
• network-c tem uma relação de intercâmbio com network-b e network-b tem uma relação de intercâmbio com network-c.
• network-b está ligado a uma rede no local com túneis do Cloud VPN através do encaminhamento dinâmico. Os mesmos princípios aplicam-se se os túneis forem substituídos por associações de VLAN do Cloud Interconnect.
  • Para fornecer conetividade do local para sub-redes em network-a, network-b e network-c, o Cloud Router em network-b está configurado para usar o modo de anúncio personalizado. Por exemplo, o Cloud Router anuncia encaminhamentos de sub-rede a partir de network-b, além de prefixos personalizados que abrangem encaminhamentos de sub-rede em network-a e network-c.
  • Sujeito a interações de sub-rede e de rotas dinâmicas, o Cloud Router em network-b aprende prefixos no local e cria rotas dinâmicas em network-b.
• As associações de peering de network-b para network-a e de network-b para network-c estão configuradas com a flag --export-custom-routes. As associações de peering de network-a para network-b e de network-c para network-b estão configuradas com a flag --import-custom-routes.
  • Sujeito a interações de sub-rede e de rota dinâmica, o Cloud Router em network-b também cria rotas dinâmicas de peering em network-a e network-c.

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

Se as firewalls estiverem configuradas corretamente, os seguintes cenários de conetividade são possíveis:

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

Uma vez que o intercâmbio de redes da VPC não é transitivo, as instâncias de VMs em network-a e network-c não podem comunicar entre si, a menos que também ligue as redes network-a e network-c através do intercâmbio de redes da VPC.

Preços

A preços de rede normais aplica-se ao intercâmbio da rede da VPC.

O que se segue?

• Para configurar e resolver problemas do intercâmbio da rede da VPC, consulte o artigo Configure e faça a gestão do intercâmbio da rede da VPC.