Partager via

Détecter un service

  • Article

Important

Il s’agit de la documentation Azure Sphere (héritée). Azure Sphere (hérité) prend sa retraite le 27 septembre 2027 et les utilisateurs doivent migrer vers Azure Sphere (intégré) pour l’instant. Utilisez le sélecteur de version situé au-dessus du TOC pour afficher la documentation Azure Sphere (intégrée).

Sur Azure Sphere, les applications générales peuvent découvrir un service en utilisant la découverte de service DNS (DNS-SD). Les applications peuvent utiliser la découverte de service pour trouver des services réseau et effectuer la résolution de nom d’hôte pour pouvoir interagir avec le service via le pare-feu Azure Sphere. Le DNS multidiffusion (mDNS) peut également être utilisé pour effectuer la découverte de pair-à-pair sur un réseau local, ce qui est particulièrement utile quand les adresses IP et les noms d’hôte du point de terminaison de destination ne sont pas connus au moment de la conception.

Les applications utilisent des requêtes DNS-SD pour récupérer les enregistrements DNS auprès de serveurs DNS non locaux ou sur une liaison multidiffusion. Si le nom demandé se trouve sous le domaine de plus haut niveau .local, la requête fait l’objet d’une multidiffusion sur le réseau local via toutes les interfaces réseau activées ; sinon, une découverte de service monodiffusion est effectuée. L’exemple de service de découverte montre comment effectuer une découverte de service sur Azure Sphere.

Remarque

Le pare-feu Azure Sphere empêche les applications de communiquer avec des services non autorisés. Cependant, le fait d’autoriser des connexions sortantes vers des domaines de plus haut niveau .local dans le manifeste d’application peut accroître le risque de sécurité pour un appareil en permettant à une application de se connecter avec des services non autorisés qui sont publiés sur le réseau local. Les applications doivent autoriser les connexions sortantes vers des domaines de plus haut niveau .local seulement dans des environnements sécurisés qui empêchent les tiers non autorisés de publier des services. Pour fournir une protection supplémentaire dans ce scénario, Azure Sphere demande que les services découverts sur le réseau local se trouvent également sur le sous-réseau local.

Inclure des fichiers d’en-tête

Les applications qui détectent un service doivent inclure le fichier d’en-tête resolv :

 #include <resolv.h>

Autoriser une connexion de service

Avant d’effectuer une requête DNS-SD, vous devez ajouter le service à la fonctionnalité AllowedConnections du manifeste de l'application. Le pare-feu Azure Sphere autorise alors l’application à se connecter aux instances des services découverts en utilisant leurs noms d’hôte et leurs adresses IP associés. Si un service de domaine de plus haut niveau .local est spécifié, le pare-feu autorise les connexions seulement à des ressources découvertes sur le sous-réseau local.

Les types de noms de service suivants sont pris en charge dans la fonctionnalité AllowedConnections :

  • Nom de service DNS local, comme « _sample._tcp.local »
  • Nom de service DNS non local, comme « _sampleinstance._tcp.dns-sd.org »
  • Nom de l’instance de service local, par exemple « _sampleinstance._tcp.hostname.local »
  • Nom de domaine, comme « samplehost.contoso.com »
  • Adresse IP

Voici un extrait d’un manifeste d’application qui inclut un nom de service non local.

"AllowedConnections": [ "_http._tcp.dns-sd.org" ]

Effectuer une requête DNS-SD

Pour effectuer une requête DNS-SD, vous devez demander plusieurs types d’enregistrements DNS :

  • Les enregistrements PTR qui énumèrent les instances d’un service DNS.
  • Les enregistrements SRV et TXT qui contiennent les détails des instances de service, comme le nom d’hôte et le port.
  • Les enregistrements A qui contiennent les adresses IP des noms d’hôte récupérés.

Avant d’envoyer la requête, vous devez la créer et l’initialiser, puis ajouter un message de requête demandant l’enregistrement DNS. Vous pouvez créer et initialiser une requête DNS-SD en appelant la fonction POSIX res_init(). Vous pouvez créer un message pour la requête en appelant la fonction POSIX res_mkquery().

Envoyer une requête DNS monodiffusion

Lors d'une détection de service monodiffusion, vous pouvez envoyer la requête DNS-SD et récupérer la réponse en appelant la fonction POSIX res_send().

Pour envoyer une requête DNS-SD via un lien multidiffusion, l’application doit ouvrir un socket et envoyer la demande via le socket à l’adresse IP de bouclage 127.0.0.1 (port de destination 53). Une fois que la demande est envoyée, plusieurs réponses peuvent être retournées. L’application doit attendre et écouter pendant plusieurs secondes pour collecter toutes les réponses. Ceci est illustré dans l’exemple de service de découverte.

Important

Cette adresse IP de bouclage est une fonctionnalité bêta qui sera supprimée, puis remplacée dans les versions ultérieures. Un changement cassant est à venir pour les applications qui s'appuient sur l'adresse.

Connexions autorisées pour les hôtes avec plusieurs adresses IP autorisées

Le pare-feu Azure Sphere autorise les connexions à une seule adresse IP par nom d’hôte. Si un hôte dispose de plusieurs adresses IP, le pare-feu Azure Sphere autorise uniquement les connexions à une de ces adresses. Une application peut utiliser curl pour envoyer des requêtes HTTPS à un hôte qui a plusieurs adresses IP ; curl tente alors de se connecter à chaque adresse IP jusqu’à trouver l’adresse autorisée. L'application peut avoir besoin d'un certain laps de temps pour trouver l’adresse autorisée.