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 		Encaminha pacotes a um próximo salto de rota estática Para ver detalhes sobre cada próxima rota de salto estático, consulte as considerações para:
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 com base nas rotas aprendidas dos 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:
  • Rotas estáticas em uma rede de peering que usam tags de rede nunca são importadas como rotas personalizadas de peering.
  • Rotas estáticas em uma rede de peering que usam o próximo salto de gateway de Internet padrão nunca são importadas como rotas personalizadas de peering.
  • As rotas estáticas em uma rede de peering que usam próximos saltos do balanceador de carga TCP/UDP interno podem se aplicar a apenas uma região ou a todas as regiões, dependendo do acesso global estar ativado. Para mais detalhes, consulte Considerações sobre os próximos saltos do balanceador de carga TCP/UDP interno.
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 com base em políticas
Rota com base em políticas
Corresponde ao tráfego por uma combinação de protocolo, intervalo de IPs de origem e intervalo de IPs de destino. 		Um balanceador de carga TCP/UDP interno

As rotas com base na política são avaliadas antes de outras rotas. Rotas com base na política podem ser aplicadas a todas as VMs na rede, a determinadas VMs selecionadas por tag de rede ou ao tráfego que entra na rede VPC por meio de anexos da VLAN que você identifica.

Rotas com base na política não são trocadas por peering de rede VPC.

Rotas padrão geradas pelo sistema

Ao criar uma rede VPC, ela inclui uma rota padrão de IPv4 gerada pelo sistema (0.0.0.0/0). Ao criar uma sub-rede de pilha dupla com um intervalo de endereços IPv6 externo em uma rede VPC, uma rota padrão IPv6 gerada pelo sistema (::/0) é adicionada a essa rede, se a rota ainda não existir. As rotas padrão têm as seguintes finalidades:

O Google Cloud só 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:

  • Somente IPv4: 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.

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 IPv4 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. Se a sub-rede tiver um intervalo IPv6, há uma rota de sub-rede correspondente ao intervalo de endereços IPv6. Para mais informações sobre intervalos de IP de sub-rede, consulte Sub-redes.

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.

Interações com rotas estáticas personalizadas

As rotas de sub-rede local e as rotas de sub-rede de peering importadas interagem com rotas estáticas personalizadas das seguintes maneiras:

  • O Google Cloud não permite que você crie uma rota estática personalizada que tenha um destino igual ou mais estreito que qualquer rota de sub-rede ou rota de sub-rede de peering. Por exemplo, se houver uma rota de sub-rede local ou rota de sub-rede de peering para o destino 10.70.1.0/24, não será possível criar uma nova rota estática personalizada para 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 ou qualquer outro destino que caiba em 10.70.1.0/24.

  • Por outro lado, o Google Cloud não permite que você crie uma nova sub-rede ou rota de sub-rede de peering com destino que corresponda exatamente ou seja mais ampla que (que contenha) uma rota estática personalizada atual. Por exemplo, se sua rede VPC tiver uma rota estática personalizada para o destino 10.70.1.128/25, o Google Cloud proibirá a criação de qualquer sub-rede ou peering de rota de sub-rede com um intervalo de endereços IP de sub-redes primárias ou secundárias de 10.70.1.128/25, 10.70.1.0/24 ou qualquer outro intervalo que contenha todos os endereços IP em 10.70.1.128/25.

Interações com rotas dinâmicas personalizadas

As rotas de sub-rede local e as rotas de sub-rede de peering importadas interagem com Cloud Routers das seguintes maneiras:

  • Quando os Cloud Routers aprendem um prefixo que corresponde exatamente ao destino de uma sub-rede ou rota de sub-rede de peering atual, o Google Cloud não cria nenhuma rota dinâmica personalizada para o prefixo conflitante. Por exemplo, quando existe uma sub-rede ou rota de sub-rede de peering com destino 10.70.1.0/24, se os Cloud Routers na rede VPC receberem o prefixo 10.70.1.0/24 pelo BGP, o Google Cloud usará a sub-rede ou peering de sub-rede e não cria nenhuma rota dinâmica personalizada para 10.70.1.0/24.

    • Quando uma sub-rede ou rota de sub-rede de peering com destino correspondente exatamente a um prefixo aprendido pelos Cloud Routers na rede VPC é criada, o Google Cloud remove a rota dinâmica personalizada para o conflito. para criar espaço para a sub-rede ou a rota de sub-rede de peering.

  • Quando os Cloud Routers aprendem prefixos que se encaixam no destino de uma sub-rede ou rota de sub-rede de peering atual, o Google Cloud não cria nenhuma rota dinâmica personalizada para os prefixos conflitantes. Por exemplo, quando uma sub-rede ou rota de sub-rede de peering com destino 10.70.1.0/24 existe, se os Cloud Routers na rede VPC receberem os prefixos 10.70.1.0/25 e 10.70.1.128/25 pelo BGP, o Google O Cloud usa a sub-rede ou a rota de sub-rede de peering e não cria nenhuma rota dinâmica personalizada para 10.70.1.0/25 e 10.70.1.128/25.

    • Quando uma sub-rede ou rota de sub-rede de peering com destinos contém prefixos aprendizados pelos Cloud Routers na rede VPC é criada, o Google Cloud remove as rotas dinâmicas personalizadas dos prefixos conflitantes em para liberar espaço para a sub-rede ou a rota de sub-rede de peering.

Ciclo de vida das rotas de sub-rede

Rotas de sub-rede são criadas, atualizadas e excluídas quando você cria, modifica ou exclui sub-redes ou os intervalos de endereços IP delas:

  • 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

As rotas dinâmicas são criadas e excluídas automaticamente com base nas rotas aprendidas dos Cloud Routers na rede VPC. Os destinos dessas rotas sempre representam os prefixos IP fora da rede VPC. As rotas aprendidas podem ser aprendidas de um par de protocolo de gateway de borda (BGP, na sigla em inglês). Elas também podem ser rotas aprendidas personalizadas que você criou manualmente.

As rotas dinâmicas são usadas pelo seguinte:

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

Rotas com base na política

Rotas com base na política permitem o roteamento de pacotes para um próximo salto do balanceador de carga TCP/UDP. É possível selecionar o tráfego ao qual a rota se aplica com base em critérios como o endereço IP de origem de um pacote, o endereço IP de destino ou o protocolo. Para mais informações, consulte Rotas com base na política.

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.

  • Os caminhos de retorno especiais se aplicam ao retornar para balanceadores de carga de proxy, sistemas de verificação de integridade e outros serviços do Google. Para mais informações, consulte Caminhos de retorno do balanceador de carga. Essas rotas não são exibidas em nenhuma tabela de rotas.

  • Rotas com base na política podem ser aplicadas a instâncias, anexos da VLAN para o Cloud Interconnect e gateways do Cloud VPN em uma rede VPC. Rotas com base na política só se aplicam se um pacote corresponder aos critérios da rota com base na política.

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

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

Ordem de roteamento

O processo a seguir modela o comportamento de seleção de rota de rede VPC. Começando com o conjunto de rotas aplicáveis (conforme descrito na seção anterior), você pode modelar as decisões de seleção de rota que o Google Cloud toma para um pacote seguindo este processo.

  1. Caminhos de retorno especiais: não são exibidos na tabela de rotas da sua rede VPC. As rotas configuradas em uma rede VPC não se aplicam a pacotes de resposta para determinados balanceadores de carga do Google Cloud, sistemas de verificação de integridade, Identity-Aware Proxy (IAP) e proxies do Cloud DNS. Para mais detalhes, consulte Caminhos de retorno especiais.

    Se um caminho de retorno especial for aplicável, seu modelo de seleção de rota conterá apenas o caminho de retorno especial. Todas as outras rotas são desconsideradas, e a avaliação é interrompida nesta etapa.

  2. Rotas baseadas em políticas: são avaliadas após caminhos de retorno especiais e antes de qualquer outro tipo de rota. Se um pacote corresponder aos critérios para pelo menos uma rota com base na política, o Google Cloud restringirá o modelo de seleção de rota para que o modelo inclua apenas as rotas com base em política que correspondam ao maior número de características de pacotes: o mais específico para o pacote. Por exemplo, uma rota com base na política que corresponde à origem e ao destino de um pacote é selecionada em vez de uma rota com base na política que corresponde apenas ao destino de um pacote.

    O Google Cloud envia pacotes de acordo com modelos de seleção de rota destas maneiras:

    • Se um modelo de seleção de rota tiver sido limitado a uma única rota com base na política, o Google Cloud enviará o pacote ao próximo salto dessa rota.
    • Se um modelo de seleção de rota contiver duas ou mais rotas com base na política, o Google Cloud distribuirá o tráfego desta maneira:
      • Se as rotas com base na política tiverem prioridades exclusivas, o Google Cloud usará o balanceador de carga TCP/UDP interno de próximo salto da rota com base na política 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. O Google Cloud usa um algoritmo interno determinístico para selecionar um único balanceador de carga de próximo salto, ignorando outras rotas com base na política com a mesma prioridade.

  3. Destino mais específico: o Google Cloud determina qual das rotas aplicáveis tem o destino mais específico que contém o endereço IP de destino do pacote. O Google Cloud desconsidera todas as outras rotas com destinos menos específicos. Por exemplo, 10.240.1.0/24 é um destino mais específico que 10.240.0.0/16. O destino mais específico pode ser qualquer tipo de trajeto. No entanto, as rotas de sub-rede, as rotas de sub-rede com peering e os caminhos de retorno especiais são as mais específicas por definição.

    Após essa etapa, seu modelo de seleção de rota não conterá caminhos de retorno especiais ou rotas com base na política. Incluirá apenas as rotas com os destinos mais específicos.

  4. Próximos saltos em uma única rede VPC: esta etapa só é aplicável se a rede VPC que tem o comportamento de rota sendo modelado estiver conectada a uma ou mais redes VPC usando o peering de rede VPC. Com o peering de rede VPC, é possível que haja rotas personalizadas com destinos idênticos em mais de uma das redes no grupo de peering. O requisito modelado nesta etapa é que o Google Cloud selecione os próximos saltos que estiverem todos em uma única rede VPC.

    • Se uma ou mais das rotas em seu modelo de rota tiverem próximos saltos dentro da rede VPC que você está modelando, desconsidere todas as rotas que têm próximos saltos em redes de peering. Nessa situação, o Google Cloud só usa os próximos saltos na rede VPC local, mesmo que os próximos saltos para o mesmo destino existam em uma ou mais redes VPC com peering.

    • Se nenhuma das rotas no seu modelo de rota tiver próximos saltos dentro da rede VPC que você está modelando e todos os próximos saltos existirem em várias redes de peering, o Google Cloud usa um algoritmo interno para selecionar uma única rede com os próximos saltos para os destinos mais específicos. A prioridade da rota não é considerada neste momento. Além disso, se a rede VPC fizer peering com uma nova rede VPC ou se ela se desconectar de uma rede VPC existente, a rede VPC selecionada para os próximos saltos pode mudar.

    Após esta etapa, o modelo de seleção de rota contém apenas as rotas com os destinos mais específicos, e os próximos saltos para essas rotas estão todos em uma única rede VPC.

  5. Desconsidere rotas estáticas personalizadas cujos próximos saltos estão inativos: esta etapa modela duas situações em que o Google Cloud desconsidera os próximos saltos que considera inativos. Esta etapa se aplica somente a rotas estáticas personalizadas. Em vez disso, as rotas dinâmicas personalizadas são adicionadas e removidas automaticamente usando anúncios do BGP.

    • O Google Cloud ignorará todas as instâncias de VM do próximo salto (next-hop-instance ou next-hop-address) se a VM do próximo salto tiver sido interrompida ou excluída. Para mais detalhes, consulte Comportamento quando as instâncias forem interrompidas ou excluídas na seção Considerações sobre instâncias do próximo salto. Se o modelo de rota contiver rotas estáticas com VMs de próximo salto que sejam interrompidas ou excluídas, remova essas rotas do modelo.

    • O Google Cloud ignorará todas as rotas estáticas personalizadas que usam um túnel de VPN clássica do próximo salto se o túnel não tiver uma associação de segurança (SA, na sigla em inglês) da Fase 1 (IKE). Para mais detalhes, consulte Ordem das rotas na documentação da VPN clássica. Se o modelo de rota tiver rotas estáticas com próximos saltos que são túneis de VPN clássica sem SAs do IKE estabelecidas, remova-as do modelo.

  6. Desconsidere rotas de baixa prioridade: esta etapa modela como o Google Cloud descarta todas as rotas, exceto aquelas com a prioridade mais alta.

    Após essa etapa, o modelo de seleção de rota pode estar vazio ou conter uma ou mais rotas. Se o modelo contém rotas, todas as rotas têm todas estas características:

    • Destinos idênticos e mais específicos
    • Todos os próximos saltos em uma rede VPC: a rede VPC local ou uma rede VPC com peering único
    • Próximos saltos que não são conhecidos por estarem inativos
    • Prioridades idênticas e mais altas

  7. Selecione apenas a categoria de preferência mais favorável: o Google Cloud evita o roteamento de ECMP entre diferentes tipos de próximos saltos. Você pode modelar esse comportamento considerando o sistema de categorias de preferência descrito na tabela a seguir. Esta etapa refina seu modelo de rota para que ele contenha somente rotas que sejam do mesmo tipo de rota ou combinação de tipo de rota e do próximo salto.

    Categoria de preferência Combinação de categoria e próximo salto
    Primeira opção (maior preferência) Rotas estáticas personalizadas com uma instância do próximo salto em execução (next-hop-instance ou next-hop-address) ou túnel estabelecido de VPN clássica do próximo salto
    Segunda escolha Rotas dinâmicas personalizadas aprendidas de qualquer sessão do BGP de qualquer Cloud Router
    Terceira escolha Uma única rota estática personalizada com um próximo salto de balanceador de carga TCP/UDP interno
    O Google Cloud usa um algoritmo interno para selecionar um único balanceador de carga TCP/UDP interno do próximo salto ignorando os próximos saltos do balanceador de carga TCP/UDP interno com a mesma prioridade. Para mais detalhes, consulte "Mesmo destino e vários balanceadores de carga TCP/UDP internos do próximo salto" na seção Considerações para os próximos saltos do balanceador de carga TCP/UDP interno.
    Quarta opção Uma rota estática personalizada usando o próximo salto default-internet-gateway

    No final desta etapa, pode não haver rotas, uma ou duas ou mais rotas no modelo.

  8. Enviar ou soltar o pacote: o que acontece depende do número de rotas que permanecem no modelo de rota:

    • Se o modelo de rota estiver vazio, o pacote será descartado com um erro de destino do ICMP ou de rede inacessível. O Google Cloud nunca usa uma rota menos específica, que pode ter um próximo salto funcional.

    • Se o modelo de rota contiver uma única rota, o Google Cloud enviará o pacote para o próximo salto. Para os próximos saltos da VM, o Google Cloud não valida que o próximo salto da VM pode processar pacotes. Para mais detalhes, consulte Considerações comuns sobre os próximos saltos do balanceador de carga TCP/UDP interno e da instância. Se a única rota for de sub-rede ou de peering e não houver recurso do Google Cloud no endereço IP de destino do pacote, o pacote será descartado.

    • Se o modelo de rota tiver duas ou mais rotas, elas compartilham o mesmo destino mais específico, estão localizadas em uma única rede VPC, têm os próximos saltos que não são conhecidos por estarem inativos, têm a mesmo prioridade mais alta e pertencem a um tipo de rota e a uma combinação de próximo salto (categoria de preferência). O Google Cloud distribui pacotes entre os próximos saltos que implementam vários caminhos de custo igual (ECMP, na sigla em inglês) usando um algoritmo de hash. Os cálculos de hash são feitos para cada pacote no momento em que ele é enviado, com base no número atual de próximos saltos. O Google Cloud usará um hash de cinco tuplas se o pacote contiver informações de porta. Caso contrário, ele usa um hash de três tuplas. Se o modelo de rota mudar conforme os pacotes subsequentes são enviados, o Google Cloud pode direcionar esses pacotes para um próximo salto diferente, mesmo que o hash seja o mesmo.

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) externos, de proxy SSL externo e de proxy TCP externo

    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:

  • Caminho de retorno para balanceadores de carga de 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 Visão geral do balanceador 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.

Acesso VPC sem servidor

Uma rota para 35.199.224.0/19 é oferece suporte ao Acesso VPC sem servidor. A rede de produção do Google não aceita rotas para 35.199.224.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.

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.

Considerações comuns aos próximos saltos do balanceador de carga TCP/UDP interno e da instância

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óximo 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.

  • Do ponto de vista do destino de um pacote, a região de origem do pacote é a região que contém a VM de back-end ou a instância do próximo salto. Por exemplo, pacotes processados por VMs de back-end ou instâncias de próximo salto em us-west1 podem ser enviados para destinos que só podem ser acessados em us-west1 mesmo que a fonte do pacote original esteja fora de us-west1. Veja alguns exemplos de recursos que só podem ser acessados se os recursos de origem e de destino estiverem na mesma região:

    • Balanceadores de carga TCP/UDP internos com acesso global desativado
    • Balanceadores de carga HTTP(S) internos regionais
    • Balanceadores de carga do proxy TCP regionais internos

Considerações sobre instâncias do próximo salto

  • Próximo salto por nome de instância (next-hop-instance): se a rota e a instância do próximo salto estiverem no mesmo projeto, você poderá especificar uma instância de próximo salto usando o nome e a zona dela. Antes de criar a rota, o Google Cloud exige que uma instância de próximo salto precise existir e atender a todos estes critérios:

    • O nome da instância precisa corresponder ao nome da VM do próximo salto da rota.
    • A zona da instância precisa corresponder à zona do próximo salto da rota.
    • A instância precisa ter uma interface de rede na rede VPC da rota.

    O Google Cloud atualiza automaticamente uma rota em que o próximo salto é especificado por next-hop-instance nestas situações:

    • Quando o endereço IPv4 da instância do próximo salto mudar
    • Quando você substitui a instância do próximo salto, desde que a instância de substituição atenda aos mesmos critérios da instância que foi substituída.

  • Endereço IP interno da instância do próximo salto (next-hop-address): é possível especificar uma instância do próximo salto usando um endereço IPv4 interno associado a uma interface de rede na rede VPC da rota. Antes de poder criar a rota, o Google Cloud exige que uma instância do próximo salto precise existir e atender a todos os seguintes critérios:

    • A instância precisa ter pelo menos uma interface de rede na rede VPC da rota.
    • A interface de rede da instância precisa ter um endereço IPv4 interno que corresponda ao endereço do próximo salto da rota. O endereço IPv4 interno pode ser o endereço IPv4 principal da interface de rede ou um endereço IPv4 de um intervalo de IP de alias na interface de rede.

    O Google Cloud atualiza automaticamente uma rota que tem o próximo salto especificado por next-hop-address quando o endereço IPv4 é movido para uma VM diferente, desde que a VM de substituição atenda aos critérios acima.

  • Próximos saltos em um projeto de serviço de VPC compartilhada: se você precisar criar uma rota em uma rede VPC compartilhada cuja instância de próximo salto esteja localizada em um projeto de serviço, especifique o próximo salto usando next-hop-address. Não é possível especificar o próximo salto usando next-hop-instance.

  • Custos e latência entre regiões: quando você usa uma VM como próximo salto, o próximo salto está localizado em uma zona de uma região. A rota que usa o próximo salto está disponível para todas as instâncias na mesma rede VPC ou para selecionar instâncias com uma tag de rede correspondente. O Google Cloud não considera a distância regional para rotas que usam uma instância como próximo salto. Portanto, é possível criar uma rota que envia tráfego para uma VM de próximo salto em uma região diferente. O envio de pacotes de uma região para outra adiciona custos de saída e introduz a latência de rede.

  • Sem verificação de integridade, sem validação de configuração: o Google Cloud nunca verifica se uma próxima instância de próximo salto atende a todos os requisitos descritos na seção Considerações comuns sobre os próximos saltos do balanceador de carga TCP/UDP interno e da instância. Desativar a interface de rede da VM configurando o sistema operacional convidado da instância não faz com que o Google Cloud desconsidere a instância do próximo salto. Para aumentar a confiabilidade, use um balanceador de carga TCP/UDP interno como um próximo salto.

  • Sem hash simétrico ao conectar duas redes VPC: o Google Cloud não oferece hash simétrico ao usar duas ou mais VMs de próximo salto com várias interfaces de rede em uma configuração que atenda todos os seguintes critérios:

    • As VMs têm uma interface de rede em uma rede VPC e outra interface em uma segunda rede VPC.
    • Em cada rede VPC, existe um conjunto de pelo menos duas rotas estáticas personalizadas para o mesmo destino, usando a mesma prioridade, em que cada rota no conjunto faz referência a uma VM de próximo salto única.

    Se você usar duas ou mais VMs com várias interfaces para conectar redes VPC e exigir que a mesma VM processe pacotes para uma determinada conexão nas duas direções, use um balanceador de carga TCP/UDP interno do próximo salto. O balanceador de carga TCP/UDP interno do próximo salto é necessário porque ele oferece hash simétrico. Para detalhes sobre hash simétrico, consulte a Documentação de hash simétrico nos balanceadores de carga TCP/UDP internos como próximos saltos.

  • Comportamento quando as instâncias são interrompidas ou excluídas: o Google Cloud não impede que você pare ou exclua uma instância de próximo salto, independentemente da maneira como você a especificou (usando next-hop-instance ou next-hop-address). O Google Cloud descarta todas as instâncias interrompidas ou excluídas na etapa de categorização de preferência da ordem de roteamento. Os exemplos a seguir esclarecem esse comportamento:

    • Suponha que você tenha três rotas estáticas personalizadas para o destino 192.168.168.0/24: uma com prioridade 10, em que VM do próximo salto está interrompida, e uma segunda com a prioridade 20, em que a VM do próximo salto está em execução, e uma terceira com prioridade 30, em que a VM do próximo salto está em execução. O Google Cloud envia pacotes para a segunda VM, mesmo que a rota tenha uma prioridade menor do que a rota com a VM de próximo salto interrompida. Se a VM com prioridade 10 for reiniciada, o Google Cloud usará essa VM como o próximo salto.

    • Suponha que você tenha três rotas estáticas personalizadas conforme descrito anteriormente, mas todas as VMs do próximo salto estejam interrompidas ou excluídas. Os pacotes são descartados mesmo que haja rotas menos específicas com próximos saltos em funcionamento porque o Google Cloud considera a especificidade do destino antes de determinar se uma VM de próximo salto está em execução.

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

  • Efeito do acesso global. As rotas estáticas personalizadas que usam os próximos saltos do balanceador de carga TCP/UDP interno são programadas em todas as regiões. O uso do próximo salto depende da configuração de acesso global do balanceador de carga. Com o acesso global ativado, o próximo salto do balanceador de carga pode ser acessado em todas as regiões da rede VPC. Com o acesso global desativado, o próximo salto do balanceador de carga só poderá ser acessado na mesma região que o balanceador de carga. Com o acesso global desativado, os pacotes enviados de outra região para uma rota usando um próximo salto do balanceador de carga TCP/UDP interno são descartados.

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

  • As regras de encaminhamento usadas em outras configurações não são compatíveis. A regra de encaminhamento precisa fazer parte de uma configuração do balanceador de carga TCP/UDP interno. Se a regra de encaminhamento for usada em um tipo de balanceador de carga diferente ou outro recurso, como um endpoint do Private Service Connect, ela não será aceita como próximo salto.

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

    O Google Cloud seleciona um único próximo salto quando rotas estáticas com diferentes saltos internos do balanceador de carga TCP/UDP têm a mesma prioridade e destino.

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

    Rotas estáticas que não têm tags de instância não podem ser criadas com o mesmo destino, prioridade e próximo salto do balanceador de carga TCP/UDP interno.

  • 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

  • Custos e latência de região para região: 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 introduz a latência de rede. Como prática recomendada, use um túnel de VPN de alta disponibilidade com roteamento dinâmico porque essa configuração considera a distância regional.

  • Comportamento quando os túneis de VPN clássica estão inativos: as rotas estáticas personalizadas com próximos saltos que são túneis de VPN clássica não são removidas automaticamente quando os túneis de VPN clássica estão inativos. Para ver mais detalhes sobre o que acontece quando os túneis estão inativos, consulte Quando os túneis estão inativos na documentação da VPN clássica.

A seguir