Compartilhar via

Solucionar problemas de conectividade do Gateway da NAT do Azure

  • Artigo

Este artigo fornece diretrizes sobre como resolver problemas comuns de conectividade de saída no Gateway da NAT. Este artigo também fornece as melhores práticas sobre como criar aplicativos para usar conexões de saída de forma eficiente.

Diminuição de disponibilidade de datapath no gateway da NAT com falhas de conexão

Cenário

Você observa uma diminuição na disponibilidade de datapath do gateway da NAT, que coincide com falhas de conexão.

Possíveis causas:

  • Exaustão da porta de conversão de endereços de rede (SNAT) de origem.

  • Limites de conexão SNAT simultânea.

  • Tempos limite de conexão.

  • Remoção de endereços IP públicos ou sub-redes do Gateway da NAT.

Etapas de solução de problemas

Possíveis soluções para esgotamento da porta SNAT ou alcance dos limites de conexão simultânea

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

  • Distribua o ambiente de aplicativo em várias sub-redes e forneça um recurso do Gateway da NAT para cada sub-rede.

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

  • Considere os padrões de sondagem assíncrona a fim de liberar recursos de conexão para outras operações.

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

  • Se a investigação for inconclusiva, abra um caso de suporte para uma solução de problemas adicional.

Observação

É importante entender por que o esgotamento de porta SNAT ocorre. Verifique se você está usando os padrões corretos para cenários escalonáveis e confiáveis. A adição de mais portas SNAT a um cenário sem entender a causa da demanda deve ser o último recurso. Se você não sabe o motivo do cenário estar aplicando pressão no estoque de portas SNAT, a adição de mais portas SNAT adicionando mais endereços IP apenas atrasará a mesma falha de esgotamento à medida que o aplicativo escalar. Você pode estar mascarando outras ineficiências e antipadrões. Para obter mais informações, confira Melhores práticas para uso eficiente de conexões de saída.

Possíveis soluções para tempos limite de conexão de TCP

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

Keepalives TCP só precisam ser habilitados de um lado de uma conexão para manter uma conexão ativa de ambos os lados. Quando um keepalive de TCP é enviado de um lado de uma conexão, o outro lado envia automaticamente um pacote (ACK) de reconhecimento. O temporizador de tempo de ociosidade é redefinido em ambos os lados da conexão.

Observação

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

Possíveis soluções para tempos limite de conexão de protocolo UDP (User Datagram Protocol)

Os temporizadores de tempo limite ocioso de UDP estão definidos como 4 minutos e não são configuráveis. Habilite keepalives de UDP para ambas as direções em um fluxo de conexão para manter conexões longas. Quando um keepalive de 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 impedir que uma conexão UDP fique atinja o tempo limite ocioso, os keepalives UDP devem ser habilitados para as duas direções em um fluxo de conexão.

Keepalives de camada de aplicativo também podem ser usados para atualizar fluxos ociosos e redefinir o tempo limite de ociosidade. Verifique o lado do servidor para as opções existentes para o aplicativo keepalives específico.

Impacto da remoção de IPs públicos ou sub-redes do Gateway da NAT

Todas as conexões ativas associadas a um endereço IP público terminam quando o endereço IP público é removido do Gateway da NAT. Se o recurso de gateway da NAT tiver vários IPs públicos, o novo tráfego será redistribuído entre os IPs atribuídos. O tráfego também será interrompido se o Gateway da NAT for removido de quaisquer sub-redes com conexões ativas. Considere atualizar as configurações no Gateway da NAT durante as janelas de manutenção para minimizar o impacto na conectividade de saída.

Diminuição da disponibilidade de datapath no gateway da NAT, mas sem falhas de conexão

Cenário

A disponibilidade de datapath do gateway da NAT diminui, mas nenhuma conexão com falha é observada.

Causa possível

Diminuição transitória na disponibilidade do datapath causada pelo ruído no datapath.

Etapas para solucionar problemas

Se você observar uma diminuição na disponibilidade do datapath sem nenhum efeito na conectividade de saída, isso pode ocorrer devido ao gateway da NAT captar ruído transitório no datapath.

Configure um alerta para diminuições de disponibilidade de datapath ou use o Azure Resource Health para alertar sobre eventos de integridade do Gateway da NAT.

Sem conectividade de saída com a Internet

Cenário

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

Possíveis causas:

  • Configuração incorreta do gateway da NAT.

  • O tráfego de Internet é redirecionado para longe do gateway da NAT e tem túnel forçado para uma solução de virtualização ou para um destino local com uma VPN ou ExpressRoute.

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

  • A disponibilidade de datapath do gateway da NAT está degradada.

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

Etapas para solucionar problemas

  • Verifique se o gateway da NAT está configurado com pelo menos um endereço IP público ou prefixo e anexado a uma sub-rede. O gateway da 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ções do gateway da NAT.

  • Verifique a tabela de roteamento da sub-rede anexada ao gateway da NAT. Qualquer tráfego 0.0.0.0/0 com túnel forçado para uma NVA (Solução de Virtualização de Rede), ExpressRoute ou Gateway de VPN terá prioridade sobre o gateway da NAT. Para saber mais, consulte como o Azure seleciona uma rota.

  • Verifique se há regras do NSG configuradas para o adaptador de rede em sua máquina virtual que bloqueia o acesso à Internet.

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

  • Verifique as configurações de DNS se o DNS não está sendo resolvido corretamente.

Possíveis soluções para perda de conectividade de saída

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

  • Considere cuidadosamente seus requisitos de roteamento de tráfego antes de fazer alterações nas rotas de tráfego para sua rede virtual. UDRs (rotas definidas pelo usuário) que enviam tráfego 0.0.0.0/0 para uma solução de virtualização ou gateway de rede virtual substituem o gateway da NAT. Consulte rotas personalizadas para saber mais sobre como as rotas personalizadas afetam o roteamento do tráfego de rede.

    Para explorar as opções para atualizar suas rotas de tráfego na tabela de roteamento de sub-rede, consulte:

  • Atualize as regras de segurança do NSG que bloqueiam o acesso à Internet para qualquer uma de suas VMs. Para obter mais informações, consulte gerenciar grupos de segurança de rede.

  • O DNS não resolver corretamente pode ocorrer por muitos motivos. Consulte o guia de solução de problemas de DNS para ajudar a investigar por que a resolução de DNS está falhando.

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

Cenário

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

Possíveis causas:

  • Configuração incorreta do gateway da NAT.

  • Conexão ativa com outro método de conectividade de saída do Azure, como o Azure Load Balancer ou IPs públicos no nível da instância em máquinas virtuais ou acesso de saída padrão. 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 da NAT é implantado, novas conexões começam a usar o gateway da NAT imediatamente.

  • IPs privados são usados para se conectar aos serviços do Azure por ponto 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 da qual você está fazendo uma conexão.

  • O tráfego da Internet está sendo redirecionado para longe do gateway da NAT e tem túnel forçado para uma NVA ou firewall.

Como solucionar problemas

  • Verifique se o gateway da 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 da NAT.

  • Verifique se as conexões feitas com outros serviços do Azure vêm de um endereço IP privado em sua rede virtual do Azure.

  • Verifique se você tem um 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 é proveniente de outro serviço do Azure em sua rede virtual do Azure, como uma NVA (Solução de Virtualização de Rede).

Soluções possíveis para o IP público do gateway da NAT não usado para conectar a saída

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

  • Teste e resolva problemas com as VMs que mantêm endereços IP públicos de outro método de conectividade de saída, incluindo balanceador de carga, IPs públicos no nível da instância ou acesso de saída padrão por:

    • Verificar se você estabeleceu uma nova conexão e se 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 estiver usando um navegador, as conexões também poderão ser organizadas em pool.

    • Reinicialize a máquina virtual (execute um STOP/START) em uma sub-rede configurada para o gateway da NAT. Se uma máquina virtual for reinicializada, o estado da conexão será liberado. Quando o estado da conexão for liberado, todas as novas conexões começarão a usar o endereço ou os endereços IP do recurso de gateway da NAT. Tenha em mente que, se a VM tiver alguma conexão ativa no momento da reinicialização, essas conexões serão descartadas.

    • Se a investigação for inconclusiva, abra um caso de suporte para uma solução de problemas adicional.

  • As rotas personalizadas que direcionam o tráfego 0.0.0.0/0 para uma NVA terão precedência sobre o gateway da NAT para rotear o tráfego para a Internet. Para o gateway da NAT rotear o tráfego para a Internet em vez de para NVA, remova a rota personalizada para o tráfego 0.0.0.0/0 indo para a solução de virtualização. Em vez disso, o tráfego 0.0.0.0/0 é retomado usando a rota padrão para a Internet e o gateway da NAT é usado.

Importante

Antes de fazer alterações 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 a conta de armazenamento do Azure usam endereços IP privados do Azure para comunicação. Você não pode restringir o acesso a serviços específicos do Azure com base nos respectivos intervalos de endereços IP de saída públicos. Para obter mais informações, consulte restrições para regras de rede IP.
  • O Link Privado e os 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 conectarem aos serviços de plataforma do Azure em vez do IP público do gateway da NAT. Use o Link Privado para se conectar aos serviços do Azure pelo backbone do Azure em vez da Internet com o gateway da NAT.

Observação

O Link Privado é a opção recomendada em 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 da NAT para destinos da Internet falham ou atingem o tempo limite.

Possíveis causas:

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

  • limitação da taxa da API imposta pelo lado de destino.

  • Mitigações de DDoS volumoso ou modelagem de tráfego de 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.

  • Conduzir captura de pacotes dos lados de origem e de destino.

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

  • Veja os pacotes removidos para saber quantos foram removidos pelo gateway da NAT.

  • Analise os pacotes. Pacotes de TCP com pacotes de protocolo IP fragmentados indicam fragmentação de IP. O Gateway da NAT não dá suporte à fragmentação de IP e, portanto, as conexões com pacotes fragmentados falham.

  • Verifique se o IP público do gateway da NAT está listado como permitido em destinos de 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 da NAT está listado como permitido no destino.

  • Se estiver criando um teste de taxa de transação ou alto volume, 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 da NAT com o modo FTP ativo ou passivo.

Possíveis causas:

  • O modo FTP ativo está habilitado.

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

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

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

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

O gateway da 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 é colocado no mono SNAT pelo gateway da NAT para comunicação baseada na Internet, portanto, o comando PORT é visto como inválido pelo servidor FTP.

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

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

No modo FTP passivo, o cliente estabelece conexões nos canais de comando e de 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 com o gateway da NAT com vários endereços IP públicos dependendo da configuração do servidor FTP. Quando um Gateway da NAT com vários endereços IP públicos envia dados de tráfego, ele seleciona aleatoriamente um de seus endereços IP públicos para o endereço IP de origem. O FTP falha quando os canais de controle e de dados usam endereços IP de origem diferentes, dependendo da configuração do servidor FTP.

Para evitar possíveis falhas de conexão FTP passivas, faça o seguinte:

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

  2. Verifique se o intervalo de portas passivas do gateway da NAT tem permissão para passar por firewalls no ponto de extremidade de destino.

Observação

Reduzir a quantidade de endereços IP públicos em seu gateway da 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 da NAT. Não é recomendável alterar as configurações do servidor FTP para aceitar o controle e o tráfego do plano de dados de diferentes endereços IP de origem.

Conexões de saída nas portas 25 são bloqueadas

Cenário

Não é possível conectar a saída com o gateway da NAT na porta 25 para o tráfego do protocolo SMTP.

Causa

A plataforma do Azure bloqueia conexões SMTP de saída na porta TCP 25 para VMs implantadas. Esse bloqueio é para garantir uma melhor segurança para os parceiros e clientes da Microsoft, proteger a plataforma do Microsoft Azure e estar em conformidade com os padrões do setor.

Usar um serviço de retransmissão SMTP autenticado para enviar emails de VMs do Azure ou do Serviço de Aplicativo do Azure. Para saber mais, confira solucionar problemas de conectividade de SMTP de saída.

Mais diretrizes de solução de problemas

Capturas de rede extras

Se a investigação for inconclusiva, abra um caso de suporte para continuar a solução de problemas e colete as informações a seguir para acelerar a resolução. Escolha apenas uma máquina virtual na sub-rede configurada do gateway da NAT e execute os seguintes testes:

  • Teste a resposta da porta de investigação usando ps ping em uma das VMs de back-end na 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 de netsh simultâneo na máquina virtual de back-end e na máquina virtual de teste da rede virtual enquanto executa PsPing. Depois, interrompa o rastreamento de netsh.

Melhores práticas de conectividade de saída

O Azure monitora e opera sua infraestrutura com muito cuidado. No entanto, falhas transitórias ainda podem ocorrer nos aplicativos implantados. Não há garantia de que não haverá perda de transmissão. O gateway da NAT é a opção preferencial para estabelecer uma conectividade de saída altamente confiável e resiliente de implantações do Azure. Para otimizar a eficiência da conexão do aplicativo, consulte as diretrizes posteriormente no artigo.

Usar o pool de conexões

Ao agrupar suas conexões, você evita abrir novas conexões de rede para chamadas aos mesmos endereço e porta. Você pode implementar um esquema de pooling de conexão no aplicativo, em que as solicitações são distribuídas internamente em um conjunto de conexões fixo e são reutilizadas sempre que possível. Essa configuração restringe o número de portas SNAT em uso e cria um ambiente mais previsível. O pooling de conexões ajuda a reduzir a latência e a utilização de recursos e ainda aprimora o desempenho dos aplicativos.

Para saber mais sobre o pooling de conexões HTTP, confira Conexões HTTP em pool com HttpClientFactory.

Reutilizar conexões

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

Usar lógica de repetição menos agressiva

Quando as portas SNAT estão esgotadas ou quando ocorrem falhas no aplicativo, repetições de força bruta ou agressivas sem lógica de atraso e retirada fazem com que o esgotamento ocorra ou persista. Você pode reduzir a demanda de portas SNAT usando uma lógica de repetição menos agressiva.

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

Para obter diretrizes e exemplos adicionais, confira Padrão de repetição.

Usar keepalives para redefinir o tempo limite ocioso de saída

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

Quando possível, o Link Privado deve ser usado para se conectar as redes virtuais diretamente aos serviços da plataforma Azure a fim de reduzir a demanda em portas SNAT. Reduzir a demanda em portas SNAT pode ajudar a reduzir o risco de esgotamento de porta SNAT.

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

Próximas etapas

Sempre nos esforçamos para aprimorar a experiência de nossos clientes. Se você encontrar problemas de gateway da NAT que não foram resolvidos ou resolvidos por este artigo, forneça comentários por meio do GitHub na parte inferior desta página.

Saiba mais sobre métricas de gateways da NAT: