Laboratório de Troubleshooting: Choose when to use a public IP address prefix
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações recebe uma reclamação de um cliente parceiro: após o Azure provisionar novos recursos na assinatura da empresa, o tráfego desses recursos está sendo bloqueado pelo firewall on-premises do cliente. Os recursos mais antigos continuam funcionando normalmente.
O ambiente é descrito assim:
- A assinatura usa IPs públicos individuais com SKU Standard, alocados sob demanda
- O cliente parceiro mantém uma lista de permissão com 14 entradas CIDR no firewall
- O time de rede do Azure confirmou que todos os IPs estão na região East US
- A equipe verificou que os NSGs das VMs novas estão configurados corretamente
- O time de segurança confirmou que não houve mudança de política no firewall nos últimos 30 dias
O cliente relata:
Firewall log - deny outbound:
src: 20.85.112.47 dst: 10.10.5.20 port: 443 action: DENY
src: 20.85.114.12 dst: 10.10.5.20 port: 443 action: DENY
src: 20.85.99.200 dst: 10.10.5.20 port: 443 action: DENY
Qual é a causa raiz do bloqueio observado?
A) Os NSGs das novas VMs estão bloqueando o tráfego de retorno, impedindo o estabelecimento da sessão TLS
B) Os novos IPs públicos foram alocados fora do intervalo já registrado na lista de permissão do cliente, pois não há garantia de contiguidade em alocações individuais
C) O SKU Standard dos IPs públicos é incompatível com o roteamento para redes on-premises via firewall de terceiros
D) A região East US sofreu realocação de blocos IP e os endereços antigos foram invalidados
Cenário 2 — Decisão de Ação
A equipe de plataforma identificou que o problema do Cenário 1 se repetiria indefinidamente à medida que novos recursos fossem provisionados. A liderança aprovou a migração para um modelo baseado em prefixo de IP público.
O contexto de restrições é:
- Os 14 IPs públicos existentes estão associados a VMs em produção com tráfego ativo
- O cliente parceiro exige aviso prévio de 72 horas antes de qualquer mudança de IP
- O time tem uma janela de manutenção disponível em 5 dias
- Um engenheiro já provisionou um prefixo /28 na região East US e confirmou que os 16 novos IPs estão disponíveis
Qual é a ação correta a tomar neste momento?
A) Dissociar imediatamente os IPs antigos das VMs e associar os novos IPs do prefixo para encerrar o risco o mais rápido possível
B) Comunicar o cliente com os novos intervalos CIDR agora e agendar a troca de IPs para a janela de manutenção em 5 dias
C) Provisionar os novos IPs do prefixo e associá-los em paralelo às VMs, mantendo os IPs antigos ativos durante o período de transição
D) Solicitar ao cliente que amplie temporariamente a lista de permissão para aceitar qualquer IP da faixa 20.0.0.0/8 enquanto a migração é planejada
Cenário 3 — Causa Raiz
Um administrador tenta criar um IP público a partir de um prefixo existente usando o seguinte comando:
az network public-ip create \
--resource-group rg-prod \
--name pip-vm-new \
--sku Basic \
--prefix "/subscriptions/.../publicIPPrefixes/prefix-prod-eastus" \
--allocation-method Static \
--location eastus
A saída retornada é:
(InvalidPublicIpSkuMismatch) The public IP address SKU 'Basic' is not
supported for public IP prefix. Only 'Standard' SKU is supported.
Code: InvalidPublicIpSkuMismatch
Message: The public IP address SKU 'Basic' is not supported for public
IP prefix. Only 'Standard' SKU is supported.
O administrador relata que o prefixo foi criado há três semanas sem problemas, que a alocação de outros IPs a partir do mesmo prefixo funcionou anteriormente, e que a assinatura ainda tem cota disponível para IPs públicos na região.
Qual é a causa raiz do erro?
A) O prefixo atingiu o limite de IPs alocados e não aceita mais criações até que um IP seja liberado
B) O parâmetro --allocation-method Static é incompatível com IPs derivados de prefixos e causou a rejeição da operação
C) O SKU especificado no comando é incompatível com o SKU do prefixo, pois prefixos de IP público exigem que os IPs derivados sejam SKU Standard
D) A cota de IPs públicos Basic na região East US foi esgotada, fazendo o Azure rejeitar a criação com uma mensagem de erro genérica
Cenário 4 — Sequência de Diagnóstico
Uma empresa provisionou um prefixo de IP público /29 e começou a criar IPs a partir dele. Após algum tempo, um novo engenheiro tenta provisionar mais um IP público a partir do mesmo prefixo e recebe uma falha. O engenheiro precisa diagnosticar o problema.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- P1: Verificar quantos IPs públicos já foram criados a partir do prefixo
- P2: Confirmar o tamanho do prefixo (/29 fornece no máximo 8 endereços)
- P3: Tentar criar o IP público com um nome diferente para descartar conflito de nomenclatura
- P4: Verificar se o prefixo existe na mesma região e grupo de recursos esperado
- P5: Verificar se todos os 8 endereços do prefixo já estão associados a IPs públicos provisionados
Qual é a sequência correta de diagnóstico?
A) P3 > P1 > P5 > P2 > P4
B) P4 > P2 > P1 > P5 > P3
C) P1 > P3 > P4 > P2 > P5
D) P2 > P4 > P5 > P1 > P3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está nos logs do firewall: os três IPs bloqueados (20.85.112.47, 20.85.114.12, 20.85.99.200) não pertencem ao mesmo bloco CIDR e não formam um intervalo contíguo. Isso é o comportamento esperado quando IPs públicos são alocados individualmente no Azure: o plataforma não garante que alocações separadas resultem em endereços adjacentes ou pertencentes ao mesmo prefixo.
A informação sobre NSGs configurados corretamente é irrelevante para o diagnóstico e foi incluída propositalmente. O bloqueio ocorre no firewall do cliente, antes mesmo do tráfego chegar às regras de NSG das VMs. A alternativa C é um distrator plausível, mas o SKU Standard é totalmente compatível com tráfego on-premises. A alternativa D descreve um evento hipotético sem nenhuma evidência no enunciado.
O distrator mais perigoso é A: um diagnóstico focado em NSGs levaria a horas de investigação no lugar errado, enquanto novos recursos continuariam sendo bloqueados.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é o aviso prévio de 72 horas exigido pelo cliente. Qualquer ação que resulte em mudança de IP sem essa notificação viola um compromisso operacional com o parceiro, independentemente da correção técnica da ação.
A alternativa A ignora diretamente essa restrição e causaria interrupção de serviço para o cliente sem aviso. A alternativa C é tecnicamente atraente, mas IPs públicos no Azure não podem ser associados em paralelo a um mesmo recurso de forma que o tráfego de entrada funcione pelos dois simultaneamente sem uma camada adicional. A alternativa D é inadequada porque expande a superfície de ataque do firewall do cliente de forma desnecessária e sem prazo definido.
A ação correta é comunicar o cliente agora com os blocos CIDR do novo prefixo e executar a migração dentro da janela de manutenção, respeitando o prazo contratual.
Gabarito — Cenário 3
Resposta: C
A mensagem de erro é explícita: Only 'Standard' SKU is supported. Prefixos de IP público no Azure são criados com SKU Standard e todos os IPs provisionados a partir deles devem ser igualmente SKU Standard. Essa restrição é absoluta e não depende de cota, nomenclatura ou método de alocação.
As informações sobre o prefixo ter sido criado há três semanas e sobre alocações anteriores terem funcionado são irrelevantes: elas apenas confirmam que o prefixo e a assinatura estão saudáveis, o que redireciona o diagnóstico correto para o próprio comando submetido.
A alternativa D é o distrator mais perigoso: a mensagem de erro poderia ser interpretada como genérica por engenheiros menos experientes, levando a uma investigação de cota que não encontraria nenhum problema real.
Gabarito — Cenário 4
Resposta: B
A sequência correta segue a lógica de eliminar causas estruturais antes de causas operacionais:
P4 confirma que o prefixo existe no local esperado, pois sem isso os demais passos não têm base. P2 estabelece o limite teórico máximo de endereços disponíveis no prefixo (/29 = 8 endereços). P1 verifica quantos IPs foram criados, fornecendo o número atual de alocações. P5 confronta esse número com o limite e confirma se o esgotamento ocorreu. P3 só faz sentido como última verificação, pois conflito de nomenclatura só seria relevante se ainda houvesse capacidade disponível no prefixo.
A sequência A comete o erro clássico de testar soluções (P3) antes de entender o problema estrutural. A sequência C pula para verificações operacionais sem primeiro confirmar a existência do recurso. A sequência D inverte P1 e P5, verificando esgotamento antes de saber quantos IPs existem, o que carece de lógica progressiva.
Árvore de Troubleshooting: Choose when to use a public IP address prefix
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa no ambiente, não no que você supõe. Siga o caminho que corresponde ao comportamento observado até alcançar um nó vermelho de causa ou um nó verde de ação. Nunca pule níveis: cada pergunta filtra uma classe de causas e garante que o diagnóstico seja progressivo, não especulativo.