Solução de problemas de configuração
Este guia pode ajudar você a resolver problemas comuns com o Cloud NAT.
Problemas comuns
As VMs podem acessar a Internet de forma inesperada, sem o Cloud NAT
Se as instâncias de máquina virtual (VM, na sigla em inglês) ou as instâncias de contêiner conseguirem acessar a Internet sem o Cloud NAT, mas você não quiser que isso aconteça, verifique se há algum dos seguintes problemas:
Determine se a interface de rede da VM tem um endereço IP externo. Se a interface de rede tiver um endereço IP externo atribuído a ela, o Google Cloud executará automaticamente NAT individual para pacotes cujas origens correspondem ao endereço IP interno principal da interface. Para mais informações, consulte as especificações do Cloud NAT.
Para determinar se uma VM tem um endereço IP externo, consulte como alterar ou atribuir um endereço IP externo a uma instância existente.
Certifique-se de que seu cluster do Google Kubernetes Engine (GKE) seja um cluster particular. Cada VM de nó em um cluster não particular tem um endereço IP externo, de modo que cada nó pode usar rotas na sua rede de nuvem privada virtual (VPC, na sigla em inglês) cujo próximo salto é o gateway de Internet padrão sem depender do Cloud NAT. Para mais informações, incluindo a forma como os clusters não privados interagem com os gateways do Cloud NAT, consulte Interação do Compute Engine.
Liste rotas na sua rede de nuvem privada virtual procurando rotas que possam fornecer conexão de Internet por meio de um próximo salto diferente do gateway de Internet padrão. Por exemplo:
Rotas estáticas que tenham os próximos são VMs, balanceadores de carga de rede de passagem interna ou Cloud VPN e túneis podem fornecer conectividade com a Internet indiretamente. Por exemplo, as VMs do próximo salto ou VMs de back-end para um balanceador de carga de rede de passagem interno podem ter endereços IP externos ou um túnel Cloud VPN pode se conectar a uma rede que ofereça acesso à Internet.
Rotas dinâmicas aprendidas com por Cloud Routers na sua VPC ela pode se conectar a uma rede que ofereça acesso à Internet.
Lembre-se de que outras rotas personalizadas na sua rede VPC podem ter prioridades mais altas do que as rotas com os próximos saltos como gateway de Internet padrão. Para informações sobre como o Google Cloud avalia as rotas, consulte a aplicabilidade e a ordem do roteamento.
Nenhum registro é gerado
- Verifique se o log NAT está ativado.
Verifique se a visualização dos registros não está filtrando os registros que você está procurando. Para mais instruções, consulte Como ver registros.
Verifique se uma regra de firewall não está bloqueando o tráfego. As regras de firewall que bloqueiam o tráfego de saída são aplicadas antes de o tráfego ter sido enviado ao gateway NAT. Você pode usar registros de regras de firewall para ver se suas regras de saída personalizadas estão bloqueando o tráfego de saída.
Consulte Tipos de Cloud NAT. O destino do seu tráfego pode não ser processado por NAT.
Determinados registros são excluídos
Verifique se o registro de NAT está ativado e se seu filtro de registro não está excluindo os registros que você quer manter. Limpe um filtro de registros para que nada seja excluído.
O Cloud NAT não registra todos os eventos. Durante períodos de tráfego intenso de saída, o registro de NAT é regulado, proporcional ao tipo de máquina da VM. Os registros de tradução ou erro podem ser descartados e não é possível determinar o que foi omitido durante a limitação.
Pacotes descartados por causa do motivo "out of resources [sem recursos]"
Se você vir a perda de pacotes de VMs que usam o Cloud NAT, talvez seja porque não há endereços IP de origem NAT suficientes e tuplas de porta de origem para que a VM use no momento da perda do pacote. (exaustão da porta) Não é possível reutilizar uma tupla quíntupla (endereço IP de origem NAT, porta de origem e tupla tripla de destino) dentro do tempo limite TCP TIME_WAIT.
Se não houver tuplas NAT suficientes, o motivo dropped_sent_packets_count
será OUT_OF_RESOURCES
. Para mais informações sobre métricas, consulte
Como usar métricas de instâncias de VM.
Veja como reduzir o uso da porta em Reduzir o uso da porta.
Se você usa a alocação de porta dinâmica, consulte a seção a seguir para saber como reduzir as quedas de pacotes quando a alocação de porta dinâmica for usada.
Pacotes descartados quando a alocação de porta dinâmica está configurada
A alocação dinâmica de portas detecta quando uma VM está perto de estar sem portas e dobra o número de portas alocadas para ela. Isso ajuda garantem que as portas não sejam desperdiçadas, mas que podem resultar na queda de pacotes de portas alocadas está aumentando.
Para reduzir o número de pacotes descartados, considere o seguinte:
Se você puder ampliar as conexões mais lentamente, o Cloud NAT terá mais tempo para alocar mais portas.
Se as VMs fazem conexões TCP, é possível configurá-las com um endereço Valor de
tcp_syn_retries
, o que dá ao sistema mais tempo para estabelecer a conexão e aumenta as chances de sucesso da conexão.Por exemplo, para VMs do Linux, é possível ver a configuração atual usando:
sysctl net.ipv4.tcp_syn_retries
Se necessário, aumente a configuração usando:
sudo sysctl -w net.ipv4.tcp_syn_retries=NUM
Se você tiver cargas de trabalho com bursts e precisar alocar rapidamente mais portas, talvez seja necessário ajustar o número mínimo de portas por VM. Veja o uso da porta e determina o número mínimo adequado de portas por VM.
Pacotes descartados com razão: conflito independente de endpoint
Se você perceber a perda de pacotes de VMs que usam o Public NAT e tiver
o mapeamento independente de endpoint estiver ativado, a perda de pacotes pode ser causada por um
independente de endpoint
conflitos. Em caso afirmativo, o motivo de dropped_sent_packets_count
é ENDPOINT_INDEPENDENT_CONFLICT
. Para mais informações sobre métricas, consulte
Como usar métricas de instâncias de VM.
Reduza as chances de conflitos independentes de endpoint usando as seguintes técnicas:
Desative o mapeamento independente de endpoint. Isso permite que a nova conexão a partir de um determinado endereço IP e porta de origem use uma porta e um endereço IP de origem de NAT diferentes dos usados anteriormente. A desativação ou a ativação do mapeamento independente de endpoint não interrompe as conexões estabelecidas.
Aumente o número mínimo padrão de portas NAT por instância de VM para que o procedimento de reserva de porta possa atribuir mais IP de origem NAT e tuplas de porta de origem para cada VM cliente. Isso diminui a probabilidade de dois ou mais endereços IP de cliente e tuplas de porta de origem temporária receberem o mesmo endereço IP de origem NAT e tupla de porta de origem.
Verifique quantas portas de origem temporárias estão sendo usadas:
Para VMs do Linux:
netstat -an | egrep 'ESTABLISHED|TIME_WAIT|CLOSE_WAIT' | wc -l
Para VMs do Windows:
netstat -tan | findstr "ESTABLISHED TIME_WAIT CLOSE_WAIT" | find /c /v ""
Configure as instâncias de VM para usar um conjunto maior de portas de origem temporárias:
Para VMs do Linux:
Veja qual intervalo de portas está configurado com este comando:
cat /proc/sys/net/ipv4/ip_local_port_range
É possível definir
ip_local_port_range
como o número máximo de portas de origem temporárias (64.512) com este comando:echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
Para VMs do Windows:
Você pode ver quais intervalos de portas estão configurados com estes comandos:
netsh int ipv4 show dynamicport tcp netsh int ipv4 show dynamicport udp
É possível definir o número de portas TCP e UDP de origem temporária como o máximo possível (64.512) com estes comandos:
netsh int ipv4 set dynamicport tcp start=1024 num=64512 netsh int ipv4 set dynamicport udp start=1024 num=64512
Nos nós do Google Kubernetes Engine, é possível automatizar essa configuração usando um
DaemonSet
com privilégios.
Para clusters do GKE, desative o NAT de origem executado em cada nó para pacotes enviados a destinos de interesse. Isso pode ser feito de duas maneiras:
Ao implantar o
ip-masq-agent
e adicionar os destinos de interesse à lista denonMasqueradeCIDRs
.Ao desativar o SNAT para destinos não mascarados padrão com a sinalização
--disable-default-snat
ao criar um cluster.
Pacotes recebidos descartados
Um gateway do Cloud NAT mantém uma tabela de rastreamento de conexão para armazenar detalhes da conexão e mapeamentos de endereços IP e portas. Como endereços IP e portas da VM converter em endereços IP NAT e portas. Um gateway do Cloud NAT descarta uma entrada pacote de dados se a tabela de rastreamento de conexão não que contêm qualquer entrada para a conexão.
A ausência da entrada de conexão na tabela pode ocorrer devido ao seguinte: motivos:
- Uma conexão TCP estabelecida expirou porque a conexão TCP estabelecida O tempo limite de inatividade expirou devido à inatividade.
- Um endpoint externo falha ao estabelecer uma nova conexão antes da transição TCP transitória
O tempo limite de inatividade da conexão expirou. Por exemplo, um recurso do Google Cloud
inicia uma conexão com
TCP SYN
, mas o endpoint externo não responde com umSYN ACK
. - Um endpoint externo, como uma sonda, tenta se conectar a um endereço IP NAT e porta. O Cloud NAT não aceita conexões de entrada não solicitadas. Entradas para esse tipo de conexão não estarão presentes na tabela de conexões. Assim, todos os pacotes recebidos serão descartados.
- Se você remover IPs NAT de seu gateway enquanto conexões NAT ainda estiverem ativas, os mapeamentos NAT se tornam inválidos e essas conexões são imediatamente removido da tabela de rastreamento de conexão, qualquer tráfego de retorno é descartado.
Antes de resolver as quedas do pacote de entrada, confirme se elas realmente afetam seu aplicativo. Para confirmar, verifique se há erros no aplicativo quando houver picos em pacotes de entrada descartados.
Se as quedas do pacote de entrada afetarem seu aplicativo, tente usar o seguinte: técnicas para resolver o problema:
- Use mecanismos de sinal de atividade no aplicativo para que conexões de longa duração pode ficar aberta por mais tempo.
- Aumente o valor do Tempo limite de inatividade da conexão transitória TCP para que Endpoints externos que recebem tráfego (iniciados pelos recursos do Google Cloud) por um gateway do Cloud NAT têm mais tempo para responder e estabelecer a conexão.
- Aumente o valor do Tempo limite de inatividade da conexão estabelecida TCP se você tiver diminuiu significativamente o valor padrão.
É necessário alocar mais endereços IP
Às vezes, as VMs não conseguem se conectar à Internet porque você não tem endereços IP NAT suficientes. Vários fatores podem causar esse problema. Para mais informações, veja a tabela a seguir:
Causa principal | Sintoma | Solução |
---|---|---|
Você alocou manualmente os endereços, mas não o suficiente, de acordo com o uso atual da porta. |
|
Escolha uma destas opções:
|
Você ultrapassou um limite rígido de endereços IP NAT. |
|
|
Para monitorar falhas causadas por um número insuficiente de endereços IP,
crie um alerta para a
métrica
nat_allocation_failed
. Essa métrica será definida como true
se o Google Cloud não puder
alocar endereços IP suficientes para qualquer VM no gateway NAT. Para
informações sobre políticas de alertas, consulte
Como definir políticas de alertas.
Reduzir o uso da porta
É possível minimizar o número de portas que cada VM usa quando a alocação de mais endereços IP NAT não é possível ou desejável.
Para reduzir o uso da porta, siga estas etapas:
Desative o mapeamento independente de endpoint.
Ative a alocação de porta dinâmica. Para usar a alocação de porta dinâmica, defina um número mínimo de portas por VM e um número máximo de portas por VM. O Cloud NAT aloca automaticamente vários endereços IP de origem NAT e tuplas de portas de origem entre o número mínimo e o número máximo de portas, que também estão inclusos. O uso de um número baixo para o mínimo de portas reduz o desperdício de endereço IP de origem NAT e tuplas de portas de origem em VMs com menos conexões ativas. Se você atingir o tempo limite de conexão enquanto as portas estiverem sendo alocadas, consulte Reduzir a queda de pacotes com a alocação de portas dinâmicas.
Determine o menor número mínimo possível de portas para atender às suas necessidades. Há vários métodos para fazer isso, e a maioria depende da revisão do número de portas usadas (
compute.googleapis.com/nat/port_usage
) como ponto de partida para o processo de tomada de decisão. Para informações sobre como encontrar o uso da porta, consulte Ver uso da porta. Veja a seguir dois métodos de exemplo para determinar um número mínimo de portas:- Considere o valor médio de
compute.googleapis.com/nat/port_usage
durante um período representativo para um número representativo de VMs. - Considere o valor mais comum de
compute.googleapis.com/nat/port_usage
durante um período representativo para um número representativo de VMs.
- Considere o valor médio de
Determine o menor número máximo possível de portas para atender às suas necessidades. Mais uma vez, revise
compute.googleapis.com/nat/port_usage
como ponto de partida para seu processo de tomada de decisão. Considere o valor máximo decompute.googleapis.com/nat/port_usage
durante um período representativo para um número representativo de VMs como um ponto de partida para o número máximo de portas. Lembre-se de que definir o número máximo muito alto pode impedir que outras VMs recebam endereços IP de origem NAT e tuplas de porta de origem.Encontrar os valores certos para as portas mínima e máxima envolve o teste iterativo. Veja como alterar os números mínimo e máximo de portas em Alterar as portas mínima ou máxima da configuração da alocação dinâmica de portas.
Revise os tempos limite da NAT, bem como os significados e valores padrão deles. Se você precisar criar rapidamente uma série de conexões TCP para a mesma tupla tripla de destinos, considere reduzir o tempo de espera do TCP para que o Cloud NAT possa reutilizar o endereço IP de origem NAT e as tuplas de porta de origem mais rapidamente. Isso permite que o Cloud NAT use mais rapidamente a mesma tupla quíntupla, em vez de precisar usar uma tupla quíntupla exclusiva, o que pode exigir a alocação de outros endereços IP de origem NAT e tuplas de porta de origem para cada VM de envio. Para ver as etapas para alterar os tempos limite do NAT, consulte Altere os tempos limite do NAT.
Perguntas frequentes
Restrição regional para o Cloud NAT
Posso usar o mesmo gateway do Cloud NAT em mais de uma região?
Não. Um gateway do Cloud NAT não pode ser associado a mais de uma região, rede VPC ou Cloud Router.
Se você precisar fornecer conectividade para outras regiões ou redes VPC, crie gateways do Cloud NAT adicionais para elas.
Os endereços IP NAT externos são usados por gateways do Cloud NAT globais ou regionais?
Os gateways do Cloud NAT usam endereços IP externos regionais como endereços IP NAT. Mesmo que sejam regionais, eles são roteáveis publicamente. Para informações sobre as diferentes maneiras de alocar ou atribuir endereços IP NAT, consulte Endereços IP NAT.
Quando o Cloud NAT pode e não pode ser usado
O Cloud NAT é aplicável a instâncias, incluindo VMs de nó do GKE, que têm endereços IP externos?
Geralmente não. Se a interface de rede de uma VM tiver um endereço IP externo, o Google Cloud sempre realizará NAT um para um para pacotes enviados do endereço IP interno principal da interface de rede sem usar o Cloud NAT. No entanto, um Cloud NAT ainda pode fornecer serviços NAT para pacotes enviados de intervalos de endereços IP do alias da mesma interface de rede. Para mais detalhes, consulte Especificações do Cloud NAT e Interação do Compute Engine.
O NAT público permite que uma VM de origem com uma interface de rede sem um endereço IP externo envie tráfego para uma VM de destino ou balanceador de carga que tenha um endereço IP externo, mesmo quando a origem e o destino estiverem na mesma rede VPC?
Sim. O caminho da rede envolve o envio de tráfego para fora da rede VPC por meio de um gateway de Internet padrão e, em seguida, no recebimento da mesma rede.
Quando a VM de origem envia um pacote para o destino, o Public NAT realiza NAT de origem (SNAT) antes de entregar o pacote à segunda instância. O NAT público executa o NAT de destino (DNAT) para as respostas do segundo instância para a primeira. Para ver um exemplo detalhado, consulte Configuração e fluxo de trabalho do NAT público básico.
Posso usar o Private NAT para a comunicação entre VMs na mesma rede VPC?
Não, o Private NAT não executa NAT no tráfego entre VMs na mesma rede VPC do produtor de serviços.
Conexões recebidas não solicitadas não são aceitas
O Cloud NAT permite conexões de entrada (por exemplo, SSH) para instâncias sem endereços IP externos?
Não, o Cloud NAT não aceita conexões de entrada não solicitadas.
Para mais informações, consulte as
especificações do Cloud NAT.
No entanto, a borda da rede do Google Cloud pode responder a pings
é um endereço IP externo de gateway do Cloud NAT
tem mapeamentos de porta ativos para pelo menos uma instância de VM. Para acessar endereços IP
atribuído a um gateway do Cloud NAT, use
gcloud compute Routers get-nat-ip-info:
Os endereços IP externos marcados como IN_USE
podem responder a pings.
Se você precisar se conectar a uma VM que não tenha um endereço IP externo, consulte Escolher uma opção de conexão para VMs somente internas. Por exemplo, como parte da configuração do Compute Engine de exemplo do Cloud NAT, você se conecta a uma VM sem um endereço IP externo usando o Identity-Aware Proxy.
Cloud NAT e portas
Por que uma VM tem um número fixo de portas (64
por padrão)?
Quando um gateway do Cloud NAT fornece NAT para uma VM, ele reserva o endereço de origem e as tuplas de origem de acordo com o procedimento de reserva de porta.
Para mais informações, consulte exemplos de reserva de portas.
Posso alterar o número mínimo de portas reservadas para uma VM?
Sim. Você pode aumentar ou diminuir o número mínimo de portas por VM ao criar um novo gateway do Cloud NAT ou editá-lo posteriormente. Cada gateway do Cloud NAT reserva as tuplas de endereço de origem e de origem de acordo com o procedimento de reserva de porta.
Para mais informações sobre como diminuir o número mínimo de portas, consulte a próxima pergunta.
Posso diminuir o número mínimo de portas por VM depois de criar o gateway do Cloud NAT?
Sim No entanto, diminuir o número mínimo de portas pode resultar no procedimento de reserva de portas reservar um número menor de portas por VM. Quando isso acontece, as conexões TCP existentes podem ser redefinidas e, em caso afirmativo, precisam ser restabelecidas.
Ao alternar o mapeamento NAT de intervalos primários e secundários para apenas o intervalo primário, as outras portas alocadas a cada instância são liberadas imediatamente?
Não. Todas as portas adicionais usadas por intervalos secundários são mantidas pelas instâncias até que a configuração de portas mínimas por VM seja reduzida. Quando o Cloud NAT é configurado para mapear intervalos secundários (alias) para sub-redes, o Cloud NAT atribui um mínimo de 1.024 portas por instância, com base no procedimento de reserva de porta.
Ao alternar para intervalos primários, o Cloud NAT preserva as portas alocadas adicionais para instâncias que já tiveram essas portas atribuídas. Depois de mudar os intervalos em que o Cloud NAT é aplicado apenas ao primário, o número real de portas atribuídas a essas instâncias não é alterado até que a configuração de portas mínimas por VM também seja reduzida.
Para reduzir a quantidade de portas alocadas a essas instâncias, após alternar para os intervalos primários, a configuração de portas mínimas por VM precisa ser reduzida. Depois que esse valor for reduzido, o Cloud NAT ajustará automaticamente o número de portas alocadas por instância, o que reduz o consumo de portas.
Cloud NAT e outros serviços do Google
O Cloud NAT permite o acesso a APIs e serviços do Google?
Quando você ativa o Cloud NAT no intervalo de IP principal de uma sub-rede, o Google Cloud ativa automaticamente o Acesso privado do Google. Para mais informações, consulte Interação com o Acesso privado do Google.