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 personalizadas cujos próximos saltos são VMs, balanceadores de carga de rede de passagem internos ou túneis do Cloud VPN podem fornecer indiretamente conectividade com a Internet. 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.

    • Traçados dinâmicos personalizados aprendidos em redes locais por roteadores de nuvem na sua VPC podem se conectar a uma rede que oferece 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 tráfego pode não ser tratado pelo 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 a garantir que as portas não sejam desperdiçadas, mas pode resultar em pacotes descartados enquanto o número de portas alocadas aumenta.

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 estiverem fazendo conexões TCP, será possível configurá-las com um valor maior para tcp_syn_retries, o que dá ao sistema mais tempo para estabelecer a conexão e aumenta as chances de êxito 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ê vir perda de pacotes de VMs que usam NAT pública e tiver o mapeamento independente de endpoint ativado, a perda de pacotes poderá ser causada por um conflito independente de endpoint. 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:

É 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.
  • O console do Google Cloud mostra um erro com a mensagem: Você precisa alocar pelo menos mais 'X' endereços IP para permitir que todas as instâncias acessem a Internet.
  • O valor da métrica nat_allocation_failed é true.

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:

  1. Desative o mapeamento independente de endpoint.

  2. 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.

  3. 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.

  4. 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 de compute.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.

  5. 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.

  6. 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 de NAT, consulte Alterar tempos limite de 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.

Posso usar o Cloud NAT para comunicação entre VMs em uma rede VPC?

Não, o Cloud NAT foi projetado para fornecer conectividade apenas com a Internet.

Posso usar o Cloud NAT para conectar uma rede VPC a outra rede para resolver endereços IP sobrepostos?

Não, o Cloud NAT não pode ser aplicado a qualquer rota personalizada cujo próximo salto não seja o gateway de Internet padrão. Por exemplo, o Cloud NAT não pode ser aplicado ao tráfego enviado para um túnel Cloud VPN do próximo salto, mesmo se o destino for um endereço IP roteável publicamente.

O Cloud NAT permite que uma VM de origem com 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 Cloud NAT realiza NAT de origem (SNAT) antes de entregar o pacote à segunda instância. O Cloud NAT realiza o NAT de destino (DNAT) das respostas da segunda instância para a primeira. Para um exemplo detalhado, consulte Configuração e fluxo de trabalho de NAT pública básica.

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.

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.

A seguir