Pular para o conteúdo principal

Laboratório de Troubleshooting: Configure private endpoints for Azure PaaS

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Uma equipe de desenvolvimento reporta que uma aplicação hospedada em uma VM dentro de vnet-app (região East US) não consegue conectar a um Azure Storage Account após a criação de um private endpoint. O administrador verifica o seguinte:

  • O private endpoint foi criado na subnet snet-pe dentro de vnet-app.
  • A Private DNS Zone privatelink.blob.core.windows.net existe no ambiente.
  • A VM consegue pingar outros recursos na mesma VNet normalmente.
  • O Storage Account tem o acesso público ainda habilitado.
  • A aplicação reporta timeout ao tentar acessar storprod001.blob.core.windows.net.

O administrador executa o seguinte teste a partir da VM:

nslookup storprod001.blob.core.windows.net

Saída:

Server:  168.63.129.16
Address:  168.63.129.16#53

Non-authoritative answer:
Name:    storprod001.blob.core.windows.net
Address: 20.150.47.131

A equipe menciona que o Storage Account foi criado há seis meses e nunca apresentou problemas antes da tentativa de migração para acesso privado. O private endpoint foi criado ontem à noite.

Qual é a causa raiz do problema?

A. O NSG aplicado à subnet snet-pe está bloqueando o tráfego de saída da VM para a porta 443.

B. A Private DNS Zone não está vinculada à vnet-app, portanto o DNS continua resolvendo o FQDN para o IP público do Storage Account.

C. O acesso público do Storage Account precisa ser desabilitado antes que o private endpoint comece a funcionar.

D. O private endpoint foi criado na subnet errada; ele deveria estar na subnet da VM e não em snet-pe.

Cenário 2 — Decisão de Ação​

A causa do problema já foi identificada: um Azure Key Vault de produção tem um private endpoint ativo, mas a Private DNS Zone privatelink.vaultcore.azure.net foi acidentalmente excluída por um membro da equipe. Como consequência, todas as aplicações que acessam o Key Vault via nome privado estão falhando com erros de conexão recusada, impactando um sistema de pagamentos em produção.

O administrador tem permissões de Contributor no Resource Group onde a DNS Zone existia, mas não possui permissões de Private DNS Zone Contributor no nível de subscription. O time de segurança exige que qualquer alteração em zonas DNS privadas seja registrada via ticket de mudança, processo que leva 48 horas para aprovação.

O sistema de pagamentos tem um SLA de 99,9% e cada minuto de indisponibilidade gera penalidade contratual. O engenheiro sênior responsável pelo Key Vault está disponível e possui as permissões necessárias.

Qual é a ação correta a tomar neste momento?

A. Recriar imediatamente a Private DNS Zone e vinculá-la à VNet usando as próprias permissões de Contributor, sem aguardar aprovação, dado o impacto em produção.

B. Abrir o ticket de mudança, documentar o impacto e aguardar as 48 horas de aprovação para manter a conformidade com o processo de segurança.

C. Contatar imediatamente o engenheiro sênior para que ele recrie a Private DNS Zone com as permissões corretas, enquanto o ticket de mudança é aberto em paralelo para conformidade retroativa.

D. Reverter temporariamente o Key Vault para acesso público até que a DNS Zone seja recriada dentro do processo formal de mudança.

Cenário 3 — Causa Raiz​

Um administrador configura um private endpoint para um Azure SQL Database em snet-data dentro de vnet-hub. A Private DNS Zone privatelink.database.windows.net foi criada e vinculada a vnet-hub. O registro A foi criado automaticamente pelo Azure.

Dois dias depois, a equipe de dados reporta que consultas ao banco de dados a partir de VMs em vnet-spoke (pareada com vnet-hub) funcionam, mas uma aplicação rodando em um Azure Kubernetes Service (AKS) no mesmo vnet-spoke falha consistentemente com o seguinte erro:

dial tcp: lookup sql-prod.database.windows.net on 10.0.0.10:53: no such host

O administrador verifica:

  • O peering entre vnet-hub e vnet-spoke está ativo e bidirecional.
  • VMs em vnet-spoke resolvem sql-prod.database.windows.net corretamente para 10.1.2.5 (IP privado).
  • O cluster AKS usa Azure CNI e os pods recebem IPs diretamente da subnet snet-aks em vnet-spoke.
  • O cluster AKS foi criado com a opção de DNS padrão do Kubernetes, que usa CoreDNS.
  • A Private DNS Zone privatelink.database.windows.net está vinculada a vnet-hub e a vnet-spoke.

Qual é a causa raiz do erro de resolução DNS nos pods do AKS?

A. O peering entre vnet-hub e vnet-spoke não propaga registros de Private DNS Zones, por isso os pods não conseguem resolver o nome.

B. O CoreDNS do AKS não está configurado para encaminhar queries do domínio privatelink.database.windows.net ao Azure DNS (168.63.129.16), então as queries não chegam à Private DNS Zone.

C. A Private DNS Zone deveria estar vinculada à subnet snet-aks especificamente, e não apenas à VNet.

D. O erro indica que o registro A na Private DNS Zone foi excluído automaticamente após 48 horas, comportamento padrão do Azure para registros criados por private endpoints.

Cenário 4 — Sequência de Diagnóstico​

Um administrador recebe o seguinte alerta: uma função Azure (Azure Function) com VNet Integration habilitada não consegue acessar um Azure Service Bus que tem um private endpoint configurado. A função retorna SocketException: Connection refused ao tentar publicar mensagens.

Os passos de investigação disponíveis estão fora de ordem:

  1. Verificar se a Private DNS Zone privatelink.servicebus.windows.net está vinculada à VNet integrada pela Azure Function.
  2. Confirmar se o acesso público do Service Bus foi desabilitado e se a regra de firewall permite o IP da Function.
  3. Testar a resolução DNS do FQDN do Service Bus a partir do ambiente de execução da Function usando nslookup ou Resolve-DnsName.
  4. Verificar se a VNet Integration da Azure Function está configurada e apontando para a VNet correta.
  5. Confirmar que o private endpoint do Service Bus foi criado na subnet correta e que o IP privado está alocado.

Qual é a sequência correta de diagnóstico?

A. 5 -> 1 -> 4 -> 3 -> 2

B. 4 -> 5 -> 1 -> 3 -> 2

C. 3 -> 1 -> 4 -> 5 -> 2

D. 2 -> 4 -> 1 -> 5 -> 3

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: B

A pista definitiva está na saída do nslookup: o FQDN está resolvendo para 20.150.47.131, que é um IP público. Se a Private DNS Zone estivesse vinculada à vnet-app, o Azure DNS (168.63.129.16) retornaria o IP privado do private endpoint, tipicamente na faixa de endereços da subnet. O fato de o resolver ser o próprio 168.63.129.16 mas retornar um IP público confirma que ele consultou a DNS pública porque não encontrou a zona privada associada à VNet.

A informação irrelevante no enunciado é a idade do Storage Account ("criado há seis meses"). Ela não tem nenhuma relação com o comportamento do private endpoint ou da DNS Zone.

A alternativa C representa o equívoco mais perigoso: desabilitar o acesso público não é pré-requisito para que o private endpoint funcione. Ele pode coexistir com o acesso público durante uma migração. Agir com base nessa alternativa quebraria o acesso público sem resolver o problema de DNS.

A alternativa D é tecnicamente incorreta: o private endpoint deve estar em uma subnet da VNet, mas não precisa ser a mesma subnet da VM. Qualquer subnet dentro da mesma VNet (ou VNet com acesso via peering) é válida.

Gabarito — Cenário 2​

Resposta: C

O cenário apresenta duas restrições que tornam as outras alternativas inviáveis: o administrador não tem permissão para recriar a DNS Zone (elimina A), e o processo formal exige 48 horas (elimina B como ação imediata dada a penalidade contratual em curso). A alternativa D é tecnicamente válida como mitigação emergencial, mas expõe o Key Vault de produção publicamente, violando o modelo de segurança e criando um risco maior do que o problema original.

A alternativa C é a única que respeita todas as restrições simultaneamente: resolve o problema com urgência usando quem tem permissão, mantém o registro de conformidade por meio do ticket paralelo, e não expõe o recurso publicamente.

O raciocínio correto aqui é identificar que "ação correta" não significa "ação tecnicamente possível", mas "ação que atende ao conjunto de restrições de segurança, permissão e SLA ao mesmo tempo".

Gabarito — Cenário 3​

Resposta: B

A pista crítica é que VMs na mesma vnet-spoke resolvem o nome corretamente, mas os pods do AKS não. Isso elimina imediatamente a alternativa A: se o peering não propagasse a DNS Zone, as VMs também falhariam. O problema é específico ao ambiente de execução dos pods.

O CoreDNS, que é o resolvedor DNS padrão do Kubernetes, gerencia as queries DNS dos pods. Por padrão, ele não encaminha automaticamente domínios do Azure para o Azure DNS. É necessário configurar um ConfigMap do CoreDNS com uma regra de forward para os domínios privatelink.* apontando para 168.63.129.16. Sem isso, as queries saem pelo CoreDNS, que não as encontra e retorna no such host.

A alternativa C é tecnicamente incorreta: Private DNS Zones são vinculadas a VNets inteiras, não a subnets individuais. A alternativa D é falsa: registros A criados por private endpoints são permanentes enquanto o endpoint existir.

A informação potencialmente distratora é o detalhe sobre Azure CNI: ele é relevante para entender que os pods têm IPs da VNet, mas não é a causa do problema de DNS. O Azure CNI resolve conectividade de rede, não resolução de nomes.

Gabarito — Cenário 4​

Resposta: B

A sequência correta segue a lógica de diagnóstico progressivo: verificar primeiro se a integração de rede existe (passo 4), depois confirmar se o private endpoint está corretamente provisionado com IP alocado (passo 5), em seguida validar se a resolução DNS está apontando para o IP privado (passo 1), então testar a resolução efetiva do FQDN no ambiente de execução da Function (passo 3), e por último verificar configurações de firewall e acesso público (passo 2).

A sequência B (4 -> 5 -> 1 -> 3 -> 2) respeita a pirâmide diagnóstica: confirmar infraestrutura antes de testar comportamento, e testar comportamento antes de ajustar políticas. Começar pelo passo 3 (alternativa C) ou pelo passo 2 (alternativa D) inverte a lógica: não adianta testar DNS antes de confirmar que a VNet Integration e o endpoint estão funcionando, e não adianta revisar firewall antes de confirmar que o DNS resolve para o IP correto.

O distrator mais perigoso é a alternativa C, que começa pelo teste de DNS. Ele parece razoável, mas sem confirmar que a VNet Integration está ativa (passo 4), o resultado do nslookup pode ser enganoso, pois a Function poderia estar resolvendo DNS fora do contexto da VNet.

Árvore de Troubleshooting: Configure private endpoints for Azure PaaS​

100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Legenda:

CorSignificado
Azul escuroSintoma inicial (ponto de entrada)
AzulPergunta de diagnóstico
VermelhoCausa identificada ou ação corretiva
VerdeResolução confirmada
LaranjaVerificação intermediária antes de concluir

Para usar esta árvore diante de um problema real, comece pelo nó raiz (sintoma observado) e responda cada pergunta com base no que você pode verificar diretamente no ambiente. O primeiro passo sempre é testar a resolução DNS do FQDN do recurso: se o resultado for um IP público, o problema está na camada de DNS. Se for um IP privado mas o acesso ainda falhar, o problema está na camada de rede ou no firewall do recurso. Siga o caminho correspondente até chegar a uma causa identificada antes de executar qualquer ação corretiva.