Laboratório de Troubleshooting: Diagnose and Resolve Client-Side and Authentication Issues
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento reporta que a aplicação parou de se comunicar com o Azure SQL Database após uma migração de ambiente. A aplicação está hospedada em uma VM dentro da VNet vnet-app (10.10.0.0/16). O banco de dados foi configurado com um Private Endpoint na sub-rede snet-data (10.10.2.0/24). O administrador confirma que o status do Private Endpoint é Aprovado e que o NSG da sub-rede snet-data permite tráfego na porta 1433 de qualquer origem dentro da VNet.
Durante a investigação, o desenvolvedor executa o seguinte teste a partir da VM:
# Teste de resolução DNS
nslookup meu-sql.database.windows.net
Server: 168.63.129.16
Address: 168.63.129.16#53
Non-authoritative answer:
Name: meu-sql.database.windows.net
Address: 20.40.180.12
# Teste de conectividade TCP
Test-NetConnection -ComputerName meu-sql.database.windows.net -Port 1433
TcpTestSucceeded : False
O administrador menciona que o servidor DNS da VNet está configurado como Default (Azure-provided) e que uma Private DNS Zone chamada privatelink.database.windows.net foi criada no mesmo Resource Group. O firewall do SQL Server permite apenas conexões via Private Endpoint (acesso público desabilitado).
Qual é a causa raiz da falha de conectividade?
A) O NSG da sub-rede snet-data está bloqueando a porta 1433, pois regras de entrada não se aplicam ao tráfego dentro da mesma VNet quando o destino é um Private Endpoint.
B) A Private DNS Zone privatelink.database.windows.net não está vinculada à VNet vnet-app, fazendo com que a resolução retorne o IP público em vez do IP privado do endpoint.
C) O servidor DNS padrão do Azure (168.63.129.16) não suporta resolução de nomes para Private Endpoints e deve ser substituído por um DNS customizado.
D) O firewall do Azure SQL Database está bloqueando a conexão mesmo com acesso público desabilitado, porque a regra de Virtual Network não foi adicionada para a sub-rede snet-data.
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que uma política de Microsoft Entra Conditional Access mal configurada está impedindo todos os usuários de um grupo crítico de acessar o portal do Azure em produção. A causa foi confirmada: a política aplica um controle de acesso baseado em localização que bloqueia IPs corporativos por um erro na lista de IPs confiáveis. A política está em modo Enabled (ativa).
O ambiente possui as seguintes restrições:
- São 14h de uma sexta-feira; o time de identidade encerra às 15h e não há plantão no fim de semana
- O grupo afetado inclui os administradores de plataforma responsáveis pelo monitoramento de produção
- Existe uma segunda conta de acesso de emergência (break glass account) disponível, sem Conditional Access aplicado
- A alteração na lista de IPs confiáveis requer aprovação de um segundo administrador do Entra ID, que está disponível agora
- Reverter a política para o modo Report-only restauraria o acesso imediatamente sem remover a política
Qual é a ação correta a tomar neste momento?
A) Usar a break glass account para acessar o portal, corrigir a lista de IPs confiáveis na política e aguardar a aprovação do segundo administrador antes de reativar a política em modo Enabled.
B) Alterar o modo da política para Report-only imediatamente para restaurar o acesso do grupo afetado, e em seguida corrigir a lista de IPs com o segundo administrador ainda disponível.
C) Excluir a política de Conditional Access problemática agora e recriar uma nova política correta na próxima semana, após revisão completa com a equipe de segurança.
D) Aguardar até segunda-feira para corrigir a política junto com a equipe de segurança completa, usando a break glass account para cobrir as operações críticas do fim de semana.
Cenário 3 — Causa Raiz
Um administrador de rede recebe reclamações de que usuários de uma filial conectada via VPN Site-to-Site conseguem acessar servidores na VNet do Azure normalmente, mas não conseguem acessar um sistema específico hospedado em uma segunda VNet conectada ao hub via VNet Peering. A topologia é hub-and-spoke.
Filial (on-premises)
|
VPN S2S
|
VNet Hub (10.0.0.0/16) <---> VNet Spoke-A (10.1.0.0/16)
| [sistema inacessível]
VNet Gateway
O administrador verifica e confirma:
- O peering entre Hub e Spoke-A está como Connected nos dois lados
- A opção Allow Forwarded Traffic está habilitada no peering do lado do Hub
- O NSG da sub-rede do sistema em Spoke-A permite a porta necessária de qualquer origem
- O Local Network Gateway contém o prefixo 10.1.0.0/16 no espaço de endereços
- A latência reportada pelos usuários para os servidores acessíveis no Hub é normal (12ms)
Logs de diagnóstico do Virtual Network Gateway mostram:
[INFO] Route learned via BGP: 10.0.0.0/16 (Hub VNet)
[INFO] Route learned via BGP: 192.168.1.0/24 (on-premises)
[WARN] No route advertised for prefix: 10.1.0.0/16
Qual é a causa raiz do problema?
A) O NSG da sub-rede do sistema em Spoke-A está bloqueando o tráfego originado fora da VNet, pois a tag de serviço VirtualNetwork não abrange redes conectadas via VPN.
B) A opção Use Remote Gateways não está habilitada no peering do lado do Spoke-A, impedindo que o gateway do Hub anuncie o prefixo 10.1.0.0/16 para a filial via VPN.
C) O Local Network Gateway já contém o prefixo 10.1.0.0/16, o que cria um conflito com o roteamento aprendido via BGP e faz o tráfego ser descartado.
D) A opção Allow Gateway Transit não está habilitada no peering do lado do Hub, impedindo que o gateway encaminhe tráfego entre a VPN e o Spoke-A.
Cenário 4 — Sequência de Diagnóstico
Um usuário reporta que não consegue autenticar em uma aplicação publicada via Microsoft Entra Application Proxy. O sintoma relatado é: após inserir as credenciais no portal de login do Microsoft Entra ID, o navegador exibe um erro genérico 500 Internal Server Error e o usuário não é redirecionado para a aplicação.
Os passos de investigação disponíveis são:
- Passo P: Verificar os logs de sign-in no Microsoft Entra ID para identificar se a autenticação no Entra ID foi concluída com sucesso antes do erro
- Passo Q: Verificar se o conector do Application Proxy está ativo e com heartbeat recente no portal
- Passo R: Testar o acesso à URL interna da aplicação diretamente a partir do servidor onde o conector está instalado
- Passo S: Verificar se a URL externa do Application Proxy está corretamente mapeada para a URL interna nas configurações da aplicação
- Passo T: Reiniciar o serviço do conector no servidor on-premises
Qual sequência de diagnóstico está correta?
A) T -> P -> Q -> S -> R
B) P -> Q -> S -> R -> T
C) Q -> P -> R -> S -> T
D) P -> S -> Q -> R -> T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A saída do nslookup é a pista decisiva: o DNS retornou o IP 20.40.180.12, que é um IP público do Azure SQL. Isso confirma que a resolução DNS não está passando pela Private DNS Zone. Para que o DNS do Azure resolva nomes de Private Endpoints corretamente, a zona privatelink.database.windows.net precisa estar vinculada à VNet de onde a consulta se origina. A criação da zona no mesmo Resource Group é irrelevante sem o vínculo.
A informação irrelevante neste cenário é a configuração do NSG da sub-rede snet-data. O tráfego nem chega ao Private Endpoint porque o cliente está tentando se conectar ao IP público, que está bloqueado pelo firewall do SQL. O NSG não tem papel nessa falha.
A alternativa C é o distrator mais perigoso: o DNS padrão do Azure (168.63.129.16) suporta resolução via Private DNS Zones normalmente; o problema não é o servidor DNS, mas a ausência do vínculo da zona com a VNet. Agir com base nessa alternativa levaria a uma mudança desnecessária no DNS da VNet sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
O conjunto de restrições define claramente a janela de ação: há menos de uma hora antes do time encerrar, o grupo afetado inclui administradores de produção, e o fim de semana sem plantão torna qualquer impacto prolongado crítico. Alterar a política para Report-only restaura o acesso imediatamente, preserva a política existente (sem risco de perda de configuração), e ainda permite corrigir a lista de IPs com o segundo administrador disponível no mesmo momento.
A alternativa A comete um erro de sequência: usar a break glass account para corrigir os IPs e aguardar aprovação mantém o grupo de produção bloqueado durante todo o processo de aprovação e pelo fim de semana se algo falhar.
A alternativa C é a mais perigosa: excluir a política remove uma camada de segurança sem substituto imediato, e recriar na semana seguinte deixa o ambiente sem controle de localização por dias. A alternativa D é tecnicamente a mais irresponsável dado o contexto, pois deixa administradores de produção sem acesso direto por todo o fim de semana.
Gabarito — Cenário 3
Resposta: D
O log do Virtual Network Gateway é a pista definitiva: No route advertised for prefix: 10.1.0.0/16. O gateway não está anunciando o prefixo do Spoke-A para a filial via VPN. O motivo é que a opção Allow Gateway Transit no peering do lado do Hub não está habilitada. Essa opção permite que o gateway do Hub encaminhe tráfego entre conexões externas (como a VPN) e VNets em peering. Sem ela, o gateway ignora o Spoke-A como destino alcançável.
A informação irrelevante é a presença do prefixo 10.1.0.0/16 no Local Network Gateway. Esse prefixo indica o que a filial quer alcançar, mas não garante que o Azure anuncia essa rota de volta. O problema está no lado Azure, não no lado on-premises.
A alternativa B descreve uma condição complementar: Use Remote Gateways no spoke é necessário para que o spoke use o gateway do hub, mas o log confirma que o problema está no anúncio de rota pelo gateway, o que aponta para Allow Gateway Transit no hub. Ambas as opções precisam estar habilitadas em conjunto, mas dado o log, a ausência do Allow Gateway Transit no hub é a causa raiz confirmada.
Gabarito — Cenário 4
Resposta: B
A sequência correta segue a lógica de diagnóstico progressivo do fluxo do Application Proxy, do ponto mais externo para o mais interno:
| Passo | Ação | Justificativa |
|---|---|---|
| P | Verificar logs de sign-in no Entra ID | Determina se a autenticação foi concluída antes do erro 500 |
| Q | Verificar status do conector | Confirma se o plano de transporte entre nuvem e on-premises está ativo |
| S | Verificar mapeamento de URL | Confirma se o conector sabe para onde encaminhar a requisição |
| R | Testar URL interna a partir do servidor do conector | Confirma se a aplicação interna está respondendo |
| T | Reiniciar o conector | Ação corretiva, nunca primeiro passo |
O erro 500 ocorre após a autenticação no Entra ID (o usuário vê a tela de login), portanto o primeiro passo é confirmar no log se o token foi emitido corretamente (P). Reiniciar o conector (T) antes de qualquer diagnóstico (alternativa A) é o erro mais comum em troubleshooting: aplica uma ação corretiva cega que pode mascarar o problema real sem resolvê-lo, e se o conector não era o problema, o diagnóstico recomeça do zero.
Árvore de Troubleshooting: Diagnose and Resolve Client-Side and Authentication Issues
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou observável) |
| Laranja | Validação ou verificação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução (implícita nos nós de causa) |
Diante de um problema real, inicie pelo nó raiz descrevendo o sintoma e escolha o ramo que corresponde ao que você consegue observar diretamente: o DNS está resolvendo para IP público ou privado? A autenticação chegou a ser processada pelo Entra ID? O túnel VPN está de pé? Cada resposta elimina um conjunto inteiro de hipóteses. Os nós laranja indicam que é preciso coletar uma evidência antes de avançar. Os nós vermelhos encerram o raciocínio com a causa precisa, que direciona diretamente à ação corretiva.