Visão geral de rotas

As rotas do Google Cloud definem os caminhos percorridos pelo tráfego de rede de uma instância de máquina virtual (VM) para outros destinos. Esses destinos podem estar na sua rede de nuvem privada virtual (VPC) do Google Cloud (por exemplo, em outra VM) ou fora dela.

Em uma rede VPC, uma rota consiste em um prefixo de destino no formato CIDR e um próximo salto. Quando uma instância em uma rede VPC envia um pacote, o Google Cloud entrega o pacote ao próximo salto da rota se o endereço de destino do pacote estiver dentro do intervalo de destino da rota.

Esta página fornece uma visão geral de como as rotas funcionam no Google Cloud.

Roteamento no Google Cloud

Toda rede VPC usa um mecanismo de roteamento virtual distribuído e escalonável. Não há nenhum dispositivo físico atribuído à rede. Algumas rotas podem ser aplicadas seletivamente, mas a tabela de roteamento de uma rede VPC é definida no nível da rede VPC.

Cada instância de VM tem um controlador que conhece todas as rotas aplicáveis da tabela de roteamento da rede. Cada pacote que deixa uma VM é entregue no próximo salto apropriado de uma rota aplicável com base em uma ordem de roteamento. Quando você adiciona ou exclui uma rota, o conjunto de alterações é propagado para os controladores de VM usando um design de consistência posterior.

Tipos de rota

As tabelas a seguir resumem como o Google Cloud categoriza rotas em redes VPC.

Tipo e destino Próximo salto Observações
Rotas geradas pelo sistema
Rotas padrão geradas pelo sistema
0.0.0.0/0 para IPv4
::/0 para IPv6
default-internet-gateway Aplica-se a toda a rede VPC

Pode ser removida ou substituída
Rota de sub-rede
Criada automaticamente para cada intervalo do endereço IP da sub-rede
Rede VPC
Encaminha pacotes a VMs e balanceadores de carga internos
Aplica-se a toda a rede VPC

Criada, atualizada e removida automaticamente pelo Google Cloud quando você cria, modifica ou exclui uma sub-rede ou um intervalo de endereços IP secundários de uma sub-rede.
Rotas personalizadas
Rota estática
Compatível com vários destinos
Próximo salto de rota estática válido Para balanceadores de carga TCP/UDP internos do próximo salto, aplica-se somente ao tráfego TCP e UDP na mesma região do balanceador de carga, a menos que o acesso global esteja ativado.

Para outros próximos saltos estáticos: a rota poderá ser aplicada a VMs específicas se você especificar tags de rede na rota. Se você não especificar nenhuma tag de rede, a rota será aplicada a todas as VMs na rede VPC.
Rota dinâmica
Destinos que não entram em conflito com rotas de sub-rede ou rotas estáticas
Par de uma sessão do BGP em um Cloud Router As rotas são adicionadas e removidas automaticamente pelos Cloud Routers na sua rede VPC.

As rotas se aplicam às VMs de acordo com o modo de roteamento dinâmico da rede VPC.
Rotas de peering
Rota de sub-rede em peering
Representa um intervalo de endereços IP de sub-rede em uma rede conectada usando peering de rede VPC.
Rede VPC com peering
Encaminha pacotes a VMs e balanceadores de carga internos na rede com peering
Aplica-se a toda a rede VPC

Criada, atualizada e removida automaticamente pelo Google Cloud quando as sub-redes são criadas, modificadas ou excluídas na rede de peering.
Peering personalizado
Rota personalizada estática ou personalizada em uma rede conectada usando peering de rede VPC
Próximo salto na rede VPC com peering As rotas personalizadas de peering compatíveis com rotas estáticas na rede de peering se aplicam da seguinte maneira:
  • Se a rota personalizada de peering tiver o suporte de uma rota estática personalizada em que o próximo salto é um balanceador de carga TCP/UDP interno, a rota será aplicada ao tráfego TCP e UDP na mesma região do balanceador de carga, a menos que o acesso global é ativado na regra de encaminhamento do balanceador de carga.
  • Se a rota personalizada de peering tiver o suporte de uma rota estática personalizada em que o próximo salto não é um balanceador de carga TCP/UDP interno e essa rota estática personalizada não tiver uma tag associada: a rota se aplica a todas as VMs na rede VPC que importa a rota.
  • Rotas estáticas em uma rede de peering que usam tags de rede ou em que os próximos saltos são o gateway de Internet padrão nunca são exportadas em uma relação de peering.
As rotas personalizadas de peering compatíveis com rotas dinâmicas na rede com peering se aplicam de acordo com o modo de roteamento dinâmico da rede VPC que importa as rotas.

Rotas padrão geradas pelo sistema

Ao criar uma rede VPC, ela inclui uma rota padrão IPv4 gerada pelo sistema (0.0.0.0/0). Se você ativar endereços IPv6 externos em uma sub-rede, uma rota padrão IPv6 gerada pelo sistema (::/0) será adicionada a essa rede VPC. As rotas padrão têm as seguintes finalidades:

O Google Cloud usa uma rota padrão se uma rota com um destino mais específico não se aplicar a um pacote. Para ver informações sobre como a especificidade do destino e a prioridade da rota são usadas para selecionar uma rota, consulte Ordem de rotas.

Se você quiser isolar completamente sua rede da Internet ou se precisar substituir a rota padrão por uma personalizada, você pode excluir a rota padrão:

  • Se você quiser rotear o tráfego da Internet para um próximo salto diferente, substitua a rota padrão por uma dinâmica ou estática personalizada. Por exemplo, é possível substituí-la por uma rota estática personalizada que tenha como próximo salto uma VM do proxy.

  • IPv4 e IPv6: se você excluir a rota padrão e não a substituir, os pacotes destinados a intervalos IP que não forem cobertos por outras rotas serão descartados.

    Se você excluir a rota padrão do IPv6, as VMs não poderão se conectar a VMs em outras regiões usando os endereços IPv6.

Rotas de sub-rede

As rotas de sub-rede definem os caminhos para recursos como VMs e balanceadores de carga internos em uma rede VPC.

Cada sub-rede tem pelo menos uma rota de sub-rede com um destino que corresponde ao intervalo de IP primário da sub-rede. Se a sub-rede tiver intervalos de IP secundários, há uma rota de sub-rede correspondente para cada um dos intervalos de endereços IP secundários. Para mais informações sobre intervalos de IP de sub-rede, consulte Redes e sub-redes.

Nenhuma outra rota pode ter um destino que corresponda ou seja mais específico (tenha uma máscara de sub-rede maior) do que o destino de uma rota de sub-rede.

Rotas de sub-rede sempre têm os destinos mais específicos. Elas não podem ser substituídas por outras rotas, mesmo que outra tenha uma prioridade mais alta. Isso ocorre porque o Google Cloud considera a especificidade do destino antes da prioridade ao selecionar uma rota. O Google Cloud usa 0 como prioridade para todas as rotas de sub-redes.

Veja nos pontos a seguir como as rotas de sub-rede são criadas e removidas:

  • Quando você adiciona uma sub-rede, o Google Cloud cria uma rota de sub-rede correspondente ao intervalo de endereços IP primário da sub-rede.

  • As redes VPC de modo automático criam uma rota de sub-rede para os intervalos de IP principais de cada uma das sub-redes criadas automaticamente. Só é possível excluir essas sub-redes se você converter a rede VPC do modo automático para o modo personalizado.

  • Não é possível excluir uma rota de sub-rede a menos que modifique ou exclua a sub-rede:

    • Quando você remove um intervalo secundário de uma sub-rede, a rota de sub-rede desse intervalo secundário é excluída automaticamente.

    • Quando você exclui uma sub-rede, todas as rotas de sub-rede para os intervalos principais e secundários são excluídas automaticamente. Não é possível excluir a rota de sub-rede para o intervalo principal da sub-rede de nenhuma outra maneira.

O número de rotas de sub-rede em uma rede VPC é limitado pelo número máximo de intervalos de IP de sub-redes (primários e secundários).

Rotas estáticas

As rotas estáticas são definidas usando parâmetros de rota estática e compatíveis com próximos saltos da rota estática. É possível criar rotas estáticas de duas maneiras:

Rotas dinâmicas

Rotas dinâmicas são gerenciadas por Cloud Routers na rede VPC. Os destinos sempre representam intervalos de endereços IP fora da sua rede VPC, recebidos de um par do BGP. Rotas dinâmicas são usadas por:

As redes VPC ignoram os destinos recebidos pelo Cloud Routers quando os destinos corresponderem a um destes critérios:

  • O destino corresponde exatamente a um intervalo de endereços IP de sub-rede.

  • O destino se encaixa em um intervalo de sub-rede maior do que de uma sub-rede.

No entanto, o destino de uma rota dinâmica pode conter (pode ter uma máscara de sub-rede menor que) um intervalo de IPs de uma sub-rede. Por exemplo, se você tem um intervalo de IPs de sub-rede de 10.10.10.0/24, pode ter uma rota dinâmica com um destino de 10.10.10.0/23. Se o endereço IP de destino de um pacote não couber no destino da rota de sub-rede, o pacote será enviado para o próximo salto da rota dinâmica. O maior destino possível é 0.0.0.0/0.

Rotas de sub-redes de peering

As rotas de sub-rede de peering definem caminhos para recursos usando sub-redes em outra rede VPC conectada usando peering de rede VPC. A outra rede é chamada de rede VPC com peering.

As redes com peering compartilham rotas de sub-rede da seguinte maneira:

  • As redes com peering sempre exportam as rotas de sub-rede para todos os intervalos de endereços IP primários e secundários.

  • As redes com peering importam automaticamente rotas de sub-rede, desde que o destino (intervalo de endereços IP da sub-rede) não seja um endereço IP público utilizado em particular. É possível configurar um par para importar as rotas de sub-rede que usam endereços IP públicos de utilização privada, se necessário.

  • As rotas de sub-rede de peering importadas não podem ser removidas, a menos que você desative o peering. Quando você desativa o peering, todas as rotas de sub-rede de peering importadas são removidas automaticamente.

  • O Google Cloud impede conflitos de intervalos de endereços IP de sub-rede entre redes com peering.

O número combinado de rotas de sub-rede em uma rede VPC e as rotas de sub-rede com peering importadas de todas as redes de mesmo nível é limitado pelo número máximo de intervalos de IP de sub-redes (primários e secundários).

Rotas personalizadas de peering

É possível configurar redes em peering para exportar ou importar rotas personalizadas. Nesse contexto, as rotas personalizadas significam rotas estáticas e dinâmicas em uma rede VPC.

Mesmo quando uma rede VPC é configurada para exportar rotas personalizadas, ela omite esses tipos de rotas:

O número combinado de rotas estáticas e dinâmicas em uma rede VPC mais as rotas personalizadas de peering importadas de todas as redes de peering é limitado por:

  • Número máximo de rotas estáticas em um grupo de peering
  • Número máximo de rotas dinâmicas em um grupo de peering

Aplicabilidade e ordem

Rotas aplicáveis

Cada instância tem um conjunto de rotas aplicáveis, que são um subconjunto de todas as rotas na rede VPC. As rotas aplicáveis são os caminhos de saída possíveis que um pacote pode seguir quando enviado da instância.

  • As rotas de sub-rede e de peering de peering se aplicam a todas as instâncias. Rotas de sub-rede e rotas de sub-rede de peering correspondem a sub-redes em sua rede VPC e àquelas importadas de redes de peering.

  • A rota padrão gerada pelo sistema se aplica a todas as instâncias. É possível substituir a rota padrão gerada pelo sistema por uma rota estática personalizada, se preferir.

  • Rotas estáticas personalizadas podem ser aplicadas a todas as instâncias ou instâncias específicas. Rotas estáticas com um atributo de tag aplicam-se a instâncias que têm a mesma tag de rede. Se a rota não tiver uma tag de rede, a rota será aplicada a todas as instâncias na rede.

    • Quando uma rota estática personalizada tem um próximo salto de instância da VM, a rota é sempre válida, mesmo se a VM de próximo salto for excluída, desligada ou estiver com mau funcionamento. Para mais informações, consulte Instâncias como próximos saltos.

    • Quando uma rota estática personalizada tiver um próximo salto do túnel do Cloud VPN, a rota será sempre válida se o túnel estiver ativo. Para ver informações sobre como o Google Cloud lida com rotas de túneis desativados, consulte Quando os túneis são desativados na documentação do Cloud VPN.

  • Rotas dinâmicas se aplicam a instâncias baseadas no modo de roteamento dinâmico da rede VPC. Se uma rede VPC usar o modo de roteamento dinâmico regional, todos os Cloud Routers criarão rotas dinâmicas somente para prefixos aprendidos na região local. Caso uma rede VPC use o modo de roteamento dinâmico global, todos os Cloud Routers criarão rotas dinâmicas para prefixos aprendidos em todas as regiões.

    • Os Cloud Routers descartam automaticamente os prefixos aprendidos que correspondem aos próximos saltos inacessíveis (túneis do Cloud VPN ou anexos do Cloud Interconnect). Dependendo de sua rede, os Cloud Routers podem levar até 40 segundos de tempo de processamento para remover uma rota dinâmica com um próximo salto que esteja inativo.
  • Para alguns tráfegos com balanceamento de carga, as rotas aplicáveis são originadas fora da rede VPC. Para mais informações, consulte Caminhos de retorno do balanceador de carga.

Ordem de roteamento

Quando uma instância envia um pacote, o Google Cloud tenta selecionar uma rota do conjunto de rotas aplicáveis de acordo com a seguinte ordem de roteamento.

  1. Rotas de sub-rede e rotas de sub-rede de peering são consideradas primeiro porque essas rotas têm os destinos mais específicos. O Google Cloud considera as rotas de sub-redes de peering da mesma maneira que considera as rotas de sub-redes locais.

    • Se o endereço IP de destino de um pacote se encaixa em um destino de rota de sub-rede ou peering:

      • os pacotes são entregues ao endereço IP interno de uma instância de VM em execução ou ao balanceador de carga interno configurado;

      • os pacotes destinados a uma instância de VM interrompida são descartados;

      • os pacotes destinados a um endereço IP interno serão descartados se nenhum recurso do Google Cloud for configurado para usar o endereço IP.

    • O Google Cloud não permite que você crie uma rota estática personalizada que tenha um destino igual ou mais específico do que qualquer rota de sub-rede ou qualquer rota de sub-rede de peering.

    • Os Cloud Routers ignoram os prefixos aprendidos que correspondem exatamente ao destino de uma rota de sub-rede ou rota de sub-rede de peering.

    • Os Cloud Routers ignoram os prefixos aprendidos que se encaixam e têm uma máscara de sub-rede mais longa do que uma rota de sub-rede ou rota de sub-rede de peering.

  2. Se o pacote não puder ser roteado por uma rota de sub-rede ou rota de sub-rede de peering, o Google Cloud procurará uma rota personalizada estática, dinâmica ou de peering que tenha o destino mais específico. Por exemplo,10.240.1.0/24 é um destino mais específico que 10.240.0.0/16 para pacotes com o destino 10.240.1.4.

  3. Se mais de uma rota tiver o mesmo destino mais específico, o Google Cloud usará o seguinte processo para selecionar uma rota entre os candidatos de rota. Os candidatos de rota são as rotas personalizadas estáticas, dinâmicas e de peering que têm o mesmo destino mais específico.

    1. Se sua rede VPC estiver conectada a redes semelhantes, o Google Cloud eliminará todos os candidatos de rota, exceto aqueles de uma única rede VPC.

      • Se um ou mais candidatos de rota existirem na sua rede VPC local, o Google Cloud desconsidera todos os candidatos de rota de redes semelhantes.

      • Se nenhum dos candidatos de rota existir na rede VPC local, mas existir em várias redes de mesmo peering, o Google Cloud desconsidera todos os candidatos de rota, exceto aqueles definidos em uma das redes em peering. O Google Cloud usa um algoritmo interno para selecionar a rede de mesmo nível, e esse algoritmo não considera a prioridade da rota nesse momento no processo. Se você fizer peering com uma nova rede ou se desconectar de uma rede com peering existente, isso poderá alterar a rede VPC escolhida pelo Google Cloud.

    2. O Google Cloud elimina todos os candidatos a rota, exceto aqueles que têm a prioridade mais alta. Se isso resultar em uma única rota restante, o Google Cloud enviará o pacote para o próximo salto.

    3. Se vários candidatos de rota tiverem a mesma prioridade mais alta, o Google Cloud continuará o processo de eliminação usando o próximo salto e o tipo da rota. Se isso resultar em uma única rota restante, o Google Cloud enviará o pacote para o próximo salto.

      1. É melhor usar rotas estáticas personalizadas com próximos saltos: instância do próximo salto, IP do próximo salto ou túnel da VPN do próximo salto. Todos os outros candidatos de rota serão eliminados se existir um candidato de rota usando esse tipo de próximo salto.

      2. As rotas dinâmicas personalizadas são a segunda opção mais recomendada.

      3. As rotas estáticas personalizadas com próximos saltos que têm como base o balanceador de carga TCP/UDP interno são a melhor opção.

      4. As rotas estáticas personalizadas que usam o próximo salto do gateway de Internet padrão são as menos preferidas.

    4. Se mais de uma rota dos candidatos de rota permanecer, todas elas estarão na mesma rede VPC, terão a mesma prioridade mais alta e serão do mesmo tipo de rota ou usarão o mesmo tipo de próximo salto. O Google Cloud distribui o tráfego da seguinte maneira:

      • Se o próximo salto não for um balanceador de carga TCP/UDP interno, o Google Cloud distribuirá pacotes entre os próximos saltos dos candidatos de rota usando um hash de cinco tuplas para afinidade, implementando vários caminhos de custo igual (ECMP, na sigla em inglês). Os cálculos de hash são feitos para todos os pacotes no momento em que são enviados, com base no número de candidatos de rota nessa etapa. Se o número de candidatos de rota for alterado, o hash poderá direcionar um pacote com o mesmo hash de cinco tuplas para outro próximo salto.

      • Se o próximo salto for um balanceador de carga TCP/UDP interno, o Google Cloud usará um algoritmo interno para selecionar um único balanceador de carga de próximo salto e irá ignorar os próximos saltos, mesmo que estejam associados a rotas com a mesma prioridade. Para mais detalhes sobre essa situação, consulte Considerações específicas para os próximos saltos do balanceador de carga TCP/UDP interno.

  4. Se nenhum destino aplicável for encontrado, o Google Cloud descartará o pacote, respondendo com um erro de destino do ICMP ou rede inacessível.

Caminhos de retorno especiais

As redes VPC têm rotas especiais para determinados serviços. Essas rotas são definidas fora da sua rede VPC, na rede de produção do Google. Elas não aparecem na tabela de roteamento da sua rede VPC. Não é possível removê-las ou substituí-las, mesmo se você excluir ou substituir uma rota padrão na sua rede VPC. No entanto, é possível controlar o tráfego de e para esses serviços através do uso de regras de firewall.

Caminhos de retorno do balanceador de carga

Se você usa um dos balanceadores de carga do Google Cloud a seguir, o Google Cloud tem rotas especiais para os balanceadores de carga e verificações de integridade associadas, descritas em mais detalhes nas seções a seguir.

Caminhos de retorno para balanceadores de carga HTTP(S), proxy SSL e proxy TCP

Para esses tipos de balanceador de carga, os sistemas Google Front End (GFE) servem como proxies. Quando um cliente envia uma solicitação ao balanceador de carga, um proxy encerra a sessão TCP e abre uma nova com sua VM de back-end. Rotas definidas fora de sua rede VPC facilitam a comunicação dos proxies GFE para suas VMs de back-end e vice-versa.

Para mais informações, consulte as seguintes páginas:

Caminhos de retorno para balanceadores de carga da rede

Quando um cliente na Internet envia uma solicitação TCP ou UDP por meio de um balanceador de carga de rede para uma VM de back-end, o Google Cloud usa rotas definidas fora de sua rede VPC para facilitar a comunicação entre o cliente e sua VM de back-end.

Para mais informações, consulte Balanceamento de carga de rede.

Verificações de integridade para todos os tipos de balanceador de carga

Os pacotes enviados dos sistemas de sondagem de verificação de integridade do Google Cloud têm origens conforme descrito em Intervalos de IP de sondagem e regras de firewall. Rotas que facilitam a comunicação entre os sistemas de sondagem de verificação de integridade do Google Cloud e suas VMs de back-end existem fora da rede VPC e não podem ser removidas. No entanto, sua rede VPC precisa ter a entrada permitida pelas regras de firewall para permitir o tráfego desses sistemas.

IAP

Uma rota para 35.235.240.0/20 está incluída para ser compatível com o encaminhamento de TCP com IAP. A rede de produção do Google não aceita rotas para 35.235.240.0/20 de outras fontes na Internet.

Cloud DNS

Uma rota para 35.199.192.0/19 é compatível com a conectividade com destinos de encaminhamento que usam roteamento privado ou servidores de nomes alternativos que usam roteamento privado. A rede de produção do Google não aceita rotas para 35.199.192.0/19 de outras fontes na Internet.

Parâmetros da rota estática

Cada rota estática consiste nos seguintes componentes:

  • Nome e descrição. Esses campos identificam a rota. O nome é obrigatório, mas a descrição é opcional. Cada rota no seu projeto precisa ter um nome exclusivo.

  • Rede. Cada rota precisa estar associada a exatamente uma rede VPC.

  • Intervalo de destino. O intervalo de destino é um único bloco CIDR IPv4 que contém os endereços IP dos sistemas que recebem pacotes de entrada. Os destinos precisam ser expressos na notação CIDR. Os destinos não podem corresponder exatamente a um intervalo de endereços IP de sub-rede e nem podem estar dentro de um intervalo de endereços IP de sub-rede (não podem ter uma máscara de sub-rede mais longa). No entanto, o destino de uma rota estática pode conter (pode ter uma máscara de sub-rede menor que) um intervalo de IPs de uma sub-rede. Por exemplo, se você tem um intervalo de IPs de sub-rede de 10.10.10.0/24, pode ter uma rota estática com um destino de 10.10.10.0/23. Se o endereço IP de destino de um pacote não couber no destino da rota de sub-rede, o pacote será enviado para o próximo salto da rota estática. O maior destino possível é 0.0.0.0/0.

  • Prioridade. Se várias rotas têm destinos idênticos, a prioridade é usada para determinar qual rota deve ser usada. Números menores indicam prioridades maiores. Por exemplo, uma rota de valor 100 tem prioridade mais alta que uma de valor 200. Uma prioridade de rota mais alta indica o menor número inteiro não negativo possível. "Zero" tem a prioridade mais alta porque ele é o menor número inteiro não negativo possível.

  • Próximo salto. As rotas estáticas podem ter próximos saltos que apontam para o gateway de Internet padrão, uma instância do Google Cloud ou um túnel do Cloud VPN. Para mais informações, consulte Próximos saltos da rota estática.

  • Tags. É possível especificar uma lista de tags de rede para que a rota se aplique somente a instâncias que tenham pelo menos uma das tags listadas. Se você não especificar tags, o Google Cloud aplicará a rota a todas as instâncias na rede. Os balanceadores de carga TCP/UDP internos do próximo salto não são compatíveis com tags de rede.

Próximos saltos da rota estática

Veja a seguir os próximos saltos válidos para rotas estáticas. Para mais informações sobre cada tipo, consulte a documentação de referência gcloud.

  • Gateway do próximo salto (next-hop-gateway). É possível especificar um gateway de Internet padrão para definir um caminho para endereços IP externos.

  • Instância do próximo de salto (next-hop-instance). É possível direcionar o tráfego para uma instância existente no Google Cloud especificando seu nome e zona. O tráfego é direcionado para o endereço IP interno primário da interface de rede da VM na rede VPC em que você define a rota.

    • Alterações no endereço IP interno primário referente à interface de rede da instância de VM na rede VPC fazem com que o Google Cloud atualize a tabela de roteamento da rede automaticamente para que o tráfego continue a ser enviado para a VM em seu novo endereço IP.

    • Se a VM for substituída por uma nova com o mesmo nome na mesma zona, o Google Cloud atualizará a tabela de roteamento da rede VPC automaticamente para que o tráfego seja direcionado à VM substituta.

    • O Google Cloud confirma que uma VM de próximo salto existe e faz isso somente quando você cria a rota. Ele não valida a capacidade da VM de processar ou encaminhar pacotes. Se a VM for excluída posteriormente, mas não substituída, a rota ainda será aplicada, o que pode resultar em pacotes descartados.

  • Balanceador de carga TCP/UDP interno do próximo salto (next-hop-ilb). Para balanceamento de carga TCP/UDP interno, use o endereço IP do balanceador de carga como um próximo salto que distribui o tráfego entre instâncias de back-end íntegras. Por exemplo, use uma rota estática personalizada cujo próximo salto é um balanceador de carga TCP/UDP interno para distribuir o tráfego entre as VMs de back-end.

  • IP do próximo salto (next-hop-address). É possível fornecer um endereço IP interno primário atribuído a uma interface de VM do Google Cloud como um próximo salto.

    • Ao utilizar next-hop-address, o Google Cloud envia tráfego para qualquer instância de VM atribuída a esse endereço IP. Se você substituir uma instância de VM por outra que use o mesmo endereço IP interno primário, o tráfego será transferido para a substituição, mesmo que tenha um nome diferente. Para definir um próximo salto por nome de VM, use Próxima instância de salto.

    • O Google Cloud só verifica se o endereço IP é um membro válido do intervalo de IP primário ou secundário de uma sub-rede quando você cria a rota. Ele não valida a existência de uma instância no endereço IP do próximo salto. Se o endereço IP do próximo salto não for atribuído a nenhuma instância, a rota ainda será aplicada, o que pode resultar em pacotes descartados. Para mais informações, consulte Considerações para a instância e o próximo salto do balanceador de carga.

    • Não é possível especificar um endereço IP arbitrário no próximo salto: não são permitidos endereços fora do intervalo de endereços IP de uma sub-rede na sua rede VPC.

  • Túnel da VPN do próximo salto (next-hop-vpn-tunnel). Para túneis do Cloud VPN que usam roteamento baseado em políticas e VPNs baseadas em rotas, direcione o tráfego para o túnel VPN criando rotas que incluam saltos que se refiram ao túnel por nome e região. O Google Cloud ignora rotas cujos próximos saltos são túneis do Cloud VPN que estão inativos. Para ver mais exemplos sobre como as rotas e os túneis do Cloud VPN interagem, consulte os exemplos de rotas do Cloud VPN.

Considerações sobre a instância e os próximos saltos do balanceador de carga

O roteamento baseado em instância refere-se a uma rota estática com um próximo salto que é uma instância de VM (next-hop-instance ou next-hop-address).

O balanceador de carga TCP/UDP interno como um próximo salto se refere a uma rota estática com um próximo salto que é um balanceador de carga TCP/UDP interno (next-hop-ilb).

Ao configurar o roteamento com base em instância ou um balanceador de carga TCP/UDP interno como um próximo salto, considere as seguintes diretrizes:

  • É preciso configurar as VMs de back-end ou a Instância de próximo salto para encaminhar pacotes de qualquer endereço IP de origem. Para configurar o encaminhamento, ative o encaminhamento de IP (can-ip-forward) por VM quando criar a VM. Para VMs criadas automaticamente como parte de um grupo gerenciado de instâncias, ative o encaminhamento de IP no modelo de instância usado pelo grupo de instâncias. Você deve fazer esta alteração de configuração além de qualquer configuração de sistema operacional necessária para rotear pacotes.

  • O software em execução na VM de back-end ou na Instância de próxima salto deve ser configurado adequadamente. Por exemplo, VMs de dispositivos de terceiros que agem como roteadores ou firewalls devem ser configuradas de acordo com as instruções do fabricante.

  • As VMs de back-end ou a Instância de próximo salto devem ter regras de firewall apropriadas. Você deve configurar regras de firewall que se aplicam aos pacotes que estão sendo roteados. Lembre-se:

    • As regras de entrada do firewall aplicáveis a instâncias que executam funções de roteamento devem incluir os endereços IP de origens de pacotes roteados. A regra de entrada de negação implícita bloqueia todos os pacotes de entrada. Portanto, você deve ao menos criar regras personalizadas de firewall com permissão de entrada.
    • As regras de saída do firewall aplicáveis a instâncias que executam funções de roteamento devem incluir os endereços IP de destinos de pacotes roteados. A regra de saída de permissão implícita permite isso, a menos que você tenha criado uma regra de proibição de saída específica para substituí-la.
    • Leve em consideração se a VM de back-end ou a Próxima instância de salto está realizando a Conversão de endereços de rede (NAT) ao criar suas regras de firewall.

    Para mais informações, consulte Regras de firewall implícitas.

Considerações específicas para as próximas instâncias de salto

  • Quando você usa uma instância como próximo salto (next-hop-instance ou next-hop-address), lembre-se de que a instância é um recurso de zona. Selecionar uma zona significa que você selecionou uma região. O Google Cloud não considera a distância regional para rotas que usam uma Próxima instância de salto, por isso é possível criar uma rota que envia tráfego para um próximo salto em uma região diferente. Isso adiciona custos de saída e aumenta a latência da rede.

  • O Google Cloud realiza uma das seguintes validações básicas somente quando você cria a rota:

    • Se você especificar next-hop-instance, a instância já deverá existir.
    • Se você especificar next-hop-address, o endereço IP precisa estar no intervalo de IP primário ou secundário da sub-rede existente.

    Por exemplo, se você remover uma instância ou excluir uma sub-rede, o Google Cloud ainda considerará qualquer rota que a use como um próximo salto quando avaliar as rotas aplicáveis. Isso pode fazer com que alguns ou todos os pacotes de um determinado destino sejam descartados, dependendo das outras rotas na sua rede.

  • Se houver falha no software em uma instância de VM (como o sistema operacional da VM ou o processo da VM que roteia pacotes), os pacotes destinados a essa instância serão descartados. Para aumentar a confiabilidade, use um balanceador de carga TCP/UDP interno como um próximo salto. Um balanceador de carga TCP/UDP interno requer uma verificação de integridade configurada, e esta verificação de integridade determina como as novas conexões são roteadas.

  • Desativar uma interface de rede configurando o sistema operacional convidado da instância não faz com que o Google Cloud pare de considerar a interface como o próximo salto de uma rota.

  • Se você quiser rotear o tráfego para uma instância em um projeto de serviço de VPC compartilhada, use next-hop-address. next-hop-instance não é compatível.

Considerações específicas sobre os próximos saltos do balanceador de carga TCP/UDP interno

  • Quando nenhum back-end é íntegro. Quando todos os back-ends de um balanceador de carga TCP/UDP interno falharem nas verificações de integridade, as rotas que usam esse próximo salto ainda estarão em vigor. Os pacotes processados pela rota são enviados para um dos back-ends do balanceador de carga do próximo salto, de acordo com a distribuição de tráfego.

  • Não é possível usar regras de encaminhamento que usam um endereço IP interno comum (--purpose=SHARED_LOADBALANCER_VIP). O balanceador de carga TCP/UDP interno de próximo salto e as regras de encaminhamento do balanceador de carga TCP/UDP interno com um endereço IP comum são recursos mutuamente exclusivos. Um balanceador de carga TCP/UDP interno de próximo salto precisa usar um endereço IP exclusivo da regra de encaminhamento do balanceador de carga para que apenas um serviço de back-end (um balanceador de carga) seja referenciado sem ambiguidade. É possível que as regras de encaminhamento que usam um endereço IP interno comum se refiram a diferentes serviços de back-end (diferentes balanceadores de carga TCP/UDP internos).

  • Mesmo destino e vários balanceadores de carga TCP/UDP internos de próximo salto. Se você criar duas ou mais rotas estáticas personalizadas com o mesmo destino usando os próximos saltos do balanceador de carga TCP/UDP interno, o Google Cloud nunca distribuirá o tráfego entre os próximos saltos do balanceador de carga usando ECMP. Se as rotas tiverem prioridades exclusivas, o Google Cloud usará o balanceador de carga TCP/UDP interno de próximo salto na rota com a prioridade mais alta. Se as rotas tiverem as mesmas prioridades, o Google Cloud ainda selecionará apenas um balanceador de carga TCP/UDP interno de próximo salto. Nesse caso, conforme ilustrado no diagrama abaixo, o Google Cloud usa um algoritmo interno determinístico para selecionar uma única regra de encaminhamento de próximo salto (forwarding-rule-a), ignorando outras rotas com a mesma prioridade.

    Mesmo destino, próximos saltos do balanceador de carga TCP/UDP interno diferentes
    Mesmo destino, próximos saltos do balanceador de carga TCP/UDP interno diferentes
  • Vários destinos e o mesmo balanceador de carga TCP/UDP interno do próximo salto.

    Com tags de instância:

    Se você usa tags de instância (também chamadas de tags de rede), pode usar o mesmo balanceador de carga TCP/UDP interno do próximo salto para várias rotas estáticas personalizadas com o mesmo destino e prioridade.

    Sem tags: sem tags de rede, não é possível criar várias rotas estáticas personalizadas com a mesma combinação de destino, prioridade e próximo salto do balanceador de carga TCP/UDP interno. Por exemplo, route-x, route-y e route-z podem ser criados, mas route-x-copy não pode ser criado.

    Exemplos de rotas sem tag usando um próximo salto do balanceador de carga TCP/UDP interno comum
    Exemplos de rotas sem tag usando um próximo salto do balanceador de carga TCP/UDP interno comum
  • Tags da instância.

    É possível especificar tags de instância (também chamadas de tags de rede) para que a rota de próximo salto se aplique apenas a instâncias de cliente que foram configuradas com a tag. Isso permite selecionar quais instâncias de clientes serão preenchidas com qual rota de próximo salto com tag e a qual conjunto de dispositivos rotear o seu tráfego.

    Você não precisa separar as diferentes instâncias de cliente em redes VPC separadas, cada uma apontando para o balanceador de carga TCP/UDP interno preferido de front-end de um conjunto de dispositivos.

    .
  • Várias rotas para o mesmo prefixo de destino. As tags permitem especificar várias rotas para o mesmo destino com diferentes balanceadores de carga internos como próximos saltos. É possível usar tags ou prioridades diferentes para essas mesmas rotas de destino.

Considerações sobre os próximos saltos do túnel da VPN clássica

O Google Cloud não considera a distância regional para rotas que usam um túnel de VPN clássica do próximo salto. O envio de tráfego para um túnel de VPN clássica do próximo salto em outra região adiciona custos de saída e aumenta a latência da rede. Como prática recomendada, use túneis de VPN de alta disponibilidade ou túneis VPN clássicos que usem roteamento dinâmico.

A seguir