Interações com o produto Cloud NAT

Esta página descreve as interações importantes entre o Cloud NAT e outros Google Cloud produtos.

Interações com trajetos

Um gateway de NAT público só pode usar rotas cujos próximos saltos sejam o gateway de Internet predefinido. Cada rede de nuvem virtual privada (VPC) começa com uma rota predefinida cuja destinação é 0.0.0.0/0 e cujo próximo salto é o gateway de Internet predefinido. Para obter informações de contexto importantes, consulte a vista geral das rotas.

Os exemplos seguintes ilustram situações que podem fazer com que os gateways NAT público fiquem inoperacionais:

  • Se criar uma rota estática com saltos seguintes definidos como qualquer outro tipo de salto seguinte de rota estática, os pacotes com endereços IP de destino correspondentes ao destino da rota são enviados para esse salto seguinte em vez de para o gateway de Internet predefinido. Por exemplo, se usar instâncias de máquinas virtuais (VMs) que executam um gateway NAT, uma firewall ou um software proxy, cria rotas estáticas para direcionar o tráfego para essas VMs como o próximo salto. As VMs de próximo salto requerem endereços IP externos. Assim, o tráfego das VMs que dependem das VMs de próximo salto ou das próprias VMs de próximo salto não pode usar gateways de NAT público .

  • Se criar uma rota estática personalizada cujo próximo salto seja um túnel do Cloud VPN, o NAT público não usa essa rota. Por exemplo, um encaminhamento estático com o 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 e não para o gateway de Internet predefinido. Por conseguinte, os gateways de NAT público não podem usar essa rota. Da mesma forma, os gateways de NAT público não podem usar rotas estáticas com destinos mais específicos, incluindo 0.0.0.0/1 e 128.0.0.0/1.

  • Se um router no local anunciar uma rota dinâmica a um Cloud Router que gere um túnel de VPN na nuvem ou um anexo de VLAN, NAT público os gateways não podem usar essa rota. Por exemplo, se o seu router no local anunciar um trajeto dinâmico com o destino 0.0.0.0/0, o tráfego para 0.0.0.0/0 seria direcionado para o túnel da Cloud VPN ou a ligação VLAN. Este comportamento mantém-se verdadeiro mesmo para destinos mais específicos, incluindo 0.0.0.0/1 e 128.0.0.0/1.

A NAT privada usa os seguintes trajetos:

  • Para os raios do Network Connectivity Center, a NAT privada usa rotas de sub-rede e rotas dinâmicas:
    • Para o tráfego entre dois raios da VPC associados a um hub da NCC que contém apenas raios da VPC, o NAT privado usa as rotas da sub-rede trocadas pelos raios da VPC associados. Para ver informações sobre os raios da VPC, consulte o artigo Vista geral dos raios da VPC.
    • Se um hub da NCC contiver raios da VPC e raios híbridos, como anexos de VLAN para o Cloud Interconnect, túneis de VPN do Google Cloud ou VMs de dispositivo de encaminhamento, o NAT privado usa as rotas dinâmicas aprendidas pelos raios híbridos através do BGP e as rotas de sub-rede trocadas pelos raios da VPC anexados. Para obter informações sobre raios híbridos, consulte o artigo Raios híbridos.
  • Para a NAT híbrida, a NAT privada usa rotas dinâmicas aprendidas pelo Cloud Router através do Cloud Interconnect ou do Cloud VPN.

Interações com o acesso privado do Google

Um gateway de NAT público nunca executa NAT para tráfego enviado para os endereços IP externos selecionados para APIs e serviços Google. Em alternativa, o gateway de Google Cloud ativa automaticamente o acesso privado à Google para um intervalo de endereços IP de sub-rede quando configura um gateway de NAT público para aplicar a esse intervalo de sub-rede, primário ou secundário. Desde que o gateway forneça NAT para o intervalo de uma sub-rede, o acesso privado à Google está em vigor para esse intervalo e não pode ser desativado manualmente.

Uma gateway de NAT pública não altera a forma como o Acesso privado do Google funciona. Para mais informações, consulte o artigo Acesso privado à Google.

Os gateways NAT privados não se aplicam ao acesso privado à Google.

Interações da VPC partilhada

A VPC partilhada permite que vários projetos de serviço numa única organização usem uma rede VPC partilhada comum num projeto anfitrião. Para fornecer NAT para VMs em projetos de serviço que usam uma rede de VPC partilhada, tem de criar gateways Cloud NAT no projeto anfitrião.

Interações de intercâmbio da rede da VPC

Os gateways NAT da nuvem estão associados a intervalos de endereços IP de sub-redes numa única região e numa única rede da VPC. Um gateway Cloud NAT criado numa rede da VPC não pode fornecer NAT a VMs noutras redes da VPC que estejam ligadas através do intercâmbio das redes da VPC, mesmo que as VMs nas redes com intercâmbio estejam na mesma região que o gateway.

Interações do GKE

Um gateway de NAT público pode executar NAT para nós e pods num cluster privado, que é um tipo de cluster nativo da VPC. O gateway NAT público tem de ser configurado para se aplicar, pelo menos, aos seguintes intervalos de endereços IP da sub-rede que o cluster usa:

  • Intervalo de endereços IP principal da sub-rede (usado por 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 forma mais simples de fornecer NAT para um cluster privado inteiro é configurar um gateway de NAT público para aplicar a todos os intervalos de endereços IP da sub-rede do cluster.

Para informações gerais sobre como os clusters nativos de VPC usam intervalos de endereços IP de sub-redes, consulte o artigo Intervalos de IP para clusters nativos de VPC.

Quando um gateway de NAT público é configurado para fornecer NAT para um cluster privado, reserva endereços IP de origem NAT e portas de origem para cada VM de nó. Esses endereços IP de origem NAT e portas de origem são utilizáveis pelos pods porque os endereços IP dos pods são implementados como intervalos de IP de alias atribuídos a cada VM de nó.

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

  • Se a atribuição de portas estática estiver configurada, o procedimento de reserva de portas NAT público reserva,pelo menos,1024 portas de origem por nó. Se o valor especificado para o número mínimo de portas por VM for superior a 1024, esse valor é usado.

  • Se a atribuição dinâmica de portas estiver configurada, o valor especificado para o número mínimo de portas por VM é inicialmente atribuído por nó. O número de portas atribuídas varia posteriormente entre os valores especificados para o mínimo e o máximo de portas por VM, com base na procura.

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

Independentemente de NAT público , o Google Kubernetes Engine realiza a tradução de endereços de rede de origem (NAT de origem ou SNAT) usando software executado em cada nó quando os pods enviam pacotes para a Internet, a menos que tenha alterado a configuração de mascaramento de IP do cluster. Se precisar de um controlo detalhado sobre o tráfego de saída dos pods, pode usar uma política de rede.

Em determinadas circunstâncias, o NAT público também pode ser útil para clusters nativos da VPC não privados. Uma vez que os nós num cluster não privado têm endereços IP externos, os pacotes enviados a partir do endereço IP interno principal do nó nunca são processados pelo NAT da nuvem. No entanto, se ambas as seguintes condições forem verdadeiras, os pacotes enviados a partir de pods num cluster não privado podem ser processados por um gateway de NAT público :

  • Para clusters nativos da VPC, o gateway NAT pública está configurado para se aplicar ao intervalo de endereços IP secundário dos pods do cluster.

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

O exemplo seguinte mostra a interação de NAT público com o GKE:

NAT público com o GKE.
NAT público com o GKE (clique para aumentar).

Neste exemplo, quer que os seus contentores sejam traduzidos por NAT. Para ativar a NAT para todos os contentores e o nó do GKE, tem de escolher todos os intervalos de endereços IP de Subnet 1 como candidato a NAT:

  • Intervalo de endereços IP principais da sub-rede: 10.240.0.0/24
  • Intervalo de endereços IP secundários da sub-rede usado para pods: 10.0.0.0/16

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

Um gateway NAT privado pode executar NAT para nós e pods num cluster privado e num cluster não privado. O gateway NAT privado aplica-se automaticamente a todos os intervalos de endereços IP da sub-rede privada que o cluster usa.

Interações de saída da VPC direta

Os gateways Cloud NAT podem fornecer NAT para recursos do Cloud Run configurados com saída direta da VPC. Para permitir que o Cloud Run use uma gateway do Cloud NAT para NAT público ou NAT privado, configure o seguinte:

  • Quando implementar os seus recursos do Cloud Run, defina a flag --vpc-egress. Se quiser usar a NAT pública, o valor tem de estar definido como all-traffic.

  • Configure a gateway do Cloud NAT com as seguintes definições:

    • Especifique que intervalos de sub-redes de origem podem usar o gateway definindo a flag --nat-custom-subnet-ip-ranges. Defina o valor para os nomes das sub-redes onde implementa os seus recursos do Cloud Run.
    • Defina o valor da flag --endpoint-types como ENDPOINT_TYPE_VM.

    • Para o NAT público, certifique-se de que o valor da flag --min-ports-per-vm está definido para o dobro do número de portas necessárias por uma única instância do Cloud Run. Para NAT privado, esta flag tem de ser definida para quatro vezes o número de portas necessárias por instância do Cloud Run.

    • Se quiser configurar a atribuição manual de endereços IP NAT (apenas NAT pública), atribua um número de endereços IP ao gateway suficiente para cobrir a soma das instâncias de VM e das instâncias do Cloud Run publicadas pelo gateway.

Os registos do Cloud NAT para a saída da VPC direta não apresentam os nomes dos recursos do Cloud Run.

Interações dos testes de conetividade

Pode usar testes de conetividade para verificar a conetividade entre pontos finais de rede que usam configurações do Cloud NAT.Pode executar testes de conetividade em redes que usam gateways NAT públicos ou gateways NAT privados, ou ambos.

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

Interações do Cloud Load Balancing

OsGoogle Cloud balanceadores de carga de aplicações internos regionais e os balanceadores de carga de aplicações externos regionais comunicam com vários back-ends de grupos de pontos finais de rede (NEGs) da Internet regionais. Ao configurar gateways Cloud NAT para os NEGs da Internet regionais, pode atribuir o seu próprio conjunto de intervalos de endereços IP externos a partir dos quais o Google Cloud tráfego deve ter origem. As verificações de funcionamento e o tráfego do plano de dados têm origem nos endereços IP NAT que atribui.

Outros Google Cloud balanceadores de carga externos e sistemas de verificação de funcionamento comunicam com as VMs através de caminhos de encaminhamento especiais. As VMs de back-end não requerem endereços IP externos, nem um gateway Cloud NAT gere a comunicação para balanceadores de carga e verificações de funcionamento. Para mais informações, consulte a Vista geral do Cloud Load Balancing e a Vista geral das verificações de funcionamento.

Interações de ligações propagadas do Private Service Connect

Quando usar o NAT privado para o NCC e as ligações propagadas do Private Service Connect no mesmo spoke da VPC, aplica-se o seguinte:

  • Se uma sub-rede estiver configurada com NAT privado, o tráfego da sub-rede para ligações propagadas do Private Service Connect é ignorado.

  • Para evitar a perda de tráfego de sub-redes não sobrepostas, considere o seguinte quando configurar o NAT privado:

    • Especifique sub-redes sobrepostas através da flag --nat-custom-subnet-ip-ranges.
    • Não especifique sub-redes não sobrepostas que precisam de aceder a ligações propagadas.
    • Não use a flag --nat-all-subnet-ip-ranges.

Interações com sub-redes híbridas

O NAT híbrido não é suportado com as sub-redes híbridas.

Se o tráfego tiver origem numa sub-rede onde o NAT híbrido está configurado e o endereço IP de destino corresponder a uma rota de sub-rede híbrida, o SNAT não é realizado. Esta configuração resulta num comportamento de encaminhamento imprevisível porque o tráfego pode alcançar uma rede não VPC através do endereço IP de origem original não traduzido.

Não use sub-redes híbridas em redes onde o NAT híbrido está configurado.

O que se segue?