Diagnosticar problemas de configuração de links privados no Azure Key Vault

Introdução

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

Se você for novo nesse recurso, confira Integrar o Key Vault com o Link Privado do Azure.

Problemas abordados neste artigo

• As 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 usando o recurso de links privados.
• Todas as solicitações feitas por determinado cliente que está usando o 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 recebem a resposta 403 com o código de erro interno ForbiddenByFirewall.
• Você está usando links privados, mas o cofre de chaves ainda aceita solicitações da Internet pública.
• O cofre de chaves 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 abordados neste artigo

• Há um problema de conectividade intermitente. Em determinado cliente, você vê algumas solicitações funcionando e outras não. 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 de cliente.
• Você está usando um produto do Azure que dá suporte a BYOK (Bring Your Own Key), CMK (Chaves gerenciadas pelo cliente) ou acesso a segredos armazenados no cofre de chaves. Quando você habilita o firewall nas configurações do cofre de chaves, esse produto não pode acessar o cofre. Confira a documentação específica do produto. Verifique se ele declara explicitamente o suporte a cofres-chave com o firewall habilitado. Entre em contato com o suporte sobre esse produto específico, se necessário.

Como ler este artigo

Caso você seja novo em links privados ou esteja avaliando uma implantação complexa, recomendamos 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. Confirmar se você possui a conexão do cliente

Confirmar se o cliente é executado na rede virtual

Este guia destina-se a ajudar a corrigir conexões com o cofre de chaves provenientes do código do aplicativo. Os exemplos são aplicativos e scripts executados em máquinas virtuais do Azure, clusters do Azure Service Fabric, Serviço de Aplicativo do Azure, AKS (Serviço de Kubernetes do Azure) e outros semelhantes. Este guia também se aplica a acessos realizados na interface do usuário baseada na Web do portal do Azure, em que o navegador acessa diretamente o cofre de chaves.

Pela definição de links privados, o aplicativo, script ou portal deve estar em execução no computador, cluster ou ambiente conectado à Rede Virtual em que o recurso de Ponto de Extremidade Privado foi implantado.

Se o aplicativo, script ou portal estiver sendo executado em uma rede conectada na Internet arbitrária, este guia NÃO será aplicável e provavelmente os links privados não poderão ser usados. Essa limitação também se aplica a comandos executados no Azure Cloud Shell, porque eles são executados em um computador remoto do Azure fornecido sob demanda, e não no navegador do usuário.

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

Este guia NÃO se aplica a soluções gerenciadas pela Microsoft, em que o cofre de chaves é acessado por um produto do Azure que existe independentemente da Rede Virtual do cliente. Exemplos desses cenários são o Armazenamento do Microsoft Azure ou SQL do Azure configurado para criptografia em repouso, Hubs de Eventos do Azure criptografando dados com chaves fornecidas pelo cliente, Azure Data Factory acessando credenciais de serviço armazenadas no cofre de chaves, Azure Pipelines recuperando segredos do cofre de chaves e outros cenários semelhantes. Nesses casos, você deve verificar se o produto dá suporte a cofres de chaves com o firewall habilitado. Esse suporte é normalmente executado com o recurso de Serviços Confiáveis do firewall do Key Vault. No entanto, muitos produtos não estão incluídos na lista de serviços confiáveis, por vários motivos. Nesse caso, contate 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 adicionará um dispositivo de rede à Rede Virtual do cliente, permitindo que ele envie solicitações como se estivesse implantado na Rede Virtual. Um exemplo notável é o Azure Databricks. Produtos como esse podem fazer solicitações para o cofre de chaves usando links privados. Este guia de solução de problemas pode ajudar.

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

As seguintes etapas validam se a conexão de ponto de extremidade privado foi aprovada e bem-sucedida:

1. Abra o portal do Azure e o recurso do cofre de chaves.
2. No menu à esquerda, selecione Rede.
3. Selecione a guia Conexões de ponto de extremidade privado. Isso mostrará todas as conexões de ponto de extremidade privado e os respectivos estados. Se não houver conexões ou se a conexão de sua Rede Virtual estiver ausente, você precisará criar um Ponto de Extremidade Privado. Abordaremos isso mais tarde.
4. Ainda em Conexões de ponto de extremidade privado, encontre aquela que você está diagnosticando e confirme se o "Estado da conexão" é Aprovado e o "Estado de provisionamento" é Bem-sucedido.
   • Caso a conexão esteja no estado "Pendente", talvez você precise apenas aprová-la.
   • Se o estado da conexão for "Rejeitada", "Falha", "Erro", "Desconectada" ou outro, ela não estará funcionando. Você precisará criar um recurso de Ponto de Extremidade Privado.

É uma boa ideia excluir conexões ineficazes a fim de manter tudo limpo.

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

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

1. Abra o portal do Azure e 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 a opção Permitir acesso público de todas as redes estiver selecionada, isso explica por que os clientes externos ainda podem acessar o cofre de chaves. Se você quiser que o Key Vault seja acessível somente por Link Privado, selecione Desabilitar Acesso Público.

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

• O recurso de links privados não exige que nenhuma "rede virtual" seja especificada nas configurações de firewall do cofre de chaves. Todas as solicitações que usam o endereço IP privado do cofre de chaves (confira 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 que usam 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 serão:

• Você tem um sistema híbrido em que alguns clientes usam links privados, outros usam pontos de extremidade de serviço e outros usam o 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ê deverá remover redes virtuais e endereços IP das configurações de firewall do cofre de chaves.

4. Verificar se o cofre de chaves tem um endereço IP privado

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

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

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

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

• 224.x.x.x: multicast
• 255.255.255.255: difundido
• 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.

Ao navegar no portal ou executar um comando que mostra o endereço IP, identifique 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 que pertence ao espaço de endereço de Rede Virtual.

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

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

1. Abra o portal do Azure e o recurso do cofre de chaves.
2. No menu à esquerda, selecione Rede.
3. Selecione a guia Conexões de ponto de extremidade privado. Isso mostrará todas as conexões de ponto de extremidade privado e os respectivos estados.
4. Localize aquela que você está diagnosticando e confirme se o "Estado da conexão" é Aprovado e o Estado de provisionamento é Bem-sucedido. Se você não estiver vendo isso, volte para as seções anteriores deste documento.
5. Quando você encontrar o item correto, clique no link na coluna Ponto de extremidade privado. Isso abrirá o recurso Ponto de Extremidade Privado.
6. A página de Visão geral pode mostrar uma seção chamada Configurações personalizadas de DNS. Confirme se há apenas uma entrada que corresponda ao nome de host 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 Adaptador de rede e confirmar se o endereço IP privado é o mesmo exibido na etapa anterior. O adaptador de rede é um dispositivo virtual que representa o cofre de chaves.

O endereço IP é aquele que as VMs e outros dispositivos em execução 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 a toque enquanto fizer investigações adicionais.

5. Validar a resolução de DNS

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

Cofres de chaves sem link privado

Esta seção é destinada a fins de aprendizado. Quando o cofre de chaves não tem nenhuma conexão de ponto de extremidade privado no estado aprovado, resolver o nome do host fornece 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á nenhum alias privatelink. O alias será explicado mais tarde, não se preocupe com isso agora.

O resultado acima é esperado, independentemente de o computador estar conectado à Rede Virtual ou ser um computador arbitrário com uma conexão com a Internet. Isso acontece porque o cofre de chaves não tem nenhuma conexão de ponto de extremidade privado no estado aprovado e, portanto, não há necessidade de que o cofre de chaves dê suporte a links privados.

Cofre de chaves com resolução de link privado pelo computador arbitrário da Internet

Quando o cofre de chaves tiver uma ou mais conexões de ponto de extremidade privado no estado aprovado e você resolver o nome do host de um computador arbitrário conectado à Internet (um computador que não está conectado à Rede Virtual em que reside o Ponto de Extremidade Privado), você 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 executadas de computadores fora da Rede Virtual (como a que você acabou de usar) usarão links privados. Você pode ver isso pelo fato de que o nome do host ainda é resolvido para um endereço IP público. Somente computadores conectados à Rede Virtual podem usar links privados. Confira mais informações abaixo.

Se você não vir o alias privatelink, significa que o cofre de chaves não tem nenhuma conexão de ponto de extremidade privado no estado Approved. Volte para esta seção antes de tentar novamente.

Cofre de chaves com resolução de link privado pela Rede Virtual

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 por um computador conectado à Rede Virtual em que 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 visíveis. Primeiro, o nome é resolvido para um endereço IP privado. Ele deve ser o endereço IP que encontramos na seção correspondente deste artigo. Em segundo lugar, não há nenhum outro alias após privatelink. Isso acontece porque os servidores DNS da Rede Virtual interceptam a cadeia de aliases e retornam o endereço IP privado diretamente do nome fabrikam.privatelink.vaultcore.azure.net. Essa entrada é, na verdade, um registro A em uma Zona DNS Privada. Confira mais informações abaixo.

Se você executar esses comandos em uma Máquina Virtual conectada à Rede Virtual em que o Ponto de Extremidade Privado foi criado e ela não estiver 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

Caso a resolução de DNS não esteja funcionando conforme descrito na seção anterior, pode haver um problema com sua Zona DNS Privada. Esta seção pode ajudar. Se a resolução de DNS mostrar o endereço IP privado do cofre de chaves correto, sua Zona DNS Privada provavelmente estará correta. Você pode ignorar esta seção inteira.

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

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

privatelink.vaultcore.azure.net

Você pode verificar a presença desse recurso acessando a página de assinatura 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 de forma automática quando você cria um Ponto de Extremidade Privado usando um procedimento comum. Mas há casos em que o recurso não é criado automaticamente e é necessário fazer isso de forma manual. O recurso também pode ter sido excluído acidentalmente.

Se você não tiver esse recurso, crie um recurso Zona DNS Privada em sua assinatura. 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 nomes explicada neste artigo não funcionará. Para obter mais informações sobre como criar o recurso, confira Criar uma Zona DNS Privada do Azure usando o portal do Azure. Se você seguir esta página, poderá ignorar a criação de Rede Virtual porque, neste ponto, você já deve ter uma. Você também pode ignorar os procedimentos de validação com Máquinas Virtuais.

Confirmar se a Zona DNS Privada está vinculada à Rede Virtual

Não é suficiente ter uma Zona DNS Privada. Ela também deve estar vinculada à 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 de DNS dessa Rede 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 de ponto de extremidade privado deve estar listada aqui. Se não estiver, adicione-a. Para obter etapas detalhadas, confira Vincular a rede virtual. Você pode deixar a opção "Habilitar registro automático" desmarcada – esse recurso não está relacionado aos links privados.

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

Confirmar se a Zona DNS Privada contém o registro A correto

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

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

Além disso, o valor do registro A (o endereço IP) deve ser o endereço IP privado do cofre de chaves. Se você encontrar o registro A, mas ele tiver o endereço IP errado, remova esse endereço IP e adicione um novo. É recomendável que você remova todo o registro A e adicione um novo.

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 de Extremidade Privado referenciando o 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 Zona DNS Privada também são necessárias, cada uma vinculada a uma Rede Virtual diferente e usando um endereço IP distinto no registro A.

Em cenários mais avançados, as Redes Virtuais podem ter o emparelhamento habilitado. Nesse caso, apenas uma Rede Virtual precisa do recurso de Ponto de Extremidade Privado, embora ambas precisem estar vinculadas ao recurso de Zona DNS Privada. Esse cenário não é abordado diretamente neste documento.

Você tem controle sobre a resolução de DNS

Conforme 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 cada alias em busca de um registro privado. Se encontrar um, ele interromperá os aliases seguintes definidos no registro público.

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

Como você pode ver, a resolução de nomes está sob seu controle. Os motivos para esse 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 convertidos em endereços IP.
• Talvez seja necessário acessar um cofre de chaves sem links privados. Nesse caso, resolver o nome do host da Rede Virtual deverá retornar o endereço IP público. Isso ocorre porque os cofres de chaves sem links privados não têm o alias privatelink no registro de nome.

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

Consultar o ponto de extremidade /healthstatus do cofre de chaves

O cofre de chaves fornece o ponto de extremidade /healthstatus, que pode ser usado para diagnóstico. Os cabeçalhos de resposta incluem o endereço IP de origem, como visto pelo serviço de cofre de chaves. Você pode chamar o ponto de extremidade com o seguinte comando (use o nome do 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 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

Caso você não obtenha uma saída semelhante a essa ou receba um erro de rede, isso significa que o cofre de chaves não está acessível por meio do nome de host especificado (fabrikam.vault.azure.net no exemplo). O nome do host não está sendo resolvido para o endereço IP correto, ou você tem um problema de conectividade na camada de transporte. Isso pode ser causado por problemas de roteamento, quedas de pacote e outros motivos. Você precisa investigar mais detalhadamente.

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 campo addr no cabeçalho x-ms-keyvault-network-info mostra o endereço IP da origem da solicitação. Esse endereço IP pode ser um dos seguintes:

• O endereço IP privado do computador que está fazendo a solicitação. Indica que a solicitação está usando links privados ou pontos de extremidade de serviço. Esse é o resultado esperado para links privados.
• Algum outro endereço IP privado, que não é do computador que está fazendo a solicitação. Isso indica que um roteamento personalizado é eficaz. Indica também 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 de gateway (NAT). Indica também que a solicitação NÃO está usando links privados e que algum problema precisa ser corrigido. Os motivos comuns para isso são 1) o ponto de extremidade privado não está em estado aprovado e com êxito; e 2) o nome do host não está sendo 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, poderá usar -SkipCertificateCheck para ignorar as verificações de certificado HTTPS e 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 curl, poderá fazer o mesmo com o argumento -k:

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 devem incluir o cabeçalho x-ms-keyvault-network-info com o mesmo valor. O ponto de extremidade /healthstatus não se importará se você estiver usando o nome do host ou o endereço IP do cofre de chaves.

Caso você veja x-ms-keyvault-network-info retornando um valor para a solicitação usando o nome do host do cofre de chaves e outro valor para a solicitação usando o endereço IP, cada solicitação está sendo direcionada para um ponto de extremidade diferente. Confira a explicação do campo addr de 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 a seguir são ações de investigação não exaustivas. Eles informarão onde procurar problemas adicionais, mas você deve ter um 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 de DNS poderá não ser como a descrita neste documento. Você precisa diagnosticar como os servidores DNS estão resolvendo o nome do host do cofre de chaves.

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

Diagnosticar substituição de hosts 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 arquivo hosts. Eles também podem permitir a substituição de servidores DNS. Se você usar um desses cenários, prossiga com as opções de diagnóstico específicas do sistema.

Proxies promíscuos (Fiddler etc.)

Exceto quando explicitamente indicado, as opções de diagnóstico neste artigo só funcionarão se não houver nenhum proxy promíscuo no ambiente. Embora esses proxies costumem ser instalados exclusivamente no computador que está sendo diagnosticado (o Fiddler é o exemplo mais comum), administradores avançados podem substituir ACs (autoridades de certificação) raiz e instalar um proxy promíscuo em dispositivos de gateway que atendem a vários computadores na rede. Esses proxies podem afetar substancialmente a segurança e a confiabilidade. A Microsoft não dá suporte a configurações que usam esses produtos.

Outros elementos que podem afetar a conectividade

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

• Configurações de firewall, seja o Firewall do Azure conectado à Rede Virtual ou uma solução de firewall personalizada que está sendo implantada na Rede Virtual ou no computador.
• 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 como o tráfego é roteado, incluindo o tráfego de consultas DNS.