1. Introduction
Qu'est-ce que Thread ?
Thread est un protocole de réseau maillé sans fil basse consommation basé sur les adresses IP, qui permet une communication sécurisée d'appareil à appareil et de cloud à appareil. Les réseaux Thread peuvent s'adapter aux changements de topologie pour éviter les défaillances en un point.
Qu'est-ce qu'OpenThread ?
OpenThread publié par Google est une implémentation Open Source de Thread®.
Qu'est-ce qu'un routeur de bordure OpenThread ?
Le routeur de bordure OpenThread (OTBR) publié par Google est une implémentation Open Source du routeur de bordure Thread.
NAT64
NAT64 est un mécanisme qui permet aux hôtes des réseaux IPv6 uniquement d'accéder aux ressources des réseaux IPv4. La passerelle NAT64 est un traducteur entre les protocoles IPv4 et IPv6.
Le traducteur NAT64, qui fait partie du routeur de bordure OpenThread, prend en charge la traduction des protocoles TCP, UDP et ICMP (ICMPv6).
Objectifs de l'atelier
Dans cet atelier de programmation, vous allez configurer un routeur de bordure OpenThread et un appareil Thread, puis activer et vérifier la communication entre les appareils Thread et les hôtes IPv4 sur Internet via un routeur de bordure OpenThread.
Points abordés
- Créer un routeur de bordure OpenThread avec des fonctionnalités NAT64.
- Communiquer avec les hôtes IPv4 depuis des appareils Thread
Ce dont vous avez besoin
- Une station de travail Linux, pour créer et flasher un NCP Thread, la CLI OpenThread, et tester la connectivité IPv4
- Raspberry Pi 4 avec 4 Go de RAM pour le routeur de bordure Thread. Votre poste de travail Linux doit être accessible via IPv4 depuis cet appareil.
- 2 cartes Nordic Semiconductor nRF52840 DK.
Topologie du réseau pour cet atelier de programmation:
2. Configurer le routeur de bordure OpenThread
Suivez l'étape de configuration OTBR de l'atelier de programmation de bordure Thread – Connectivité IPv6 bidirectionnelle et détection de services DNS pour créer le routeur de bordure OpenThread, avec le changement suivant:
Dans Build and install OTBR, vous devez indiquer au script d'activer le traducteur NAT64 dans OpenThread en définissant la variable d'environnement NAT64
sur 1
et NAT64_SERVICE
sur openthread
. Exécutez la commande suivante avant l'étape:
$ export NAT64=1 NAT64_SERVICE=openthread
Poursuivez l'atelier de programmation Routeur de bordure Thread – Connectivité IPv6 bidirectionnelle et détection de services DNS. Après avoir formé un réseau Thread, vous pouvez vérifier que le routeur de bordure publie un préfixe NAT64 via les commandes de la CLI OpenThread.
Tout d'abord, assurez-vous que notre routeur de bordure est opérationnel et que le NAT64 est activé sur celui-ci:
$ sudo ot-ctl state leader Done $ sudo ot-ctl nat64 enable Done $ sudo ot-ctl nat64 state PrefixManager: Active Translator: Active Done
Nous devrions constater que OTBR joue le rôle de leader du thread Thread et qu'il existe un préfixe NAT64 (fd4c:9574:3720:2:0:0::/96
dans notre cas) dans les données du réseau Thread:
$ sudo ot-ctl netdata show Prefixes: fd4c:9574:3720:1::/64 paos low 0800 Routes: fd49:7770:7fc5:0::/64 s med 0800 fd4c:9574:3720:2:0:0::/96 sn low 0800 Services: 44970 01 41000500000e10 s 0800 44970 5d fdd20e532b87b93f50ad4eea0450f1bfd11f s 0800 Done
Le préfixe NAT64 sera utilisé par les appareils Thread lorsqu'ils communiqueront avec un hôte IPv4.
3. Configurer l'appareil final Thread
Suivez l'étape de configuration des FTD de l'atelier de programmation "Créer un réseau Thread avec des cartes nRF52840" et l'atelier de programmation OpenThread pour créer et flasher un appareil final de la CLI nRF52840, en remplaçant l'étape suivante:
Dans Build et Flash, vous devez ajouter -DOT_DNS_CLIENT=ON
, -DOT_SRP_CLIENT=ON
et -DOT_ECDSA=ON
à la ligne de commande lorsque vous appelez script/build
:
$ cd ~/src/ot-nrf528xx $ rm -rf build $ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON -DOT_DNS_CLIENT=ON -DOT_SRP_CLIENT=ON -DOT_ECDSA=ON
Poursuivez l'atelier de programmation Créer un réseau Thread avec les cartes nRF52840 et l'atelier de programmation OpenThread. Une fois que l'appareil de fin a été flashé avec l'image de la CLI, suivez les instructions de Routeur de bordure Thread – Connectivité IPv6 bidirectionnelle et détection de services DNS pour configurer l'appareil final Thread.
Patientez quelques secondes après avoir configuré l'appareil de fin Thread, puis vérifiez si la connexion au réseau Thread a réussi. Vous devriez trouver un préfixe NAT64 à partir des données réseau (fd4c:9574:3720:2:0:0::/96
dans notre cas):
> netdata show Prefixes: fd4c:9574:3720:1::/64 paos low 0800 Routes: fd49:7770:7fc5:0::/64 s med 0800 fd4c:9574:3720:2:0:0::/96 sn low 0800 Services: 44970 01 41000500000e10 s 0800 44970 5d fdd20e532b87b93f50ad4eea0450f1bfd11f s 0800 Done
Assurez-vous que les données réseau correspondent à celles d'OTBR.
4. Communiquer avec des hôtes IPv4 depuis l'appareil final Thread
Vous pouvez désormais communiquer avec les hôtes du réseau IPv4 depuis l'appareil final que nous venons de configurer.
Envoyer des requêtes d'écho ICMP aux hôtes IPv4
À partir de la CLI de notre appareil final Thread:
> ping 8.8.8.8 Pinging synthesized IPv6 address: fd4c:9574:3720:2:0:0:808:808 16 bytes from fd4c:9574:3720:2:0:0:808:808: icmp_seq=15 hlim=119 time=48ms 1 packets transmitted, 1 packets received. Packet loss = 0.0%. Round-trip min/avg/max = 48/48.0/48 ms. Done
Le routeur de bordure crée un élément de mappage NAT64 pour cet appareil à l'aide de la commande nat64 mappings
:
$ sudo ot-ctl nat64 mappings | | Address | | 4 to 6 | 6 to 4 | +------------------+-------------------------------------------------------------+--------+-------------------------+-------------------------+ | ID | IPv6 | IPv4 | Expiry | Pkts | Bytes | Pkts | Bytes | +------------------+------------------------------------------+------------------+--------+----------+--------------+----------+--------------+ | 377ee63dd3127f1a | fd4c:9574:3720:1:1d61:b4c1:494f:f975 | 192.168.255.254 | 7190s | 1 | 16 | 1 | 16 | | | TCP | 0 | 0 | 0 | 0 | | | UDP | 0 | 0 | 0 | 0 | | | ICMP | 1 | 16 | 1 | 16 | Done
fd4c:9574:3720:1:1d61:b4c1:494f:f975
doit être l'adresse IPv6 de votre appareil Thread.
Exécutez la commande suivante à tout moment sur le routeur de bordure pour voir comment le trafic est comptabilisé.
Envoyer des requêtes DNS aux serveurs DNS IPv4
Utilisez dns resolve4
pour résoudre un nom d'hôte sur le réseau IPv4. L'adresse du serveur DNS peut également être une adresse IPv4:
> dns resolve4 example.com 8.8.8.8 Synthesized IPv6 DNS server address: fd4c:9574:3720:2:0:0:808:808 DNS response for example.com. - fd4c:9574:3720:2:0:0:5db8:d822 TTL:20456 Done
Communiquer via TCP
Il est possible d'établir des connexions TCP entre l'appareil final et les hôtes dans le réseau IPv4.
Supposons que l'adresse IP de votre hôte IPv4 Linux soit 192.168.0.2
.
Sur votre hôte IPv4 Linux, utilisez nc
pour écouter les connexions TCP:
$ nc -l 0.0.0.0 12345
Depuis votre appareil final Thread, établissez une connexion TCP et envoyez des messages à votre hôte Linux IPv4:
> tcp init Done > tcp connect 192.168.0.2 12345 Connecting to synthesized IPv6 address: fd4c:9574:3720:2:0:0:c0a8:2 Done > tcp send hello
Votre hôte IPv4 Linux génère les éléments suivants:
hello
Vous pouvez également envoyer des messages à partir de votre hôte IPv4 Linux vers l'appareil final Thread. Saisissez "world" et appuyez sur Entrée sur votre hôte IPv4 Linux exécutant nc
. Votre appareil final Thread génère les résultats suivants:
TCP: Received 6 bytes: world
Communiquer via UDP
Il est possible de communiquer via UDP entre les appareils Thread et les hôtes du réseau IPv4.
Supposons que l'adresse IP de votre hôte IPv4 Linux soit 192.168.0.2
.
Utilisez nc
pour écouter les connexions UDP:
$ nc -u -l 0.0.0.0 12345
Depuis votre appareil final Thread, établissez une connexion UDP et envoyez des messages à votre hôte Linux IPv4:
> udp open Done > udp connect 192.168.0.2 12345 Connecting to synthesized IPv6 address: fd4c:9574:3720:2:0:0:c0a8:2 Done > udp send hello Done
Votre hôte IPv4 Linux génère les éléments suivants:
hello
Vous pouvez également envoyer des messages à partir de votre hôte IPv4 Linux vers l'appareil final Thread. Saisissez "world" et appuyez sur Entrée sur votre hôte IPv4 Linux exécutant nc
. Votre appareil final Thread génère les résultats suivants:
6 bytes from fd4c:9574:3720:2:0:0:c0a8:2 12345 world
5. Activer/Désactiver NAT64 sur le routeur de bordure
Vous pouvez activer ou désactiver NAT64 à tout moment. Utilisez nat64 disable
pour désactiver NAT64. Utilisez nat64 state
pour vérifier l'état de NAT64.
$ sudo ot-ctl nat64 disable Done $ sudo ot-ctl nat64 state PrefixManager: Disabled Translator: Disabled Done
Après la désactivation, l'appareil ne publie plus de préfixe NAT64:
$ sudo ot-ctl netdata show Prefixes: fd4c:9574:3720:1::/64 paos low 0800 Routes: fd49:7770:7fc5:0::/64 s med 0800 Services: 44970 01 41000500000e10 s 0800 44970 5d fdd20e532b87b93f50ad4eea0450f1bfd11f s 0800 Done
De plus, les appareils du réseau Thread ne peuvent plus accéder à l'hôte IPv4 via ce routeur de bordure.
À partir de la CLI de notre appareil final Thread:
> ping 8.8.8.8 Error 13: InvalidState
Utilisez nat64 enable
pour activer le NAT64. L'annonce d'un préfixe NAT64 peut prendre un certain temps:
$ sudo ot-ctl nat64 enable Done $ sudo ot-ctl nat64 state PrefixManager: Idle Translator: NotWorking Done
Après quelques secondes, les composants NAT64 sont opérationnels:
$ sudo ot-ctl nat64 state PrefixManager: Active Translator: Active Done $ sudo ot-ctl netdata show Prefixes: fd4c:9574:3720:1::/64 paos low 0800 Routes: fd49:7770:7fc5:0::/64 s med 0800 fd4c:9574:3720:2:0:0::/96 sn low 0800 Services: 44970 01 41000500000e10 s 0800 44970 5d fdd20e532b87b93f50ad4eea0450f1bfd11f s 0800 Done
Notez que la désactivation de NAT64 efface le tableau de mappage:
$ sudo ot-ctl nat64 mappings | | Address | | 4 to 6 | 6 to 4 | +------------------+-------------------------------------------------------------+--------+-------------------------+-------------------------+ | ID | IPv6 | IPv4 | Expiry | Pkts | Bytes | Pkts | Bytes | +------------------+------------------------------------------+------------------+--------+----------+--------------+----------+--------------+ Done
6. Transférer les requêtes DNS vers les serveurs DNS en amont
Lorsque le protocole NAT64 est activé sur le routeur de bordure, OpenThread tente de transférer les requêtes DNS des domaines Internet vers les serveurs DNS en amont.
Cette fonction est prise en charge par le serveur DNS-SD interne. Vous devez donc vous assurer que le serveur DNS-SD est activé.
$ sudo ot-ctl srp server state running Done
Si ce n'est pas running
, activez-la:
$ sudo ot-ctl srp server enable Done
Assurez-vous que le proxy DNS en amont est activé:
$ sudo ot-ctl dns server upstream Enabled Done
Si ce n'est pas Enabled
, activez-la:
$ sudo ot-ctl dns server upstream enable Done
Sur les appareils finaux, assurez-vous que le client SRP est activé pour pouvoir envoyer des requêtes DNS au routeur de bordure:
> srp client state Enabled Done
Si ce n'est pas Enabled
, activez-la:
> srp client autostart enable Done
Sur votre appareil final, assurez-vous que le serveur DNS par défaut est le routeur de bordure:
> dns config Server: [fdd2:0e53:2b87:b93f:50ad:4eea:0450:f1bf]:53 ResponseTimeout: 6000 ms MaxTxAttempts: 3 RecursionDesired: yes Done
L'adresse IPv6 du serveur (fdd2:0e53:2b87:b93f:50ad:4eea:0450:f1bf
dans l'exemple ci-dessus) doit correspondre à l'une des adresses de votre routeur de bordure OpenThread.
Vous pouvez maintenant envoyer des requêtes DNS pour des domaines Internet depuis l'appareil final:
> dns resolve example.com DNS response for example.com. - 2606:2800:220:1:248:1893:25c8:1946 TTL:8720 Done > dns resolve4 example.com DNS response for example.com. - fd4c:9574:3720:2:0:0:5db8:d822 TTL:20456 Done
7. Félicitations
Félicitations, vous venez de configurer un routeur de bordure compatible avec NAT64 et de l'utiliser pour fournir un accès Internet aux appareils finaux Thread.
Documentation complémentaire
- Guides OpenThread
- Documentation de référence de la CLI OpenThread
- Documentation de référence de l'API OpenThread pour NAT64
- Documentation de référence de l'API OpenThread pour le DNS en amont
- Abstraction de la plate-forme OpenThread pour le DNS