Laboratório de Troubleshooting: Configure access to private endpoints
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma VM hospedada na VNet-Prod (região East US) tenta acessar um Azure SQL Database via nome de host. O Private Endpoint foi criado na subnet snet-endpoints da mesma VNet há três dias e está com status Succeeded no portal. A conexão de rede pública do SQL Database foi desabilitada. A VM utiliza o servidor DNS padrão do Azure (168.63.129.16).
O engenheiro responsável executa o seguinte diagnóstico a partir da VM:
nslookup meu-servidor.database.windows.net
Server: 168.63.129.16
Address: 168.63.129.16
Non-authoritative answer:
Name: meu-servidor.privatelink.database.windows.net
Address: 20.42.65.90
Em seguida, testa a conectividade:
Test-NetConnection -ComputerName 20.42.65.90 -Port 1433
TcpTestSucceeded : False
O engenheiro verifica o portal e confirma que o IP privado alocado ao Private Endpoint é 10.1.2.5. A VNet não possui User Defined Routes configuradas. A subnet snet-endpoints tem uma política de rede para Private Endpoints com valor padrão.
Qual é a causa raiz da falha de conectividade?
A. O Azure DNS não consegue resolver nomes de Private Endpoints quando o acesso público do recurso está desabilitado, por isso retorna um IP público incorreto.
B. A Private DNS Zone não está vinculada à VNet, fazendo o DNS retornar o IP público do SQL Database em vez do IP privado do endpoint.
C. Um Network Security Group aplicado à subnet snet-endpoints está bloqueando o tráfego de entrada na porta 1433.
D. A política de rede para Private Endpoints na subnet está impedindo que o tráfego alcance o IP privado do endpoint.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: a Private DNS Zone privatelink.database.windows.net existe na assinatura, contém o registro A correto apontando para 10.1.2.5, mas não possui nenhum Virtual Network Link configurado.
O ambiente é de produção crítico. A janela de manutenção programada é às 23h. São 14h. O time de segurança informou que qualquer alteração em zonas DNS privadas requer aprovação prévia de um Change Advisory Board (CAB), mas há um processo de aprovação emergencial disponível com SLA de 2 horas.
O acesso ao SQL Database via endpoint público está completamente desabilitado e não pode ser reabilitado sem aprovação de nível mais elevado. Aplicações em produção estão falhando.
Qual é a ação correta a tomar neste momento?
A. Recriar o Private Endpoint com a opção de integração DNS habilitada, o que criará e vinculará a zona automaticamente, eliminando a necessidade de aprovação do CAB.
B. Acionar o processo de aprovação emergencial do CAB para adicionar o Virtual Network Link à Private DNS Zone existente, pois essa é a correção cirúrgica e de menor risco.
C. Aguardar a janela de manutenção às 23h e realizar a vinculação da zona DNS dentro do processo padrão de mudança.
D. Configurar um servidor DNS customizado na VNet apontando diretamente para o IP 10.1.2.5 como entrada estática, contornando a dependência da Private DNS Zone.
Cenário 3 — Causa Raiz
Uma equipe de dados configurou um Private Endpoint para uma conta de storage (conta-datalake) apontando para o sub-recurso dfs (Azure Data Lake Storage Gen2). A Private DNS Zone privatelink.dfs.core.windows.net foi criada e vinculada corretamente à VNet. As aplicações que utilizam o endpoint DFS funcionam sem problemas.
Semanas depois, uma aplicação de backup tenta acessar os mesmos dados via protocolo Blob:
nslookup conta-datalake.blob.core.windows.net
Server: 168.63.129.16
Address: 168.63.129.16
Non-authoritative answer:
Name: conta-datalake.privatelink.blob.core.windows.net
Address: 52.239.184.16
A aplicação de backup falha ao tentar gravar arquivos. O time verifica que o acesso público da conta de storage está desabilitado. A subnet onde a aplicação está hospedada possui saída para internet via NAT Gateway, que foi recentemente adicionado para permitir atualizações de pacotes nas VMs.
Qual é a causa raiz da falha da aplicação de backup?
A. O NAT Gateway adicionado à subnet está interceptando o tráfego destinado ao Private Endpoint e roteando-o para a internet, impedindo o acesso privado.
B. Não existe um Private Endpoint criado para o sub-recurso blob da mesma conta de storage, por isso o DNS resolve para o IP público, que está inacessível.
C. A Private DNS Zone privatelink.dfs.core.windows.net está em conflito com a resolução do subdomínio blob, causando falha na resposta DNS.
D. O acesso público desabilitado impede qualquer aplicação de acessar o sub-recurso blob mesmo que um Private Endpoint seja criado posteriormente.
Cenário 4 — Sequência de Diagnóstico
Uma VM em uma VNet conectada via VNet Peering a outra VNet (onde o Private Endpoint está provisionado) não consegue alcançar o serviço exposto pelo endpoint. O peering está no estado Connected em ambos os lados. A VM consegue fazer ping em outras VMs da VNet remota sem problemas.
Os passos de investigação disponíveis são:
- Verificar se a Private DNS Zone está vinculada à VNet da VM (não apenas à VNet do endpoint)
- Confirmar que o peering está ativo e no estado Connected
- Executar
nslookupa partir da VM e verificar se o nome resolve para o IP privado ou público - Verificar se há NSG na subnet da VM bloqueando o tráfego na porta do serviço
- Confirmar o IP privado alocado ao Private Endpoint no portal do Azure
Qual é a sequência correta de investigação para este cenário?
A. 2 → 1 → 3 → 5 → 4
B. 3 → 1 → 5 → 4 → 2
C. 2 → 3 → 1 → 5 → 4
D. 1 → 3 → 5 → 2 → 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva está nos dois comandos executados em sequência. O nslookup retornou 20.42.65.90, que é o IP público do SQL Database, confirmando que o DNS não está resolvendo para o IP privado. Contudo, a pergunta não é sobre o DNS: o engenheiro testou a conectividade diretamente com esse IP público via Test-NetConnection. A falha de TCP nesse IP é esperada, pois o acesso público está desabilitado.
O diagnóstico correto exige perceber que o real problema de acesso seria descoberto apenas ao testar o IP privado 10.1.2.5. O enunciado informa que a subnet snet-endpoints tem a política de rede de Private Endpoints com valor padrão, e é exatamente esse o gatilho: a política de rede (PrivateEndpointNetworkPolicies) no estado padrão pode impedir que NSGs e UDRs sejam aplicados, mas quando habilitada em modo restritivo, ela pode bloquear o tráfego. No entanto, a causa mais precisa e verificável com as informações dadas é um NSG na subnet bloqueando a porta 1433, pois o IP privado nunca foi testado diretamente.
A alternativa B seria a causa da falha de DNS (IP público retornado), não da falha de conectividade TCP. A informação do NAT Gateway não aparece neste cenário; o engenheiro nunca testou o IP privado 10.1.2.5. A alternativa D confunde o comportamento da política de rede, que por padrão não bloqueia tráfego. A alternativa A é tecnicamente incorreta: o Azure DNS resolve Private Endpoints independentemente do estado do acesso público.
O erro mais perigoso seria escolher B e ir corrigir o DNS sem nunca testar o IP privado diretamente, o que atrasaria o diagnóstico real.
Gabarito — Cenário 2
Resposta: B
A causa está identificada e é precisa: falta o Virtual Network Link na Private DNS Zone existente. A correção cirúrgica é adicionar esse link, uma operação atômica e de baixíssimo risco que não altera registros DNS, não recria recursos e não afeta outras zonas ou VNets.
O processo de aprovação emergencial com SLA de 2 horas existe exatamente para situações como essa: produção impactada, causa identificada, correção de baixo risco. Acionar esse processo é a única resposta que respeita todas as restrições do cenário.
A alternativa A parece razoável mas viola uma restrição crítica: recriar o Private Endpoint implicaria deletar e recriar um recurso de produção em uso, o que é uma operação de maior impacto e risco do que simplesmente adicionar um link DNS. Além disso, a recriação do endpoint também precisaria de aprovação do CAB.
A alternativa C ignora o impacto em produção: aplicações estão falhando agora, e aguardar 9 horas sem acionar o processo emergencial é negligência operacional.
A alternativa D é tecnicamente perigosa: configurar uma entrada estática de DNS para o IP do endpoint contorna toda a infraestrutura de resolução, torna o ambiente frágil a mudanças futuras no IP do endpoint e não segue nenhuma prática recomendada pela Microsoft.
Gabarito — Cenário 3
Resposta: B
A causa raiz é direta: um Private Endpoint criado para o sub-recurso dfs não cobre o sub-recurso blob. Cada sub-recurso de uma conta de storage possui seu próprio FQDN, seu próprio Private Endpoint e sua própria Private DNS Zone. O nslookup retorna o IP público para blob.core.windows.net porque não existe registro A privado para esse subdomínio em nenhuma zona vinculada à VNet.
A informação sobre o NAT Gateway é deliberadamente irrelevante neste cenário. NAT Gateways afetam tráfego de saída para a internet, mas Private Endpoints são acessados via rotas internas da VNet e não passam pelo NAT Gateway. Incluir essa informação força o leitor a testar se associará a falha a uma mudança recente de infraestrutura, o que é um erro diagnóstico clássico: correlação temporal sem causalidade real.
A alternativa C é tecnicamente impossível: zonas DNS privadas para subdomínios diferentes (dfs vs blob) são independentes e não interferem entre si. A alternativa D é incorreta: desabilitar o acesso público não impede a criação de novos Private Endpoints nem bloqueia endpoints já existentes.
Gabarito — Cenário 4
Resposta: C
A sequência correta é 2 → 3 → 1 → 5 → 4, que segue a lógica de eliminação progressiva de hipóteses do mais simples para o mais específico.
O primeiro passo é confirmar que o peering está ativo (passo 2), pois sem conectividade de camada 3 nenhum outro diagnóstico faz sentido. O enunciado já informa que o peering está Connected, mas em um diagnóstico real essa validação é sempre o ponto de partida antes de investigar camadas superiores.
Com a conectividade de base confirmada, o passo 3 (executar nslookup) revela imediatamente se o problema é de resolução DNS ou de conectividade TCP. Essa distinção define o caminho seguinte: se o DNS resolve para o IP público, o problema está na vinculação da zona (passo 1). Se resolve para o IP privado mas o TCP falha, o problema está na camada de rede (passo 4).
O passo 5 (confirmar o IP privado no portal) serve como referência para validar se o IP retornado pelo DNS é o correto antes de investigar NSGs.
A alternativa B começa pelo nslookup sem antes confirmar a conectividade básica, o que pode gerar diagnósticos falsos. A alternativa A confirma o peering mas pula direto para a zona DNS antes de sequer observar o comportamento do DNS com nslookup. A alternativa D começa pela zona DNS sem nenhuma evidência de que o problema está ali.
Árvore de Troubleshooting: Configure access to private endpoints
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão sim/não) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e responda cada pergunta diagnóstica com base no que você pode verificar diretamente no ambiente. O primeiro ponto de bifurcação, se o nome resolve para um IP privado ou público, é o mais importante: ele separa imediatamente os problemas de DNS dos problemas de conectividade de rede, que exigem caminhos de investigação completamente diferentes. Siga as ramificações até chegar a um nó de causa identificada (vermelho) e execute a ação correspondente (verde). Os nós de validação intermediária (laranja) indicam onde você precisa coletar evidências antes de avançar para a próxima pergunta.