Diagnostique problemas de configuração de links privados em Azure Key Vault

Introdução

Este artigo ajuda os utilizadores a diagnosticar e corrigir problemas relacionados com o Key Vault e a funcionalidade de 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 é novo nesta funcionalidade, veja Integrar Key Vault com 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.
• Todos os pedidos feitos por um dado cliente que está a usar ligação privada falham devido a timeouts 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 raramente são causados por um problema na configuração de links privados; Eles são um sinal de sobrecarga de rede ou cliente.
• Está a usar um produto Azure que suporta BYOK (Traga a Sua Própria Chave), CMK (Chaves Geridas pelo Cliente) 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 seu cliente está a correr na rede virtual

Este guia destina-se a ajudá-lo a corrigir conexões com o Key Vault que se originam do código da aplicação. Exemplos são aplicações e scripts que executam em Máquinas Virtuais do Azure, clusters Azure Service Fabric, Serviço de Aplicações do Azure, Azure Kubernetes Service (AKS) e outros semelhantes. Este guia também é aplicável a acessos realizados na interface web do portal Azure, onde o navegador acede diretamente ao seu cofre de chaves.

Por definição de links privados, a aplicação, script ou portal deve estar a correr na máquina, cluster ou ambiente ligado ao Rede Virtual onde o recurso Private Endpoint foi implementado.

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. Esta limitação aplica-se também a comandos executados no Azure Cloud Shell, porque correm numa máquina Azure remota fornecida on-demand em vez do navegador do utilizador.

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

Os serviços Azure geridos requerem configurações diferentes

Este guia NÃO se aplica a serviços geridos pela Microsoft que acedam ao seu Key Vault a partir de fora da sua Rede Virtual. Esses cenários incluem:

• Armazenamento do Azure configurado com encriptação em repouso
• SQL do Azure usando chaves geridas pelo cliente
• Hubs de Eventos do Azure encripta dados com as suas chaves
• Azure Data Factory aceder a credenciais armazenadas no Key Vault
• Azure Pipelines recuperando segredos do Key Vault

Para estes cenários, deve verificar se o serviço específico do Azure suporta o acesso a Cofres de Chaves com firewalls ativados. Muitos serviços utilizam a funcionalidade Trusted Services para aceder de forma segura ao seu Key Vault apesar das restrições do firewall. No entanto, nem todos os serviços do Azure aparecem na lista de serviços confiáveis devido a várias razões arquitetónicas.

Se estiver a ter problemas com um serviço específico do Azure a aceder ao seu Key Vault, consulte a documentação desse serviço ou contacte a equipa de suporte para obter orientações específicas.

Alguns Azure produtos suportam o conceito de injeção vnet. Em termos simples, o produto adiciona um dispositivo de rede à Rede Virtual do cliente, permitindo-lhe enviar pedidos como se tivesse sido implementado na Rede Virtual. Um exemplo notável é 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 seu recurso do cofre de chaves.
2. No menu à esquerda, selecione Rede.
3. Selecione a guia Private endpoint connections para ver todas as conexões de endpoint privadas e seus respetivos estados. Se não houver ligações, ou se a ligação da sua Rede Virtual estiver em falta, tem de criar um novo Endpoint Privado. Este passo será abordado mais adiante.
4. Ainda em conexões de endpoint privadas, encontre a que está a diagnosticar e confirme que "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

Uma noção importante é que a funcionalidade de links privados apenas dá acesso ao seu cofre de chaves numa Rede Virtual 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 seu 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 quiser que o Key Vault seja acessível apenas por Private Link, 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 as ligações privadas funcionem, o nome de host do cofre de chaves deve ser resolvido para um endereço IP privado que pertença ao espaço de endereçamento 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 estes passos:

1. Abra o portal do Azure e abra o seu recurso do cofre de chaves.
2. No menu à esquerda, selecione Rede.
3. Selecione a guia Private endpoint connections . A exibição resultante mostra todas as conexões de ponto de extremidade privadas e seus respetivos estados.
4. Encontre a conexão que você está diagnosticando e confirme se "Estado da conexão" é Aprovado e Estado de provisionamento é Bem-sucedido. Se o estado for diferente, volte para as secções anteriores do documento.
5. Quando encontrar o item apropriado, selecione o link na coluna endpoint privado. A ação abre o recurso Ponto Final Privado.
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 selecionar o link na interface de rede e confirmar se o endereço IP privado é o mesmo exibido na etapa anterior. A interface de rede é um dispositivo virtual que representa o Key Vault.

O endereço IP é aquele que as VMs e outros dispositivos a correr na mesma Rede Virtual usam para se ligar 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.

5. Valide a resolução DNS

A resolução DNS é o processo de traduzir o nome de anfitrião do cofre de chaves (exemplo: fabrikam.vault.azure.net) num 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.

Cofres de chaves sem ligação privada

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 há privatelink alias. O pseudônimo é explicado mais tarde, não se preocupe com isso agora.

Este resultado aparece o mesmo quer esteja a executar a consulta a partir de uma máquina ligada à Rede Virtual ou de qualquer computador com ligação à internet. O resultado ocorre porque o cofre de chaves não tem conexões de ponto de extremidade privadas em um estado aprovado, portanto, não há necessidade de o cofre de chaves oferecer suporte a links privados.

Cofre de segredos com a resolução de ligações privadas a partir de uma máquina qualquer na Internet

Quando o cofre de chaves tem uma ou mais conexões de endpoint privado em estado aprovado e resolve o nome de host a partir de uma máquina arbitrária conectada à Internet (uma máquina que não está conectada à Rede Virtual onde reside o Endpoint Privado), recebe 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
          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. O Plano de Dados do cofre de chaves está pronto para aceitar solicitações de links privados.

Isto não significa que os pedidos realizados a partir de máquinas externas à rede virtual (como a que acabou de usar) usem links privados, não os usam. Pode perceber isso pelo facto de que o nome do host ainda é traduzido para um endereço IP público. Apenas máquinas ligadas ao Rede Virtual podem usar ligações privadas.

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.

Cofre de chaves com ligação privada a ser resolvida a partir da Rede Virtual

Quando o cofre de chaves tem uma ou mais ligações de ponto final privado em estado aprovado e resolve o nome de host a partir de uma máquina ligada à Rede Virtual onde o ponto final 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 . Isto acontece porque os servidores DNS Rede Virtual interceptam a cadeia de pseudónimos e devolvem o endereço IP privado diretamente do nome fabrikam.privatelink.vaultcore.azure.net. Essa entrada é, na verdade, um registo A numa Zona DNS Privado.

Se executares estes comandos numa Máquina Virtual ligada à Rede Virtual onde o Endpoint Privado foi criado e eles não estiverem a mostrar o endereço IP privado do cofre de chaves, a secção seguinte pode ajudar a resolver o problema.

6. Validar a Zona de DNS Privada

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

Confirme que existe o recurso necessário da Zona DNS Privado

A sua subscrição Azure deve ter um recurso DNS Privado Zone 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 DNS Privado zona.

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 DNS Privado Zone na sua subscrição. Lembre-se que o nome deve ser exatamente privatelink.vaultcore.azure.net, sem espaços ou pontos extras. Se você especificar o nome errado, a resolução de nomes explicada neste artigo falhará. Para mais informações sobre como criar este recurso, consulte Criar uma Azure zona DNS privada usando o portal Azure. Se seguires essa página, podes saltar a criação do Rede Virtual porque, neste momento, já deves ter uma. Também pode saltar procedimentos de validação com Máquinas Virtuais.

Confirme que a DNS Privado Zone está ligada à Rede Virtual

Não basta ter uma Zona DNS Privado. Deve também estar ligado à Rede Virtual que contém o Endpoint Privado. Se a DNS Privado Zone não estiver ligada à Rede Virtual correta, qualquer resolução DNS dessa Rede Virtual irá ignorar a DNS Privado Zone.

Abra o recurso DNS Privado Zona e selecione a opção Ligações de rede virtual no menu esquerdo. Vê uma lista de links, cada um com o nome de uma Rede Virtual na sua subscrição. A Rede Virtual que contém o recurso Private Endpoint deve estar 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 de a DNS Privado Zone estar ligada à Rede Virtual, quaisquer pedidos DNS provenientes dessa rede verificam automaticamente esta zona privada para resolução de nomes. Esta ligação é essencial para que as Máquinas Virtuais na mesma Rede Virtual que o Ponto Final Privado resolvam corretamente o nome do host do cofre de chaves para o seu endereço IP privado em vez de para o seu endereço público.

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

Usando o Portal, abra a Zona DNS Privado com o nome privatelink.vaultcore.azure.net. A página Visão geral mostra todos os registros. Por padrão, há um registo com o nome @ e tipo SOA, que representa o Início de Autoridade. Não toques nisso.

Para que a resolução do nome do cofre de chaves funcione, deve haver um A registo com o nome simples do cofre, 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 valor do A registo (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.

Resolução DNS para mais do que 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. Isto significa que também são necessárias várias Zonas DNS Privado, cada uma ligada a um Rede Virtual diferente e usando um endereço IP distinto no registo A.

Em cenários mais avançados, as Redes Virtuais podem ter o emparelhamento habilitado. Neste caso, apenas uma Rede Virtual necessita do recurso Private Endpoint, embora ambos possam precisar de ser ligados ao recurso DNS Privado Zone. 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 em seu {vaultname}.privatelink.vaultcore.azure.net. O servidor DNS usado pelo Rede Virtual usa o registo público, mas verifica todos os alias para um registo privado e, se for encontrado, deixa de seguir os alias definidos no registo público.

Esta lógica significa que, se o Rede Virtual estiver ligado a uma Zona DNS Privado com o nome privatelink.vaultcore.azure.net, e o registo DNS público do cofre de chaves tiver o alias fabrikam.privatelink.vaultcore.azure.net (note que o sufixo do nome do cofre de chave corresponde exatamente ao nome da DNS Privado Zona), então a consulta DNS procura um registo A com o nome fabrikamno DNS Privado Zona. 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. O fundamento para esta conceçã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, porque os cofres de chaves sem ligações privadas não contêm o alias privatelink no registo do nome.

7. Valide se as solicitações para o cofre de chaves usam link privado

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 endpoint com o seguinte comando (lembre-se de usar o nome do host do seu 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 de Windows 10 que inclua 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 indica continuamente que a solicitação está usando links privados ou endpoints 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 concluído com sucesso; e 2) o nome do host não está resolvido para o endereço IP privado do cofre de chaves. Este artigo inclui ações de solução de problemas para ambos os casos.

Consultar diretamente o endereço IP do 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 estiver a usar os servidores DNS predefinidos fornecidos pelo Azure, este documento completo é 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 na ausência de um proxy promíscuo 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 suporta configurações que utilizem 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:

• Definições de firewall, seja o Azure Firewall ligado à Rede Virtual, ou uma solução de firewall personalizada a ser implementada na Rede Virtual ou na máquina.
• Emparelhamento de rede, que pode afetar os servidores DNS usados e como o tráfego é roteado.
• Soluções de gateways personalizados (NAT), que podem afetar a forma como o tráfego é roteado, incluindo o tráfego de consultas DNS.

Próximos passos

• Integrar o Key Vault com o Azure Private Link
• Configurar segurança de rede para Azure Key Vault
• Assegure o seu Azure Key Vault