Rotas estáticas

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

Para uma visão geral das rotas no Google Cloud, consulte a Visão geral das rotas.

Considerações para criar rotas estáticas

É possível criar rotas estáticas de duas maneiras:

É possível trocar rotas estáticas com uma rede VPC com peering, conforme descrito em Opções para trocar rotas estáticas personalizadas na documentação do Peering de redes VPC.

Parâmetros de rota

As rotas estáticas são compatíveis com os seguintes atributos:

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

  • Próximo salto. O próximo salto identifica o recurso de rede a que os pacotes são enviados. Todos os tipos de próximo salto oferecem suporte a destinos IPv4, e alguns tipos de próximo salto oferecem suporte a destinos IPv6. Para mais informações, consulte Próximos saltos e recursos.

  • Intervalo de destino. O intervalo de destino é uma única notação CIDR IPv4 ou IPv6.

    Os destinos de rotas estáticas precisam seguir as regras descritas em Interações com rotas estáticas personalizadas e Interações de sub-rede e rota estática. O destino mais amplo possível para uma rota estática IPv4 é 0.0.0.0/0. O destino mais amplo possível para uma rota estática IPv6 é ::/0.

  • Prioridade. Números menores indicam prioridades mais altas. A prioridade mais alta possível é 0, e a prioridade mais baixa é 65,535.

  • Tags de rede. É possível fazer com que uma rota estática seja aplicada apenas a instâncias de VM selecionadas na rede VPC, identificadas por uma tag de rede. Se você não especificar uma tag de rede, o Google Cloud aplicará a rota estática a todas as instâncias da rede. Rotas estáticas com tags nunca são trocadas ao usar o peering de rede VPC.

Próximos saltos e recursos

A tabela a seguir resume o suporte ao recurso de rota estática por tipo de próximo salto:

Próximo tipo de salto IPv4 IPv6 ECMP1
Gateway do próximo salto (next-hop-gateway)
Especifique um gateway de Internet padrão para definir um caminho para endereços IP externos.
Instância do próximo salto por nome e zona (next-hop-instance)
Enviar pacotes para uma VM do próximo salto que seja identificada por nome e zona e que esteja no mesmo projeto como a rota. Para mais informações, consulte Considerações para instâncias do próximo salto.
Instância do próximo salto por endereço (next-hop-address)
Enviar pacotes para uma VM do próximo salto identificada pelo endereço IPv4 interno endereço IPv6 interno ou externo da interface de rede. Para mais informações, consulte Considerações para instâncias do próximo salto.		 (Visualização)
Balanceador de carga de rede de passagem interna do próximo salto por nome da regra de encaminhamento (next-hop-ilb) e região (next-hop-ilb-region)
Envie pacotes para os back-ends de um balanceador de carga de rede de passagem interna identificado pelo nome da regra de encaminhamento, região e, opcionalmente, projeto. Para mais informações, consulte Considerações para os próximos saltos do balanceador de carga de rede interno.
Balanceador de carga de rede de passagem interna do próximo salto por endereço (next-hop-ilb).
Envie pacotes para back-ends de um balanceador de carga de rede de passagem interna, que é identificado pelo endereço IP da regra de encaminhamento do balanceador de carga. Para mais informações, consulte Considerações para os próximos saltos do balanceador de carga de rede interno.
Túnel da VPN clássica do próximo salto (next-hop-vpn-tunnel)
Enviar pacotes para um túnel da VPN clássica do próximo salto usando um roteamento com base em política ou uma VPN baseada em rota. Para mais informações, consulte Considerações para próximos saltos de túnel de VPN clássica.
1Multicaminho de custo igual (ECMP, na sigla em inglês) significa que duas ou mais rotas estáticas podem compartilhar o mesmo intervalo de destino e prioridade. Embora seja possível criar duas ou mais rotas estáticas em uma rede VPC com o mesmo destino, prioridade e próximo salto do gateway de Internet padrão, o efeito é o mesmo de uma única rota estática que usa o próximo salto de gateway de Internet padrão para esse destino e prioridade.

Projeto e rede do próximo salto

Uma rota estática do próximo salto está associada a uma rede VPC e a um projeto:

  • Rede: exceto conforme indicado na tabela abaixo, a rede VPC do próximo salto precisa corresponder à rede VPC da rota.

  • Projeto: exceto conforme indicado na tabela abaixo, o próximo salto precisa estar localizado no projeto que contém a rede VPC dele (um projeto independente ou um projeto host de VPC compartilhada). Alguns próximos saltos podem estar localizados em projetos de serviço de VPC compartilhada.

Próximo tipo de salto Podem estar em uma rede VPC com peering Pode estar em um projeto de serviço de VPC compartilhada
Gateway do próximo salto (next-hop-gateway)
Instância do próximo salto por nome (next-hop-instance)
Instância do próximo salto por endereço (next-hop-address)
Balanceador de carga de rede de passagem interna do próximo salto por nome e região da regra de encaminhamento (next-hop-ilb)
Balanceador de carga de rede de passagem interna do próximo salto por endereço (next-hop-ilb)
Túnel da VPN clássica do próximo salto (next-hop-vpn-tunnel)

Considerações comuns para os próximos saltos do balanceador de carga de rede da instância e da passagem interna

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

Balanceador de carga de rede de passagem interna como um próximo salto refere-se a uma rota estática com um próximo salto que é um balanceador de carga de rede de passagem interna (next-hop-ilb).

Ao configurar o roteamento com base em instância ou um balanceador de carga de rede de passagem 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 de firewall com permissão de entrada personalizada.
    • 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.

  • A região de origem de um pacote enviado por uma VM de back-end ou uma instância do próximo salto é onde a VM de back-end ou a instância do próximo salto está localizada. Por exemplo, os pacotes processados por VMs de back-end ou instâncias do próximo salto em us-west1 podem ser enviados para destinos acessíveis apenas em us-west1, mesmo que a VM de back-end ou a instância do próximo salto originalmente receberam o pacote de um recurso em uma região diferente de us-west1. Veja a seguir alguns exemplos de recursos que podem ser acessados apenas na mesma região de uma VM que envia um pacote, inclui:

    • Balanceadores de carga de rede de passagem interna, balanceadores de carga de aplicativo internos e balanceadores de carga de rede de proxy interno regional com acesso global desativado
    • Túneis do Cloud VPN, anexos da VLAN do Cloud Interconnect e VMs do dispositivo roteador do Network Connectivity se a rede VPC usar roteamento dinâmico regional

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

  • Próximo salto por nome e zona da instância (next-hop-instance): quando você cria uma rota estática que tem uma instância do próximo salto especificada por nome e zona, o Google Cloud exige que uma instância com esse nome exista na zona especificada e atenda ao seguinte:

    • A instância está localizada no mesmo projeto da rota.
    • A instância tem uma interface de rede (NIC) na rede VPC da rota, e não uma rede VPC com peering.

    Enquanto a rota estática existir:

    • O Google Cloud atualiza automaticamente a programação para o próximo salto em um dos seguintes casos:

      • O endereço IPv4 interno principal da próxima instância de salto for alterado ou
      • Você substitui a instância do próximo salto, e ela tem o mesmo nome, está na mesma zona e projeto e tem uma interface de rede na rede VPC da rota.

    • O Google Cloud não atualiza a programação para o próximo salto na seguintes casos:

      • Quando a instância é excluída.
      • O intervalo de endereços IPv6 atribuído às mudanças de placa de rede (NIC) da instância.
      • Quando o endereço IPv4 ou IPv6 da instância não estiver atribuído.

  • Endereço IP da instância do próximo salto (next-hop-address): os endereços IP válidos da VM do próximo salto são:

    • O endereço IPv4 interno principal de uma interface de rede da VM.
    • Qualquer endereço IPv6 interno ou externo no intervalo de endereços IPv6 /96 atribuído a uma interface de rede de VM.

    Quando você cria uma rota estática com uma instância do próximo salto especificada por um IP, o Google Cloud aceita qualquer endereço IP atribuído pela VM que atenda um intervalo de sub-redes na mesma rede VPC ao longo do trajeto. No entanto, o Google Cloud só programa a rota se a próxima é um endereço IP da VM do próximo salto válido. Por exemplo, se você criar uma rota e especificar o próximo salto como um endereço IP proveniente de um alias intervalo de IP, a rota é criada. No entanto, como os endereços IP de alias não são endereços IP válidos da VM do próximo salto, a rota não será programada.

    O Google Cloud atualiza automaticamente a programação para o próximo salto se o endereço IP do próximo salto for movido para outra VM, permanece um endereço IP válido da VM do próximo salto.

    Quando você especifica uma instância de próximo salto por endereço IP, os pacotes são roteados para a interface de rede da instância, não para o endereço IP específico.

  • Instâncias do próximo salto em projetos de serviço de VPC compartilhada: quando você especifica uma VM de próximo salto por endereço IP, a VM pode estar localizada no mesmo projeto como a rota (um projeto independente ou um projeto host de VPC compartilhada) ou a VM pode estar localizada em um projeto de serviço de VPC compartilhada. Quando você especifica uma VM de próximo salto por nome e zona da instância, ela precisa estar localizada no mesmo projeto que a rota e a rede VPC (um projeto autônomo ou um projeto host de VPC compartilhada).

  • 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 aumenta os custos da transferência de dados de saída e gera 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 de rede de passagem interno e da instância. Desativar a interface de rede da VM ao configurar o sistema operacional convidado da instância não causa o Google Cloud desconsidere a instância do 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 precisar que a mesma VM processe pacotes para uma determinada conexão em ambas as direções, precisará de hash simétrico, que é compatível apenas com pelos balanceadores de carga de rede de passagem interna do próximo salto. Para mais informações, consulte Hash simétrico.

  • Comportamento quando as instâncias são interrompidas ou excluídas: o Google Cloud não impede que você pare ou exclua uma VM do próximo salto de rota estática (especificada por um nome e zona ou endereço interno). Quando uma VM de próximo salto não está em execução, o roteamento para o destino depende da existência de outras rotas para o mesmo destino e se elas têm próximos saltos em execução. Para ilustrar esse comportamento, considere os exemplos a seguir:

    • Os pacotes com destinos que se encaixam em 192.168.168.0/24 são enviados para o próximo salto de route-vm-b na seguinte situação, em que o próximo salto para a rota de maior prioridade não está em execução. Esse roteamento acontece porque o Google Cloud desconsidera os próximos saltos que não estão em execução antes de considerar a etapa Ignorar rotas de baixa prioridade da ordem de roteamento:
    • route-vm-a, destino 192.168.168.0/24, prioridade 10, a VM do próximo salto está interrompida
    • route-vm-b, destino 192.168.168.0/24, prioridade 20, a VM do próximo salto está em execução.

    • route-vm-c, destino 192.168.168.0/24, prioridade 30, a VM do próximo salto está em execução.

    • Os pacotes com destinos que se encaixam em 192.168.168.0/24 são descartados neste próximo exemplo, em que todas as VMs do próximo salto para as rotas 192.168.168.0/24 não estão em execução, mesmo que uma rota para a 192.168.0.0/16 mais ampla tenha uma VM do próximo salto que esteja em execução. Os pacotes são descartados porque o Google Cloud desconsidera rotas com intervalos de destino mais amplos (menores comprimento de máscara de sub-rede) na etapa destino mais específico que acontece antes da etapa desconsiderar rotas estáticas personalizadas que os próximos saltos não estejam em execução da ordem de roteamento:

    • route-vm-x, destino 192.168.168.0/24, prioridade 10, a VM do próximo salto está interrompida

    • route-vm-y, destino 192.168.168.0/24, prioridade 20, a VM do próximo salto está interrompida

    • route-vm-z, destino 192.168.0.0/16, prioridade 0, a VM do próximo salto está em execução.

Considerações sobre os próximos saltos do balanceador de carga de rede de passagem interno

  • Regras de encaminhamento compatíveis. O Google Cloud é compatível apenas com regras de encaminhamento do balanceador de carga de rede de passagem interna de próximo salto. O Google Cloud não é compatível com regras de encaminhamento de próximo salto usadas por outros balanceadores de carga, encaminhamento de protocolo ou como endpoints do Private Service Connect.

  • Métodos de especificação e rede e projeto de regras de encaminhamento. É possível especificar uma regra de encaminhamento de próximo salto usando um dos três métodos a seguir. O método de especificação usado determina se a rede da regra de encaminhamento precisa corresponder à rede da rota e em qual projeto a regra de encaminhamento pode estar localizada:

    • Por nome (--next-hop-ilb) e região (--next-hop-ilb-region) da regra de encaminhamento: ao especificar uma regra de encaminhamento de próximo salto por nome e região, a rede da regra de encaminhamento precisa corresponder à rede VPC da rota. A regra de encaminhamento precisa estar localizada no mesmo projeto que contém a rede dela (um projeto independente ou um projeto host de VPC compartilhada).

    • Por link de recurso da regra de encaminhamento: um link de recurso da regra de encaminhamento usa o formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, em que PROJECT_ID é o ID do projeto que contém a regra de encaminhamento, REGION é a região da regra de encaminhamento e FORWARDING_RULE_NAME é o nome da regra de encaminhamento. Ao especificar uma regra de encaminhamento do próximo salto pelo link do recurso, a rede da regra de encaminhamento precisa corresponder à rede VPC da rota. A regra de encaminhamento pode estar localizada em um destes projetos: no projeto que contém a rede dela (um projeto independente ou um projeto host de VPC compartilhada) ou em um projeto de serviço de VPC compartilhada.

    • Por endereço IPv4 da regra de encaminhamento: ao especificar uma regra de encaminhamento de próximo salto pelo respectivo endereço IPv4, a rede dela pode ser uma destas: a rede VPC da rota ou uma rede VPC com peering. A regra de encaminhamento pode estar localizada em um destes projetos: no projeto que contém a rede dela (um projeto independente ou um projeto host de VPC compartilhada) ou em um projeto de serviço de VPC compartilhada.

  • Efeito do acesso global. As rotas estáticas personalizadas que usam os próximos saltos do balanceador de carga de rede 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 de rede de passagem interno são descartados.

  • Quando nenhum back-end é íntegro. Quando todos os back-ends de um balanceador de carga de rede de passagem 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). Os balanceadores de carga internos de passagem de salto e as regras de encaminhamento do balanceador de carga de rede de passagem interno com um endereço IP comum são recursos mutuamente exclusivos. Um balanceador de carga de rede de passagem interna do próximo salto precisa usar um endereço IP exclusivo para a 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 de rede de passagem internos).

  • Várias rotas com os mesmos destinos e prioridades, mas diferentes balanceadores de carga de rede de passagem interna de próximo salto. O Google Cloud nunca distribui o tráfego entre dois ou mais balanceadores de carga de rede de passagem interna de próximo salto usando o ECMP. Em vez disso, o Google Cloud seleciona apenas um balanceador de carga de rede de passagem interna de próximo salto usando um algoritmo interno determinístico. Para evitar essa ambiguidade, use tags de rede exclusivas para cada rota.

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

  • Várias rotas com os mesmos destinos, prioridades e balanceadores de carga de rede de passagem interna de próximo salto. Sem uma tag de rede, o Google Cloud não permite criar várias rotas estáticas que tenham a mesma combinação de destino, prioridade e próximo salto do balanceador de carga de rede de passagem interna. Com as tags de rede, é possível criar várias rotas estáticas com a mesma combinação de destino, prioridade e próximo salto do balanceador de carga de rede de passagem interna.

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

  • Custos e latência de região a região: o Google Cloud não considera distância regional para rotas que usam uma VPN clássica de próximo salto por túnel. O envio de tráfego para um túnel de VPN clássica de próximo salto em outra região adiciona custos de transferência de dados de saída e introduz 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 túneis de VPN clássica não estão em execução: rotas estáticas personalizadas com próximos saltos que são túneis de VPN clássica não são removidas automaticamente quando esses túneis não estão em execução. Para detalhes sobre o que acontece quando os túneis não estão em execução, consulte Quando os túneis estão desativados na documentação da VPN clássica.

A seguir

  • Para criar e gerenciar rotas, consulte Usar rotas.
  • Para ter uma visão geral das rotas do Google Cloud, consulte Rotas.