Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Interações com o produto Cloud NAT

Esta página descreve as interações importantes entre o Cloud NAT e outros Cloud de Confiance by S3NS produtos.

Interações com trajetos

Um gateway de NAT na nuvem 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 da nuvem 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 Cloud NAT .
Se criar uma rota estática personalizada cujo próximo salto seja um túnel do Cloud VPN, o NAT da nuvem 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 na nuvem não podem usar essa rota. Da mesma forma, os gateways de NAT da nuvem 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 na nuvem 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.

Interações com o acesso privado do Google

Um gateway de NAT da nuvem 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 Cloud de Confiance ativa automaticamente o acesso privado à Google para um intervalo de endereços IP de sub-rede quando configura um gateway de NAT da nuvem 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 na nuvem não altera a forma como o Acesso privado do Google funciona. Para mais informações, consulte o artigo 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 na nuvem pode executar NAT para nós e pods num cluster privado, que é um tipo de cluster nativo da VPC. O gateway NAT da nuvem 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 da nuvem 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 da nuvem é 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 na nuvem , 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 da nuvem 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 da nuvem :

Para clusters nativos da VPC, o gateway NAT da nuvem 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 da nuvem com o GKE:

NAT público com o GKE. — NAT na nuvem 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.

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 conectividade em redes que usam gateways NAT da nuvem.

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

OsCloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance 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.