gluon
gluon copied to clipboard
freifunk-gluon
Feature request: How to best turn a Gluon node into a Gateway?
Feature request
What is the problem? For a larger apartment complex our Freifunk community runs two VDSL lines under our name and put a Debian machine to it that is configured as a gateway. That machine just broke and I wish I could just go and configure an edge router to act as a gateway, instead of going through the trouble to set up something from scratch again.
What is the desired behaviour? A "gateway-"-tab that asks "Is this router a gateway?" which then does not use the Mesh-VPN access the internet but instead offers the local internet connection to all the nodes it meshes with - directly or via the Mesh-VPN.
Many thanks!
gluon-alt-esc is/was? an attempt to directly share internet access at the wan port.
So this is quite related: https://github.com/freifunk-gluon/gluon/pull/1094
In my oppinion there should be no gateways in the ordinary sense. @christf and I have talked about a completely decentralized Gluon concept where each node can theoretically offer VPN and/or traffic exit services using a decentralized Kademlia-like database. The problem is that the network configuration is growing more complex and for avoiding any security issues due to misconfiguration, network namespaces would be a viable solution, but besides @lemoer having done some work on it, OpenWrt does not support network namespaces, yet. Another idea was to join forces with GNUnet.
Many thanks to @CodeFetch and @AiyionPrime, I already learned a lot from following your keywords and pointers. I do not know much more about how this all works than what is required to set up a gateway or to build a new firmware (or to maintain the BOINC package for OpenWrt). Today, a gateway I set up is a Debian machine - either on some remote machine or, and this is what I am after for this issue, on a small form factor industrial PC. For the remote I do not care since we would only have a few. But for the local machine, I still have some hope that we can scale this up towards a number that I would not want to maintain manually, so I am hoping for a regular Gluon instance to gain that functionality. These would be exit nodes - all the nodes already meshing with it can leave but the machine would not be seen in the site.conf because of the asymmetric VDSL and its dynamic IP. It should have a fastd connection to one of the regular gateways though, just like any regular router, so the net does not fragment, map and automated updates still work.
What I am missing is a module that would
- batctl gw server ...
- adds the masquerading
- provides a switch to enable it all on lua
- prepares DHCPd and address space
- extends the node-info page
If I am missing something then this is also why I think I should not design/prepare anything like this myself :o) Not alone, at least. If this thread would help with the identification of a minimal set of commands to turn a regular Gluon router into a gateway then this would already help my cause? Instead of adding a module I would then just copy+adjust+paste a recipe and maybe at some later stage help with work on the node-info page?
identification of a minimal set of commands to turn a regular Gluon router into a gateway then this would already help my cause
It's more complex than that. What's needed is:
- network namespaces and network configuration redesign for mesh-protocol-agnostic clean separation
- node2node VPN
- something to make gateways with different external IPs/IPv6 prefixes usable for clients with seamless roaming
What we've already got:
- ddhcp
Visualization in the status page is the least problem we'd need to worry about. Biggest problem I see is that there is not much interest or better say most Gluon-devs can't afford the free-time.
You say that this would need many things to be developed, but we have none of that with our Debian-base local setup. And it works. Works well enough that is. For us, every local gateway has its own subnet within a larger net that is handled by batman and treated equally for all gateways. The DHCPd positions that gateway as the gateway for that subnet. Roaming works, at least I think it does - is a bit tricky to test since the installation is a bit of an island and we are not doing it all much different than for the regular gateways.
What do I miss? Would it preferable to have this set up with OpenWrt instead of Gluon?
@smoe The reason I would like to have supernode capabilities built into Gluon is that Freifunk could become more decentralized. You seem to be hoping for less maintenance work, which is not really feasible. It's much more easy to maintain Ansible scripts for setting up a Debian gateway than maintaining a Gluon fork or similar. Otherwise you'd need to integrate the missing functionalities into OpenWrt/Gluon (like namespaces) to reduce the additional maintenance burden.
In Debian you have a more sophisticated process control, firewall, different routing tables without leakage/weird behaviour and much better maintained packages as Debian is a popular distribution for servers. E.g. running an exitnode/AS would be a nightmare on OpenWrt compared to Debian due to required BGP support. If someone would pay me well I might do such thing, but this is out of reach for a free-time project in my eyes.
@smoe: your list looks quite complete. One point missing is adjusting firewall rules to allow DHCP and router advertisements to pass.
Another / an easier option than fully implementing gateways in Gluon might be to only adjust the firewall and "batctl gw". And then attach your preferred router to the LAN port. Or if you're on a PC, add such a Gluon VM and a default OpenWrt VM. That would have a lot less changes to Gluon.
As far as I understand @CodeFetch's suggestions are overkill for what you want to achieve.
The gluon-alt-esc package should work for your use-case, too. Feel free to try it (if it still compiles). Major blockers/todos were validating that the routing table adjustments don't break other things and checking how much kernel size increases with the new ebtables-tiny nat and redirect targets. Other than that the feature itself worked as expected for me in my tests.
@T-X Thank you. I was hoping for this. Also many thanks to @CodeFetch again, but, well, I need something for more grounded. I like the suggestion to use Ansible/Chef/.. but this would also work for the OpenWrt router-to-turn-Gateway. Maybe that would be easiest for a start.
Let me just describe "the easier option" you mentioned in my own words to make sure I got you right. We start with the regular gluon mesh in that building that also comprises a regular gluon router, which is special since it knows how to connect to the regular Freifunk gateways with the MeshVPN. That "connecting router" is then changed to route Freifunk-external traffic to the local internet access point and only forwards to "bat0" what is Freifunk-internal?
The gluon-alt-esc I liked. But then again, if a few lines on the command line can achieve the same, then this would help my understanding and that may be preferable for a wider adoption, possibly also from the Gluon-maintainers' point of view.
@CodeFetch's suggestions are overkill for what you want to achieve.
@T-X From my experience with Gluon another approach just wouldn't get the attention/maintenance needed. Your gluon-alt-esc was moved to the community repository. If I understand smoe right, he really wants to use this e.g. on a KVM server as a supernode substitute. This will need a node2node VPN implementation. One could run a second instance of fastd or something, but with the diverse VPN methods and the aim to abstract them we would get a big messy routing approach without network namespaces. I just see implementing network namespace support and abstracting the networks by their function as the more promising and consistent approach. I really doubt that increasing routing table complexity will be accepted. Your gluon-alt-esc approach was already too much. So why should Gluon add the complexity without previously doing the network refactoring which is on the agenda for 4 years now?
I feel like I said anything I know about the topic and this branches off far too fast for my taste. I've unsubscribed; good luck @smoe !
@smoe So you don't want to run a gateway like a supernode, but just use gluon-alt-esc? gluon-alt-esc consists of a provider and a client package. You can run the provider-part on a node with internet connection and share the internet connection directly while still being able to access the Freifunk network via VPN. You can then setup the gluon-alt-esc client package on neighboring nodes to directly use the provider node's internet connection...
It seems I've understood you wrong. I've thought you wanted to run a supernode with Gluon... For the case mentioned above T-X's package is the right fit and you can't simplify it much further...