Laboratório de Troubleshooting: Identify appropriate use cases for Azure NAT Gateway
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que um conjunto de VMs em produção parou de conseguir estabelecer novas conexões de saída para uma API externa. As VMs estão em uma sub-rede associada a um NAT Gateway com dois endereços IP públicos. O ambiente tem funcionado sem problemas por seis meses.
O engenheiro responsável coleta as seguintes informações:
- A sub-rede contém 180 VMs ativas
- Cada VM mantém em média 850 conexões de saída simultâneas para o mesmo endpoint externo
- O NAT Gateway está com status Succeeded no portal do Azure
- Um novo Network Security Group foi associado à sub-rede há três dias, liberando a porta 443 de saída
- Os logs do NAT Gateway mostram o seguinte contador com crescimento contínuo nas últimas horas:
Metric: SNATConnectionCount
State: Failed
Value: 38.420 (last 10 minutes)
Qual é a causa raiz das falhas de conexão observadas?
A) O novo NSG está bloqueando o tráfego de retorno das conexões estabelecidas, pois não há regra de entrada correspondente para o tráfego assimétrico.
B) O número de portas SNAT disponíveis foi esgotado: com 180 VMs e 850 conexões simultâneas cada, a demanda supera o total de portas fornecidas pelos dois IPs públicos do NAT Gateway.
C) O NAT Gateway não suporta mais de 100 VMs por sub-rede; a configuração atual excede o limite documentado do serviço.
D) O endpoint externo está bloqueando requisições originadas de múltiplos IPs do NAT Gateway alternadamente, interpretando o comportamento como tráfego suspeito.
Cenário 2 — Decisão de Ação
A causa raiz foi identificada: o NAT Gateway de uma sub-rede de workloads críticos está associado a apenas um endereço IP público, e o volume de conexões simultâneas de saída atingiu o limite de portas SNAT disponíveis. O esgotamento está causando falhas intermitentes em chamadas para serviços externos de pagamento.
O contexto operacional é o seguinte:
- O ambiente está em produção ativa com SLA de 99,9%
- O parceiro de pagamentos aplica allowlist por IP; qualquer novo IP deve ser comunicado com 48 horas de antecedência
- A equipe de redes tem permissão para modificar o NAT Gateway sem janela de manutenção
- Existe um segundo endereço IP público já provisionado na assinatura, ainda não associado a nenhum recurso
- O time de negócios está presente e disponível para aprovar comunicações urgentes ao parceiro
Qual é a ação correta a tomar neste momento?
A) Substituir o NAT Gateway atual por um novo com configuração de dois IPs públicos, realizando a troca durante o horário de menor tráfego.
B) Associar imediatamente o segundo IP público ao NAT Gateway existente, sem aguardar, pois a adição de IP não interrompe o tráfego existente; notificar o parceiro em paralelo para atualizar a allowlist.
C) Criar uma nova sub-rede com um NAT Gateway separado e migrar metade das VMs para distribuir a carga de portas SNAT entre dois recursos.
D) Associar o segundo IP público ao NAT Gateway e aguardar a confirmação do parceiro antes de ativar qualquer tráfego pelo novo IP, mantendo o IP atual como único até a allowlist ser atualizada.
Cenário 3 — Causa Raiz
Um administrador configura um novo ambiente e reporta que uma VM específica, chamada vm-app-01, não está usando o NAT Gateway da sub-rede para acessar a internet, apesar de a sub-rede estar corretamente associada ao recurso. Outras VMs na mesma sub-rede funcionam normalmente através do NAT Gateway.
O administrador compartilha o seguinte levantamento do ambiente:
Sub-rede: snet-app (10.2.0.0/24)
NAT Gateway: natgw-prod (associado, status: Succeeded)
IP publico do NAT Gateway: 20.10.5.80
VM: vm-app-01
NIC: nic-app-01
IP privado: 10.2.0.10
IP publico atribuido a NIC: 40.80.120.55
VM: vm-app-02
NIC: nic-app-02
IP privado: 10.2.0.11
IP publico atribuido a NIC: nenhum
O administrador também informa que o NSG da sub-rede foi criado há uma semana e que a tabela de rotas associada à sub-rede não possui rotas personalizadas.
Qual é a causa raiz do comportamento observado em vm-app-01?
A) O NSG da sub-rede, criado recentemente, está interceptando o tráfego de vm-app-01 antes que ele alcance o NAT Gateway, desviando o fluxo de saída.
B) A tabela de rotas sem rotas personalizadas não inclui uma rota explícita para o NAT Gateway, por isso vm-app-01 não consegue alcançar o recurso.
C) O endereço IP público atribuído diretamente à NIC de vm-app-01 tem precedência sobre o NAT Gateway da sub-rede, fazendo com que o tráfego de saída use o IP 40.80.120.55.
D) O NAT Gateway limita o número de IPs privados atendidos por sub-rede; como vm-app-01 foi a última VM adicionada, ela foi excluída automaticamente do pool SNAT.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "VMs em uma sub-rede específica não conseguem acessar a internet. Outras sub-redes na mesma VNet funcionam normalmente."
O engenheiro tem acesso ao portal do Azure e ao terminal. Abaixo estão cinco passos de investigação possíveis, apresentados fora de ordem:
[P1] Verificar se o NAT Gateway associado à sub-rede tem status "Succeeded"
e se possui ao menos um IP público ou prefixo de IP associado
[P2] Executar um teste de conectividade de saída a partir de uma VM da sub-rede,
apontando para um endpoint externo conhecido (ex: curl -v https://example.com)
[P3] Confirmar que a sub-rede em questão está efetivamente associada
a um NAT Gateway (e não a outra sub-rede)
[P4] Verificar se existe uma UDR (User Defined Route) com rota 0.0.0.0/0
associada à sub-rede que possa estar sobrescrevendo o caminho do NAT Gateway
[P5] Analisar as regras do NSG da sub-rede para confirmar que o tráfego
de saída nas portas necessarias nao esta sendo bloqueado
Qual é a sequência correta de investigação?
A) P2 -> P3 -> P1 -> P5 -> P4
B) P3 -> P1 -> P4 -> P5 -> P2
C) P1 -> P3 -> P5 -> P4 -> P2
D) P4 -> P3 -> P1 -> P2 -> P5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O cálculo confirma o esgotamento: cada IP público do NAT Gateway fornece 64.512 portas SNAT. Com dois IPs, o total disponível é 129.024 portas. Com 180 VMs mantendo 850 conexões simultâneas cada, a demanda é de 153.000 conexões, superando a capacidade em aproximadamente 24.000 portas. O contador SNATConnectionCount no estado Failed com crescimento contínuo é a confirmação direta no log.
A informação sobre o novo NSG é o elemento irrelevante proposital do cenário. O NSG libera a porta 443 de saída, o que é compatível com o tráfego esperado. NSGs não afetam portas SNAT nem o comportamento do NAT Gateway. Incluí-la força o leitor a resistir ao viés de causalidade temporal ("aconteceu depois, logo foi a causa").
A alternativa A é o distrator mais perigoso: confunde o tráfego assimétrico de estado de conexão TCP com bloqueio de NSG, o que não tem relação com esgotamento de portas. A alternativa C inventa um limite que não existe na documentação do NAT Gateway. A alternativa D atribui ao endpoint externo um comportamento que contradiz o que os logs locais já revelam diretamente.
Gabarito — Cenário 2
Resposta: D
A restrição crítica do cenário é a allowlist por IP do parceiro de pagamentos. Adicionar um novo IP ao NAT Gateway é uma operação que não interrompe o tráfego existente, mas o novo IP começará a ser usado imediatamente pelo NAT Gateway para balancear conexões de saída. Se o parceiro ainda não atualizou a allowlist, conexões que saírem pelo novo IP serão rejeitadas pelo lado externo, o que agrava o problema em vez de resolvê-lo.
A alternativa B é tecnicamente correta em relação ao NAT Gateway, mas ignora a restrição de allowlist, que é o ponto central do cenário. Em produção ativa, agir sem coordenar com o parceiro significaria introduzir um segundo ponto de falha imediato. A alternativa A é desnecessariamente disruptiva: substituir o NAT Gateway inteiro causa indisponibilidade, quando apenas adicionar um IP já resolve o problema de capacidade. A alternativa C introduz complexidade arquitetural desnecessária e impacto de migração sem justificativa técnica.
A ação correta é associar o IP ao recurso e aguardar a confirmação do parceiro antes que o tráfego de saída passe a usar o novo endereço de forma irrestrita.
Gabarito — Cenário 3
Resposta: C
A pista definitiva está na configuração da NIC de vm-app-01: ela possui um endereço IP público próprio (40.80.120.55) atribuído diretamente. O Azure aplica uma ordem de precedência bem definida para tráfego de saída: IP público na NIC tem prioridade sobre o NAT Gateway da sub-rede. Portanto, vm-app-01 usa seu próprio IP para saída, não o IP do NAT Gateway.
O comportamento não é uma falha. É o funcionamento esperado da precedência de saída do Azure.
Os elementos irrelevantes são a criação recente do NSG e a ausência de rotas personalizadas na tabela de rotas. Nenhum dos dois tem relação com a precedência de IP de saída. O NSG não interfere na escolha de qual IP será usado para SNAT. A ausência de UDR significa que o roteamento padrão está ativo, o que é compatível com o NAT Gateway funcionar normalmente para as demais VMs.
A alternativa A é o distrator baseado no elemento irrelevante temporal (NSG recente). A alternativa B confunde roteamento com tradução de endereço: o NAT Gateway não requer rota explícita na tabela de rotas para funcionar. A alternativa D inventa um comportamento de exclusão que não existe no serviço.
Gabarito — Cenário 4
Resposta: B
A sequência correta de diagnóstico segue o princípio de validar do mais externo para o mais específico, eliminando hipóteses estruturais antes de testar comportamentos:
P3 confirma se a sub-rede está de fato associada ao NAT Gateway, pois sem essa associação nenhuma outra investigação faz sentido.
P1 valida se o NAT Gateway está operacional e tem ao menos um IP público, pois um recurso em estado degradado ou sem IP não fornecerá saída.
P4 verifica se uma UDR está sobrescrevendo o caminho padrão do NAT Gateway, o que é uma causa comum e silenciosa de falha de saída.
P5 confirma se o NSG está bloqueando o tráfego de saída antes que ele alcance o NAT Gateway.
P2 é o teste de validação final: só faz sentido executá-lo após confirmar que a infraestrutura está corretamente configurada, pois sem isso o resultado do teste não permite distinguir entre as causas possíveis.
A alternativa A começa pelo teste ativo (P2), o que produz apenas um sintoma sem diagnóstico. A alternativa C inicia pela saúde do NAT Gateway antes de confirmar se ele sequer está associado. A alternativa D começa pela UDR, que é uma hipótese específica, pulando a verificação estrutural básica.
Árvore de Troubleshooting: Identify appropriate use cases for Azure NAT Gateway
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou de estado) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação intermediária ou validação |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma e siga as ramificações respondendo cada pergunta com base no que você observa no ambiente. Perguntas de cor azul exigem verificação ativa no portal, via CLI ou via métricas antes de avançar. Ao atingir um nó vermelho, você identificou a causa; o nó verde imediatamente ligado a ele indica a ação correta. Nós laranjas sinalizam pontos onde é necessário coletar evidência adicional antes de continuar o diagnóstico.