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

Введение

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

Если вы не знакомы с этой функцией, см. статью Интеграция Key Vault с помощью приватного канала Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Для функции приватных каналов не требуется указывать виртуальную сеть в параметрах брандмауэра хранилища ключей. Все запросы, использующие частный 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 в каждом сценарии.

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

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

Виндоус:

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 отсутствует. Псевдоним объясняется позже, пока что о нем не беспокойтесь.

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

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

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

Виндоус:

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. Вернитесь к этому разделу перед повторной попыткой.

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

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

Виндоус:

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 с таким же именем:

privatelink.vaultcore.azure.net

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

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

Если у вас нет этого ресурса, создайте новый ресурс "Частная зона DNS" в подписке. Помните, что имя должно быть точно privatelink.vaultcore.azure.net, без пробелов или дополнительных точек. Если указать неправильное имя, разрешение имен, описанное в этой статье, завершается ошибкой. Дополнительные сведения о создании этого ресурса см. в статье Создание частной зоны DNS Azure на портале 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.

В более сложных сценариях для виртуальных сетей может быть включен пиринг. В этом случае только одной виртуальной сети требуется ресурс частной конечной точки, хотя может потребоваться связать каждую из них с ресурсом частной зоны 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 Private Link
• Настройка сетевой безопасности для Azure Key Vault
• Обеспечьте безопасность Azure Key Vault