Any way to do this? I would not like this to be public on my IP:14002. Using docker version. Where is it stored and how to password protect the dashboard? Thanks!
Yes. First of all - remove forwarding rule from your router for 14002 port.
1 Like
OK. I guess I just have to ssh my machine and run docker exec -it storagenode /app/dashboard.sh. Not what I wanted, but will do. More interested in how to password protect the GUI dashboard. It says way more than the CLI version.
If you do ssh anyway, you can just add -L 14002:localhost:14002 to your ssh command and open http://localhost:14002 in your local browser
My firewall does not like this. Returns channel 2: open failed: connect failed: Connection refused after logging in in the host via ssh. Note: I use a key to login without password.
It should not. The full command should looks like
ssh -L 14002:localhost:14002 svet0slav@your.public.address
You can also add option -N before -L option to do not actually login to shell. It will establish a connection and would wait for Ctrl-C to finish it.
If you have used a non-standard port (recommended), the command would look like this
ssh -L 14002:localhost:14002 -p 32137 svet0slav@your.public.addressYes. I surely use a custom port to ssh the machine, of course. 
ssh -N -L 14002:localhost:14002 -p 'PORT' 'USER@IP' returns…
bind [::1]:14002: Cannot assign requested address
The machine does not use IPv6. Only IPv4. Hm…
Then please try to replace localhost to 127.0.0.1, it will use IPv4 explicitly.
Perhaps your local PC complaining about bind. Then you can provide the 127.0.0.1 for your local host too:
ssh -NL 127.0.0.1:14002:127.0.0.1:14002 -p 'PORT' 'USER@IP'
That did not work for me. Tried firewalling, which did not work either.
iptables -t filter -A INPUT -p tcp -s MY_VPN_IP --dport 14002 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp -s MY_VPN_IP --dport 14002 -j ACCEPT
iptables -t filter -A INPUT -p udp -s MY_VPN_IP --dport 14002 -j ACCEPT
iptables -t filter -A OUTPUT -p udp -s MY_VPN_IP --dport 14002 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 14002 -j DROP
iptables -t filter -A OUTPUT -p tcp --dport 14002 -j DROP
iptables -t filter -A INPUT -p udp --dport 14002 -j DROP
iptables -t filter -A OUTPUT -p udp --dport 14002 -j DROP
The dashboard is listening on 127.0.0.1:14002, so you also need to route traffic to localhost then.
Example:
The other way - replace 127.0.0.1 in port mapping option to MY_VPN_IP, but if VPN is not running, the storagenode is likely will fail to start.
Trying to actually set firewall rules, so that dashboard is accessible only from one of my VPNs, so that dashboard is not visible to the public, if someone visits the domains or IPs of STORJ nodes on port 14002.
1 Like
Not really. It listens to public IP on my docker container settings, but the node address setting is a domain, in case I need to change the IP, migrate the nodes to other hardware, etc. Any idea why my iptables rules don’t work?
The full command I use to start the node on system start is
docker run -d --restart unless-stopped --stop-timeout 300 -p 28967:28967/tcp -p 28967:28967/udp -p PUBLIC_IP:14002:14002 -e WALLET="MY_WALLET" -e EMAIL="MY_EMAIL" -e ADDRESS="SUBDOMAIN.DOMAIN.TLD:28967" -e STORAGE="XXTB" --mount type=bind,source="IDENTITY_DIR",destination=/app/identity --mount type=bind,source="MOUNT_POINT",destination=/app/config --name NODE_NAME storjlabs/storagenode:latest
The iptables rules up there are in my custom firewall. Seems weird they don’t work.
The dashboard is not listening on MY_VPN_IP:14002
If your loopback working properly and you did not specify the IP in docker run command, i.e. -p 14002:14002, then dashboard would listen on any available interface, include MY_VPN_IP.
Or make it listen on MY_VPN_IP only, i.e. -p MY_VPN_IP:14002:14002
Please, remove PUBLIC_IP from the dashboard port. It could bind to it only if that PUBLIC_IP is locally accessible, i.e. your PC with storagenode connected directly to the internet without any router.
And your rules allow to connect to/from 14002 and MY_VPN_IP address.
By the way, OUT rules to 14002 from MY_VPN_IP are looking weird. They looks redundant.
You seem to be missing the point. I want the dashboard to be on the public IP, not any IP of the machine, because the machine has multiple IPs assigned to it on different adapters and ports so the port 14002 on the PUBLIC_IP`to be accessible only from VPN_IP, to which only I have access and could connect to, thus the dashboard would run ONLY on IP:PORT, but it won’t be accessible unless requested from VPN only I could connect from and making resolving IP:PORT or domain.tld:port unaccessible, if not using that VPN.
Why do you need so weird configuration?
I do not believe it’s possible, if you do not have NAT hairpin on your router and the PUBLIC_IP is not on your host.
Your setup seems too overcomplicated for the goal.
If you would use the -p 127.0.0.1:14002:14002 and ssh tunnel - you can open the dashboard from your remote device AND from the LAN AND from the host on http://localhost:14002
Because what you suggested did not work for me. I appreciate the effort, though.
Sorry about that. You need someone who used similar setups with multiple networks, include using VPN.
I just checked this setup in VM and it works. So, your initial post seems missed some important details.
What I have done:
- The dashboard port is listening on 127.0.0.1,
-p 127.0.0.1:14002:14002 - The ssh server with authorized_keys containing my public ssh key
- I added two rules
iptables -A INPUT --src 127.0.0.1 --protocol tcp --dport 14002 -j ACCEPT
iptables -A INPUT --src $IP_VPN --protocol tcp --dport 22 -j ACCEPT
- made tunnel from my PC
ssh -NL 14006:localhost:14002 USER@VM
- Opened http://localhost:14006 in my local browser
The dashboard is available
By the way, with ufw enabled it’s even more simple - only allowing ssh is enough to make ssh tunnel works.
Resurrecting ancient thread: but today there is a free and an extremely simple option: cloudflare zero trust.
You can install cloudflared to the same container/jail/host your node is running and bam — access from anywhere, protected by your favourite identity provider, like google or GitHub.