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 saltos seguintes sejam o gateway de Internet predefinido. Cada rede da nuvem virtual privada (VPC) começa com uma rota predefinida cujo destino é 0.0.0.0/0 e cujo salto seguinte é o gateway de Internet predefinido. Para ver informações de contexto importantes, consulte a vista geral das rotas.

Os exemplos seguintes ilustram situações que podem fazer com que os gateways de 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 os gateways NAT público .

  • Se criar uma rota estática personalizada cujo próximo salto seja um túnel da 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 salto seguinte 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 anexados a um hub do Network Connectivity Center que contém apenas raios da VPC, o NAT privado usa as rotas da sub-rede trocadas pelos raios da VPC anexados. Para ver informações sobre os raios da VPC, consulte o artigo Vista geral dos raios da VPC.
    • Se um hub do Network Connectivity Center contiver raios de 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 de VPC anexados. Para obter informações sobre raios híbridos, consulte o artigo Raios híbridos.
  • Para o NAT híbrido, o NAT privado usa rotas dinâmicas aprendidas pelo Cloud Router através do Cloud Interconnect ou do Cloud VPN.

Interações do 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,Google Cloud ativa automaticamente o Acesso privado do Google para um intervalo de endereços IP de sub-rede quando configura um gateway de NAT pública para aplicar a esse intervalo de sub-rede, primário ou secundário. Enquanto o gateway fornecer NAT para um intervalo de 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 em 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 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 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 está 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 e portas de origem da NAT 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áticas 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 as portas mínimas 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) através de 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 do tráfego de saída dos pods, pode usar uma política de rede.

Em determinadas circunstâncias, NAT pública 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 Cloud NAT. 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 NAT público :

  • Para clusters nativos da VPC, o gateway NAT público 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

As gateways do Cloud NAT podem fornecer NAT para recursos do Cloud Run configurados com saída da VPC direta. 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 ser definido como all-traffic.

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

    • Especifique os intervalos de sub-redes de origem que 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 é definido como 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 os 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 backends de grupos de pontos finais de rede (NEGs) da Internet regionais. Ao configurar gateways NAT na nuvem 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 tráfego deve ter origem. Google Cloud As verificações de saúde e o tráfego do plano de dados são provenientes dos 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 centro de conectividade de rede e 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.

O que se segue?