Ordem dos trajetos

Esta página descreve como funcionam as rotas personalizadas com saltos seguintes de túneis da VPN na nuvem Google Cloud.

Para informações gerais sobre os Google Cloud trajetos, incluindo a aplicabilidade e a ordem dos trajetos, bem como os parâmetros dos trajetos estáticos, consulte a vista geral dos trajetos da nuvem virtual privada (VPC).

Tipos de trajetos

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

  • Um Cloud Router gere sempre um túnel de VPN clássica que usa encaminhamento dinâmico ou um túnel de VPN de alta disponibilidade. O Cloud Router recebe anúncios BGP e envia mensagens BGP para um gateway de VPN de pares. O Cloud Router cria e remove automaticamente rotas dinâmicas na sua rede VPC, ou seja, as rotas com destinos numa rede de pares. Também anuncia rotas para uma rede de pares, ou seja, rotas para os intervalos de IP de sub-redes na sua rede VPC ou para destinos personalizados que especifica numa configuração do Cloud Router. O modo de encaminhamento dinâmico da sua rede VPC controla o conjunto de rotas que o Cloud Router importa e exporta.

  • Um túnel de VPN clássica baseado em políticas ou em rotas usa encaminhamento estático. Se usar a Google Cloud consola para criar um destes túneis, Google Cloud cria automaticamente rotas estáticas com base nos intervalos de IP remotos que especificar na configuração da Cloud VPN. Se usar a CLI do Google Cloud para criar um destes túneis, tem de criar manualmente as rotas estáticas que usam o túnel como um próximo salto.

Cenários de exemplo

Google Cloud segue uma aplicabilidade e uma ordem bem definidas quando seleciona o próximo salto para o qual um pacote deve ser enviado. Os exemplos seguintes demonstram interações comuns entre trajetos e o Cloud VPN.

Interação com encaminhamentos de sub-rede

A tabela seguinte demonstra como os trajetos de sub-rede e os trajetos personalizados interagem. Cada linha representa um intervalo de IPs possível de uma sub-rede numa rede VPC. Os intervalos no local são 10.2.0.0/16 para IPv4 e fd20:a:b:c::/64 para IPv6.

O tráfego IPv6 só é suportado por gateways de VPN de alta disponibilidade que estão configurados com um tipo de pilha dupla de IPv4 e IPv6.

Rede da VPC Encaminhamento do túnel do Cloud VPN
Intervalo de IP da Google Cloud sub-rede Estática (baseada em políticas, baseada em rotas)
Apenas VPN clássica		 Dinâmico (BGP)
VPN clássica ou VPN de alta disponibilidade
10.2.0.0/16
Igual ao intervalo de IP no local		 Google Cloud não lhe permite criar uma rota estática cujo destino seja 10.2.0.0/16 e cujo próximo salto seja um túnel de VPN do Google Cloud. O Cloud Router associado ao túnel ignora todas as rotas anunciadas com um destino de 10.2.0.0/16. O tráfego destinado a 10.2.0.0/16 permanece na sua rede VPC.
fd20:a:b:c::/64
Igual ao intervalo de IP no local		 A VPN clássica não suporta IPv6. O Cloud Router associado ao túnel ignora todas as rotas anunciadas com um destino de fd20:a:b:c::/64. O tráfego destinado a fd20:a:b:c::/64 permanece na sua rede VPC.
10.0.0.0/8
Mais abrangente do que o intervalo de IP no local
(máscara de sub-rede mais pequena)		 Google Cloud não lhe permite criar uma rota estática cujo destino seja 10.2.0.0/16 e cujo próximo salto seja um túnel de VPN do Google Cloud. O Cloud Router associado ao túnel ignora todas as rotas anunciadas cujos destinos correspondam ou se enquadrem em 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 VPC.
fd20:a:b::/48
Mais abrangente do que o intervalo de IP no local
(máscara de sub-rede mais pequena)		 A VPN clássica não suporta IPv6. O Cloud Router associado ao túnel ignora todas as rotas anunciadas cujos destinos correspondam ou se enquadrem em fd20:a:b::/48, incluindo fd20:a:b:c::/64. O tráfego destinado a fd20:a:b::/48 permanece na sua rede VPC.
10.2.99.0/24
Mais restrito do que o intervalo de IP no local
(máscara de sub-rede mais longa)		 Google Cloud permite-lhe criar uma rota estática com o destino 10.2.0.0/16 e o túnel do Cloud VPN de próximo salto. No entanto, o tráfego para endereços IP em 10.2.99.0/24 permanece na sua rede VPC. O Cloud Router associado ao túnel aceita uma rota anunciada cujo destino é 10.2.0.0/16. No entanto, o tráfego para endereços IP em 10.2.99.0/24 permanece na sua rede VPC.
fd20:a:b:c::/80
Mais restrito do que o intervalo de IP no local
(máscara de sub-rede mais longa)		 A VPN clássica não suporta IPv6. O Cloud Router associado ao túnel aceita uma rota anunciada cujo destino é fd20:a:b:c::/64. No entanto, o tráfego para endereços IP em fd20:a:b:c::/80 permanece na sua rede VPC.

Quando os túneis estão inativos

Encaminhamento dinâmico (BGP)

Quando um túnel de VPN clássica que usa o encaminhamento dinâmico ou um túnel de VPN de HA fica inativo, o Cloud Router que o gere remove automaticamente as rotas aprendidas. O tempo necessário para detetar a falha varia consoante a ativação da Deteção de encaminhamento bidirecional (BFD). Se o BFD estiver ativado, a deteção ocorre quando o temporizador de retenção do BGP expira. Caso contrário, a deteção ocorre em menos de 60 segundos. As rotas aprendidas podem ser readicionadas quando o túnel é restabelecido.

Este processo é totalmente automático, mas pode resultar na perda de alguns pacotes durante o tempo que o Cloud Router demora a remover as rotas afetadas.

Encaminhamento estático

Google Cloud Nunca considera um túnel da Cloud VPN como um próximo salto válido que não tenha estabelecido uma associação de segurança (SA) IKE. Se um túnel de VPN na nuvem tiver estabelecido uma SA IKE, Google Cloudconsidera-o operacional. Um túnel do Cloud VPN operacional só passa tráfego se for selecionado como o próximo salto de acordo com a ordem de encaminhamento. Em alternativa, pode ser usado o próximo salto para uma rota diferente, com um destino mais específico ou com uma prioridade mais elevada.

Os seguintes cenários demonstram os comportamentos esperados:

  • Se tiver várias rotas estáticas para o mesmo destino, cada uma com um túnel de VPN do Google Cloud de próximo salto diferente, Google Cloud só são considerados os túneis que estabeleceram SAs IKE (fase 1). Os túneis que estão inativos, ou seja, que não têm SAs IKE válidas, são ignorados antes de considerar a prioridade do trajeto.

    Por exemplo, suponhamos que tem três rotas estáticas para o destino 192.168.168.0/24: uma com a prioridade 10 cujo túnel de VPN do Google Cloud está inativo, uma segunda com a prioridade 20 cujo túnel de próximo salto está ativo e uma terceira com a prioridade 30 cujo túnel de próximo salto também está ativo.O Google Cloud envia tráfego para o segundo próximo salto, mesmo que a respetiva rota tenha uma prioridade inferior à da rota cujo próximo salto está inativo. Se o primeiro túnel for restabelecido, o sistema Google Cloud considera-o um salto seguinte válido e usa essa rota.

  • O tráfego é rejeitado se todos os túneis de VPN na nuvem que servem como saltos seguintes para rotas estáticas com o mesmo destino estiverem inativos. O tráfego é ignorado mesmo que exista um trajeto estático para um destino mais amplo com um túnel de salto seguinte operacional.

    Por exemplo, suponhamos que tem um encaminhamento estático para 192.168.168.0/24 cujo próximo salto do túnel do Cloud VPN está inativo (sem SA IKE válido). Mesmo que tenha um encaminhamento para 192.168.0.0/16 cujo próximo salto seja um túnel de VPN na nuvem operacional, o tráfego para 192.168.168.0/24 é rejeitado. Isto deve-se ao facto de o Google Cloud aplicativo selecionar sempre os trajetos com os destinos mais específicos.

Quando o tráfego muda de um túnel de VPN do Google Cloud de próximo salto para outro, deve continuar a esperar perdas de pacotes. Os pacotes em voo podem ser ignorados e têm de ser retransmitidos.

ECMP sobre túneis

Para o encaminhamento dinâmico e estático, se existir mais do que uma rota personalizada para o mesmo destino e tiver a mesma prioridade e um túnel de salto seguinte ativo (IKE SA estabelecido), o Google Cloud usa o encaminhamento de vários caminhos de custo igual (ECMP) para distribuir pacotes entre os túneis.

Este método de equilíbrio baseia-se num hash, pelo que todos os pacotes do mesmo fluxo usam o mesmo túnel, desde que esse túnel esteja ativo.

Para testar o comportamento do ECMP, use o iperf3, através de túneis de VPN do Google Cloud. Se precisar de validar o comportamento do ECMP, não use o 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 através de túneis de VPN na nuvem, porque só é selecionado um túnel quando tem uma origem e um destino fixos. O ICMP não tem o conceito de portas e é um protocolo fixo, pelo que o hash é calculado apenas a partir de duas informações: os endereços de origem e destino (um hash de dois elementos).

O que se segue?