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

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.

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 o Cloud Router aprende prefixos que correspondem exatamente ao destino de uma rota de sub-rede ou peering de sub-rede, o Google Cloud ignora essas rotas dinâmicas personalizadas. Por exemplo, se houver uma sub-rede ou rota de sub-rede de peering para o destino 10.70.1.0/24 e um ou mais Cloud Routers na rede VPC receberem o prefixo 10.70.1.0/24 por meio do BGP, o Google Cloud usará a sub-rede ou a rota de sub-rede de peering e ignora a rota dinâmica personalizada conflitante.

  • Quando o Cloud Router aprende prefixos que se encaixam no destino de uma sub-rede ou rota de sub-rede de peering, o Google Cloud ignora essas rotas dinâmicas personalizadas. Por exemplo, se houver uma sub-rede ou rota de sub-rede de peering para o destino 10.70.1.0/24 e um ou mais Cloud Routers na rede VPC receberem o prefixo 10.70.1.0/25 via BGP, o Google Cloud usará a sub-rede ou rota de sub-rede de peering e ignora a rota dinâmica personalizada conflitante.

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

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.

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

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

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. Destino mais específico: o Google Cloud determina primeiro quais das rotas aplicáveis têm 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.

  2. Após esta etapa, seu modelo de seleção de rota contém apenas as rotas com os destinos mais específicos.

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

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

  5. 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
  6. 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.

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

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.

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 você iniciar a VM para o primeiro salto, o Google Cloud usará a primeira rota.

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

  • 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

  • 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 túneis de VPN de alta disponibilidade ou túneis de VPN clássica que usem roteamento dinâmico.

  • 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