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 NAT público o gateway só pode usar rotas com os próximos saltos gateway de Internet padrão. Cada rede de nuvem privada virtual (VPC) começa com um rota com destino 0.0.0.0/0 e em que o próximo salto é o padrão de um gateway de VPN de alta disponibilidade. Para informações contextuais importantes, consulte a visão geral de rotas.

Os exemplos a seguir ilustram situações que podem causar NAT público que os gateways 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, se você usa instâncias de máquina virtual (VM) que executam um gateway NAT, firewall ou proxy; você cria rotas estáticas personalizadas para direcionar o tráfego para essas VMs como 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 VMs do próximo salto. não possam usar NAT público gateways.

  • Se você criar uma rota estática personalizada que tenha como próximo salto um Cloud VPN túnel, NAT público não usa esse trajeto. Por exemplo, um bloco Rota estática com destino 0.0.0.0/0 e um Cloud VPN de próximo salto direciona o tráfego para esse túnel, não para o gateway de Internet padrão. Portanto, NAT público os gateways não podem usar trajeto. Da mesma forma, NAT público os gateways não podem usar imagens estáticas rotas 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 o Cloud Router que gerencia um túnel do Cloud VPN ou anexo da VLAN, NAT público gateways não podem usar essa rota. Por exemplo, se o roteador no local anuncia 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 anexo da VLAN. Esse comportamento é válido mesmo para destinos mais específicos, incluindo 0.0.0.0/1 e 128.0.0.0/1.

A NAT particular usa as seguintes rotas:

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

Interação com o Acesso privado do Google

Um NAT público gateway nunca executa NAT para o tráfego enviado ao endereços IP externos para APIs do Google e serviços. Em vez disso, O Google Cloud ativa automaticamente o Acesso privado do Google para um intervalo de endereços IP de sub-rede. NAT público para se aplicar a esse intervalo de sub-rede, seja ele 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 NAT público gateway não muda a forma como O Acesso privado do Google funciona. 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 NAT público pode executar NAT para nós e pods em um cluster particular, que é um tipo de cluster nativo de VPC. O NAT público gateway precisa ser configurado para ser aplicado pelo menos aos seguintes intervalos de endereços IP de sub-redes para a sub-rede que o cluster usa:

  • 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 para um cluster particular inteiro é configurar a NAT público a ser aplicado em todos os intervalos de endereços IP da sub-rede 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 NAT público é configurado para fornecer NAT a uma rede VPC 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.

Independente de NAT público , o Google Kubernetes Engine executa as verificações conversão de endereços (NAT ou SNAT de origem) usando software em execução em cada nó quando os pods enviam pacotes para a Internet. a menos que você tenha alterado o mascaramento de IP . Se você precisar controle granular sobre o tráfego de saída dos pods, é possível usar uma política.

Em certas circunstâncias, NAT público podem ser úteis para usuários clusters nativos de VPC. Como os nós em um cluster não particular têm endereços IP externo, pacotes enviados do endereço IP interno primário do nó nunca são o Cloud NAT. No entanto, se ambas as condições forem verdadeiras, os pacotes enviados de Os pods em um cluster não particular podem ser processados por NAT público gateway:

  • Para clusters nativos de VPC, a NAT público o gateway é configuradas para serem aplicadas 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 NAT público com o GKE:

Public NAT com GKE.
NAT público com o 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 do Private NAT pode realizar 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

NAT público os gateways podem realizar NAT para serviços do Cloud Run ou jobs configurados com Saída de VPC direta. Para permitir que o Cloud Run use uma NAT público seu gateway de VPN de alta disponibilidade, NAT público para um gateway de VPN de alta qualidade com os seguintes configurações:

  • Para configurar quais sub-redes e intervalos de endereços IP de sub-redes são associados à As instâncias do Cloud Run podem usar o NAT público gateway, 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 NAT público de gateway, especifique o parâmetro --nat-all-subnet-ip-ranges .
    • Para permitir que apenas sub-redes e intervalos de endereços IP específicos usem o NAT público de gateway, especifique-as com 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 da VPC direta possam usar o NAT público para outro gateway de VPN de alta disponibilidade.
  • No caso de alocação de porta estática, defina o valor do --min-ports-per-vm. sinalização para quatro vezes o número de portas necessárias para um único instância do Cloud Run.
  • No caso de alocação manual de endereços IP NAT, atribua um número adequado de aos endereços IP internos NAT público para responder à soma do número de instâncias do Google Cloud e do número de As instâncias do Cloud Run implantadas no rede VPC do produtor de serviços.

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

Se você configurou um serviço ou job do Cloud Run com a sinalização --vpc-egress definida como private-ranges-only, o serviço ou job envia apenas para endereços IP internos. Você não precisa de um NAT público para rotear o tráfego para destinos internos.

Para impedir que serviços ou jobs do Cloud Run que defina a sinalização --vpc-egress como private-ranges-only para que ela não use uma NAT público gateway, faça o seguinte:

  • Configure o NAT público para outro gateway do Compute Engine 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. Defina 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 Cloud Monitoring:
  • Os registros do Cloud NAT para a saída de VPC direta não mostram o nome Serviço, revisão ou job do Cloud Run.

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

Interações de Testes de conectividade

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

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

Interações do Cloud Load Balancing

Balanceadores de carga de aplicativo internos regionais do Google Cloud e balanceadores de carga de aplicativo externos regionais se comunicam com vários back-ends de grupos de endpoints de rede (NEGs) regionais da Internet. Ao configurar gateways do Cloud NAT para a de NEGs da Internet regionais, é possível alocar o 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 é originado dos endereços IP do NAT que você aloca.

Outros balanceadores de carga e sistemas de verificação de integridade externos do Google Cloud se comunicam com as VMs usando rotas especiais. VMs de back-end não exigem endereços IP externo nem um gateway do Cloud NAT 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