Ordem das rotas

Esta página descreve como rotas personalizadas com próximos saltos de túneis do Cloud VPN funcionarão no Google Cloud.

Tipos de rota

É possível que um túnel do Cloud VPN seja um próximo salto para uma rota personalizada na sua rede de VPC. Cada rota personalizada com um túnel do Cloud VPN próximo salto define um caminho de saída para os pacotes que saem da rede de VPC:

  • Um túnel de VPN clássica que usa roteamento dinâmico ou um túnel de VPN de alta disponibilidade é sempre gerenciado por um Cloud Router. O Cloud Router recebe divulgação do BGP e envia mensagens do BGP para um gateway da VPN de peering. O Cloud Router cria e remove automaticamente trajetos dinâmicos personalizados na sua rede de VPC. Esses são os trajetos com destinos em uma rede de peering. Ele também anuncia rotas para uma rede de peering. Estas são rotas para os intervalos IP da sub-rede da VPC ou para destinos personalizados que você especificar em uma configuração do Cloud Router. O conjunto de rotas que o Cloud Router importa e exporta são controladas pelo modo de roteamento dinâmico da sua rede da VPC.

  • Um túnel da VPN clássica com base em uma rota ou em uma política usa roteamento estático. Se você criar um desses túneis usando o Console do Cloud, o Google Cloud criará automaticamente rotas estáticas personalizadas com base nos intervalos de IP remotos especificados na configuração do Cloud VPN. Se você usar comandos gcloud para criar um desses túneis, deverá criar manualmente as rotas estáticas que usam o túnel como um próximo salto.

Exemplos de cenários

O Google Cloud segue uma aplicabilidade e um pedido bem definidos ao selecionar o próximo salto para o qual um pacote deve ser enviado. Os exemplos a seguir demonstram interações comuns entre rotas e o Cloud VPN.

Interação com rotas de sub-redes

A tabela a seguir demonstra como as rotas de sub-rede e as rotas personalizadas interagem. Cada linha representa um possível intervalo de IP de uma sub-rede em uma rede VPC. O intervalo de IP local é 10.2.0.0/16.

Rede da VPC Roteamento de túnel do Cloud VPN
Intervalo de IP da sub-rede do Google Cloud Apenas VPN clássica estática
(com base em política e rota)
VPN clássica ou de alta disponibilidade
dinâmicas (BGP)
10.2.0.0/16
Igual ao intervalo de IP local
O Google Cloud não permite que você crie uma rota estática personalizada que tenha como destino 10.2.0.0/16 e que seu próximo salto seja um túnel do Cloud VPN. O Cloud Router associado ao túnel ignora todas as rotas divulgadas com 10.2.0.0/16 como destino. O tráfego destinado a 10.2.0.0/16 permanece na sua rede de VPC.
10.0.0.0/8
Mais amplo que o intervalo de IP local
(máscara de sub-rede menor)
O Google Cloud não permite que você crie uma rota estática personalizada que tenha como destino 10.2.0.0/16 e que seu próximo salto seja um túnel do Cloud VPN. O Cloud Router associado ao túnel ignora todas as rotas divulgadas que tenham como destino ou se ajustem a 10.0.0.0/8, incluindo 10.2.0.0/16. O tráfego destinado a 10.0.0.0/8 permanece na sua rede de VPC.
10.2.99.0/24
Mais estreito que o intervalo de IP local
(máscara de sub-rede mais longa)
O Google Cloud permite que você crie uma rota estática personalizada com o destino 10.2.0.0/16 e o próximo salto do túnel do Cloud VPN. No entanto, o tráfego para endereços IP em 10.2.99.0/24 permanece dentro de sua rede de VPC. O Cloud Router associado ao túnel aceita uma rota divulgada que tenha como destino 10.2.0.0/16. No entanto, o tráfego para endereços IP em 10.2.99.0/24 permanece dentro de sua rede de VPC.

Quando os túneis estão desativados

Roteamento dinâmico (BGP)

Quando um túnel da VPN clássica que usa roteamento dinâmico ou um túnel de VPN de alta disponibilidade fica inativo, o Cloud Router que o gerencia automaticamente remove as rotas dinâmicas personalizadas aprendidas em cerca de 40 segundos. É possível que as rotas dinâmicas personalizadas sejam adicionadas novamente quando o túnel for restabelecido.

Esse processo é totalmente automático, mas ainda é possível resultar em perda de alguns pacotes durante o tempo que o Cloud Router leva para remover as rotas afetadas.

Roteamento estático

O Google Cloud nunca considera um túnel do Cloud VPN que não tenha estabelecido uma associação de segurança do IKE (SA) como um próximo salto válido. No entanto, isso não significa que o tráfego será automaticamente enviado a um próximo salto para um túnel operacional do Cloud VPN.

Os cenários a seguir demonstram os comportamentos esperados:

  • Se você tiver várias rotas estáticas personalizadas para o mesmo destino, cada uma com um túnel diferente do Cloud VPN, o Google Cloud considerará apenas os que estabeleceram associações de segurança do IKE (fase 1). Os túneis desativados, ou seja, que não têm associações de segurança do IKE válidas, são desconsiderados antes de considerar a prioridade da rota.

    Por exemplo, suponha que você tenha três rotas estáticas personalizadas para o destino 192.168.168.0/24. A primeira rota tem prioridade 10, com um túnel do Cloud VPN inativo no próximo salto. A segunda com prioridade 20, mas com um túnel ativo no próximo salto. E, por último, uma terceira com prioridade 30, também com um túnel ativo no próximo salto. O Google Cloud enviará tráfego para o segundo próximo salto, mesmo que o trajeto tenha uma prioridade mais baixa do que o do próximo salto. Se o primeiro túnel for restabelecido, o Google Cloud o considerará um próximo salto válido e usará essa rota.

  • O tráfego será descartado se todos os túneis do Cloud VPN, que são disponibilizados como próximos saltos para rotas estáticas personalizadas com o mesmo destino, estiverem inativos. Isso acontecerá mesmo se houver uma rota estática personalizada para um destino mais amplo com um túnel operacional do próximo salto.

    Por exemplo, suponha que você tenha uma rota estática personalizada para 192.168.168.0/24 na qual o túnel do Cloud VPN do próximo salto esteja inativo (nenhum SA do IKE válido). Mesmo se você tiver uma rota para 192.168.0.0/16 que tenha no próximo salto um túnel operacional do Cloud VPN, o tráfego para 192.168.168.0/24 será descartado. Isso ocorre porque o Google Cloud sempre seleciona rotas com os destinos mais específicos.

Quando o tráfego muda de um túnel do Cloud VPN do próximo salto para outro, você ainda pode ter a perda de pacotes. É possível que pacotes em trânsito sejam descartados e precisem ser retransmitidos.

ECMP sobre túneis

Para roteamento dinâmico e estático, se houver mais de uma rota personalizada para o mesmo destino, com a mesma prioridade e um túnel ativo no próximo salto (com SA do IKE estabelecido), o Google Cloud distribuirá pacotes entre os túneis usando ECMP.

Esse método de balanceamento é baseado em um hash. Desse modo, todos os pacotes do mesmo fluxo usam o mesmo túnel caso ele esteja ativo.

Para testar o comportamento do ECMP, use iperf3 para enviar vários fluxos simultâneos do TCP, de preferência de várias VMs do GCP, por túneis do Cloud VPN. Não realize testes usando ICMP (ping) se você precisar validar o comportamento do ECMP. Um teste de ping de uma instância de VM não é suficiente para testar saídas baseadas em ECMP por meio de túneis do Cloud VPN, já que apenas um túnel é selecionado quando você tem uma origem e destino fixos. O ICMP não tem nenhum conceito de portas e é um protocolo fixo. Portanto, o hash é calculado somente a partir de duas informações: os endereços de origem e destino (um hash de duas tuplas).

A seguir