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 em que os próximos saltos sejam o gateway de Internet padrão. Cada rede de nuvem privada virtual (VPC) começa com uma rota padrão com o destino 0.0.0.0/0 e com o gateway de Internet padrão como próximo salto. Para informações importantes, consulte a visão geral das rotas.

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

  • Se você criar uma rota estática com próximos saltos definidos como qualquer outro tipo de próximo salto de rota estática, 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ê usar instâncias de máquina virtual (VM) que executam um gateway NAT, firewall ou software proxy, crie rotas estáticas 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 as próprias VMs do próximo salto não podem usar gateways do Public NAT .

  • Se você criar uma rota estática personalizada cujo próximo salto seja um túnel do Cloud VPN, o Public NAT (,) e o Cloud NAT não usarão essa rota. Por exemplo, uma rota estática com destino de 0.0.0.0/0 e um túnel do Cloud VPN do 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 do Cloud 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 roteador local anunciar uma rota dinâmica para um Cloud Router que gerencia um túnel do Cloud VPN ou um anexo da VLAN, os gateways do Public NAT, do Cloud NAT e donão poderão usar essa rota. Por exemplo, se o roteador local anunciar uma rota dinâmica com destino 0.0.0.0/0, 0.0.0.0/0 será direcionado ao túnel do Cloud VPN ou ao 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.

O Private NAT usa as seguintes rotas:

  • Para os spokes do Network Connectivity Center, o Private NAT usa rotas de sub-rede e rotas dinâmicas:
    • Para o tráfego entre dois spokes de VPC anexados a um hub do NCC que contém apenas spokes de VPC, o Private NAT usa as rotas de sub-rede trocadas pelos spokes de VPC anexados. Para informações sobre spokes de VPC, consulte Visão geral dos spokes de VPC.
    • Se um hub do NCC tiver spokes de VPC e híbridos, como anexos da VLAN do Cloud Interconnect, túneis do Cloud VPN ou VMs de dispositivo roteador, o Private NAT usará as rotas dinâmicas aprendidas pelos spokes híbridos via BGP e as rotas de sub-rede trocadas pelos spokes de VPC anexados. Para informações sobre spokes híbridos, consulte Spokes híbridos.
  • Para o Hybrid NAT, o Private NAT usa rotas dinâmicas aprendidas pelo Cloud Router no Cloud Interconnect ou no Cloud VPN.

Interações com o Acesso privado do Google

Um gateway do Public NAT nunca realiza NAT para o tráfego enviado aos endereços IP externos selecionados para APIs e serviços do Google. Em vez disso, oGoogle Cloud ativa automaticamente o Acesso privado do Google para um intervalo de endereços IP de sub-rede quando você configura um gateway Public NAT para 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 gateway do Public NAT não muda a forma como o Acesso privado do Google funciona. Para mais informações, consulte Acesso privado do Google.

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

Interações 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ções 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 usando o peering de rede VPC, mesmo que as VMs em redes com peering estejam na mesma região que o gateway.

Interações do GKE

Um gateway do Public NAT pode realizar 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 a pelo menos os seguintes intervalos de endereços IP de sub-rede para a sub-rede que seu 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 a um cluster particular inteiro é configurar um gateway do Public NAT para aplicar a todos os intervalos de endereços IP de 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 gateway do 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 de 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 do Public NAT , o Google Kubernetes Engine realiza a conversão de endereços de rede de origem (NAT ou SNAT de origem) usando software em execução em cada node 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, o Public NAT também pode ser útil para clusters nativos de VPC que não sã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 gateway do Public NAT :

  • Para clusters nativos de VPC, o gateway do Public NAT é configurado para ser aplicado ao intervalo de endereços IP secundário para os 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 do Private NAT 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

Os gateways do Cloud NAT podem fornecer NAT para recursos do Cloud Run configurados com saída de VPC direta. Para permitir que o Cloud Run use um gateway do Cloud NAT para Public NAT ou Private NAT, configure o seguinte:

  • Ao implantar seus recursos do Cloud Run, defina a flag --vpc-egress. Se você quiser usar o Public NAT, o valor precisa ser definido como all-traffic.

  • Configure o gateway do Cloud NAT com as seguintes configurações:

    • Especifique quais intervalos de sub-rede de origem podem usar o gateway definindo a flag --nat-custom-subnet-ip-ranges. Defina o valor como os nomes das sub-redes em que você implanta os recursos do Cloud Run.
    • Defina o valor da sinalização --endpoint-types como ENDPOINT_TYPE_VM.

    • Para o Public NAT, verifique se o valor da flag --min-ports-per-vm está definido como duas vezes o número de portas necessárias para uma única instância do Cloud Run. Para o Private NAT, essa flag precisa ser definida como quatro vezes o número de portas necessárias por instância do Cloud Run.

    • Se você quiser configurar a alocação manual de endereços IP NAT (somente Public NAT), atribua ao gateway um número de endereços IP suficiente para cobrir a soma das instâncias de VM e do Cloud Run atendidas pelo gateway.

Os registros do Cloud NAT para saída de VPC direta não mostram os nomes dos recursos do Cloud Run.

Interações dos Testes de conectividade

É possível usar os Testes de conectividade para verificar a conectividade entre endpoints de rede que usam configurações do Cloud NAT. É possível executar os Testes de conectividade em redes que usam Public NAT gateways ou Private NAT gateways, ou ambos.

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

Interações do Cloud Load Balancing

OsGoogle Cloud balanceadores de carga de aplicativo internos regionais e os balanceadores de carga de aplicativo externos regionais se comunicam com vários back-ends de grupo de endpoints de rede (NEG) da Internet 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 originados dos endereços IP de NAT alocados.

Outros balanceadores de carga externos e sistemas de verificação de integridade se comunicam com VMs usando caminhos de roteamento especiais. Google Cloud 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.

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

Ao usar o Private NAT para NCC e as conexões propagadas do Private Service Connect no mesmo spoke de VPC, o seguinte se aplica:

  • Se uma sub-rede for configurada com Private NAT, o tráfego da sub-rede para conexões propagadas do Private Service Connect será descartado.

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

    • Especifique sub-redes sobrepostas usando a flag --nat-custom-subnet-ip-ranges.
    • Não especifique sub-redes não sobrepostas que precisam acessar conexões propagadas.
    • Não use a flag --nat-all-subnet-ip-ranges.

Interações com Hybrid Subnets

O Hybrid NAT não é compatível com as Hybrid Subnets.

Se o tráfego se originar de uma sub-rede em que o NAT híbrido está configurado e o endereço IP de destino corresponder a uma rota de sub-rede híbrida, a SNAT não será realizada. Essa configuração resulta em um comportamento de roteamento imprevisível porque o tráfego pode alcançar uma rede não VPC usando o endereço IP de origem original e não traduzido.

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

A seguir