Pular para o conteúdo principal

Laboratório de Troubleshooting: Plan private endpoints

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Uma equipe reporta que uma aplicação hospedada em uma VM na spoke-vnet-prod não consegue se conectar a um Azure Key Vault. O private endpoint do Key Vault foi provisionado na hub-vnet há três dias e funcionou normalmente durante os testes iniciais realizados a partir de VMs no próprio hub.

O ambiente possui as seguintes características:

  • Peering entre hub-vnet e spoke-vnet-prod está ativo, bidirecional e com "Allow forwarded traffic" habilitado
  • A VM na spoke usa o servidor DNS customizado 10.1.0.4, hospedado no hub
  • O servidor DNS customizado está configurado com forwarder apontando para 168.63.129.16
  • O NSG da subnet do private endpoint não possui regras de bloqueio para a porta 443
  • A conta de serviço da aplicação tem permissão de leitura no Key Vault via RBAC
  • A zona DNS privada privatelink.vaultcore.azure.net está vinculada apenas à hub-vnet

A equipe executou o seguinte diagnóstico a partir da VM na spoke:

curl -v https://contoso-kv.vault.azure.net/secrets/dbpassword
* Could not resolve host: contoso-kv.vault.azure.net
* Closing connection 0
curl: (6) Could not resolve host: contoso-kv.vault.azure.net

Em seguida, testaram conectividade direta pelo IP:

curl -v https://10.1.2.5/secrets/dbpassword
* Connected to 10.1.2.5 (10.1.2.5) port 443 (#0)
* SSL certificate subject: CN=contoso-kv.vault.azure.net
* SSL certificate verify ok.
< HTTP/2 200

Qual é a causa raiz da falha observada?

A) O peering entre hub e spoke não está propagando as rotas do private endpoint, impedindo que o tráfego chegue ao IP privado 10.1.2.5
B) A zona DNS privada não está vinculada à hub-vnet, fazendo com que o servidor DNS customizado não consiga resolver o FQDN
C) A zona DNS privada está vinculada apenas à hub-vnet, e como o servidor DNS customizado faz forward para o Azure DNS no contexto do hub, a spoke não recebe a resolução privada por falta de link da zona com a spoke-vnet-prod
D) O NSG da subnet da VM na spoke está bloqueando a consulta DNS na porta 53 em direção ao servidor 10.1.0.4

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

A equipe de plataforma identificou que um private endpoint provisionado em produção para um namespace do Azure Service Bus está inacessível a partir de todas as VMs da VNet. O diagnóstico confirmou que a causa é a ausência de qualquer registro na zona DNS privada privatelink.servicebus.windows.net. O private endpoint foi criado manualmente via ARM template por um engenheiro que não habilitou a integração automática com DNS privado durante o provisionamento.

O ambiente possui as seguintes restrições:

  • O private endpoint está em produção e recebendo tráfego de três aplicações críticas que usam o IP privado hardcoded temporariamente como contorno
  • A equipe tem permissão para modificar zonas DNS privadas e criar vínculos, mas não tem permissão para recriar ou excluir private endpoints no ambiente de produção
  • Uma janela de manutenção está disponível em 48 horas
  • A zona DNS privada privatelink.servicebus.windows.net já existe e está vinculada à VNet correta

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

A) Recriar o private endpoint com a opção de integração DNS habilitada, substituindo o endpoint existente durante a janela de manutenção
B) Criar manualmente um registro A na zona DNS privada existente apontando para o IP privado do private endpoint, sem aguardar a janela de manutenção
C) Aguardar a janela de manutenção e então reconfigurar o ARM template para habilitar a integração DNS, reaplicando o template completo
D) Criar um segundo private endpoint idêntico com integração DNS habilitada e redirecionar o tráfego das aplicações para o novo endpoint durante a janela de manutenção

Cenário 3 — Causa Raiz​

Uma equipe de segurança aplicou uma política de NSG mais restritiva na subnet pe-subnet de uma VNet, com o objetivo de controlar o tráfego de entrada e saída dos private endpoints ali hospedados. Após a mudança, as equipes de aplicação reportaram que os private endpoints continuam acessíveis normalmente, sem qualquer bloqueio, mesmo para conexões que as novas regras deveriam bloquear.

O ambiente:

  • Subnet pe-subnet criada há seis meses com private endpoints de storage e SQL
  • NSG nsg-pe-prod recém-criado, com regras de negação explícita para tráfego vindo de subnets não autorizadas
  • NSG associado corretamente à pe-subnet via portal
  • Logs do NSG foram habilitados após a mudança e mostram zero hits nas regras de negação
  • A equipe de rede confirmou que não há Azure Firewall ou NVA interceptando o tráfego antes do NSG

O engenheiro responsável pela mudança assume que o NSG está com defeito ou foi sobrescrito por uma Azure Policy.

Qual é a causa raiz do comportamento observado?

A) Uma Azure Policy com efeito Audit está impedindo que as regras de negação do NSG sejam avaliadas corretamente
B) A propriedade PrivateEndpointNetworkPolicies da subnet está desabilitada, fazendo com que NSGs não sejam aplicados ao tráfego dos private endpoints
C) Os logs do NSG têm latência de até 30 minutos, e os hits das regras de negação ainda não apareceram no workspace do Log Analytics
D) O NSG foi associado à subnet, mas as regras foram criadas com prioridade acima de 65000, colidindo com as regras padrão do Azure

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

Uma VM em produção começa a falhar ao conectar-se a uma conta de armazenamento via private endpoint após uma mudança de rede realizada pela equipe de plataforma. O sintoma é: timeout na porta 443 ao tentar acessar https://storaccprod.blob.core.windows.net.

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

  1. Verificar se a zona DNS privada privatelink.blob.core.windows.net retorna o IP privado correto para o FQDN da storage account ao consultar a partir da VNet da VM
  2. Confirmar se o IP retornado pelo DNS corresponde ao IP privado configurado na NIC do private endpoint no portal do Azure
  3. Executar nslookup storaccprod.blob.core.windows.net a partir da VM afetada para verificar qual endereço IP está sendo resolvido
  4. Tentar conexão direta via curl https://[IP_PRIVADO]:443 para isolar se o problema é de DNS ou de conectividade de rede
  5. Verificar se houve alteração recente na associação de VNets à zona DNS privada ou na configuração do servidor DNS customizado da VNet

Qual é a sequência correta de investigação?

A) 3 → 4 → 1 → 2 → 5
B) 1 → 3 → 2 → 4 → 5
C) 3 → 1 → 5 → 2 → 4
D) 5 → 3 → 1 → 2 → 4

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: C

A pista decisiva está nos dois testes realizados pela equipe: o acesso pelo FQDN falha com "could not resolve host", mas o acesso pelo IP privado direto funciona perfeitamente, incluindo validação do certificado SSL. Isso elimina qualquer hipótese de problema de roteamento ou NSG, porque o IP privado 10.1.2.5 é alcançável. O problema é exclusivamente de resolução DNS.

O raciocínio correto começa por entender a cadeia de resolução: a VM na spoke consulta 10.1.0.4 (DNS customizado no hub), que faz forward para 168.63.129.16 (Azure DNS). O Azure DNS só retorna o registro privado da zona privatelink.vaultcore.azure.net se a VNet a partir da qual ele é consultado estiver vinculada à zona privada. O forward chega ao Azure DNS no contexto da hub-vnet, e a zona está vinculada ao hub, então o hub resolve corretamente. Mas a spoke não está vinculada, e o forward parte do hub. Isso pode parecer suficiente, mas a vinculação à spoke-vnet-prod também é necessária para que VMs nessa VNet obtenham resolução privada diretamente, especialmente em cenários onde o forwarding não é configurado de forma completa.

A alternativa A é o distrator mais perigoso: a equipe poderia desperdiçar tempo investigando rotas quando o próprio teste com IP já prova que o roteamento funciona. A alternativa B é factualmente errada porque a zona está vinculada ao hub. A alternativa D não tem suporte nos dados coletados; a consulta DNS falha com "could not resolve", não com timeout de conexão.

O risco de agir com base no distrator A seria abrir um chamado de rede desnecessário, atrasando a resolução real em horas.

Gabarito — Cenário 2​

Resposta: B

A causa já está identificada no enunciado: ausência de registro DNS. A zona privada correta já existe e está vinculada à VNet. O private endpoint está funcional e recebendo tráfego (via IP hardcoded). A restrição crítica é que a equipe não tem permissão para recriar ou excluir o endpoint em produção.

Criar manualmente um registro A na zona DNS privada existente é a ação correta, tecnicamente válida e que não requer nenhuma modificação no private endpoint. Essa ação pode ser executada imediatamente, sem janela de manutenção, pois não causa interrupção e remove a dependência do IP hardcoded nas aplicações.

A alternativa A viola explicitamente a restrição de permissões declarada no cenário. A alternativa C aguarda a janela e recria o endpoint via ARM template, o que também exigiria permissão de exclusão do endpoint existente. A alternativa D cria um segundo endpoint, o que novamente requer permissão de criação de endpoints em produção e introduz complexidade desnecessária quando o endpoint existente já funciona.

O distrator mais perigoso é A: parece a "solução limpa" e correta tecnicamente, mas ignora a restrição de permissões declarada, o que em produção causaria uma tentativa bloqueada e potencial incidente.

Gabarito — Cenário 3​

Resposta: B

O enunciado contém uma informação irrelevante deliberada: a suposição do engenheiro de que o NSG está com defeito ou sobrescrito por Azure Policy. Essa hipótese é plausível o suficiente para distrair, mas não tem suporte nos dados coletados. Os logs do NSG mostrando zero hits nas regras de negação não indicam defeito no NSG; indicam que o tráfego nunca chegou a ser avaliado pelas regras.

A causa real é o comportamento padrão do Azure para private endpoints: a propriedade PrivateEndpointNetworkPolicies de uma subnet é desabilitada por padrão, o que significa que NSGs e UDRs associados à subnet não são aplicados ao tráfego da NIC do private endpoint. O NSG foi associado corretamente, mas a subnet não está configurada para honrar políticas de rede para endpoints privados.

A alternativa A é o distrator mais inteligente: Azure Policy com efeito Audit não bloqueia nem interfere na avaliação de NSGs. A alternativa C é plausível como fenômeno real de Log Analytics, mas conflita com o fato de que o acesso funciona há seis meses sem logs de bloqueio. A alternativa D descreve um equívoco sobre prioridades de NSG; regras com prioridade acima de 65000 são as regras padrão invioláveis do Azure, mas isso não explica a ausência total de avaliação.

Agir com base no distrator A levaria a uma investigação longa e infrutífera de Azure Policy, enquanto o problema real é resolvido com uma única alteração na propriedade da subnet.

Gabarito — Cenário 4​

Resposta: A

A sequência correta é: 3 → 4 → 1 → 2 → 5

O raciocínio diagnóstico correto parte sempre do sintoma mais próximo do usuário e avança em direção à causa, descartando camadas progressivamente:

  • Passo 3 (nslookup): determina imediatamente se o problema é de DNS ou de conectividade. Se o IP retornado for público, o problema é DNS. Se for privado e o timeout persistir, o problema é de rede.
  • Passo 4 (curl pelo IP): isola a camada de rede. Se o IP privado responder, confirma que a rede está funcionando e o problema é exclusivamente de resolução.
  • Passo 1: investiga a zona DNS privada para entender o que deveria ser retornado.
  • Passo 2: compara o registro da zona com o IP real da NIC do private endpoint, verificando consistência.
  • Passo 5: investiga a mudança recente como causa raiz da divergência encontrada.

A alternativa B começa investigando a zona DNS antes de sequer saber se o problema é de DNS, o que é ineficiente. A alternativa C mistura validações de causa raiz (passo 5) antes de confirmar o sintoma. A alternativa D começa pela mudança recente (passo 5), que é uma hipótese, não um dado observado; iniciar por hipótese em vez de sintoma é o erro diagnóstico mais comum e mais custoso em ambientes de produção.

Árvore de Troubleshooting: Plan private endpoints​

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

Legenda de cores:

CorTipo de nó
Azul escuroSintoma inicial (ponto de entrada)
AzulPergunta diagnóstica
VermelhoCausa identificada
VerdeAção recomendada ou resolução
LaranjaValidação ou verificação intermediária

Diante de uma falha real, comece sempre pelo nó raiz em azul escuro e responda cada pergunta diagnóstica com base no que foi observado ou medido, nunca com base em suposição. A primeira bifurcação separa problemas de DNS de problemas de conectividade de rede, o que elimina metade das hipóteses com um único comando nslookup. A partir daí, cada nó de pergunta reduz progressivamente o espaço de causas possíveis até chegar ao nó vermelho correspondente e, em seguida, à ação verde que resolve o problema. Os nós laranja indicam que a ação foi aplicada e que o resultado deve ser verificado antes de encerrar o diagnóstico.