letscontrolit / ESPEasy

Easy MultiSensor device based on ESP8266/ESP32
http://www.espeasy.com
Other
3.25k stars 2.2k forks source link

Tunneling and VPN for remote control #3892

Open garudaonekh opened 2 years ago

garudaonekh commented 2 years ago

Hi,

I have used MQTT_VPN(https://github.com/martin-ger/MQTT_VPN) on several projects for testing. The result is quite impressive for small size UI project.

The idea of this MQTT_VPN is to allow remote access to ESP32 thru MQTT. With this I can remotely control my esp32 project like I control it locally. Many ioT projects I see on Github(Correct me, if I am wrong) is still relying on local UI so with this it's a plus. We need just to have a cloud MQTT server(I host on DigitalOcean which can serve around 50 to 100 devices at ease for 5$).

So my idea is to integrate it with ESPEasy so that we can remotely control ESPEasy from anywhere. But ESPEasy is too big and complicated for me to handle.

ANOTHER LEVEL is to use GPRS(2G or 4G), so user can remotely access their ESP32 using GPRS. I have also tried this on several small size project with the above MQTT_VPN. With both together, we don't rely on wifi anymore, which is very good for remote area or agriculture project. I use TTGO T-call and this https://github.com/levkovigor/ppposclient

The problems I have observe are: 1-It's too slow for big UI. For my case, I push the JS,Image,CSS and other asset to remote server so it ease the load. So the MQTT only handle AJAX and Websocket request.

2-I experience some PPPOS modem issues like it stop responding after some time, MQTT message issues,.. which I think we can either live with it or optimize.

Thanks;

TD-er commented 2 years ago

That's interesting and also seems to be able to combine with the idea we have (and Jimmy is working on) for the single page application (or "New UI"). It is then more like a REST API. But I don't see why we won't be able to accept it via other channels.

One thing I'm still a bit worried about, when configuring via MQTT, is how to determine authorization etc. For example changing MQTT credentials via MQTT is a very nice receipt for a Man-in-the-middle attack.

Another way could be to let one node on a local network with other nodes be the gateway and just forwarding things. Is that how you imagined it yourself? What is roughly the maximum message size you can transfer via this "IP VPN over MQTT" link? Would it be feasible to supply firmware updates?

garudaonekh commented 2 years ago

I don't have implement at security on the MQTT yet.

For my case, I run MQTT_VPN backend on the cloud.

sudo ./mqtt_vpn -i mq0 -a 10.0.1.1 -b tcp://my_broker.org:1883 -k secret -d

My ESP32 will subscribe to this my_broker.org.

User will access the cloud thru assign subdomain. My APACHE on the cloud will send the request to that specific IP for each ESP32 device.

Regarding the size, MQTT_VPN will break big data to multiple mqtt message itself. For firmware OTA, i haven't tried yet.

garudaonekh commented 2 years ago

Another way could be to let one node on a local network with other nodes be the gateway and just forwarding things. @TD-er I don't understand these 2 sentences

But I don't see why we won't be able to accept it via other channels.

Another way could be to let one node on a local network with other nodes be the gateway and just forwarding things.