Conexión de dispositivos de Azure IoT Edge para crear una jerarquía

Article
08/07/2024

Se aplica a: IoT Edge 1.5 IoT Edge 1.4

Importante

IoT Edge 1.5 LTS e IoT Edge 1.4 LTS son versiones compatibles. IoT Edge 1.4 LTS finaliza el ciclo de vida el 12 de noviembre de 2024. Si está usando una versión anterior, consulte Actualización de IoT Edge.

En este artículo, se proporcionan pasos para establecer una conexión de confianza entre una puerta de enlace IoT Edge y un dispositivo de IoT Edge de nivel inferior. Esta configuración también se conoce como perímetro anidado.

En un escenario de puerta de enlace, un dispositivo IoT Edge puede ser tanto una puerta de enlace como un dispositivo de nivel inferior. Se pueden superponer varias puertas de enlace IoT Edge para crear una jerarquía de dispositivos. Los dispositivos de nivel inferior (secundarios) pueden autenticarse y enviar o recibir mensajes mediante su dispositivo de puerta de enlace (primario).

Hay dos configuraciones diferentes para los dispositivos IoT Edge en una jerarquía de puertas de enlace, y en este artículo se abordan ambas. La primera es el dispositivo IoT Edge de la capa superior. Cuando se conectan entre sí varios dispositivos IoT Edge, cualquier dispositivo que no tenga un dispositivo primario, sino que se conecte directamente a IoT Hub, se considera que está en la capa superior. Este dispositivo es responsable de administrar las solicitudes de todos los dispositivos que se encuentran debajo de él. La otra configuración se aplica a cualquier dispositivo IoT Edge en una capa inferior de la jerarquía. Estos dispositivos pueden ser una puerta de enlace para otros dispositivos de IoT e IoT Edge de nivel inferior, pero también necesitan enrutar las comunicaciones a través de sus propios dispositivos primarios.

Algunas arquitecturas de red requieren que solo el dispositivo IoT Edge superior de una jerarquía pueda conectarse a la nube. En esta configuración, todos los dispositivos IoT Edge en capas inferiores de una jerarquía solamente se pueden comunicar con su dispositivo (primario) de puerta de enlace y con dispositivos (secundarios) de bajada.

Todos los pasos de este artículo se basan en Configuración de un dispositivo IoT Edge para que actúe como puerta de enlace transparente, donde se configura un dispositivo IoT Edge para que sea una puerta de enlace para los dispositivos IoT de nivel inferior. Los mismos pasos básicos se aplican a todos los escenarios de puertas de enlace:

Autenticación: Cree identidades de IoT Hub para todos los dispositivos de la jerarquía de puertas de enlace.
Autorización: configure la relación de elementos primarios y secundarios en IoT Hub para autorizar a los dispositivos de bajada para que se conecten al dispositivo primario como si lo hicieran a IoT Hub.
Detección de puerta de enlace: asegúrese de que el dispositivo de bajada puede encontrar el dispositivo primario en la red local.
Conexión segura: Establezca una conexión segura con certificados de confianza que formen parte de la misma cadena.

Requisitos previos

Un centro de IoT gratis o estándar.
Al menos dos dispositivos IoT Edge, uno para que sea el dispositivo de nivel superior y uno o varios dispositivos de capa inferior. Si no tiene dispositivos IoT Edge disponibles, puede ejecutar Azure IoT Edge en máquinas virtuales Ubuntu.
Si usa la CLI de Azure para crear y administrar dispositivos, instale la extensión de Azure IoT.

Sugerencia

En este artículo se proporcionan pasos detallados y opciones para ayudarle a crear la jerarquía de puertas de enlace correcta para su escenario. Para ver un tutorial guiado, consulte Creación de una jerarquía de dispositivos IoT Edge mediante puertas de enlace.

Creación de una jerarquía de puertas de enlace

Cree una jerarquía de puertas de enlace IoT Edge mediante la definición de relaciones de elementos primarios y secundarios para los dispositivos IoT Edge en el escenario. Para establecer un dispositivo primario, puede crear una nueva identidad del dispositivo o puede administrar el elemento primario y los elementos secundarios de una identidad del dispositivo existente.

El paso de configuración de las relaciones de elementos primarios y secundarios autoriza a los dispositivos de bajada a conectarse al dispositivo primario como si lo hicieran a IoT Hub.

Solo los dispositivos IoT Edge pueden ser dispositivos primarios, pero tanto los dispositivos IoT Edge como los dispositivos IoT pueden ser secundarios. Un elemento primario puede tener muchos elementos secundarios, pero un elemento secundario solo puede tener un elemento primario. Una jerarquía de puertas de enlace se crea encadenando conjuntos de elementos primarios y secundarios para que el elemento secundario de un dispositivo sea el primario de otro.

De forma predeterminada, un dispositivo primario puede tener hasta 100 elementos secundarios. Puede cambiar este límite estableciendo la variable de entorno MaxConnectedClients en el módulo edgeHub del dispositivo primario.

Portal
CLI de Azure

En Azure Portal, puede administrar la relación de elementos primarios y secundarios al crear nuevas identidades de dispositivos o editando los dispositivos existentes.

Al crear un dispositivo IoT Edge, tiene la opción de elegir dispositivos primarios y secundarios de la lista de dispositivos IoT Edge existentes en ese centro.

En Azure Portal, navegue hasta su centro de IoT.
En el menú Administración de dispositivos, seleccione Dispositivos.
Seleccione Agregar dispositivo y, luego, active la casilla Dispositivo IoT Edge.
Además de establecer el identificador del dispositivo y la configuración de autenticación, puede establecer un dispositivo primario o elegir dispositivos secundarios.
Elija el o los dispositivos que quiera como primario o secundario.

También puede crear o administrar relaciones de elementos primarios y secundarios para los dispositivos existentes.

En Azure Portal, navegue hasta su centro de IoT.
Seleccione Dispositivos en el menú Administración de dispositivos.
En la lista, seleccione el dispositivo IoT Edge que quiere administrar.
Seleccione el icono Establecer un dispositivo primario de engranaje o Administrar dispositivos secundarios.
Agregue o quite dispositivos primarios o secundarios.

La extensión azure-iot de la CLI de Azure proporciona comandos para administrar los recursos de IoT. Puede administrar la relación de elementos primarios y secundarios de dispositivos IoT y IoT Edge al crear nuevas identidades de dispositivos o editando los dispositivos existentes.

El conjunto de comandos az iot hub device-identity permite administrar las relaciones de elementos primarios y secundarios para un dispositivo determinado.

El comando create incluye parámetros para agregar dispositivos secundarios y establecer un dispositivo primario en el momento de la creación del dispositivo.

Los comandos adicionales de identidades de dispositivos, incluidos add-children, list-children y remove-children, o get-parent y set-parent, permiten administrar las relaciones de elementos primarios y secundarios para los dispositivos existentes.

Nota:

Si desea establecer relaciones entre elementos primarios y secundarios mediante programación, puede usar el SDK de servicios de IoT Hub de C#, Java o Node.js.

Este es un ejemplo de asignación de dispositivos secundarios mediante el SDK de C#. La tarea RegistryManager_AddAndRemoveDeviceWithScope() muestra cómo crear mediante programación una jerarquía de tres capas. Un dispositivo IoT Edge está en la capa uno, como elemento primario. Otro dispositivo IoT Edge está en la capa dos, que sirve como elemento secundario y primario. Por último, un dispositivo IoT está en la capa tres, como el dispositivo secundario de la capa más baja.

Generación de certificados

Se debe instalar una cadena de certificados coherente en los dispositivos de la misma jerarquía de puertas de enlace para establecer una comunicación segura entre ellos. Todos los dispositivos de la jerarquía, ya sean dispositivos IoT Edge o dispositivos de bajada de IoT, necesitan una copia del mismo certificado de CA raíz. Cada dispositivo IoT Edge de la jerarquía luego usa ese certificado de CA raíz como raíz para su certificado de CA perimetral.

Con esta configuración, cada dispositivo IoT Edge de nivel inferior puede comprobar la identidad de su elemento primario comprobando que el elemento edgeHub al que se conecta tenga un certificado de servidor firmado por el certificado de CA raíz compartido.

Ilustración de una cadena de certificados emitida por la entidad de certificación raíz en el dispositivo de puerta de enlace y de nivel inferior

Para más información sobre los requisitos de los certificados de IoT Edge, consulte Información sobre los certificados de Azure IoT Edge.

Cree o solicite los certificados siguientes:
- Un certificado de CA raíz, que es el certificado compartido de nivel superior para todos los dispositivos de una jerarquía de puertas de enlace determinada. Este certificado está instalado en todos los dispositivos.
- Todo certificado intermedio que quiera incluir en la cadena de certificados raíz.
- Un certificado de CA perimetral y su clave privada, generada por los certificados raíz e intermedios. Necesita un único certificado de CA perimetral para cada dispositivo IoT Edge en la jerarquía de puertas de enlace.
Puede usar una entidad de certificado autofirmado o comprar uno a una entidad de certificación comercial de confianza, como Baltimore, Verisign, DigiCert o GlobalSign.
Si no tiene sus propios certificados para usarlos para la prueba, cree un conjunto de certificados raíz e intermedios y, a continuación, cree certificados de CA perimetrales para cada dispositivo. En este artículo, usaremos certificados de prueba generados mediante certificados de entidad de certificación de prueba para ejemplos y tutoriales. Por ejemplo, los siguientes comandos crean un certificado de CA raíz, un certificado de dispositivo primario y un certificado de dispositivo secundario.
```
# !!! 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"
```
Advertencia

No use los certificados creados por los scripts de prueba para producción. Contienen contraseñas codificadas de forma rígida y expiran de manera predeterminada después de 30 días. Los certificados de CA de prueba se proporcionan con fines de demostración para ayudarle a comprender los certificados de CA. Use sus propios procedimientos recomendados de seguridad para la creación de certificados y la administración de su vigencia en producción.

Para más información sobre cómo crear certificados de prueba, consulte Creación de certificados de demostración para probar las características del dispositivo IoT Edge.
Deberá transferir los certificados y las claves a cada dispositivo. Puede usar una unidad USB, un servicio como Azure Key Vault o una función como Secure file copy. Elija el método que mejor se adapte a su escenario. Copie los archivos en el directorio preferido para los certificados y las claves. Use /var/aziot/certs para certificados y /var/aziot/secrets para claves.

Para más información sobre cómo instalar certificados en un dispositivo, consulte Administración de certificados en un dispositivo IoT Edge.

Configuración del dispositivo primario

Para configurar el dispositivo primario, abra un shell de comandos local o remoto.

Para habilitar las conexiones seguras, cada dispositivo IoT Edge primario de un escenario de puerta de enlace se debe configurar con un único certificado de CA perimetral y una copia del certificado de CA raíz compartido por todos los dispositivos de la jerarquía de puertas de enlace.

Compruebe que los certificados cumplen los requisitos de formato.
Transfiera el certificado de CA raíz, el certificado de CA perimetral primaria y la clave privada primaria al dispositivo primario.

Copie los certificados y las claves en los directorios correctos. Los directorios preferidos para los certificados de dispositivo son /var/aziot/certs para los certificados y /var/aziot/secrets para las claves.

### 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

Cambie la propiedad y los permisos de los certificados y las claves.

# 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

La salida de la lista con la propiedad y el permiso correctos es similar a la siguiente:

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

Instale el certificado de entidad de certificación raíz en el dispositivo primario IoT Edge actualizando el almacén de certificados en el dispositivo mediante el comando específico de la plataforma.
```
# 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
```
Para más información sobre el uso de update-ca-trust en EFLOW, consulte Administración de certificados de CA de SSL de CBL-Mariner.

El comando informa de que se ha agregado un certificado a /etc/ssl/certs.

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

Actualización del archivo de configuración primario

Ya tiene que haber instalado IoT Edge en el dispositivo. Si no es así, siga las instrucciones para aprovisionar manualmente un único dispositivo IoT Edge en Linux.

Compruebe que exista el archivo de configuración /etc/aziot/config.toml en el dispositivo primario.

Si el archivo de configuración no está en el dispositivo, use el siguiente comando para crearlo en función del archivo de plantilla:
```
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
```
También puede usar el archivo de plantilla como referencia para agregar parámetros de configuración en esta sección.
Abra el archivo de configuración de IoT Edge mediante un editor. Por ejemplo, use el editor nano para abrir el archivo /etc/aziot/config.toml.
```
sudo nano /etc/aziot/config.toml
```
Busque el parámetro hostname o agréguelo al principio del archivo de configuración. Actualice el valor para que sea el nombre de dominio completo (FQDN) o la dirección IP del dispositivo IoT Edge primario. Por ejemplo:
```
hostname = "10.0.0.4"
```
Para habilitar la detección de puertas de enlace, cada dispositivo de puerta de enlace IoT Edge (primario) debe especificar el parámetro hostname, que sus dispositivos secundarios usarán para encontrarlo en la red local. Cada dispositivo IoT Edge de nivel inferior debe especificar el parámetro parent_hostname para identificar a su dispositivo primario. En un escenario jerárquico, en el que un único dispositivo IoT Edge es tanto un dispositivo primario como uno secundario, necesita ambos parámetros.

Los parámetros hostname y trust_bundle_cert deben estar al principio del archivo de configuración antes de cualquier sección. Agregar el parámetro antes de las secciones definidas garantiza que se aplique correctamente.

Use un nombre de host de menos de 64 caracteres, que es el límite de caracteres de un nombre común del certificado de servidor.

Sea coherente con el patrón del nombre de host en una jerarquía de puertas de enlace. Use FQDN o direcciones IP, pero no ambos. Se requiere el FQDN o la dirección IP para conectarse a los dispositivos de nivel inferior.

Establezca el nombre de host antes de crear el contenedor edgeHub. Si edgeHub está en ejecución, cambiar el nombre de host en el archivo de configuración no surtirá efecto hasta que se vuelva a crear el contenedor. Para más información sobre cómo comprobar que se haya aplicado el nombre de host, consulte la sección Comprobación de la configuración primaria.
Busque el parámetro trust_bundle_cert o agréguelo al principio del archivo de configuración.

Actualice el parámetro trust_bundle_cert con el identificador URI de archivo al certificado de CA raíz en el dispositivo. Por ejemplo:
```
trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
```
Busque la sección del certificado de CA de Edge en el archivo de configuración o agréguela. Actualice los parámetros cert del certificado y pk de la clave privada con las rutas de acceso del identificador URI de archivo del certificado de cadena completa y los archivos de claves en el dispositivo IoT Edge primario. IoT Edge requiere que el certificado y la clave privada estén en formato de correo de privacidad mejorada (PEM) basado en texto. Por ejemplo:
```
[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"
```
Compruebe que el dispositivo IoT Edge utiliza la versión correcta del agente de IoT Edge cuando se inicie. Busque la sección Agente de Edge predeterminado y establezca el valor de la imagen para IoT Edge en la versión 1.5. Por ejemplo:
```
[agent]
name = "edgeAgent"
type = "docker"

[agent.config]
image = "mcr.microsoft.com/azureiotedge-agent:1.5"
```

El principio del archivo de configuración primario debe ser similar al ejemplo siguiente.

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"

Guarde y cierre el archivo de configuración config.toml. Por ejemplo, si usa el editor nano, seleccione Ctrl+O - Escribir, Entrar y Ctrl+X - Salir.
Si anteriormente ha usado cualquier otro certificado para IoT Edge, elimine los archivos de los dos directorios siguientes para asegurarse de que se apliquen los nuevos certificados:
- /var/lib/aziot/certd/certs
- /var/lib/aziot/keyd/keys
Aplique los cambios.
```
sudo iotedge config apply
```
Compruebe los errores en la configuración.
```
sudo iotedge check --verbose
```
Nota:

En un dispositivo recién aprovisionado, es posible que vea un error relacionado con IoT Edge Hub:

× preparación para producción: el directorio de almacenamiento de Edge Hub se conserva en el sistema de archivos host: error

No se pudo comprobar el estado actual del contenedor de Edge Hub

Este error se espera en un dispositivo recién aprovisionado porque el módulo de IoT Edge Hub no se está ejecutando. Para resolver el error, en IoT Hub, establezca los módulos del dispositivo y cree una implementación. La creación de una implementación para el dispositivo inicia los módulos en el dispositivo, incluido el módulo de IoT Edge Hub.

Comprobación de la configuración primaria

El nombre de host debe ser un nombre de dominio completo (FQDN) o la dirección IP del dispositivo IoT Edge porque IoT Edge usa este valor en el certificado de servidor cuando se conectan los dispositivos de nivel inferior. Los valores deben coincidir o se producirá un error de coincidencia de direcciones IP.

Para comprobar el nombre de host, debe inspeccionar las variables de entorno del contenedor edgeHub.

Enumere los contenedores de IoT Edge en ejecución.

iotedge list

Compruebe que los contenedores edgeAgent y edgeHub estén en ejecución. La salida del comando debe ser similar a la del ejemplo siguiente.

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

Inspeccione el contenedor edgeHub.
```
sudo docker inspect edgeHub
```
En la salida, busque el parámetro EdgeDeviceHostName en la sección Env.
```
"EdgeDeviceHostName=10.0.0.4"
```
Compruebe que el valor del parámetro EdgeDeviceHostName coincida con la configuración hostname de config.toml. Si no coincide, el contenedor edgeHub estaba en ejecución al modificar y aplicar la configuración. Para actualizar EdgeDeviceHostName, quite el contenedor edgeAgent.
```
sudo docker rm -f edgeAgent
```
Los contenedores edgeAgent y edgeHub se vuelven a crear y se inician en unos minutos. Una vez que esté en ejecución el contenedor edgeHub, inspeccione el contenedor y compruebe que el parámetro EdgeDeviceHostName coincida con el archivo de configuración.

Configuración de un dispositivo de bajada

Para configurar un dispositivo de bajada, abra un shell de comandos local o remoto.

Para habilitar las conexiones seguras, cada dispositivo IoT Edge de bajada de un escenario de puerta de enlace se debe configurar con un único certificado de CA perimetral y una copia del certificado de CA raíz compartido por todos los dispositivos de la jerarquía de puertas de enlace.

Compruebe que los certificados cumplen los requisitos de formato.
Transfiera el certificado de CA raíz, el certificado de CA perimetral secundaria y la clave privada secundaria al dispositivo de bajada.

### 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

Cambie la propiedad y los permisos de los certificados y las claves.

# 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 {} \;

Instale el certificado de CA raíz en el dispositivo IoT Edge de bajada actualizando el almacén de certificados en el dispositivo mediante el comando específico de la plataforma.
```
# 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
```
Para más información sobre el uso de update-ca-trust en EFLOW, consulte Administración de certificados de CA de SSL de CBL-Mariner.

El comando informa de que se ha agregado un certificado a /etc/ssl/certs.

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

Actualización del archivo de configuración de bajada

Ya tiene que haber instalado IoT Edge en el dispositivo. Si no es así, siga las instrucciones para aprovisionar manualmente un único dispositivo IoT Edge en Linux.

Compruebe que el archivo de configuración /etc/aziot/config.toml existe en el dispositivo de bajada.

Si el archivo de configuración no está en el dispositivo, use el siguiente comando para crearlo en función del archivo de plantilla:
```
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
```
También puede usar el archivo de plantilla como referencia para agregar parámetros de configuración en esta sección.
Abra el archivo de configuración de IoT Edge mediante un editor. Por ejemplo, use el editor nano para abrir el archivo /etc/aziot/config.toml.
```
sudo nano /etc/aziot/config.toml
```
Busque el parámetro parent_hostname o agréguelo al principio del archivo de configuración. Cada dispositivo IoT Edge de nivel inferior debe especificar el parámetro parent_hostname para identificar a su elemento primario. Actualice el parámetro parent_hostname para que sea el FQDN o la dirección IP del dispositivo primario, para que coincida con lo que se proporcionó como nombre de host en el archivo de configuración del dispositivo primario. Por ejemplo:
```
parent_hostname = "10.0.0.4"
```
Busque el parámetro trust_bundle_cert o agréguelo al principio del archivo de configuración.

Actualice el parámetro trust_bundle_cert con el identificador URI de archivo al certificado de CA raíz en el dispositivo. Por ejemplo:
```
trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
```
Busque la sección del certificado de CA de Edge en el archivo de configuración o agréguela. Actualice los parámetros cert del certificado y pk de la clave privada con las rutas de acceso del identificador URI de archivo del certificado de cadena completa y los archivos de claves en el dispositivo IoT Edge del nivel inferior. IoT Edge requiere que el certificado y la clave privada estén en formato de correo de privacidad mejorada (PEM) basado en texto. Por ejemplo:
```
[edge_ca]
cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem"
pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"
```
Compruebe que el dispositivo IoT Edge utiliza la versión correcta del agente de IoT Edge cuando se inicie. Busque la sección Agente de Edge predeterminado y establezca el valor de la imagen para IoT Edge en la versión 1.5. Por ejemplo:
```
[agent]
name = "edgeAgent"
type = "docker"

[agent.config]
image: "mcr.microsoft.com/azureiotedge-agent:1.5"
```

El inicio del archivo de configuración de bajada debe ser similar al ejemplo siguiente.

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"

Guarde y cierre el archivo de configuración config.toml. Por ejemplo, si usa el editor nano, seleccione Ctrl+O - Escribir, Entrar y Ctrl+X - Salir.
Si anteriormente ha usado cualquier otro certificado para IoT Edge, elimine los archivos de los dos directorios siguientes para asegurarse de que se apliquen los nuevos certificados:
- /var/lib/aziot/certd/certs
- /var/lib/aziot/keyd/keys
Aplique los cambios.
```
sudo iotedge config apply
```
Compruebe los errores en la configuración.
```
sudo iotedge check --verbose
```
Sugerencia

La herramienta de comprobación de IoT Edge usa un contenedor para realizar algunas de las comprobaciones de diagnóstico. Si quiere usar esta herramienta en dispositivos IoT Edge de nivel inferior, asegúrese de que pueden acceder a mcr.microsoft.com/azureiotedge-diagnostics:latest, o mantenga la imagen de contenedor en el registro de contenedor privado.

Nota:

En un dispositivo recién aprovisionado, es posible que vea un error relacionado con IoT Edge Hub:

× preparación para producción: el directorio de almacenamiento de Edge Hub se conserva en el sistema de archivos host: error

No se pudo comprobar el estado actual del contenedor de Edge Hub

Este error se espera en un dispositivo recién aprovisionado porque el módulo de IoT Edge Hub no se está ejecutando. Para resolver el error, en IoT Hub, establezca los módulos del dispositivo y cree una implementación. La creación de una implementación para el dispositivo inicia los módulos en el dispositivo, incluido el módulo de IoT Edge Hub.

Aislamiento de red de dispositivos de nivel inferior

Hasta ahora, los pasos de este artículo configuran dispositivos IoT Edge como puerta de enlace o como dispositivo de nivel inferior, y crean una conexión de confianza entre ellos. El dispositivo de puerta de enlace controla las interacciones entre el dispositivo de nivel inferior y IoT Hub, incluida la autenticación y el enrutamiento de mensajes. Los módulos implementados en dispositivos IoT Edge de nivel inferior pueden crear sus propias conexiones a los servicios en la nube.

Algunas arquitecturas de red, como las que siguen el estándar ISA-95, buscan minimizar el número de conexiones a Internet. En estos casos, puede configurar los dispositivos IoT Edge de nivel inferior sin conectividad a Internet. Más allá del enrutamiento de las comunicaciones de IoT Hub a través del dispositivo de puerta de enlace, los dispositivos IoT Edge de nivel inferior pueden depender del dispositivo de puerta de enlace para todas las conexiones en la nube

Esta configuración de red requiere que solo el dispositivo IoT Edge de la capa superior de una jerarquía de puertas de enlace tenga conexiones directas a la nube. Los dispositivos IoT Edge de las capas inferiores solo se pueden comunicar con su dispositivo primario o con los dispositivos secundarios. Los módulos especiales de los dispositivos de puerta de enlace permiten este escenario, entre los que se incluyen:

El módulo de proxy de API es necesario en cualquier puerta de enlace IoT Edge que tenga otro dispositivo IoT Edge debajo. Esto significa que debe estar en cada capa de una jerarquía de puertas de enlace, excepto la capa última. Este módulo usa un proxy inverso nginx para enrutar los datos HTTP a través de las capas de red mediante un único puerto. Es altamente configurable mediante su módulo gemelo y las variables de entorno, por lo que se puede ajustar para adaptarse a los requisitos de su escenario de puerta de enlace.
El módulo de registro de Docker puede implementarse en la puerta de enlace IoT Edge en la capa superior de una jerarquía de puertas de enlace. Este módulo es responsable de la recuperación y el almacenamiento en caché de las imágenes de contenedor en nombre de todos los dispositivos IoT Edge de las capas inferiores. La alternativa a la implementación de este módulo en la capa superior es usar un registro local, o cargar manualmente las imágenes de contenedor en los dispositivos y establecer la directiva de extracción del módulo en nunca.
Azure Blob Storage en IoT Edge puede implementarse en la puerta de enlace IoT Edge en la capa superior de una jerarquía de puertas de enlace. Este módulo es responsable de la carga de blobs en nombre de todos los dispositivos IoT Edge de las capas inferiores. La capacidad de cargar blobs también hace posible una funcionalidad útil de solución de problemas para dispositivos IoT Edge en capas inferiores, como la carga de registros de módulos y la carga de paquetes de soporte técnico.

Configuración de red

Para cada dispositivo de puerta de enlace de la capa superior, los operadores de red deben:

Proporcionar una dirección IP estática o nombre de dominio completo (FQDN).
Autorizar las comunicaciones salientes desde esta dirección IP a su nombre de host de Azure IoT Hub a través de los puertos 443 (HTTPS) y 5671 (AMQP).
Autorizar las comunicaciones salientes desde esta dirección IP a su nombre de host de Azure Container Registry a través del puerto 443 (HTTPS).

El módulo de proxy de API solo puede controlar conexiones a un registro de contenedor a la vez. Se recomienda almacenar todas las imágenes de contenedor, incluidas las imágenes públicas proporcionadas por el Registro de contenedor de Microsoft (mcr.microsoft.com), en el registro de contenedor privado.

Para cada dispositivo de puerta de enlace de una capa inferior, los operadores de red deben:

Proporcionar una dirección IP estática.
Autorizar las comunicaciones salientes desde esta dirección IP a la dirección IP de la puerta de enlace primaria a través de los puertos 443 (HTTPS) y 5671 (AMQP).

Implementación de módulos en el dispositivos de capa superior

El dispositivo IoT Edge en la capa superior de una jerarquía de puertas de enlace tiene un conjunto de módulos necesarios que se deben implementar en él, además de los módulos de carga de trabajo que se puedan ejecutar en el dispositivo.

El módulo de proxy de API se diseñó para personalizarse y administrar los escenarios de puerta de enlace más comunes. En este artículo, se proporciona un ejemplo de cómo establecer los módulos en una configuración básica. Consulte Configuración del módulo de proxy de API para el escenario de jerarquías de puertas de enlace para obtener información más detallada y ejemplos.

Portal
CLI de Azure

En Azure Portal, navegue hasta su centro de IoT.
En el menú Administración de dispositivos, seleccione Dispositivos.
En la lista, seleccione el dispositivo IoT Edge de la capa superior que va a configurar.
Seleccione Set modules (Establecer módulos).
En la sección Módulos de IoT Edge, seleccione Agregar y, a continuación, elija Módulo de IoT Edge.
Actualice la siguiente configuración del módulo:

Configuración Valor

Nombre del módulo de IoT IoTEdgeAPIProxy

URI de imagen mcr.microsoft.com/azureiotedge-api-proxy:latest

Directiva de reinicio Siempre

Estado deseado en ejecución

Si desea usar una versión o arquitectura diferentes del módulo proxy de API, busque las imágenes disponibles en el Registro de artefactos Microsoft.
1. En la pestaña Variables de entorno, agregue una variable denominada NGINX_DEFAULT_PORT de tipo Text con un valor de 443.
2. En la pestaña Opciones de creación del contenedor, actualice los enlaces de puerto para hacer referencia al puerto 443.
```
{
  "HostConfig": {
    "PortBindings": {
      "443/tcp": [
        {
          "HostPort": "443"
        }
      ]
    }
  }
}
```
Estos cambios configuran el módulo de proxy de API para que escuche en el puerto 443. Para evitar colisiones de enlace de puertos, debe configurar el módulo edgeHub para que no escuche en el puerto 443. En su lugar, el módulo de proxy de API enrutará todo el tráfico de edgeHub en l puerto 443.
Seleccione Agregar para agregar el módulo a la implementación.
Seleccione Configuración del entorno de ejecución y busque las opciones de creación de contenedores del módulo edgeHub. Elimine el enlace de puerto para el puerto 443, y deje los enlaces a los puertos 5671 y 8883.
```
{
  "HostConfig": {
    "PortBindings": {
      "5671/tcp": [
        {
          "HostPort": "5671"
        }
      ],
      "8883/tcp": [
        {
          "HostPort": "8883"
        }
      ]
    }
  }
}
```
Seleccione Aplicar para guardar los cambios en la configuración del entorno de ejecución.

Configuración	Valor
Nombre del módulo de IoT	`IoTEdgeAPIProxy`
URI de imagen	`mcr.microsoft.com/azureiotedge-api-proxy:latest`
Directiva de reinicio	Siempre
Estado deseado	en ejecución

Proporcione los siguientes valores para agregar el módulo del registro de Docker a su implementación.

En la sección Módulos de IoT Edge, seleccione Agregar y, a continuación, elija Módulo de IoT Edge.

Configuración Valor

Nombre del módulo de IoT registry

URI de imagen registry:latest

Directiva de reinicio always

Estado deseado running

Configuración	Valor
Nombre del módulo de IoT	`registry`
URI de imagen	`registry:latest`
Directiva de reinicio	`always`
Estado deseado	`running`

En la pestaña Variables de entorno, agregue las siguientes variables:

Nombre	Tipo	Valor
`REGISTRY_PROXY_REMOTEURL`	Texto	Dirección URL del registro de contenedor al que quiere que se asigne este módulo del registro. Por ejemplo, `https://myregistry.azurecr`. El módulo del registro solo se puede asignar a un registro de contenedor, por lo que se recomienda tener todas las imágenes de contenedor en un solo registro de contenedor privado.
`REGISTRY_PROXY_USERNAME`	Texto	Nombre de usuario para autenticarse en el registro de contenedor.
`REGISTRY_PROXY_PASSWORD`	Texto	Contraseña para autenticarse en el registro de contenedor.

En la pestaña Opciones de creación del contenedor, actualice los enlaces de puerto para hacer referencia al puerto 5000.

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

Seleccione Agregar para agregar el módulo a la implementación.
Seleccione Siguiente: Rutas para ir al paso siguiente.
Para habilitar los mensajes del dispositivo a la nube desde dispositivos de nivel inferior para que se comuniquen con IoT Hub, incluya una ruta que pase todos los mensajes a IoT Hub. Por ejemplo:
1. Nombre: Route
2. Valor: FROM /messages/* INTO $upstream
Seleccione Revisar y crear para ir al paso final.
Seleccione Crear para implementar el dispositivo.

En Azure Cloud Shell, cree un archivo JSON de implementación. Por ejemplo:

{
    "modulesContent": {
        "$edgeAgent": {
            "properties.desired": {
                "modules": {
                    "dockerContainerRegistry": {
                        "settings": {
                            "image": "registry:latest",
                            "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"5000/tcp\":[{\"HostPort\":\"5000\"}]}}}"
                        },
                        "type": "docker",
                        "version": "1.0",
                        "env": {
                            "REGISTRY_PROXY_REMOTEURL": {
                                "value": "The URL for the container registry you want this registry module to map to. For example, https://myregistry.azurecr"
                            },
                            "REGISTRY_PROXY_USERNAME": {
                                "value": "Username to authenticate to the container registry."
                            },
                            "REGISTRY_PROXY_PASSWORD": {
                                "value": "Password to authenticate to the container registry."
                            }
                        },
                        "status": "running",
                        "restartPolicy": "always"
                    },
                    "IoTEdgeAPIProxy": {
                        "settings": {
                            "image": "mcr.microsoft.com/azureiotedge-api-proxy:1.1",
                            "createOptions": "{\"HostConfig\": {\"PortBindings\": {\"443/tcp\": [{\"HostPort\":\"443\"}]}}}"
                        },
                        "type": "docker",
                        "env": {
                            "NGINX_DEFAULT_PORT": {
                                "value": "443"
                            },
                            "DOCKER_REQUEST_ROUTE_ADDRESS": {
                                "value": "registry:5000"
                            }
                        },
                        "status": "running",
                        "restartPolicy": "always",
                        "version": "1.0"
                    }
                },
                "runtime": {
                    "settings": {
                        "minDockerVersion": "v1.25"
                    },
                    "type": "docker"
                },
                "schemaVersion": "1.1",
                "systemModules": {
                    "edgeAgent": {
                        "settings": {
                            "image": "mcr.microsoft.com/azureiotedge-agent:1.5",
                            "createOptions": "{}"
                        },
                        "type": "docker"
                    },
                    "edgeHub": {
                        "settings": {
                            "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
                            "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
                        },
                        "type": "docker",
                        "env": {},
                        "status": "running",
                        "restartPolicy": "always"
                    }
                }
            }
        },
        "$edgeHub": {
            "properties.desired": {
                "routes": {
                    "route": "FROM /messages/* INTO $upstream"
                },
                "schemaVersion": "1.1",
                "storeAndForwardConfiguration": {
                    "timeToLiveSecs": 7200
                }
            }
        }
    }
}

Este archivo de implementación configura el módulo de proxy de API para que escuche en el puerto 443. Para evitar colisiones de enlace de puertos, el archivo configura el módulo edgeHub para que no escuche en el puerto 443. En su lugar, el módulo de proxy de API enrutará todo el tráfico de edgeHub en l puerto 443.

Escriba el siguiente comando para crear una implementación en un dispositivo IoT Edge:

az iot edge set-modules --device-id <device_id> --hub-name <iot_hub_name> --content ./<deployment_file_name>.json

Implementación de módulos en dispositivos de capas inferiores

Los dispositivos IoT Edge en las capas inferiores de una jerarquía de puertas de enlace tienen un módulo necesario que se debe implementar en ellos, además de los módulos de carga de trabajo que se puedan ejecutar en los dispositivos.

Enrutamiento de extracciones de imágenes de contenedor

Antes de analizar el módulo de proxy necesario para los dispositivos IoT Edge en las jerarquías de puertas de enlace, es importante comprender cómo los dispositivos IoT Edge de las capas inferiores obtienen sus imágenes de módulo.

Si los dispositivos de capas inferiores no se pueden conectar a la nube, pero quiere que extraigan imágenes de módulo como de costumbre, el dispositivo de la capa superior de la jerarquía de puertas de enlace debe configurarse para controlar estas solicitudes. El dispositivo de la capa superior tiene que ejecutar un módulo de registro de Docker que esté asignado al registro de contenedor. A continuación, configure el módulo de proxy de API para enrutar a él las solicitudes de contenedor. Estos detalles se describen en las secciones anteriores de este artículo. En esta configuración, los dispositivos de las capas inferiores no deben apuntar a los registros de contenedor en la nube, sino al registro que se ejecuta en la capa superior.

Por ejemplo, en lugar de llamar a mcr.microsoft.com/azureiotedge-api-proxy:1.1, los dispositivos de las capas inferiores deben llamar a $upstream:443/azureiotedge-api-proxy:1.1.

El parámetro $upstream apunta al elemento primario de un dispositivo de capa inferior, por lo que la solicitud se enrutará a través de todas las capas hasta que llegue a la capa superior, que tiene un entorno de proxy que enruta las solicitudes al módulo del registro. El puerto :443 en este ejemplo debe reemplazarse por el puerto en el que esté escuchando el módulo de proxy de API en el dispositivo primario.

El módulo de proxy de API solo puede enrutar a un módulo del registro, y cada módulo del registro solo puede asignarse a un registro de contenedor. Por lo tanto, las imágenes que los dispositivos de las capas inferiores tengan que extraer deben almacenarse en un registro de contenedor único.

Si no quiere que los dispositivos de las capas inferiores realicen solicitudes de extracción de módulos a través de una jerarquía de puertas de enlace, otra opción es administrar una solución de registro local. O bien, inserte las imágenes del módulo en los dispositivos antes de crear las implementaciones y, a continuación, establezca imagePullPolicy en never.

Arranque del agente de IoT Edge

El agente de IoT Edge es el primer componente del entorno de ejecución en iniciarse en cualquier dispositivo IoT Edge. Debe asegurarse de que los dispositivos IoT Edge de nivel inferior pueden acceder a la imagen del módulo edgeAgent cuando se inician y, a continuación, pueden acceder a las implementaciones e iniciar el resto de las imágenes del módulo.

Cuando vaya al archivo de configuración en un dispositivo IoT Edge para proporcionar la información de autenticación, los certificados y el nombre de host primario, actualice también la imagen del contenedor edgeAgent.

Si el dispositivo de puerta de enlace de nivel superior está configurado para controlar las solicitudes de imagen de contenedor, reemplace mcr.microsoft.com por el nombre de host primario y el puerto de escucha del proxy de API. En el manifiesto de implementación, puede usar $upstream como acceso directo, pero esto requiere que el módulo edgeHub controle el enrutamiento y que ese módulo no se haya iniciado en este momento. Por ejemplo:

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

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

Si usa un registro de contenedor local o proporciona las imágenes de contenedor manualmente en el dispositivo, actualice el archivo de configuración en consecuencia.

Configuración del entorno de ejecución e implementación del módulo de proxy

El módulo de proxy de API es necesario para enrutar todas las comunicaciones entre la nube y los dispositivos IoT Edge de nivel inferior. Un dispositivo IoT Edge en la capa última de la jerarquía, sin dispositivos IoT Edge de nivel inferior, no necesita este módulo.

El módulo de proxy de API se diseñó para personalizarse y administrar los escenarios de puerta de enlace más comunes. En este artículo se analizan brevemente los pasos para establecer los módulos en una configuración básica. Consulte Configuración del módulo de proxy de API para el escenario de jerarquías de puertas de enlace para obtener información más detallada y ejemplos.

En Azure Portal, navegue hasta su centro de IoT.
En el menú Administración de dispositivos, seleccione Dispositivos.
En la lista, seleccione el dispositivo IoT Edge de la capa inferior que va a configurar.
Seleccione Set modules (Establecer módulos).
En la sección Módulos de IoT Edge, seleccione Agregar y, a continuación, elija Módulo de IoT Edge.
Actualice la siguiente configuración del módulo:

Configuración Valor

Nombre del módulo de IoT IoTEdgeAPIProxy

URI de imagen mcr.microsoft.com/azureiotedge-api-proxy:latest

Directiva de reinicio always

Estado deseado running

Si desea usar una versión o arquitectura diferentes del módulo proxy de API, busque las imágenes disponibles en el Registro de artefactos Microsoft.
1. En la pestaña Variables de entorno, agregue una variable denominada NGINX_DEFAULT_PORT de tipo Text con un valor de 443.
2. En la pestaña Opciones de creación del contenedor, actualice los enlaces de puerto para hacer referencia al puerto 443.
```
{
  "HostConfig": {
    "PortBindings": {
      "443/tcp": [
        {
          "HostPort": "443"
        }
      ]
    }
  }
}
```
Estos cambios configuran el módulo de proxy de API para que escuche en el puerto 443. Para evitar colisiones de enlace de puertos, debe configurar el módulo edgeHub para que no escuche en el puerto 443. En su lugar, el módulo de proxy de API enrutará todo el tráfico de edgeHub en l puerto 443.
Seleccione Configuración del entorno de ejecución.
Actualice la configuración del módulo edgeHub:
1. En el campo Imagen, reemplace mcr.microsoft.com por $upstream:443.
2. En el campo Opciones de creación, elimine el enlace de puerto para el puerto 443, y deje los enlaces a los puertos 5671 y 8883.
```
{
  "HostConfig": {
    "PortBindings": {
      "5671/tcp": [
        {
          "HostPort": "5671"
        }
      ],
      "8883/tcp": [
        {
          "HostPort": "8883"
        }
      ]
    }
  }
}
```
Actualice la configuración del módulo edgeAgent:
1. En el campo Imagen, reemplace mcr.microsoft.com por $upstream:443.
Seleccione Aplicar para guardar los cambios en la configuración del entorno de ejecución.
Seleccione Siguiente: Rutas para ir al paso siguiente.
Para habilitar los mensajes del dispositivo a la nube desde dispositivos de nivel inferior para que se comuniquen con IoT Hub, incluya una ruta que pase todos los mensajes a $upstream. El parámetro ascendente apunta al dispositivo primario en el caso de los dispositivos de capas inferiores. Por ejemplo:
1. Nombre: Route
2. Valor: FROM /messages/* INTO $upstream
Seleccione Revisar y crear para ir al paso final.
Seleccione Crear para implementar el dispositivo.

Configuración	Valor
Nombre del módulo de IoT	`IoTEdgeAPIProxy`
URI de imagen	`mcr.microsoft.com/azureiotedge-api-proxy:latest`
Directiva de reinicio	`always`
Estado deseado	`running`

Comprobación de la conectividad del dispositivo secundario al primario

Para comprobar la conexión TLS/SSL del dispositivo secundario al primario, ejecute el siguiente comando openssl en el dispositivo de bajada. Reemplace <parent hostname> por el FQDN o la dirección IP del elemento primario.
```
openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null
```
El comando debe validar correctamente la cadena de certificados primaria de forma similar a la del ejemplo siguiente:
```
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
```
Se puede omitir el mensaje "No se puede usar SSL_get_servername".

El valor depth=0 CN = debe coincidir con el parámetro hostname especificado en el archivo de configuración config.toml del elemento primario.

Si el comando agota el tiempo de espera, puede haber puertos bloqueados entre los dispositivos secundarios y primarios. Revise la configuración de red y los valores de los dispositivos.
Advertencia

Si no se usa un certificado de cadena completa en la sección [edge_ca] de la puerta de enlace, se producen errores de validación de certificados del dispositivo de bajada. Por ejemplo, el comando openssl s_client ... anterior generaría:
```
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
```
El mismo problema se produce para los dispositivos habilitados para TLS que se conectan al dispositivo de bajada IoT Edge si el certificado de dispositivo de cadena completa no se usa y se configura en el dispositivo de bajada.

Integración de Microsoft Defender para IoT con una puerta de enlace de IoT Edge

Los dispositivos de bajada se pueden usar para integrar el microagente de Microsoft Defender para IoT con la puerta de enlace de IoT Edge mediante la creación de conexiones proxy de dispositivo de bajada.

Aprenda más sobre el microagente de Defender para IoT.

Haga lo siguiente para integrar Microsoft Defender para IoT con IoT Edge mediante la creación de conexiones proxy de dispositivo de bajada:

Inicie sesión en Azure Portal.
Vaya a IoT Hub>Your Hub>Administración de dispositivos>Dispositivos.
Seleccione el dispositivo.
Seleccione el módulo gemelo DefenderIotMicroAgent que creó a partir de estas instrucciones.
Selección del botón para copiar la cadena de conexión (clave principal).
Pegue la cadena de conexión en una aplicación de edición de texto y agregue GatewayHostName a la cadena. GatewayHostName es el nombre de dominio completo o la dirección IP del dispositivo primario. Por ejemplo, HostName=nested11.azure-devices.net;DeviceId=downstream1;ModuleId=module1;SharedAccessKey=xxx;GatewayHostName=10.16.7.4.
Abra un terminal en el dispositivo de bajada.
Use el comando siguiente para colocar la cadena de conexión codificada en utf-8 en el directorio del agente de Defender for Cloud en el archivo connection_string.txt en la ruta de acceso siguiente: /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 debe encontrarse ahora en la siguiente ubicación de ruta de acceso /etc/defender_iot_micro_agent/connection_string.txt.

Reinicie el servicio con este comando:

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

Vuelva al dispositivo.
Habilite la conexión a IoT Hub y seleccione el icono de engranaje.
Seleccione el dispositivo principal en la lista mostrada.
Asegúrese de que el puerto 8883 (MQTT) entre el dispositivo de bajada y el dispositivo IoT Edge está abierto.

Pasos siguientes

Uso de un dispositivo IoT Edge como puerta de enlace

Configuración del módulo de proxy de API para el escenario de jerarquías de puertas de enlace

Comparteix a través de