Editar

Revisão do Azure Well-Architected Framework de um gateway NAT do Azure

Azure Application Gateway
Azure Virtual Network
Azure Private Link

Este artigo fornece práticas recomendadas para um gateway NAT do Azure. A orientação é baseada nos cinco pilares da excelência da arquitetura: Otimização de Custos, Excelência Operacional, Eficiência de Desempenho, Confiabilidade e Segurança.

Supomos que você tenha um conhecimento prático do Azure NAT Gateway e que conheça bem os respetivos recursos. Como atualização, revise o conjunto completo de documentação do Gateway NAT do Azure.

NAT significa tradução de endereços de rede. Consulte Uma introdução à Tradução de Endereço de Rede.

Otimização de custos

O acesso aos serviços PaaS deve ser feito por meio do Azure Private Link ou de pontos de extremidade de serviço (incluindo armazenamento), para evitar o uso de um gateway NAT. Link privado e pontos de extremidade de serviço não exigem a travessia do gateway NAT para acessar serviços PaaS. Essa abordagem reduzirá a cobrança por GB de dados processados, ao comparar os custos de um gateway NAT com Private Link ou com pontos de extremidade de serviço. Há benefícios de segurança adicionais para usar o Private Link ou pontos de extremidade de serviço.

Eficiência de desempenho

Cada recurso de gateway NAT fornece até 50 Gbps de taxa de transferência. Você pode dividir suas implantações em várias sub-redes e, em seguida, atribuir a cada sub-rede ou grupos de sub-redes um gateway NAT para dimensionamento.

Cada endereço IP público do NAT Gateway fornece até 64 512 portas SNAT. Até 16 endereços IP podem ser atribuídos a um gateway NAT. Os endereços IP podem ser endereços IP públicos padrão individuais, o prefixo IP público ou ambos. Para conexões que vão para o mesmo ponto de extremidade de destino, o gateway NAT pode suportar até 50.000 fluxos simultâneos para TCP e UDP, respectivamente, por endereço IP de saída atribuído. Analise a seção a seguir sobre Tradução de endereços de rede de origem (SNAT) para obter detalhes. TCP significa Transmission Control Protocol ( Protocolo de Controle de Transmissão) e UDP ( User Datagram Protocol).

Esgotamento da SNAT

  • Os recursos do gateway NAT têm um tempo limite de inatividade TCP padrão de 4 minutos que pode ser configurado até 120 minutos. Se essa configuração for alterada para um valor mais alto do que o padrão, o gateway NAT manterá os fluxos por mais tempo e poderá causar pressão desnecessária no inventário de portas SNAT.
  • As solicitações atômicas (uma solicitação por conexão) são uma escolha de design ruim, porque limitam a escala, reduzem o desempenho e reduzem a confiabilidade. Em vez disso, reutilize conexões HTTP/S para reduzir o número de conexões e portas SNAT associadas. A reutilização da conexão permitirá que o aplicativo seja dimensionado melhor. O desempenho do aplicativo melhorará devido à redução de apertos de mão, despesas gerais e custos de operação criptográfica ao usar TLS.
  • As pesquisas de DNS (Sistema de Nomes de Domínio) podem introduzir muitos fluxos individuais no volume, quando o cliente não está armazenando em cache o resultado dos resolvedores de DNS. Use o cache DNS para reduzir o volume de fluxos e reduzir o número de portas SNAT. DNS é o sistema de nomenclatura que mapeia nomes de domínio para endereços IP para recursos conectados à Internet ou a uma rede privada.
  • Os fluxos UDP, como pesquisas de DNS, usam portas SNAT durante o tempo limite ocioso. O temporizador de tempo limite de inatividade UDP é fixado em 4 minutos e não pode ser alterado.
  • Use pools de conexões para moldar seu volume de conexão.
  • Nunca abandone silenciosamente um fluxo TCP e confie nos temporizadores TCP para limpar o fluxo. Se você não permitir que o TCP feche explicitamente a conexão, a conexão TCP permanecerá aberta. Sistemas intermediários e pontos finais manterão essa conexão em uso, o que, por sua vez, torna a porta SNAT indisponível para outras conexões. Esse antipadrão pode desencadear falhas no aplicativo e exaustão do SNAT.
  • Não altere os valores do temporizador relacionado ao fechamento de TCP no nível do sistema operacional sem conhecimento especializado das implicações. Embora a pilha TCP se recupere, o desempenho do aplicativo pode ser afetado negativamente quando os pontos de extremidade de uma conexão não correspondem às expectativas. A alteração dos valores do temporizador é geralmente um sinal de um problema de design subjacente. Se a aplicação subjacente tiver outros anti-padrões, a exaustão SNAT também pode ser amplificada se os valores do temporizador forem alterados.

Analise as seguintes orientações para melhorar a escala e a confiabilidade do seu serviço:

  • Explore o efeito da redução do tempo limite de inatividade do TCP para valores mais baixos. Um tempo limite de inatividade padrão de 4 minutos pode liberar o inventário de porta SNAT mais cedo.
  • Considere padrões de sondagem assíncronos para operações de longa execução, para liberar seus recursos de conexão para outras operações.
  • Fluxos de longa duração, como conexões TCP reutilizadas, devem usar keepalives TCP ou keepalives de camada de aplicativo para evitar o tempo limite dos sistemas intermediários. Você só deve aumentar o tempo limite ocioso como último recurso, e isso pode não resolver a causa raiz. Um tempo limite longo pode causar falhas de baixa taxa, quando o tempo limite expira, e pode introduzir um atraso e falhas desnecessárias. Os keepalives TCP podem ser ativados de um lado da conexão para manter uma conexão viva de ambos os lados.
  • Para fluxos de longa duração com tráfego UDP, você pode habilitar keepalives UDP para manter as conexões vivas. Lembre-se de que os keepalives UDP habilitados em um lado da conexão só mantêm a conexão ativa de um lado. Os keepalives UDP devem ser habilitados em ambos os lados de uma conexão para manter uma conexão viva.
  • Padrões de repetição graciosos devem ser usados para evitar tentativas/explosões agressivas durante falhas transitórias ou recuperação de falhas. Um antipadrão, chamado conexões atômicas, é quando você cria uma nova conexão TCP para cada operação HTTP. As conexões atômicas impedirão que seu aplicativo seja bem dimensionado e desperdiçarão recursos. Sempre canalize várias operações para a mesma conexão. Seu aplicativo se beneficiará em velocidade de transação e custos de recursos. Quando seu aplicativo usa criptografia de camada de transporte (por exemplo, TLS), há um custo significativo associado ao processamento de novas conexões. Consulte Azure Cloud Design Patterns para obter mais padrões de práticas recomendadas.

Excelência operacional

Embora o gateway NAT possa ser usado com o Serviço Kubernetes do Azure (AKS), ele não é gerenciado como parte do AKS. Se você atribuir um gateway NAT à sub-rede CNI (Container Networking Interface), permitirá que os pods AKS saiam pelo gateway NAT.

Ao usar vários gateways NAT entre zonas ou entre regiões, mantenha a propriedade IP de saída gerenciável usando prefixos IP públicos do Azure ou prefixos BYOIP. Um tamanho de prefixo IP maior que 16 endereços IP (/28 tamanho de prefixo) não pode ser atribuído ao gateway NAT.

Use os alertas do Azure Monitor para monitorar e alertar sobre o uso da porta SNAT, pacotes processados ou descartados e quantidade de dados transmitidos. Use logs de fluxo NSG para monitorar o fluxo de tráfego de saída de instâncias de máquina virtual em uma sub-rede configurada de gateway NAT.

Quando uma sub-rede é configurada com um gateway NAT, o gateway NAT substituirá toda a outra conectividade de saída para a Internet pública para todas as VMs nessa sub-rede. O gateway NAT terá precedência sobre um balanceador de carga com ou sem regras de saída e sobre endereços IP públicos atribuídos diretamente a VMs. O Azure rastreia a direção de um fluxo e o roteamento assimétrico não ocorrerá. O tráfego originado de entrada será traduzido corretamente, como um IP frontend do balanceador de carga, e será traduzido separadamente do tráfego originado de saída por meio de um gateway NAT. Essa separação permite que os serviços de entrada e saída coexistam perfeitamente.

O gateway NAT é recomendado como padrão para habilitar a conectividade de saída para redes virtuais. O gateway NAT é mais eficiente e menos complexo operacionalmente do que outras técnicas de conectividade de saída no Azure. Os gateways NAT alocam portas SNAT sob demanda e usam um algoritmo mais eficiente para evitar conflitos de reutilização de portas SNAT. Não confie na conectividade de saída padrão (um antipadrão) para sua propriedade. Em vez disso, defina-o explicitamente com recursos de gateway NAT.

Fiabilidade

Os recursos de gateway NAT estão altamente disponíveis em uma zona de disponibilidade e abrangem vários domínios de falha. O gateway NAT pode ser implantado em "nenhuma zona" na qual o Azure seleciona automaticamente uma zona para colocar o gateway NAT. O gateway NAT também pode ser isolado em uma zona específica por um usuário.

O isolamento da zona de disponibilidade não pode ser fornecido, a menos que cada sub-rede tenha recursos apenas dentro de uma zona específica. Em vez disso, implante uma sub-rede para cada uma das zonas de disponibilidade em que as VMs são implantadas, alinhe as VMs zonais com gateways NAT zonais correspondentes e crie pilhas zonais separadas. Por exemplo, uma máquina virtual na zona de disponibilidade 1 está em uma sub-rede com outros recursos que também estão apenas na zona de disponibilidade 1. Um gateway NAT é configurado na zona de disponibilidade 1 para servir essa sub-rede. Veja o seguinte diagrama.

Diagrama que demonstra o fluxo direcional de uma pilha zonal.

As redes virtuais e as sub-redes abrangem todas as zonas de disponibilidade de uma região. Não é necessário dividi-los por zonas de disponibilidade para acomodar recursos zonais.

Segurança

Com o gateway NAT, as máquinas virtuais individuais (ou outros recursos de computação) não precisam de endereços IP públicos e podem permanecer totalmente privadas. Recursos sem um endereço IP público ainda podem alcançar fontes externas fora da rede virtual. Você pode associar um prefixo IP público para garantir que um conjunto contíguo de IPs seja usado para conectividade de saída. As regras de firewall de destino podem ser configuradas com base nesta lista de IP previsível.

Uma abordagem comum é projetar um cenário de dispositivo virtual de rede (NVA) somente de saída com firewalls de terceiros ou com servidores proxy. Quando um gateway NAT é implantado em uma sub-rede com um conjunto de NVAs em escala de máquina virtual, esses NVAs usarão o(s) endereço(s) do gateway NAT para conectividade de saída, em oposição ao IP de um balanceador de carga ou aos IPs individuais. Para empregar esse cenário com o Firewall do Azure, consulte Integrar o Firewall do Azure ao Balanceador de Carga Padrão do Azure.

Diagrama que mostra firewalls com um sanduíche de balanceador de carga e gateway NAT.

O Microsoft Defender for Cloud pode monitorar qualquer conectividade de saída suspeita por meio de um gateway NAT. Este é um recurso de alerta no Microsoft Defender for Cloud.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos