Este artigo descreve as práticas recomendadas para um gateway NAT do Azure. A orientação é baseada nos cinco pilares da excelência arquitetônica: Otimização de Custos, Excelência Operacional, Eficiência de Desempenho, Confiabilidade e Segurança.
Como pré-requisito para esta orientação, você deve ter um conhecimento prático do Azure NAT Gateway e entender seus respetivos recursos. Para obter mais informações, consulte a documentação do Gateway NAT do Azure.
Otimização de custos
Configure o acesso a soluções de plataforma como serviço (PaaS) por meio do Azure Private Link ou pontos de extremidade de serviço, incluindo armazenamento, para que você não precise usar um gateway NAT. O link privado e os pontos de extremidade de serviço não exigem a travessia do gateway NAT para acessar os serviços PaaS. Essa abordagem reduz o custo por gigabyte (GB) de dados processados, em comparação com o custo de usar um gateway NAT. O Private Link e os pontos de extremidade de serviço também oferecem benefícios de segurança.
Eficiência de desempenho
Cada recurso de gateway NAT fornece até 50 gigabits por segundo (Gbps) de taxa de transferência. Você pode dividir suas implantações em várias sub-redes e, em seguida, atribuir um gateway NAT a cada sub-rede ou grupo de sub-redes para expansão.
Cada endereço IP público do gateway NAT fornece 64.512 portas SNAT (Source Network Address Translation). Você pode atribuir até 16 endereços IP a um gateway NAT, incluindo endereços IP públicos padrão individuais, o prefixo IP público ou ambos. Para cada endereço IP de saída atribuído que vai para o mesmo ponto de extremidade de destino, o gateway NAT pode suportar até 50.000 fluxos simultâneos para TCP (Transmission Control Protocol) e UDP (User Datagram Protocol), respectivamente.
Esgotamento da SNAT
Considere as seguintes orientações para ajudar a evitar o esgotamento do SNAT:
Os recursos do gateway NAT têm um tempo limite de inatividade TCP padrão de quatro minutos. Você pode configurar o tempo limite por até 120 minutos. Se você alterar essa configuração para um valor mais alto do que o padrão, o gateway NAT reterá os fluxos por mais tempo, o que pode criar pressão desnecessária no inventário de portas SNAT.
As solicitações atômicas (uma solicitação por conexão) limitam a escala, reduzem o desempenho e reduzem a confiabilidade. Em vez de solicitações atômicas, você pode reutilizar conexões HTTP ou HTTPS para reduzir o número de conexões e portas SNAT associadas. Quando você reutiliza conexões, o aplicativo pode ser dimensionado melhor. O desempenho do aplicativo melhora devido à redução de handshakes, despesas gerais e custos de operação criptográfica quando você usa TLS (Transport Layer Security).
Se você não armazenar em cache os resultados do resolvedor de DNS, as pesquisas de DNS (Sistema de Nomes de Domínio) podem introduzir muitos fluxos individuais no volume. 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 quatro minutos.
Use pools de conexões para moldar seu volume de conexão.
Para limpar fluxos, não abandone silenciosamente os fluxos TCP nem confie em temporizadores TCP. Se você não permitir que o TCP feche explicitamente uma conexão, a conexão TCP permanecerá aberta. Sistemas intermediários e pontos finais mantêm essa conexão em uso, o que 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 TCP no nível do SO, a menos que conheça as implicações. Se os pontos de extremidade de uma conexão tiverem expectativas incompatíveis, a pilha TCP poderá se recuperar, mas poderá afetar negativamente o desempenho do aplicativo. Normalmente, você tem um problema de design subjacente se precisar alterar os valores do temporizador. E se o aplicativo subjacente tiver outros antipadrões e você alterar os valores do temporizador, você também pode acelerar a exaustão do SNAT.
Analise as seguintes orientações para melhorar a escala e a confiabilidade do seu serviço:
Considere os efeitos da redução do tempo limite de inatividade do TCP para um valor mais baixo. Um tempo limite de ociosidade padrão de quatro minutos pode liberar preventivamente o inventário de portas SNAT.
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.
Considere o uso de keepalives TCP ou keepalives de camada de aplicativo para fluxos TCP de longa duração, como conexões TCP reutilizadas, para evitar que os sistemas intermediários atinjam o tempo limite. 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. Também pode introduzir um atraso e falhas desnecessárias. Você pode habilitar keepalives TCP de um lado de uma conexão para manter uma conexão ativa de ambos os lados.
Considere o uso de keepalives UDP para fluxos UDP de longa duração para evitar que os sistemas intermediários atinjam o tempo limite. Quando você habilita keepalives UDP em um lado da conexão, apenas um lado da conexão permanece ativo. Você deve habilitar o UDP keepalives em ambos os lados de uma conexão para manter uma conexão ativa.
Considere padrões de repetição graciosos para evitar repetições agressivas e explosões durante falhas transitórias ou recuperação de falhas. Para as conexões atômicas antipadrão, você cria uma nova conexão TCP para cada operação HTTP. As conexões atômicas desperdiçam recursos e impedem que seu aplicativo seja bem dimensionado.
Para aumentar a velocidade de transação e diminuir os custos de recursos para seu aplicativo, sempre canalize várias operações para a mesma conexão. Quando seu aplicativo usa criptografia de camada de transporte, por exemplo, TLS, o novo processamento de conexão aumenta o custo. Para obter mais padrões de práticas recomendadas, consulte Padrões de design de nuvem do Azure.
Excelência operacional
Você pode usar um gateway NAT com o Serviço Kubernetes do Azure (AKS), mas o gerenciamento de gateway NAT não está incluído no AKS. Se você atribuir um gateway NAT à sub-rede CNI (Container Networking Interface), habilitará os pods AKS para sair pelo gateway NAT.
Quando você usa vários gateways NAT entre zonas ou regiões, mantenha a propriedade IP de saída gerenciável usando prefixos IP públicos do Azure ou prefixos BYOIP (traga seu próprio IP). Não é possível atribuir um tamanho de prefixo IP maior que 16 endereços IP (/28 tamanho de prefixo) a um gateway NAT.
Use os alertas do Azure Monitor para monitorar e alertar sobre o uso da porta SNAT, pacotes processados ou descartados e a quantidade de dados transmitidos. Use logs de fluxo NSG (grupo de segurança de rede) para monitorar o fluxo de tráfego de saída de instâncias de máquina virtual (VM) em uma sub-rede configurada pelo gateway NAT.
Quando você configura uma sub-rede com um gateway NAT, o gateway NAT substitui todas as outras conexões de saída para a Internet pública para todas as VMs nessa sub-rede. O gateway NAT tem precedência sobre um balanceador de carga, independentemente das regras de saída. O gateway também tem precedência sobre os endereços IP públicos atribuídos diretamente às VMs. O Azure rastreia a direção de um fluxo e impede o roteamento assimétrico. O tráfego originado de entrada, como um IP front-end do balanceador de carga, é traduzido corretamente e é 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.
Recomendamos um gateway NAT como padrão para habilitar a conectividade de saída para redes virtuais. Um gateway NAT fornece eficiência e simplicidade operacional em comparação com 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 no antipadrão de conectividade de saída padrão para sua propriedade. Em vez disso, defina explicitamente sua configuração 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. Você pode implantar um gateway NAT em uma zona sem na qual o Azure seleciona automaticamente uma zona para colocar o gateway NAT ou isola o gateway NAT em uma zona de disponibilidade específica.
Para fornecer isolamento de zona de disponibilidade, cada sub-rede deve ter recursos apenas dentro de uma zona específica. Para implementar essa abordagem, você pode:
- 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.
- Crie pilhas zonais separadas.
No diagrama a seguir, uma VM 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.
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 um gateway NAT, VMs individuais ou outros recursos de computação não precisam de endereços IP públicos e podem permanecer totalmente privados. 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 você use um conjunto contíguo de IPs para conectividade de saída. Você pode configurar regras de firewall de destino com base nessa lista de IP previsível.
Uma abordagem comum é projetar um cenário de dispositivo virtual de rede (NVA) somente de saída com firewalls que não sejam da Microsoft ou com servidores proxy. Quando você implanta um gateway NAT em uma sub-rede com um conjunto de NVAs em escala de máquina virtual, esses NVAs usam um ou mais endereços de gateway NAT para conectividade de saída em vez de um IP de balanceador de carga ou os 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.
Você pode usar o recurso de alerta do Microsoft Defender for Cloud para monitorar qualquer conectividade de saída suspeita em um gateway NAT.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Ethan Haslett - Brasil | Arquiteto de Soluções Cloud Sênior
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- Estrutura bem arquitetada da Microsoft
- Tutorial: Criar um gateway NAT usando o portal do Azure
- Recomendações para o uso de zonas e regiões de disponibilidade