Delen via

Azure IoT Edge-apparaten verbinden om een hiërarchie te maken

  • Artikel

Van toepassing op: IoT Edge 1.5-vinkje IoT Edge 1.5 Vinkje voor IoT Edge 1.4 IoT Edge 1.4

Belangrijk

IoT Edge 1.5 LTS en IoT Edge 1.4 LTS worden ondersteund releases. IoT Edge 1.4 LTS eindigt op 12 november 2024. Raadpleeg IoT Edge bijwerken als u een eerdere versie hebt.

Dit artikel bevat stappen voor het tot stand brengen van een vertrouwde verbinding tussen een IoT Edge-gateway en een downstream IoT Edge-apparaat. Deze configuratie wordt ook wel geneste rand genoemd.

In een gatewayscenario kan een IoT Edge-apparaat zowel een gateway als een downstreamapparaat zijn. Meerdere IoT Edge-gateways kunnen worden gelaagd om een hiërarchie van apparaten te maken. De downstreamapparaten (onderliggende) apparaten kunnen berichten verifiëren en verzenden of ontvangen via hun gatewayapparaat (bovenliggend).

Er zijn twee verschillende configuraties voor IoT Edge-apparaten in een gatewayhiërarchie en in dit artikel worden beide behandeld. De eerste is het IoT Edge-apparaat in de bovenste laag . Wanneer meerdere IoT Edge-apparaten verbinding maken via elkaar, wordt elk apparaat dat geen bovenliggend apparaat heeft, maar rechtstreeks verbinding maakt met IoT Hub, beschouwd als in de bovenste laag. Dit apparaat is verantwoordelijk voor het verwerken van aanvragen van alle apparaten eronder. De andere configuratie is van toepassing op elk IoT Edge-apparaat in een lagere laag van de hiërarchie. Deze apparaten zijn mogelijk een gateway voor andere downstream-IoT- en IoT Edge-apparaten, maar moeten ook communicatie doorsturen via hun eigen bovenliggende apparaten.

Sommige netwerkarchitecturen vereisen dat alleen het bovenste IoT Edge-apparaat in een hiërarchie verbinding kan maken met de cloud. In deze configuratie kunnen alle IoT Edge-apparaten in lagere lagen van een hiërarchie alleen communiceren met hun gatewayapparaat (bovenliggend) en eventuele downstreamapparaten (onderliggende) apparaten.

Alle stappen in dit artikel zijn gebaseerd op het configureren van een IoT Edge-apparaat om te fungeren als een transparante gateway, waarmee een IoT Edge-apparaat wordt ingesteld als een gateway voor downstream IoT-apparaten. Dezelfde basisstappen zijn van toepassing op alle gatewayscenario's:

  • Verificatie: IoT Hub-identiteiten maken voor alle apparaten in de gatewayhiërarchie.
  • Autorisatie: stel de bovenliggende/onderliggende relatie in IoT Hub in om downstreamapparaten te autoriseren om verbinding te maken met hun bovenliggende apparaat, net zoals ze verbinding willen maken met IoT Hub.
  • Gatewaydetectie: zorg ervoor dat het downstreamapparaat het bovenliggende apparaat op het lokale netwerk kan vinden.
  • Beveiligde verbinding: maak een beveiligde verbinding met vertrouwde certificaten die deel uitmaken van dezelfde keten.

Vereisten

Tip

Dit artikel bevat gedetailleerde stappen en opties om u te helpen de juiste gatewayhiërarchie voor uw scenario te maken. Zie Een hiërarchie van IoT Edge-apparaten maken met behulp van gateways voor een begeleide zelfstudie.

Een gatewayhiërarchie maken

U maakt een IoT Edge-gatewayhiërarchie door bovenliggende/onderliggende relaties voor de IoT Edge-apparaten in het scenario te definiëren. U kunt een bovenliggend apparaat instellen wanneer u een nieuwe apparaat-id maakt of u kunt de bovenliggende en onderliggende items van een bestaande apparaat-id beheren.

De stap van het instellen van bovenliggende/onderliggende relaties machtigt downstreamapparaten om verbinding te maken met hun bovenliggende apparaat, net zoals ze verbinding zouden maken met IoT Hub.

Alleen IoT Edge-apparaten kunnen bovenliggende apparaten zijn, maar zowel IoT Edge-apparaten als IoT-apparaten kunnen onderliggende apparaten zijn. Een ouder kan veel kinderen hebben, maar een kind kan slechts één ouder hebben. Een gatewayhiërarchie wordt gemaakt door bovenliggende/onderliggende sets te koppelen, zodat het onderliggende van het ene apparaat het bovenliggende element van een ander apparaat is.

Standaard kan een bovenliggend element maximaal 100 onderliggende elementen hebben. U kunt deze limiet wijzigen door de omgevingsvariabele MaxConnectedClients in te stellen in de edgeHub-module van het bovenliggende apparaat.

In Azure Portal kunt u de bovenliggende/onderliggende relatie beheren wanneer u nieuwe apparaatidentiteiten maakt of door bestaande apparaten te bewerken.

Wanneer u een nieuw IoT Edge-apparaat maakt, hebt u de mogelijkheid om bovenliggende en onderliggende apparaten te kiezen uit de lijst met bestaande IoT Edge-apparaten in die hub.

  1. Navigeer in Azure Portal naar uw IoT-hub.
  2. Selecteer Apparaten in het menu Apparaatbeheer .
  3. Selecteer Apparaat toevoegen en schakel vervolgens het selectievakje IoT Edge-apparaat in.
  4. Naast het instellen van de apparaat-id en verificatie-instellingen kunt u een bovenliggend apparaat instellen of onderliggende apparaten kiezen.
  5. Kies het apparaat of de apparaten die u wilt gebruiken als bovenliggend of onderliggend item.

U kunt ook bovenliggende/onderliggende relaties voor bestaande apparaten maken of beheren.

  1. Navigeer in Azure Portal naar uw IoT-hub.
  2. Selecteer Apparaten in het menu Apparaatbeheer .
  3. Selecteer het IoT Edge-apparaat dat u wilt beheren in de lijst.
  4. Selecteer het tandwielpictogram van een bovenliggend apparaat instellen of onderliggende apparaten beheren.
  5. Voeg bovenliggende of onderliggende apparaten toe of verwijder deze.

Notitie

Als u programmatisch relaties tussen bovenliggende en onderliggende elementen wilt instellen, kunt u de C#-, Java- of Node.js IoT Hub Service SDK gebruiken.

Hier volgt een voorbeeld van het toewijzen van onderliggende apparaten met behulp van de C#SDK. De taak RegistryManager_AddAndRemoveDeviceWithScope() laat zien hoe u programmatisch een hiërarchie met drie lagen maakt. Een IoT Edge-apparaat bevindt zich in laag één, als het bovenliggende apparaat. Een ander IoT Edge-apparaat bevindt zich in laag twee, zowel als een onderliggend en een bovenliggend apparaat. Ten slotte bevindt een IoT-apparaat zich in laag drie, als het onderliggende apparaat van de laagste laag.

Certificaten genereren

Er moet een consistente keten van certificaten worden geïnstalleerd op apparaten in dezelfde gatewayhiërarchie om een veilige communicatie tussen zichzelf tot stand te brengen. Elk apparaat in de hiërarchie, ongeacht of een IoT Edge-apparaat of een IoT-downstreamapparaat, heeft een kopie van hetzelfde basis-CA-certificaat nodig. Elk IoT Edge-apparaat in de hiërarchie gebruikt vervolgens dat basis-CA-certificaat als de basis voor het Edge-CA-certificaat.

Met deze installatie kan elk downstream IoT Edge-apparaat de identiteit van hun bovenliggende apparaat verifiëren door te controleren of de edgeHub waarmee ze verbinding maken een servercertificaat heeft dat is ondertekend door het gedeelde basis-CA-certificaat.

Afbeelding van de certificaatketen die is uitgegeven door de basis-CA op gateway en downstreamapparaat

Zie Begrijpen hoe Azure IoT Edge certificaten gebruikt voor meer informatie over de vereisten voor IoT Edge-certificaten.

  1. Maak of vraag de volgende certificaten aan:

    • Een basis-CA-certificaat, het meest gedeelde certificaat voor alle apparaten in een bepaalde gatewayhiërarchie. Dit certificaat is geïnstalleerd op alle apparaten.
    • Tussenliggende certificaten die u wilt opnemen in de basiscertificaatketen.
    • Een Edge CA-certificaat en de bijbehorende persoonlijke sleutel, gegenereerd door de basis- en tussencertificaten. U hebt één uniek Edge CA-certificaat nodig voor elk IoT Edge-apparaat in de gatewayhiërarchie.

    U kunt een zelfondertekende certificeringsinstantie gebruiken of er een kopen bij een vertrouwde commerciële certificeringsinstantie zoals Baltimore, Verisign, Digicert of GlobalSign.

  2. Als u niet over uw eigen certificaten beschikt om te testen, maakt u één set basis- en tussencertificaten en maakt u edge-CA-certificaten voor elk apparaat. In dit artikel gebruiken we testcertificaten die zijn gegenereerd met behulp van test-CA-certificaten voor voorbeelden en zelfstudies. Met de volgende opdrachten maakt u bijvoorbeeld een basis-CA-certificaat, een bovenliggend apparaatcertificaat en een onderliggend apparaatcertificaat.

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

    Waarschuwing

    Gebruik geen certificaten die zijn gemaakt door de testscripts voor productie. Ze bevatten in code vastgelegde wachtwoorden en verlopen standaard na 30 dagen. De test-CA-certificaten worden gegeven voor demonstratiedoeleinden om u te helpen ca-certificaten te begrijpen. Gebruik uw eigen aanbevolen beveiligingsprocedures voor het maken van certificeringen en levensduurbeheer in productie.

    Zie Democertificaten maken om IoT Edge-apparaatfuncties te testen voor meer informatie over het maken van testcertificaten.

  3. U moet de certificaten en sleutels overdragen naar elk apparaat. U kunt een USB-station, een service zoals Azure Key Vault of met een functie zoals beveiligd bestand kopiëren gebruiken. Kies een van deze methoden die het beste overeenkomen met uw scenario. Kopieer de bestanden naar de voorkeursmap voor certificaten en sleutels. Gebruiken /var/aziot/certs voor certificaten en /var/aziot/secrets voor sleutels.

Zie Certificaten beheren op een IoT Edge-apparaat voor meer informatie over het installeren van certificaten op een apparaat.

Bovenliggend apparaat configureren

Als u het bovenliggende apparaat wilt configureren, opent u een lokale of externe opdrachtshell.

Als u beveiligde verbindingen wilt inschakelen, moet elk bovenliggend IoT Edge-apparaat in een gatewayscenario worden geconfigureerd met een uniek Edge-CA-certificaat en een kopie van het basis-CA-certificaat dat wordt gedeeld door alle apparaten in de gatewayhiërarchie.

  1. Controleer of uw certificaten voldoen aan de indelingsvereisten.

  2. Breng het basis-CA-certificaat, het bovenliggende Edge-CA-certificaat en de bovenliggende persoonlijke sleutel over naar het bovenliggende apparaat.

  3. Kopieer de certificaten en sleutels naar de juiste mappen. De voorkeursmappen voor apparaatcertificaten zijn /var/aziot/certs voor de certificaten en /var/aziot/secrets voor sleutels.

    ### 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. Wijzig het eigendom en de machtigingen van de certificaten en sleutels.

    # 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

    De uitvoer van de lijst met het juiste eigendom en de juiste machtiging is vergelijkbaar met het volgende:

    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. Installeer het basis-CA-certificaat op het bovenliggende IoT Edge-apparaat door het certificaatarchief op het apparaat bij te werken met behulp van de platformspecifieke opdracht.

    # 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

    Zie CBL-Mariner SSL CA-certificatenbeheer voor meer informatie over het gebruik update-ca-trustin EFLOW.

De opdracht rapporteert dat er één certificaat is toegevoegd aan /etc/ssl/certs.

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

Bovenliggend configuratiebestand bijwerken

IoT Edge moet al op uw apparaat zijn geïnstalleerd. Als dat niet het probleem is, volgt u de stappen voor het handmatig inrichten van één Linux IoT Edge-apparaat.

  1. Controleer of het /etc/aziot/config.toml configuratiebestand bestaat op het bovenliggende apparaat.

    Als het configuratiebestand niet op uw apparaat bestaat, gebruikt u de volgende opdracht om het te maken op basis van het sjabloonbestand:

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

    U kunt het sjabloonbestand ook gebruiken als verwijzing om configuratieparameters toe te voegen in deze sectie.

  2. Open het IoT Edge-configuratiebestand met behulp van een editor. Gebruik bijvoorbeeld de nano editor om het /etc/aziot/config.toml bestand te openen.

    sudo nano /etc/aziot/config.toml

  3. Zoek de hostnaamparameter of voeg deze toe aan het begin van het configuratiebestand. Werk de waarde bij als de FQDN (Fully Qualified Domain Name) of het IP-adres van het bovenliggende IoT Edge-apparaat. Voorbeeld:

    hostname = "10.0.0.4"

    Als u gatewaydetectie wilt inschakelen, moet elk IoT Edge-gatewayapparaat (bovenliggend) een hostnaamparameter opgeven die de onderliggende apparaten gebruiken om deze op het lokale netwerk te vinden. Elk downstream IoT Edge-apparaat moet een parent_hostname parameter opgeven om het bovenliggende apparaat te identificeren. In een hiërarchisch scenario waarbij één IoT Edge-apparaat zowel een bovenliggend als een onderliggend apparaat is, heeft het beide parameters nodig.

    De parameters hostnaam en trust_bundle_cert moeten zich aan het begin van het configuratiebestand bevinden vóór secties. Als u de parameter toevoegt vóór gedefinieerde secties, zorgt u ervoor dat deze correct wordt toegepast.

    Gebruik een hostnaam die korter is dan 64 tekens. Dit is de tekenlimiet voor een algemene naam van een servercertificaat.

    Consistent zijn met het hostnaampatroon in een gatewayhiërarchie. Gebruik FQDN's of IP-adressen, maar niet beide. FQDN of IP-adres is vereist om downstreamapparaten te verbinden.

    Stel de hostnaam in voordat de edgeHub-container wordt gemaakt. Als EdgeHub wordt uitgevoerd, wordt het wijzigen van de hostnaam in het configuratiebestand pas van kracht nadat de container opnieuw is gemaakt. Zie de sectie Bovenliggende configuratie controleren voor meer informatie over het controleren of de hostnaam is toegepast.

  4. Zoek de parameter vertrouwensbundel of voeg het toe aan het begin van het configuratiebestand.

    Werk de trust_bundle_cert parameter bij met de bestands-URI naar het basis-CA-certificaat op uw apparaat. Voorbeeld:

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

  5. Zoek of voeg de sectie Edge CA-certificaat toe aan het configuratiebestand. Werk de parameters voor het certificaat cert en de persoonlijke sleutel pk bij met de bestands-URI-paden voor het volledige certificaat en de sleutelbestanden op het bovenliggende IoT Edge-apparaat. Voor IoT Edge is vereist dat het certificaat en de persoonlijke sleutel de PEM-indeling (Privacy-Enhanced Mail) op basis van tekst hebben. Voorbeeld:

    [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. Controleer of uw IoT Edge-apparaat de juiste versie van de IoT Edge-agent gebruikt wanneer het wordt gestart. Zoek de sectie Default Edge Agent en stel de afbeeldingswaarde voor IoT Edge in op versie 1.5. Voorbeeld:

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

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

  7. Het begin van het bovenliggende configuratiebestand moet er ongeveer uitzien als in het volgende voorbeeld.

    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. Sla het configuratiebestand op en sluit het config.toml . Als u bijvoorbeeld de nano-editor gebruikt, selecteert u Ctrl+O - Write Out, Enter en Ctrl+X - Exit.

  9. Als u eerder andere certificaten voor IoT Edge hebt gebruikt, verwijdert u de bestanden in de volgende twee mappen om ervoor te zorgen dat uw nieuwe certificaten worden toegepast:

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

  10. Pas uw wijzigingen toe.

    sudo iotedge config apply

  11. Controleer op eventuele fouten in de configuratie.

    sudo iotedge check --verbose

    Notitie

    Op een nieuw ingericht apparaat ziet u mogelijk een fout met betrekking tot IoT Edge Hub:

    × productiegereedheid: de opslagmap van Edge Hub blijft behouden in het hostbestandssysteem - Fout

    Kan de huidige status van de EdgeHub-container niet controleren

    Deze fout wordt verwacht op een nieuw ingericht apparaat omdat de IoT Edge Hub-module niet wordt uitgevoerd. Als u de fout wilt oplossen, stelt u in IoT Hub de modules voor het apparaat in en maakt u een implementatie. Als u een implementatie voor het apparaat maakt, worden de modules op het apparaat gestart, inclusief de IoT Edge Hub-module.

Bovenliggende configuratie controleren

De hostnaam moet een gekwalificeerde domeinnaam (FQDN) of het IP-adres van het IoT Edge-apparaat zijn, omdat IoT Edge deze waarde gebruikt in het servercertificaat wanneer downstreamapparaten verbinding maken. De waarden moeten overeenkomen of u krijgt een foutmelding over niet-overeenkomende IP-adressen.

Als u de hostnaam wilt controleren, moet u de omgevingsvariabelen van de edgeHub-container inspecteren.

  1. Vermeld de actieve IoT Edge-containers.

    iotedge list

    Controleer of edgeAgent- en EdgeHub-containers worden uitgevoerd. De uitvoer van de opdracht moet vergelijkbaar zijn met het volgende voorbeeld.

    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. Inspecteer de edgeHub-container .

    sudo docker inspect edgeHub

  3. Zoek in de uitvoer de parameter EdgeDeviceHostName in de sectie Env .

    "EdgeDeviceHostName=10.0.0.4"

  4. Controleer of de parameterwaarde EdgeDeviceHostName overeenkomt met de config.toml hostnaaminstelling. Als deze niet overeenkomt, werd de EdgeHub-container uitgevoerd toen u de configuratie hebt gewijzigd en toegepast. Als u de EdgeDeviceHostName wilt bijwerken, verwijdert u de edgeAgent-container .

    sudo docker rm -f edgeAgent

    De edgeAgent - en EdgeHub-containers worden binnen enkele minuten opnieuw gemaakt en gestart. Zodra de EdgeHub-container wordt uitgevoerd, controleert u de container en controleert u of de parameter EdgeDeviceHostName overeenkomt met het configuratiebestand.

Downstreamapparaat configureren

Als u uw downstreamapparaat wilt configureren, opent u een lokale of externe opdrachtshell.

Als u beveiligde verbindingen wilt inschakelen, moet elk IoT Edge-downstreamapparaat in een gatewayscenario worden geconfigureerd met een uniek Edge-CA-certificaat en een kopie van het basis-CA-certificaat dat wordt gedeeld door alle apparaten in de gatewayhiërarchie.

  1. Controleer of uw certificaten voldoen aan de indelingsvereisten.

  2. Draag het basis-CA-certificaat, het onderliggende Edge-CA-certificaat en de onderliggende persoonlijke sleutel over naar het downstreamapparaat.

  3. Kopieer de certificaten en sleutels naar de juiste mappen. De voorkeursmappen voor apparaatcertificaten zijn /var/aziot/certs voor de certificaten en /var/aziot/secrets voor sleutels.

    ### 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. Wijzig het eigendom en de machtigingen van de certificaten en sleutels.

    # 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. Installeer het basis-CA-certificaat op het downstream-IoT Edge-apparaat door het certificaatarchief op het apparaat bij te werken met behulp van de platformspecifieke opdracht.

    # 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

    Zie CBL-Mariner SSL CA-certificatenbeheer voor meer informatie over het gebruik update-ca-trustin EFLOW.

De opdracht rapporteert dat er één certificaat is toegevoegd aan /etc/ssl/certs.

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

Downstreamconfiguratiebestand bijwerken

IoT Edge moet al op uw apparaat zijn geïnstalleerd. Als dat niet het probleem is, volgt u de stappen voor het handmatig inrichten van één Linux IoT Edge-apparaat.

  1. Controleer of het /etc/aziot/config.toml configuratiebestand bestaat op het downstreamapparaat.

    Als het configuratiebestand niet op uw apparaat bestaat, gebruikt u de volgende opdracht om het te maken op basis van het sjabloonbestand:

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

    U kunt het sjabloonbestand ook gebruiken als verwijzing om configuratieparameters toe te voegen in deze sectie.

  2. Open het IoT Edge-configuratiebestand met behulp van een editor. Gebruik bijvoorbeeld de nano editor om het /etc/aziot/config.toml bestand te openen.

    sudo nano /etc/aziot/config.toml

  3. Zoek de parameter parent_hostname of voeg deze toe aan het begin van het configuratiebestand. Elk downstream IoT Edge-apparaat moet een parent_hostname parameter opgeven om de bovenliggende parameter te identificeren. Werk de parameter bij om de parent_hostname FQDN of het IP-adres van het bovenliggende apparaat te zijn, zodat deze overeenkomt met wat er is opgegeven als de hostnaam in het configuratiebestand van het bovenliggende apparaat. Voorbeeld:

    parent_hostname = "10.0.0.4"

  4. Zoek de parameter vertrouwensbundel of voeg het toe aan het begin van het configuratiebestand.

    Werk de trust_bundle_cert parameter bij met de bestands-URI naar het basis-CA-certificaat op uw apparaat. Voorbeeld:

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

  5. Zoek of voeg de sectie Edge CA-certificaat toe aan het configuratiebestand. Werk de parameters voor het certificaat cert en de persoonlijke sleutel pk bij met de bestands-URI-paden voor het volledige certificaat en de sleutelbestanden op het IoT Edge-downstreamapparaat. Voor IoT Edge is vereist dat het certificaat en de persoonlijke sleutel de PEM-indeling (Privacy-Enhanced Mail) op basis van tekst hebben. Voorbeeld:

    [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. Controleer of uw IoT Edge-apparaat de juiste versie van de IoT Edge-agent gebruikt wanneer het wordt gestart. Zoek de sectie Default Edge Agent en stel de afbeeldingswaarde voor IoT Edge in op versie 1.5. Voorbeeld:

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

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

  7. Het begin van het downstreamconfiguratiebestand moet er ongeveer uitzien als in het volgende voorbeeld.

    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. Sla het configuratiebestand op en sluit het config.toml . Als u bijvoorbeeld de nano-editor gebruikt, selecteert u Ctrl+O - Write Out, Enter en Ctrl+X - Exit.

  9. Als u eerder andere certificaten voor IoT Edge hebt gebruikt, verwijdert u de bestanden in de volgende twee mappen om ervoor te zorgen dat uw nieuwe certificaten worden toegepast:

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

  10. Pas uw wijzigingen toe.

    sudo iotedge config apply

  11. Controleer op eventuele fouten in de configuratie.

    sudo iotedge check --verbose

    Tip

    Het ioT Edge-controleprogramma maakt gebruik van een container om een deel van de diagnostische controle uit te voeren. Als u dit hulpprogramma wilt gebruiken op downstream IoT Edge-apparaten, moet u ervoor zorgen dat ze toegang hebben tot de containerinstallatiekopieën mcr.microsoft.com/azureiotedge-diagnostics:latestof de containerinstallatiekopieën in uw privécontainerregister hebben.

    Notitie

    Op een nieuw ingericht apparaat ziet u mogelijk een fout met betrekking tot IoT Edge Hub:

    × productiegereedheid: de opslagmap van Edge Hub blijft behouden in het hostbestandssysteem - Fout

    Kan de huidige status van de EdgeHub-container niet controleren

    Deze fout wordt verwacht op een nieuw ingericht apparaat omdat de IoT Edge Hub-module niet wordt uitgevoerd. Als u de fout wilt oplossen, stelt u in IoT Hub de modules voor het apparaat in en maakt u een implementatie. Als u een implementatie voor het apparaat maakt, worden de modules op het apparaat gestart, inclusief de IoT Edge Hub-module.

Netwerkafwaartse apparaten isoleren

De stappen tot nu toe in dit artikel stellen IoT Edge-apparaten in als een gateway of een downstreamapparaat en maken een vertrouwde verbinding tussen deze apparaten. Het gatewayapparaat verwerkt interacties tussen het downstreamapparaat en IoT Hub, inclusief verificatie en berichtroutering. Modules die zijn geïmplementeerd op downstream IoT Edge-apparaten kunnen nog steeds hun eigen verbindingen met cloudservices maken.

Sommige netwerkarchitecturen, zoals die voldoen aan de ISA-95-standaard, proberen het aantal internetverbinding te minimaliseren. In deze scenario's kunt u downstream IoT Edge-apparaten configureren zonder directe internetverbinding. Naast het routeren van IoT Hub-communicatie via hun gatewayapparaat, kunnen downstream IoT Edge-apparaten afhankelijk zijn van het gatewayapparaat voor alle cloudverbindingen.

Deze netwerkconfiguratie vereist dat alleen het IoT Edge-apparaat in de bovenste laag van een gatewayhiërarchie directe verbindingen met de cloud heeft. IoT Edge-apparaten in de onderste lagen kunnen alleen communiceren met hun bovenliggende apparaat of onderliggende apparaten. Speciale modules op de gatewayapparaten maken dit scenario mogelijk, waaronder:

  • De API-proxymodule is vereist op elke IoT Edge-gateway met een ander IoT Edge-apparaat eronder. Dit betekent dat deze zich op elke laag van een gatewayhiërarchie moet bevindt, behalve de onderste laag. In deze module wordt een omgekeerde nginx-proxy gebruikt om HTTP-gegevens via netwerklagen via één poort te routeren. Het is zeer configureerbaar via de moduledubbel- en omgevingsvariabelen, dus kan worden aangepast aan de vereisten voor uw gatewayscenario.

  • De Docker-registermodule kan worden geïmplementeerd op de IoT Edge-gateway op de bovenste laag van een gatewayhiërarchie. Deze module is verantwoordelijk voor het ophalen en opslaan van containerinstallatiekopieën in de cache namens alle IoT Edge-apparaten in lagere lagen. Het alternatief voor het implementeren van deze module op de bovenste laag is het gebruik van een lokaal register of het handmatig laden van containerinstallatiekopieën op apparaten en het pull-beleid van de module zo instellen dat dit nooit gebeurt.

  • Azure Blob Storage in IoT Edge kan worden geïmplementeerd op de IoT Edge-gateway op de bovenste laag van een gatewayhiërarchie. Deze module is verantwoordelijk voor het uploaden van blobs namens alle IoT Edge-apparaten in lagere lagen. De mogelijkheid om blobs te uploaden maakt ook nuttige probleemoplossingsfunctionaliteit mogelijk voor IoT Edge-apparaten in lagere lagen, zoals uploaden van modulelogboeken en ondersteuning voor bundelupload.

Netwerkconfiguratie

Voor elk gatewayapparaat in de bovenste laag moeten netwerkoperators het volgende doen:

  • Geef een statisch IP-adres of FQDN (Fully Qualified Domain Name) op.

  • Verleent uitgaande communicatie van dit IP-adres aan uw Azure IoT Hub-hostnaam via poort 443 (HTTPS) en 5671 (AMQP).

  • Verleent uitgaande communicatie van dit IP-adres aan uw Azure Container Registry-hostnaam via poort 443 (HTTPS).

    De API-proxymodule kan verbindingen met één containerregister tegelijk verwerken. U wordt aangeraden alle containerinstallatiekopieën, inclusief de openbare installatiekopieën van Microsoft Container Registry (mcr.microsoft.com), op te slaan in uw persoonlijke containerregister.

Voor elk gatewayapparaat in een lagere laag moeten netwerkoperators het volgende doen:

  • Geef een statisch IP-adres op.
  • Verleent uitgaande communicatie van dit IP-adres aan het IP-adres van de bovenliggende gateway via poort 443 (HTTPS) en 5671 (AMQP).

Modules implementeren op apparaten in de bovenste laag

Het IoT Edge-apparaat op de bovenste laag van een gatewayhiërarchie heeft een set vereiste modules die erop moeten worden geïmplementeerd, naast de workloadmodules die u op het apparaat kunt uitvoeren.

De API-proxymodule is ontworpen om te worden aangepast om de meest voorkomende gatewayscenario's te verwerken. Dit artikel bevat een voorbeeld voor het instellen van de modules in een basisconfiguratie. Raadpleeg de API-proxymodule configureren voor uw gatewayhiërarchiescenario voor meer gedetailleerde informatie en voorbeelden.

  1. Navigeer in Azure Portal naar uw IoT-hub.

  2. Selecteer Apparaten in het menu Apparaatbeheer .

  3. Selecteer het IoT Edge-apparaat in de bovenste laag dat u configureert in de lijst.

  4. Selecteer Modules instellen.

  5. Selecteer Toevoegen in de sectie IoT Edge-modules en kies vervolgens IoT Edge-module.

  6. Werk de volgende module-instellingen bij:

    Instelling Weergegeven als
    Naam van IoT-module IoTEdgeAPIProxy
    URI installatiekopie mcr.microsoft.com/azureiotedge-api-proxy:latest
    Beleid voor opnieuw opstarten altijd
    Gewenste status actief

    Als u een andere versie of architectuur van de API-proxymodule wilt gebruiken, zoekt u de beschikbare installatiekopieën in de Microsoft-artefactregister.

    1. Voeg op het tabblad Omgevingsvariabelen een variabele toe met de naam NGINX_DEFAULT_PORT van het type Tekst met de waarde .443

    2. Werk op het tabblad Opties voor container maken de poortbindingen bij om te verwijzen naar poort 443.

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

    Met deze wijzigingen configureert u de API-proxymodule om te luisteren op poort 443. Als u poortbindingsconflicten wilt voorkomen, moet u de EdgeHub-module configureren om niet te luisteren op poort 443. In plaats daarvan routeert de API-proxymodule elk edgeHub-verkeer op poort 443.

  7. Selecteer Toevoegen om de module toe te voegen aan de implementatie.

  8. Selecteer Runtime-instellingen en zoek de edgeHub-module Container create Options. Verwijder de poortbinding voor poort 443 en laat de bindingen voor poort 5671 en 8883 staan.

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

  9. Selecteer Toepassen om uw wijzigingen op te slaan in de runtime-instellingen.

  10. Geef de volgende waarden op om de Docker-registermodule toe te voegen aan uw implementatie.

    1. Selecteer Toevoegen in de sectie IoT Edge-modules en kies vervolgens IoT Edge-module.

      Instelling Weergegeven als
      Naam van IoT-module registry
      URI installatiekopie registry:latest
      Beleid voor opnieuw opstarten always
      Gewenste status running

    2. Voeg op het tabblad Omgevingsvariabelen de volgende variabelen toe:

      Name Type Weergegeven als
      REGISTRY_PROXY_REMOTEURL Sms verzenden De URL voor het containerregister waaraan u deze registermodule wilt toewijzen. Bijvoorbeeld: https://myregistry.azurecr. De registermodule kan slechts aan één containerregister worden toegewezen, dus we raden u aan alle containerinstallatiekopieën in één privécontainerregister te plaatsen.
      REGISTRY_PROXY_USERNAME Sms verzenden Gebruikersnaam voor verificatie bij het containerregister.
      REGISTRY_PROXY_PASSWORD Sms verzenden Wachtwoord voor verificatie bij het containerregister.

    3. Werk op het tabblad Opties voor container maken de poortbindingen bij om te verwijzen naar poort 5000.

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

  11. Selecteer Toevoegen om de module toe te voegen aan de implementatie.

  12. Selecteer Volgende: Routes om naar de volgende stap te gaan.

  13. Als u wilt dat apparaat-naar-cloud-berichten van downstreamapparaten IoT Hub bereiken, moet u een route opnemen die alle berichten doorgeeft aan IoT Hub. Voorbeeld:

    1. Naam: Route
    2. Waarde: FROM /messages/* INTO $upstream

  14. Selecteer Beoordelen en maken om naar de laatste stap te gaan.

  15. Selecteer Maken om te implementeren op uw apparaat.

Modules implementeren op apparaten met een lagere laag

IoT Edge-apparaten in lagere lagen van een gatewayhiërarchie hebben één vereiste module die erop moet worden geïmplementeerd, naast de workloadmodules die u op het apparaat kunt uitvoeren.

Pulls voor containerinstallatiekopieën routeren

Voordat u de vereiste proxymodule voor IoT Edge-apparaten in gatewayhiërarchieën bespreekt, is het belangrijk om te begrijpen hoe IoT Edge-apparaten in lagere lagen hun module-installatiekopieën krijgen.

Als uw apparaten met een lagere laag geen verbinding kunnen maken met de cloud, maar u wilt dat ze module-installatiekopieën zoals gebruikelijk ophalen, moet het apparaat van de bovenste laag van de gatewayhiërarchie worden geconfigureerd om deze aanvragen af te handelen. Het apparaat in de bovenste laag moet een Docker-registermodule uitvoeren die is toegewezen aan uw containerregister. Configureer vervolgens de API-proxymodule om containeraanvragen naar deze module te routeren. Deze details worden besproken in de eerdere secties van dit artikel. In deze configuratie mogen de apparaten in de onderste laag niet verwijzen naar cloudcontainerregisters, maar naar het register dat wordt uitgevoerd op de bovenste laag.

In plaats van aanroepen mcr.microsoft.com/azureiotedge-api-proxy:1.1moeten apparaten met een lagere laag bijvoorbeeld worden aangeroepen $upstream:443/azureiotedge-api-proxy:1.1.

De $upstream parameter verwijst naar het bovenliggende element van een apparaat met een lagere laag, zodat de aanvraag door alle lagen wordt gerouteerd totdat deze de bovenste laag bereikt die een containeraanvragen voor de proxyomgeving naar de registermodule doorsturen. De :443 poort in dit voorbeeld moet worden vervangen door de poort waarop de API-proxymodule op het bovenliggende apparaat luistert.

De API-proxymodule kan slechts naar één registermodule worden gerouteerd en elke registermodule kan slechts worden toegewezen aan één containerregister. Daarom moeten installatiekopieën die apparaten met een lagere laag moeten worden opgehaald, worden opgeslagen in één containerregister.

Als u niet wilt dat apparaten met een lagere laag pull-aanvragen via een gatewayhiërarchie indienen, kunt u ook een lokale registeroplossing beheren. Of push de moduleinstallatiekopieën naar de apparaten voordat u implementaties maakt en stel vervolgens imagePullPolicy in op nooit.

Bootstrap van de IoT Edge-agent

De IoT Edge-agent is het eerste runtime-onderdeel dat moet worden gestart op elk IoT Edge-apparaat. U moet ervoor zorgen dat alle downstream IoT Edge-apparaten toegang hebben tot de edgeAgent-module-installatiekopieën wanneer ze worden opgestart en dat ze vervolgens toegang hebben tot implementaties en de rest van de module-installatiekopieën kunnen starten.

Wanneer u naar het configuratiebestand op een IoT Edge-apparaat gaat om de verificatiegegevens, certificaten en bovenliggende hostnaam op te geven, werkt u ook de containerinstallatiekopie van edgeAgent bij.

Als het gatewayapparaat op het hoogste niveau is geconfigureerd voor het afhandelen van aanvragen voor containerinstallatiekopieën, vervangt u deze door mcr.microsoft.com de bovenliggende hostnaam en api-proxy die naar de poort luistert. In het implementatiemanifest kunt u als snelkoppeling gebruiken $upstream , maar hiervoor moet de EdgeHub-module routering verwerken en die module is op dit moment niet gestart. Voorbeeld:

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

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

Als u een lokaal containerregister gebruikt of de containerinstallatiekopieën handmatig op het apparaat opgeeft, werkt u het configuratiebestand dienovereenkomstig bij.

Runtime configureren en proxymodule implementeren

De API-proxymodule is vereist voor het routeren van alle communicatie tussen de cloud en eventuele downstream IoT Edge-apparaten. Een IoT Edge-apparaat in de onderste laag van de hiërarchie, zonder downstream IoT Edge-apparaten, heeft deze module niet nodig.

De API-proxymodule is ontworpen om te worden aangepast om de meest voorkomende gatewayscenario's te verwerken. In dit artikel worden de stappen voor het instellen van de modules in een basisconfiguratie kort besproken. Raadpleeg de API-proxymodule configureren voor uw gatewayhiërarchiescenario voor meer gedetailleerde informatie en voorbeelden.

  1. Navigeer in Azure Portal naar uw IoT-hub.

  2. Selecteer Apparaten in het menu Apparaatbeheer .

  3. Selecteer het IoT Edge-apparaat in de onderste laag dat u configureert in de lijst.

  4. Selecteer Modules instellen.

  5. Selecteer Toevoegen in de sectie IoT Edge-modules en kies vervolgens IoT Edge-module.

  6. Werk de volgende module-instellingen bij:

    Instelling Weergegeven als
    Naam van IoT-module IoTEdgeAPIProxy
    URI installatiekopie mcr.microsoft.com/azureiotedge-api-proxy:latest
    Beleid voor opnieuw opstarten always
    Gewenste status running

    Als u een andere versie of architectuur van de API-proxymodule wilt gebruiken, zoekt u de beschikbare installatiekopieën in de Microsoft-artefactregister.

    1. Voeg op het tabblad Omgevingsvariabelen een variabele toe met de naam NGINX_DEFAULT_PORT van het type Tekst met de waarde .443

    2. Werk op het tabblad Opties voor container maken de poortbindingen bij om te verwijzen naar poort 443.

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

    Met deze wijzigingen configureert u de API-proxymodule om te luisteren op poort 443. Als u poortbindingsconflicten wilt voorkomen, moet u de EdgeHub-module configureren om niet te luisteren op poort 443. In plaats daarvan routeert de API-proxymodule elk edgeHub-verkeer op poort 443.

  7. Selecteer Runtime-instellingen.

  8. Werk de edgeHub-module-instellingen bij:

    1. Vervang in het veld Afbeelding door mcr.microsoft.com $upstream:443.
    2. Verwijder in het veld Opties maken de poortbinding voor poort 443 en laat de bindingen voor poorten 5671 en 8883 staan.
    {
  "HostConfig": {
    "PortBindings": {
      "5671/tcp": [
        {
          "HostPort": "5671"
        }
      ],
      "8883/tcp": [
        {
          "HostPort": "8883"
        }
      ]
    }
  }
}

  9. Werk de edgeAgent-module-instellingen bij:

    1. Vervang in het veld Afbeelding door mcr.microsoft.com $upstream:443.

  10. Selecteer Toepassen om uw wijzigingen op te slaan in de runtime-instellingen.

  11. Selecteer Volgende: Routes om naar de volgende stap te gaan.

  12. Als u apparaat-naar-cloud-berichten van downstreamapparaten wilt inschakelen om IoT Hub te bereiken, moet u een route opnemen waarmee alle berichten $upstreamworden doorgegeven. De upstream-parameter verwijst naar het bovenliggende apparaat in het geval van apparaten met een lagere laag. Voorbeeld:

    1. Naam: Route
    2. Waarde: FROM /messages/* INTO $upstream

  13. Selecteer Beoordelen en maken om naar de laatste stap te gaan.

  14. Selecteer Maken om te implementeren op uw apparaat.

Connectiviteit van onderliggend naar bovenliggend item controleren

  1. Controleer de TLS/SSL-verbinding van het onderliggende naar het bovenliggende item door de volgende openssl opdracht uit te voeren op het downstreamapparaat. Vervang <parent hostname> door de FQDN of het IP-adres van het bovenliggende item.

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

    De opdracht moet een geslaagde validatie van de bovenliggende certificaatketen bevestigen, vergelijkbaar met het volgende voorbeeld:

    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

    Het bericht 'Kan SSL_get_servername niet gebruiken' kan worden genegeerd.

    De depth=0 CN = waarde moet overeenkomen met de hostnaamparameter die is opgegeven in het configuratiebestand van config.toml het bovenliggende item.

    Als er een time-out optreedt voor de opdracht, zijn er mogelijk geblokkeerde poorten tussen de onderliggende en bovenliggende apparaten. Controleer de netwerkconfiguratie en -instellingen voor de apparaten.

    Waarschuwing

    Het gebruik van een volledig ketencertificaat in de sectie van [edge_ca] de gateway resulteert in certificaatvalidatiefouten van het downstreamapparaat. Met de openssl s_client ... bovenstaande opdracht wordt bijvoorbeeld het volgende geproduceerd:

    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

    Hetzelfde probleem treedt op voor TLS-apparaten die verbinding maken met het downstream-IoT Edge-apparaat als het certificaat voor volledige ketenapparaten niet wordt gebruikt en geconfigureerd op het downstreamapparaat.

Microsoft Defender for IoT integreren met IoT Edge-gateway

Downstreamapparaten kunnen worden gebruikt om de microagent van Microsoft Defender for IoT te integreren met de IoT Edge-gateway met behulp van downstreamapparaatproxy.

Meer informatie over de Defender for IoT-microagent.

Microsoft Defender for IoT integreren met IoT Edge met behulp van downstreamapparaatproxy:

  1. Meld u aan bij het Azure-portaal.

  2. Ga naar Apparaten voor IoT Hub-apparaatbeheer>Your Hub>>

  3. Selecteer uw apparaat.

    Schermopname die laat zien waar uw apparaat zich bevindt voor selectie.

  4. Selecteer de DefenderIotMicroAgent moduledubbel die u hebt gemaakt op basis van deze instructies.

    Schermopname van de locatie van DefenderIotMicroAgent.

  5. Selecteer de knop om de verbindingsreeks (primaire sleutel) te kopiëren.

  6. Plak de verbindingsreeks in een tekstbewerkingstoepassing en voeg de GatewayHostName toe aan de tekenreeks. De GatewayHostName is de volledig gekwalificeerde domeinnaam of het IP-adres van het bovenliggende apparaat. Bijvoorbeeld: HostName=nested11.azure-devices.net;DeviceId=downstream1;ModuleId=module1;SharedAccessKey=xxx;GatewayHostName=10.16.7.4.

  7. Open een terminal op het downstreamapparaat.

  8. Gebruik de volgende opdracht om de verbindingsreeks gecodeerd in utf-8 in de map Defender voor Cloud agent in het bestand connection_string.txt in het volgende pad te plaatsen: /etc/defender_iot_micro_agent/connection_string.txt

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

    De connection_string.txt moet zich nu op de volgende padlocatie /etc/defender_iot_micro_agent/connection_string.txtbevinden.

  9. Start de service opnieuw met behulp van deze opdracht:

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

  10. Ga terug naar het apparaat.

    Schermopname die laat zien hoe u terug navigeert naar uw apparaat.

  11. Schakel de verbinding met de IoT Hub in en selecteer het tandwielpictogram.

    Schermopname die laat zien wat u moet selecteren om een bovenliggend apparaat in te stellen.

  12. Selecteer het bovenliggende apparaat in de weergegeven lijst.

  13. Zorg ervoor dat poort 8883 (MQTT) tussen het downstreamapparaat en het IoT Edge-apparaat is geopend.

Volgende stappen

Hoe een IoT Edge-apparaat kan worden gebruikt als gateway

De API-proxymodule configureren voor uw gatewayhiërarchiescenario