Laboratório de Troubleshooting: Plan and configure subnetting for services, including virtual network gateways, private endpoints, service endpoints, firewalls, application gateways, VNet-integrated platform services, and Azure Bastion
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de plataforma implantou um Azure Firewall Premium em uma VNet de hub. A subnet criada para o firewall tem o nome AzureFirewallSubnet e prefixo /26. O recurso foi provisionado com sucesso e as regras de rede e aplicação foram configuradas conforme o design aprovado.
Dois dias após a implantação, o time de operações habilita o IDPS (Intrusion Detection and Prevention System) no Azure Firewall Premium e começa a observar latência elevada em conexões que passam pelo firewall. Um analista verifica os logs e nota que pacotes legítimos estão sendo descartados intermitentemente. O time de redes informa que nenhuma regra foi alterada desde a implantação inicial. O time de segurança confirma que o certificado TLS intermediário utilizado na inspeção está válido e dentro do prazo de expiração.
Os logs do firewall mostram entradas como:
Action: Deny
Rule: IDPS Signature Match
Signature ID: 2031234
Severity: Medium
Protocol: TCP
Source: 10.1.2.45:54321
Destination: 20.45.132.11:443
A subnet da aplicação de origem (app-subnet) tem uma User Defined Route (UDR) com rota padrão 0.0.0.0/0 apontando para o IP privado do Azure Firewall. O time confirma que a mesma UDR estava em uso antes da ativação do IDPS sem qualquer problema.
Qual é a causa raiz do comportamento observado?
A) A subnet /26 do Azure Firewall é insuficiente para o modo Premium com IDPS ativo, causando descarte de pacotes por falta de recursos internos de processamento.
B) As assinaturas do IDPS estão classificando tráfego legítimo como ameaça, e a política de IDPS está configurada em modo Alert and Deny em vez de Alert Only.
C) A UDR na app-subnet está causando roteamento assimétrico porque não há rota de retorno explícita para o range da subnet de origem no Azure Firewall.
D) O certificado TLS intermediário, embora válido, não está sendo reconhecido pela cadeia de confiança do Azure Firewall Premium, causando falhas na inspeção de pacotes.
Cenário 2 — Decisão de Ação
A equipe de rede identificou que um VPN Gateway em produção não está processando conexões de clientes Point-to-Site. Após investigação, confirmou-se que a causa é a seguinte: a subnet GatewaySubnet tem prefixo /29, e o gateway foi atualizado para o SKU VpnGw2 há três dias para suportar um volume maior de conexões simultâneas. O aumento no número de instâncias internas do gateway esgotou os endereços IP disponíveis na subnet, e novas instâncias não conseguem ser provisionadas.
O ambiente possui as seguintes restrições:
- A VNet tem espaço de endereçamento disponível para expansão
- Há 47 conexões Site-to-Site ativas neste gateway, todas em uso por filiais críticas
- A janela de manutenção aprovada começa em 6 horas
- O time não tem permissão para recriar o gateway fora da janela de manutenção
Qual é a ação correta a tomar neste momento?
A) Recriar imediatamente o VPN Gateway com um novo SKU e uma GatewaySubnet de tamanho /27, aproveitando que o problema já causou interrupção parcial.
B) Expandir o espaço de endereçamento da VNet agora e redimensionar a GatewaySubnet para /27 durante a janela de manutenção aprovada em 6 horas.
C) Fazer downgrade do SKU para VpnGw1 imediatamente para reduzir o número de instâncias internas e liberar IPs na subnet atual.
D) Criar uma segunda GatewaySubnet com prefixo /27 em paralelo e migrar o gateway para ela antes da janela de manutenção.
Cenário 3 — Causa Raiz
Uma equipe de desenvolvimento relata que uma aplicação hospedada em uma VM na subnet app-subnet (10.2.1.0/24) não consegue se conectar a um Azure Storage Account via Private Endpoint. O Private Endpoint foi criado há uma semana e, segundo o time de plataforma, funcionou corretamente em testes iniciais.
A VM consegue resolver o nome mystorageaccount.blob.core.windows.net mas a conexão TCP na porta 443 expira sem resposta. O time de segurança informa que nenhuma alteração foi feita nas regras do NSG da app-subnet desde os testes iniciais. O administrador verifica a configuração do Private Endpoint e confirma que o status de aprovação está como Approved.
O administrador executa o seguinte comando a partir da VM:
nslookup mystorageaccount.blob.core.windows.net
Server: 168.63.129.16
Address: 168.63.129.16
Non-authoritative answer:
Name: mystorageaccount.privatelink.blob.core.windows.net
Address: 20.45.132.90
O time de redes confirma que o IP do Private Endpoint provisionado é 10.2.3.5. A app-subnet e a subnet do Private Endpoint (pe-subnet, 10.2.3.0/24) estão na mesma VNet. Uma UDR foi adicionada à pe-subnet há dois dias para rotear tráfego de saída para um NVA.
Qual é a causa raiz do problema observado?
A) O NSG da app-subnet está bloqueando o tráfego de saída na porta 443 para o range 10.2.3.0/24, apesar de o time de segurança afirmar que não houve alterações.
B) A resolução DNS está retornando o IP público do Storage Account em vez do IP privado do Private Endpoint, indicando que a zona DNS privada não está integrada corretamente à VNet.
C) A UDR adicionada à pe-subnet está redirecionando o tráfego de retorno para o NVA, causando roteamento assimétrico e descarte da conexão TCP.
D) O status Approved do Private Endpoint é necessário mas não suficiente; a conexão falha porque o Private Endpoint não foi associado a um DNS Group após a aprovação.
Cenário 4 — Impacto Colateral
Uma equipe identificou que o Azure Application Gateway v2 estava apresentando falhas intermitentes de provisionamento de novas instâncias durante picos de tráfego. A causa foi confirmada: a subnet do Application Gateway (appgw-subnet, /26) estava com apenas 3 endereços IP livres, insuficientes para acomodar novas instâncias durante o autoescalonamento.
Para resolver o problema, a equipe tomou a seguinte ação: expandiu o prefixo da appgw-subnet de /26 para /24, liberando mais de 250 endereços adicionais. O Application Gateway voltou a escalar normalmente e as falhas cessaram.
Qual consequência secundária essa ação pode causar?
A) A expansão do prefixo da subnet pode sobrescrever endereços já alocados para outros recursos na VNet caso o novo range entre em conflito com subnets existentes ou com o espaço de endereçamento da VNet.
B) O Application Gateway v2 perderá sua configuração de autoescalonamento ao detectar a mudança de subnet e precisará ser reconfigurado manualmente.
C) Regras de NSG associadas à appgw-subnet serão automaticamente removidas pelo Azure ao detectar a alteração de prefixo, exigindo recriação manual.
D) O IP privado do frontend do Application Gateway será realocado automaticamente para um novo endereço dentro do range expandido, quebrando referências em regras de firewall e UDRs.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está nos logs: os pacotes estão sendo descartados por IDPS Signature Match, e isso começou exatamente após a ativação do IDPS. O modo padrão de novas políticas IDPS no Azure Firewall Premium é Alert and Deny para assinaturas de severidade média e alta. Quando tráfego legítimo corresponde a uma assinatura de ameaça conhecida (falso positivo), o firewall descarta o pacote sem exceção no modo Deny.
A informação sobre o certificado TLS válido é deliberadamente irrelevante. O problema não está na inspeção TLS, e os logs não indicam falhas de certificado; eles indicam correspondência de assinatura IDPS. Essa informação existe para atrair o leitor para a alternativa D.
A alternativa C, sobre roteamento assimétrico, seria plausível em outro contexto, mas a UDR estava funcionando antes da ativação do IDPS e nenhuma mudança de roteamento foi feita. O sintoma também não é consistente com assimetria, que normalmente causa timeout total, não descarte com log de assinatura.
O distrator mais perigoso é a alternativa C, pois roteamento assimétrico é uma causa real e comum em ambientes com Azure Firewall. Agir com base nela levaria a alterar UDRs sem resolver o problema real, potencialmente quebrando o roteamento de outras subnets.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é clara: o time não tem permissão para recriar o gateway fora da janela de manutenção, e a janela começa em 6 horas. A ação correta é preparar o terreno agora (expandir o espaço de endereçamento da VNet, pois isso não causa interrupção) e executar a operação destrutiva na janela aprovada.
A alternativa A ignora a restrição de permissão e destruiria as 47 conexões Site-to-Site ativas. Recriar um VPN Gateway é uma operação que pode levar entre 30 e 45 minutos e interrompe todas as conexões existentes.
A alternativa C parece uma solução rápida, mas fazer downgrade de SKU em um gateway com 47 conexões ativas também é uma operação que causa interrupção. Além disso, não resolve o problema estrutural.
A alternativa D descreve algo tecnicamente impossível: uma VNet só pode ter uma GatewaySubnet. Não é possível criar uma segunda.
O raciocínio correto aqui é distinguir entre o que pode ser feito agora sem impacto (preparação) e o que deve esperar a janela de manutenção (execução).
Gabarito — Cenário 3
Resposta: B
A prova decisiva está na saída do nslookup: o nome mystorageaccount.blob.core.windows.net está resolvendo para 20.45.132.90, que é um IP público, e não para 10.2.3.5, que é o IP do Private Endpoint. Quando a resolução DNS retorna o IP público, a conexão TCP nunca chega ao Private Endpoint, independentemente de qualquer outra configuração.
Para que o Private Endpoint funcione corretamente, a zona DNS privada privatelink.blob.core.windows.net deve estar vinculada à VNet, e o registro A deve apontar para o IP privado. A saída do nslookup mostra que o CNAME para privatelink está sendo resolvido, mas para o IP público, o que indica que a zona privada não está vinculada à VNet ou está com registro incorreto.
A UDR na pe-subnet é a informação irrelevante do cenário. Embora UDRs em subnets de Private Endpoint possam causar problemas em alguns contextos, o sintoma aqui é de resolução DNS incorreta, não de roteamento. O pacote nem chega ao IP correto para que o roteamento seja relevante.
O distrator mais perigoso é a alternativa A, pois um analista pressionado poderia ignorar a saída do nslookup e investigar o NSG primeiro. Isso consumiria tempo e não resolveria nada, pois o tráfego não está chegando ao endpoint privado para ser filtrado pelo NSG.
Gabarito — Cenário 4
Resposta: A
A expansão de um prefixo de subnet (/26 para /24) amplia o range de IPs que aquela subnet ocupa dentro do espaço de endereçamento da VNet. Se o espaço de endereçamento da VNet não foi previamente expandido para comportar o novo range, ou se outras subnets já ocupam parte do range 10.x.x.0/24 pretendido, a operação pode falhar ou, em configurações incorretas, criar sobreposição de endereços.
Mais especificamente: o Azure impede a criação de subnets sobrepostas na mesma VNet, então a operação falharia. Mas se o espaço da VNet foi expandido sem verificar conflitos com subnets em VNets pareadas (peered VNets), pode haver sobreposição de endereços no nível de roteamento inter-VNet, que o Azure não bloqueia automaticamente no momento da expansão.
A alternativa B é falsa: o Application Gateway não perde configurações de autoescalonamento por mudança de tamanho de subnet. A alternativa C é falsa: o Azure não remove NSGs automaticamente em redimensionamentos de subnet. A alternativa D é tecnicamente possível em alguns cenários de realocação, mas o IP do frontend do Application Gateway é alocado estaticamente no momento da criação e não é reatribuído automaticamente por mudanças na subnet.
Árvore de Troubleshooting: Plan and configure subnetting for services
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma geral e responda cada pergunta de diagnóstico com base no que é observável no ambiente. Os nós de validação em laranja indicam onde coletar evidências antes de prosseguir. Siga o caminho até chegar a um nó vermelho de causa identificada e, a partir dele, execute a ação correspondente em verde. Nunca pule etapas de validação intermediária, pois o sintoma visível frequentemente aponta para a causa errada.