Pular para o conteúdo principal

Laboratório de Troubleshooting: Create private endpoints

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Uma equipe de operações reporta que uma aplicação hospedada na subnet snet-app (10.1.0.0/24) não consegue se conectar a um Azure SQL Database via private endpoint. O time informa que o ambiente foi provisionado há duas semanas e funcionava normalmente até ontem.

O administrador executa os seguintes comandos a partir de uma VM na subnet snet-app:

# Teste de resolução DNS
nslookup sqlprod.database.windows.net
Server:  168.63.129.16
Address: 168.63.129.16

Non-authoritative answer:
Name:    sqlprod.privatelink.database.windows.net
Address: 13.91.44.120

# Teste de conectividade TCP
Test-NetConnection -ComputerName sqlprod.database.windows.net -Port 1433
ComputerName     : sqlprod.database.windows.net
RemoteAddress    : 13.91.44.120
RemotePort       : 1433
InterfaceAlias   : Ethernet
SourceAddress    : 10.1.0.5
TcpTestSucceeded : False

O administrador confirma que o private endpoint pe-sqlprod existe, está com status Succeeded e possui o IP privado 10.2.1.8 alocado na subnet snet-data. A conta do SQL Database tem o firewall habilitado e acesso público negado. O Network Security Group da subnet snet-app permite saída para qualquer destino na porta 1433.

Qual é a causa raiz da falha de conectividade?

A) O NSG da subnet snet-app está bloqueando o tráfego de saída para a subnet snet-data.

B) A Private DNS Zone privatelink.database.windows.net não está vinculada à rede virtual que contém a subnet snet-app, fazendo com que o DNS resolva para o IP público do serviço.

C) O firewall do SQL Database está bloqueando conexões originadas do IP 10.1.0.5.

D) O private endpoint foi provisionado em uma subnet diferente da aplicação, o que impede a conectividade entre as duas subnets.

Cenário 2 — Causa Raiz​

Uma empresa provisionou um Azure Private Link Service para expor um serviço interno a parceiros externos. O serviço está atrás de um Standard Load Balancer interno na subnet snet-provider (10.0.1.0/24). Os parceiros criaram private endpoints em suas redes virtuais e os administradores confirmam que o status da conexão está como Approved no portal do Azure.

Apesar disso, o parceiro A reporta que as requisições HTTP enviadas ao IP privado do endpoint (192.168.10.4) retornam timeout após 30 segundos. O parceiro B, em outra assinatura, relata o mesmo comportamento. O time do provedor verifica que o Load Balancer interno apresenta as backends como healthy no health probe.

O administrador do provedor consulta a configuração da subnet e obtém a seguinte saída:

{
  "name": "snet-provider",
  "addressPrefix": "10.0.1.0/24",
  "privateLinkServiceNetworkPolicies": "Enabled",
  "privateEndpointNetworkPolicies": "Disabled",
  "networkSecurityGroup": null
}

O time de rede informa que a subnet snet-provider foi criada há três meses e que nenhuma configuração foi alterada desde a criação do Private Link Service.

Qual é a causa raiz do comportamento observado?

A) A ausência de um Network Security Group na subnet snet-provider impede que o Private Link Service encaminhe o tráfego dos parceiros.

B) O status Approved da conexão indica apenas aprovação administrativa; o tráfego só flui após a confirmação manual no portal do parceiro.

C) A propriedade privateLinkServiceNetworkPolicies está habilitada na subnet do provedor, o que bloqueia o funcionamento correto do Private Link Service.

D) Os dois parceiros estão em assinaturas diferentes, e o Private Link Service exige peering entre as assinaturas para encaminhar o tráfego.

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

A causa foi identificada: a Private DNS Zone privatelink.blob.core.windows.net está vinculada apenas à rede virtual vnet-hub, mas a aplicação que precisa do acesso privado está em vnet-spoke-prod. As duas redes virtuais possuem peering configurado e funcional. O ambiente está em produção com alta disponibilidade e o impacto atual é que uploads de arquivos estão falhando silenciosamente, pois a aplicação tenta o IP público mas o firewall do Storage rejeita a conexão.

O arquiteto responsável tem permissão para modificar configurações de DNS e rede virtual, mas não pode reiniciar a aplicação nem fazer alterações que exijam janela de manutenção. A equipe de segurança exige que qualquer mudança seja reversível em menos de cinco minutos caso cause impacto adicional.

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

A) Criar uma nova Private DNS Zone privatelink.blob.core.windows.net exclusiva para vnet-spoke-prod e migrar os registros A existentes para a nova zona.

B) Adicionar um Virtual Network Link da Private DNS Zone existente privatelink.blob.core.windows.net para a rede virtual vnet-spoke-prod.

C) Configurar um servidor DNS customizado em vnet-spoke-prod com um forwarder apontando para o IP 168.63.129.16 e reiniciar o serviço DNS das VMs da spoke.

D) Habilitar o atributo DNS proxy no Azure Firewall de vnet-hub e criar uma regra de DNS para encaminhar consultas de vnet-spoke-prod para a zona privada.

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

Um administrador recebe o seguinte alerta às 14h32:

"Aplicação de relatórios não consegue ler dados do Azure Storage Account stprodreports. Erro reportado: timeout na conexão."

O ambiente possui um private endpoint pe-storage-reports configurado para o sub-recurso blob. A aplicação roda em VMs na subnet snet-reports (10.3.0.0/24). Recentemente, foi habilitado o acesso público ao Storage para uma auditoria externa, e o time de segurança solicitou a desabilitação imediatamente após o fim da auditoria.

Os passos de investigação disponíveis são:

  1. Verificar se o private endpoint pe-storage-reports está com status Succeeded e se o IP privado está alocado.
  2. Executar nslookup stprodreports.blob.core.windows.net a partir de uma VM em snet-reports para verificar qual IP está sendo resolvido.
  3. Verificar se o firewall do Storage Account está configurado para negar acesso público e se redes virtuais selecionadas ou endpoints privados estão liberados.
  4. Consultar os logs do NSG associado à subnet snet-reports para verificar se há bloqueio de tráfego de saída na porta 443.
  5. Confirmar se a Private DNS Zone privatelink.blob.core.windows.net possui um registro A apontando para o IP privado do endpoint.

Qual é a sequência correta de diagnóstico progressivo para este cenário?

A) 1 → 3 → 2 → 5 → 4

B) 2 → 5 → 1 → 3 → 4

C) 3 → 1 → 4 → 2 → 5

D) 4 → 2 → 1 → 5 → 3

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: B

Explique:

  • A saída do nslookup é a pista decisiva: o DNS está retornando o IP 13.91.44.120, que é um endereço público. Isso significa que a resolução de nomes não está sendo interceptada pela Private DNS Zone e encaminhada para o IP privado 10.2.1.8. O sintoma de "funcionava e parou" pode ter ocorrido por uma desvinculação acidental da zona DNS ou por uma alteração no servidor DNS configurado na VNet.
  • A informação irrelevante neste cenário é o fato de o NSG de snet-app permitir saída na porta 1433. Esse dado é verdadeiro e correto, mas não é a causa do problema, pois o tráfego sequer chega à camada de rede na direção correta: o DNS já encaminhou a conexão para o IP público.
  • A alternativa A é um distrator clássico: o administrador vê "falha de conexão" e imediatamente suspeita do NSG, sem verificar primeiro para onde o tráfego está sendo direcionado. A alternativa D representa um equívoco conceitual: private endpoints podem residir em qualquer subnet da mesma VNet ou de VNets emparelhadas; a subnet do endpoint não precisa ser a mesma da aplicação. O distrator mais perigoso é o C: agir no firewall do SQL sem verificar a causa real atrasaria a resolução e poderia expor o ambiente a reconfigurações desnecessárias.

Gabarito — Cenário 2​

Resposta: C

Explique:

  • A propriedade privateLinkServiceNetworkPolicies controla se as políticas de rede (rotas de sistema e NSGs) são aplicadas ao tráfego direcionado ao Private Link Service dentro da subnet. Quando essa propriedade está como Enabled, o Azure aplica políticas que interferem no roteamento interno do Private Link Service, impedindo que o tráfego dos consumidores alcance o Load Balancer corretamente. Para que o Private Link Service funcione, essa propriedade deve estar configurada como Disabled na subnet do provedor.
  • A informação irrelevante é o fato de que "nenhuma configuração foi alterada desde a criação". Essa afirmação pode levar o leitor a descartar configurações do ambiente como causa, mas o problema está exatamente em como a subnet foi criada originalmente, com a propriedade incorreta desde o início.
  • A alternativa A é descartável pelo enunciado: a ausência de NSG não impede o funcionamento do Private Link Service. A alternativa B representa um equívoco sobre o fluxo de aprovação: status Approved significa que a conexão de rede está estabelecida e o tráfego pode fluir, não que seja necessária uma confirmação adicional. A alternativa D é conceitualmente errada: o Private Link Service foi criado exatamente para permitir consumo entre assinaturas distintas sem peering.

Gabarito — Cenário 3​

Resposta: B

Explique:

  • Adicionar um Virtual Network Link à Private DNS Zone existente é a ação correta porque resolve o problema diretamente na sua causa: a zona não está vinculada a vnet-spoke-prod. Essa operação é não destrutiva, não requer reinicialização de recursos, leva menos de um minuto para propagar e é totalmente reversível com a simples remoção do link, atendendo a todas as restrições declaradas.
  • A alternativa A é tecnicamente possível, mas incorreta neste contexto: criar uma segunda zona com o mesmo nome causaria conflito de resolução e poderia gerar comportamento imprevisível. Além disso, migrar registros A é uma operação desnecessariamente complexa para uma correção que se resolve com um link.
  • A alternativa C introduz uma dependência operacional que viola a restrição de não reiniciar serviços: configurar DNS customizado normalmente exige que as VMs renovem configurações de rede ou reiniciem o cliente DNS. A alternativa D é uma solução de arquitetura mais complexa que requer o Azure Firewall como proxy DNS, o que vai muito além do escopo da correção necessária e não atende ao critério de reversibilidade rápida.

Gabarito — Cenário 4​

Resposta: B

Explique:

  • A sequência correta é 2 → 5 → 1 → 3 → 4 porque segue a lógica de diagnóstico progressivo do sintoma para a causa, camada por camada.
  • O passo 2 (nslookup) deve ser o primeiro: ele determina imediatamente se o tráfego está sendo roteado para o IP privado ou para o IP público. Essa informação divide o espaço do problema em dois caminhos completamente distintos. Se o DNS retorna IP público, o problema está na resolução de nomes; se retorna IP privado, o problema está na conectividade de rede.
  • O passo 5 vem em seguida: se o DNS retornou IP privado, verifica-se se o registro A na Private DNS Zone está correto, confirmando que a zona está integrada.
  • O passo 1 valida se o próprio private endpoint está íntegro e alocado.
  • O passo 3 verifica a configuração do firewall do Storage, que é especialmente relevante dado o contexto da auditoria recente (acesso público foi habilitado e depois desabilitado, e pode ter ficado em estado inconsistente).
  • O passo 4 (logs de NSG) é o último porque o NSG raramente é a causa em cenários de private endpoint bem configurados, e sua análise é mais demorada. Iniciar por ele seria uma perda de tempo diante das causas mais prováveis.
  • A alternativa A começa pelo passo 3 (firewall), que é o distrator mais atraente dado o contexto da auditoria, mas verifica o firewall antes mesmo de saber para qual IP o tráfego está sendo enviado, o que é um erro de metodologia diagnóstica.

Árvore de Troubleshooting: Create private endpoints​

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

Legenda de cores:

CorTipo de nó
Azul escuro (navy)Sintoma inicial, ponto de entrada da investigação
Azul (blue)Pergunta diagnóstica objetiva, verificável na prática
VermelhoCausa identificada que exige correção
VerdeAção recomendada ou estado de resolução confirmada
LaranjaValidação intermediária ou verificação de estado

Para usar esta árvore diante de um problema real, comece sempre pelo nó raiz (falha de conectividade) e responda cada pergunta com base no que você observa no ambiente, sem presumir a causa. A primeira bifurcação, que verifica se o DNS resolve para IP privado, é a mais importante: ela separa imediatamente os problemas de camada DNS dos problemas de camada de rede e configuração de recurso. Siga o caminho correspondente ao que você observou até chegar a um nó de causa ou ação. Se a ação tomada não resolver o problema, retorne ao nó anterior e siga o próximo ramo possível, tratando a árvore como um checklist progressivo e não como uma sequência linear obrigatória.