Laboratório de Troubleshooting: Create a secure hub by deploying Azure Firewall inside Virtual WAN hub
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de redes implantou um Azure Firewall dentro de um hub do Azure Virtual WAN em uma região secundária. O hub foi criado com sucesso e o firewall aparece como provisionado no portal. No entanto, o tráfego entre duas VNets conectadas a esse hub não está sendo inspecionado pelo firewall: os pacotes chegam ao destino sem nenhum log gerado no workspace do Log Analytics.
O ambiente possui as seguintes características:
- Hub do Virtual WAN do tipo Standard
- Azure Firewall provisionado no hub com SKU Premium
- Duas VNets conectadas ao hub via Virtual Network Connections
- Workspace do Log Analytics configurado e com diagnósticos habilitados no firewall
- Firewall Policy associada ao firewall com regras de rede permitindo o tráfego entre as VNets
- O administrador confirmou que as rotas das VNets aparecem na tabela de rotas do hub
A equipe também observou que a configuração de BGP entre o hub e um gateway de VPN conectado ao mesmo hub foi atualizada na semana anterior, mas o gateway está em uma região diferente.
Qual é a causa raiz do problema?
A) O SKU Premium do firewall não é compatível com o Virtual WAN hub em regiões secundárias.
B) As Virtual Network Connections estão conectadas ao hub, mas a opção de Routing Intent não foi habilitada para redirecionar o tráfego privado pelo firewall.
C) O workspace do Log Analytics está em uma região diferente do firewall, impedindo a geração de logs.
D) A atualização de BGP no gateway de VPN corrompeu a tabela de rotas do hub, desviando o tráfego.
Cenário 2 — Sequência de Diagnóstico
Um administrador relata que, após habilitar o Routing Intent em um hub do Azure Virtual WAN com Azure Firewall, conexões de Branch (ExpressRoute) para VNet pararam de funcionar. O tráfego entre VNets continua operando normalmente.
Os passos de investigação disponíveis são:
- Verificar se a Firewall Policy possui regras de rede que permitam o tráfego do prefixo do circuito ExpressRoute para os prefixos das VNets.
- Confirmar que o Routing Intent está configurado para inspecionar tráfego privado e não apenas tráfego de internet.
- Verificar os logs do Azure Firewall no Log Analytics para identificar se o tráfego está chegando ao firewall e sendo negado.
- Confirmar que o circuito ExpressRoute está no estado Connected no portal do Azure.
- Verificar se há rotas aprendidas do ExpressRoute na tabela de rotas efetivas do hub.
Qual é a sequência correta de investigação?
A) 4 → 5 → 3 → 1 → 2
B) 2 → 4 → 5 → 3 → 1
C) 4 → 2 → 5 → 3 → 1
D) 5 → 4 → 3 → 2 → 1
Cenário 3 — Causa Raiz
Uma organização configurou um hub seguro no Azure Virtual WAN com Azure Firewall e habilitou o Routing Intent para tráfego de internet. O objetivo é que todo o tráfego de saída das VNets para a internet passe pelo firewall antes de sair.
Após a configuração, os administradores observam que máquinas virtuais em uma VNet específica ainda acessam a internet diretamente, sem passar pelo firewall. Os logs do firewall não registram nenhum tráfego originado dessa VNet.
Detalhes do ambiente:
- O Routing Intent de internet está habilitado no hub
- A VNet em questão possui uma UDR (User-Defined Route) com rota
0.0.0.0/0apontando para um NVA implantado dentro da própria VNet - O peering entre a VNet e o hub está ativo e no estado Connected
- Há uma segunda VNet sem UDR que funciona corretamente pelo firewall
- O hub é do tipo Standard com firewall SKU Premium
- A subscription da VNet problemática pertence a um grupo de gerenciamento diferente das demais VNets
Qual é a causa raiz do problema?
A) O hub do tipo Standard não propaga rotas de Routing Intent para VNets que pertencem a subscriptions em grupos de gerenciamento diferentes.
B) A UDR na VNet com rota 0.0.0.0/0 apontando para o NVA local tem precedência sobre as rotas propagadas pelo hub, desviando o tráfego antes de chegar ao firewall.
C) O SKU Premium do firewall requer configuração adicional de Firewall Policy para interceptar tráfego de VNets com peering ativo.
D) O peering entre a VNet e o hub precisa ser recriado após a habilitação do Routing Intent para que as novas rotas sejam propagadas.
Cenário 4 — Decisão de Ação
A equipe identificou que o Routing Intent de tráfego privado foi habilitado no hub, mas a Firewall Policy associada ao firewall não contém nenhuma regra de rede explícita para o tráfego entre VNets. Como resultado, todo o tráfego entre VNets está sendo bloqueado pelo firewall, causando indisponibilidade em aplicações críticas de produção.
Restrições do contexto:
- O ambiente está em produção e a janela de manutenção só ocorre às sextas-feiras à noite
- A equipe de segurança precisa aprovar qualquer nova regra antes de ser aplicada
- Existe uma Firewall Policy de nível pai (parent policy) compartilhada com outros hubs, e a policy local herda dela
- A equipe possui permissão para editar a Firewall Policy local, mas não a parent policy
- É terça-feira e o impacto nas aplicações já dura duas horas
Qual é a ação correta a tomar neste momento?
A) Desabilitar temporariamente o Routing Intent no hub para restaurar a conectividade enquanto as regras são preparadas e aprovadas.
B) Adicionar uma regra de rede permissiva na Firewall Policy local, sem aguardar aprovação, para restaurar o serviço imediatamente.
C) Criar as regras de rede necessárias na Firewall Policy local, submeter para aprovação da equipe de segurança em regime de urgência e solicitar autorização para aplicação fora da janela de manutenção, dado o impacto em produção.
D) Editar a parent policy para adicionar a regra de rede, já que ela é compartilhada e a correção afetaria todos os hubs de forma consistente.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O Azure Firewall provisionado em um hub do Virtual WAN não inspeciona tráfego automaticamente apenas por estar presente. Para que o tráfego entre VNets (tráfego privado) seja redirecionado pelo firewall, o Routing Intent precisa ser habilitado explicitamente com a opção de tráfego privado ativada. Sem isso, as VNets se comunicam diretamente através do hub sem passar pelo firewall, o que explica a ausência de logs: o tráfego nunca chega ao firewall.
A pista central no enunciado é que as rotas das VNets aparecem na tabela de rotas do hub e o firewall está provisionado corretamente. O problema não é de conectividade nem de provisionamento, mas de política de roteamento.
A informação sobre a atualização de BGP no gateway de VPN é irrelevante. Ela se refere a um componente em outra região e a um gateway separado, sem relação com o fluxo entre as duas VNets em questão.
O distrator mais perigoso é o D, pois direciona a investigação para o BGP e a tabela de rotas, que parecem suspeitos por terem sido modificados recentemente. Agir com base nisso levaria a uma investigação de horas sem encontrar a causa real.
Gabarito — Cenário 2
Resposta: A
A sequência correta é 4 → 5 → 3 → 1 → 2.
O raciocínio progressivo exige confirmar primeiro se o circuito ExpressRoute está operacional (passo 4), pois sem conectividade física todo diagnóstico posterior é inútil. Em seguida, verificar se as rotas do ExpressRoute estão presentes na tabela do hub (passo 5) valida se o plano de controle está funcionando. Com isso confirmado, os logs do firewall (passo 3) revelam se o tráfego chega ao firewall e qual decisão ele toma. A partir dos logs, faz sentido verificar as regras da Firewall Policy (passo 1). Só por último vale confirmar a configuração do Routing Intent (passo 2), pois o enunciado já informa que ele foi habilitado e o tráfego entre VNets funciona, o que confirma que o Routing Intent está ativo para tráfego privado.
O distrator mais comum é o B, que começa pela configuração do Routing Intent. Embora pareça lógico revisar o que foi alterado, começar pela camada de configuração sem validar primeiro a camada física e de roteamento é um erro metodológico que pode levar a conclusões falsas.
Gabarito — Cenário 3
Resposta: B
A UDR com rota 0.0.0.0/0 configurada diretamente na subnet da VNet tem precedência sobre as rotas propagadas pelo hub do Virtual WAN. Quando o Routing Intent está ativo, o hub anuncia 0.0.0.0/0 como next-hop apontando para o firewall. Porém, rotas definidas em UDR são mais específicas no plano de decisão de roteamento do Azure e sobrescrevem as rotas aprendidas via propagação do hub. O tráfego da VNet sai pelo NVA local sem nunca alcançar o firewall do hub.
A pista central está na existência da UDR e no contraste com a segunda VNet, que não possui UDR e funciona corretamente.
A informação sobre o grupo de gerenciamento diferente é irrelevante. O Routing Intent propaga rotas com base na conexão da VNet ao hub, não na hierarquia de grupos de gerenciamento da subscription.
O distrator mais perigoso é o D, pois induz a recriar o peering, uma ação destrutiva e desnecessária que geraria indisponibilidade adicional sem resolver o problema real.
Gabarito — Cenário 4
Resposta: C
O contexto apresenta múltiplas restrições simultâneas: impacto em produção, necessidade de aprovação de segurança, janela de manutenção, e limitação de permissão na parent policy. A única ação que respeita todas as restrições e age com urgência adequada é criar as regras na policy local, acionar a aprovação em regime de urgência e solicitar autorização para aplicar fora da janela regular.
O distrator A parece razoável porque restauraria o serviço rapidamente, mas desabilitar o Routing Intent em produção sem aprovação é uma mudança de arquitetura de segurança de alto impacto, tão ou mais arriscada que o problema original.
O distrator B ignora o processo de aprovação da equipe de segurança, o que pode violar políticas de governança e criar exposição de risco não avaliado.
O distrator D é inviável porque o enunciado é claro: a equipe não possui permissão para editar a parent policy.
Árvore de Troubleshooting: Azure Firewall no Azure Virtual WAN Hub
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
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ê pode verificar diretamente no portal, nos logs ou via comandos. Cada ramificação leva a uma causa concreta ou a uma nova pergunta mais específica. Siga o caminho até encontrar um nó vermelho de causa identificada e aplique a ação verde correspondente. Se a ação não resolver, retorne ao último nó de validação laranja e explore o caminho alternativo.