Contrôle de modules Yoctopuce à travers un filtre NAT

Contrôle de modules Yoctopuce à travers un filtre NAT

Lorsque l'on met en place un système d'automatisation chez soi pour une application de domotique, un problème courant est de le contrôler depuis l'extérieur. En effet, la connexion réseau via un routeur DSL protège en général le réseau domestique par un mécanisme de traduction d'adresse (NAT), qui rend invisible les machines locales depuis l'extérieur. Aujourd'hui, nous vous présentons une solution pour contourner ce problème sans affaiblir la sécurité de votre réseau privé. Une application pratique dans le domaine de la domotique suivra dans l'article de la semaine prochaine...


Théorie: la traduction d'adresse réseau, problème et solutions

Un routeur DSL qui effectue de la traduction d'adresse réseau (NAT) fonctionne un peu comme un petit central téléphonique privé: les postes internes peuvent s'appeler l'un l'autre ainsi que faire des appels vers l'extérieur, mais vu de l'extérieur, il n'existe qu'un numéro de téléphone officiel, attribué au central téléphonique lui-même. Les postes internes ne sont pas atteignables depuis l'extérieur.

Configuration typique d'un réseau domestique
Configuration typique d'un réseau domestique



Transposé en terme de réseau, cela donne ceci: les appareils connectés sur votre réseau domestique peuvent communiquer entre eux en utilisant une adresse IP locale (du genre 192.168.xxx.yyy), et contacter des serveurs sur Internet par leur adresse publique, mais vu de l'extérieur, vous n'avez qu'une seule adresse IP officielle, attribuée à votre routeur DSL exclusivement, et vos différents appareils réseau ne sont pas directement atteignables depuis l'extérieur. C'est assez contraignant, mais c'est en réalité grâce à cela que les virus informatiques ne peuvent pas profiter trop facilement à distance des vulnérabilités présentes dans les ordinateurs du commun des mortels.

Les réponses aux requêtes sortantes sont routées de manière transparente
Les réponses aux requêtes sortantes sont routées de manière transparente



... mais les connections entrantes sont forcément interceptées par le routeur
... mais les connections entrantes sont forcément interceptées par le routeur



Voir Internet sans être vu représente un avantage de sécurité énorme. Cependant, cela signifie qu'a priori, on ne peut pas simplement monter son propre serveur Web chez soi pour y contrôler une installation domotique depuis l'extérieur. Une solution à ce problème, préconisée par de nombreux vendeurs de domotique, consiste à donner une visibilité externe au serveur de domotique lui-même, en ajoutant une règle de routage dans la configuration NAT du routeur DSL. Le problème de cette solution est qu'il expose le serveur de domotique aux attaques de virus et de pirates externes. Et comme le coeur du serveur de domotique est en général un système d'exploitation comme les autres, il risque d'y avoir tôt ou tard une vulnérabilité qui sera découverte et qui permettra de pénétrer sur votre réseau privé. Cela n'est donc pas la solution la plus sûre.

Une première solution qui ne requiert pas de changement à la configuration NAT du routeur a été présentée il y a quelque temps: elle consiste à piloter votre maison à travers des e-mails. Néanmoins, cela demande d'écrire pas mal de code spécifique et limite les possibilités d'interactions.

La solution que nous vous proposons aujourd'hui est basée sur l'utilisation de notre API de programmation PHP dans le cadre d'un callback HTTP. Après avoir vu comment utiliser les callbacks pour enregistrer automatiquement des mesures sur Internet, nous allons voir comment prolonger cette approche pour réagir à un callback, par des actions sur la machine ayant effectué l'appel de callback.

L'approche par callback HTTP
L'approche par callback HTTP



Le VirtualHub et l'API par callback HTTP

L'installation logicielle sur votre PC qui servira de serveur de domotique est triviale: il suffit de copier la version du VirtualHub pour votre machine, et à le lancer automatiquement au démarrage, par exemple dans le fichier rc.local. Quand cela est fait, connectez-vous avec un navigateur (depuis votre réseau local) sur le port 4444, et vérifiez que vous pouvez piloter manuellement vos modules Yoctopuce branchés à la machine.

La logique de pilotage de votre solution de domotique personnalisée se trouvera sur un serveur Web publique, par exemple sur un hébergement mutualisé. C'est grâce à cela que vous pourrez l'atteindre depuis n'importe où, sans devoir ajouter de règle NAT à votre routeur DSL. Vous trouverez des offres d'hébergement mutualisé dès 2 EUR/mois chez OVH.com par exemple, mais presque n'importe quel fournisseur offrant PHP en version 5.2 ou plus devrait convenir.

Le script PHP qui va piloter les modules pourra utiliser l'API Yoctopuce habituelle. Par exemple, pour activer un Yocto-PowerRelay, on utilisera:

$multiprise = yFindRelay("multiprise");
$multiprise->set_output(Y_OUTPUT_ON);



La seule différence consiste à indiquer au tout début de notre script PHP comment trouver le VirtualHub, et à configurer le VirtualHub pour trouver notre script PHP. Rien de plus simple:

include("yocto_api.php");
include("yocto_relay.php");
// les modules sont sur le VirtualHub qui fait le callback
yRegisterHub("http://callback");



Sauvez votre script de pilotage PHP dans un fichier chez votre hébergeur (par exemple sous domotics/test.php, et ajoutez dans le même répertoire les fichiers de la librairie PHP de Yoctopuce (au minimum les fichiers yocto_api.php et yocto_relay.php). Il vous faudra utiliser la toute dernière version de la librairie PHP, disponible ici en attendant la prochaine version officielle dans les prochains jours.

Pour configurer le callback du VirtualHub, ouvrez un browser sur l'interface du VirtualHub, cliquez sur le bouton configure, puis sur le bouton edit à côté de Callback URL et choisissez le réglage POST en mode Yocto-API, comme ci-dessous:

Fenêtre de configuration des callbacks HTTP



En pressant le bouton Test, vous pourrez directement vérifier si votre commande par HTTP callback fonctionne, et voir les éventuels messages d'erreur rendus par PHP. Par exemple, selon les réglages de votre hébergeur Internet, il se peut que vous obteniez le message:

error: URL file-access is disabled in the server configuration

Si cela se produit, c'est que vous devez rajouter un fichier .htaccess dans le même répertoire que votre script, contenant simplement la ligne suivante:

php_flag "allow_url_fopen" "On"



Comment ça marche ?

Si vous connaissez un peu le protocole HTTP, vous devez vous demander comment nous pouvons faire marcher notre API à l'envers à travers du NAT. C'est très simple, il s'agit en réalité d'un comportement simplifié : lorsque le VirtualHub appelle le callback en mode Yocto-API, il poste dans la requête l'état complet de tous les capteurs branchés, au format JSON. Sur le serveur, l'appel initial à InitAPI("http://callback") déclenche l'analyse de toutes ces données postées et leur indexation dans une mémoire cache.

Ensuite, lorsque le script PHP fait des appels à l'API Yoctopuce,
- les lectures de valeurs sont effectuées d'après le contenu de la mémoire cache
- les changements d'état (actions) sont envoyés directement par le canal HTTP standard, avec un simple marqueur qui permet au VirtualHub de les détecter parmi le flux de sortie de la page, et de les exécuter, tout en ignorant les autres affichages faits par le script.

Il s'agit donc d'une utilisation parfaitement standard du protocole HTTP, qui peut donc fonctionner sans problème à travers le NAT.

Rendez-vous la semaine prochaine pour un exemple d'application basé sur ce principe !

Commenter aucun commentaire Retour au blog












Yoctopuce, get your stuff connected.