Laboratório de Troubleshooting: Create and implement an Azure Firewall deployment
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações implantou um Azure Firewall em uma VNet hub chamada vnet-hub-eastus com o seguinte endereçamento:
VNet hub: 10.0.0.0/16
AzureFirewallSubnet: 10.0.1.0/26
GatewaySubnet: 10.0.2.0/27
Após o provisionamento, o firewall aparece com status Failed no portal Azure. O time verifica que a subscription tem cota suficiente para IPs públicos e que a região East US está disponível. Um engenheiro menciona que o mesmo template ARM foi usado com sucesso em outra subscription há dois meses. A conta utilizada para o deploy tem permissão de Contributor no resource group. Os logs de atividade mostram:
OperationName: Create or Update Azure Firewall
Status: Failed
Error Code: DeploymentFailed
Message: Subnet 'AzureFirewallSubnet' size /26 is too small.
Minimum required prefix length is /26.
SubnetId: /subscriptions/.../subnets/AzureFirewallSubnet
A equipe também reporta que o peering entre vnet-hub-eastus e duas VNets spoke foi configurado antes do deploy do firewall.
Qual é a causa raiz do problema?
A) O peering com as VNets spoke foi configurado antes do provisionamento do firewall, causando conflito de roteamento que impede o deploy.
B) A subnet AzureFirewallSubnet está com prefixo /26, que é menor do que o mínimo exigido pelo Azure Firewall.
C) A conta com permissão Contributor não tem privilégios suficientes para provisionar recursos de rede com IP público associado.
D) O template ARM está desatualizado e referencia uma versão de API do Azure Firewall que não suporta a região East US.
Cenário 2 — Impacto Colateral
Um administrador identificou que o Azure Firewall de uma VNet hub estava processando todo o tráfego de saída das VNets spoke sem qualquer regra de rede ou aplicação definida na política associada. Para resolver o problema de permissividade excessiva, o administrador adicionou uma regra de rede com prioridade 100 negando todo o tráfego de qualquer origem para qualquer destino em todas as portas.
A regra foi aplicada com sucesso e confirmada no portal. O tráfego não autorizado cessou imediatamente.
Qual é a consequência secundária mais provável desta ação?
A) A regra de negação total substitui as regras DNAT existentes, impedindo que sessões de entrada via NAT continuem funcionando.
B) O tráfego de gerenciamento do próprio Azure Firewall para os serviços de controle da Microsoft é bloqueado, causando falha no health probe do recurso.
C) Conexões legítimas de saída das VNets spoke, incluindo acesso a serviços como atualizações de SO e comunicação com endpoints Azure, são bloqueadas junto com o tráfego não autorizado.
D) A regra de negação em prioridade 100 é ignorada pelo processamento do firewall porque regras de aplicação têm precedência sobre regras de rede quando o destino é um FQDN.
Cenário 3 — Decisão de Ação
Uma equipe de segurança identificou que o Azure Firewall em produção está processando tráfego entre VNets spoke sem passar pela inspeção correta, pois as User Defined Routes nas subnets spoke apontam para o IP privado de um firewall de terceiros legado que foi descomissionado. A causa raiz está formalmente documentada: as UDRs associadas às subnets spoke referenciam um next hop inexistente.
O ambiente processa transações financeiras em tempo real. Não há janela de manutenção aprovada. O time de mudanças exige aprovação formal com no mínimo 48 horas de antecedência para alterações em UDRs de produção. Existe uma rota de emergência no processo de gestão de mudanças que pode ser acionada com aprovação do CISO em até 2 horas.
Qual é a ação correta a tomar neste momento?
A) Atualizar imediatamente as UDRs nas subnets spoke para apontar para o IP privado do Azure Firewall, pois o risco de tráfego sem inspeção supera o risco de uma mudança não aprovada.
B) Acionar a rota de emergência do processo de gestão de mudanças, documentar o risco, obter aprovação do CISO e executar a correção das UDRs dentro do processo formal.
C) Criar uma nova Route Table com as rotas corretas e associá-la às subnets spoke sem passar pelo processo de mudança, pois trata-se de um novo recurso e não de uma alteração.
D) Aguardar a próxima janela de manutenção aprovada e documentar o risco no registro de incidentes enquanto o tráfego continua sem inspeção adequada.
Cenário 4 — Causa Raiz
Uma empresa configurou o Azure Firewall em uma arquitetura hub-and-spoke. As VMs nas VNets spoke conseguem acessar a internet normalmente, mas não conseguem resolver nomes DNS de recursos internos hospedados em um servidor DNS privado localizado em 10.10.5.4, na VNet spoke de infraestrutura. O time de redes confirma que o peering entre todas as VNets está ativo e bidirecional, e que o servidor DNS em 10.10.5.4 responde corretamente quando consultado diretamente de uma VM na mesma VNet.
O Azure Firewall está configurado com as seguintes definições de DNS:
"dnsSettings": {
"servers": [],
"enableProxy": true
}
As regras de rede do firewall permitem tráfego UDP na porta 53 de qualquer origem para qualquer destino. Um engenheiro menciona que o servidor 10.10.5.4 foi adicionado ao ambiente há três semanas como parte de uma migração de DNS. As VMs nas subnets spoke estão configuradas para usar o IP do Azure Firewall como servidor DNS.
Qual é a causa raiz do problema?
A) As regras de rede permitem apenas UDP na porta 53, mas consultas DNS maiores utilizam TCP na porta 53, que está bloqueado pelo firewall.
B) O peering entre VNets spoke não permite tráfego de DNS transitivo, bloqueando a resolução entre subnets de VNets diferentes.
C) O proxy DNS do firewall está habilitado, mas a lista de servidores DNS upstream está vazia, fazendo com que o firewall encaminhe as consultas para o DNS público do Azure em vez do servidor privado em 10.10.5.4.
D) As VMs estão configuradas para usar o IP do firewall como DNS, mas o firewall não suporta resolução de nomes internos e encaminha todas as consultas diretamente para a internet.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro no log de atividade é direta: Subnet 'AzureFirewallSubnet' size /26 is too small. Minimum required prefix length is /26. À primeira leitura isso parece contraditório, mas o Azure Firewall exige que a subnet AzureFirewallSubnet tenha prefixo no máximo /26, ou seja, /26 é o menor prefixo aceito, e qualquer valor maior (como /27, /28) é rejeitado. O erro confirma que a subnet está exatamente no limite inferior. Entretanto, a mensagem deixa claro que o tamanho atual é insuficiente, o que indica que o prefixo usado foi mais restritivo que /26.
A informação sobre o peering com as VNets spoke é propositalmente irrelevante: peering não interfere no provisionamento do firewall. A permissão Contributor é suficiente para provisionar Azure Firewall. A versão da API do template ARM não é indicada como problemática em nenhum dado do cenário.
O distrator mais perigoso é a alternativa A, pois leva o diagnóstico para a camada de rede e roteamento, onde o time pode gastar tempo investigando peering e tabelas de rota sem jamais encontrar a causa real, que está na configuração da subnet.
Gabarito — Cenário 2
Resposta: C
Quando uma regra de negação total é adicionada com prioridade alta (100) sem exceções, ela bloqueia indiscriminadamente todo o tráfego de saída processado pelo firewall. Isso inclui conexões legítimas das VMs nas VNets spoke para endpoints de atualização de SO, serviços Azure como Azure Monitor, Key Vault, Log Analytics e qualquer outro serviço que dependa de conectividade de saída. A intenção era bloquear tráfego não autorizado, mas o escopo da regra é irrestrito.
A alternativa A é incorreta: regras DNAT são processadas antes das regras de rede, e uma regra DNAT bem configurada não é sobrescrita por uma regra de rede de negação. A alternativa B descreve um comportamento que não ocorre no Azure Firewall: o tráfego de gerenciamento do próprio firewall com a infraestrutura de controle da Microsoft não passa pelas regras de usuário. A alternativa D inverte a lógica de precedência: regras de rede são processadas antes das regras de aplicação, não o contrário.
O impacto colateral da alternativa C é o mais grave na prática, pois pode interromper operações críticas de VMs em produção de forma silenciosa e gradual, com sintomas que demoram a ser associados à mudança de regra.
Gabarito — Cenário 3
Resposta: B
O cenário impõe uma restrição organizacional explícita: mudanças em UDRs de produção exigem aprovação formal com 48 horas de antecedência, mas existe um mecanismo de emergência que permite aprovação em até 2 horas. A ação correta é usar o processo que foi criado exatamente para situações como esta, onde o risco é imediato e documentado.
A alternativa A ignora o processo de mudança sem qualquer autorização, expondo a equipe a risco disciplinar e o ambiente a uma mudança não rastreada formalmente. A alternativa C é uma tentativa de contornar o processo usando uma justificativa técnica inválida: associar uma nova Route Table a uma subnet é funcionalmente equivalente a alterar a UDR existente e está sujeita às mesmas restrições de processo. A alternativa D é inaceitável porque documenta o risco e aguarda passivamente enquanto o problema persiste em um ambiente de transações financeiras.
O processo de emergência existe para ser usado. Ignorá-lo em qualquer direção, seja agindo sem aprovação ou aguardando sem acionar o mecanismo formal, representa falha de governança.
Gabarito — Cenário 4
Resposta: C
A configuração do firewall mostra "servers": [] com "enableProxy": true. Quando o proxy DNS está habilitado mas a lista de servidores upstream está vazia, o Azure Firewall encaminha as consultas DNS para o Azure DNS público (168.63.129.16), que não tem conhecimento sobre zonas privadas internas nem sobre o servidor DNS em 10.10.5.4. As VMs nas subnets spoke usam o IP do firewall como DNS, então todas as consultas passam pelo proxy, e todas são resolvidas apenas pelo DNS público.
A informação sobre a adição do servidor 10.10.5.4 há três semanas é irrelevante para o diagnóstico: o servidor funciona corretamente quando consultado diretamente, o que elimina qualquer problema no servidor em si. A alternativa A é um distrator plausível mas incorreto: consultas DNS que excedem 512 bytes usam TCP/53, mas a grande maioria das resoluções internas funciona via UDP/53. A alternativa B é tecnicamente incorreta: o peering hub-and-spoke com tráfego roteado pelo firewall permite transitividade de DNS quando o proxy está corretamente configurado. A alternativa D é incorreta porque o proxy DNS do Azure Firewall foi projetado exatamente para encaminhar consultas a servidores DNS privados quando configurado adequadamente.
Árvore de Troubleshooting: Criação e Implementação do Azure Firewall
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial, ponto de entrada da investigação |
| Azul | Pergunta diagnóstica fechada e verificável |
| Vermelho | Causa identificada com precisão |
| Verde | Ação recomendada ou resolução do problema |
| Laranja | Validação intermediária antes de encerrar o diagnóstico |
Para usar esta árvore diante de um problema real com o Azure Firewall, comece pelo nó raiz identificando se o problema ocorre durante o provisionamento ou após o firewall já estar em operação. Essa primeira decisão define o ramo principal de investigação. A partir daí, responda cada pergunta com base apenas no que foi observado ou verificado diretamente, sem pular etapas. Cada ramo termina em uma causa nomeada seguida de uma ação específica, garantindo que a correção só seja aplicada após o diagnóstico estar confirmado.