Change settings around VRM / ssh tunnel / remote access

[wiebeytec]

Current situation

The ssh tunnel for access to local services is started when:

• Remote support is enabled, or
• Remote console (VNC) on VRM is on

The problem is that remote Node-RED and Signal K also needs this tunnel, but there is no 'Node RED on VRM' option. It currently just says in the GUI: "Access node-RED via http://venus.local:1881 and via VRM". But via VRM only works if the ssh tunnel is on, so only when 'remote support' or 'remote console on VRM' is enabled.

Desired situation

• Probably a new option to 'expose local web services to VRM' should be made. I don't know what the best wording is. It affects both Node-RED and Signal K, but that is probably too long, and may change in the future.
• And, with the GUIv2, the ssh tunnel's run condition for remote console is no longer required, for most people. But, it's still used for when you're running a custom build of the wasm. I'm unsure how to deal with that.

TODO

VRM logger

• [x] act on VRM Portal == Off, while keeping the ability to log to offline storage.
• [ ] log the VRM Portal / Security Profile to VRM when not set to Off.

venus-html5-app

• [ ] help text should be updated, MQTT on LAN (plaintext) will become obsolete
• [x] it should connect to nginx, not directly to flashmq, see https://github.com/victronenergy/venus-html5-app/issues/384
• [ ] Something must be done about the https -> http redirect in Secure Mode, as is they point to eachother.

javascript-vnc-client

• [ ] The help text in javascript-vnc-client should be update to mention the new settings: "Make sure to enable Remote Console for LAN" will be no longer correct.

gui-v2

• [ ] https://github.com/victronenergy/gui-v2/issues/1254 (needs testing)

Others

• [ ] Improve / check downgrade paths
• [ ] Look at node-red if http:// can be made available when the Security Profile is Weak or Unsecured
• [ ] Perhaps rename the settings -> VncLocal to just VNC etc?
• [ ] Wiebe reported a inconsistent firewall state
• [ ] Add automated checks for settings migration

done

• [x] The dynamic forwarding rules can disallow VNC access when VRM Portal != FULL.
• [x] The gui-v1 start script should be updated to the new settings
• [x] Adjust the restore to default functionality accordingly
• [x] Migration path for MQTT should be added
• [x] The login doesn't survive a reboot at the moment

[mpvader]

The following would be taking it a bit wider, but how about we change the Logging to VRM setting (vrmlogger on/off) into a setting with three options. Name of the setting is VRM Portal. Options are:

1. Off
2. Read only. (vrmlogger is enabled, but gui-v1 and gui-v2 don't work remotely, and remote access over MQTT isn't available either)
3. Full access (default) (MQTT + the option for ssh tunnel)

The VRM two way communication setting, as well as the Remote console on VRM setting can then be removed. What we accomplish then is one setting less.

Resulting settings:

• Local gui (gui v1, gui v2). (on GUIv1: start ssh tunnel when VRM is 'full access')
• remote support (on, off) (always start SSH tunnel, and put the authorized_keys in place)
• vrm (off, read only, full access). 'Full access' starts flashmq and enables the MQTT bridge config. LAN access is only opened up in iptables when MQTT on LAN is also on.
• services -> Node-Red (start ssh tunnel when VRM is 'full access')
• services -> Signal-K (start ssh tunnel when VRM is 'full access')
• Added later, because a coming change requires this too: EVCS (start ssh tunnel when VRM is 'full access')
• services -> MQTT on LAN: starts flashmq and opens up the firewall, as already the case.

Services that are influenced:

• FlashMQ runs when services/mqtt on LAN or VRM full access is on. Bridge config is placed in when 'full access' VRM. LAN access is protected by iptables when MQTT on LAN is off. This is like this currently already.
• Firewall opens up access to MQTT LAN when services/MQTT on lan.
• SSH tunnel is started when (VRM is full access + service that needs it. OR 'remote support' is enabled.

(edited by Wiebe, finishing the thought)

[mpvader]

As discussed today, @jhofstee & @jepefe will review the idea and if they agree we go for this.