Подключение устройств Azure IoT Edge для создания иерархии

Область применения: IoT Edge 1.5

В этой статье объясняется, как установить надежное подключение между шлюзом IoT Edge и подчиненным устройством IoT Edge. Эта конфигурация называется вложенным краем.

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

В этой статье рассматриваются две конфигурации для устройств IoT Edge в иерархии шлюза. Первым расположено устройство IoT Edge верхнего уровня. Когда несколько устройств IoT Edge подключаются друг к другу, любое устройство, которое не имеет родительского устройства, но подключается непосредственно к Центр Интернета вещей считается в верхнем слое. Это устройство отвечает за обработку запросов со всех устройств, расположенных под ним. Вторая конфигурация применяется к любому устройству IoT Edge на более низком уровне иерархии. Эти устройства могут быть шлюзом для других подчиненных устройств Интернета вещей и IoT Edge, но также должны направлять любые коммуникации через собственные родительские устройства.

Для некоторых сетевых архитектур требуется, чтобы только верхнее устройство IoT Edge в иерархии могло подключаться к облаку. В этой конфигурации все устройства IoT Edge в более низких уровнях иерархии могут взаимодействовать только со своим устройством шлюза (родительским) и любыми дочерними (дочерними) устройствами.

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

• Проверка подлинности. Создайте удостоверения центра Интернета вещей для всех устройств в иерархии шлюзов.
• Авторизация: настройте связь родительского или дочернего устройства в Центр Интернета вещей, чтобы авторизовать подчиненные устройства для подключения к родительскому устройству, как они будут подключаться к Центр Интернета вещей.
• Обнаружение шлюза: убедитесь, что нижнее устройство может найти родительское устройство в локальной сети.
• Безопасное подключение. Установите безопасное соединение с доверенными сертификатами, которые являются частью одной цепочки.

Необходимые компоненты

• Центр Интернета вещей уровня "Бесплатный" или "Стандартный".
• По крайней мере два устройства IoT Edge, одно из которых будет устройством верхнего уровня, а остальные — более низкого уровня. Если у вас нет доступных устройств IoT Edge, вы можете запустить Azure IoT Edge на виртуальных машинах Ubuntu.
• Если вы используете Azure CLI для создания устройств и управления ими, установите расширение Azure IoT.

Создание иерархии шлюзов

Иерархия шлюзов IoT Edge создается путем определения отношений "родитель-потомок" для устройств IoT Edge в сценарии. Вы можете задать родительское устройство при создании нового удостоверения устройства или управлять родительскими и дочерними устройствами существующего удостоверения устройства.

Шаг настройки отношений "родительский или дочерний" разрешает подчиненным устройствам подключаться к родительскому устройству, как они будут подключаться к Центр Интернета вещей.

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

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

Создание сертификатов

Для установления безопасного взаимодействия между ними необходимо установить согласованную цепочку сертификатов на устройствах в одной иерархии шлюзов. Каждое устройство в иерархии, независимо от того, требуется ли устройство IoT Edge или нижнее устройство Интернета вещей, копия одного корневого сертификата ЦС. Затем каждое устройство IoT Edge в иерархии использует этот корневой сертификат ЦС в качестве корневого сертификата ЦС для пограничного ЦС.

С помощью этой установки каждое нижнее устройство IoT Edge может проверить удостоверение родительского устройства, убедившись, что edgeHub , к которому они подключаются, имеет сертификат сервера, подписанный общим корневым сертификатом ЦС.

Дополнительные сведения о требованиях к сертификату IoT Edge см. в статье о том, как Azure IoT Edge использует сертификаты.

1. Создайте или запросите следующие сертификаты:

   • Корневой сертификат ЦС, который является самым верхним общим сертификатом для всех устройств в данной иерархии шлюзов. Этот сертификат устанавливается на всех устройствах.
   • Все промежуточные сертификаты, которые необходимо включить в цепочку корневых сертификатов.
   • Сертификат ЦС Edge и его закрытый ключ, созданные корневыми и промежуточными сертификатами. Для каждого устройства IoT Edge в иерархии шлюза требуется один уникальный сертификат ЦС Edge.

   Вы можете использовать самозаверяющий центр сертификации или приобрести один из доверенных коммерческих центров сертификации, таких как Baltimore, VeriSign, DigiCert или GlobalSign.

2. Если у вас нет собственных сертификатов для тестирования, создайте один набор корневых и промежуточных сертификатов, а затем создайте сертификаты ЦС Edge для каждого устройства. Например, эти команды создают корневой сертификат ЦС, родительский сертификат устройства и дочерний сертификат устройства.

   # !!! For test only - do not use in production !!!
   
   # Create the the root CA test certificate
   ./certGen.sh create_root_and_intermediate
   
   # Create the parent (gateway) device test certificate 
   # signed by the shared root CA certificate
   ./certGen.sh create_edge_device_ca_certificate "gateway"
   
   # Create the downstream device test certificate
   # signed by the shared root CA certificate
   ./certGen.sh create_edge_device_ca_certificate "downstream"
   

   Предупреждение

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

   Дополнительные сведения о создании тестовых сертификатов см. в статье о создании демонстрационных сертификатов для тестирования функций устройств IoT Edge.

3. Вам потребуется передать сертификаты и ключи каждому устройству. Вы можете использовать USB-диск, службу, например Azure Key Vault, или функцию, например безопасную копию файлов. Выберите один из этих методов, которые лучше всего соответствуют вашему сценарию. Скопируйте файлы в предпочтительный каталог для сертификатов и ключей. Используется /var/aziot/certs для сертификатов и /var/aziot/secrets ключей.

Дополнительные сведения об установке сертификатов на устройстве см. в разделе "Управление сертификатами" на устройстве IoT Edge.

Настройка родительского устройства

Чтобы настроить родительское устройство, откройте локальную или удаленную командную оболочку.

Чтобы обеспечить безопасные подключения, каждому родительскому устройству IoT Edge в сценарии шлюза необходимо настроить с уникальным сертификатом ЦС Edge и копией корневого сертификата ЦС, доступного всем устройствам в иерархии шлюза.

1. Проверьте сертификаты в соответствии с требованиями к формату.

2. Передайте корневой сертификат ЦС, родительский сертификат ЦС Edge и родительский закрытый ключ на родительское устройство.

3. Скопируйте сертификаты и ключи в правильные каталоги. Предпочтительный каталог для сертификатов устройств — /var/aziot/certs для сертификатов и /var/aziot/secrets ключей.

   ### Copy device certificate ###
   
   # If the device certificate and keys directories don't exist, create, set ownership, and set permissions
   sudo mkdir -p /var/aziot/certs
   sudo chown aziotcs:aziotcs /var/aziot/certs
   sudo chmod 755 /var/aziot/certs
   
   sudo mkdir -p /var/aziot/secrets
   sudo chown aziotks:aziotks /var/aziot/secrets
   sudo chmod 700 /var/aziot/secrets
   
   # Copy full-chain device certificate and private key into the correct directory
   sudo cp iot-edge-device-ca-gateway-full-chain.cert.pem /var/aziot/certs
   sudo cp iot-edge-device-ca-gateway.key.pem /var/aziot/secrets
   
   ### Root certificate ###
   
   # Copy root certificate into the /certs directory
   sudo cp azure-iot-test-only.root.ca.cert.pem /var/aziot/certs
   
   # Copy root certificate into the CA certificate directory and add .crt extension.
   # The root certificate must be in the CA certificate directory to install it in the certificate store.
   # Use the appropriate copy command for your device OS or if using EFLOW.
   
   # For Ubuntu and Debian, use /usr/local/share/ca-certificates/
   sudo cp azure-iot-test-only.root.ca.cert.pem /usr/local/share/azure-iot-test-only.root.ca.cert.pem.crt
   # For EFLOW, use /etc/pki/ca-trust/source/anchors/
   sudo cp azure-iot-test-only.root.ca.cert.pem /etc/pki/ca-trust/source/anchors/azure-iot-test-only.root.ca.pem.crt
   

4. Измените владение и разрешения сертификатов и ключей.

   # Give aziotcs ownership to certificates
   # Read and write for aziotcs, read-only for others
   sudo chown -R aziotcs:aziotcs /var/aziot/certs
   sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;
   
   # Give aziotks ownership to private keys
   # Read and write for aziotks, no permission for others
   sudo chown -R aziotks:aziotks /var/aziot/secrets
   sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;
   
   # Verify permissions of directories and files
   sudo ls -Rla /var/aziot
   

   Выходные данные списка с правильным владением и разрешением аналогичны следующим:

   azureUser@vm:/var/aziot$ sudo ls -Rla /var/aziot
   /var/aziot:
   total 16
   drwxr-xr-x  4 root    root    4096 Dec 14 00:16 .
   drwxr-xr-x 15 root    root    4096 Dec 14 00:15 ..
   drwxr-xr-x  2 aziotcs aziotcs 4096 Jan 14 00:31 certs
   drwx------  2 aziotks aziotks 4096 Jan 23 17:23 secrets
   
   /var/aziot/certs:
   total 20
   drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 .
   drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
   -rw-r--r-- 1 aziotcs aziotcs 1984 Jan 14 00:24 azure-iot-test-only.root.ca.cert.pem
   -rw-r--r-- 1 aziotcs aziotcs 5887 Jan 14 00:27 iot-edge-device-ca-gateway-full-chain.cert.pem
   
   /var/aziot/secrets:
   total 16
   drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 .
   drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
   -rw------- 1 aziotks aziotks 3243 Jan 14 00:28 iot-edge-device-ca-gateway.key.pem
   

5. Установите сертификат корневого ЦС на родительском устройстве IoT Edge, обновив хранилище сертификатов на устройстве с помощью команды для конкретной платформы.

   # Update the certificate store
   
   # For Ubuntu or Debian - use update-ca-certificates
   sudo update-ca-certificates
   # For EFLOW or RHEL - use update-ca-trust
   sudo update-ca-trust
   

   Дополнительные сведения об использовании update-ca-trust в EFLOW см. в разделе CBL-Mariner SSL CERTIFICATEs management.

Команда сообщает, что в нее добавлен /etc/ssl/certsодин сертификат.

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Обновление родительского файла конфигурации

На устройстве уже должен быть установлен IoT Edge. Если нет, выполните действия, чтобы вручную подготовить одно устройство Linux IoT Edge.

1. Убедитесь, что /etc/aziot/config.toml файл конфигурации существует на родительском устройстве.

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

   sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
   

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

2. Откройте файл конфигурации IoT Edge с помощью редактора. Например, используйте nano редактор для открытия /etc/aziot/config.toml файла.

   sudo nano /etc/aziot/config.toml
   

3. Найдите параметр имени узла или добавьте его в начало файла конфигурации. Обновите значение, чтобы иметь полное доменное имя (FQDN) или IP-адрес родительского устройства IoT Edge. Например:

   hostname = "10.0.0.4"
   

   Чтобы включить обнаружение шлюза, каждому устройству-шлюзу IoT Edge (родительскому) необходимо указать параметр имя узла, который его дочерние устройства используют для поиска его в локальной сети. Каждому нижнему устройству IoT Edge необходимо указать параметр parent_hostname для идентификации родительского элемента. В иерархическом сценарии, в котором одно устройство IoT Edge является родительским и дочерним, оно требует обоих параметров.

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

   Используйте имя узла короче 64 символов — это лимит для общего имени сертификата сервера.

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

   Задайте имя узла перед созданием контейнера edgeHub . Если edgeHub запущен, изменение имени узла в файле конфигурации не вступит в силу до повторного создания контейнера. Дополнительные сведения о том, как проверить применение имени узла, см. в разделе "Проверка родительской конфигурации ".

4. Найдите параметр сертификата пакета доверия или добавьте его в начало файла конфигурации.

   trust_bundle_cert Обновите параметр с помощью URI файла до корневого сертификата ЦС на устройстве. Например:

   trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
   

5. Найдите или добавьте раздел сертификата ЦС Edge в файле конфигурации. Обновите параметры сертификата cert и закрытого ключа pk с помощью путей URI файла для полноцепочки сертификатов и файлов ключей на родительском устройстве IoT Edge. IoT Edge требует, чтобы сертификат и закрытый ключ были в текстовом формате электронной почты ( PEM). Например:

   [edge_ca]
   cert = "file:///var/aziot/certs/iot-edge-device-ca-gateway-full-chain.cert.pem"
   pk = "file:///var/aziot/secrets/iot-edge-device-ca-gateway.key.pem"
   

6. Убедитесь, что устройство IoT Edge использует правильную версию агента IoT Edge при запуске. Найдите раздел агента Edge по умолчанию и задайте значение изображения для IoT Edge версии 1.5. Например:

   [agent]
   name = "edgeAgent"
   type = "docker"
   
   [agent.config]
   image = "mcr.microsoft.com/azureiotedge-agent:1.5"
   

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

   hostname = "10.0.0.4"
   trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
   
   [edge_ca]
   cert = "file:///var/aziot/certs/iot-edge-device-ca-gateway-full-chain.cert.pem"
   pk = "file:///var/aziot/secrets/iot-edge-device-ca-gateway.key.pem"
   

8. Сохраните config.toml и закройте файл конфигурации. Например, если вы используете редактор nano, выберите , - и Exit.

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

   • /var/lib/aziot/certd/certs
   • /var/lib/aziot/keyd/keys

10. Примените изменения.

    sudo iotedge config apply
    

11. Проверьте конфигурацию на наличие ошибок.

    sudo iotedge check --verbose
    

    Примечание.

    На новом настроенном устройстве может появиться ошибка, связанная с IoT Edge Hub.

    × рабочей готовности: каталог хранилища Edge Hub сохраняется в файловой системе узла — ошибка

    Не удалось проверить текущее состояние контейнера edgeHub

    Эта ошибка ожидается на недавно подготовленном устройстве, так как модуль Центра Интернета вещей не запущен. Чтобы устранить ошибку, в Центр Интернета вещей задайте модули для устройства и создайте развертывание. Создание развертывания для устройства запускает модули на устройстве, включая модуль Центра IoT Edge.

Проверка родительской конфигурации

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

Чтобы проверить имя узла, необходимо проверить переменные среды контейнера edgeHub .

1. Перечислите запущенные контейнеры IoT Edge.

   iotedge list
   

   Убедитесь, что запущены контейнеры edgeAgent и edgeHub . Выходные данные команды должны быть похожи на следующий пример.

   NAME                        STATUS           DESCRIPTION      CONFIG
   SimulatedTemperatureSensor  running          Up 5 seconds     mcr.microsoft.com/azureiotedge-simulated-temperature-sensor:1.0
   edgeAgent                   running          Up 17 seconds    mcr.microsoft.com/azureiotedge-agent:1.5
   edgeHub                     running          Up 6 seconds     mcr.microsoft.com/azureiotedge-hub:1.5
   

2. Проверьте контейнер edgeHub.

   sudo docker inspect edgeHub
   

3. В выходных данных найдите параметр EdgeDeviceHostName в разделе Env .

   "EdgeDeviceHostName=10.0.0.4"
   

4. Убедитесь, что значение параметра EdgeDeviceHostName соответствует параметру config.tomlимени узла. Если он не соответствует, контейнер edgeHub выполнялся при изменении и применении конфигурации. Чтобы обновить EdgeDeviceHostName, удалите контейнер edgeAgent .

   sudo docker rm -f edgeAgent
   

   Контейнеры edgeAgent и edgeHub создаются и запускаются в течение нескольких минут. После запуска контейнера EdgeHub проверьте контейнер и убедитесь , что параметр EdgeDeviceHostName соответствует файлу конфигурации.

Настройка нижестоящего устройства

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

Чтобы обеспечить безопасные подключения, каждому нижнему устройству IoT Edge в сценарии шлюза необходимо настроить с уникальным сертификатом ЦС Edge и копией корневого сертификата ЦС, совместно используемого всеми устройствами в иерархии шлюза.

1. Проверьте сертификаты в соответствии с требованиями к формату.

2. Передайте сертификат корневого ЦС, дочерний сертификат ЦС edge и дочерний закрытый ключ на нижнее устройство.

3. Скопируйте сертификаты и ключи в правильные каталоги. Предпочтительный каталог для сертификатов устройств — /var/aziot/certs для сертификатов и /var/aziot/secrets ключей.

   ### Copy device certificate ###
   
   # If the device certificate and keys directories don't exist, create, set ownership, and set permissions
   sudo mkdir -p /var/aziot/certs
   sudo chown aziotcs:aziotcs /var/aziot/certs
   sudo chmod 755 /var/aziot/certs
   
   sudo mkdir -p /var/aziot/secrets
   sudo chown aziotks:aziotks /var/aziot/secrets
   sudo chmod 700 /var/aziot/secrets
   
   # Copy device full-chain certificate and private key into the correct directory
   sudo cp iot-device-downstream-full-chain.cert.pem /var/aziot/certs
   sudo cp iot-device-downstream.key.pem /var/aziot/secrets
   
   ### Root certificate ###
   
   # Copy root certificate into the /certs directory
   sudo cp azure-iot-test-only.root.ca.cert.pem /var/aziot/certs
   
   # Copy root certificate into the CA certificate directory and add .crt extension.
   # The root certificate must be in the CA certificate directory to install it in the certificate store.
   # Use the appropriate copy command for your device OS or if using EFLOW.
   
   # For Ubuntu and Debian, use /usr/local/share/ca-certificates/
   sudo cp azure-iot-test-only.root.ca.cert.pem /usr/local/share/azure-iot-test-only.root.ca.cert.pem.crt
   # For EFLOW, use /etc/pki/ca-trust/source/anchors/
   sudo cp azure-iot-test-only.root.ca.cert.pem /etc/pki/ca-trust/source/anchors/azure-iot-test-only.root.ca.pem.crt
   

4. Измените владение и разрешения сертификатов и ключей.

   # Give aziotcs ownership to certificates
   # Read and write for aziotcs, read-only for others
   sudo chown -R aziotcs:aziotcs /var/aziot/certs
   sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;
   
   # Give aziotks ownership to private keys
   # Read and write for aziotks, no permission for others
   sudo chown -R aziotks:aziotks /var/aziot/secrets
   sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;
   

5. Установите корневой сертификат ЦС на нижнем устройстве IoT Edge, обновив хранилище сертификатов на устройстве с помощью команды для конкретной платформы.

   # Update the certificate store
   
   # For Ubuntu or Debian - use update-ca-certificates
   sudo update-ca-certificates
   # For EFLOW or RHEL - use update-ca-trust
   sudo update-ca-trust
   

   Дополнительные сведения об использовании update-ca-trust в EFLOW см. в разделе CBL-Mariner SSL CERTIFICATEs management.

Команда сообщает, что в нее добавлен /etc/ssl/certsодин сертификат.

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Обновление нижестоящего файла конфигурации

На устройстве уже должен быть установлен IoT Edge. Если нет, выполните действия, чтобы вручную подготовить одно устройство Linux IoT Edge.

1. Убедитесь, что /etc/aziot/config.toml файл конфигурации существует на нижнем устройстве.

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

   sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
   

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

2. Откройте файл конфигурации IoT Edge с помощью редактора. Например, используйте nano редактор для открытия /etc/aziot/config.toml файла.

   sudo nano /etc/aziot/config.toml
   

3. Найдите параметр parent_hostname или добавьте его в начало файла конфигурации Каждый подчиненный устройство IoT Edge, чтобы указать параметр parent_hostname для идентификации родительского элемента. parent_hostname Обновите параметр, чтобы быть полным доменным именем или IP-адресом родительского устройства, совпадая с именем узла в файле конфигурации родительского устройства. Например:

   parent_hostname = "10.0.0.4"
   

4. Найдите параметр сертификата пакета доверия или добавьте его в начало файла конфигурации.

   trust_bundle_cert Обновите параметр с помощью URI файла до корневого сертификата ЦС на устройстве. Например:

   trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
   

5. Найдите или добавьте раздел сертификата ЦС Edge в файл конфигурации. Обновите параметры сертификата cert и закрытого ключа pk с помощью путей URI файла для полного цепочки сертификатов и файлов ключей на нижнем устройстве IoT Edge. IoT Edge требует, чтобы сертификат и закрытый ключ были в текстовом формате электронной почты ( PEM). Например:

   [edge_ca]
   cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem"
   pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"
   

6. Убедитесь, что устройство IoT Edge использует правильную версию агента IoT Edge при запуске. Найдите раздел агента Edge по умолчанию и задайте значение изображения для IoT Edge версии 1.5. Например:

   [agent]
   name = "edgeAgent"
   type = "docker"
   
   [agent.config]
   image: "mcr.microsoft.com/azureiotedge-agent:1.5"
   

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

   parent_hostname = "10.0.0.4"
   trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
   
   [edge_ca]
   cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem"
   pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"
   

8. Сохраните config.toml и закройте файл конфигурации. Например, если вы используете редактор nano, выберите , - и Exit.

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

   • /var/lib/aziot/certd/certs
   • /var/lib/aziot/keyd/keys

10. Примените изменения.

    sudo iotedge config apply
    

11. Проверьте конфигурацию на наличие ошибок.

    sudo iotedge check --verbose
    

    Совет

    Средство проверки IoT Edge использует контейнер для выполнения некоторых диагностических проверок. Если вы хотите использовать это средство на подчиненных устройствах IoT Edge, убедитесь, что у них есть доступ к mcr.microsoft.com/azureiotedge-diagnostics:latest или в частном реестре контейнеров есть образ контейнера.

    Примечание.

    На недавно подготовленном устройстве может появиться ошибка, связанная с IoT Edge Hub.

    × рабочей готовности: каталог хранилища Edge Hub сохраняется в файловой системе узла — ошибка

    Не удалось проверить текущее состояние контейнера edgeHub

    Эта ошибка ожидается на недавно подготовленном устройстве, так как модуль Центра Интернета вещей не запущен. Чтобы устранить ошибку, в Центр Интернета вещей задайте модули для устройства и создайте развертывание. Создание развертывания для устройства запускает модули на устройстве, включая модуль Центра IoT Edge.

Сетевая изоляция подчиненных устройств

С помощью действий, приведенных в этой статье, вы настроили устройства IoT Edge в качестве шлюза или подчиненного устройства и создали доверительное соединение между ними. Устройство шлюза обрабатывает взаимодействие между подчиненным устройством и центром Интернета вещей, включая проверку подлинности и маршрутизацию сообщений. Модули, развернутые на подчиненных устройствах IoT Edge, по-прежнему могут создавать собственные подключения к облачным службам.

Некоторые сетевые архитектуры, например те, которые соответствуют стандарту ISA-95, стараются максимально сократить число подключений к Интернету. В этих сценариях можно настроить подчиненные устройства IoT Edge без прямого подключения к Интернету. Помимо маршрутизации обмена данными с центром Интернета вещей через устройство шлюза, подчиненные устройства IoT Edge могут использовать устройство шлюза для всех облачных подключений.

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

• Модуль прокси API требуется для любого шлюза IoT Edge, под которым расположено другое устройство IoT Edge. Это означает, что он должен находиться на каждом уровне иерархии шлюзов, за исключением нижнего. Этот модуль использует обратный прокси-сервер nginx для маршрутизации данных HTTP через сетевые уровни с помощью одного порта. Она настраивается с помощью двойника модуля и переменных среды, поэтому ее можно настроить в соответствии с требованиями к сценарию шлюза.

• Модуль реестра Docker можно развернуть на шлюзе IoT Edge на верхнем уровне иерархии шлюзов. Этот модуль отвечает за извлечение и кэширование образов контейнеров от имени всех устройств IoT Edge на более низких уровнях. Альтернативой развертыванию этого модуля на верхнем уровне является использование локального реестра или ручная загрузка образов контейнеров на устройства и установка для политики извлечения модуля значения never.

• Хранилище BLOB-объектов Azure на IoT Edge можно развернуть на шлюзе IoT Edge на верхнем уровне иерархии шлюзов. Этот модуль отвечает за отправку больших двоичных объектов от имени всех устройств IoT Edge на более низких уровнях. Возможность отправки BLOB-объектов также позволяет использовать полезные функции устранения неполадок для устройств IoT Edge на более низких уровнях, например передача журнала модуля и отправка пакета поддержки.

Сетевая конфигурация

Для каждого устройства шлюза на верхнем уровне операторы сети должны:

• Предоставлять статический IP-адрес или полное доменное имя (FQDN).

• Разрешите исходящую связь с этого IP-адреса на узел IoT Hub Azure через порты 443 (HTTPS) и 5671 (AMQP).

• Авторизовать исходящие коммуникации с этого IP-адреса на имя узла Реестра контейнеров Azure через порт 443 (HTTPS).

  Модуль прокси API может одновременно управлять подключениями только к одному реестру контейнеров. Мы рекомендуем использовать все образы контейнеров, включая общедоступные образы, предоставляемые Microsoft Container Registry (mcr.microsoft.com), которые хранятся в частном реестре контейнеров.

Для каждого устройства шлюза на нижнем уровне операторы сети должны:

• Предоставлять статический IP-адрес.
• Авторизовать исходящие подключения с этого IP-адреса к IP-адресу родительского шлюза через порты 443 (HTTPS) и 5671 (AMQP).

Развертывание модулей на устройствах верхнего уровня

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

Модуль прокси API можно настраивать, чтобы адаптировать к большинству распространенных сценариев использования шлюзов. В этой статье приведен пример настройки модулей в базовой конфигурации. Дополнительные сведения и примеры см. в разделе "Настройка прокси-модуля API" для сценария иерархии шлюза.

Развертывание модулей на устройствах нижнего уровня

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

Извлечение образа контейнера для маршрутизации

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

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

Например, вместо вызова mcr.microsoft.com/azureiotedge-api-proxy:1.1 устройства более низкого уровня должны вызывать $upstream:443/azureiotedge-api-proxy:1.1.

Параметр $upstream указывает на родительское устройство нижнего уровня, поэтому запрос проходит через все уровни, пока не достигнет верхнего уровня, где прокси-среда направляет запросы контейнеров в модуль реестра. Порт :443 в этом примере следует заменить на порт, прослушиваемый модулем прокси API на родительском устройстве.

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

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

Начальная загрузка агента IoT Edge

Агент IoT Edge — это первый компонент среды выполнения, который можно запустить на любом устройстве IoT Edge. Необходимо убедиться, что все подчиненные устройства IoT Edge могут получить доступ к образу модуля edgeAgent при запуске, чтобы затем получить доступ к развертываниям и запустить остальные образы модулей.

При обновлении файла конфигурации на устройстве IoT Edge для предоставления сведений о проверке подлинности, сертификатах и родительском имени узла также обновите образ контейнера EdgeAgent.

Если устройство шлюза верхнего уровня настроено для обработки запросов образа контейнера, замените mcr.microsoft.com на имя родительского узла и порт прослушивания прокси API. В манифесте развертывания можно использовать $upstream в качестве ярлыка, но для этого необходимо, чтобы модуль edgeHub обрабатывал маршрутизацию и не запускался на этом этапе. Например:

[agent]
name = "edgeAgent"
type = "docker"

[agent.config]
image: "{Parent FQDN or IP}:443/azureiotedge-agent:1.5"

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

Настройка среды выполнения и развертывание модуля прокси

Прокси API необходим для маршрутизации всех взаимодействий между облаком и любыми подчиненными устройствами IoT Edge. Устройство IoT Edge на нижнем уровне иерархии, без ниже стоящих устройств IoT Edge, не нуждается в этом модуле.

Модуль прокси API можно настраивать, чтобы адаптировать к большинству распространенных сценариев использования шлюзов. В этой статье кратко рассматриваются действия по настройке модулей в базовой конфигурации. Более подробные сведения и примеры см. в разделе Настройка модуля прокси API для иерархии шлюзов.

1. Найдите нужный Центр Интернета вещей на портале Azure.

2. Выберите устройства в меню управления устройствами .

3. Выберите устройство ioT Edge нижнего уровня, которое вы настраиваете в списке.

4. Щелкните Set modules (Настроить модули).

5. В разделе модулей IoT Edge выберите "Добавить", а затем выберите "Модуль IoT Edge".

6. Обновите следующие параметры модуля:

   Параметр	Значение
   Имя модуля Интернета вещей	IoTEdgeAPIProxy
   URI образа	mcr.microsoft.com/azureiotedge-api-proxy:latest
   Политика перезапуска	always
   Требуемое состояние	running

   Если вы хотите использовать другую версию или архитектуру прокси-модуля API, найдите доступные образы в Реестр артефактов Microsoft.

   1. На вкладке "Переменные

   2. На вкладке Параметры создания контейнера обновите привязки портов, чтобы они ссылались на порт 443.

      {
        "HostConfig": {
          "PortBindings": {
            "443/tcp": [
              {
                "HostPort": "443"
              }
            ]
          }
        }
      }
      

   Эти изменения настраивают модуль прокси API для прослушивания порта 443. Чтобы предотвратить конфликты привязки портов, необходимо настроить модуль edgeHub так, чтобы он не прослушивал порт 443. Вместо этого модуль прокси API направляет любой трафик edgeHub через порт 443.

7. Выберите Параметры среды выполнения.

8. Обновите параметры модуля edgeHub:

   1. В поле Образ замените mcr.microsoft.com на $upstream:443.
   2. В поле Создание параметров удалите привязку для порта 443, оставив привязки для портов 5671 и 8883.

   {
     "HostConfig": {
       "PortBindings": {
         "5671/tcp": [
           {
             "HostPort": "5671"
           }
         ],
         "8883/tcp": [
           {
             "HostPort": "8883"
           }
         ]
       }
     }
   }
   

9. Обновите параметры модуля edgeAgent:

   1. В поле Образ замените mcr.microsoft.com на $upstream:443.

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

11. Нажмите Далее: маршруты, чтобы перейти к следующему шагу.

12. Чтобы разрешить отправку сообщений с устройства в облако, то есть с подчиненных устройств в центр Интернета вещей, включите маршрут, передающий все сообщения в $upstream. Параметр вышестоящего устройства указывает на родительское устройство в случае более низкоуровневых устройств. Например:

    1. Имя: Route
    2. Значение: FROM /messages/* INTO $upstream

13. Нажмите Проверка и создание, чтобы перейти к последнему шагу.

14. Нажмите Создать для развертывания на устройстве.

Проверка подключения от дочернего к родительскому

1. Проверьте подключение TLS/SSL от дочернего объекта к родителю, выполнив следующую openssl команду на нижнем устройстве. Замените <parent hostname> полное доменное имя или IP-адрес родительского объекта.

   openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null
   

   Команда должна подтвердить успешную проверку родительской цепочки сертификатов, аналогичную следующему примеру:

   azureUser@child-vm:~$ openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null
   Can't use SSL_get_servername
   depth=3 CN = Azure_IoT_Hub_CA_Cert_Test_Only
   verify return:1
   depth=2 CN = Azure_IoT_Hub_Intermediate_Cert_Test_Only
   verify return:1
   depth=1 CN = gateway.ca
   verify return:1
   depth=0 CN = <parent hostname>
   verify return:1
   DONE
   

   Сообщение "Не удается использовать SSL_get_servername", можно игнорировать.

   Значение depth=0 CN = должно соответствовать параметру имени узла, указанному в файле конфигурации родительского config.toml элемента.

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

   Предупреждение

   Не используя полный сертификат в разделе шлюза [edge_ca] , возникают ошибки проверки сертификата с нижнего устройства. Например, приведенная выше команда создает следующий результат: openssl s_client ...

   Can't use SSL_get_servername
   depth=1 CN = gateway.ca
   verify error:num=20:unable to get local issuer certificate
   verify return:1
   depth=0 CN = <parent hostname>
   verify return:1
   DONE
   

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

Интеграция Microsoft Defender для Интернета вещей с шлюзом IoT Edge

Подчиненные устройства можно использовать для интеграции микроагента Microsoft Defender для Интернета вещей с шлюзом IoT Edge с помощью прокси-сервера нижестоящего устройства.

Дополнительные сведения о микроагенте Defender для Интернета вещей.

Чтобы интегрировать Microsoft Defender для Интернета вещей с IoT Edge с помощью прокси-сервера нижестоящего устройства:

1. Войдите на портал Azure.

2. Перейдите к Центру Интернета вещей>Your Hub>Управление устройствами>Устройства.

3. Выберите устройство.

   

4. DefenderIotMicroAgent Выберите двойник модуля, созданный из этих инструкций.

   

5. Нажмите кнопку , чтобы скопировать строку подключения (первичный ключ).

6. Вставьте строка подключения в текстовое приложение редактирования и добавьте gatewayHostName в строку. GatewayHostName — это полное доменное имя или IP-адрес родительского устройства. Например, HostName=nested11.azure-devices.net;DeviceId=downstream1;ModuleId=module1;SharedAccessKey=xxx;GatewayHostName=10.16.7.4.

7. Откройте терминал на нижнем устройстве.

8. Используйте следующую команду, чтобы поместить строка подключения в кодировке utf-8 в каталог агента Defender для облака в файл connection_string.txt в следующем пути: /etc/defender_iot_micro_agent/connection_string.txt

   sudo bash -c 'echo "<connection string>" > /etc/defender_iot_micro_agent/connection_string.txt'
   

   Теперь файл connection_string.txt должен находиться по такому пути: /etc/defender_iot_micro_agent/connection_string.txt.

9. Перезапустите службу, выполнив следующую команду:

   sudo systemctl restart defender-iot-micro-agent.service 
   

10. Вернитесь к устройству.

    

11. Включите подключение к Центр Интернета вещей и выберите значок шестеренки.

    

12. Выберите родительское устройство из отображаемого списка.

13. Убедитесь, что порт 8883 (MQTT) между подчиненным устройством и устройством IoT Edge открыт.

Следующие шаги

Использование устройства IoT Edge в качестве шлюза

Настройка модуля прокси API для иерархии шлюзов