Je m'interroge sur comment faire en sorte que les ESP présents derrière une box puissent être accessibles depuis l'extérieur sans toucher à la config NAT.
En effet j'ai plusieurs appareils du style NEST ou autre qui se connectent au Wifi de la box, puis on y accède sans toucher à la config NAT de la box. Comment font-ils ?
En claire à la 1ère installation du produit ESP, je pense à ça :
Accéder à une page web interne à l'ESP
Renseigner les codes d'accès du routeur, chez moi une box.
=> L'ESP peut donc se connecter à la box.
Mais juste avec ça, ça ne suffit pas. il manque un truc du style :
Ouvrir une appli, sur mobile par exemple, qui avec un compte autorise ....
En fait j'en sais rien.
Sans doute que ces appareils initient une connexion sortante tous les ∆t pour voir si un message est en attente pour eux. Comme ce sont eux qui ont initié la communication, le NAT joue son rôle et la réponse revient directement à l'appareil émetteur
il y a aussi la possibilité d'un serveur intermédiaire dans ce cas. Votre appareil se connecte au serveur, votre téléphone qui n'est pas sur le même réseau aussi et c'est ce serveur intermédiaire visuel de tous qui sert à faire le transfert d'infos
Vu les milliers d'objets connectés au monde j'ai du mal à croire que ça se passe comme ça.
Il y aurait rapidement une surcharge du réseau.
Là j'y crois davantage, intéressant.
On imagine qu'à la 1ère connexion de l'ESP sur la box, il se connecte au fameux serveur intermédiaire. Du coup le serveur connait l'adresse IP.
ça peut marcher mais comment fait le serveur lorsque l'adresse de la box change, du genre assez souvent ?
Côté mobile, on se connecte au serveur sur page web. On imagine qu'un compte est lié à l'identifiant de l'ESP et ça match ... Le serveur transfert la requête à l'ESP.
C'est tiré par les cheveux, pas certain que ce soit ça.
Je vais naviguer sur goog.. pour en savoir davantage.
Vu les milliers d'objets connectés au monde j'ai du mal à croire que ça se passe comme ça
c'est comme cela que fonctionne le centre de notification de Google sur Android et Apple sur iOS... vous avez un démon qui tourne sur votre appareil et qui tous les ∆t va demander au centre de notification si quelque chose est dispo pour lui. ce sont des dizaines de milliards de requêtes par jour. Pourquoi pensez vous qu'ils ont des data center gigantesques ?
les applis qui veulent vous envoyer des données parlent en fait au Push Notification service en donnant l'identifiant de l'appareil qu'elle veulent joindre et un identifiant de service et le message. C'est ce message qui est retiré lors de la connexion et la notification est traitée. Elle peut prendre la forme de lancer une application qui était en tâche de fond et cette application va établir la connexion vers le monde extérieur.
C'est le principe du ∆t avec un très long temps... mais la connexion doit être maintenue ouverte.
il n'y a aucun moyen pour un serveur externe, une fois la connexion rompue, de revenir parler à un appareil dans votre réseau privé... Sinon bonjour le risque de piratage !!
PS: bien sûr des failles de sécurité notamment dans les routeurs permettent de passer outre. Un appareil qui a un canal de communication ouvert sur le monde est un risque de point d'entrée / d'attaque (man in the middle etc)
Merci pour ces explications, ça me donne des pistes.
Mais de manière générale, comment ça se passe lorsque l'IP du routeur change ?
Je connais la notion de DNS pour accéder à une adresse via un nom plus simple à retenir, mais tout le monde n'a pas de DNS chez soit. Et d'ailleurs, d'IP fixe non plus.
Quand on n'a pas d'IP fixe on utilise un DNS dynamique (DDNS ou DynDNS). il y a des solutions sur le marché
une recherche sur "DNS Dynamique gratuit" donne des trucs du genre
Personnellement (outre d'autres bidouilles locales - j'ai 2 réseaux distincts dont un qui sert pour l'exploration et les trucs risqués) j'ai un nom de domaine et un serveur hébergé chez OVH (en service partagé), ça coute pas très cher et vous avez un truc toujours joignable. Mes gadgets publient là bas et ce serveur héberge des applications qui consolident ces données. Comme cela je n'ouvre aucun port dans mon réseau perso. Tout se fait en sortie.
The U.S Department of Homeland Security urged all businesses to disable their UPnP following a cyberattack in 2013 impacting tens of millions of devices. Though this was about 8 years ago, UPnP-related cyberattacks are still being detected today.
➜ donc on peut jouer avec sur son réseau de test et d'exploration mais perso je ne mets pas ça actif dans mon réseau principal de la maison.
(cela dit c'est énormément déployé et actif par défaut sur nombre de box)
Si vous maîtrisez bien votre réseau c’est envisageable. Ça rend des services
Oui pour la question 1
Pour interroger les objets je peux le faire quand je suis sur le réseau local sinon je ne le fais pas ce sont les données compilées sur le serveur qui m’intéressent. Les apps agrègent les données pour et présentent les infos comme il faut.
Oui c’est le fonctionnement général et vous pouvez mettre de la pression sur le site d’interrogation car vous avez un vrai serveur dispo et pas un petit microcontroller. De plus ça permet de faire dormir les capteurs la majorité du temps et donc permet de les disséminer ou vous voulez avec juste une batterie pour le fonctionnement et avoir des semaines/mois/années de fonctionnement autonome.
Pour la seconde question :
Avec un VPS (Virtual Private Server) vous avez la main sur votre server
La plupart des hébergeurs ont une offre équivalente
Sinon l’hébergement de base c’est un nom de domain, un serveur HTTP avec PHP, du FTP et de l’espace dosage et une instance de base de données (et quelques apps pour créer un site web). Ça suffit pour commencer à jouer
Mon objectif est de piloter des machines à distance.
Chaque machine est équipée d'une carte électronique pour la gestion de capteurs (T°, P, ...) et pilote un certain nombre d'actionneurs (résistance de chauffe, relais, ...).
Cette carte incorpore une liaison RS485 qui me servira d'interface avec un module ESP32, pour la rendre accessible depuis le net.
L'idée est de pouvoir paramétrer et récupérer les datas en "temps réel" de telle ou telle machine.
De la contrôler à distance, de démarrer un cycle, tracer une courbe de chauffe ...
Par principe, il peut y avoir plusieurs machines derrière le même routeur, d'où mes précédentes questions.
Vers quelle architecture dois-je m'orienter ?
Je suis séduit par le Websocket pour l'aspect réactivité "temps réel".
J'ai encore du mal avec les clients/serveur.
Dans mon cas qui est client, qui est serveur ?
Mes machines offrent un service dans le sens où elles peuvent envoyer des datas, donc serveur.
Mais en même temps, l'appli web sera à l'initiative des requêtes, donc serveur aussi.
Mon raisonnement n'est pas bon.
il y a sans doute de nombreuses façon de procéder, on peut penser à une architecture distribuée.
vous avez besoin de pouvoir accéder depuis l'extérieur à chaque ESP donc vous devez résoudre cela. Si c'est en entreprise, il y a généralement des règles très précises sur les accès à distance au sein de l'intranet... au mieux vous rentrez dans la DMZ.
ça plaiderait pour un serveur d'agrégation par site, qui serait dans la DMZ et accessible depuis l'extérieur de façon sécurisée et serait aussi accessible sur l'intranet aux ESP. Il offrirait une API d'agrégation et contrôle de tous les ESP locaux. On peut envisager un broker MQTT par exemple tournant sur ce serveur et une architecture pub/sub entre les ESP et ce broker.
Vous avez ensuite un serveur global, sur internet, qui est la console de pilotage des serveurs intermédiaires, et éventuellement qui agrège les données des serveurs intermédiaires.
Les ESP ne voient que leur serveur local sur le réseau local.
Le serveur local n'accepte des communication entrantes que depuis le serveur central, en communication sécurisée.
Le serveur central est sur internet et offre une interface d'accès sécurisée
Il suffit d'attribuer, à chaque ESP, un port spécifique à "l'entrée" du routeur, l'ESP lui-même gardant le port par défaut (80).
De faire du port forwarding, port d'entrée d'ESPn forwardé sur ip et port par défaut de l'ESPn
Ce sont effectivement de petites entreprises, voir même des asso.
Ils n'ont pas forcément de connaissances sur les infras réseaux.
D'où mes précédentes interrogations sur l'UPnP, les config sans toucher au NAT, ...
Vous me direz, il y a toujours une confi mini qq part, c'est sûr.
Dans un 1er temps, je souhaiterais expérimenter une architecture simple.
Avec qq restrictions, certes, même si dans certains cas ça ne fonctionnera pas dû aux restrictions réseaux de certaines boites.
2 ESP connectés à un routeur avec redirection de port.
Les ESP embarquent le même soft, genre Websocket client : Websocket Client
Désolé j'ai peut-être pas le bon vocabulaire ...
Le serveur, hébergé sur VPS, ne stock pas les datas en BDD en provenance des ESP.
Il affiche seulement les datas sur une page web.
Côté utilisateur, 1 nom de domaine qui redirige vers le serveur pour accéder à la page d'authentification.
Une fois authentifié, le User accède à la 2nde page dans laquelle il voit la liste de ces qq machines.
Avec lesquelles il peut interagir.
Pour l'instant, le seul stockage qui me semble nécessaire ce sont les identifiants User associés aux adresses IP:port des machines.
Est-ce une architecture valable ?
En écrivant ces lignes, je me demande si on pourra agir sur une même machine via 1 PC ET 1 mobile en même temps ?
En fait je me demande si c'est pas l'inverse qu'il faut faire : Les ESP en serveurs Websocket
Je vais devoir me lancer pour expérimenter parce que là je suis perdu.
En fait je me demande si c'est pas l'inverse qu'il faut faire : Les ESP en serveurs Websocket
Les Websocket (WS) commencent leur vie en HTTP, donc soit l'ESP soit le serveur peuvent initier la connection du moment "qu'ils se voient" (ie il existe une route TCP/IP entre les 2) et qu'ils ont un point d'entrée HTTP sur le port 80 ou 443 (habituellement). Tout dépend de qui prend l'initiative de parler à qui. Une fois le canal ouvert, les WS permettent une communication full-duplex
Cest envisageable mais
bcp de configuration à faire pour chaque ESP (une entrée dans le routeur)
vous devez réfléchir à la sécurité de la connexion, envisager WSS = WebSocket secure: WS over TLS et valider l'origine lors de l'établissement de la connexion. (cf les risques comme Cable Haunt - Wikipedia)
vous aurez une certaine latence en consultation sur le serveur central, les ESP ne sont pas de bêtes de course s'il y a de nombreuses données à exporter.
Cela dit, si j'avais une petite entreprise ciblée par votre solution, je n'autoriserais pas des accès directs depuis internet à des appareils pilotant des appareils... Trop de risques de sécurité.
L'idée est de pouvoir paramétrer et récupérer les datas en "temps réel" de telle ou telle machine.
De la contrôler à distance, de démarrer un cycle, tracer une courbe de chauffe ...
Dans le cas du contrôle à distance , l'éxecution doit-elle impérativement être "immédiate" ?"
Quel est le délai maximal d'exécution toléré ?
Peut il être égal à la cadence de rafraîchissement des données envoyées ?
Si oui envisager des ESP32 clients envoyant leurs données à intervalle de temps fixe vers un serveur distant (ou Broker MQTT) et à chaque envoi prenant connaissance du nouveau paramétrage et des ordres.
Certains process supportent ce cadencement , d'autres non
MQTT j'y ai pensé mais pas pratique pour mon application.
J'aurai pas mal de paramètres à envoyer, et parfois des courbes à récupérer.
J'entreprends de développer la partie Web avec la suite Webdev.
Certains n'aiment pas mais chacun son avis. Je connais très bien Windev, pas encore Webdev.
Côté sécurité, WSS bien sûr, OAtuh2.
Côté latence, j'ai fait qq manip (sans la partie sécu) et ça va pas trop mal.
?
