Laboratório de Troubleshooting: Configure networking settings for an App Service
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento relata que um App Service no plano Premium P2v3 não consegue resolver nomes DNS de recursos internos dentro da VNet integrada. A aplicação retorna o seguinte erro ao tentar conectar ao servidor interno db-interno.corp.local:
System.Net.Sockets.SocketException: No such host is known
at System.Net.Dns.GetHostEntryOrAddressesCore(String hostName, ...)
Host: db-interno.corp.local
Ao investigar o ambiente, você coleta as seguintes informações:
| Configuração | Valor |
|---|---|
| VNet Integration | Habilitada (regional) |
| WEBSITE_VNET_ROUTE_ALL | 1 |
| Plano do App Service | Premium P2v3 |
| Subnet de integração | /24, delegada a Microsoft.Web/serverFarms |
| DNS da VNet | Configurado para 10.0.0.4 (servidor DNS interno) |
| Private Endpoint no App Service | Não configurado |
| Região do App Service | East US |
| Certificado TLS do app | Válido, emitido há 3 dias |
A subnet de integração tem 240 endereços disponíveis. O servidor DNS 10.0.0.4 responde corretamente quando consultado a partir de uma VM na mesma VNet.
Qual é a causa raiz da falha na resolução de nomes?
A) A subnet de integração não tem endereços suficientes para a operação do App Service no plano Premium
B) O App Service não está usando o servidor DNS configurado na VNet porque a configuração WEBSITE_DNS_SERVER não foi definida no nível do App Service
C) Private Endpoint não está habilitado, o que impede o tráfego DNS de alcançar servidores internos via VNet Integration
D) O valor WEBSITE_VNET_ROUTE_ALL = 1 redireciona o tráfego DNS para a internet, ignorando o DNS interno da VNet
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o App Service de produção está com Access Restrictions mal configuradas. Uma regra "Allow" foi adicionada para o bloco 10.0.0.0/8, mas a regra padrão do sistema permanece com prioridade 2147483647 como "Allow All" em vez de "Deny All", porque o recurso foi criado por um script legado que não configurou a restrição padrão corretamente.
Como resultado, qualquer IP da internet consegue acessar o App Service, contrariando a política de segurança da empresa.
O contexto operacional é o seguinte:
- O App Service está em produção com SLA ativo
- Existe uma dependência de um serviço de healthcheck externo monitorando o endpoint
/healtha partir do IP198.51.100.20 - A equipe de segurança exige que o acesso seja restrito imediatamente
- Você tem permissão de escrita no recurso
- Não há janela de manutenção aberta
Qual é a ação correta a tomar neste momento?
A) Excluir o App Service e recriá-lo via ARM template com as Access Restrictions corretas, garantindo consistência total da configuração
B) Adicionar uma regra "Deny" explícita para 0.0.0.0/0 com prioridade 100 imediatamente, sem considerar o healthcheck externo
C) Adicionar uma regra "Allow" para 198.51.100.20 com prioridade alta, em seguida adicionar uma regra "Deny" para 0.0.0.0/0, mantendo a regra existente para 10.0.0.0/8
D) Aguardar a janela de manutenção para aplicar as restrições, pois qualquer alteração em Access Restrictions causa reinicialização do App Service
Cenário 3 — Causa Raiz
Um arquiteto configurou um Private Endpoint para um App Service corporativo e criou uma Private DNS Zone vinculada à VNet. Após a configuração, usuários internos que acessam via VPN corporativa relatam que o acesso ao app funciona corretamente. Porém, um parceiro externo que acessa o mesmo hostname pela internet recebe o seguinte comportamento:
curl -v https://meuapp.azurewebsites.net
* Trying 20.45.132.18...
* Connected to meuapp.azurewebsites.net (20.45.132.18) port 443
> GET / HTTP/1.1
< HTTP/1.1 403 Forbidden
< x-ms-error-code: Forbidden
O parceiro confirma que o certificado TLS é válido e a conexão TCP é estabelecida. O App Service está no plano Premium P3v3. A equipe informa que o App Service foi migrado de outro tenant há duas semanas e que o Custom Domain foi reconfigurado nessa migração. O endpoint público do App Service nunca foi desabilitado após a criação do Private Endpoint.
Qual é a causa raiz do erro 403 recebido pelo parceiro externo?
A) O certificado TLS foi reemitido durante a migração de tenant e não é reconhecido pelo cliente externo, causando rejeição na camada de aplicação
B) O parceiro está resolvendo o hostname para o IP público do App Service, e como o endpoint público não foi desabilitado mas não há Access Restriction permitindo o IP do parceiro, a requisição é bloqueada pela regra padrão
C) A Private DNS Zone está interceptando as consultas DNS externas e retornando o IP privado, tornando o App Service inacessível fora da VNet
D) O plano Premium P3v3 não suporta acesso simultâneo via Private Endpoint e endpoint público, gerando conflito de roteamento
Cenário 4 — Sequência de Diagnóstico
Um App Service em produção parou de se comunicar com um Azure Service Bus hospedado em uma VNet privada. A falha começou após uma atualização de configuração realizada ontem à tarde. Não houve alteração no código da aplicação.
Você tem os seguintes passos disponíveis para investigar:
[P1] Verificar se a VNet Integration ainda está associada ao App Service e se a subnet está correta
[P2] Confirmar se o Service Bus responde corretamente a partir de uma VM na mesma subnet
[P3] Revisar o histórico de Activity Log do App Service nas últimas 24 horas
[P4] Testar a conectividade de saída do App Service usando o recurso "Diagnose and Solve Problems > Network checks"
[P5] Verificar se houve alteração no NSG associado à subnet de integração
Qual é a sequência correta de investigação?
A) P3 → P1 → P5 → P2 → P4
B) P2 → P4 → P1 → P3 → P5
C) P3 → P1 → P4 → P5 → P2
D) P1 → P3 → P5 → P2 → P4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva no enunciado é que o DNS da VNet está corretamente configurado para 10.0.0.4 e esse servidor responde a partir de VMs na mesma VNet. Isso elimina qualquer problema no servidor DNS em si. O App Service com VNet Integration regional usa, por padrão, o DNS do Azure (168.63.129.16) e não herda automaticamente o DNS configurado na VNet. Para forçar o uso do servidor DNS interno, é necessário definir a configuração de aplicativo WEBSITE_DNS_SERVER com o endereço 10.0.0.4.
A informação sobre o certificado TLS válido é irrelevante para o diagnóstico de resolução DNS e foi incluída propositalmente para desviar a atenção.
O distrator C representa o erro mais perigoso: confundir os papéis de Private Endpoint (tráfego de entrada) e VNet Integration (tráfego de saída). Private Endpoint não tem relação com a capacidade do App Service de resolver nomes via DNS interno.
O distrator D inverte a lógica do WEBSITE_VNET_ROUTE_ALL: esse valor força o tráfego de saída pela VNet, o que beneficia o acesso ao DNS interno, não o prejudica.
Gabarito — Cenário 2
Resposta: C
O cenário apresenta duas restrições críticas: a exigência de ação imediata e a dependência do healthcheck externo em 198.51.100.20. A alternativa C é a única que satisfaz ambas simultaneamente, criando primeiro a regra de exceção para o healthcheck antes de fechar o acesso geral.
O distrator B resolve o problema de segurança mas quebra o healthcheck externo imediatamente, gerando um alerta de indisponibilidade durante uma janela fora de manutenção, o que viola o SLA ativo.
O distrator A é tecnicamente válido para padronizar a configuração, mas recriar um App Service de produção fora de janela de manutenção representa um risco operacional desproporcional ao problema.
O distrator D contém uma premissa falsa: alterações em Access Restrictions não causam reinicialização do App Service. Agir com base nesse distrator significa deixar o acesso não autorizado ativo por mais tempo sem necessidade.
Gabarito — Cenário 3
Resposta: B
A pista central está em dois fatos: a conexão TCP é estabelecida (o IP público responde na porta 443) e o erro é 403 Forbidden com x-ms-error-code: Forbidden. Esse é exatamente o comportamento das Access Restrictions do App Service quando uma requisição é bloqueada pela regra padrão após a criação de qualquer regra explícita. Com a criação do Private Endpoint, é provável que uma regra "Allow" para a VNet tenha sido adicionada, ativando o modo de avaliação de regras e tornando a regra padrão "Deny All" efetiva para tráfego externo não autorizado.
A informação sobre a migração de tenant e a reconfiguração do Custom Domain é irrelevante para o diagnóstico. O erro não está na camada TLS, pois a conexão foi estabelecida com sucesso.
O distrator C representa um equívoco importante: Private DNS Zones não afetam consultas DNS externas. Elas são resolvidas apenas por clientes dentro da VNet vinculada. Um cliente externo resolve o hostname via DNS público da Microsoft, que retorna o IP público normalmente.
O distrator mais perigoso é A: focar no certificado por causa da menção à migração de tenant. O enunciado diz explicitamente que a conexão TCP e TLS foram estabelecidas com sucesso, o que descarta qualquer problema de certificado.
Gabarito — Cenário 4
Resposta: A
A sequência correta começa por P3 (Activity Log) porque o enunciado confirma que a falha começou após uma atualização de configuração ontem. O Activity Log identifica exatamente o que foi alterado, direcionando toda a investigação subsequente. Com essa informação, P1 verifica se a VNet Integration foi afetada, P5 verifica se o NSG da subnet foi alterado (causa mais comum de bloqueio de saída), P2 valida se o Service Bus é alcançável pela rede, e P4 confirma a conectividade de saída do próprio App Service.
A sequência D (P1 → P3 → P5 → P2 → P4) parece lógica mas erra ao verificar o estado atual antes de entender o que mudou. Começar pelo P1 sem saber o que foi alterado pode levar a uma investigação longa em componentes que estão corretos.
A sequência B começa por P2, que verifica o Service Bus isoladamente sem nenhuma evidência de que o problema está nele. É o erro clássico de diagnosticar o destino antes de validar o caminho e o ponto de origem.
Árvore de Troubleshooting: Configure networking settings for an App Service
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (nó de decisão) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
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, sem presumir a causa. A primeira bifurcação separa problemas de saída (o App Service não alcança algo) de problemas de entrada (algo não consegue acessar o App Service). A partir daí, cada resposta elimina caminhos inteiros de investigação. Ao chegar a um nó vermelho, você tem a causa identificada. Ao chegar a um nó verde, execute a ação indicada e valide se o sintoma foi resolvido antes de encerrar o diagnóstico.