Rotas estáticas

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

Para uma vista geral dos trajetos no Google Cloud, consulte a vista geral dos trajetos.

Considerações para criar rotas estáticas

Pode criar rotas estáticas de duas formas:

• Pode criar rotas estáticas manualmente através da Google Cloud consola, gcloud compute routes create ou da routes.insert API.

• Se usar a Google Cloud consola para criar um túnel de VPN clássica que não use o encaminhamento dinâmico, a Cloud VPN pode criar rotas estáticas correspondentes automaticamente. Para mais informações, consulte o artigo Redes VPN do Google Cloud e encaminhamento de túneis.

Pode trocar rotas estáticas com uma rede VPC com peering, conforme descrito nas Opções para trocar rotas estáticas personalizadas na documentação do VPC Network Peering.

Parâmetros de rota

As rotas estáticas suportam os seguintes atributos:

• Nome e Descrição. Estes campos identificam o trajeto. É necessário introduzir um nome, mas a descrição é opcional. Cada trajeto no seu projeto tem de ter um nome exclusivo.

• Rede. Cada trajeto tem de estar associado exatamente a uma rede VPC.

• Salto seguinte. O próximo salto identifica o recurso de rede para o qual os pacotes são enviados. Todos os tipos de próximo salto suportam destinos IPv4 e alguns tipos de próximo salto suportam destinos IPv6. Para mais informações, consulte Saltos seguintes e funcionalidades.

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

  Os destinos das rotas estáticas têm de seguir as regras descritas em Interações entre rotas de sub-rede e rotas estáticas e Interações de sub-redes e rotas estáticas do peering de redes VPC. 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. Os números mais baixos indicam prioridades mais elevadas. A prioridade mais elevada possível é 0 e a mais baixa possível é 65,535.

• Etiquetas de rede. Pode fazer com que uma rota estática se aplique apenas a instâncias de VM selecionadas na rede de VPC, identificadas por uma etiqueta de rede:

  • Uma rota estática sem uma etiqueta de rede aplica-se a todos os recursos na rede VPC, incluindo todas as instâncias de VM, os túneis do Cloud VPN, as associações de VLAN do Cloud Interconnect, os dispositivos de encaminhamento e os proxies do Envoy em sub-redes apenas de proxy.

  • Uma rota estática com uma etiqueta de rede aplica-se apenas a instâncias de VM que tenham essa etiqueta de rede. Não se aplica a outros recursos.

  • Os trajetos estáticos com etiquetas nunca são trocados quando usa o VPC Network Peering.

Saltos seguintes e funcionalidades

A tabela seguinte resume o suporte de funcionalidades de rotas estáticas por tipo de salto seguinte:

Projeto e rede do salto seguinte

O próximo salto de uma rota estática está associado a uma rede VPC e a um projeto:

• Rede: exceto quando indicado na tabela seguinte, a rede VPC do salto seguinte tem de corresponder à rede VPC da rota.

• Projeto: exceto quando indicado na tabela seguinte, o próximo salto tem de estar localizado no projeto que contém a rede VPC do próximo salto (um projeto autónomo ou um projeto anfitrião da VPC partilhada). Alguns saltos seguintes podem estar localizados em projetos de serviço da VPC partilhada.

Considerações comuns aos próximos saltos do balanceador de carga de rede de encaminhamento interno e de instâncias

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

Balanceador de carga de rede de encaminhamento interno como salto seguinte refere-se a uma rota estática com um salto seguinte que é um balanceador de carga de rede de encaminhamento interno (next-hop-ilb).

Quando configura o encaminhamento baseado em instâncias ou um Network Load Balancer de passagem interno como um salto seguinte, tenha em consideração as seguintes diretrizes:

• Tem de 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) numa base por VM quando criar a VM. Para VMs criadas automaticamente como parte de um grupo de instâncias gerido, ative o encaminhamento de IP no modelo de instância usado pelo grupo de instâncias. Tem de fazer esta alteração de configuração além de qualquer configuração do sistema operativo necessária para encaminhar pacotes.

• O software em execução na VM de back-end ou na instância do próximo salto tem de ser configurado adequadamente. Por exemplo, as VMs de dispositivos de terceiros que atuam como routers ou firewalls têm de ser configuradas de acordo com as instruções do fabricante.

• As VMs de back-end ou a instância de salto seguinte têm de ter regras de firewall adequadas. Tem de configurar regras de firewall que se aplicam aos pacotes que estão a ser encaminhados. Tenha em atenção o seguinte:

  • As regras de firewall de entrada aplicáveis a instâncias que executam funções de encaminhamento têm de incluir os endereços IP de origens de pacotes encaminhados. A regra de entrada de negação implícita bloqueia todos os pacotes recebidos, pelo que tem de criar, pelo menos, regras de firewall de entrada de permissão personalizadas.
  • As regras de firewall de saída aplicáveis a instâncias que executam funções de encaminhamento têm de incluir os endereços IP dos destinos de pacotes encaminhados. A regra de saída de permissão implícita permite esta ação, a menos que tenha criado uma regra de saída de recusa específica para a substituir.
  • Tenha em conta se a VM de back-end ou a instância de próximo salto está a realizar a tradução de endereços de rede (NAT) quando criar as regras de firewall.

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

• A região de origem de um pacote enviado por uma VM de back-end ou uma instância de salto seguinte é a região onde a VM de back-end ou a instância de salto seguinte está localizada. Por exemplo, os pacotes processados por VMs de back-end ou instâncias de 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 de próximo salto tenha recebido originalmente o pacote de um recurso numa região diferente de us-west1. Seguem-se exemplos de recursos que só estão acessíveis na mesma região que uma VM que envia um pacote:

  • Balanceadores de carga de rede de encaminhamento interno, balanceadores de carga de aplicações internos e balanceadores de carga de rede de proxy internos regionais com o acesso global desativado
  • Túneis do Cloud VPN, anexos de VLAN do Cloud Interconnect e VMs de appliance do router de conetividade de rede se a rede VPC usar o encaminhamento dinâmico regional

Considerações para instâncias de salto seguinte

• Salto seguinte por nome da instância e zona (next-hop-instance): quando cria uma rota estática que tem uma instância de salto seguinte especificada pelo nome da instância e pela zona, Google Cloud requer que exista uma instância com esse nome na zona especificada e que cumpra os seguintes requisitos:

  • A instância está localizada no mesmo projeto que a rota.
  • A instância tem uma interface de rede (NIC) na rede da VPC da rota (não numa rede da VPC com intercâmbio).

  Enquanto a rota estática existir, aplica-se o seguinte:

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

    • O endereço IPv4 interno principal da instância do próximo salto muda, ou
    • Substitui a instância de salto seguinte e a instância de substituição tem o mesmo nome, está na mesma zona e projeto, e tem uma interface de rede na rede VPC da rota.

  • OGoogle Cloud não atualiza a programação para o próximo salto nos seguintes casos:

    • Quando a instância é eliminada.
    • O intervalo de endereços IPv6 atribuído à NIC da instância é alterado.
    • Quando o endereço IPv4 ou IPv6 da instância não está atribuído.

• Endereço IP da instância do próximo salto (next-hop-address): os endereços IP de VM do próximo salto válidos são os seguintes:
  • O endereço IPv4 interno principal de uma interface de rede de VM.
  • Qualquer endereço IPv6 interno ou externo no /96intervalo de endereços IPv6 atribuído a uma interface de rede de VM.

  Quando cria uma rota estática com uma instância de próximo salto especificada por um endereço IP, Google Cloud aceita qualquer endereço IP atribuído à VM que se enquadre num intervalo de sub-rede de uma sub-rede na mesma rede VPC que a rota. No entanto, Google Cloud só programa a rota se o endereço do próximo salto for um endereço IP de VM de próximo salto válido. Por exemplo, se criar uma rota e especificar o próximo salto como um endereço IP proveniente de um intervalo de IP de alias, a rota é criada. No entanto, uma vez que os endereços IP de alias não são endereços IP de VMs de próximo salto válidos, a rota não é programada.

  Google Cloud atualiza automaticamente a programação para o próximo salto se o endereço IP do próximo salto for movido para uma VM diferente, se o endereço IP permanecer um endereço IP de VM de próximo salto válido.

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

• Instâncias de próximo salto em projetos de serviço de VPC partilhada: quando especifica uma VM de próximo salto por endereço IP, a VM pode estar localizada no mesmo projeto que a rota (um projeto autónomo ou um projeto anfitrião de VPC partilhada) ou a VM pode estar localizada num projeto de serviço de VPC partilhada. Quando especifica uma VM de salto seguinte pelo nome da instância e zona, a VM de salto seguinte tem de estar localizada no mesmo projeto que a rota e a rede VPC (um projeto autónomo ou um projeto anfitrião de VPC partilhada).

• Custos e latência de região para região: quando usa uma VM como próximo salto, o próximo salto está localizado numa 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 etiqueta de rede correspondente.O Google Cloud não considera a distância regional para rotas que usam uma instância como um próximo salto, pelo que é possível criar uma rota que envie tráfego para uma VM de próximo salto numa região diferente. Google Cloud O envio de pacotes de uma região para outra adiciona custos de transferência de dados de saída e introduz latência de rede.

• Sem verificação de funcionamento, sem validação da configuração: Google Cloud nunca verifica se uma instância de próximo salto cumpre todos os requisitos descritos na secção Considerações comuns às instâncias e aos próximos saltos do balanceador de carga de rede de passagem interna. A desativação da interface de rede da VM através da configuração do sistema operativo convidado da instância não faz com que Google Cloud a instância de salto seguinte seja ignorada.

• Não existe hash simétrico quando se ligam duas redes VPC: Google Cloud não oferece hash simétrico quando usa duas ou mais VMs de salto seguinte que têm várias interfaces de rede numa configuração que cumpre todos os seguintes critérios:

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

  Se usar duas ou mais VMs com várias interfaces para ligar redes VPC e precisar que a mesma VM processe pacotes para uma determinada ligação em ambas as direções, precisa de hashing simétrico, que só é suportado por equilibradores de carga de passagem interna de próximo salto. Para mais informações, consulte o artigo Hash simétrico.

• Comportamento quando as instâncias são paradas ou eliminadas: Google Cloud não impede que pare ou elimine uma VM de próximo salto de rota estática (especificada pelo nome e pela zona ou pelo endereço interno). Quando uma VM de salto seguinte não está em execução, o encaminhamento depende da existência de outras rotas para o mesmo destino e se essas outras rotas têm saltos seguintes que estão em execução. Para ilustrar este comportamento, considere os seguintes exemplos:

  • Tem os seguintes trajetos e estados de VMs:

    • route-a, destino 192.168.168.0/24, prioridade 10, a VM de salto seguinte vm-a está parada
    • route-b, destino 192.168.168.0/24, prioridade 20, a VM de salto seguinte vm-b está em execução
    • route-c, destino 192.168.168.0/24, prioridade 30, a VM de salto seguinte vm-c está em execução

    Neste exemplo, os pacotes cujos destinos se enquadram em 192.168.168.0/24 são enviados para o próximo salto vm-b porque o próximo salto vm-a da prioridade mais alta route-a não está em execução. Isto acontece porque o passo disregard static and dynamic routes with unusable next hops precede o passo disregard low priority routes naGoogle Cloud ordem de encaminhamento.

  • Tem os seguintes trajetos e estados de VMs:

    • route-x, destino 192.168.168.0/24, prioridade 10, a VM de salto seguinte vm-x está parada
    • route-y, destino 192.168.168.0/24, prioridade 20, a VM de salto seguinte vm-y está parada
    • route-z, destino 192.168.0.0/16, prioridade 0, próximo salto A VM vm-z está em execução

    Neste exemplo, os pacotes cujos destinos se enquadram em 192.168.168.0/24 são ignorados porque as VMs de próximo salto para as duas rotas 192.168.168.0/24 (route-x e route-y) não estão em execução, mesmo que exista uma rota para o destino 192.168.0.0/16 mais amplo (route-z) com uma VM de próximo salto em execução. Isto acontece porque o passo de destino mais específico precede o passo de ignorância das rotas estáticas e dinâmicas com saltos seguintes não utilizáveis naGoogle Cloud ordem de encaminhamento.

Considerações para os próximos saltos do balanceador de carga de rede de encaminhamento interno

• Regras de encaminhamento suportadas. Google Cloud suporta apenas regras de encaminhamento do balanceador de carga de rede de passagem interna de próximo salto. Google Cloud Não suporta regras de encaminhamento de próximo salto usadas por outros balanceadores de carga, encaminhamento de protocolos ou como pontos finais do Private Service Connect.

• Métodos de especificação e rede e projeto da regra de encaminhamento. Pode especificar uma regra de encaminhamento do próximo salto através de um dos três métodos seguintes. O método de especificação que usa determina se a rede da regra de encaminhamento tem de corresponder à rede da rota e em que projeto a regra de encaminhamento pode estar localizada.

  Escolha um dos seguintes métodos e certifique-se de que a versão IP da sua regra de encaminhamento corresponde à versão IP da rota estática que criar:

  • Pelo nome da regra de encaminhamento (--next-hop-ilb) e pela região (--next-hop-ilb-region): quando especifica uma regra de encaminhamento de próximo salto pelo nome e pela região, a rede da regra de encaminhamento tem de corresponder à rede de VPC da rota. A regra de encaminhamento tem de estar localizada no mesmo projeto que contém a rede da regra de encaminhamento (um projeto autónomo ou um projeto anfitrião da VPC partilhada).

  • Por link de recurso da regra de encaminhamento: um link de recurso de uma regra de encaminhamento usa o formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, onde 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. Quando especifica uma regra de encaminhamento do próximo salto através do respetivo link de recurso, a rede da regra de encaminhamento tem de corresponder à rede da VPC da rota. A regra de encaminhamento pode estar localizada no projeto que contém a rede da regra de encaminhamento (um projeto autónomo ou um projeto anfitrião de VPC partilhada) ou num projeto de serviço de VPC partilhada.

  • Pelo endereço IP de uma regra de encaminhamento: quando especifica uma regra de encaminhamento de próximo salto pelo respetivo endereço IPv4 ou IPv6, a rede da regra de encaminhamento pode ser a rede VPC da rota ou uma rede VPC que esteja ligada à rede VPC da rota através do peering de redes VPC ou do Network Connectivity Center. O Network Connectivity Center suporta um balanceador de carga de rede de passagem interno de próximo salto num raio da VPC sujeito aos requisitos do Network Connectivity Center para conetividade. A regra de encaminhamento pode estar localizada no projeto que contém a rede da regra de encaminhamento (um projeto autónomo ou um projeto anfitrião de VPC partilhada) ou num projeto de serviço de VPC partilhada.

• Efeito do acesso global. As rotas estáticas personalizadas que usam saltos seguintes do Network Load Balancer de passagem interna são programadas em todas as regiões. A usabilidade do próximo salto depende da definição de acesso global do balanceador de carga. Com o acesso global ativado, o próximo salto do balanceador de carga é acessível em todas as regiões da rede VPC. Com o acesso global desativado, o próximo salto do balanceador de carga só é acessível na mesma região que o balanceador de carga. Com o acesso global desativado, os pacotes enviados de outra região para um encaminhamento que use um próximo salto do Network Load Balancer de passagem interno são ignorados.

• Quando todos os back-ends estão em mau estado de funcionamento. Quando todos os back-ends de um balanceador de carga de encaminhamento interno falham nas verificações de funcionamento, as rotas que usam o próximo salto desse balanceador de carga continuam 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.

• As regras de encaminhamento que usam um endereço IP interno comum (--purpose=SHARED_LOADBALANCER_VIP) não são suportadas. O próximo salto dos balanceadores de carga de rede de encaminhamento interno e das regras de encaminhamento do balanceador de carga de rede de encaminhamento interno com um endereço IP comum são funcionalidades mutuamente exclusivas. Um Network Load Balancer de passagem interno de salto seguinte tem de 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 de forma inequívoca. É possível que as regras de encaminhamento que usam um endereço IP interno comum façam referência a diferentes serviços de back-end (diferentes equilibradores de carga de rede de passagem interna).

• Vários trajetos com os mesmos destinos e prioridades, mas diferentes balanceadores de carga de rede de passagem interna de salto seguinte. Google Cloud Nunca distribui tráfego entre dois ou mais balanceadores de carga de rede de passagem interna de salto seguinte através do ECMP. Em alternativa, o Google Cloud seleciona apenas um encaminhamento interno de próximo salto do balanceador de carga de rede através de um algoritmo interno determinístico.Google Cloud Para evitar esta ambiguidade, pode usar etiquetas de rede únicas para cada trajeto.

  

• Várias rotas com os mesmos destinos, prioridades e próximo salto Equilibradores de carga de rede de encaminhamento interno. Sem uma etiqueta de rede, Google Cloud não lhe permite criar várias rotas estáticas com a mesma combinação de destino, prioridade e próximo salto do equilibrador de carga de rede de encaminhamento interno. Com as etiquetas de rede, pode 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 para os próximos saltos do túnel de VPN clássica

• Custos e latência de região para região: Google Cloud não considera a distância regional para rotas que usam um túnel de VPN clássica de próximo salto. O envio de tráfego para um túnel VPN clássico de próximo salto noutra 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 HA com encaminhamento dinâmico em vez disso, porque essa configuração considera a distância regional.

• Comportamento quando os túneis de VPN clássica não estão em execução: os encaminhamentos estáticos personalizados cujos saltos seguintes são túneis de VPN clássica não são removidos automaticamente quando os túneis de VPN clássica não estão em execução. Para ver detalhes sobre o que acontece quando os túneis não estão em execução, consulte a secção Quando os túneis estão inativos na documentação da VPN clássica.

Considerações para o Network Connectivity Center

• Pode criar rotas estáticas a partir dos raios da VPC para equilibradores de carga de rede de passagem interna acessíveis através do hub do Network Connectivity Center.
• Aplicam-se limitações adicionais a estas rotas estáticas do Network Connectivity Center. Para mais informações, consulte a vista geral dos trajetos estáticos.

O que se segue?

• Para criar e gerir trajetos, consulte o artigo Use trajetos.
• Para obter uma vista geral dos trajetos Google Cloud, consulte Trajetos.