Visão geral do peering da rede VPC

O peering de rede VPC do Google Cloud permite fazer conexões privadas RFC 1918 entre duas redes de nuvem privada virtual (VPC) pertencentes ou não ao mesmo projeto ou organização.

O Peering de redes VPC permite fazer peering de redes VPC para que as cargas de trabalho em diferentes redes VPC possam se comunicar no espaço RFC 1918 privado. O tráfego fica restrito à rede do Google e não passa pela Internet pública.

O Peering de redes VPC é útil para:

  • Ecossistemas SaaS (Software as a Service) no Google Cloud. É possível disponibilizar serviços de maneira particular em diferentes redes VPC entre organizações e dentro delas.
  • Organizações com vários domínios administrativos de rede, que podem fazer peering entre si.

Se você tiver vários domínios administrativos de rede na sua organização, o Peering de redes VPC permitirá disponibilizar serviços entre redes VPC no espaço RFC 1918 particular. Se você oferece serviços a outras organizações, o Peering de redes VPC permite que esses serviços sejam disponibilizados a essas organizações no espaço RFC 1918 privado. Assim, essa capacidade é útil para oferecer serviços a outras empresas, além de ser benéfica para sua própria empresa se você tiver vários nós de organização distintos devido à sua estrutura ou como resultado de fusões ou aquisições.

O Peering de redes VPC oferece várias vantagens em comparação com o uso de VPNs ou endereços IP externos para conectar redes, como:

  • Latência da rede: a rede de IPs públicos sofre uma latência maior do que a rede privada. Todo o tráfego de peering fica restrito à rede do Google.
  • Segurança da rede: os proprietários de serviços não precisam ter os serviços expostos à Internet pública e lidar com os riscos associados.
  • Custo da rede: o Google Cloud cobra o preço da largura de banda de saída no caso de redes que usam IPs externos para se comunicar, ainda que o tráfego esteja dentro da mesma zona. No entanto, se as redes estiverem com peering, poderão usar IPs internos para se comunicar e economizar esses custos de saída. O preço normal da rede se aplicará a todo o tráfego.

Para mais informações sobre como criar conexões de peering, consulte Como usar o Peering de redes VPC.

Propriedades principais

As redes VPC com peering exibem as propriedades principais a seguir:

  • O peering de rede VPC funciona com o Compute Engine, o GKE e o ambiente flexível do App Engine.
  • As redes VPC com peering permanecem separadas administrativamente. Rotas, firewalls, VPNs e outras ferramentas de gerenciamento de tráfego são administradas e aplicadas separadamente em cada uma das redes VPC.
  • 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.
  • O peering e a opção de importar e exportar rotas personalizadas podem ser configurados para uma rede VPC mesmo antes da outra rede VPC ser criada. Embora a troca de rota ocorra somente após os dois lados terem sido configurados.
  • Os pares VPC sempre trocam todas as rotas de sub-rede. Também é possível trocar rotas personalizadas (rotas estáticas e dinâmicas), se as configurações de peering tiverem sido configuradas para importá-las ou exportá-las. Para mais informações, consulte Como importar e exportar rotas personalizadas.
  • Rotas de sub-rede e rotas estáticas são globais. Já as rotas dinâmicas podem ser regionais ou globais, dependendo do modo de roteamento dinâmico da rede VPC.
  • Uma determinada rede VPC pode fazer peering com várias redes VPC, mas há um limite.
  • As permissões do IAM para criar e excluir o Peering de redes VPC são incluídas como parte dos papéis de proprietário do projeto, editor do projeto e administrador de rede.
  • O tráfego de peering (tráfego que flui entre redes com peering) tem a mesma latência, capacidade e disponibilidade que o tráfego particular na mesma rede.
  • A política de faturamento para tráfego de peering é igual à política de faturamento para tráfego particular na mesma rede.
  • Se você for um administrador de políticas da organização, poderá usar uma política da organização para restringir as redes VPC que podem fazer peering com redes VPC na sua organização. É possível negar conexões de peering para redes VPC particulares ou para redes VPC em uma pasta ou organização particular. A restrição se aplica a novas configurações de peering e não afeta conexões existentes. Uma conexão de peering existente pode continuar funcionando mesmo se uma nova política negar novas conexões. Para mais informações, consulte a restrição constraints/compute.restrictVpcPeering.

Restrições

Ao fazer peering com redes VPC, considere as seguintes restrições:

  • Um intervalo CIDR de sub-rede em uma rede VPC com peering não pode se sobrepor a uma rota estática em outra rede com peering. Essa regra abrange rotas de sub-rede e rotas estáticas. O Google Cloud verifica se há sobreposição nas seguintes circunstâncias e gera um erro caso ela ocorra.
    • Quando você faz peering de redes VPC pela primeira vez.
    • Quando você cria uma rota estática em uma rede VPC com peering.
    • Quando você cria uma nova sub-rede em uma rede VPC com peering.
  • Uma rota dinâmica pode se sobrepor a uma rota de sub-rede em uma rede com peering. No caso de rotas dinâmicas, os intervalos de destino que se sobrepõem a uma rota de sub-rede da rede com peering são descartados de maneira silenciosa. O Google Cloud usa a rota de sub-rede.
  • O Peering de redes VPC é aceito somente em redes VPC. Ele NÃO é compatível com redes legadas.
  • Não é possível desativar a troca de rotas de sub-rede ou escolher quais delas serão trocadas. Depois que o peering é estabelecido, todos os recursos dentro dos endereços IP de sub-rede ficam acessíveis nas redes com peering direto. O Peering de redes VPC não fornece controles de rota granulares para filtrar quais intervalos CIDR de sub-rede podem ser acessados nas redes com peering. Se for necessário, use regras de firewall para filtrar o tráfego. Os tipos de endpoints e recursos a seguir são acessíveis em qualquer rede com peering direto:
    • IPs internos da máquina virtual (VM) em todas as sub-redes
    • IPs internos com carga balanceada em todas as sub-redes
  • Somente redes com peering direto podem se comunicar. O peering transitivo não é aceito. Ou seja, se a rede VPC N1 estabelecer peering com a N2 e a N3, mas a N2 e a N3 não tiverem uma conexão direta, a rede VPC N2 não poderá se comunicar com a rede VPC N3 por meio do Peering de redes VPC.
  • Não é possível usar uma tag ou uma conta de serviço de uma rede com peering na outra rede com peering.
  • Os nomes de DNS internos do Compute Engine criados em uma rede não podem ser acessados em redes com peering. Use o endereço IP para acessar as instâncias de VM na rede com peering.
  • Por padrão, o peering de redes VPC com GKE é aceito quando usado com aliases de IP. Se você não costuma utilizar aliases de IP, exporte rotas personalizadas para que os contêineres do GKE possam ser acessados em redes com peering.

Ordem de roteamento

Depois de fazer peering com outra rede e trocar rotas, sua rede VPC pode ter rotas com destinos concorrentes. Consulte Ordem de roteamento para entender como o Google Cloud determina a ordem de roteamento.

Como importar e exportar rotas personalizadas

Por padrão, as rotas de sub-rede são sempre trocadas entre redes com peering. Também é possível trocar rotas personalizadas, que incluem rotas estáticas e dinâmicas, caso os administradores de ambas as redes tenham as configurações de peering apropriadas.

Quando você importa rotas personalizadas, sua rede VPC só pode receber rotas personalizadas da rede com peering se elas estiverem sendo exportadas por essa rede. Da mesma forma, quando você exporta rotas personalizadas, a rede com peering só pode receber rotas personalizadas se elas estiverem sendo importadas por essa rede.

Quando você importa ou exporta rotas personalizadas, as redes só trocam rotas personalizadas com pares diretos. Por exemplo, se sua rede VPC estabelecer peering com várias redes, as rotas que ela importa de uma rede com peering não serão exportadas para as outras redes com peering.

Quando você cria ou modifica uma configuração de peering, pode optar por importar rotas, exportar rotas ou ambos. O administrador de redes com peering precisa definir a configuração de peering delas antes que as rotas sejam trocadas. Esse processo garante que os administradores de rede concordem explicitamente em trocar rotas personalizadas antes que elas sejam trocadas.

Benefícios da troca de rotas personalizadas

O compartilhamento de rotas personalizadas com redes VPC com peering permite que as redes aprendam rotas diretamente das redes com peering. Por exemplo, se uma rota personalizada em uma rede com peering for atualizada, sua rede VPC aprenderá automaticamente e usará a rota personalizada atualizada sem exigir nenhuma ação de sua parte.

A troca de rotas personalizadas pode ser útil nos seguintes cenários:

  • Se você tiver clusters do GKE sem endereçamento nativo VPC, poderá ter várias rotas estáticas para direcionar o tráfego para instâncias de VM que hospedem seus contêineres. É possível exportar essas rotas estáticas para que os contêineres possam ser acessados em redes com peering.
  • Se você tiver uma interconexão ou um túnel VPN, poderá compartilhar rotas personalizadas para que as redes com peering possam acessar sua rede local. No caso de rotas dinâmicas, adicione divulgações personalizadas de rota do Cloud Router em sua rede VPC para divulgar sub-redes de rede com peering na rede local.

Considerações

Ao configurar a importação ou a exportação de rotas personalizadas, considere os seguintes comportamentos:

  • Tanto rotas estáticas como dinâmicas são exportadas ou importadas. Não é possível optar por importar ou exportar apenas um tipo de rota.
  • As rotas personalizadas importadas de uma rede VPC não podem ser exportadas para outra rede VPC com peering de forma transitiva.
  • As rotas a seguir estão excluídas da importação e exportação:
    • As rotas com tags incluídas nunca são trocadas entre redes em peering. As rotas com tags são rotas estáticas personalizadas com escopo definido para instâncias de VM usando tags de rede. As tags de rede só podem ser resolvidas na rede VPC em que são criadas.
    • As rotas estáticas com um próximo salto para o gateway de Internet padrão nunca são trocadas. Por exemplo, a rota padrão (0.0.0.0/0) com um próximo salto para o gateway de internet padrão não é trocada entre redes em peering.
  • Rotas importadas podem levar a mudanças não intencionais no fluxo de tráfego, como alterações na ordem de roteamento. Para mais informações, consulte Ordem de roteamento.
  • Quando uma rede VPC importa rotas personalizadas de uma rede com peering, os intervalos de destino são importados como estão. No entanto, o próximo salto de uma rota importada é definido como o nome da conexão de peering. O tráfego é roteado para a rede com peering em que o próximo salto real estiver definido.

Recursos de rede em cenários do Peering de redes VPC

As seções a seguir demonstram como o Peering de redes VPC se comporta em determinados cenários.

Sub-redes sobrepostas no momento do peering

No momento de fazer o peering, o Google Cloud verifica se há sub-redes com intervalos de IP sobrepostos entre as duas redes VPC ou em qualquer uma das redes com peering. Se houver uma sobreposição, o peering não será estabelecido. Como uma conectividade de malha completa é criada entre instâncias de VM, as sub-redes nas redes VPC com peering não podem ter intervalos de IP sobrepostos. Isso causaria problemas de roteamento.

Intervalos de IP de sub-rede sobrepostos entre dois pares (clique para ampliar)
Intervalos de IP de sub-rede sobrepostos entre dois pares (clique para ampliar)

Uma sub-rede com intervalos de IP sobrepostos entre pares de uma determinada rede VPC causaria um conflito de roteamento. Por exemplo, imagine que a rede VPC N1 já tenha estabelecido peering com a rede VPC N2. A rede VPC N3 tentaria então fazer peering com a N2. Esse peering seria inválido porque a N3 tem uma sub-rede chamada "Subnet_5" e o intervalo de IP dela se sobrepõe à Subnet_1 na rede N1.

Intervalos de IP de sub-rede sobrepostos com três pares (clique para ampliar)
Intervalos de IP de sub-rede sobrepostos com três pares (clique para ampliar)

Sub-redes sobrepostas ao criar ou expandir sub-redes

Quando uma sub-rede VPC é criada ou um intervalo de IP de sub-rede é expandido, o Google Cloud executa uma verificação para garantir que o novo intervalo de sub-rede não se sobreponha aos intervalos de IP de sub-redes na mesma rede VPC ou em redes VPC com peering direto. Caso isso ocorra, a ação de criação ou expansão falhará. Por exemplo, quando uma nova sub-rede Subnet_3 é criada na rede N2 na figura a seguir, os intervalos de IP não podem se sobrepor aos intervalos de IP definidos na rede N1 com peering direto.

Verificação de criação de sub-rede (clique para ampliar)
Verificação de criação de sub-rede (clique para ampliar)

O Google Cloud também garante que nenhum intervalo de IP de sub-rede sobreposto seja permitido em redes VPC que tenham uma rede com peering em comum. Caso isso ocorra, a ação de criação ou expansão falhará. Por exemplo, quando uma nova sub-rede Subnet_5 é criada na rede N3 na figura a seguir, os intervalos de IP não podem se sobrepor aos intervalos de IP definidos na rede N2 com peering direto ou na rede N1 porque N1 já fez peering com N2.

Verificação de criação de sub-rede com três pares (clique para ampliar)
Verificação de criação de sub-rede com três pares (clique para ampliar)

Acesso local em rede com peering

É possível usar o Cloud VPN ou o Cloud Interconnect para conectar com segurança a rede local à sua rede VPC. Se você exportar rotas personalizadas, as redes VPC com peering também poderão se conectar à rede local. No lado local, é preciso criar rotas para que o tráfego que flui para as redes VPC seja direcionado para o túnel VPN.

O Cloud VPN aceita roteamento estático e dinâmico, mas o Cloud Interconnect só é compatível com roteamento dinâmico. Para roteamento dinâmico, use o Cloud Router para atualizar dinamicamente as rotas entre sua rede VPC e a rede local usando o protocolo do gateway de borda (BGP, na sigla em inglês). Os Cloud Routers podem aprender e propagar rotas na própria região ou para todas as regiões dentro de uma rede VPC. Esse comportamento depende do modo de roteamento dinâmico da rede VPC, que pode ser regional ou global.

Os casos de uso a seguir demonstram como os recursos em redes VPC com peering podem ser acessados após a importação e exportação de rotas personalizadas. Cada exemplo mostra duas redes (network-a e network-b) que estão com peering entre si. Em um exemplo, o modo de roteamento dinâmico para network-b é regional e, no outro, é global.

Roteamento dinâmico regional

Se você usar o roteamento dinâmico regional, somente recursos na mesma região do Cloud Router poderão acessar a rede local. Essa restrição se aplica à rede VPC do Cloud Router e a qualquer rede VPC com peering, independentemente do modo de roteamento dinâmico da rede VPC com peering. No exemplo a seguir, network-b contém um túnel da VPN (que também pode ser uma interconexão) e um Cloud Router. O modo de roteamento dinâmico de network-b está definido como regional. Na rede com peering, subnet-a está na mesma região que o Cloud Router em network-b.

Depois que uma conexão de peering é estabelecida, network-a pode acessar o túnel da VPN em network-b. Esse acesso é limitado a sub-redes que estejam na mesma região do Cloud Router. Por exemplo, a instância de VM vm-a pode acessar o túnel da VPN porque está na mesma região que o Cloud Router, ao contrário de instâncias de VM em outras regiões.

Como o Cloud Router não aprende nem propaga rotas a partir de redes VPC com peering, é preciso ter uma divulgação de rota personalizada no Cloud Router que propague o intervalo 10.8.1.0/24para a rede local na sessão do BGP.

A tabela a seguir resume as rotas resultantes para network-a e network-b, caso ambas importem e exportem rotas personalizadas:

Rede Destino Próximo salto Origem
network-a 0.0.0.0/0 Gateway da Internet local
10.8.1.0/24 network-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 peering-a-to-b peering
10.10.0.0/16
(rota dinâmica limitada a us-west1)
peering-a-to-b peering
network-b 0.0.0.0/0 Gateway da Internet local
10.8.2.0/24 network-b local
10.10.0.0/16
(rota dinâmica limitada a us-west1)
vpn-b local
10.8.1.0/24 peering-b-to-a peering
10.30.0.0/16 peering-b-to-a peering

Roteamento dinâmico global

Se network-b ativar o roteamento dinâmico global, os recursos em todas as regiões poderão acessar a rede local. Isso se aplica à rede VPC do Cloud Router e a qualquer rede VPC com peering, independentemente do modo de roteamento dinâmico da rede VPC com peering.

No exemplo a seguir, os recursos em network-a podem acessar o túnel da VPN em network-b, independentemente da região. Por exemplo, as instâncias de VM vm-a1 e vm-a2 podem alcançar a rede local mesmo se vm-a2 estiver em uma região diferente do túnel da VPN.

O Cloud Router também precisa incluir uma divulgação de rota personalizada para anunciar os intervalos 10.8.1.0/24 e 10.9.1.0/24 para a rede local na sessão do BGP.

A tabela a seguir resume as rotas resultantes para network-a e network-b, caso ambas importem e exportem rotas personalizadas:

Rede Destino Próximo salto Origem
network-a 0.0.0.0/0 Gateway da Internet local
10.8.1.0/24 network-a local
10.9.1.0/24 network-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 peering-a-to-b peering
10.10.0.0/16
(rota dinâmica global)
peering-a-to-b peering
network-b 0.0.0.0/0 Gateway da Internet local
10.8.2.0/24 network-b local
10.10.0.0/16
(rota dinâmica global)
vpn-b local
10.8.1.0/24 peering-b-to-a peering
10.9.1.0/24 peering-b-to-a peering
10.30.0.0/16 peering-b-to-a peering

Rede VPC como uma rede de trânsito

Imagine que você tenha uma única conexão local, como um túnel da VPN ou uma interconexão, entre sua rede VPC e a rede local. Você quer compartilhar essa conexão com outras redes VPC para que você não precise recriar uma conexão local para todas as outras redes VPC.

É possível ter outras redes VPC que estabeleçam peering com sua rede VPC (também conhecida como rede de trânsito) para que as outras redes possam usar a conexão local. Todas as redes com peering podem usar a conexão local, mas não poderão rotear o tráfego para outro par por meio da rede de trânsito.

No exemplo a seguir, existem três redes VPC. network-b faz peering com network-a e network-c. Todas as redes estão exportando e importando rotas personalizadas. network-b atua como rede de trânsito e é nela que o túnel VPN está localizado.

  • network-b tem as rotas de VPN estáticas relevantes para rotear o tráfego para a rede local conectada. A rota estática é exportada e, em seguida, importada pelas redes VPC com peering. Se estiver usando o Cloud Router para roteamento dinâmico, é necessário divulgar os endereços IP de sub-rede das redes em peering. O Cloud Router não divulga automaticamente rotas a partir do peering de redes VPC.

  • Os hosts na rede local podem enviar e receber tráfego entre hosts em cada uma das redes VPC. A rede local precisa conter rotas que tenham um próximo salto para o gateway de VPN, caso o tráfego seja destinado a uma rede VPC.

  • Os hosts em network-c podem acessar hosts em network-b e na rede local, mas não em network-a. Da mesma forma, os hosts em network-a podem acessar network-b e a rede local, mas não network-c. Isso ocorre porque as rotas de peering não são transitivas.

Balanceamento de carga TCP/UDP interno

As instâncias de VM em redes com peering poderão acessar os endereços IP internos de balanceadores de carga TCP/UDP internos na sua rede VPC se as seguintes condições forem atendidas:

  • As VMs estão localizadas na mesma região que o balanceador de carga TCP/UDP interno.
  • As regras de firewall de entrada que se aplicam às VMs de back-end do balanceador de carga permitem o tráfego de origens em redes com peering. Essas regras de firewall de entrada precisam ser criadas na rede VPC que contém o balanceador de carga.

Para mais informações, consulte Como usar o Peering de redes VPC.

Regras de firewall

Quando você conecta redes usando o Peering de redes VPC, as regras de firewall não são trocadas entre elas. Para permitir o tráfego de entrada de instâncias de VM em uma rede com peering, é preciso criar regras de firewall de permissão de entrada. Por padrão, o tráfego de entrada para VMs é bloqueado pela regra implícita "negar entrada".

Se você precisar restringir o acesso a VMs de modo que somente outras VMs na sua rede VPC tenham acesso, verifique se as origens para a entrada permitem que as regras de firewall identifiquem VMs apenas na sua rede VPC, e não em redes com peering. Por exemplo, é possível especificar intervalos de IP de origem apenas para as sub-redes na sua rede VPC.

Para restringir o acesso a um balanceador de carga TCP/UDP interno, crie regras de firewall de entrada que se apliquem às VMs de back-end do balanceador de carga.

Firewall

As regras de firewall não são importadas para as redes com peering. Você pode configurar regras de firewall em cada rede separadamente para controlar o tráfego que você quer permitir ou bloquear de redes com peering.

Você poderá bloquear o tráfego para um dado conjunto de instâncias VM ou pontos de extremidade de balanceamento de carga interno, se tiver um peering entre sua rede VPC e outra rede VPC. Como não é possível excluir certas instâncias de VM ou balanceadores de carga internos do peering, você precisará usar as regras de firewall. Se quiser desativar a comunicação com determinadas instâncias de VM ou balanceadores de carga internos, é possível instalar regras de firewall de entrada na rede com que pretende bloquear a comunicação.

  • Instâncias de VM: neste caso, é possível instalar um firewall de entrada que só permite o tráfego de determinados IPs de origem. Esses IPs de origem podem ser mapeados para os CIDRs de sub-rede em sua própria rede VPC. Isso bloqueia qualquer tráfego proveniente das redes VPC com peering.
Firewall com peering de redes VPC (clique para ampliar)
Firewall com peering de redes VPC (clique para ampliar)
  • Balanceadores de carga internos: neste caso, é possível instalar regras de firewall de entrada na rede VPC com o balanceador de carga interno. Esses IPs de origem podem ser mapeados para todos ou parte dos CIDRs de sub-rede na sua própria rede. Se as regras de firewall de entrada forem implementadas para todos os intervalos de CIDR de sub-rede na rede com peering, nenhuma instância nessa rede poderá acessar as VMs do back-end do balanceador de carga interno.

VPC compartilhada

O Peering de redes VPC permite fazer peering com uma VPC compartilhada. Um projeto de host de VPC compartilhada permite que outros projetos usem uma de suas redes. O diagrama a seguir mostra esta configuração.

VPC compartilhada com peering de rede (clique para ampliar)
VPC compartilhada com peering de rede (clique para ampliar)

A Rede-SVPC está em uma rede VPC compartilhada no projeto host P1. Os projetos de serviço P3 e P4 podem anexar instâncias de VM à Rede-SVPC. A Rede-SVPC faz peering com a Rede-A. Como resultado:

  • As instâncias de VM em projetos de serviço VPC compartilhados que usam a Rede-SVPC (VM3 e VM4) têm conectividade de IP interna e particular com qualquer endpoint associado à Rede-A.
  • As instâncias de VM associadas à Rede-A terão conectividade privada de IP interno com qualquer endpoint associado à Rede-SVPC, independentemente de estar no projeto host ou em um projeto de serviço.

É possível configurar o Peering de redes VPC entre duas redes VPC compartilhadas.

Várias interfaces de rede por instância de VM

Uma instância de VM pode ter várias interfaces de rede, uma por rede VPC. Nessas instâncias, o Google Cloud atribui rotas IP com base no destino. Cada interface recebe uma rota da sub-rede em que se encontra. Além disso, o Google Cloud fornece uma rota padrão para a interface de rede principal. Usando o roteamento baseado no destino, qualquer tráfego que não seja destinado a uma das sub-redes da instância é transferido da interface da rede principal. Para mais informações, consulte Comportamento do DHCP com várias interfaces de rede.

Quando houver redes em peering que incluam instâncias de VM com várias interfaces de rede, talvez seja necessário alterar a política de roteamento padrão baseada no destino para uma política de roteamento baseada na origem. Para mais informações, consulte Como configurar o roteamento de políticas.

Os cenários a seguir mostram quando uma instância de VM pode ou não exigir uma política de roteamento baseada na origem

Política de roteamento obrigatória

No exemplo a seguir, vm1 requer uma política de roteamento com base na origem para que vm1 e vm2 possam se comunicar. Sem uma política de roteamento, todo o tráfego sai por vm1-nic0 para network-a, a menos que o tráfego seja destinado a subnet-b em que nic1 está localizado. Isso significa que o tráfego de vm1 destinado a network-c é descartado ou enviado para o destino incorreto porque a instância de VM sempre envia tráfego para fora de sua interface principal.

O requisito da política de roteamento depende dos intervalos de IP da sub-rede

No exemplo a seguir, a interface da rede principal de vm1 está em uma rede que tem peering com outra rede. Não é necessário configurar o roteamento de políticas em vm1.

No exemplo a seguir, vm1-nic1 e vm2-nic0 estão em sub-redes sobrepostas. Quando o peering é estabelecido, o Google Cloud verifica a sobreposição de intervalos de IP somente entre pares e não entre redes com instâncias com interfaces de rede. Para garantir que a comunicação entre vm1 e vm2 funcione, é preciso adicionar uma política de roteamento com base na origem em vm1-nic0.

Peering entre interfaces

O exemplo a seguir mostra uma instância de VM com várias interfaces de rede, em que todas estão em uma rede com peering. Nesse caso, vm1 não exige uma política de roteamento baseada na origem. O tráfego que sai da instância de VM para cada sub-rede usa a interface de rede correspondente.

Se vm1 enviar o tráfego para o endereço IP de vm2-nic1, o tráfego entrará em nic1, mas sairá de nic0. Da mesma forma, se vm3 enviar o tráfego para o endereço IP de vm2-nic0, o tráfego entrará em nic0, mas sairá de nic1.

Intervalos secundários de sub-rede

Uma sub-rede tem um único intervalo de endereços IP primários e, opcionalmente, um ou mais intervalos de endereços IP secundários. Para cada intervalo de endereços IP de sub-rede, o Google Cloud cria uma rota de sub-rede. Quando você usa o peering de rede VPC, o Google Cloud sempre troca as rotas de sub-rede entre as duas redes com peering. Se as regras de firewall em cada rede permitirem a comunicação, as instâncias de VM em uma rede poderão se comunicar com instâncias na rede com peering.

Quando você estabelece uma relação de peering, o Google Cloud verifica se os intervalos primários e secundários de uma sub-rede não se sobrepõem a outros intervalos em redes com peering.

A seguir