Partilhar via

Solucionar problemas de conectividade do Gateway NAT do Azure

  • Artigo

Este artigo fornece orientação sobre como solucionar e resolver problemas comuns de conectividade de saída com seu gateway NAT. Este artigo também fornece práticas recomendadas sobre como projetar aplicativos para usar conexões de saída de forma eficiente.

Queda na disponibilidade do caminho de dados no gateway NAT com falhas de conexão

Cenário

Você observa uma queda na disponibilidade do caminho de dados do gateway NAT, que coincide com falhas de conexão.

Causas possíveis

  • Exaustão da porta SNAT (Source Network Address Translation).

  • Limites de conexão SNAT simultâneos.

  • Tempos limite de conexão.

Solucionar problemas de etapas

  • Avalie a integridade do gateway NAT verificando a métrica de disponibilidade do caminho de dados.

  • Verifique a métrica Contagem de Conexões SNAT e divida o estado da conexão por conexões tentadas e com falha. Mais de zero conexões com falha indicam exaustão da porta SNAT ou atingindo o limite de contagem de conexões SNAT do gateway NAT.

  • Verifique se a métrica de contagem de conexões está dentro dos limites verificando a métrica Contagem total de conexões SNAT. O gateway NAT suporta 50.000 conexões simultâneas por endereço IP para um destino único e até 2 milhões de conexões no total. Para obter mais informações, consulte Desempenho do gateway NAT.

  • Verifique a métrica de pacotes descartados para quaisquer quedas de pacotes que se alinhem com falhas de conexão ou alto volume de conexão.

  • Ajuste as configurações de tempo limite ocioso do TCP (Transmission Control Protocol) conforme necessário. Um temporizador de tempo limite ocioso definido acima do padrão (4 minutos) mantém os fluxos por mais tempo e pode criar pressão extra no inventário de portas SNAT.

Soluções possíveis para exaustão da porta SNAT ou atingir limites de conexão simultâneos

  • Adicione endereços IP públicos ao seu gateway NAT até um total de 16 para dimensionar sua conectividade de saída. Cada IP público fornece 64.512 portas SNAT e suporta até 50.000 conexões simultâneas por ponto de extremidade de destino exclusivo para gateway NAT.

  • Distribua seu ambiente de aplicativo em várias sub-redes e forneça um recurso de gateway NAT para cada sub-rede.

  • Libere o inventário de portas SNAT reduzindo o temporizador de tempo limite ocioso TCP para um valor mais baixo. O temporizador de tempo limite de inatividade TCP não pode ser definido abaixo de 4 minutos.

  • Considere padrões de sondagem assíncronos para liberar recursos de conexão para outras operações.

  • Faça conexões com serviços PaaS do Azure no backbone do Azure usando o Private Link. Link privado libera portas SNAT para conexões de saída para a Internet.

  • Se a sua investigação for inconclusiva, abra um caso de suporte para solucionar problemas adicionais.

Nota

É importante entender por que ocorre a exaustão da porta SNAT. Certifique-se de usar os padrões certos para cenários escaláveis e confiáveis. Adicionar mais portas SNAT a um cenário sem entender a causa da demanda deve ser um último recurso. Se você não entender por que seu cenário está pressionando o inventário de portas SNAT, adicionar mais portas SNAT adicionando mais endereços IP só atrasará a mesma falha de exaustão que seu aplicativo é dimensionado. Você pode estar mascarando outras ineficiências e anti-padrões. Para obter mais informações, consulte as práticas recomendadas para o uso eficiente de conexões de saída.

Soluções possíveis para tempos limite de conexão TCP

Use keepalives TCP ou keepalives da camada de aplicativo para atualizar fluxos ociosos e redefinir o temporizador de tempo limite ocioso. Para obter exemplos, consulte Exemplos do .NET.

Os keepalives TCP só precisam ser habilitados de um lado de uma conexão para manter uma conexão viva de ambos os lados. Quando um keepalive TCP é enviado de um lado de uma conexão, o outro lado envia automaticamente um pacote de confirmação (ACK). O temporizador de tempo limite ocioso é então redefinido em ambos os lados da conexão.

Nota

Aumentar o tempo limite de inatividade do TCP é um último recurso e pode não resolver a causa raiz do problema. Um tempo limite longo pode introduzir atraso e causar falhas desnecessárias de baixa taxa quando o tempo limite expira.

Soluções possíveis para tempos limite de conexão UDP (User Datagram Protocol)

Os temporizadores de tempo limite ocioso UDP são definidos para 4 minutos e não são configuráveis. Habilite keepalives UDP para ambas as direções em um fluxo de conexão para manter conexões longas. Quando um keepalive UDP está habilitado, ele fica ativo apenas para uma direção em uma conexão. A conexão ainda pode ficar ociosa e atingir o tempo limite do outro lado de uma conexão. Para evitar que uma conexão UDP atinja o tempo limite, os keepalives UDP devem ser habilitados para ambas as direções em um fluxo de conexão.

Os keepalives da camada de aplicativo também podem ser usados para atualizar fluxos ociosos e redefinir o tempo limite ocioso. Verifique no lado do servidor quais opções existem para keepalives específicos do aplicativo.

Queda na disponibilidade do caminho de dados no gateway NAT, mas sem falhas de conexão

Cenário

A disponibilidade do caminho de dados do gateway NAT cai, mas nenhuma conexão com falha é observada.

Causa possível

Queda transitória na disponibilidade do caminho de dados causada por ruído no caminho de dados.

Passos de resolução de problemas

Se você notar uma queda na disponibilidade do caminho de dados sem qualquer efeito na conectividade de saída, isso pode ser devido ao gateway NAT captar ruído transitório no caminho de dados.

Configure um alerta para quedas de disponibilidade do caminho de dados ou use a Integridade dos Recursos do Azure para alertar sobre eventos de integridade do Gateway NAT.

Sem conectividade de saída à Internet

Cenário

Você não observa nenhuma conectividade de saída em seu gateway NAT.

Causas possíveis

  • Configuração incorreta do gateway NAT.

  • O tráfego da Internet é redirecionado para longe do gateway NAT e encapsulado à força para um dispositivo virtual ou para um destino local com uma VPN ou Rota Expressa.

  • As regras do NSG (Grupo de Segurança de Rede) são configuradas para bloquear o tráfego da Internet.

  • A disponibilidade do caminho de dados do gateway NAT está degradada.

  • Configuração incorreta do Sistema de Nomes de Domínio (DNS).

Passos de resolução de problemas

  • Verifique se o gateway NAT está configurado com pelo menos um endereço IP público ou prefixo e conectado a uma sub-rede. O gateway NAT não estará operacional até que um IP público e uma sub-rede sejam anexados. Para obter mais informações, consulte Noções básicas de configuração do gateway NAT.

  • Verifique a tabela de roteamento da sub-rede conectada ao gateway NAT. Qualquer tráfego 0.0.0.0/0 que esteja sendo encapsulado à força para um Network Virtual Appliance (NVA), ExpressRoute ou VPN Gateway terá prioridade sobre o gateway NAT. Para obter mais informações, consulte como o Azure seleciona uma rota.

  • Verifique se há alguma regra NSG configurada para a interface de rede em sua máquina virtual que bloqueie o acesso à Internet.

  • Verifique se a disponibilidade do caminho de dados do gateway NAT está em um estado degradado. Consulte as diretrizes de solução de problemas de falha de conexão se o gateway NAT estiver em um estado degradado.

  • Verifique as configurações de DNS se o DNS não estiver resolvendo corretamente.

Soluções possíveis para perda de conectividade de saída

O IP público do gateway NAT não é usado para conectar a saída

Cenário

O gateway NAT é implantado em sua rede virtual do Azure, mas endereços IP inesperados são usados para conexões de saída.

Causas possíveis

  • Configuração incorreta do gateway NAT.

  • Conexão ativa com outro método de conectividade de saída do Azure, como o balanceador de carga do Azure ou IPs públicos no nível da instância em máquinas virtuais. Os fluxos de conexão ativos continuam a usar o endereço IP público anterior atribuído quando a conexão foi estabelecida. Quando o gateway NAT é implantado, novas conexões começam a usar o gateway NAT imediatamente.

  • Os IPs privados são usados para se conectar aos serviços do Azure por pontos de extremidade de serviço ou Link Privado.

  • As conexões com contas de armazenamento vêm da mesma região da máquina virtual a partir da qual você está fazendo uma conexão.

  • O tráfego da Internet está sendo redirecionado para longe do gateway NAT e encapsulado à força para um NVA ou firewall.

Como solucionar problemas

  • Verifique se o gateway NAT tem pelo menos um endereço IP público ou prefixo associado e pelo menos uma sub-rede.

  • Verifique se algum método de conectividade de saída anterior, como um balanceador de carga público, ainda está ativo após a implantação do gateway NAT.

  • Verifique se as conexões que estão sendo feitas com outros serviços do Azure estão vindo de um endereço IP privado em sua rede virtual do Azure.

  • Verifique se você tem o Link Privado ou pontos de extremidade de serviço habilitados para se conectar a outros serviços do Azure.

  • Verifique se sua máquina virtual está localizada na mesma região que o armazenamento do Azure ao fazer uma conexão de armazenamento.

  • Verifique se o endereço IP público usado para conexões é originário de outro serviço do Azure em sua rede virtual do Azure, como um Network Virtual Appliance (NVA).

Possíveis soluções para IP público de gateway NAT não usado para conectar saída

  • Anexe um endereço IP público ou prefixo ao gateway NAT. Verifique se o gateway NAT está conectado a sub-redes da mesma rede virtual. Valide se o gateway NAT pode se conectar de saída.

  • Teste e resolva problemas com VMs que mantêm endereços IP SNAT antigos de outro método de conectividade de saída:

    • Certifique-se de estabelecer uma nova conexão e de que as conexões existentes não estão sendo reutilizadas no sistema operacional ou se o navegador está armazenando as conexões em cache. Por exemplo, ao usar curl no PowerShell, certifique-se de especificar o parâmetro -DisableKeepalive para forçar uma nova conexão. Se você estiver usando um navegador, as conexões também podem ser agrupadas.

    • Não é necessário reinicializar uma máquina virtual em uma sub-rede configurada para gateway NAT. No entanto, se uma máquina virtual for reinicializada, o estado da conexão será liberado. Quando o estado da conexão é liberado, todas as conexões começam a usar o endereço IP ou endereços do recurso de gateway NAT. Esse comportamento é um efeito colateral da reinicialização da máquina virtual e não um indicador de que uma reinicialização é necessária.

    • Se você ainda estiver tendo problemas, abra um caso de suporte para solução de problemas adicionais.

  • As rotas personalizadas que direcionam o tráfego 0.0.0.0/0 para um NVA terão precedência sobre o gateway NAT para rotear o tráfego para a Internet. Para que o tráfego de roteio do gateway NAT para a Internet em vez do NVA, remova a rota personalizada para o tráfego 0.0.0.0/0 indo para o dispositivo virtual. O tráfego 0.0.0.0/0 é retomado usando a rota padrão para a Internet e o gateway NAT é usado.

Importante

Antes de fazer qualquer alteração na forma como o tráfego é roteado, considere cuidadosamente os requisitos de roteamento da sua arquitetura de nuvem.

  • Os serviços implantados na mesma região que uma conta de armazenamento do Azure usam endereços IP privados do Azure para comunicação. Não é possível restringir o acesso a serviços específicos do Azure com base no intervalo de endereços IP de saída públicos. Para obter mais informações, consulte restrições para regras de rede IP.
  • Link privado e pontos de extremidade de serviço usam os endereços IP privados de instâncias de máquina virtual em sua rede virtual para se conectar aos serviços da plataforma Azure em vez do IP público do gateway NAT. Use o Private Link para se conectar a outros serviços do Azure pelo backbone do Azure em vez de pela Internet com o gateway NAT.

Nota

Private Link é a opção recomendada sobre Pontos de extremidade de serviço para acesso privado aos serviços hospedados do Azure.

Falhas de conexão no destino público da Internet

Cenário

As conexões de gateway NAT para destinos da Internet falham ou expiram.

Causas possíveis

  • Firewall ou outros componentes de gerenciamento de tráfego no destino.

  • Limitação da taxa API imposta pelo lado do destino.

  • Mitigações volumétricas de DDoS ou modelagem de tráfego da camada de transporte.

  • O ponto de extremidade de destino responde com pacotes fragmentados.

Como solucionar problemas

  • Valide a conectividade com um ponto de extremidade na mesma região ou em outro lugar para comparação.

  • Conduza a captura de pacotes dos lados de origem e destino.

  • Observe a contagem de pacotes na origem e no destino (se disponível) para determinar quantas tentativas de conexão foram feitas.

  • Observe os pacotes descartados para ver quantos pacotes foram descartados pelo gateway NAT.

  • Analise os pacotes. Pacotes TCP com pacotes de protocolo IP fragmentados indicam fragmentação IP. O gateway NAT não suporta fragmentação IP e, portanto, as conexões com pacotes fragmentados falham.

  • Certifique-se de que o IP público do gateway NAT esteja listado como permitido em destinos parceiros com firewalls ou outros componentes de gerenciamento de tráfego.

Possíveis soluções para falhas de conexão no destino da internet

  • Verifique se o IP público do gateway NAT está listado como permitido no destino.

  • Se você estiver criando testes de alto volume ou taxa de transação, explore se a redução da taxa reduz a ocorrência de falhas.

  • Se a redução da taxa de conexões diminuir a ocorrência de falhas, verifique se o destino atingiu seus limites de taxa de API ou outras restrições.

Falhas de conexão no servidor FTP para o modo ativo ou passivo

Cenário

Você vê falhas de conexão em um servidor FTP ao usar o gateway NAT com o modo FTP ativo ou passivo.

Causas possíveis

  • O modo FTP ativo está ativado.

  • O modo FTP passivo está habilitado e o gateway NAT está usando mais de um endereço IP público.

Possível solução para o modo FTP ativo

FTP usa dois canais separados entre um cliente e servidor, o comando e canais de dados. Cada canal se comunica em conexões TCP separadas, uma para enviar os comandos e outra para transferir dados.

No modo FTP ativo, o cliente estabelece o canal de comando e o servidor estabelece o canal de dados.

O gateway NAT não é compatível com o modo FTP ativo. O FTP ativo usa um comando PORT do cliente FTP que informa ao servidor FTP qual endereço IP e porta para o servidor usar no canal de dados para se conectar novamente ao cliente. O comando PORT usa o endereço privado do cliente, que não pode ser alterado. O tráfego do lado do cliente é SNATed pelo gateway NAT para comunicação baseada na Internet, portanto, o comando PORT é visto como inválido pelo servidor FTP.

Uma solução alternativa ao modo FTP ativo é usar o modo FTP passivo em vez disso. No entanto, para usar o gateway NAT no modo FTP passivo, algumas considerações devem ser feitas.

Solução possível para o modo FTP passivo

No modo FTP passivo, o cliente estabelece conexões nos canais de comando e dados. O cliente solicita que o servidor responda em uma porta em vez de tentar estabelecer uma conexão de volta ao cliente.

O FTP passivo de saída não funciona para gateway NAT com vários endereços IP públicos, dependendo da configuração do seu servidor FTP. Quando um gateway NAT com vários endereços IP públicos envia tráfego de saída, ele seleciona aleatoriamente um de seus endereços IP públicos para o endereço IP de origem. FTP falha quando os dados e canais de controle usam endereços IP de origem diferentes, dependendo da configuração do seu servidor FTP.

Para evitar possíveis falhas de conexão FTP passiva, execute as seguintes etapas:

  1. Verifique se o seu gateway de NAT está anexado a um único endereço IP público em vez de a vários endereços IP ou prefixo.

  2. Certifique-se de que o intervalo de portas passivas do gateway NAT tenha permissão para passar quaisquer firewalls no ponto de extremidade de destino.

Nota

Reduzir a quantidade de endereços IP públicos em seu gateway NAT reduz o inventário de porta SNAT disponível para fazer conexões de saída e pode aumentar o risco de esgotamento da porta SNAT. Considere suas necessidades de conectividade SNAT antes de remover endereços IP públicos do gateway NAT. Não é recomendável alterar as configurações do servidor FTP para aceitar o tráfego de controle e plano de dados de endereços IP de origem diferentes.

As conexões de saída na porta 25 estão bloqueadas

Cenário

Não é possível conectar a saída com o gateway NAT na porta 25 para tráfego SMTP (Simple Mail Transfer Protocol).

Motivo

A plataforma Azure bloqueia conexões SMTP de saída na porta TCP 25 para VMs implantadas. Este bloco destina-se a garantir uma melhor segurança para os parceiros e clientes da Microsoft, proteger a plataforma Azure da Microsoft e estar em conformidade com os padrões da indústria.

Use um serviço de retransmissão SMTP autenticado para enviar emails de VMs do Azure ou do Serviço de Aplicativo do Azure. Para obter mais informações, consulte solucionar problemas de conectividade SMTP de saída.

Mais documentação de orientação para a resolução de problemas

Capturas de rede extras

Se a investigação for inconclusiva, abra um pedido de suporte para resolução de problemas e recolha as informações seguintes para uma resolução mais rápida. Escolha uma única máquina virtual na sub-rede configurada do gateway NAT e execute os seguintes testes:

  • Teste a resposta da porta de teste usando ps ping uma das VMs de back-end dentro da rede virtual e registre os resultados (exemplo: ps ping 10.0.0.4:3389).

  • Se nenhuma resposta for recebida nesses testes de ping, execute um rastreamento simultâneo netsh na máquina virtual de back-end e a máquina virtual de teste de rede virtual enquanto você executa o PsPing e, em seguida, pare o netsh rastreamento.

Práticas recomendadas de conectividade de saída

O Azure monitora e opera sua infraestrutura com muito cuidado. No entanto, falhas transitórias ainda podem ocorrer a partir de aplicativos implantados, e não há garantia de transmissões sem perdas. O gateway NAT é a opção preferida para estabelecer conectividade de saída altamente confiável e resiliente a partir de implantações do Azure. Para otimizar a eficiência da conexão do aplicativo, consulte as orientações mais adiante no artigo.

Utilizar o conjunto de ligações

Ao agrupar suas conexões, você evita abrir novas conexões de rede para chamadas para o mesmo endereço e porta. Você pode implementar um esquema de pool de conexões em seu aplicativo onde as solicitações são distribuídas internamente em um conjunto fixo de conexões e reutilizadas quando possível. Essa configuração restringe o número de portas SNAT em uso e cria um ambiente previsível. O pool de conexões ajuda a reduzir a latência e a utilização de recursos e, em última análise, melhora o desempenho de seus aplicativos.

Para saber mais sobre como agrupar conexões HTTP, consulte Pool HTTP connections with HttpClientFactory.

Reutilizar conexões

Em vez de gerar conexões TCP atômicas individuais para cada solicitação, configure seu aplicativo para reutilizar conexões. A reutilização de conexão resulta em transações TCP de maior desempenho e é especialmente relevante para protocolos como HTTP/1.1, onde a reutilização de conexão é o padrão. Essa reutilização se aplica a outros protocolos que usam HTTP como transporte, como REST.

Use uma lógica de repetição menos agressiva

Quando as portas SNAT estão esgotadas ou ocorrem falhas no aplicativo, novas tentativas agressivas ou de força bruta sem demora e a lógica de back-off faz com que a exaustão ocorra ou persista. Você pode reduzir a demanda por portas SNAT usando uma lógica de repetição menos agressiva.

Dependendo do tempo limite ocioso configurado, se as novas tentativas forem muito agressivas, as conexões não terão tempo suficiente para fechar e liberar portas SNAT para reutilização.

Para obter orientações e exemplos adicionais, consulte Repetir padrão.

Utilizar as métricas keep alive para repor o tempo limite de inatividade de saída

Para obter mais informações sobre keepalives, consulte Tempo limite de ociosidade TCP.

Quando possível, o Private Link deve ser usado para se conectar diretamente de suas redes virtuais aos serviços da plataforma Azure para reduzir a demanda em portas SNAT. Reduzir a demanda nas portas SNAT pode ajudar a reduzir o risco de exaustão das portas SNAT.

Para criar um Link Privado, consulte os seguintes guias de início rápido para começar:

Próximos passos

Esforçamo-nos sempre para melhorar a experiência dos nossos clientes. Se você encontrar problemas de gateway NAT que não foram abordados ou resolvidos por este artigo, forneça comentários por meio do GitHub na parte inferior desta página.

Para saber mais sobre o gateway NAT, consulte: