Laboratório de Troubleshooting: Create a Private Link service
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de plataforma de uma empresa expôs um serviço interno via Private Link service associado a um Standard Load Balancer interno. O time consumidor criou um Private Endpoint na VNet deles, a conexão foi aprovada pelo provedor e o status exibe Approved. No entanto, ao tentar conectar à aplicação a partir de uma VM consumidora, todas as tentativas falham com timeout.
O engenheiro responsável coletou as seguintes informações:
# Teste de conectividade a partir da VM consumidora
Test-NetConnection -ComputerName 10.100.5.4 -Port 443
TcpTestSucceeded : False
PingSucceeded : False
# Status do Private Endpoint (portal / CLI)
ProvisioningState : Succeeded
ConnectionState : Approved
# NSG aplicado à subnet do Private Endpoint (consumidor)
Rule: AllowVnetInBound -- Allow -- Any -- Any
Rule: DenyAllInbound -- Deny -- Any -- Any
# NSG aplicado à subnet de NAT do provedor
Rule: AllowAzureLoadBalancerInBound -- Allow
Rule: DenyAllInBound -- Deny -- Any -- Any
Rule: AllowVnetInBound -- Allow -- Any -- Any
O Load Balancer do provedor está saudável, os backends respondem na porta 443 e o certificado TLS está válido. A subnet do Private Endpoint tem apenas um endpoint provisionado, sem outros recursos.
Qual é a causa raiz da falha de conectividade?
A) O status Approved é exibido antes que a propagação de DNS esteja completa, e o timeout ocorre porque o IP do Private Endpoint ainda não foi resolvido corretamente.
B) O NSG aplicado à subnet de NAT do provedor está bloqueando o tráfego de retorno, pois a política de rede do Private Link service requer que o NSG da subnet de NAT esteja desabilitado ou que regras explícitas permitam o tráfego originado dos IPs de NAT.
C) O NSG aplicado à subnet do Private Endpoint do consumidor está bloqueando o tráfego de saída da VM em direção ao endpoint, pois não existe regra de saída explícita permitindo a porta 443.
D) A Private Link Network Policy está habilitada na subnet de NAT do provedor, o que impede a alocação de IPs de NAT e causa timeout nas conexões.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o Private Link service de um ambiente de produção foi configurado com visibilidade Public, permitindo que qualquer subscription da organização descubra o alias e crie Private Endpoints. O time de segurança detectou três conexões pendentes originadas de subscriptions desconhecidas e não autorizadas.
O serviço está em produção e atende conexões legítimas de dois consumidores aprovados. Qualquer interrupção deve ser evitada. O engenheiro tem permissão de escrita no recurso do Private Link service e precisa agir imediatamente.
Qual é a ação correta a tomar neste momento?
A) Recriar o Private Link service com visibilidade Restricted, listando apenas as subscriptions autorizadas, e recriar os Private Endpoints dos consumidores legítimos apontando para o novo serviço.
B) Rejeitar as três conexões pendentes não autorizadas e, em seguida, alterar a visibilidade do Private Link service para Restricted, adicionando apenas as subscriptions legítimas, sem interromper as conexões já aprovadas.
C) Deletar imediatamente o Private Link service e recriar com a configuração correta, pois a visibilidade não pode ser alterada em um serviço existente.
D) Manter a visibilidade como Public e adicionar um NSG na subnet de NAT bloqueando os IPs das subscriptions não autorizadas, usando as conexões pendentes como referência.
Cenário 3 — Causa Raiz
Um provedor configurou um Private Link service com aprovação automática habilitada para a subscription do consumidor. O consumidor criou um Private Endpoint e recebeu o status Approved imediatamente. Mesmo assim, a aplicação retorna erro de conexão recusada na porta 8080.
# Saída do comando no consumidor
curl -v http://10.100.7.10:8080/health
* Trying 10.100.7.10:8080...
* connect to 10.100.7.10 port 8080 failed: Connection refused
* Failed to connect to 10.100.7.10 port 8080
# Configuração do Private Link service (resumida)
Frontend IP Configuration: 10.0.2.20 (Standard Internal LB)
Load Balancer: lb-producao-001
NAT Subnet: pls-nat-subnet (10.0.3.0/28)
Private Link Network Policy: Disabled
# Load Balancer lb-producao-001 -- Regras de balanceamento
| Nome | Frontend IP | Porta Frontend | Porta Backend | Protocolo |
|---------------|--------------|----------------|---------------|-----------|
| rule-https | 10.0.2.20 | 443 | 443 | TCP |
| rule-http | 10.0.2.20 | 80 | 80 | TCP |
O time de plataforma informa que o certificado do serviço foi renovado há dois dias e que a subnet de NAT tem 12 IPs disponíveis.
Qual é a causa raiz do erro observado?
A) A renovação do certificado há dois dias causou um reset nas conexões ativas do Private Link service, e novas tentativas falham até que o serviço seja reiniciado.
B) O Private Link service está associado ao IP de frontend correto do Load Balancer, mas não existe regra de balanceamento configurada para a porta 8080, fazendo com que o tráfego chegue ao Load Balancer e seja descartado por ausência de regra correspondente.
C) A subnet de NAT com prefixo /28 é insuficiente para o volume de conexões simultâneas, e o esgotamento de IPs de NAT causa recusa de novas conexões.
D) A Private Link Network Policy está desabilitada na subnet de NAT, o que impede que o tráfego na porta 8080 seja encaminhado corretamente ao backend.
Cenário 4 — Sequência de Diagnóstico
Um consumidor relata que o Private Endpoint criado para um serviço do provedor está com status Disconnected. O provedor confirma que o Private Link service existe e está operacional para outros consumidores. Nenhuma alteração recente foi declarada por nenhum dos lados.
Os passos de investigação abaixo estão fora de ordem:
- Verificar se o Private Link service do provedor ainda existe e está no estado Succeeded
- Confirmar se o consumidor está utilizando o Resource ID ou alias correto na configuração do Private Endpoint
- Verificar o histórico de atividades do Private Endpoint para identificar se houve alguma operação de delete ou recriação recente
- Confirmar se a conexão no lado do provedor foi rejeitada, removida ou se nunca chegou a ser aprovada
- Verificar se o DNS privado do consumidor está resolvendo o FQDN do endpoint para o IP correto
Qual sequência representa o raciocínio diagnóstico correto, do mais abrangente ao mais específico?
A) 2 → 1 → 4 → 3 → 5
B) 1 → 4 → 3 → 2 → 5
C) 5 → 2 → 1 → 4 → 3
D) 3 → 1 → 4 → 2 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: D
A pista decisiva está no bloco de configuração: Private Link Network Policy não aparece como desabilitada na subnet de NAT do provedor. Para que o Private Link service funcione corretamente, essa política deve estar desabilitada na subnet designada como NAT subnet. Quando está habilitada, o Azure não consegue alocar os IPs de NAT necessários para realizar o SNAT das conexões dos consumidores, resultando em timeout mesmo com o status da conexão como Approved.
O status Approved reflete apenas o plano de controle (a conexão foi aceita administrativamente), não o plano de dados. Isso elimina qualquer hipótese baseada em aprovação ou DNS como causa.
A alternativa C é o distrator mais perigoso: o NSG do lado do consumidor parece suspeito à primeira vista, mas as regras mostradas se aplicam ao tráfego de entrada na subnet, não ao tráfego de saída da VM. O tráfego originado pela VM consumidora em direção ao Private Endpoint é tráfego de saída e não seria bloqueado pelas regras listadas. Agir sobre o NSG do consumidor consumiria tempo sem resolver o problema real.
A informação sobre o certificado TLS válido e os backends saudáveis é propositalmente irrelevante: como o tráfego nunca chega ao backend (falha no plano de dados do Private Link), o estado do TLS não tem influência no sintoma.
Gabarito — Cenário 2
Resposta: B
O cenário impõe duas restrições simultâneas: não interromper conexões legítimas ativas e agir imediatamente. A alternativa B é a única que satisfaz ambas. A visibilidade e a lista de aprovação automática de um Private Link service podem ser editadas in-place sem recriar o recurso ou impactar conexões já aprovadas. Rejeitar as pendentes e restringir a visibilidade são operações no plano de controle que não afetam o tráfego em andamento.
A alternativa A é tecnicamente válida como solução de longo prazo, mas recria o serviço e exige que os consumidores legítimos recriem seus Private Endpoints, gerando uma janela de indisponibilidade. Isso viola a restrição de não interrupção.
A alternativa C é factualmente incorreta: a visibilidade é um atributo editável do serviço existente.
A alternativa D é o distrator mais perigoso porque parece resolver o problema sem recriação, mas NSGs na subnet de NAT controlam o plano de dados, não a visibilidade do serviço. As subscriptions não autorizadas continuariam podendo descobrir o alias e submeter novas conexões pendentes indefinidamente.
Gabarito — Cenário 3
Resposta: B
A causa está explícita nos dados fornecidos, mas requer que o leitor cruze as informações: o erro é Connection refused na porta 8080, e a tabela de regras do Load Balancer mostra apenas regras para as portas 443 e 80. O Private Link service encaminha o tráfego ao frontend do Load Balancer exatamente como recebido; se o Load Balancer não tem regra para a porta solicitada, ele descarta o pacote e a conexão é recusada.
A renovação do certificado há dois dias é a informação irrelevante incluída propositalmente. Renovação de certificado não afeta o plano de dados do Load Balancer nem do Private Link service, e o sintoma (connection refused) é estruturalmente diferente de um erro TLS.
A alternativa C sobre esgotamento de IPs de NAT seria plausível em cenários de timeout, não de connection refused. Uma subnet /28 fornece 11 IPs utilizáveis para NAT, suficiente para a maioria dos cenários. Além disso, o enunciado informa explicitamente que há 12 IPs disponíveis, dado que deveria eliminar essa hipótese.
A alternativa D inverte a lógica correta: desabilitar a Private Link Network Policy é o estado necessário para o funcionamento do serviço, não uma causa de falha.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 1 → 4 → 3 → 2 → 5, seguindo a lógica de eliminar hipóteses da mais abrangente para a mais específica:
- Passo 1: confirmar que o Private Link service do provedor ainda existe é o primeiro filtro. Se o serviço foi deletado, todos os Private Endpoints apontando para ele ficam com status Disconnected independentemente de qualquer outra configuração.
- Passo 4: se o serviço existe, verificar o estado da conexão no lado do provedor determina se houve rejeição explícita ou remoção da aprovação.
- Passo 3: o histórico de atividades do Private Endpoint revela se o recurso foi recriado ou sofreu alguma operação que rompeu o vínculo com o serviço.
- Passo 2: só faz sentido verificar o Resource ID ou alias após confirmar que o serviço existe e que não há operação recente que explique o problema.
- Passo 5: a resolução DNS é validada por último, pois status Disconnected indica que o problema está no plano de controle, não na resolução de nomes. A resolução de DNS só se torna relevante após confirmar que o plano de controle está íntegro.
A sequência C (5 → ...) é o distrator mais comum: começa pela resolução de DNS, que é um sintoma de segundo nível e não a causa de um status Disconnected. Iniciar pelo DNS levaria o engenheiro ao caminho errado antes de verificar se o serviço ainda existe.
Árvore de Troubleshooting: Create a Private Link service
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou de estado) |
| 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 descrevendo o sintoma de conectividade. Siga cada pergunta respondendo com base no que você observa, não no que você suspeita. Cada bifurcação elimina uma classe inteira de causas. Ao atingir um nó vermelho de causa identificada, a ação correspondente em verde é o próximo passo operacional. Se o nó de validação laranja confirmar que o tráfego está fluindo mas a aplicação ainda falha, o caminho continua pela resolução DNS, garantindo que o diagnóstico cubra tanto o plano de controle quanto o plano de dados.