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 dentro da 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 único destino (CIDR) e um único 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. Embora algumas rotas possam ser aplicadas seletivamente, 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 redes VPC podem incluir rotas geradas pelo sistema ou rotas personalizadas.

A tabela a seguir resume as rotas geradas pelo sistema, que são adicionadas ou atualizadas automaticamente quando você cria uma rede VPC, adiciona uma sub-rede, expande o intervalo de IP principal de uma sub-rede ou edita o intervalo de IP secundário de uma sub-rede. Elas se aplicam a todas as instâncias na rede VPC.

Rotas geradas pelo sistema
Tipo Destino Próximo salto Removível
Rota padrão 0.0.0.0/0 default-internet-gateway Sim
Rota de sub-rede Intervalos de IP primário e secundário da sub-rede
Rede VPC, que encaminha pacotes para VMs nas sub-redes delas Somente quando a sub-rede é excluída ou quando você altera os intervalos de IP secundários da sub-rede

A tabela a seguir resume as rotas personalizadas, que você cria e mantém diretamente ou usando o Cloud Router.

Rotas personalizadas
Tipo Destino Próximo salto Removível Aplicável a
Rota estática • Intervalo de IP que não se sobrepõe parcial ou exatamente com nenhum intervalo de IP de sub-rede
• Intervalo de IP mais amplo que um intervalo de IP de sub-rede
Um de:
• Instância por nome
• Instância por endereço IP
• Túnel do Cloud VPN
Sim Ou:
• Todas as instâncias na rede
• Instâncias específicas na rede, identificadas pela tag de rede, se o escopo da rota puder ser definido pela tag de rede
Rota dinâmica • Intervalo de IP que não se sobrepõe parcial ou exatamente com nenhum intervalo de IP de sub-rede
• Intervalo de IP mais amplo que um intervalo de IP de sub-rede
Endereço IP do peer de BGP do Cloud Router Somente por um Cloud Router, se ele não receber mais a rota do peer de BGP • Instâncias na mesma região do Cloud Router, se a rede VPC estiver no modo de roteamento dinâmico regional
• Todas as instâncias, se a rede VPC estiver no modo de roteamento dinâmico global

Rota padrão

Ao criar uma rede VPC, o Google Cloud cria uma rota padrão gerada pelo sistema. Essa rota tem dois propósitos:

  • Ela define o caminho para fora da rede VPC, inclusive o caminho para a Internet. Além dessa rota, as instâncias precisarão atender aos requisitos complementares se necessitarem de acesso à Internet.

  • Ela fornece o caminho padrão para o Acesso privado do Google.

A rota padrão gerada pelo sistema tem uma prioridade de 1000. Como o destino é o mais amplo possível (0.0.0.0/0), o Google Cloud o usa somente 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, exclua 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 um túnel do Cloud VPN ou outra instância, como um servidor proxy.

  • Se você remover 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

Rotas de sub-rede são rotas geradas pelo sistema que definem caminhos para cada sub-rede na 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, o Google Cloud criará uma rota de sub-rede com um destino correspondente para cada intervalo secundário. Para mais informações sobre intervalos de IP de sub-rede, consulte Redes e sub-redes.

Nenhuma outra rota pode ter um destino que corresponda ou seja mais específico que o destino de uma rota de sub-rede. É possível criar uma rota personalizada com um intervalo de destino mais amplo que contenha o intervalo de destino da rota de sub-rede.

Em casos de sobreposição de intervalo de IP, como o Google Cloud usa a especificidade do destino como o primeiro critério para ordem de roteamento, a rota de sub-rede é sempre o próximo salto preferencial para pacotes que têm destinos que se encaixam em seu intervalo de destino. Isso é verdadeiro mesmo que outra rota com destino que contenha o destino da rota de sub-rede tenha uma prioridade maior.

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

  • Quando uma sub-rede é criada, uma rota de sub-rede correspondente ao intervalo de IP principal da sub-rede também é criada.

    • Se você adicionar um intervalo de IP secundário a uma sub-rede, será criada uma rota de sub-rede correspondente a esse intervalo secundário.
  • 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 você 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.

  • Quando as redes são conectadas usando Peering de Rede VPC, as rotas de sub-rede de uma rede são importadas para a outra rede e vice-versa. Por isso, todos os intervalos de IP principais e secundários da sub-rede precisam ser exclusivos.

    • Não é possível que as rotas de sub-redes para sub-redes em redes com peering sejam removidas, a menos que você quebre o relacionamento de peering. Ao fazer isso, todas as rotas de sub-rede importadas da outra rede serão automaticamente removidas.

É possível que as regras de firewall bloqueiem a comunicação entre instâncias. Para ver informações sobre a comunicação de instância para instância, consulte a comunicação na rede.

Rotas personalizadas

Rotas personalizadas são ou rotas estáticas que você cria manualmente ou rotas dinâmicas mantidas automaticamente por um ou mais de seus Cloud Routers.

Os destinos para rotas personalizadas não podem ser os mesmos ou mais específicos que qualquer rota de sub-rede na rede.

Se você estiver usando uma rede VPC de modo automático, não use destinos que estejam no bloco CIDR 10.128.0.0/9, porque esse bloco define o espaço de endereço atual e futuro para rotas de sub-rede. Para mais informações, consulte Intervalos de IP do modo automático.

É possível que rotas estáticas com destinos dentro de 10.128.0.0/9 sejam desativadas a qualquer momento em uma rede VPC de modo automático. Isso acontece se uma nova região do Google Cloud estiver disponível e uma nova sub-rede for criada automaticamente (com a rota de sub-rede). Para mais informações, consulte Considerações sobre as redes VPC de modo automático.

Rotas estáticas

É possível que rotas estáticas usem qualquer um dos próximos saltos da rota estática. Você cria rotas estáticas de duas maneiras:

  • É possível criá-las manualmente.

  • Se você utiliza o Console do Google Cloud para criar um túnel do Cloud VPN que usa roteamento baseado em política ou uma VPN baseada em rota, são criadas rotas estáticas para os seletores de tráfego remotos. Para mais informações, consulte Roteamento de túnel e redes do Cloud VPN.

Para mais informações, consulte Parâmetros de rota estáticos.

Rotas dinâmicas

Rotas dinâmicas são gerenciadas por um ou mais Cloud Routers. Os destinos sempre representam intervalos de IP fora da rede VPC, e os próximos saltos são sempre endereços de terceiros no BGP. Um Cloud Router pode gerenciar rotas dinâmicas para:

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.

  • Rotas geradas pelo sistema se aplicam a todas as instâncias em uma rede VPC. Não é possível alterar o escopo das instâncias a que as rotas de sub-rede se aplicam. No entanto, é possível substituir a rota padrão.

  • As rotas estáticas personalizadas se aplicam 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 uma tag de rede correspondente. 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 estã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 a rede VPC estiver no modo de roteamento dinâmico regional, todos os Cloud Routers aplicarão rotas aprendidas nas respectivas regiões. Se a rede estiver no modo de roteamento dinâmico global, todos os Cloud Routers aplicarão rotas aprendidas em toda a rede.

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

Ordem de roteamento

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

  1. As rotas de sub-rede são consideradas primeiro porque o Google Cloud exige que as rotas de sub-rede tenham os destinos mais específicos correspondentes aos intervalos de endereços IP das respectivas sub-redes. As rotas de sub-rede são rotas para os intervalos de endereços IP de sub-rede principal e secundária de cada sub-rede na rede VPC e para os intervalos de endereços IP de sub-redes primárias e secundárias em redes com peering. Se o destino de um pacote se encaixa no destino de uma rota de sub-rede, ele é entregue na sub-rede do Google Cloud. Não é possível substituir uma rota de sub-rede por nenhum outro tipo de rota.

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

    • Nos casos em que uma rota estática tem o mesmo tamanho de prefixo que uma rota dinâmica, a rota estática tem uma prioridade mais alta que a rota dinâmica do Cloud Router. Uma rota estática com o mesmo prefixo e mesma métrica de uma rota dinâmica sempre tem uma prioridade mais alta que a rota dinâmica, de modo que todas as rotas dinâmicas conflitantes sejam ignoradas.

    • Para rotas dinâmicas personalizadas, o Cloud Router ignora qualquer rota para outras redes recebidas por um Cloud Router se a rota recebida tiver um destino igual ou mais específico do que qualquer rota de sub-rede.

    • Quando você conecta redes VPC usando peering de rede VPC, as redes compartilham todas as rotas de sub-redes. O Google Cloud prioriza rotas de sub-rede em redes similares semelhantes às próprias rotas de sub-redes da rede local: rotas de sub-redes em redes de mesmo nível precisam ter os destinos mais específicos.

  2. Se o pacote não couber no destino de uma rota de sub-rede, o Google Cloud procurará uma rota personalizada com o destino mais específico.

    • Suponha que o destino de um pacote que sai de uma VM seja 10.240.1.4 e que haja duas rotas com destinos diferentes: 10.240.1.0/24 e 10.240.0.0/16. Como o destino mais específico para 10.240.1.4 é 10.240.1.0/24, a rota com destino 10.240.1.0/24 define o próximo salto para o pacote.
  3. Se mais de uma rota personalizada tiver o mesmo destino mais específico, o Google Cloud usará o seguinte processo para selecionar uma rota das rotas candidatas. As rotas candidatas são rotas personalizadas (estáticas ou dinâmicas) que têm o mesmo destino mais específico.

    1. Se sua rede VPC estiver conectada a outras redes por meio do peering de rede VPC, o Google Cloud diminuirá as rotas candidatas que forem todas de uma única rede VPC.

      • Se pelo menos uma sugestão de rota candidata for definida em sua rede VPC local, o Google Cloud usará a rota candidata local e desconsiderará todas as candidatas de redes semelhantes.

      • Se as rotas candidatas forem de várias redes do mesmo nível, o Google Cloud selecionará uma das redes semelhantes em que pelo menos uma rota candidata está definida e desconsidera rotas candidatas de outras redes de mesmo nível. O Google Cloud usa um método não determinístico para selecionar a rede de mesmo nível, independentemente da prioridade de cada rota. Se você adicionar ou remover redes do grupo de peering, o Google Cloud poderá escolher rotas candidatas de outra rede semelhante.

      O Google Cloud é movido para selecionar uma rota a partir de rotas candidatas de uma única rede.

    2. Se uma rota com a maior prioridade estiver disponível, o Google Cloud enviará o pacote para o próximo salto.

    3. Se várias rotas tiverem a prioridade mais alta, o Google Cloud selecionará uma rota com base em uma rota estática ou dinâmica e no valor do próximo salto. O Google Cloud usa a seguinte ordem (listada por preferência):

      1. O Google Cloud seleciona uma rota estática personalizada que tem como próximo salto: próxima instância de salto, IP do próximo salto ou túnel da VPN do próximo salto.

      2. O Google Cloud seleciona uma rota dinâmica personalizada que está sendo anunciada por um Cloud Router.

      3. O Google Cloud seleciona uma rota estática personalizada que tem como próximo salto o balanceador de carga TCP/UDP interno do próximo salto.

      4. O Google Cloud seleciona uma rota estática personalizada usando o gateway de Internet padrão do próximo salto.

    4. Se nenhuma rota única puder ser selecionada, o Google Cloud distribuirá o tráfego entre os próximos saltos das rotas candidatas usando um hash de cinco tuplas para afinidade, implementando um design de roteamento ECMP. O hash é calculado a partir do protocolo, dos endereços IP de origem e destino e das portas de origem e destino do pacote que está sendo enviado. Esse cálculo é feito para cada pacote enviado com base no número de rotas candidatas disponíveis. Se o número de rotas candidatas disponível for alterado, o hash poderá direcionar o pacote para um próximo salto.

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

Caminhos de retorno 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. Essas rotas estão definidas fora de 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.

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

Para esses tipos de balanceadores 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 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 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.

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. O Google Cloud não é compatível com intervalos de destino IPv6. Os destinos precisam ser expressos na notação CIDR, e 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 mais altas. Por exemplo, uma rota com prioridade 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.

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

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

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

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

    • O Google Cloud só confirma que uma VM de próximo salto existe quando você cria a rota. Ele não valida a capacidade da VM de processar ou encaminhar pacotes. Se a VM for excluída, mas não substituída, a rota ainda será aplicada, o que pode resultar em pacotes descartados. Para mais informações, consulte Instâncias como próximos saltos.

  • Balanceador de carga TCP/UDP interno do próximo salto (next-hop-ilb). Para balanceamento de carga TCP/UDP interno, use o endereço IP do balanceador de carga como um próximo salto que distribui o tráfego entre instâncias de back-end íntegras. Por exemplo, use uma rota estática personalizada que tenha como próximo salto um balanceador de carga TCP/UDP interno para distribuir o tráfego entre as VMs de back-end. As rotas estáticas personalizadas que usam este próximo salto não podem ser limitadas a instâncias específicas pela tag de rede.

  • IP do próximo salto (next-hop-address). É possível proporcionar um endereço IP como próximo salto se esse endereço couber no intervalo de IP principal ou secundário de uma sub-rede existente na rede VPC. Não é possível usar um endereço IP público ou um endereço IP interno em uma rede local.

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

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

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

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

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

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

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

  • É necessário configurar as VMs de back-end ou a Próxima instância de salto para encaminhar pacotes de outras fontes (can-ip-forward). É possível ativar o encaminhamento de IP por VM quando criar a VM. Para ativar o encaminhamento de IP para VMs criadas automaticamente como parte de um grupo de instâncias gerenciadas, ative o encaminhamento de IP no modelo de instância usado pelo grupo de instâncias. Você precisa 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 Próxima instância de salto precisa ser configurado adequadamente. Por exemplo, VMs de dispositivos de terceiros que agem como roteadores ou firewalls precisam ser configuradas de acordo com as instruções do fabricante.

  • As VMs de back-end ou a Próxima instância de salto precisam ter regras de firewall apropriadas. Você deve configurar regras de firewall que se aplicam aos pacotes que estão sendo roteados. Lembre-se do seguinte:

    • As regras de entrada do firewall aplicáveis a instâncias que executam funções de roteamento precisam 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ê precisa 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 precisam 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.
    • Considere se a VM de back-end ou a Próxima instância de salto está realizando a Conversão de endereços de rede (NAT) ao criar suas regras de firewall.

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

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

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

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

    • Se você especificar next-hop-instance, a instância já deverá existir.
    • Se você especificar next-hop-address, o endereço IP precisa estar no intervalo de IP primário ou secundário da sub-rede existente.
  • Por exemplo, se você remover uma instância ou excluir uma sub-rede, o Google Cloud ainda considerará qualquer rota que a use como um próximo salto quando avaliar as rotas aplicáveis. Isso pode fazer com que alguns ou todos os pacotes de um determinado destino sejam descartados, dependendo das outras rotas na sua rede.

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

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

A seguir