Laboratório de Troubleshooting: Integrate a Private Link service with on-premises clients
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma empresa conecta seu ambiente on-premises ao Azure via ExpressRoute com peering privado. Um Private Endpoint foi criado na VNet vnet-prod (prefixo 10.2.8.0/24) para expor um Azure SQL Database. A zona de DNS privado privatelink.database.windows.net foi criada e vinculada à vnet-prod. Um Azure DNS Private Resolver foi implantado na mesma VNet com um Inbound Endpoint no IP 10.2.8.100, e os servidores DNS on-premises foram configurados para encaminhar consultas ao domínio database.windows.net para esse IP.
A equipe relata que consultas DNS realizadas a partir de servidores on-premises retornam o IP correto do Private Endpoint (10.2.8.50). No entanto, conexões TCP na porta 1433 para esse IP falham com timeout.
Informações adicionais coletadas pela equipe:
# Teste executado a partir de servidor on-premises
Test-NetConnection -ComputerName 10.2.8.50 -Port 1433
ComputerName : 10.2.8.50
RemoteAddress : 10.2.8.50
RemotePort : 1433
InterfaceAlias : Ethernet0
SourceAddress : 192.168.10.25
PingSucceeded : False
TcpTestSucceeded : False
# Rota verificada no gateway on-premises
Network Gateway Interface
10.2.0.0/16 via ExpressRoute GW-ER
A MTU configurada nos links ExpressRoute está em 1500 bytes. O circuito ExpressRoute apresenta largura de banda utilizada abaixo de 20%.
Qual é a causa raiz da falha de conectividade?
A) O DNS Private Resolver não suporta encaminhamento de consultas para zonas privatelink; é necessário usar um servidor DNS customizado em VM.
B) A rota 10.2.0.0/16 cobre o prefixo do Private Endpoint, mas o NSG associado à subnet do Private Endpoint está bloqueando o tráfego de origem 192.168.10.0/24 na porta 1433, e as políticas de rede do endpoint estão habilitadas na subnet.
C) O circuito ExpressRoute não anuncia o prefixo 10.2.8.0/24 para o ambiente on-premises porque esse prefixo não está sendo propagado pelo gateway de VNet.
D) O Private Endpoint foi criado sem aprovação manual da conexão pelo provedor do serviço, e por isso o estado da conexão é Pending, não Approved.
Cenário 2 — Decisão de Ação
A equipe de rede identificou que clientes on-premises não conseguem acessar um Private Endpoint porque a política de rede do Private Endpoint (PrivateEndpointNetworkPolicies) está habilitada na subnet e um NSG está bloqueando o tráfego originado do prefixo on-premises. A causa foi confirmada via análise dos logs de fluxo do NSG.
O ambiente é de produção, com SLA ativo e janela de manutenção somente aos sábados. O acesso ao Private Endpoint é necessário apenas para uma aplicação batch que roda às 3h da manhã on-premises. Hoje é quinta-feira. A equipe tem permissão para modificar NSGs e políticas de subnet sem aprovação adicional.
Qual é a ação correta a tomar neste momento?
A) Desabilitar imediatamente PrivateEndpointNetworkPolicies na subnet para remover a restrição de NSG e restaurar o acesso sem impacto a outros recursos.
B) Adicionar uma regra de permissão no NSG para o prefixo on-premises na porta correta, aplicando a mudança agora, pois adicionar uma regra de permissão não causa interrupção em conexões existentes.
C) Aguardar a janela de manutenção do sábado para desabilitar PrivateEndpointNetworkPolicies e ajustar o NSG simultaneamente, evitando qualquer mudança em produção fora da janela.
D) Recriar o Private Endpoint em uma subnet sem NSG associado, redirecionando o tráfego imediatamente.
Cenário 3 — Causa Raiz
Uma equipe configurou um Private Link Service para expor uma aplicação interna hospedada atrás de um Standard Internal Load Balancer. O serviço foi publicado e um consumidor em outra subscription criou um Private Endpoint apontando para esse serviço. O status da conexão no lado do provedor aparece como Pending.
O engenheiro do provedor verifica o portal e observa:
Private Link Service: pls-app-prod
Alias: pls-app-prod.abc12345.brazilsouth.azure.privatelinkservice
Conexoes de Private Endpoint:
Nome: pe-consumer-001
Estado: Pending
Descricao: Aguardando aprovacao
Subscription consumidora: sub-parceiro-01
O engenheiro informa que a subscription sub-parceiro-01 estava na lista de aprovação automática quando o serviço foi configurado. Ele também confirma que o Load Balancer está saudável, que os backends respondem normalmente e que a subnet do Private Link Service tem PrivateLinkServiceNetworkPolicies desabilitado.
Qual é a causa raiz do estado Pending da conexão?
A) A subnet do Private Link Service está com PrivateLinkServiceNetworkPolicies habilitado, impedindo que conexões externas sejam aprovadas automaticamente.
B) O alias do Private Link Service foi usado pelo consumidor em vez do Resource ID completo, e conexões via alias sempre requerem aprovação manual, independentemente da lista de aprovação automática.
C) A subscription sub-parceiro-01 não está incluída corretamente na lista de aprovação automática do Private Link Service, seja por erro de digitação no ID ou por ausência do registro.
D) O Private Endpoint foi criado em uma região diferente da região do Private Link Service, e conexões inter-regionais exigem aprovação manual obrigatória.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: clientes on-premises conectados via VPN site-to-site tentam acessar um serviço exposto por um Private Endpoint na VNet do Azure, mas as conexões falham com timeout. O DNS resolve corretamente o IP privado do endpoint.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se o prefixo da subnet do Private Endpoint está sendo anunciado pelo gateway de VPN para o ambiente on-premises via BGP ou rota estática.
- Confirmar que o IP retornado pelo DNS on-premises corresponde ao IP privado do Private Endpoint e não ao IP público do serviço.
- Verificar se há NSG na subnet do Private Endpoint com
PrivateEndpointNetworkPolicieshabilitado que bloqueie o prefixo de origem on-premises. - Testar conectividade TCP da porta do serviço a partir de uma VM dentro da própria VNet do Azure para o IP do Private Endpoint.
- Revisar os logs de fluxo do NSG para identificar se o tráfego chega à subnet e é descartado, ou se não chega à subnet.
Qual é a sequência correta de investigação?
A) 2 → 1 → 4 → 5 → 3
B) 1 → 2 → 3 → 4 → 5
C) 4 → 2 → 1 → 3 → 5
D) 2 → 4 → 1 → 5 → 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na combinação de dois dados: o DNS resolve corretamente (descartando problema de DNS), o PingSucceeded é False (descartando problema de roteamento no nível ICMP) e a rota 10.2.0.0/16 cobre o destino (descartando ausência de rota). O único caminho que explica timeout em TCP enquanto o roteamento está aparentemente correto é um NSG bloqueando o tráfego. Para que o NSG atue sobre o IP do Private Endpoint, as PrivateEndpointNetworkPolicies precisam estar habilitadas, o que é o pré-requisito para que NSGs sejam aplicados ao endpoint.
A informação sobre MTU e utilização do circuito é propositalmente irrelevante: o tráfego nem chega ao endpoint para que MTU importe. A alternativa C é descartável porque a rota 10.2.0.0/16 cobre 10.2.8.0/24 e o ping falhou, indicando bloqueio e não ausência de rota. A alternativa D seria visível no estado da conexão do Private Endpoint, não resultaria em timeout TCP de rede. A alternativa A é factualmente incorreta: o DNS Private Resolver suporta zonas privatelink.
O distrator mais perigoso é C, pois o engenheiro poderia gastar horas investigando o circuito ExpressRoute enquanto o problema real está em um NSG local à subnet.
Gabarito — Cenário 2
Resposta: B
A causa já foi identificada e confirmada: o NSG está bloqueando com a política habilitada. A restrição do cenário é o SLA de produção ativo e a janela de manutenção. A ação correta é adicionar uma regra de permissão ao NSG agora, pois adicionar uma regra de Allow em um NSG não interrompe conexões existentes. É uma operação não destrutiva que resolve o problema imediatamente, dentro das permissões disponíveis.
A alternativa A (desabilitar PrivateEndpointNetworkPolicies) seria uma mudança de maior escopo: removeria a capacidade de aplicar NSGs e UDRs a todos os Private Endpoints da subnet, afetando potencialmente outros endpoints e controles de segurança. Em produção, essa mudança tem impacto colateral e deveria ser avaliada com cuidado. A alternativa C ignora o fato de que a aplicação batch falha toda noite até o sábado, o que é inaceitável. A alternativa D recria o endpoint, o que causa downtime completo do serviço durante a recriação.
Gabarito — Cenário 3
Resposta: C
O enunciado afirma que a subscription estava na lista de aprovação automática "quando o serviço foi configurado". Isso não garante que o ID da subscription está correto hoje. A causa mais precisa é que a subscription sub-parceiro-01 não consta efetivamente na lista de aprovação automática do Private Link Service com o ID correto. Isso pode ocorrer por erro de digitação no GUID da subscription, por remoção inadvertida da lista, ou por uso de um alias de subscription ao invés do ID.
A alternativa A é descartada pelo próprio enunciado, que confirma que PrivateLinkServiceNetworkPolicies está desabilitado. A alternativa B é factualmente incorreta: conexões via alias também podem ser aprovadas automaticamente se a subscription estiver na lista. A alternativa D é incorreta: Private Link suporta conectividade inter-regional e não exige aprovação manual por esse motivo.
A informação sobre saúde do Load Balancer e backends é irrelevante para o estado Pending, que é um mecanismo de controle de acesso no plano de gerenciamento, não de conectividade de dados.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 2 → 1 → 4 → 5 → 3.
O raciocínio diagnóstico progressivo parte do que já foi parcialmente confirmado (DNS resolve) e avança em camadas:
O passo 2 confirma que o IP retornado é de fato o privado e não o público, validando o ponto de partida. O passo 1 verifica se o prefixo do endpoint está sendo anunciado ao on-premises, pois sem rota o tráfego nunca sai do cliente. O passo 4 isola se o problema é na rede entre on-premises e Azure ou no próprio endpoint, testando de dentro da VNet. Se funciona de dentro, o problema está no caminho on-premises. O passo 5 usa os logs de fluxo para determinar se o tráfego chega à subnet ou é descartado antes, distinguindo problema de roteamento de problema de NSG. O passo 3 é o mais específico e só faz sentido após confirmar que o tráfego de fato chega à subnet (confirmado pelo passo 5).
A alternativa B começa com verificação de roteamento antes de confirmar o estado do DNS, perdendo a referência de que o DNS já foi parcialmente validado no enunciado. A alternativa C inverte a lógica ao testar de dentro da VNet antes de validar se o roteamento on-premises existe, desperdiçando o passo mais rápido de eliminação.
Árvore de Troubleshooting: Integrate a Private Link service with on-premises clients
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta diagnóstica com base no que é observável no ambiente, sem assumir causas. Cada ramificação elimina uma hipótese e direciona para a próxima verificação. Quando atingir um nó vermelho (causa identificada), execute a ação correspondente no nó verde ligado a ele. Nos nós de validação (laranja), o resultado do teste determina qual caminho seguir, impedindo que uma suposição incorreta consuma tempo de diagnóstico.