Visão geral do peering da rede VPC

O peering de rede VPC do Google Cloud permite conectividade de endereço IP interno em duas redes de nuvem privada virtual (VPC), pertencentes ou não ao mesmo projeto ou à mesma organização.

O peering de rede VPC permite conectar redes VPC para que as cargas de trabalho em diferentes redes VPC possam se comunicar internamente. O tráfego fica restrito à rede do Google e não passa pela Internet pública.

O peering de rede VPC é útil nestes ambientes:

  • 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 precisam se comunicar usando endereços IP internos.

Se você tiver vários domínios administrativos de rede na sua organização, o peering de rede VPC permitirá a disponibilização de serviços em redes VPC usando endereços IP internos. Se você oferece serviços a outras organizações, o peering de rede VPC permite disponibilizar esses serviços usando endereços IP internos. A capacidade de oferecer serviços em várias organizações é útil se você quiser oferecer serviços a outras empresas e também se você for proprietário ou controlar mais de uma organização.

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 de rede: a conectividade que usa apenas endereços internos fornece menor latência do que a conectividade que usa endereços externos.
  • Segurança da rede: não é necessário que os proprietários de serviços tenham os serviços expostos à Internet pública nem tenham que lidar com os riscos associados a isso.
  • Custo da rede: o Google Cloud cobra o preço da largura de banda de saída para redes que usam IPs externos para se comunicarem, mesmo 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 de VPC sempre trocam rotas de sub-rede que não usam endereços IP públicos reutilizados de modo privado. As redes precisam importar explicitamente as rotas de sub-rede que usam endereços IP públicos reutilizados de modo privado para recebê-las.
  • É possível trocar rotas personalizadas (rotas estáticas e dinâmicas), caso as configurações de peering tenham sido definidas para importar 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 do tráfego de peering é igual à política de faturamento do 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

Analise cuidadosamente a Ordem de roteamento para saber como o Google Cloud resolve conflitos de rota entre redes em um grupo de peering.

Como importar e exportar rotas personalizadas

Rotas de sub-rede que não usam endereços IP públicos reutilizados de modo privado são sempre trocadas entre redes com peering. Também é possível trocar rotas personalizadas, que incluem rotas estáticas e dinâmicas, bem como rotas para sub-redes que usam endereços de IP públicos reutilizados de maneira privada se os administradores das duas redes tiverem as configurações de peering apropriadas.

Quando você importa rotas personalizadas, sua rede VPC receberá rotas personalizadas da rede com peering somente 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 sejam acessíveis de redes com peering.
  • Se você tiver um túnel VPN ou uma interconexão, será possível compartilhar rotas personalizadas para que as redes com peering acessem sua rede no 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:

  • No momento de fazer o peering, o Google Cloud verifica se há intervalos de IP de sub-rede que se sobreponham a intervalos de IP de sub-rede na outra rede. Se houver alguma sobreposição, o peering não será estabelecido. Essa verificação de sobreposição é apenas para intervalos de sub-rede VPC. As rotas estáticas e dinâmicas não são verificadas. Se o peering continuar, elas serão exportadas do jeito que estiverem.
  • 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 duas sub-redes em peering (clique para ampliar)
Intervalos de IP de sub-rede sobrepostos entre duas sub-redes em peering (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 sub-redes em peering (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 sub-redes em peering (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.

A VPN de alta disponibilidade e o Cloud Interconnect requerem roteamento dinâmico. Os túneis de VPN clássica podem usar roteamento estático ou dinâmico. No entanto, alguns casos de uso de túneis de VPN clássica estão obsoletos.

Para roteamento dinâmico, use o Cloud Router para atualizar dinamicamente as rotas entre a 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 que vm-a2 esteja em uma região diferente do túnel 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.

  • Por padrão, o Cloud Router que gerencia rotas para túneis conectados ao gateway do Cloud VPN em network-b divulga automaticamente os intervalos de endereços IP de sub-rede de sub-redes em network-b.

  • As rotas para destinos locais são instaladas como rotas dinâmicas personalizadas em network-b pelo Cloud Router, que gerencia rotas para túneis conectados ao gateway do Cloud VPN em network-b.

  • Adicione os intervalos de endereços IP de sub-rede de sub-redes em network-a e network-c configurando divulgações de rota personalizadas no Cloud Router, que gerencia rotas para túneis conectados ao gateway do Cloud VPN em network-b.

  • As rotas dinâmicas personalizadas (para destinos locais) são trocadas usando o peering de rede VPC para network-a e network-c porque network-b foi configurado para exportar rotas personalizadas, e as outras duas redes foram configuradas para importá-las.

  • Neste exemplo, veja a seguinte acessibilidade:

    • As instâncias de VM em network-a podem acessar outras VMs em network-b e sistemas na rede local.
    • 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.
    • As instâncias de VM em network-c podem acessar outras VMs em network-b e 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 faça peering da rede network-a com network-c.

Balanceadores de carga internos

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:

  • Se o acesso global for desativado em um balanceador de carga TCP/UDP interno, os clientes precisarão estar na mesma região que o balanceador. Eles também precisam estar na mesma rede VPC do balanceador de carga ou em uma rede conectada à rede VPC balanceador usando o peering da rede VPC.

  • Se o acesso global estiver ativado em um balanceador de carga TCP/UDP interno, os clientes poderão estar em qualquer região. Eles ainda precisam estar na mesma rede VPC que o balanceador de carga ou em uma rede conectada à rede VPC do balanceador usando peering da rede VPC.

  • 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.

Veja mais informações em:

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.

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 que não usam endereços IP públicos reutilizados de maneira privada entre as duas redes com peering. Se as regras de firewall de cada rede permitirem a comunicação, as instâncias de VM de 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