Диагностика проблем с конфигурацией приватных каналов в Azure Key Vault

Введение

Эта статья помогает пользователям диагностировать и устранять проблемы, связанные с Key Vault и функцией приватных ссылок. Это руководство поможет понять тонкости настройки, такие как подготовка приватных каналов к первому запуску или исправление ситуаций, связанных с остановкой приватных каналов после внесения некоторых изменений.

Если вы не знакомы с этой функцией, ознакомьтесь с Integrate Key Vault с Приватный канал Azure.

Проблемы, которые описываются в этой статье

• Запросы DNS по-прежнему возвращают общедоступный IP-адрес для хранилища ключей вместо частного IP-адреса, получение которого ожидается в результате использования функции приватных каналов.
• Все запросы, сделанные заданным клиентом, использующим приватный канал, завершаются сбоем со временем ожидания или сетевыми ошибками, и проблема не прерывается.
• Хранилище ключей имеет частный IP-адрес, но запросы по-прежнему получают ответ 403 с кодом внутренней ошибки ForbiddenByFirewall.
• Вы используете приватные каналы, но хранилище ключей по-прежнему принимает запросы из общедоступного Интернета.
• В вашем хранилище ключей есть две частные конечные точки. Запросы, использующие один вариант, работают нормально, но запросы, использующие другой, не работают.
• У вас есть другая подписка, хранилище ключей или виртуальная сеть, которая использует приватные каналы. Вы хотите создать новое аналогичное развертывание, но не можете заставить работать частные ссылки.

Проблемы, которые НЕ описываются в этой статье

• Проблема с нестабильным подключением. В определенном клиенте некоторые запросы работают, а некоторые не работают. Периодические проблемы редко возникают из-за проблемы в конфигурации приватных каналов; они являются признаком перегрузки сети или клиента.
• Вы используете продукт Azure, который поддерживает использование собственного ключа (BYOK), ключи, управляемые клиентом (CMK), или доступ к секретам, хранящимся в хранилище ключей. При включении брандмауэра в параметрах хранилища ключей этот продукт не может получить доступ к хранилищу ключей. Посмотрите документацию по продукту. Убедитесь, что в ней явно говорится о поддержке хранилищ ключей с включенным сетевым экраном. При необходимости обратитесь в службу поддержки данного продукта.

Как читать эту статью

Если вы не знакомы с частными ссылками или оцениваете сложное развертывание, рекомендуется ознакомиться со всей статьей. В противном случае вы можете выбрать раздел, который лучше всего подходит для проблемы, с которой вы столкнулись.

Давайте приступим!

1. Убедитесь, что у вас клиентское подключение

Убедитесь, что ваш клиент работает в виртуальной сети

Это руководство предназначено для помощи в решении проблем с подключением к хранилищу ключей, связанных с кодом приложения. Примерами являются приложения и скрипты, которые выполняются в Виртуальные машины Azure, кластерах Azure Service Fabric, Служба приложений Azure, Azure Kubernetes Service (AKS) и аналогичных других. Это руководство также применимо к доступу, выполняемому в пользовательском интерфейсе веб-интерфейса портала Azure, где браузер обращается к хранилищу ключей напрямую.

По определению частных ссылок приложение, скрипт или портал должны работать на компьютере, кластере или среде, подключенной к виртуальная сеть, где развернут ресурс конечной точки Private Endpoint.

Если запуск приложения, скрипта или портала выполнен в произвольной сети, подключенной к Интернету, то НЕВОЗМОЖНО будет применить это руководство и, скорее всего, нельзя будет использовать приватные каналы. Это ограничение также применимо к командам, выполняемым в Azure Cloud Shell, так как они выполняются на удаленном Azure компьютере, предоставленном по запросу, а не в браузере пользователя.

Если вы используете управляемое решение, см. документацию по этому вопросу

Для управляемых служб Azure требуется другая конфигурация

Это руководство не применяется к управляемым Майкрософт службам, которые обращаются к Key Vault за пределами виртуальная сеть. Ниже приведены соответствующие сценарии.

• служба хранилища Azure, настроенное с шифрованием данных в состоянии покоя
• Azure SQL с помощью ключей, управляемых клиентом
• Центры событий Azure шифрование данных с вашими ключами
• Фабрика данных Azure доступ к учетным данным, хранящимся в Key Vault
• Azure Pipelines извлечение секретов из Хранилища ключей

Для этих сценариев необходимо проверить, поддерживает ли конкретная служба Azure доступ к Key Vault с включенными брандмауэрами. Многие службы используют функцию Trusted Services для безопасного доступа к Key Vault, несмотря на ограничения брандмауэра. Однако не все службы Azure отображаются в списке доверенных служб из-за различных архитектурных причин.

Если у вас возникли проблемы с определенной службой Azure, обращаюющейся к Key Vault, обратитесь к документации этой службы или обратитесь в службу поддержки для получения конкретных рекомендаций.

Несколько продуктов Azure поддерживают концепцию внедрения vnet. В простых терминах продукт добавляет сетевое устройство в клиентскую виртуальная сеть, что позволяет отправлять запросы, как если бы оно было развернуто в виртуальная сеть. Примером является Azure Databricks. Подобные продукты могут отправлять запросы в хранилище ключей с использованием приватных каналов, и в этом случае данное руководство по устранению неполадок может помочь.

2. Убедитесь, что подключение утверждено и выполнено

Следующие шаги направлены на проверку того, что подключение к частной конечной точке утверждено и выполнено:

1. Откройте портал Azure и откройте ресурс хранилища ключей.
2. В меню слева выберите Сеть.
3. Перейдите на вкладку "Подключения частной конечной точки ", чтобы просмотреть все подключения к частной конечной точке и соответствующие состояния. Если нет подключений или если подключение для виртуальная сеть отсутствует, необходимо создать новую частную конечную точку. Это будет рассмотрено позже.
4. Находясь на вкладке Подключения к частной конечной точке, найдите подключение, которое вы диагностируете, и убедитесь, что параметр "Состояние подключения" имеет значение Утверждено, а параметр "Состояние подготовки" — Выполнено.
   • Если подключение находится в состоянии "Ожидание", вы можете просто утвердить его.
   • Если подключение находится в состоянии "Отклонено", "Сбой", "Ошибка", "Отключено" или в другом состоянии, такой шаг не является эффективным. Вместо этого необходимо создать новый ресурс приватной конечной точки.

Рекомендуется удалять недействующие подключения, чтобы не было ничего лишнего.

3. Убедитесь, что брандмауэр хранилища ключей настроен правильно

Важно отметить, что функция приватных ссылок предоставляет доступ к вашему хранилищу ключей только в виртуальной сети, которая закрыта для предотвращения утечки данных. Таким образом никакой уже существующий доступ не удаляется. Для эффективной блокировки доступа из общедоступного Интернета необходимо непосредственно включить брандмауэр хранилища ключей:

1. Откройте портал Azure и откройте ресурс хранилища ключей.
2. В меню слева выберите Сеть.
3. Убедитесь, что вверху выбрана вкладка Брандмауэры и виртуальные сети.
4. Если вы обнаружите, что выбрано разрешено общедоступный доступ из всех сетей, это объясняет, почему внешние клиенты по-прежнему могут получать доступ к хранилищу ключей. Если вы хотите, чтобы Key Vault был доступен только через Приватный канал, выберите Disable Public Access.

Следующие инструкции также применяются к параметрам брандмауэра:

• Для функции приватных каналов не требуется указывать виртуальную сеть в параметрах брандмауэра хранилища ключей. Все запросы, использующие частный IP-адрес хранилища ключей (см. следующий раздел), должны работать, даже если в параметрах брандмауэра хранилища ключей не указана виртуальная сеть.
• Функция приватных каналов не требует указания IP-адреса в параметрах брандмауэра хранилища ключей. Опять же, все запросы, использующие частный IP-адрес хранилища ключей, должны работать, даже если в параметрах брандмауэра не указан IP-адрес.

При использовании приватных каналов единственными причинами для указания виртуальной сети или IP-адреса в брандмауэре хранилища ключей являются:

• У вас есть гибридная система, в которой некоторые клиенты используют частные ссылки, некоторые используют конечные точки службы, некоторые используют общедоступный IP-адрес.
• Выполняется переход на приватные ссылки. В этом случае после подтверждения того, что все клиенты используют приватные каналы, следует удалить виртуальные сети и IP-адреса из параметров брандмауэра хранилища ключей.

4. Убедитесь, что для хранилища ключей указан частный IP-адрес

Различие между частными и общедоступными IP-адресами

Частный IP-адрес всегда имеет один из следующих форматов:

• 10.x.x.x (примеры: 10.1.2.3, 10.56.34.12).
• 172.16.x.x – 172.32.x.x (примеры: 172.20.1.1, 172.31.67.89).
• 192.168.x.x (примеры: 192.168.0.1, 192.168.100.7).

Некоторые IP-адреса и диапазоны зарезервированы:

• 224.x.x.x: многоадресная рассылка
• 255.255.255.255: широковещательный адрес
• 127.x.x.x: взаимообратный адрес
• 169.254.x.x: локальный адрес связи
• 168.63.129.16: внутренняя служба доменных имен

Все остальные IP-адреса являются общедоступными.

При просмотре портала или выполнении команды, которая отображает IP-адрес, убедитесь, что вы можете определить, является ли этот IP-адрес частным, общедоступным или зарезервированным. Для работы приватных ссылок имя узла хранилища ключей должно разрешаться на частный IP-адрес, принадлежащий пространству адресов виртуальной сети.

Поиск частного IP-адреса хранилища ключей в виртуальной сети

Вам потребуется диагностировать разрешение имени узла, и для этого необходимо знать точный частный IP-адрес вашего хранилища ключей с включенными приватными ссылками. Чтобы найти этот адрес, выполните следующие действия.

1. Откройте портал Azure и откройте ресурс хранилища ключей.
2. В меню слева выберите Сеть.
3. Перейдите на вкладку "Подключения к частной конечной точке ". В результирующем представлении отображаются все подключения к частной конечной точке и соответствующие состояния.
4. Найдите подключение, которое вы диагностируете, и убедитесь, что состояние подключения утверждено, а состояние подготовки завершено успешно. Если состояние отличается, вернитесь к предыдущим разделам документа.
5. Когда вы найдете нужный элемент, выберите ссылку в столбце приватной конечной точки. Действие открывает ресурс частной конечной точки.
6. На странице обзора может отображаться раздел Настраиваемые параметры DNS. Убедитесь, что существует только одна запись, соответствующая имени узла хранилища ключей. Эта запись отображает частный IP-адрес хранилища ключей.
7. Вы также можете выбрать ссылку в сетевом интерфейсе и убедиться, что частный IP-адрес совпадает с предыдущим шагом. Сетевой интерфейс — это виртуальное устройство, которое представляет Key Vault.

IP-адрес — это тот, который виртуальные машины и другие устройства, работающие в той же виртуальной сети, используют для подключения к хранилищу ключей. Запишите IP-адрес или не закрывайте эту вкладку браузера, пока проводите дальнейшие исследования.

5. Проверьте разрешение DNS

Разрешение DNS — это процесс перевода имени узла хранилища ключей (например: fabrikam.vault.azure.net) в IP-адрес (например: 10.1.2.3). В следующих подразделах показаны ожидаемые результаты разрешения DNS в каждом сценарии.

Хранилища ключей без приватной ссылки

Этот раздел предназначен для учебных целей. Если в хранилище ключей нет подключения к частной конечной точке в утвержденном состоянии, разрешение имени узла приводит к результату, аналогичному следующему:

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

Линукс:

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

Как видите, имя преобразуется в общедоступный IP-адрес, а псевдоним privatelink отсутствует. Псевдоним объясняется позже, пока что о нем не беспокойтесь.

Этот результат отображается так же, выполняется ли запрос с компьютера, подключенного к виртуальная сеть или с любого компьютера с подключением к Интернету. Результат возникает, поскольку хранилище ключей не имеет частных сетевых соединений в разрешенном состоянии, поэтому нет необходимости поддерживать частные соединения.

Хранилище ключей с разрешением приватного канала с произвольного компьютера в Интернете

Если в хранилище ключей есть одно или несколько подключений к частной конечной точке в утвержденном состоянии, и вы разрешаете имя узла с произвольного компьютера, подключенного к Интернету (компьютер, который не подключен к виртуальной сети, где находится частная конечная точка), вы получите результат, аналогичный этому:

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

Линукс:

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

Важным отличием от предыдущего сценария является наличие нового псевдонима со значением {vaultname}.privatelink.vaultcore.azure.net. Плоскость данных хранилища ключей готова принимать запросы из частных ссылок.

Это не означает, что запросы, выполненные с компьютеров за пределами виртуальной сети (например, того, который вы только что использовали), используют частные ссылки — они этого не делают. Это подтверждается тем, что имя хоста по-прежнему преобразуется в общедоступный IP-адрес. Только компьютеры подключены к виртуальная сеть могут использовать закрытые ссылки.

Если псевдоним privatelink не отображается, это означает, что в хранилище ключей нет подключений к частным конечным точкам в состоянии Approved. Вернитесь к этому разделу перед повторной попыткой.

Хранилище ключей с приватным соединением из виртуальной сети

Если хранилище ключей имеет одно или несколько подключений к частной конечной точке в утвержденном состоянии, и вы разрешаете имя узла с компьютера, подключенного к виртуальная сеть, где была создана частная конечная точка, это ожидаемый ответ:

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

Линукс:

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

Существует два существенных отличия. Первое: имя преобразуется в частный IP-адрес. Это должен быть IP-адрес, который мы определили в соответствующем разделе этой статьи. Второе: после privatelink нет никаких других псевдонимов. Это происходит потому, что виртуальная сеть DNS-серверы перехватывают цепочку псевдонимов и возвращают частный IP-адрес непосредственно из имени fabrikam.privatelink.vaultcore.azure.net. Эта запись фактически является записью A в зоне Частная зона DNS.

Если вы выполняете эти команды на виртуальной машине, подключенной к виртуальной сети, где была создана частная конечная точка, и они не показывают частный IP-адрес хранилища ключей, следующий раздел может помочь устранить проблему.

6. Проверка зоны Частная зона DNS

Если разрешение DNS не работает, как описано в предыдущем разделе, может возникнуть проблема с зоной Частная зона DNS, и этот раздел может помочь. Если разрешение DNS показывает правильный частный IP-адрес хранилища ключей, вероятно, ваша частная зона DNS настроена правильно. Весь этот раздел можно пропустить.

Убедитесь, что необходимый ресурс зоны Частная зона DNS существует

Подписка Azure должна иметь ресурс Частная зона DNS Zone с таким точным именем:

privatelink.vaultcore.azure.net

Чтобы проверить наличие этого ресурса, перейдите на страницу подписки на портале и выберите в меню слева пункт "Ресурсы". Имя ресурса должно быть privatelink.vaultcore.azure.net, а тип ресурса должен быть Частная зона DNS зона.

Обычно этот ресурс создается автоматически при создании частной конечной точки с помощью общей процедуры. Но бывают случаи, когда этот ресурс не создается автоматически, и эту процедуру необходимо выполнить вручную. Также этот ресурс мог быть случайно удален.

Если у вас нет этого ресурса, создайте в подписке новый ресурс Частная зона DNS Zone. Помните, что имя должно быть точно privatelink.vaultcore.azure.net, без пробелов или дополнительных точек. Если указать неправильное имя, разрешение имен, описанное в этой статье, завершается ошибкой. Для получения дополнительной информации о том, как создать этот ресурс, см. статью Создание приватной зоны Azure DNS с помощью портала Azure. Если вы следуете инструкциям на этой странице, вы можете пропустить создание виртуальной сети, так как на этом этапе у вас уже должна быть одна. Также можно пропустить процедуры проверки с помощью Виртуальные машины.

Убедитесь, что зона Частная зона DNS связана с виртуальная сеть

Недостаточно иметь зону Частная зона DNS. Она также должна быть связана с виртуальная сеть, содержащей частную конечную точку. Если зона Частная зона DNS не связана с правильным виртуальная сеть, любое разрешение DNS из этого виртуальная сеть будет игнорировать зону Частная зона DNS.

Откройте ресурс зоны Частная зона DNS и выберите пункт Сетевые ссылки в меню слева. Вы увидите список ссылок, каждая из которых содержит имя виртуальной сети в вашей подписке. Здесь должна быть указана виртуальная сеть, содержащая ресурс частной конечной точки. Если она отсутствует, добавьте ее. Подробные инструкции см. в разделе Связывание виртуальной сети. Вы можете не устанавливать флажок "Включить авторегистрацию", поскольку эта функция не связана с приватными каналами.

После того как зона Частная зона DNS связана с виртуальная сеть, все запросы DNS, поступающие из этой сети, автоматически проверяют эту частную зону для разрешения имен. Эта компоновка необходима для виртуальных машин в той же виртуальной сети, что и частная конечная точка, чтобы правильно разрешать имя узла хранилища ключей на его частный IP-адрес, а не на общедоступный адрес.

Убедитесь, что зона Частная зона DNS содержит правильную запись A

На портале откройте зону Частная зона DNS с именем privatelink.vaultcore.azure.net. На странице "Обзор" отображаются все записи. По умолчанию существует одна запись с именем @ и типом SOA, что означает начало авторитетной информации. Не трогайте ее.

Для работы разрешения имен хранилища ключей должна существовать запись A с простым именем хранилища без суффикса или точек. Например, если имя узла — fabrikam.vault.azure.net, то должна существовать запись A с именем fabrikam (без суффикса или точек).

Кроме того, значение записи A (IP-адрес) должно быть частным IP-адресом хранилища ключей. Если вы нашли запись A, но она содержит неправильный IP-адрес, необходимо удалить этот IP-адрес и добавить новый. Рекомендуется удалить всю A запись и добавить новую.

Разрешение DNS для более чем одной виртуальной сети

Если существует несколько виртуальных сетей и у каждой из них есть собственная частная конечная точка, ссылающаяся на одно и то же хранилище ключей, имя узла хранилища ключей должно преобразовываться в другой частный IP-адрес в зависимости от сети. Это означает, что требуются несколько зон Частная зона DNS, каждая из которых связана с разными виртуальная сеть и использует другой IP-адрес в записи A.

В более сложных сценариях для виртуальных сетей может быть включен пиринг. В этом случае для ресурса «Private Endpoint» требуется только один «виртуальная сеть», хотя оба ресурса могут быть связаны с ресурсом зоны «Частная зона DNS». Этот сценарий не рассматривается напрямую в этом документе.

Поймите, что вы имеете контроль над разрешением DNS

Как описано в предыдущем разделе, хранилище ключей с приватными ссылками имеет псевдоним {vaultname}.privatelink.vaultcore.azure.net в публичной регистрации. DNS-сервер, используемый виртуальной сетью, использует общедоступную регистрацию, но проверяет каждый псевдоним на наличие частной регистрации, и если таковая найдена, он перестает обрабатывать псевдонимы, определенные при общедоступной регистрации.

Эта логика означает, что если Виртуальная сеть связана с зоной Частная зона DNS с именем privatelink.vaultcore.azure.net, и общедоступная регистрация DNS для хранилища ключей имеет псевдоним fabrikam.privatelink.vaultcore.azure.net (обратите внимание, что суффикс имени узла хранилища ключей соответствует имени зоны Частная зона DNS), то dns-запрос ищет запись A с именем fabrikam в зоне Частная зона DNS. Если запись A найдена, ее IP-адрес возвращается в запросе DNS и дальнейший поиск в публичной регистрации DNS не выполняется.

Как видите, разрешение имен находится под вашим контролем. Обоснование этого дизайна заключается в следующем:

• У вас может быть сложный сценарий, включающий пользовательские DNS-серверы и интеграцию с локальными сетями. В этом случае вы должны решать, каким образом имена преобразуются в IP-адреса.
• Может потребоваться доступ к хранилищу ключей без приватных каналов. В этом случае разрешение имени узла из виртуальной сети должно возвращать общедоступный IP-адрес, так как хранилища ключей без частных соединений не имеют псевдонима privatelink при регистрации имен.

7. Убедитесь, что запросы к хранилищу ключей используют приватный канал

Запросите конечную точку хранилища ключей /healthstatus

Ваше хранилище ключей предоставляет конечную точку /healthstatus, которую можно использовать для диагностики. Заголовки ответов включают исходный IP-адрес, как показано в службе хранилища ключей. Эту конечную точку можно вызвать с помощью следующей команды (используйте имя узла вашего хранилища ключей):

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 или последняя версия Windows 10, которая включает 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

Если вы не получаете подобный результат или если ответ содержит сетевую ошибку, значит хранилище ключей не доступно через указанное имя узла (в примере это fabrikam.vault.azure.net). Имя узла не преобразуется в правильный IP-адрес или возникла ошибка подключения на транспортном уровне. Это может быть вызвано проблемами маршрутизации, отбрасыванием пакетов и другими причинами. Вам необходимо продолжить анализ.

Ответ должен включать заголовок x-ms-keyvault-network-info:

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

Поле addr в заголовке x-ms-keyvault-network-info показывает IP-адрес источника запроса. IP-адресом может быть один из следующих адресов:

• Частный IP-адрес компьютера, выполняющего запрос. Это означает, что запрос использует приватные каналы или конечные точки службы. Это ожидаемый результат для приватных каналов.
• Какой-либо другой частный IP-адрес, который не принадлежит компьютеру, выполняющему запрос. Это означает, что действует пользовательская маршрутизация. Это все еще говорит о том, что запрос использует приватные каналы или конечные точки службы.
• Общедоступный IP-адрес. Это означает, что запрос направляется в Интернет через устройство шлюза (NAT). Это означает, что запрос НЕ использует приватные каналы, и некоторые проблемы необходимо исправить. Распространенные причины: 1) частная конечная точка не находится в утвержденном и выполненном состоянии; и 2) имя узла не преобразуется в частный IP-адрес хранилища ключей. В этой статье содержатся действия по устранению неполадок в обоих случаях.

Запрос IP-адреса хранилища ключей напрямую

Если у вас установлена последняя версия PowerShell, вы можете использовать -SkipCertificateCheck для пропуска проверок HTTPS-сертификатов, после чего можно будет напрямую использовать целевой IP адрес хранилища ключей:

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

Если вы используете curl, то можете сделать то же самое с помощью аргумента -k:

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

Ответ должен быть аналогичен ответу из предыдущего раздела, что означает, что он должен включать заголовок x-ms-keyvault-network-info с тем же значением. Для конечной точки /healthstatus не важно, используете вы имя узла или IP-адрес хранилища ключей.

Если вы видите, что x-ms-keyvault-network-info возвращает одно значение для запроса, используя имя узла хранилища ключей, и другое для запроса с использованием IP-адреса, значит запросы используют разные целевые конечные точки. Ознакомьтесь с описанием поля addr из x-ms-keyvault-network-info в предыдущем разделе, чтобы определить, что является неправильным и нуждается в исправлении.

8. Другие изменения и настройки, приводящие к последствиям

Следующие пункты не являются полным перечнем действий для расследования. Они направят вас на место поиска дополнительных проблем, но для их устранения в этих сценариях понадобятся глубокие сетевые знания.

Диагностика пользовательских DNS-серверов на виртуальная сеть

На портале откройте ресурс виртуальная сеть. В меню слева откройте DNS-серверы. Если вы используете "Пользовательский", то разрешение DNS может отличаться от описанного в этом документе. Необходимо определить, как DNS-серверы преобразовывают имя узла хранилища ключей.

Если вы используете DNS-серверы, предоставляемые по умолчанию Azure, это применимо ко всему документу.

Диагностика хостов, использующих переопределенные или настраиваемые DNS-серверы на виртуальной машине.

Многие операционные системы позволяют задавать явный фиксированный IP-адрес для каждого имени узла, как правило, путем изменения файла hosts. Также можно разрешить переопределение DNS-серверов. Если вы используете один из этих сценариев, перейдите к характерным для вашей системы параметрам диагностики.

Неизбирательные прокси-серверы (Fiddler и т. д.)

Кроме случаев, когда это явно указано, параметры диагностики в этой статье работают только тогда, когда в среде нет неизбирательного прокси-сервера. Хотя эти прокси-серверы часто устанавливаются исключительно на проверяемом компьютере (Fiddler является наиболее распространенным примером), опытные администраторы могут перезаписывать корневые центры сертификации и установить неизбирательный прокси-сервер на устройства шлюзов, обслуживающие несколько компьютеров в сети. Эти прокси-серверы могут существенно сказаться на безопасности и надежности. Майкрософт не поддерживает конфигурации, использующие такие продукты.

Другие детали, которые могут повлиять на подключение

Следующий список элементов, которые можно найти в расширенных или сложных сценариях, не является исчерпывающим:

• Параметры брандмауэра, будь то Брандмауэр Azure, подключенный к виртуальной сети, или пользовательское решение брандмауэра, развернутое в виртуальной сети или на компьютере.
• Пиринг сети, который может повлиять на используемые DNS-серверы и способ маршрутизации трафика.
• Решения для пользовательского шлюза (NAT), которые могут повлиять на маршрутизацию трафика, включая трафик от DNS-запросов.

Дальнейшие шаги

• Интегрируйте Key Vault с помощью Приватный канал Azure
• Настройка сетевой безопасности для Azure Key Vault
• Обеспечьте защиту Azure Key Vault