Recurso do Gateway NAT do Azure

Este artigo descreve os principais componentes do recurso de gateway NAT que permitem fornecer conectividade de saída altamente segura, escalável e resiliente. Alguns desses componentes podem ser configurados em sua assinatura por meio do portal do Azure, CLI do Azure, Azure PowerShell, modelos do Gerenciador de Recursos ou alternativas apropriadas.

Arquitetura do gateway NAT

O NAT Gateway usa rede definida por software para operar como um serviço distribuído e totalmente gerenciado. Como o NAT Gateway tem vários domínios de falha, ele é capaz de suportar várias falhas sem qualquer efeito para o serviço.

O NAT Gateway fornece a conversão de endereços de rede de origem (SNAT) para instâncias privadas em sub-redes da sua rede virtual do Azure. Quando configurado em uma sub-rede, os IPs privados dentro de suas sub-redes SNAT para endereços IP públicos estáticos de um gateway NAT para se conectar de saída à Internet. O NAT Gateway também fornece conversão de endereços de rede de destino (DNAT) para pacotes de resposta apenas para uma conexão originada de saída.

Diagrama de um recurso de gateway NAT com máquinas virtuais.

Figura: Gateway NAT para saída para a Internet

Quando um gateway NAT é anexado a uma sub-rede dentro de uma rede virtual, o gateway NAT assume o tipo de próximo salto padrão da sub-rede para todo o tráfego de saída direcionado para a Internet. Não são necessárias configurações de roteamento extras. O NAT Gateway não fornece conexões de entrada não solicitadas da Internet. O DNAT só é executado para pacotes que chegam como resposta a um pacote de saída.

Sub-redes

Um gateway NAT pode ser conectado a várias sub-redes dentro de uma rede virtual para fornecer conectividade de saída à Internet. Quando um gateway NAT é anexado a uma sub-rede, ele assume a rota padrão para a Internet. O gateway NAT será então o próximo tipo de salto para todo o tráfego de saída destinado à Internet.

As seguintes configurações de sub-rede não podem ser usadas com um gateway NAT:

  • Quando o gateway NAT é anexado a uma sub-rede, ele assume a rota padrão para a Internet. Apenas um gateway NAT pode servir como a rota padrão para a Internet para uma sub-rede.

  • Um gateway NAT não pode ser anexado a sub-redes de redes virtuais diferentes.

  • Um gateway NAT não pode ser usado com uma sub-rede de gateway. Uma sub-rede de gateway é uma sub-rede designada para um gateway VPN enviar tráfego criptografado entre uma rede virtual do Azure e o local local. Para obter mais informações sobre a sub-rede do gateway, consulte Sub-rede do gateway.

Endereços IP públicos estáticos

Um gateway NAT pode ser associado a endereços IP públicos estáticos ou prefixos IP públicos para fornecer conectividade de saída. O NAT Gateway suporta endereços IPv4. Um gateway NAT pode usar endereços IP públicos ou prefixos em qualquer combinação até um total de 16 endereços IP. Se você atribuir um prefixo IP público, todo o prefixo IP público será usado. Pode utilizar diretamente um prefixo de IP público ou distribuir os endereços IP públicos do prefixo por vários recursos do NAT Gateway. O gateway NAT limpa todo o tráfego para o intervalo de endereços IP do prefixo.

  • Um gateway NAT não pode ser usado com endereços IP públicos IPv6 ou prefixos.

  • Um gateway NAT não pode ser usado com endereços IP públicos SKU básicos.

Portas SNAT

O inventário de portas SNAT é fornecido pelos endereços IP públicos, prefixos IP públicos ou ambos anexados a um gateway NAT. O inventário de portas SNAT é disponibilizado sob demanda para todas as instâncias dentro de uma sub-rede conectada ao gateway NAT. Nenhuma pré-alocação de portas SNAT por instância é necessária.

Para obter mais informações sobre portas SNAT e Azure NAT Gateway, consulte Source Network Address Translation (SNAT) with Azure NAT Gateway.

Quando várias sub-redes dentro de uma rede virtual são conectadas ao mesmo recurso de gateway NAT, o inventário de porta SNAT fornecido pelo gateway NAT é compartilhado em todas as sub-redes.

As portas SNAT servem como identificadores exclusivos para distinguir diferentes fluxos de conexão uns dos outros. A mesma porta SNAT pode ser usada para se conectar a diferentes pontos de extremidade de destino ao mesmo tempo.

Diferentes portas SNAT são usadas para fazer conexões com o mesmo ponto de extremidade de destino, a fim de distinguir diferentes fluxos de conexão uns dos outros. As portas SNAT que estão sendo reutilizadas para se conectar ao mesmo destino são colocadas em um temporizador de resfriamento de reutilização antes de poderem ser reutilizadas.

Diagrama de alocação de porta SNAT.

Figura: Alocação de porta SNAT

Um único gateway NAT pode escalar até 16 endereços IP. Cada endereço IP público do gateway NAT fornece 64.512 portas SNAT para fazer conexões de saída. Um gateway NAT pode ser dimensionado para mais de 1 milhão de portas SNAT. TCP e UDP são inventários de porta SNAT separados e não estão relacionados ao NAT Gateway.

Zonas de disponibilidade

Um gateway NAT pode ser criado em uma zona de disponibilidade específica ou colocado em nenhuma zona. Quando um gateway NAT é colocado em nenhuma zona, o Azure seleciona uma zona para o gateway NAT residir.

Os endereços IP públicos redundantes de zona podem ser usados com recursos de gateway NAT zonais ou sem zona.

A recomendação é configurar um gateway NAT para zonas de disponibilidade individuais. Além disso, ele deve ser anexado a sub-redes com instâncias privadas da mesma zona. Para obter mais informações sobre zonas de disponibilidade e o Gateway NAT do Azure, consulte Considerações de design de zonas de disponibilidade.

Diagrama de isolamento zonal criando pilhas zonais.

Depois que um gateway NAT é implantado, a seleção de zona não pode ser alterada.

Protocolos

O gateway NAT interage com cabeçalhos de transporte IP e IP de fluxos UDP e TCP. O NAT Gateway é agnóstico às cargas úteis da camada de aplicação. Outros protocolos IP não são suportados.

Redefinição de TCP

Um pacote de redefinição de TCP é enviado quando um gateway NAT deteta tráfego em um fluxo de conexão que não existe. O pacote de redefinição de TCP indica ao ponto de extremidade recetor que a liberação do fluxo de conexão ocorreu e qualquer comunicação futura nessa mesma conexão TCP falhará. A redefinição de TCP é unidirecional para um gateway NAT.

O fluxo de conexão pode não existir se:

  • O tempo limite ocioso foi atingido após um período de inatividade no fluxo de conexão e a conexão é silenciosamente descartada.

  • O remetente, do lado da rede do Azure ou do lado público da Internet, enviou tráfego depois que a conexão caiu.

Um pacote de redefinição de TCP é enviado somente após a deteção de tráfego no fluxo de conexão descartado. Esta operação significa que um pacote de redefinição de TCP pode não ser enviado imediatamente depois que um fluxo de conexão cai.

O sistema envia um pacote de redefinição de TCP em resposta à deteção de tráfego em um fluxo de conexão inexistente, independentemente de o tráfego ser originado do lado da rede do Azure ou do lado público da Internet.

Tempo limite de inatividade TCP

Um gateway NAT fornece um intervalo de tempo limite ocioso configurável de 4 minutos a 120 minutos para protocolos TCP. Os protocolos UDP têm um tempo limite de inatividade não configurável de 4 minutos.

Quando uma conexão fica ociosa, o gateway NAT mantém a porta SNAT até que a conexão ociosa atinja o tempo limite. Como os temporizadores de tempo limite de ociosidade longos podem aumentar desnecessariamente a probabilidade de exaustão da porta SNAT, não é recomendado aumentar a duração do tempo limite de ociosidade TCP para mais do que o tempo padrão de 4 minutos. O temporizador ocioso não afeta um fluxo que nunca fica ocioso.

Os keepalives TCP podem ser usados para fornecer um padrão de atualização de longas conexões ociosas e deteção de vida do ponto final. Para obter mais informações, consulte estes exemplos do .NET. Os keepalives TCP aparecem como ACKs duplicados para os pontos de extremidade, são baixos e invisíveis para a camada de aplicação.

Os temporizadores de tempo limite ocioso UDP não são configuráveis, os keepalives UDP devem ser usados para garantir que o valor de tempo limite ocioso não seja atingido e que a conexão seja mantida. Ao contrário das conexões TCP, um keepalive UDP habilitado em um lado da conexão só se aplica ao fluxo de tráfego em uma direção. Os keepalives UDP devem ser ativados em ambos os lados do fluxo de tráfego, a fim de manter o fluxo de tráfego vivo.

Temporizadores

Temporizadores de reutilização de porta

Os temporizadores de reutilização de porta determinam a quantidade de tempo após o fechamento de uma conexão que uma porta de origem está em espera antes que ela possa ser reutilizada para ir para o mesmo ponto de extremidade de destino pelo gateway NAT.

A tabela a seguir fornece informações sobre quando uma porta TCP fica disponível para reutilização no mesmo ponto de extremidade de destino pelo gateway NAT.

Temporizador Description valor
FINO TCP Depois que uma conexão é fechada por um pacote TCP FIN, um temporizador de 65 segundos é ativado que mantém pressionada a porta SNAT. A porta SNAT está disponível para reutilização após o término do temporizador. 65 segundos
TCP RST Depois que uma conexão é fechada por um pacote TCP RST (reset), um temporizador de 16 segundos é ativado que mantém pressionada a porta SNAT. Quando o temporizador termina, a porta fica disponível para reutilização. 16 segundos
TCP semiaberto Durante o estabelecimento da conexão, onde um ponto de extremidade de conexão está aguardando confirmação do outro ponto de extremidade, um temporizador de 30 segundos é ativado. Se nenhum tráfego for detetado, a conexão será fechada. Quando a conexão é fechada, a porta de origem fica disponível para reutilização no mesmo ponto de extremidade de destino. 30 segundos

Para o tráfego UDP, depois que uma conexão é fechada, a porta fica pressionada por 65 segundos antes de estar disponível para reutilização.

Temporizadores de tempo limite ociosos

Temporizador Description valor
Tempo limite de inatividade TCP As conexões TCP podem ficar ociosas quando nenhum dado é transmitido entre qualquer um dos pontos finais por um período prolongado de tempo. Um temporizador pode ser configurado de 4 minutos (padrão) a 120 minutos (2 horas) para atingir o tempo limite de uma conexão que ficou ociosa. O tráfego no fluxo redefine o temporizador de tempo limite ocioso. Configurável; 4 minutos (padrão) - 120 minutos
Tempo limite de inatividade UDP As conexões UDP podem ficar ociosas quando nenhum dado é transmitido entre qualquer um dos pontos finais por um período prolongado de tempo. Os temporizadores de tempo limite ocioso UDP são de 4 minutos e não são configuráveis. O tráfego no fluxo redefine o temporizador de tempo limite ocioso. Não configurável; 4 minutos

Nota

Estas definições do temporizador estão sujeitas a alterações. Os valores são fornecidos para ajudar na solução de problemas e você não deve depender de temporizadores específicos neste momento.

Largura de banda

Cada gateway NAT pode fornecer até um total de 50 Gbps de taxa de transferência. O limite da taxa de transferência de dados é dividido entre dados de saída e de entrada (resposta). A taxa de transferência de dados é limitada a 25 Gbps para dados de saída e 25 Gbps para dados de entrada (resposta) por recurso de gateway NAT. Você pode dividir suas implantações em várias sub-redes e atribuir cada sub-rede ou grupo de sub-redes a um gateway NAT para expansão.

Desempenho

Um gateway NAT pode suportar até 50.000 conexões simultâneas por endereço IP público para o mesmo ponto de extremidade de destino pela Internet para TCP e UDP. O gateway NAT pode processar pacotes de 1 milhão por segundo e dimensionar até 5 milhões de pacotes por segundo.

O número total de conexões que um gateway NAT pode suportar a qualquer momento é de até 2 milhões. Se o gateway NAT exceder 2 milhões de conexões, você verá um declínio na disponibilidade do caminho de dados e novas conexões falharão.

Limitações

  • Balanceadores de carga básicos e endereços IP públicos básicos não são compatíveis com o gateway NAT. Em vez disso, use balanceadores de carga SKU padrão e IPs públicos.

  • O gateway NAT não suporta ICMP

  • A fragmentação de IP não está disponível para o NAT Gateway.

  • O NAT Gateway não suporta endereços IP públicos com o tipo de configuração de roteamento internet. Para ver uma lista de serviços do Azure que dão suporte à configuração de roteamento da Internet em IPs públicos, consulte Serviços com suporte para roteamento pela Internet pública.

  • IPs públicos com proteção contra DDoS ativada não são suportados com gateway NAT. Para obter mais informações, consulte Limitações de DDoS.zzzzz

  • O Azure NAT Gateway não é suportado em uma arquitetura de rede de hub virtual segura (vWAN).

Próximos passos