Partilhar via

Diagnosticar problemas de configuração de ligações privadas no Azure Key Vault

  • Artigo

Introdução

Este artigo ajuda os usuários a diagnosticar e corrigir problemas envolvendo o Cofre de Chaves e o recurso Links Privados. Este guia ajuda em aspetos de configuração, como fazer com que os links privados funcionem pela primeira vez ou para corrigir uma situação em que os links privados pararam de funcionar devido a alguma alteração.

Se você é novo nesse recurso, consulte Integrar o Cofre da Chave com o Azure Private Link.

Problemas abrangidos por este artigo

  • Suas consultas DNS ainda retornam um endereço IP público para o cofre de chaves, em vez de um endereço IP privado que você esperaria usar o recurso de links privados.
  • Todas as solicitações feitas por um determinado cliente que está usando link privado, estão falhando com tempos limite ou erros de rede, e o problema não é intermitente.
  • O cofre de chaves tem um endereço IP privado, mas as solicitações ainda obtêm 403 resposta com o código de ForbiddenByFirewall erro interno.
  • Você está usando links privados, mas seu cofre de chaves ainda aceita solicitações da Internet pública.
  • O cofre da sua chave tem dois Pontos de Extremidade Privados. As solicitações que usam um estão funcionando bem, mas as solicitações que usam o outro estão falhando.
  • Você tem outra assinatura, cofre de chaves ou rede virtual que está usando links privados. Você deseja fazer uma nova implantação semelhante, mas não pode obter links privados para trabalhar lá.

Problemas NÃO abrangidos por este artigo

  • Há um problema intermitente de conectividade. Em um determinado cliente, você vê algumas solicitações funcionando e outras não funcionando. Problemas intermitentes normalmente não são causados por um problema na configuração de links privados; Eles são um sinal de sobrecarga de rede ou cliente.
  • Você está usando um produto do Azure que oferece suporte a BYOK (Bring Your Own Key), CMK (Customer Managed Keys) ou acesso a segredos armazenados no cofre de chaves. Quando ativa a firewall nas definições do cofre de chaves, esse produto não consegue aceder ao cofre de chaves. Consulte a documentação específica do produto. Certifique-se de que indica explicitamente o suporte para cofres de chaves com a firewall ativada. Entre em contato com o suporte para esse produto específico, se necessário.

Como ler este artigo

Se você é novo em links privados ou está avaliando uma implantação complexa, é recomendável ler o artigo inteiro. Caso contrário, sinta-se à vontade para escolher a seção que faz mais sentido para o problema que você está enfrentando.

Vamos começar!

1. Confirme que você possui a conexão do cliente

Confirme se o cliente é executado na rede virtual

Este guia destina-se a ajudá-lo a corrigir conexões com o cofre de chaves que se originam do código do aplicativo. Exemplos são aplicativos e scripts que são executados em Máquinas Virtuais do Azure, clusters do Azure Service Fabric, Serviço de Aplicativo do Azure, Serviço Kubernetes do Azure (AKS) e outros semelhantes. Este guia também é aplicável a acessos realizados na interface do usuário da base Web do portal do Azure, onde o navegador acessa seu cofre de chaves diretamente.

Por definição de links privados, o aplicativo, script ou portal deve estar em execução na máquina, cluster ou ambiente conectado à Rede Virtual onde o recurso Ponto Final Privado foi implantado.

Se o aplicativo, script ou portal estiver sendo executado em uma rede arbitrária conectada à Internet, este guia NÃO é aplicável e provavelmente links privados não podem ser usados. Essa limitação também é aplicável a comandos executados no Azure Cloud Shell, porque eles são executados em uma máquina remota do Azure fornecida sob demanda em vez do navegador do usuário.

Se você usar uma solução gerenciada, consulte a documentação específica

Este guia NÃO é aplicável a soluções geridas pela Microsoft, em que o cofre de chaves é acedido por um produto do Azure que existe independentemente da Rede Virtual do cliente. Exemplos desses cenários são o Armazenamento do Azure ou o SQL do Azure configurado para criptografia em repouso, Hubs de Eventos do Azure criptografando dados com chaves fornecidas pelo cliente, o Azure Data Factory acessando credenciais de serviço armazenadas no cofre de chaves, Pipelines do Azure recuperando segredos do cofre de chaves e outros cenários semelhantes. Nesses casos, você deve verificar se o produto suporta cofres de chaves com o firewall habilitado. Esse suporte geralmente é realizado com o recurso Serviços Confiáveis do firewall do Cofre de Chaves. No entanto, muitos produtos não estão incluídos na lista de serviços confiáveis, por vários motivos. Nesse caso, entre em contato com o suporte específico do produto.

Alguns produtos do Azure dão suporte ao conceito de injeção de vnet. Em termos simples, o produto adiciona um dispositivo de rede à Rede Virtual do cliente, permitindo que ele envie solicitações como se tivesse sido implantado na Rede Virtual. Um exemplo notável é o Azure Databricks. Produtos como este podem fazer solicitações para o cofre de chaves usando os links privados, e este guia de solução de problemas pode ajudar.

2. Confirme se a conexão foi aprovada e bem-sucedida

Os passos seguintes confirmam que a ligação de ponto final privado foi aprovada e bem-sucedida:

  1. Abra o portal do Azure e abra o recurso do cofre de chaves.
  2. No menu à esquerda, selecione Rede.
  3. Selecione o separador Ligações de ponto final privado, que mostra todas as ligações de ponto final privado e os respetivos estados. Se não houver conexões, ou se a conexão para sua Rede Virtual estiver faltando, você terá que criar um novo Ponto de Extremidade Privado. Este passo será abordado mais adiante.
  4. Ainda em Conexões de ponto de extremidade privadas, encontre a que você está diagnosticando e confirme se "Estado de conexão" é Aprovado e "Estado de provisionamento" é Bem-sucedido.
    • Se a conexão estiver no estado "Pendente", você poderá apenas aprová-la.
    • Se a conexão "Rejeitada", "Falha", "Erro", "Desconectado" ou outro estado, então ela não é eficaz, você tem que criar um novo recurso de Ponto Final Privado.

É uma boa ideia excluir conexões ineficazes para manter as coisas limpas.

3. Confirme se o firewall do cofre de chaves está configurado corretamente

Importante

Alterar as configurações do firewall pode remover o acesso de clientes legítimos que ainda não estão usando links privados. Certifique-se de que está ciente das implicações de cada alteração na configuração da firewall.

Uma noção importante é que o recurso de links privados só dá acesso ao seu cofre de chaves em uma rede virtual que é fechada para evitar a exfiltração de dados. Ele não remove nenhum acesso existente. Para bloquear efetivamente os acessos da Internet pública, você deve habilitar o firewall do cofre de chaves explicitamente:

  1. Abra o portal do Azure e abra o recurso do cofre de chaves.
  2. No menu à esquerda, selecione Rede.
  3. Verifique se a guia Firewalls e redes virtuais está selecionada na parte superior.
  4. Se você encontrar Permitir acesso público de todas as redes selecionadas, isso explica por que os clientes externos ainda podem acessar o cofre de chaves. Se pretender que o Cofre da Chave seja acessível apenas através de Link Privado, selecione Desativar Acesso Público.

As instruções a seguir também se aplicam às configurações de firewall:

  • O recurso de links privados não requer que nenhuma "rede virtual" seja especificada nas configurações do firewall do cofre de chaves. Todas as solicitações que usam o endereço IP privado do cofre de chaves (consulte a próxima seção) devem funcionar, mesmo que nenhuma rede virtual seja especificada nas configurações de firewall do cofre de chaves.
  • O recurso de links privados não requer a especificação de nenhum endereço IP nas configurações de firewall do cofre de chaves. Novamente, todas as solicitações usando o endereço IP privado do cofre de chaves devem funcionar, mesmo que nenhum endereço IP tenha sido especificado nas configurações do firewall.

Se você estiver usando links privados, as únicas motivações para especificar a rede virtual ou o endereço IP no firewall do cofre de chaves são:

  • Você tem um sistema híbrido onde alguns clientes usam links privados, alguns usam pontos de extremidade de serviço, alguns usam endereço IP público.
  • Você está fazendo a transição para links privados. Nesse caso, depois de confirmar que todos os clientes estão usando links privados, você deve remover redes virtuais e endereços IP das configurações de firewall do cofre de chaves.

4. Certifique-se de que o cofre da chave tem um endereço IP privado

Diferença entre endereços IP privados e públicos

Um endereço IP privado tem sempre um dos seguintes formatos:

  • 10.x.x.x: Exemplos: 10.1.2.3, 10.56.34.12.
  • 172.16.x.x a 172.32.x.x: Exemplos: 172.20.1.1, 172.31.67.89.
  • 192.168.x.x: Exemplos: 192.168.0.1, 192.168.100.7

Alguns endereços IP e intervalos são reservados:

  • 224.x.x.x: Multicast
  • 255.255.255.255: Transmissão
  • 127.x.x.x: Loopback
  • 169.254.x.x: Link local
  • 168.63.129.16: DNS interno

Todos os outros endereços IP são públicos.

Quando navegar no portal ou executar um comando que mostre o endereço IP, certifique-se de que consegue identificar se esse endereço IP é privado, público ou reservado. Para que os links privados funcionem, o nome do host do cofre de chaves deve ser resolvido para um endereço IP privado pertencente ao espaço de endereço da Rede Virtual.

Encontre o endereço IP privado do cofre de chaves na rede virtual

Você precisará diagnosticar a resolução do nome do host, e para isso você deve saber o endereço IP privado exato do seu cofre de chaves com links privados ativados. Para encontrar esse endereço, siga este procedimento:

  1. Abra o portal do Azure e abra o recurso do cofre de chaves.
  2. No menu à esquerda, selecione Rede.
  3. Selecione o separador Ligações de ponto final privado, que mostra todas as ligações de ponto final privado e os respetivos estados.
  4. Encontre o que você está diagnosticando e confirme se "Estado de conexão" é Aprovado e Estado de provisionamento é Bem-sucedido. Se você não estiver vendo isso, volte para as seções anteriores deste documento.
  5. Quando encontrar o item certo, clique na ligação na coluna Ponto final privado. Isso abrirá o recurso Private Endpoint.
  6. A página Visão geral pode mostrar uma seção chamada Configurações de DNS personalizadas. Confirme que só existe uma entrada que corresponda ao nome do anfitrião do cofre de chaves. Essa entrada mostra o endereço IP privado do cofre de chaves.
  7. Você também pode clicar no link em Interface de rede e confirmar que o endereço IP privado é o mesmo exibido na etapa anterior. A interface de rede é um dispositivo virtual que representa o cofre de chaves.

O endereço IP é aquele que as VMs e outros dispositivos executados na mesma Rede Virtual usarão para se conectar ao cofre de chaves. Anote o endereço IP ou mantenha a guia do navegador aberta e não toque nela enquanto faz investigações adicionais.

Nota

Se o seu cofre de chaves tiver vários pontos de extremidade privados, ele terá vários endereços IP privados. Isso só é útil se você tiver várias Redes Virtuais acessando o mesmo cofre de chaves, cada uma por meio de seu próprio Ponto Final Privado (o Ponto Final Privado pertence a uma única Rede Virtual). Certifique-se de diagnosticar o problema para a Rede Virtual correta e selecione a conexão de ponto de extremidade privada correta no procedimento acima. Além disso, não crie vários pontos de extremidade privados para o mesmo cofre de chaves na mesma rede virtual. Isso não é necessário e dá origem a confusão.

5. Valide a resolução DNS

A resolução DNS é o processo de traduzir o nome do host do cofre de chaves (exemplo: fabrikam.vault.azure.net) em um endereço IP (exemplo: 10.1.2.3). As subseções a seguir mostram os resultados esperados da resolução DNS em cada cenário.

Esta secção destina-se a fins de aprendizagem. Quando o cofre de chaves não tem nenhuma conexão de ponto de extremidade privada no estado aprovado, a resolução do nome do host dá um resultado semelhante a este:

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

Você pode ver que o nome é resolvido para um endereço IP público e não privatelink há alias. O pseudônimo é explicado mais tarde, não se preocupe com isso agora.

O resultado acima é esperado independentemente da máquina estar conectada à Rede Virtual ou ser uma máquina arbitrária com uma conexão com a Internet. Isso acontece porque o cofre de chaves não tem conexão de ponto de extremidade privado no estado aprovado e, portanto, não há necessidade de o cofre de chaves suportar links privados.

Quando o cofre de chaves tiver uma ou mais conexões de ponto de extremidade privadas no estado aprovado e você resolver o nome do host de uma máquina arbitrária conectada à Internet (uma máquina que não está conectada à Rede Virtual onde o Ponto Final Privado reside), você deverá encontrar o seguinte:

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

A diferença notável em relação ao cenário anterior é que há um novo alias com o valor {vaultname}.privatelink.vaultcore.azure.net. Isso significa que o Plano de Dados do cofre de chaves está pronto para aceitar solicitações de links privados.

Isso não significa que as solicitações realizadas a partir de máquinas fora da Rede Virtual (como a que você acabou de usar) usarão links privados - eles não usarão. Você pode ver isso pelo fato de que o nome do host ainda resolve para um endereço IP público. Somente máquinas conectadas à Rede Virtual podem usar links privados. Seguir-se-ão mais informações sobre este assunto.

Se você não vir o privatelink alias, isso significa que o cofre de chaves não tem conexões de ponto de extremidade privadas no Approved estado. Volte a esta seção antes de tentar novamente.

Quando o cofre de chaves tem uma ou mais conexões de ponto de extremidade privado no estado aprovado e você resolve o nome do host de uma máquina conectada à Rede Virtual onde o Ponto de Extremidade Privado foi criado, esta é a resposta esperada:

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  10.1.2.3
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net has address 10.1.2.3

Há duas diferenças notáveis. Primeiro, o nome é resolvido para um endereço IP privado. Esse deve ser o endereço IP que encontramos na seção correspondente deste artigo. Em segundo lugar, não existem outros pseudónimos depois deste privatelink . Isso acontece porque os servidores DNS da Rede Virtual intercetam a cadeia de aliases e retornam o endereço IP privado diretamente do nome fabrikam.privatelink.vaultcore.azure.net. Essa entrada é, na verdade, um A registro em uma zona DNS privada. Seguir-se-ão mais informações sobre este assunto.

Nota

O resultado acima só acontece em uma Máquina Virtual conectada à Rede Virtual onde o Ponto de Extremidade Privado foi criado. Se você não tiver uma VM implantada na Rede Virtual que contenha o Ponto de Extremidade Privado, implante uma e conecte-se remotamente a ela e, em seguida, execute o nslookup comando (Windows) ou o host comando (Linux) acima.

Se você executar esses comandos em uma máquina virtual conectada à rede virtual onde o ponto de extremidade privado foi criado e eles não estiverem mostrando o endereço IP privado do cofre de chaves, a próxima seção poderá ajudar a corrigir o problema.

6. Validar a zona DNS privada

Se a resolução DNS não estiver funcionando como descrito na seção anterior, pode haver um problema com sua Zona DNS Privada e esta seção pode ajudar. Se a resolução DNS mostrar o endereço IP privado do cofre de chaves correto, a sua Zona DNS Privada provavelmente está correta. Pode ignorar toda esta secção.

Confirme se o recurso de Zona DNS Privada necessário existe

Sua assinatura do Azure deve ter um recurso de Zona DNS Privada com este nome exato:

privatelink.vaultcore.azure.net

Pode verificar a presença deste recurso acedendo à página de subscrição no Portal e selecionando "Recursos" no menu à esquerda. O nome do recurso deve ser privatelink.vaultcore.azure.net, e o tipo de recurso deve ser zona DNS privada.

Normalmente, esse recurso é criado automaticamente quando você cria um ponto de extremidade privado usando um procedimento comum. Mas há casos em que este recurso não é criado automaticamente e você tem que fazê-lo manualmente. Este recurso também pode ter sido excluído acidentalmente.

Se não tiver este recurso, crie um novo recurso de Zona DNS Privada na sua subscrição. Lembre-se que o nome deve ser exatamente privatelink.vaultcore.azure.net, sem espaços ou pontos adicionais. Se você especificar o nome errado, a resolução de nome explicada neste artigo não funcionará. Para obter mais informações sobre como criar esse recurso, consulte Criar uma zona DNS privada do Azure usando o portal do Azure. Se você seguir essa página, você pode pular a criação de Rede Virtual porque neste momento você já deve ter um. Você também pode ignorar procedimentos de validação com Máquinas Virtuais.

Confirme se a Zona DNS Privada está ligada à Rede Virtual

Não basta ter uma Zona DNS Privada. Ele também deve estar vinculado à Rede Virtual que contém o Ponto de Extremidade Privado. Se a Zona DNS Privada não estiver vinculada à Rede Virtual correta, qualquer resolução DNS dessa Rede Virtual ignorará a Zona DNS Privada.

Abra o recurso Zona DNS privada e clique na opção Links de rede virtual no menu à esquerda. Isso mostrará uma lista de links, cada um com o nome de uma Rede Virtual em sua assinatura. A Rede Virtual que contém o recurso Ponto Final Privado deve ser listada aqui. Se não estiver, adicione-a. Para obter etapas detalhadas, consulte Vincular a rede virtual. Você pode deixar "Ativar registro automático" desmarcado - esse recurso não está relacionado a links privados.

Depois que a Zona DNS Privada estiver vinculada à Rede Virtual, as solicitações DNS originadas da Rede Virtual procurarão nomes na Zona DNS Privada. Isso é necessário para a resolução correta de endereços executada em Máquinas Virtuais conectadas à Rede Virtual onde o Ponto de Extremidade Privado foi criado.

Nota

Se você acabou de salvar o link, pode levar algum tempo para que isso entre em vigor, mesmo depois que o Portal diz que a operação está concluída. Também pode ser necessário reinicializar a VM que está usando para testar a resolução DNS.

Confirme se a Zona DNS Privada contém o registo A correto

Usando o Portal, abra a Zona DNS Privada com o nome privatelink.vaultcore.azure.net. A página Visão geral mostra todos os registros. Por padrão, haverá um registro com nome @ e tipo SOA, significando Início da Autoridade. Não toques nisso.

Para que a resolução do nome do cofre de chaves funcione, deve haver um A registro com o nome do cofre simples, sem sufixo ou pontos. Por exemplo, se o nome do host for fabrikam.vault.azure.net, deve haver um A registro com o nome fabrikam, sem qualquer sufixo ou pontos.

Além disso, o A valor do registro (o endereço IP) deve ser o endereço IP privado do cofre de chaves. Se você encontrar o A registro, mas ele contém o endereço IP errado, você deve remover o endereço IP errado e adicionar um novo. É recomendável remover o registro inteiro A e adicionar um novo.

Nota

Sempre que você remover ou modificar um A registro, a máquina ainda pode resolver para o endereço IP antigo porque o valor TTL (Time To Live) pode não ter expirado ainda. É recomendável que você sempre especifique um valor TTL não menor que 10 segundos e não maior que 600 segundos (10 minutos). Se você especificar um valor muito grande, seus clientes podem levar muito tempo para se recuperar de interrupções.

Resolução DNS para mais de uma Rede Virtual

Se houver várias Redes Virtuais e cada uma tiver seu próprio recurso de Ponto Final Privado fazendo referência ao mesmo cofre de chaves, o nome do host do cofre de chaves precisará ser resolvido para um endereço IP privado diferente, dependendo da rede. Isso significa que várias zonas DNS privadas também são necessárias, cada uma vinculada a uma rede virtual diferente e usando um endereço IP diferente no A registro.

Em cenários mais avançados, as Redes Virtuais podem ter o emparelhamento habilitado. Nesse caso, apenas uma Rede Virtual precisa do recurso Ponto Final Privado, embora ambos possam precisar ser vinculados ao recurso Zona DNS Privada. Este cenário não é diretamente coberto por este documento.

Entenda que você tem controle sobre a resolução de DNS

Como explicado na seção anterior, um cofre de chaves com links privados tem o alias {vaultname}.privatelink.vaultcore.azure.net em seu registro público. O servidor DNS usado pela Rede Virtual usa o registro público, mas verifica todos os alias em busca de um registro privado e, se um for encontrado, ele deixará de seguir os aliases definidos no registro público.

Essa lógica significa que, se a Rede Virtual estiver vinculada a uma Zona DNS Privada com nome privatelink.vaultcore.azure.net, e o registro DNS público para o cofre de chaves tiver o alias fabrikam.privatelink.vaultcore.azure.net (observe que o sufixo de nome de host do cofre de chaves corresponde exatamente ao nome da Zona DNS Privada), a consulta DNS procurará um A registro com nome fabrikam na Zona DNS Privada. Se o A registro for encontrado, seu endereço IP será retornado na consulta DNS e nenhuma pesquisa adicional será executada no registro DNS público.

Como você pode ver, a resolução de nomes está sob seu controle. As razões para este design são:

  • Você pode ter um cenário complexo que envolve servidores DNS personalizados e integração com redes locais. Nesse caso, você precisa controlar como os nomes são traduzidos para endereços IP.
  • Poderá ter de aceder a um cofre de chaves sem ligações privadas. Nesse caso, a resolução do nome do host da Rede Virtual deve retornar o endereço IP público, e isso acontece porque os cofres de chaves sem links privados não têm o privatelink alias no registro do nome.

Consultar o /healthstatus ponto de extremidade do cofre de chaves

Seu cofre de chaves fornece o /healthstatus ponto de extremidade, que pode ser usado para diagnósticos. Os cabeçalhos de resposta incluem o endereço IP de origem, conforme visto pelo serviço de cofre de chaves. Você pode chamar esse ponto de extremidade com o seguinte comando (lembre-se de usar seu nome de host do cofre de chaves):

Windows (PowerShell):

PS C:\> $(Invoke-WebRequest -UseBasicParsing -Uri https://fabrikam.vault.azure.net/healthstatus).Headers

Key                           Value
---                           -----
Pragma                        no-cache
x-ms-request-id               3729ddde-eb6d-4060-af2b-aac08661d2ec
x-ms-keyvault-service-version 1.2.27.0
x-ms-keyvault-network-info    addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security     max-age=31536000;includeSubDomains
Content-Length                4
Cache-Control                 no-cache
Content-Type                  application/json; charset=utf-8

Linux, ou uma versão recente do Windows 10 que inclui curl:

joe@MyUbuntu:~$ curl -i https://fabrikam.vault.azure.net/healthstatus

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
x-ms-request-id: 6c090c46-0a1c-48ab-b740-3442ce17e75e
x-ms-keyvault-service-version: 1.2.27.0
x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security: max-age=31536000;includeSubDomains
Content-Length: 4

Se você não estiver recebendo uma saída semelhante a essa, ou se você receber um erro de rede, isso significa que seu cofre de chaves não está acessível através do nome de host especificado (fabrikam.vault.azure.net no exemplo). O nome do host não está resolvendo para o endereço IP correto ou você tem um problema de conectividade na camada de transporte. Pode ser causada por problemas de roteamento, quedas de pacotes e outros motivos. É preciso investigar mais.

A resposta deve incluir o cabeçalho x-ms-keyvault-network-info:

x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;

O addr campo no cabeçalho mostra o x-ms-keyvault-network-info endereço IP da origem da solicitação. Este endereço IP pode ser um dos seguintes:

  • O endereço IP privado da máquina que faz a solicitação. Isso indica que a solicitação está usando links privados ou pontos de extremidade de serviço. Este é o resultado esperado para as ligações privadas.
  • Algum outro endereço IP privado, não da máquina que faz a solicitação. Isso indica que algum roteamento personalizado é eficaz. Ele ainda indica que a solicitação está usando links privados ou pontos de extremidade de serviço.
  • Algum endereço IP público. Isso indica que a solicitação está sendo roteada para a Internet por meio de um dispositivo NAT (gateway). Isso indica que a solicitação NÃO está usando links privados e algum problema precisa ser corrigido. As razões comuns para isso são: 1) o ponto final privado não está em estado aprovado e bem-sucedido; e 2) o nome do host não está resolvendo para o endereço IP privado do cofre de chaves. Este artigo inclui ações de solução de problemas para ambos os casos.

Nota

Se a solicitação funcionar /healthstatus , mas o x-ms-keyvault-network-info cabeçalho estiver ausente, é provável que o ponto de extremidade não esteja sendo atendido pelo cofre de chaves. Como os comandos acima também validam o certificado HTTPS, o cabeçalho ausente pode ser um sinal de adulteração.

Consultar diretamente o endereço IP do cofre de chaves

Importante

Acessar o cofre de chaves sem validação de certificado HTTPS é perigoso e só pode ser usado para fins de aprendizagem. O código de produção NUNCA deve acessar o cofre de chaves sem essa validação do lado do cliente. Mesmo que esteja apenas a diagnosticar problemas, poderá estar sujeito a tentativas de adulteração que não serão reveladas se desativar frequentemente a validação de certificados HTTPS nos seus pedidos para o cofre de chaves.

Se você instalou uma versão recente do PowerShell, pode usar -SkipCertificateCheck para ignorar verificações de certificado HTTPS, então você pode direcionar o endereço IP do cofre de chaves diretamente:

PS C:\> $(Invoke-WebRequest -SkipCertificateCheck -Uri https://10.1.2.3/healthstatus).Headers

Se você estiver usando curlo , você pode fazer o mesmo com o -k argumento:

joe@MyUbuntu:~$ curl -i -k https://10.1.2.3/healthstatus

As respostas devem ser as mesmas da seção anterior, o que significa que deve incluir o x-ms-keyvault-network-info cabeçalho com o mesmo valor. O /healthstatus ponto de extremidade não se importa se você estiver usando o nome de host do cofre de chaves ou o endereço IP.

Se você vir x-ms-keyvault-network-info retornando um valor para a solicitação usando o nome de host do cofre de chaves e outro valor para a solicitação usando o endereço IP, cada solicitação está direcionada a um ponto de extremidade diferente. Consulte a explicação do addr campo x-ms-keyvault-network-info na seção anterior, para decidir qual caso está errado e precisa ser corrigido.

8. Outras alterações e personalizações que causam impacto

Os itens que se seguem são ações de investigação não exaustivas. Eles lhe dirão onde procurar problemas adicionais, mas você deve ter conhecimento avançado de rede para corrigir problemas nesses cenários.

Diagnosticar servidores DNS personalizados na Rede Virtual

No Portal, abra o recurso Rede Virtual. No menu à esquerda, abra servidores DNS. Se você estiver usando "Personalizado", a resolução DNS pode não ser a descrita neste documento. Você tem que diagnosticar como seus servidores DNS estão resolvendo o nome de host do cofre de chaves.

Se você estiver usando os servidores DNS padrão fornecidos pelo Azure, todo este documento será aplicável.

Diagnosticar hosts substituindo ou servidores DNS personalizados na Máquina Virtual

Muitos sistemas operacionais permitem definir um endereço IP fixo explícito por nome de host, normalmente alterando o hosts arquivo. Eles também podem permitir a substituição dos servidores DNS. Se você usar um desses cenários, prossiga com as opções de diagnóstico específicas do sistema.

Procuradores promíscuos (Fiddler, etc.)

Exceto quando explicitamente indicado, as opções de diagnóstico neste artigo só funcionam se não houver nenhum proxy promíscuo presente no ambiente. Embora esses proxies geralmente sejam instalados exclusivamente na máquina que está sendo diagnosticada (o Fiddler é o exemplo mais comum), os administradores avançados podem substituir as Autoridades de Certificação (CAs) raiz e instalar um proxy promíscuo em dispositivos de gateway que atendem várias máquinas na rede. Esses proxies podem afetar substancialmente a segurança e a confiabilidade. A Microsoft não oferece suporte a configurações que usam esses produtos.

Outras coisas que podem afetar a conectividade

Esta é uma lista não exaustiva de itens que podem ser encontrados em cenários avançados ou complexos:

  • Configurações de firewall, o Firewall do Azure conectado à Rede Virtual ou uma solução de firewall personalizada implantada na Rede Virtual ou na máquina.
  • Emparelhamento de rede, que pode afetar quais servidores DNS são usados e como o tráfego é roteado.
  • Soluções de gateway personalizado (NAT), que podem afetar a forma como o tráfego é roteado, incluindo o tráfego de consultas DNS.