Поделиться через

Диагностика проблем с конфигурацией Приватных каналов в 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, который существует независимо от виртуальной сети клиента. Примерами таких сценариев являются служба хранилища Azure или Azure SQL, настроенная для шифрования неактивных данных, Центры событий Azure шифрование данных с помощью ключей, предоставленных клиентом, Фабрика данных Azure доступ к учетным данным службы, хранящимся в хранилище ключей, Azure Pipelines, извлечение секретов из хранилища ключей и другие аналогичные сценарии. В таких случаях необходимо проверить, поддерживаются ли продуктом хранилища ключей с включенным брандмауэром. Эта поддержка обычно выполняется с помощью функции Доверенные службы брандмауэра хранилища ключей. Однако многие продукты не включены в список доверенных служб по различным причинам. В этом случае обратитесь в службу поддержки конкретного продукта.

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

Как видите, имя преобразуется в общедоступный 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

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

Важным отличием от предыдущего сценария является наличие нового псевдонима со значением {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

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

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

Примечание

Приведенный выше результат возможен только на виртуальной машине, подключенной к виртуальной сети, в которой была создана частная конечная точка. Если у вас нет виртуальной машины, развернутой в виртуальной сети с частной конечной точкой, разверните ее и подключитесь к ней удаленно, затем выполните команду nslookup (Windows) или host (Linux) выше.

Если при выполнении этих команд на виртуальной машине, подключенной к виртуальной сети, в которой была создана частная конечная точка, не отображается частный 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, исходящие из виртуальной сети, будут искать имена в этой частной зоне DNS. Это необходимо для правильного разрешения адресов, выполняемых на виртуальных машинах, подключенных к виртуальной сети, в которой была создана частная конечная точка.

Примечание

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

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

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

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

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

Примечание

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

Разрешение 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 в регистрации имени.

Запросите конечную точку /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-адрес хранилища ключей. В этой статье содержатся действия по устранению неполадок в обоих случаях.

Примечание

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

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

Важно!

Доступ к хранилищу ключей без проверки сертификата HTTPS является опасным, и его можно использовать только в целях обучения. Рабочий код НИКОГДА не должен получать доступ к хранилищу ключей без проверки на стороне клиента. Даже если вы просто диагностируете проблемы, вы можете подвергнуться попыткам незаконного изменения, которые не будут обнаружены при частом отключении проверки сертификата HTTPS в запросах к хранилищу ключей.

Если у вас установлена последняя версия 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.