Laboratório de Troubleshooting: Implement Azure NAT Gateway
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações reporta que VMs em uma sub-rede de produção passaram a falhar ao tentar conectar serviços externos na internet. O problema começou logo após uma janela de manutenção na qual foram realizadas três alterações simultâneas: criação de um novo NAT Gateway, associação de um Public IP Prefix /28 ao NAT Gateway, e criação de uma nova tabela de rotas UDR para a sub-rede.
O time confirma que o NSG da sub-rede não foi alterado e que as VMs não possuem Public IPs individuais nas NICs.
O seguinte teste foi executado a partir de uma das VMs afetadas:
curl -s --max-time 10 https://ifconfig.me
# resultado: curl: (28) Operation timed out after 10000 milliseconds
A verificação do NAT Gateway no portal mostra status Succeeded e o Public IP Prefix aparece como associado. O engenheiro responsável confirma que o nome do NAT Gateway está correto e que ele foi criado na mesma região da VNet.
Qual é a causa raiz da falha de conectividade de saída?
A) O Public IP Prefix /28 é inválido para uso com NAT Gateway; o tamanho mínimo suportado é /31
B) A nova tabela de rotas UDR foi associada à sub-rede, mas a rota padrão 0.0.0.0/0 aponta para um next hop diferente de Internet, sobrepondo o comportamento do NAT Gateway
C) O NAT Gateway não foi associado à sub-rede após sua criação; o status Succeeded indica apenas que o recurso foi provisionado
D) O NSG da sub-rede está bloqueando o tráfego de saída porque regras de outbound padrão não permitem tráfego para a internet quando um NAT Gateway está presente
Cenário 2 — Decisão de Ação
A causa do problema a seguir já foi identificada e está declarada no enunciado.
Uma empresa de e-commerce opera um cluster de VMs de processamento em uma sub-rede associada a um NAT Gateway com dois Public IPs. Nos últimos dias, o time de monitoramento registrou falhas intermitentes em novas conexões de saída para APIs de pagamento externas durante picos de processamento. A análise das métricas do NAT Gateway confirmou que as falhas ocorrem exclusivamente quando a métrica SNAT Connection Count atinge o limite máximo de portas disponíveis nos dois IPs configurados.
A causa é exaustão de portas SNAT. O ambiente é de produção crítica, com SLA ativo. A adição de novos IPs públicos avulsos ao NAT Gateway pode ser feita sem reinicialização do recurso e sem impacto nas conexões SNAT já estabelecidas.
O gerente solicita a solução mais rápida e segura para restaurar capacidade sem interromper conexões existentes.
Qual é a ação correta?
A) Remover o NAT Gateway da sub-rede, associar um Azure Load Balancer externo com outbound rules e mais IPs públicos, e então reassociar o NAT Gateway
B) Adicionar imediatamente IPs públicos avulsos ao NAT Gateway existente, aumentando o pool de portas SNAT disponíveis sem interromper as conexões ativas
C) Reiniciar as VMs do cluster para liberar as portas SNAT presas em estado TIME_WAIT antes de adicionar novos IPs
D) Aumentar o idle timeout do NAT Gateway para 120 minutos para reduzir a rotatividade de portas e liberar capacidade para novas conexões
Cenário 3 — Causa Raiz
Um time de segurança configurou um novo ambiente isolado para testes de integração. A topologia usa uma VNet com duas sub-redes:
| Sub-rede | Finalidade | NAT Gateway associado |
|---|---|---|
| snet-app (10.2.1.0/24) | VMs de aplicação | nat-test |
| snet-data (10.2.2.0/24) | VMs de banco de dados | nenhum |
O NAT Gateway nat-test tem um único Public IP: 20.80.45.12.
O time reporta que as VMs em snet-data estão conseguindo fazer requisições para a internet normalmente, o que não era o comportamento esperado. O time de segurança afirma que nenhum Public IP foi associado às NICs dessas VMs.
O engenheiro verifica e confirma que o NSG de snet-data possui uma regra de saída explícita com prioridade 100 permitindo todo o tráfego para a tag de serviço Internet. A sub-rede snet-data não possui UDR associada.
# Executado em VM de snet-data:
curl -s https://ifconfig.me
# resposta: 52.191.77.230
Qual é a causa raiz do comportamento inesperado?
A) O NAT Gateway nat-test está sendo compartilhado automaticamente com snet-data porque ambas as sub-redes pertencem à mesma VNet
B) A regra de NSG com prioridade 100 permitindo saída para Internet está sobrepondo o isolamento esperado e forçando o roteamento direto para a internet
C) As VMs em snet-data estão usando o roteamento padrão do sistema da VNet, que inclui uma rota de internet implícita, e sem NAT Gateway ou bloqueio explícito de saída, o tráfego sai pelo IP público da interface de rede do host subjacente
D) O IP 52.191.77.230 pertence ao NAT Gateway nat-test, indicando que ele foi indevidamente associado a snet-data durante a configuração
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe um alerta: VMs em uma sub-rede com NAT Gateway configurado estão falhando ao conectar endpoints externos. O ambiente esteve funcionando normalmente por semanas.
Os seguintes passos de investigação estão disponíveis, mas fora de ordem:
- Verificar as métricas do NAT Gateway, especialmente SNAT Connection Count e Dropped Packets, para identificar sinais de exaustão ou falha de encaminhamento
- Confirmar se o NAT Gateway está associado à sub-rede afetada acessando as configurações da sub-rede no portal ou via CLI
- Verificar se houve alteração recente em UDRs associadas à sub-rede que possa estar desviando o tráfego de saída
- Executar um teste de conectividade simples a partir de uma das VMs afetadas para confirmar o escopo e a natureza da falha
- Checar o status de provisionamento do NAT Gateway e confirmar se o Public IP ou Prefix associado ainda está presente e ativo
Qual é a sequência de diagnóstico mais eficiente e logicamente correta?
A) 2 -> 5 -> 3 -> 1 -> 4
B) 4 -> 2 -> 5 -> 3 -> 1
C) 1 -> 4 -> 2 -> 5 -> 3
D) 5 -> 2 -> 4 -> 1 -> 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
O ponto crítico do cenário está na frase "criação de uma nova tabela de rotas UDR para a sub-rede". O NAT Gateway fornece conectividade de saída, mas ele precisa estar associado à sub-rede para entrar em efeito. O status Succeeded confirma apenas que o recurso foi provisionado com sucesso no Azure, não que ele foi vinculado a nenhuma sub-rede específica.
A pista decisiva é que o enunciado descreve três ações distintas realizadas durante a manutenção, mas não menciona explicitamente a associação do NAT Gateway à sub-rede como um passo executado. Essa omissão é a causa raiz.
A alternativa B é o distrator mais perigoso: uma UDR com next hop errado de fato pode sobrepor o NAT Gateway, mas o enunciado não descreve o conteúdo da rota criada, apenas que ela foi criada. Agir com base nessa hipótese sem validar a associação do NAT Gateway seria um erro de sequência diagnóstica. A alternativa A está factualmente errada: o NAT Gateway suporta prefixos /28 normalmente. A alternativa D está errada porque regras de outbound padrão do NSG permitem tráfego de saída para a internet por padrão, e o NAT Gateway não altera esse comportamento.
Gabarito — Cenário 2
Resposta: B
A causa está declarada: exaustão de portas SNAT. O enunciado também fornece a informação crítica de que a adição de IPs públicos ao NAT Gateway pode ser feita sem reinicialização e sem impacto nas conexões existentes. Isso elimina qualquer justificativa para ações disruptivas.
A alternativa B é a única que atende às três restrições do cenário: resolve a causa real (falta de portas SNAT), é rápida, e é segura para produção com SLA ativo.
A alternativa D representa o erro mais comum: aumentar o idle timeout reduz a rotatividade de portas para sessões já existentes, mas não aumenta o número total de portas disponíveis e pode até agravar o problema ao manter portas ocupadas por mais tempo em sessões ociosas. A alternativa C adiciona indisponibilidade ao problema sem aumentar a capacidade de SNAT. A alternativa A é tecnicamente válida como solução arquitetural, mas é disruptiva, demorada e desnecessária dado o contexto.
Gabarito — Cenário 3
Resposta: C
A causa raiz é o roteamento padrão do sistema da VNet. Toda VNet no Azure inclui uma rota de sistema implícita para 0.0.0.0/0 com next hop Internet. Quando uma sub-rede não tem NAT Gateway associado, não tem UDR sobrepondo essa rota, e as VMs não possuem Public IP nas NICs, o Azure ainda permite que o tráfego de saída ocorra usando o IP público do host subjacente (SNAT implícito da plataforma). Esse comportamento é o oposto do que muitas equipes esperam: a ausência de NAT Gateway não bloqueia saída, apenas remove o controle sobre o IP usado.
A informação irrelevante no enunciado é a regra de NSG com prioridade 100. Ela permite saída, mas o NSG nunca foi o mecanismo de bloqueio relevante aqui; o problema é arquitetural. O leitor que focou no NSG foi desviado propositalmente.
A alternativa A está errada: o NAT Gateway não é compartilhado entre sub-redes automaticamente; ele precisa ser associado explicitamente a cada uma. A alternativa D pode ser refutada verificando que o IP 52.191.77.230 não é 20.80.45.12, ou seja, não é o IP do NAT Gateway nat-test. Agir com base na alternativa D levaria o engenheiro a procurar um problema de configuração que não existe.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 4 -> 2 -> 5 -> 3 -> 1, que segue a lógica de diagnóstico progressivo do mais simples e observável para o mais específico e técnico.
Passo 4 confirma o escopo real da falha antes de qualquer investigação de infraestrutura, evitando diagnóstico de um problema que pode ser localizado ou transitório. Passo 2 verifica a associação do NAT Gateway à sub-rede, que é o requisito mais básico de funcionamento. Passo 5 valida o estado do próprio recurso e seus IPs associados. Passo 3 investiga alterações recentes em UDR, que poderiam desviar o tráfego de saída silenciosamente. Passo 1 analisa métricas para identificar exaustão ou falha de encaminhamento, sendo o passo mais específico e que requer contexto dos anteriores para ser interpretado corretamente.
A alternativa C comete o erro de começar pelas métricas antes de confirmar se o problema é real e qual é seu escopo. A alternativa A começa pela associação sem confirmar o sintoma, o que desperdiça tempo se o problema for intermitente. A alternativa D começa pelo status do recurso, pulando a confirmação do sintoma, e então vai para a associação antes de testar conectividade.
Árvore de Troubleshooting: Implement Azure NAT Gateway
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial, ponto de entrada do diagnóstico |
| Azul | Pergunta diagnóstica fechada e verificável |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz que descreve o sintoma observado e responda cada pergunta diagnóstica com base no que você consegue verificar diretamente no portal, na CLI ou dentro da VM. Siga o caminho correspondente à sua resposta até chegar a um nó de causa identificada. A partir da causa, a ação recomendada associada indica a correção precisa a aplicar. Nunca pule perguntas intermediárias: a ordem das verificações evita ações corretivas aplicadas à hipótese errada.