Laboratório de Troubleshooting: Associate public IP addresses to resources
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento reporta que uma máquina virtual recém-criada em Azure não está acessível pela internet na porta 443. A VM hospeda um serviço HTTPS interno que foi promovido para produção nesta semana.
O engenheiro responsável verifica a configuração e coleta as seguintes informações:
VM: vm-prod-api-01
Região: East US 2
Tamanho: Standard_D2s_v3
SO: Ubuntu 22.04 LTS
NIC: nic-prod-api-01
IP público associado: pip-prod-api-01 (SKU Standard, Estático)
IP público atribuído: 20.x.x.x (confirmado no portal)
Subnet: snet-backend (10.10.2.0/24)
NSG associado à NIC: nsg-prod-api-01
Regras de entrada ativas no NSG:
| Prioridade | Nome | Porta | Protocolo | Origem | Destino | Ação |
|---|---|---|---|---|---|---|
| 100 | Allow-SSH | 22 | TCP | Internet | Any | Allow |
| 65000 | AllowVnetIn | Any | Any | VNet | VNet | Allow |
| 65500 | DenyAllIn | Any | Any | Any | Any | Deny |
O engenheiro confirma que o serviço HTTPS está ativo e escutando na porta 443 dentro da VM, e que o IP público está corretamente associado à NIC. O grupo de recursos tem tags de ambiente e centro de custo devidamente preenchidas.
Qual é a causa raiz da inacessibilidade na porta 443?
A) O SKU Standard do IP público bloqueia tráfego de entrada por padrão enquanto não houver um Load Balancer na frente da VM
B) Não existe regra explícita de NSG permitindo tráfego de entrada na porta 443 a partir da internet
C) A subnet snet-backend não é adequada para hospedar VMs com IP público; o recurso deveria estar em uma subnet de front-end
D) O IP público Estático de SKU Standard requer associação a uma interface de rede do tipo acelerada para funcionar corretamente
Cenário 2 — Decisão de Ação
O time de plataforma identificou que um Standard Load Balancer público de produção está utilizando um endereço IP público de SKU Basic associado há mais de um ano. A carga no ambiente é alta e o Load Balancer atende aplicações críticas sem janela de manutenção disponível nas próximas três semanas.
A causa do problema está clara: a associação de um IP Basic a um Standard Load Balancer é uma configuração inválida segundo a documentação atual da Microsoft, e a plataforma entrou nesse estado por conta de uma migração de SKU do Load Balancer realizada sem revisão completa dos recursos dependentes.
A equipe tem permissões de Contributor no Resource Group e acesso ao portal do Azure e ao CLI.
Qual é a ação correta a tomar neste momento?
A) Excluir imediatamente o IP público Basic e criar um novo IP de SKU Standard, associando-o ao Load Balancer sem aguardar janela de manutenção
B) Converter o IP público Basic para SKU Standard usando o comando az network public-ip update --sku Standard e reassociá-lo ao Load Balancer
C) Registrar o problema no backlog com prioridade alta, documentar a configuração atual e aguardar a janela de manutenção para executar a substituição com controle de impacto
D) Associar um segundo IP público de SKU Standard ao Load Balancer agora e remover o IP Basic após confirmar que o tráfego foi redirecionado
Cenário 3 — Causa Raiz
Um engenheiro de redes relata que tentou associar um endereço IP público existente a uma nova interface de rede (NIC) de uma VM e recebeu o seguinte erro no portal do Azure:
Cannot associate public IP address 'pip-shared-01' to network interface 'nic-vm-new-03'.
The public IP address is already associated to resource '/subscriptions/.../networkInterfaces/nic-vm-legacy-05'.
Operation failed with status: 'Conflict'. Error code: 'PublicIPAddressAlreadyInUse'
O engenheiro verifica no portal que a VM associada à nic-vm-legacy-05 está no estado Stopped há 45 dias. O IP público pip-shared-01 é do SKU Basic com alocação Dinâmica. A equipe de capacidade confirma que há endereços IP públicos disponíveis no pool da assinatura e que o limite de IPs públicos não foi atingido.
O engenheiro acredita que o problema é causado pelo limite de IPs públicos por assinatura e abre um ticket de suporte para aumento de cota.
Qual é a causa raiz real do problema?
A) O SKU Basic com alocação Dinâmica não pode ser associado a NICs de VMs novas sem antes ser atualizado para SKU Standard
B) Uma VM no estado Stopped ainda mantém a associação da NIC com o IP público; o IP precisa ser desassociado antes de ser reatribuído
C) O limite de IPs públicos da assinatura foi atingido e o novo IP precisa ser solicitado via aumento de cota
D) O IP público de SKU Basic com alocação Dinâmica é liberado automaticamente apenas quando a VM é desalocada, não quando está no estado Stopped; é necessário desalocar a VM para liberar o IP
Cenário 4 — Sequência de Diagnóstico
Um operador recebe um alerta de que uma aplicação exposta via Azure Firewall parou de responder a conexões externas. O Azure Firewall está em uma VNet de hub com múltiplos IPs públicos associados via Public IP Prefix. Nenhuma mudança de infraestrutura foi registrada no Change Management nas últimas 24 horas.
Os passos de investigação disponíveis são:
- Verificar se as regras DNAT no Azure Firewall estão ativas e apontam para o IP interno correto da aplicação
- Confirmar que os endereços IP públicos do Public IP Prefix ainda estão associados ao Azure Firewall no portal
- Verificar nos logs do Azure Firewall (via Log Analytics) se há tráfego sendo recebido e descartado ou se não há tráfego chegando ao firewall
- Testar conectividade de fora da VNet diretamente para o IP público do Azure Firewall usando
Test-NetConnectionoucurl - Verificar a tabela de rotas efetivas da subnet do Azure Firewall para confirmar que o tráfego de saída está sendo roteado corretamente
Qual é a sequência correta de diagnóstico progressivo para este cenário?
A) 2, 1, 4, 3, 5
B) 4, 3, 2, 1, 5
C) 4, 2, 3, 1, 5
D) 1, 4, 3, 2, 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A tabela de regras do NSG mostra claramente que não existe nenhuma regra permitindo tráfego de entrada na porta 443. A regra padrão DenyAllIn na prioridade 65500 bloqueia qualquer tráfego que não seja explicitamente permitido por regras de menor número. O SKU Standard do IP público realmente exige NSG para controle de tráfego, mas isso reforça a alternativa B: o Standard não bloqueia por si só, ele apenas exige que o NSG seja configurado corretamente. A ausência da regra de permissão para 443 é a causa direta.
A alternativa A é o distrator mais perigoso: ela mistura corretamente o comportamento seguro por padrão do SKU Standard com uma explicação incorreta. O SKU Standard não exige Load Balancer para funcionar com VMs; ele exige NSG. A alternativa C é irrelevante: não existe restrição de topologia que impeça VMs com IP público em subnets de backend. A alternativa D é tecnicamente falsa.
A informação sobre tags de ambiente e centro de custo é propositalmente irrelevante e não deveria influenciar o diagnóstico.
Gabarito — Cenário 2
Resposta: C
O cenário declara explicitamente que não há janela de manutenção disponível nas próximas três semanas e que o ambiente é de produção com carga alta. A ação correta diante dessa restrição é registrar, documentar e aguardar o momento seguro para executar a substituição com controle de impacto.
A alternativa A representa uma ação tecnicamente necessária, mas aplicada no momento errado: excluir o IP em produção sem janela causaria interrupção imediata. A alternativa B é diretamente incorreta: a conversão de SKU Basic para Standard via CLI não é suportada pela plataforma; o IP deve ser recriado. Este é o distrator mais perigoso, pois parece uma solução elegante e sem impacto, mas o comando resultaria em erro. A alternativa D é uma abordagem válida em cenários com flexibilidade operacional, mas adicionar um segundo IP e remover o outro ainda representa uma mudança em produção fora de janela, o que contraria a restrição central do enunciado.
Gabarito — Cenário 3
Resposta: B
A mensagem de erro é direta: PublicIPAddressAlreadyInUse. O IP público ainda está associado à NIC nic-vm-legacy-05. O estado Stopped da VM não libera a associação do IP; a NIC continua vinculada ao recurso e, consequentemente, ao IP público. Para reutilizar o IP, é necessário desassociá-lo explicitamente da NIC atual, independentemente do estado da VM.
A alternativa D é o distrator mais sofisticado e mais perigoso: ela introduz uma confusão real entre os estados Stopped e Deallocated de uma VM, que é um equívoco comum. No entanto, mesmo que a VM fosse desalocada, o IP Basic com alocação Dinâmica seria liberado automaticamente, o que também resolveria o problema de forma diferente. Mas a causa raiz do erro não é o estado da VM: é a associação ativa do IP à NIC, que pode ser desfeita diretamente no portal sem alterar o estado da VM.
A alternativa C é exatamente a informação irrelevante incluída propositalmente: o enunciado confirma que o limite de IPs não foi atingido, mas o engenheiro fictício do cenário age como se fosse essa a causa, ilustrando o erro de diagnóstico de confundir sintoma com causa superficial.
Gabarito — Cenário 4
Resposta: C
A sequência correta é 4, 2, 3, 1, 5, que segue a lógica de diagnóstico progressivo: do externo para o interno, do mais simples para o mais específico.
O passo 4 responde à pergunta mais fundamental: o tráfego está chegando ao IP público? Se o teste de conectividade externa falhar completamente, o problema pode estar antes mesmo do firewall. O passo 2 confirma se os IPs públicos ainda estão associados ao Azure Firewall, eliminando a hipótese de desassociação acidental. O passo 3 analisa os logs para entender se o tráfego chega ao firewall e o que acontece com ele, separando problemas de conectividade de problemas de regras. O passo 1 investiga as regras DNAT apenas depois de confirmar que o tráfego chega e está sendo processado. O passo 5, verificação da tabela de rotas da subnet, é o mais específico e relevante apenas se houver indícios de que o roteamento interno está comprometido.
A alternativa B (4, 3, 2, 1, 5) pula a verificação de associação dos IPs antes de analisar logs, o que pode levar a conclusões baseadas em logs de um estado de configuração diferente do atual. A alternativa A começa pela associação dos IPs sem antes confirmar se o problema é externo ou interno. A alternativa D começa pelas regras DNAT, que é investigar a causa mais específica antes de validar as camadas anteriores.
Árvore de Troubleshooting: Associate public IP addresses to resources
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigacao
- Azul medio: pergunta diagnostica objetiva, requer verificacao ativa
- Verde: acao recomendada ou resolucao identificada
- Vermelho: causa identificada sem resolucao direta no Azure (problema externo)
Para usar esta arvore diante de um problema real, comece pelo no raiz descrevendo o sintoma observado e responda cada pergunta com base no que e verificavel diretamente no portal, CLI ou logs. Siga o ramo correspondente a cada resposta sem pular niveis. Cada no de pergunta representa uma verificacao especifica que elimina ou confirma uma hipotese. O objetivo e chegar a um no verde (acao corretiva) ou vermelho (causa externa) percorrendo apenas os ramos que o estado real do ambiente confirmar.