Interações com produtos do Cloud NAT

Nesta página, descrevemos as interações importantes entre o Cloud NAT e outros produtos do Google Cloud.

Interações de rotas

Um gateway do Public NAT só pode usar rotas que tenham como próximos saltos o gateway de Internet padrão. Cada rede de nuvem privada virtual (VPC) começa com uma rota padrão cujo destino é 0.0.0.0/0 e cujo próximo salto é o gateway de Internet padrão. Para informações contextuais importantes, consulte a visão geral das rotas.

Nos exemplos a seguir, ilustramos situações que podem fazer com que os gateways do Public NAT se tornem inoperantes:

  • Se você criar uma rota estática personalizada com próximos saltos definidos como qualquer outro tipo de próximo salto de rota estática personalizada, os pacotes com endereços IPs de destino correspondentes ao destino da rota serão enviados para o próximo salto em vez do gateway de Internet padrão. Por exemplo, ao usar instâncias de máquina virtual (VM) que executam um software de gateway, firewall ou proxy NAT, você cria rotas estáticas personalizadas para direcionar o tráfego para essas VMs como o próximo salto. As VMs de próximo salto exigem endereços IP externos. Assim, o tráfego das VMs que dependem das VMs do próximo salto ou das próprias VMs de próximo salto não pode usar gateways do Public NAT .

  • Se você criar uma rota estática personalizada que tenha como próximo salto um túnel do Cloud VPN, Public NAT não usará essa rota. Por exemplo, uma rota estática personalizada com destino 0.0.0.0/0 e um túnel do Cloud VPN de próximo salto direciona o tráfego para esse túnel, não para o gateway de Internet padrão. Portanto, os gateways do Public NAT não podem usar essa rota. Da mesma forma, os gateways Public NAT não podem usar rotas estáticas personalizadas com destinos mais específicos, incluindo 0.0.0.0/1 e 128.0.0.0/1.

  • Se um roteador local divulgar uma rota dinâmica personalizada para um Cloud Router que gerencia um túnel do Cloud VPN ou um anexo da VLAN, NAT pública os gateways do Cloud NAT não poderão usar essa rota. Por exemplo, se o roteador local divulgar uma rota dinâmica personalizada com o destino 0.0.0.0/0, 0.0.0.0/0 será direcionado para o túnel do Cloud VPN ou o anexo da VLAN. Esse comportamento se aplica mesmo a destinos mais específicos, incluindo 0.0.0.0/1 e 128.0.0.0/1.

A NAT particular usa as seguintes rotas:

  • Para a Inter-VPC NAT, o Private NAT usa apenas rotas de sub-rede trocadas por dois spokes de VPC do Network Connectivity Center anexados a um hub do Network Connectivity Center. Para mais informações sobre os spokes de VPC do Network Connectivity Center, consulte Visão geral dos spokes de VPC.
  • Para o Hybrid NAT (pré-lançamento), o Private NAT usa as rotas dinâmicas aprendidas pelo Cloud Router pelo Cloud VPN.

Interação com o Acesso privado do Google

Um gateway Public NAT nunca executa NAT para o tráfego enviado aos endereços IP externos selecionados para APIs e serviços do Google. Em vez disso, o Google Cloud ativa automaticamente o Acesso privado do Google para um intervalo de endereços IP de sub-rede quando você configura um gatewaypúblico NATpara aplicar a esse intervalo de sub-rede, primário ou secundário. Contanto que o gateway forneça o NAT a um intervalo de sub-rede, o Acesso privado do Google estará em vigor para esse intervalo e não poderá ser desativado manualmente.

Um gateway Public NAT não altera o funcionamento do Acesso privado do Google. Para mais informações, consulte Acesso privado do Google.

Os gateways NAT particulares não se aplicam ao Acesso privado do Google.

Interação de VPC compartilhada

A VPC compartilhada permite que vários projetos de serviço em uma única organização usem uma rede VPC compartilhada comum em um projeto host. Para fornecer NAT para VMs em projetos de serviço que usam uma rede VPC compartilhada, você deve criar gateways do Cloud NAT no projeto de host.

Interação de peering de rede VPC

Os gateways Cloud NAT estão associados aos intervalos de endereços IP de sub-rede em uma única região e em uma única rede VPC. Um gateway do Cloud NAT criado em uma rede VPC não pode fornecer NAT para VMs em outras redes VPC conectadas por meio do peering de rede VPC ou de spokes VPC do Network Connectivity Center, mesmo que as VMs em redes com peering estejam na mesma região que o gateway.

Interação do GKE

Um gateway Public NAT pode executar NAT para nós e pods em um cluster particular, que é um tipo de cluster nativo de VPC. O gateway do Public NAT precisa ser configurado para ser aplicado pelo menos aos seguintes intervalos de endereços IP de sub-redes para a sub-rede usada pelo cluster:

  • Intervalo de endereços IP principais de sub-rede (usado pelos nós)
  • Intervalo de endereços IP secundários da sub-rede usado para pods no cluster
  • Intervalo de endereços IP secundários da sub-rede usado para serviços no cluster

A maneira mais simples de fornecer NAT a um cluster particular inteiro é configurar um gatewaypúblico de NATpara aplicar a todos os intervalos de endereços IP de sub-redes da sub-rede do cluster.

Para mais informações em segundo plano sobre como os clusters nativos de VPC utilizam intervalos de endereços IP de sub-rede, consulte Intervalos de IP para clusters nativos de VPC.

Quando um gateway Public NAT é configurado para fornecer NAT a um cluster particular, ele reserva endereços IP de origem NAT e portas de origem para cada VM do nó. Esses endereços IP de origem NAT e portas de origem podem ser usados pelos pods porque os endereços IP do pod são implementados como intervalos de IP de alias atribuídos a cada VM de nó.

Os clusters nativos de VPC do Google Kubernetes Engine (GKE) sempre atribuem a cada nó um intervalo de IP do alias que contém mais de um endereço IP (máscara de rede menor que /32).

  • Se a alocação de porta estática estiver configurada, o procedimento de reserva de porta do Public NAT vai reservar pelo menos 1.024 portas de origem por nó. Se o valor especificado do número mínimo de portas por VM for maior que 1.024, esse valor será usado.

  • Se a alocação de porta dinâmica estiver configurada, o valor especificado das portas mínimas por VM será inicialmente alocado por nó. O número de portas alocadas posteriormente varia entre os valores especificados para portas mínimas e máximas por VM, com base sob demanda.

Para informações sobre intervalos de endereços IP de pods e clusters nativos de VPC, consulte Intervalo de endereços IP secundários de sub-redes para pods.

Independentemente da NAT pública , o Google Kubernetes Engine realiza a conversão de endereços de rede de origem (NAT ou SNAT de origem) usando o software em execução em cada nó quando os pods enviam pacotes para a Internet, a menos que você tenha alterado a configuração de mascaramento de IP do cluster. Se você precisar de controle granular sobre o tráfego de saída dos pods, use uma política de rede.

Em determinadas circunstâncias, Public NAT também pode ser útil para clusters nativos de VPC não particulares. Como os nós em um cluster não particular têm endereços IP externo, os pacotes enviados do endereço IP interno principal do nó nunca são processados pelo Cloud NAT. No entanto, se as duas condições a seguir forem verdadeiras, os pacotes enviados de pods em um cluster não particular poderão ser processados por um gatewaypúblico NAT:

  • Nos clusters nativos de VPC, o gateway Public NAT é configurado para aplicar ao intervalo de endereços IP secundário dos pods do cluster.

  • A configuração do mascaramento de IP do cluster não está configurada para executar SNAT no cluster para pacotes enviados de pods para a Internet.

O exemplo a seguir mostra a interação do Public NAT com o GKE:

Public NAT com GKE.
Public NAT com GKE (clique para ampliar).

Neste exemplo, você quer que seus contêineres sejam convertidos para NAT. Para ativar o NAT para todos os contêineres e o nó do GKE, escolha todos os intervalos de endereços IP de Subnet 1 como candidato NAT:

  • Intervalo do endereço IP primário da sub-rede: 10.240.0.0/24
  • Intervalo de endereços IP secundário da sub-rede usado para pods: 10.0.0.0/16

Não é possível ativar o NAT somente para Pod1 ou Pod2.

Um gateway NAT particular pode executar NAT para nós e pods em um cluster particular e em um cluster não particular. O gateway do Private NAT se aplica automaticamente a todos os intervalos de endereços IP de sub-rede usados pelo cluster.

Interações de saída de VPC direta

Public NAT podem executar NAT para serviços do Cloud Run ou jobs configurados com Saída de VPC direta. Para permitir que o Cloud Run use um gateway do Public NAT , configure o gateway do Public NAT com as seguintes configurações:

  • Para configurar quais sub-redes e intervalos de endereços IP de sub-rede associados às instâncias do Cloud Run podem usar o gateway Public NAT , especifique a sinalização --nat-all-subnet-ip-ranges ou --nat-custom-subnet-ip-ranges:
    • Para permitir que todos os intervalos de endereços IP de todas as sub-redes da região usem o gateway Public NAT , especifique a sinalização --nat-all-subnet-ip-ranges.
    • Para permitir que apenas sub-redes e intervalos de endereços IP específicos usem o gateway Public NAT , especifique-os com a sinalização --nat-custom-subnet-ip-ranges.
  • Defina o valor da sinalização --endpoint-types como ENDPOINT_TYPE_VM. Esse valor garante que apenas VMs e endpoints de VM de saída de VPC direta possam usar o gateway Public NAT .
  • No caso de alocação de porta estática, defina o valor da sinalização --min-ports-per-vm como quatro vezes o número de portas necessárias para uma única instância do Cloud Run.
  • No caso de alocação manual de endereços IP NAT, atribua um número adequado de endereços IP ao gateway Public NAT para contabilizar o soma do número de instâncias do Google Cloud e do Cloud Run implantadas na rede VPC.

Além da configuração do gateway, para enviar tráfego de saída de um serviço ou job do Cloud Run, defina a sinalização --vpc-egress como all-traffic ao criar o serviço ou job.

Se você tiver configurado um serviço ou job do Cloud Run que tenha a sinalização --vpc-egress definida como private-ranges-only, o serviço ou job enviará o tráfego apenas para endereços IP internos. Você não precisa de um gateway do Public NAT para rotear o tráfego para destinos internos.

Para evitar que os serviços ou jobs do Cloud Run que tenham a sinalização --vpc-egress definida como private-ranges-only usem um gateway NAT público faça o seguinte:

  • Configure o gateway Public NAT com a sinalização --nat-custom-subnet-ip-ranges.
  • Defina o valor da sinalização --nat-custom-subnet-ip-ranges como os nomes de sub-rede em que você implantou serviços ou jobs do Cloud Run com a sinalização --vpc-egress definida como all-traffic.

As limitações a seguir se aplicam aos serviços e jobs do Cloud Run que usam gateways do Public NAT:

  • As métricas do Cloud NAT para endpoints de saída de VPC direta não são exportadas para o Cloud Monitoring.
  • Os registros do Cloud NAT para saída da VPC direta não mostram o nome de um serviço, revisão ou job do Cloud Run.

Não é possível usar gateways Private NAT com endpoints de saída VPC direta.

Interações de Testes de conectividade

Use os Testes de conectividade para verificar a conectividade entre endpoints de rede que usam configurações do Cloud NAT. É possível executar testes de conectividade em redes que usam gateways NAT públicos, gateways NAT particulares ou ambos.

Veja os detalhes da configuração do NAT no painel Trace de análise de configuração na página Detalhes do teste de conectividade.

Interações do Cloud Load Balancing

Os balanceadores de carga de aplicativo internos regionais e regionais do Google Cloud se comunicam com vários back-ends de grupo de endpoints de rede da Internet (NEG, na sigla em inglês) regionais. Ao configurar gateways do Cloud NAT para os NEGs regionais da Internet, é possível alocar seu próprio conjunto de intervalos de endereços IP externo de onde o tráfego do Google Cloud deve se originar. As verificações de integridade e o tráfego do plano de dados são provenientes dos endereços IP do NAT alocados por você.

Outros balanceadores de carga externos e sistemas de verificação de integridade do Google Cloud se comunicam com as VMs usando rotas especiais. As VMs de back-end não exigem endereços IP externo nem um gateway do Cloud NAT gerencia a comunicação para balanceadores de carga e verificações de integridade. Para mais informações, consulte Visão geral do Cloud Load Balancing e Visão geral das verificações de integridade.

A seguir