Laboratório de Troubleshooting: Secure an origin by using Azure Private Link in Azure Front Door
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações recebe alertas de que requisições enviadas pelo Azure Front Door Premium para uma origem protegida via Private Link estão retornando 502 Bad Gateway de forma intermitente. O ambiente está em produção há três semanas sem alterações de configuração relatadas.
O engenheiro responsável coleta as seguintes informações durante a investigação:
[Front Door Health Probe Log]
Timestamp : 2024-11-14T18:32:11Z
Origin FQDN : app-backend-prod.azurewebsites.net
Probe Status : Timeout
HTTP Status : N/A
Latency (ms) : N/A
Private Link : Enabled
Connection State: Approved
[App Service Access Log - last 10 min]
Requests received : 0
Errors logged : 0
CPU usage (avg) : 12%
Memory usage : 34%
Informações adicionais coletadas:
- O Private Endpoint criado pelo Front Door aparece com status Aprovado no portal.
- O App Service está com acesso público habilitado.
- O plano do App Service é o P2v3, com capacidade disponível.
- O WAF no Front Door está em modo Detecção, sem bloqueios ativos.
- O health probe do Front Door está configurado para a rota
/healthzvia HTTPS na porta 443. - O arquivo de resposta em
/healthzfoi removido do repositório na última implantação feita há quatro dias.
Qual é a causa raiz do comportamento observado?
A. O WAF em modo Detecção está interferindo nas respostas do health probe e gerando timeouts falsos.
B. O App Service não está recebendo as requisições porque o acesso público foi desabilitado automaticamente após a aprovação do Private Link.
C. O endpoint /healthz não existe mais na aplicação, fazendo com que o health probe falhe e o Front Door marque a origem como degradada.
D. O Private Endpoint perdeu o estado de aprovação silenciosamente após 72 horas sem tráfego, exigindo reaprovação.
Cenário 2 — Decisão de Ação
A equipe de plataforma identificou que uma origem configurada no Azure Front Door Premium com Private Link está sendo acessada diretamente pela internet, sem passar pelo Front Door. Após investigação, confirmou-se que:
- A origem é um Azure App Service com o endpoint público ainda habilitado.
- O Private Link está ativo e aprovado.
- O Front Door está operando normalmente e entregando tráfego via canal privado.
- A janela de manutenção permitida é de sábado, das 02h às 04h (horário de Brasília).
- São quinta-feira, 16h, e o time de segurança exige resolução imediata por conta de uma auditoria em andamento.
A equipe tem permissão para fazer alterações no App Service mas não pode modificar as configurações do perfil do Front Door neste momento.
Qual é a ação correta a tomar agora?
A. Remover o endpoint privado do App Service para forçar todo o tráfego a passar pelo Front Door.
B. Configurar restrições de acesso no App Service para bloquear todo o tráfego que não venha da service tag AzureFrontDoor.Backend, preservando o canal Private Link.
C. Aguardar a janela de manutenção de sábado para desabilitar o endpoint público do App Service com menor risco operacional.
D. Habilitar o WAF no Front Door em modo Prevenção para bloquear o tráfego que chega diretamente à origem sem passar pelo Front Door.
Cenário 3 — Causa Raiz
Um arquiteto de nuvem configura o Azure Front Door Premium para usar Private Link Service sobre um Internal Load Balancer como origem. Após concluir a configuração, o status da conexão no portal do Front Door mostra:
Origin Name : ilb-origin-prod
Private Link : Enabled
Connection State : Pending
Last Updated : 2024-11-14T09:00:00Z
Duas horas depois, o estado permanece Pending. O arquiteto verifica o ILB e o Private Link Service e coleta:
[Private Link Service - ilb-pls-prod]
Region : brazilsouth
Alias : ilb-pls-prod.12345678.brazilsouth.azure.privatelinkservice
Visibility : Restricted (whitelist)
Auto-approval : Not configured
Pending Connections: 0
Active Connections: 0
Informações adicionais:
- O ILB está em
brazilsouthe está saudável, com backends respondendo normalmente. - O Front Door foi configurado com
privateLinkLocation: brazilsouth. - O DNS do Private Link Service está resolvendo corretamente no ambiente de teste.
- Nenhuma política de bloqueio está ativa na subscription.
- A visibilidade do Private Link Service está configurada como restrita, com uma lista de subscriptions autorizadas.
Qual é a causa raiz do estado Pending persistente?
A. O DNS do Private Link Service está resolvendo incorretamente, impedindo que o Front Door localize o serviço e registre a conexão.
B. A subscription do Azure Front Door não está incluída na lista de visibilidade restrita do Private Link Service, impedindo que a conexão seja registrada.
C. A configuração auto-approval não foi habilitada no Private Link Service, e a aprovação manual precisa ser realizada na aba de conexões pendentes do ILB.
D. O privateLinkLocation deve ser configurado com a região do Front Door, não do ILB, invertendo o valor informado.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o relato de que requisições ao Azure Front Door Premium estão retornando 421 Misdirected Request para um grupo de usuários específico. O ambiente usa Private Link para proteger a origem, e nenhuma mudança de configuração foi reportada nas últimas 48 horas.
O engenheiro tem disponíveis os seguintes passos de investigação:
- Verificar se o certificado TLS configurado na origem está com o CN ou SAN compatível com o hostname utilizado pelo Front Door no repasse.
- Verificar se o estado da conexão Private Link está como
Approvedno portal. - Confirmar se o header
Hostestá sendo preservado ou substituído corretamente nas configurações de rota do Front Door. - Checar os logs de health probe para identificar se a origem está sendo marcada como degradada.
- Validar se o WAF está em modo Prevenção e bloqueando padrões específicos do grupo afetado.
Qual é a sequência correta de investigação para esse sintoma?
A. 5 -> 2 -> 4 -> 3 -> 1
B. 4 -> 2 -> 5 -> 1 -> 3
C. 2 -> 4 -> 5 -> 3 -> 1
D. 3 -> 1 -> 4 -> 2 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista determinante está na combinação de dois fatos: o App Service não registra nenhuma requisição nos últimos 10 minutos e o arquivo /healthz foi removido na última implantação, feita quatro dias antes. O health probe do Front Door está configurado exatamente para esse caminho. Quando o probe não recebe resposta válida (o endpoint não existe mais, retornando 404 ou timeout dependendo da configuração), o Front Door começa a marcar a origem como degradada e interrompe ou reduz o envio de tráfego, gerando os 502 observados.
A informação sobre o status Approved do Private Link é relevante para eliminar problemas de conectividade de canal, mas não explica por que o App Service não recebe requisição alguma. O CPU e memória baixos eliminam sobrecarga como causa. O WAF em modo Detecção nunca bloqueia tráfego, tornando a alternativa A incorreta por definição.
A alternativa D descreve um comportamento que não existe: conexões Private Link aprovadas não expiram silenciosamente por inatividade. Agir com base nela levaria a uma reaprovação desnecessária sem resolver o problema real, enquanto o endpoint /healthz continuaria inexistente.
Gabarito — Cenário 2
Resposta: B
A causa já está identificada: o endpoint público do App Service está habilitado e acessível diretamente. O contexto impõe duas restrições críticas: a equipe pode alterar o App Service mas não o perfil do Front Door, e há uma auditoria em andamento exigindo resolução imediata. Aguardar o sábado (alternativa C) ignora a restrição de urgência imposta pelo contexto de auditoria.
A alternativa B é a ação correta porque as restrições de acesso do App Service permitem bloquear todo tráfego externo que não venha da service tag AzureFrontDoor.Backend, sem remover o endpoint público (o que poderia impactar o canal Private Link estabelecido) e sem mexer no perfil do Front Door. Essa ação pode ser executada imediatamente e resolve o vetor de acesso direto.
A alternativa A é tecnicamente perigosa: remover o Private Endpoint derrubaria o canal privado junto. A alternativa D é incorreta por razão arquitetural: o WAF opera no perímetro do Front Door e não tem capacidade de bloquear tráfego que nunca passa por ele.
Gabarito — Cenário 3
Resposta: B
O elemento decisivo está nos dados coletados do Private Link Service: Visibility: Restricted (whitelist) e Pending Connections: 0. Quando a visibilidade é restrita, apenas subscriptions explicitamente autorizadas conseguem registrar uma solicitação de conexão. Como a subscription usada pelo Azure Front Door não está na lista, o serviço nem sequer recebe a solicitação, razão pela qual o contador de conexões pendentes é zero e o estado no Front Door permanece Pending indefinidamente.
A informação sobre DNS resolvendo corretamente é propositalmente irrelevante: a resolução DNS ocorre no ambiente de teste do arquiteto, não no contexto do Front Door. A alternativa C confunde o mecanismo: a aprovação manual só seria necessária se a conexão chegasse ao Private Link Service como pendente, o que não está acontecendo. A alternativa D descreve um comportamento incorreto: o privateLinkLocation deve apontar para a região do recurso de origem, exatamente como foi configurado.
O distrator mais perigoso é C, porque levaria o engenheiro a procurar conexões pendentes em um lugar onde elas simplesmente não existem, perdendo tempo enquanto a causa real permanece na configuração de visibilidade.
Gabarito — Cenário 4
Resposta: D
O erro 421 Misdirected Request indica que a origem está rejeitando a requisição porque o hostname no header Host não corresponde ao certificado TLS apresentado ou não é reconhecido pelo servidor. A sequência correta parte do sintoma mais direto para causas progressivamente mais profundas:
3 -> 1 -> 4 -> 2 -> 5
O passo 3 é o primeiro porque o 421 é diretamente causado por incompatibilidade de hostname no repasse; o Front Door pode estar substituindo o header Host pelo FQDN do endpoint de origem em vez de preservar o hostname original. O passo 1 valida se o certificado cobre o hostname em uso. O passo 4 elimina degradação da origem como fator contribuinte. O passo 2 verifica a integridade do canal Private Link. O passo 5 é o último porque o WAF em modo Prevenção produziria 403, não 421, tornando-o improvável como causa primária mas ainda relevante para fechar o diagnóstico.
Começar pelo WAF (alternativas A e C) ou pelo health probe (alternativa B) representa um erro de triagem: o código de erro 421 é específico o suficiente para direcionar o diagnóstico diretamente ao processamento de TLS e hostname, não a bloqueios de segurança ou disponibilidade de origem.
Árvore de Troubleshooting: Secure an origin by using Azure Private Link in Azure Front Door
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Laranja | Verificação ou validação intermediária |
| 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ê consegue observar diretamente no portal, nos logs ou via CLI. Siga o caminho indicado pela sua resposta sem pular etapas. Perguntas sobre o estado do Private Link devem sempre ser verificadas no recurso de origem, não apenas no perfil do Front Door. Quando chegar a um nó de causa identificada, aplique a ação recomendada correspondente e valide o comportamento antes de encerrar o diagnóstico.