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.

Para informações gerais sobre as rotas do Google Cloud, incluindo a aplicabilidade da rota e os parâmetros de rota estática e de ordem, consulte a visão geral das rotas da nuvem privada virtual (VPC).

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 de próximo salto define um caminho de saída para os pacotes que saem da rede VPC:

  • Um Cloud Router sempre gerencia um túnel da VPN clássica que usa roteamento dinâmico ou um túnel de VPN de alta disponibilidade. 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 modo de roteamento dinâmico da sua rede VPC controla o conjunto de rotas que o Cloud Router importa e exporta.

  • Um túnel da VPN clássica com base em uma rota ou em uma política usa roteamento estático. Se você usa o Console do Google Cloud para criar um desses túneis, o Google Cloud cria automaticamente rotas estáticas personalizadas com base nos intervalos de IP remotos especificados no Cloud VPN. Se você usar a Google Cloud CLI para criar um desses túneis, crie 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 ao qual um pacote precisa 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. Os intervalos locais são 10.2.0.0/16 para IPv4 e fd20:a:b:c::/64 para IPv6.

O tráfego IPv6 é compatível apenas com gateways de VPN de alta disponibilidade que estão configurados com um tipo de pilha dupla de IPv4 e IPv6.

Rede 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.
fd20:a:b:c::/64
Igual ao intervalo de IP local		 A VPN clássica não é compatível com o IPv6. O Cloud Router associado ao túnel ignora todas as rotas divulgadas com fd20:a:b:c::/64 como destino. O tráfego destinado a fd20:a:b:c::/64 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.
fd20:a:b::/48
Mais amplo que o intervalo de IP local
(máscara de sub-rede menor)		 A VPN clássica não é compatível com o IPv6. O Cloud Router associado ao túnel ignora todas as rotas divulgadas que tenham como destino ou se ajustem a fd20:a:b::/48, incluindo fd20:a:b:c::/64. O tráfego destinado a fd20:a:b::/48 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 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.
fd20:a:b:c::/80
Mais estreito que o intervalo de IP local
(máscara de sub-rede mais longa)		 A VPN clássica não é compatível com o IPv6. O Cloud Router associado ao túnel aceita uma rota divulgada que tenha como destino fd20:a:b:c::/64. No entanto, o tráfego para endereços IP em fd20:a:b:c::/80 permanece dentro de sua rede de VPC.

Quando os túneis estão desativados

Roteamento dinâmico (BGP)

Quando um túnel de 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 remove automaticamente as rotas aprendidas. O tempo necessário para detectar a interrupção varia de acordo com a ativação da Detecção de encaminhamento bidirecional (BFD, na sigla em inglês). Se o BFD estiver ativado, a detecção ocorrerá quando o temporizador de espera do BGP expirar. Caso contrário, a detecção ocorrerá em menos de 60 segundos. As rotas aprendidas podem ser readicionadas quando o túnel é 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 como próximo salto válido que não tenha estabelecido uma associação de segurança do IKE (SA). Se um túnel do Cloud VPN tiver estabelecido uma SA do IKE, o Google Cloud o considerará operacional. Observe que um túnel operacional do Cloud VPN só passa o tráfego se for selecionado como o próximo salto de acordo com a ordem de roteamento. O próximo salto para uma rota diferente, com um destino mais específico ou com prioridade mais alta, pode ser usado.

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 túneis que estabeleceram as SAs do IKE (fase 1). Túneis inativos, ou seja, que não têm SAs IKE válidos, são ignorados 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: uma com prioridade 10 em que próximo túnel do Cloud VPN está inativo, um segundo com prioridade 20 em que o túnel do próximo salto está ativo e um terceiro com prioridade 30. O túnel do próximo salto também está ativo. 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. O tráfego é descartado mesmo que haja 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 em que 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, ainda pode haver 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 e tiver a mesma prioridade e um túnel ativo do próximo salto (com SA do IKE estabelecido), o Google Cloud usará vários caminhos de custo igual (ECMP) para distribuir pacotes entre os túneis.

Esse método de balanceamento é baseado em um hash. Sendo assim, 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 instâncias de máquina virtual (VM) do Google Cloud, usando túneis do Cloud VPN. Se você precisar validar o comportamento do ECMP, não use ICMP (ping) para realizar testes. Um teste ping de uma instância de VM não é suficiente para testar a saída baseada em ECMP por meio de túneis do Cloud VPN porque apenas um túnel é selecionado quando você tem uma origem e um 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