Laboratório de Troubleshooting: Create and configure inbound NAT rules
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações reporta que conexões RDP para uma VM específica pararam de funcionar após uma janela de manutenção. O ambiente possui um Load Balancer Standard com IP público 20.30.10.50. A inbound NAT rule para a VM está listada como provisionada com sucesso no portal.
Informações coletadas durante a investigação:
Frontend IP: 20.30.10.50
Frontend port: 50010
Backend port: 3389
Protocol: TCP
Floating IP: Disabled
Target NIC: nic-vm-prod-03
Provisioning state: Succeeded
O administrador também informa que durante a manutenção foi criada uma nova load balancing rule na porta 443 para um backend pool diferente, e que o certificado TLS do servidor web foi renovado com sucesso. A VM vm-prod-03 está com status Running e responde a pings internamente.
Testes adicionais realizados a partir de uma VM dentro da mesma VNet:
# Executado de vm-jumpbox (10.0.1.10)
Test-NetConnection -ComputerName 10.0.2.15 -Port 3389
ComputerName : 10.0.2.15
RemotePort : 3389
TcpTestSucceeded : True
Qual é a causa raiz da falha no acesso RDP via IP público?
A) A load balancing rule criada na porta 443 gerou um conflito de frontend IP que desativou a NAT rule existente
B) O NSG associado à subnet ou NIC da VM passou a bloquear conexões TCP na porta 3389 originadas de fora da VNet
C) A renovação do certificado TLS reiniciou o serviço de RDP na VM, deixando a porta 3389 temporariamente indisponível
D) O IP público 20.30.10.50 foi desassociado do frontend IP configuration do Load Balancer durante a manutenção
Cenário 2 — Causa Raiz
Um engenheiro configura um inbound NAT rule pool em um Load Balancer Standard para permitir acesso SSH a instâncias de um Virtual Machine Scale Set. Após o deploy, ele tenta conectar e recebe o seguinte resultado:
$ ssh adminuser@40.90.22.11 -p 50000
ssh: connect to host 40.90.22.11 port 50000: Connection timed out
$ ssh adminuser@40.90.22.11 -p 50001
ssh: connect to host 40.90.22.11 port 50001: Connection timed out
Todas as portas testadas resultam em timeout. O engenheiro verifica o estado do NAT rule pool no portal e encontra:
NAT rule pool name: nat-pool-ssh
Frontend port start: 50000
Backend port: 22
Protocol: TCP
Backend pool: vmss-be-pool
Provisioning state: Succeeded
Instances mapped: 3
O engenheiro também confirma que as três instâncias do VMSS estão no estado Running e que um health probe HTTP na porta 80 está retornando Healthy para todas elas. O serviço SSH está ativo e escutando na porta 22 em todas as instâncias, confirmado via console serial.
Qual é a causa raiz do timeout em todas as portas?
A) O health probe está configurado para HTTP/80, mas deveria estar em TCP/22 para que a NAT rule pool funcione corretamente
B) O NAT rule pool exige que as instâncias do VMSS tenham IPs públicos individuais além do mapeamento de porta
C) O NSG associado ao VMSS não possui regra de entrada permitindo TCP nas portas do intervalo de frontend (50000+) nem na porta 22 originada do Load Balancer
D) O frontend port start 50000 está acima do limite suportado por NAT rule pools no Load Balancer Standard
Cenário 3 — Decisão de Ação
Durante uma auditoria, a equipe de segurança identifica que a inbound NAT rule de uma VM de produção crítica está com Floating IP habilitado, mas a aplicação que roda nessa VM nunca foi configurada para escutar no IP do frontend do Load Balancer. A VM processa transações financeiras em tempo real e não pode ter interrupção durante o horário comercial (07h00 às 19h00). São 14h30 de uma segunda-feira.
A equipe confirma que, apesar da configuração incorreta do Floating IP, as conexões estão funcionando atualmente porque o cliente acessa via um segundo endereço IP configurado diretamente na NIC da VM como IP secundário, que coincide com o IP do frontend por uma configuração legada não documentada.
A causa está identificada: a configuração de Floating IP está incorreta para o modelo de uso atual e precisa ser corrigida. Qual é a ação correta neste momento?
A) Desabilitar o Floating IP na NAT rule imediatamente, pois a correção não requer reinicialização da VM e o risco de impacto é baixo
B) Remover o IP secundário legado da NIC da VM agora para forçar o tráfego a seguir o caminho correto sem Floating IP
C) Documentar a configuração atual, planejar a correção para uma janela de manutenção fora do horário comercial e validar o comportamento em ambiente de teste antes
D) Criar uma nova NAT rule sem Floating IP apontando para a mesma NIC e deletar a regra atual enquanto o tráfego migra
Cenário 4 — Sequência de Diagnóstico
Um operador reporta que conexões externas para uma VM via inbound NAT rule estão falhando com timeout imediato. O ambiente nunca funcionou desde a criação, ou seja, não houve regressão. Abaixo estão os passos de investigação disponíveis, em ordem aleatória:
[P1] Verificar se o NSG da NIC/subnet permite tráfego na porta de backend
[P2] Confirmar que a VM esta no estado Running e o servico esta escutando na porta de backend
[P3] Confirmar que o IP publico esta associado ao frontend IP configuration do Load Balancer
[P4] Verificar o Provisioning State da inbound NAT rule no portal
[P5] Testar conectividade interna direta para a porta de backend a partir de outra VM na mesma VNet
Qual sequência representa o raciocínio diagnóstico correto, do mais geral para o mais específico?
A) P4 → P3 → P2 → P5 → P1
B) P3 → P4 → P2 → P1 → P5
C) P4 → P3 → P1 → P2 → P5
D) P2 → P5 → P3 → P4 → P1
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no teste interno bem-sucedido: TcpTestSucceeded : True na porta 3389 a partir de uma VM dentro da VNet confirma que a VM está saudável, o serviço RDP está ativo e o problema está na camada que só afeta tráfego externo. O Load Balancer em si não é o problema porque o provisionamento da NAT rule está como Succeeded.
O componente que diferencia tráfego externo de interno e que pode ter sido alterado durante a manutenção sem relação direta com a tarefa principal é o NSG. NSGs são frequentemente modificados em janelas de manutenção como parte de revisões de segurança, e uma regra negando RDP de fora da VNet explicaria exatamente o sintoma observado.
A alternativa A é um equívoco clássico: load balancing rules e NAT rules podem coexistir no mesmo frontend IP em portas diferentes sem conflito. A alternativa C é implausível porque o teste interno funcionou, descartando que o serviço RDP esteja parado. A alternativa D, embora tecnicamente possível, teria resultado em Provisioning State diferente e afetaria todas as regras do Load Balancer, não apenas o acesso externo.
O distrator mais perigoso é a alternativa A: um administrador sob pressão poderia gastar tempo procurando conflitos de regras no Load Balancer enquanto ignora o NSG, que é a causa real.
Gabarito — Cenário 2
Resposta: C
O timeout em todas as portas, combinado com o serviço SSH confirmado ativo e o NAT rule pool provisionado com instâncias mapeadas, direciona o diagnóstico para uma camada de bloqueio antes mesmo de o pacote chegar à aplicação. O NSG é essa camada.
Em ambientes com VMSS, existem dois pontos onde o NSG pode bloquear: na subnet do VMSS ou nas NICs das instâncias. Para que a NAT rule pool funcione, o NSG precisa permitir tanto o tráfego nas portas de frontend (50000, 50001, 50002) chegando do IP público quanto o tráfego na porta 22 originado do IP do Load Balancer (AzureLoadBalancer service tag). A ausência de qualquer uma dessas regras resulta em timeout.
A alternativa A representa um equívoco frequente: o health probe e a NAT rule pool são independentes. O probe determina se a instância recebe tráfego balanceado, mas não controla o funcionamento do NAT. A alternativa B é falsa: NAT rule pools foram projetados exatamente para dispensar IPs públicos individuais. A alternativa D é incorreta pois 50000 é uma porta válida dentro dos limites do Load Balancer Standard.
A informação sobre o health probe retornando Healthy é deliberadamente irrelevante e serve para atrair o diagnóstico equivocado da alternativa A.
Gabarito — Cenário 3
Resposta: C
A restrição determinante neste cenário não é técnica, é operacional: são 14h30 em horário comercial, a VM processa transações financeiras em tempo real e qualquer erro na correção pode causar interrupção imediata. O fato de as conexões estarem funcionando, mesmo que por um caminho legado não documentado, significa que não há incidente ativo que justifique ação imediata.
A alternativa A ignora um risco crítico: desabilitar o Floating IP altera como o Load Balancer entrega pacotes à NIC. Mesmo sem reinicialização da VM, se a aplicação ou o IP secundário legado não se comportarem como esperado após a mudança, o serviço cai em produção. A alternativa B é a mais perigosa: remover o IP secundário sem desabilitar o Floating IP primeiro garantiria interrupção imediata, pois a aplicação passaria a receber pacotes com destino ao IP do frontend sem nenhuma configuração para aceitá-los. A alternativa D introduz uma janela de dupla configuração e risco de conexões sendo perdidas durante a transição, também em horário de pico.
O princípio aplicado aqui é: quando o sistema está funcionando e o risco de correção imediata é maior que o risco de adiar, a ação correta é planejar, não agir.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: P4 → P3 → P2 → P5 → P1.
O raciocínio parte do mais amplo para o mais específico, eliminando hipóteses de fora para dentro:
- P4 (Provisioning State): confirmar que a regra existe e está válida antes de qualquer outro passo. Se o provisionamento falhou, os demais passos são irrelevantes.
- P3 (IP público associado): verificar que o plano de dados do Load Balancer tem conectividade externa. Sem isso, nenhuma NAT rule pode receber tráfego externo.
- P2 (VM Running + serviço ativo): confirmar que o destino está operacional. Um serviço parado explicaria a falha independentemente de qualquer configuração de rede.
- P5 (teste interno): isolar se o problema está na VM/aplicação ou na camada de rede/NAT. Se o teste interno falha, o problema está na VM. Se passa, o problema está entre o Load Balancer e a VM.
- P1 (NSG): verificado por último porque requer o contexto dos passos anteriores para ser interpretado corretamente.
A alternativa D representa o erro mais comum: começar pela VM (o destino) antes de validar que o caminho de entrada está íntegro, desperdiçando tempo em um componente que pode estar perfeitamente funcional.
Árvore de Troubleshooting: Create and configure inbound NAT rules
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária) |
| Laranja | Verificação intermediária ou ponto de validação |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz que representa o sintoma observado e responda cada pergunta com base no que você consegue verificar diretamente no ambiente. Siga o ramo correspondente à sua resposta sem pular etapas. Cada caminho termina em uma causa específica acompanhada de uma ação corretiva. Se o caminho chegar a um nó de ação e o problema persistir após a correção, retorne ao nó anterior e reavalie a resposta dada, pois uma premissa pode ter sido assumida sem verificação direta.