space_server: dhcpd: Add classless static route for 10.42.0.0/16

[alloverallover]

WIP. Request for feedback :)

Change:
Add a Classless Static Route of 10.42.0.0/16 to some subnets of the DHCP server.

(Because some DHCP clients ignore default route when a Classless Static Route is set, it also sets the default route. See dhcp-options(5), RFC3442, and https://ral-arturo.org/2018/09/12/dhcp-static-route.html)

Background:
When connected to Labitat wifi (10.42.2.0/24), my laptop could not speak to a wired box on 10.42.1.0/24, if my Mullvad VPN was active.
Normally, when using space_server as default route and no VPN, traffic to other subnets will be correctly routed.
But because my VPN hijacks the default route, it also wrongly hijacks traffic to other local subnets.

Questions:

• Because we want wired boxes + users on Private wifi to be able to talk to clients on Free wifi (10.42.3.0/24), and wifi clients might also have VPN and thus be unable to reply, I also added a Classless Static Route to Free wifi. Is this actually needed? Maybe established connections will always route outside the VPN?

[alloverallover]

Actually, the solution I propose in this PR does not do what I want. I would actually like the routing to be identical between Labitat wifi, and wired, so it is easy to for example, add a static route via a wired machine, from a laptop on wifi.

The only clean solution to that problem I can think of, is if my laptop and the wired box are on the same subnet.

Unfortunately 10.42.1.0/24 and 10.42.2.0/24 are not in the same /23... and a /22 would also encompass the Free wifi, and admin net, which I'm not sure is desirable. So significant shuffling of IPs would be required to achieve that new merged wifi+wired subnet.

Does anyone have opinions about this idea? :)

[esmil]

Does anyone have opinions about this idea? :)

Yes, I would very much like to keep they layer 2 domains small to limit the blast radius if someone connects their router wrongly and provides a competing DHCP server or something like that, that is not unlikely in a hackerspace. And I'd also like the subnets to match the layer 2 domains.

The routing between the networks works exactly as intended as is. If you choose to override the default route you get from DHCP then you should also be to ip route add 10.42.0.0/16 via 10.42.2.1. In other words it shouldn't be up to the network to fix the custom setup you made on your own laptop.

[alloverallover]

(Note: all mentions of "wifi" refer to the SSID "Labitat" that requires your member password to use)

Does anyone have opinions about this idea? :)

Yes

Thx for the reply :)

I would very much like to keep they layer 2 domains small to limit the blast radius if someone connects their router wrongly and provides a competing DHCP server or something like that, that is not unlikely in a hackerspace.

Gotcha! So that if someone does something weird, there is still another way to connect that is undisrupted by whatever is going on in the other subnet, did I understand that right?
That's an important case that I didn't consider :) Couldn't that be just as well solved with an explicit backup-SSID, on a separate subnet? I don't see why we can't both a bridged and non-bridged wifi at the same time, on separate subnets. Is there something I missed that wouldn't be served by that solution?

And I'd also like the subnets to match the layer 2 domains.

Right - I could have phrased myself more clearly - that was my second suggestion :) That we have a shared subnet (like a /23), with a broadcast domain that spans both wifi and wired.

The routing between the networks works exactly as intended as is. If you choose to override the default route you get from DHCP then you should also be to ip route add 10.42.0.0/16 via 10.42.2.1.

My opinion is that networking should work for most common usecases out-of-the-box, without manual fiddling to get things like printing working. I consider a VPN to be a common usecase in a hackerspace :)
I assume that sending traffic between wifi and wired is supposed to work - because in the non-VPN case, it does. I am simply wanting to extend the existing functionality to more usecases :).

In other words it shouldn't be up to the network to fix the custom setup you made on your own laptop.

Sorry, but I think calling Mullvad VPN a "custom setup" is disingenuous. I think having a commercial/personal VPN for internet traffic is quite common, and I'm sure I'm not the only person using specifically Mullvad VPN. Purposefully letting the network be broken for such a common setup would need a very good reason. And I think we can solve the redundancy need in another way :)

Are there other features of the current setup, except the redundancy, that would disappear if we merged the subnets?