In fact it was what I supposed ...
In fact it was what I supposed ...
My go-to option at the moment is to use Zerotier, installed on both devices and linked to the same private network space, to make a RPi remotely accessible.
If you want to go the VPN route: check your home router, it might have VPN capabilities built-in. If you're the only one who's going to use this, you could use static-key encryption (doesn't require a certificate), which you can get up and running in minutes: https://openvpn.net/community-resources/static-key-mini-howto/
PiVPN is based on OpenVPN, which is definitely still maintained and isn't terribly difficult to get running.
If you don't want to do VPN, I'd do this:
- Pick a random high number port for your router to forward to port 1880 on your Pi
- Get an SSL cert either from Let's Encrypt (can be a pain) or just make a self-signed one using a tool like mkcert (you'll get security errors in some browsers, but it's still secure)
- Enable https by filling out that section in settings.js
- Also enable adminAuth, httpNodeAuth, and httpStaticAuth security measures in settings.js
Not really a pain any more.
@TotallyInformation it can be if you don't already have a web server set-up to expose the ACME challenges.
Nope, not any more. As long as you have a domain and can control the DNS to some degree it is easy and you no longer have to expose anything. Please read the post.
@TotallyInformation Touche, but I would say that having to use a DNS provider that supports DNS01 isn't a cakewalk either, especially if you already have many DNS entries.
Not trying to take away from your post, I just think it's more trouble than it's worth if the only thing you're going to expose is Node-RED. Just do a self-signed cert and ignore the security warnings or make the exception rules so you don't see the warning. The warnings are meaningless when it's hardware you control and you're the only one using it. Otherwise if it were a public server not in your possession and other people are using it, by all means, Let's Encrypt.
Thank you all , I'm planning to move like Paul suggest me 'cos for me it's much easy,using one raspberry like proxy reversed with nginx , and another raspberry with node-red running .
For me , it's the very first time that i run into security access problem ...
Well, it was actually very easy. I put all my DNS entries through the free tier of CloudFlare which supports Lets Encrypt. You don't have to mess with any of the DNS entries at all. In addition, Let's Encrypt now support wildcard and multi-domain certs so I bundled a big set into a single cert giving me lots of flexibility - the auto-renew runs quite happily on one of the Pi's so it all just works.
Anyway, each to their own but I wanted to make clear to others just how easy it is now to use Let's Encrypt.
I’ve been wondering about the same issue. I had port forwarding on for a year (don’t do that). I was going to check into a remote MQTT server with a dashboard. We hen send just the updates as needed. Mqtt would open the port and then close it. Correct? Wouldn’t that be the way to go on this?
Not sure that is correct, I suspect that the port would remain open. However that shouldn't be much of an issue as you are opening the port outwards, not inbound.
However, this approach really needs an authenticated connection and that requires an encrypted connection. While you can do it without encryption, it would mean sending your login details in free-text over the Internet, not ideal.
This is why I need to encrypt my traffic to and from Rasp.
Before publishing your ip port of Node red, make sure you set password for node red and node red user interface. Then from manage pallets, instal ngrok. The go to ngrok.com, create an account. After creating the account, there will be a tab left side. In that authuntication will be there. Click on that. There will be a key. Copy that. Now come back to the ngrok node in node red. Edit the authtoken and paste the key you copied from the website. Then give the port number in which your node red is running, usually 1880. Then select a region. Give HTTP protocol. Then in input type give input port . Leave the other options blank. Now create two input nodes. In one node give string "on" and on the other input node give string "off". Connect both to the ngrok node. Now create a debug node and connect to the other end of ngrok node. Deploy. Now inject on node. You will get the url on the debug node. Using that url you can access node red from any where. Note: for free users ngrok gives random url and the url will be available only for 8 hours. After that you have to generate a new authentication key. For paid version you can use constant domain for unlimited time.
hi, link is not working...
It did in 2019
Here it is, I will correct the original post too.
thank you bro..
Please don't use the default settings for NGROK though, they are not secure. There is a thread on the forum where I gave details but there is also this flow: Access Node-RED from the Internet securely using NGROK (flow) - Node-RED.
You can also use localtunnel
The advantage over mgrok is that you can define an url (using somthing as
lt -p 1880 -s subdomain) and you'll (nearly) always get that, as long as it isnt already used.The urls have the following format:
It is also free and open source, also unlimited connection time (until Raspberry reboots or connection crashes)
Downside is that you have to configure it over commandline, but once you have it, that can be automated (e.g via cron)
This option is not bad:
It's free, includes WAF, stats, ssl certificate rotation, OAuth integration, connection doesn't crash (multiplexing 3 redundant tunnels)...
Yes, the CloudFlare Zero Trust features are great with 50 accounts built into the free tier. Excellent for creating a secure front-end for your Node-RED dashboards/UI's as well as for access to the editor or the whole server.
The only disadvantage is that it is a fair bit more complex to set up.