unraid/webgui

IPv6 broken due to changes in rc.library.source in 6.12.x

Leseratte10 opened this issue · 5 comments

Leseratte10 commented

I stumbled upon some IPv6 issues upon updating one of my servers from 6.11.5 to 6.12.6, then stumbled upon this forum post and then the new file /etc/rc.d/rc.library.source that's been introduced since then. That forum post is from a month ago, without a response, and marked as "Annoyance" (which I don't agree with).

I found this note in the changelog which explains why all this was added:

Network improvements
We added a new section: Settings/Network Settings/Interface Extra

This new section allows the user to define which interfaces are used by the Unraid services. By default all regular interfaces with an IP address are included in the list of listening interfaces.

The tunnels of the built-in WireGuard function of Unraid are automatically added or removed from the list when the Wireguard tunnels are activated or deactivated. The user may exclude these tunnels from the list of listening interfaces.

To use the Tailscale or Zerotier interface, it is required to add the interface name or IP address of the communication to the list of included listening interfaces. Important: It is imperative that Tailscale or Zerotier container is running before the interface is added to the list. For more information, refer to this Community forum post.

Now, don't get me wrong, that's a good idea and I'm sure it'll be helpful for some people, but it doesn't look like it was implemented correctly at all, and once I took a closer look, I found multiple issues that are now causing trouble for me:

  • As the services are now listening on hardcoded IPs, they need to be notified / reloaded when the IPv6 prefix changes. I don't think that's currently supported so basically, once the IPv6 prefix changes, the Unraid server (SSH, WebUI and basically all services) will de-facto be offline until someone with IPv4 access or a local shell fixes stuff.

  • With IPv6, it's supported (and very common) to have multiple IPv6 prefixes on a single network. For example, one global (GUA) range from your ISP, and one local (ULA) range assigned by your router. I'm using ULAs in my network for VPNs and local network access. Unraid, however, with this new script, seems to assume that one interface has one IPv4 and one IPv6 each (in this case, the GUA) and completely ignores all other IPs. I had to work around that by manually adding my own ULA address to the "Include listening interfaces" setting - but that's still a terrible hack. What if the ULA prefix changes? And why can't I add "::" to get back the old behaviour?

  • The function unmask seems to assume that every single IPv4 network uses a /24 netmask, which is not the case. This should be read from the network interface or something to make sure the subnet size is correct. Looks like this will result in hard-to-notice bugs when people have a /16 prefix (or another prefix size) correctly configured but then only devices in the same /24 as the Unraid host will be able to connect ...

Is there an option or setting I'm missing to go back to the old sane behaviour of just listening on [::] so services are listening on all IPs the host has and don't have to be restarted or reloaded when IPs change?
Or will I need to write my own plugin / add-on to replace that whole file with a saner script that just throws "[::]" back into each config file?

SimonFair commented

I believe @bergware is already making changes in this area.

Leseratte10 commented

Yeah, I can see there have been some commits to that file recently.

Looking at the changes, though, it doesn't look like any of the points I mentioned have been adressed yet.

In the meantime, if someone else also runs into this issue and would prefer the old 6.11.5 behaviour of just listening on all IPs, I've created a small plugin to restore the old behaviour.

It basically makes the check function add the IPs "::" and "0.0.0.0" to the bind array, ignoring the new config.

https://github.com/Leseratte10/unraid-plugin-bind-all

Maybe this can be added to Unraid as a toggle in the settings to choose between the old behaviour (listen on any IP) and the new one, if these bugs take a bit longer to fix.

Ryker97 commented

Yeah, I can see there have been some commits to that file recently.

Looking at the changes, though, it doesn't look like any of the points I mentioned have been adressed yet.

In the meantime, if someone else also runs into this issue and would prefer the old 6.11.5 behaviour of just listening on all IPs, I've created a small plugin to restore the old behaviour.

It basically makes the check function add the IPs "::" and "0.0.0.0" to the bind array, ignoring the new config.

https://github.com/Leseratte10/unraid-plugin-bind-all

Maybe this can be added to Unraid as a toggle in the settings to choose between the old behaviour (listen on any IP) and the new one, if these bugs take a bit longer to fix.

when I used it ,the smb service can not work normally.

Leseratte10 commented

Thanks for the report, updated my plugin to fix that.