Suggestions about the project

[heiye1024]

I like this project very much, and I suggest adding the following features:

1. Traffic statistics function
2. api interface
3. Transactional database

[donaldzou]

Hi @heiye1024 , thank you very much for your suggestions! I will definitely look into a better solution on the database, and I do have thoughts on creating an api interface ;) Could you elaborate on what you mean of Traffic statistics function? Cheers!!

[heiye1024]

@donaldzou I am happy to wait for your return, the database can be recommended to use mongodb, about the traffic statistics, my advice is to periodical traffic statistics, such as is the day, month。

[donaldzou]

Hi! At the early stage of this project, I actually included all the traffic data inside the database. But then I figured out it might be using too much CPU for some system that have limited CPU. I'll consider reimplementing this functionality!

[heiye1024]

In previous tests, it was found that there is a high probability of causing read and write exceptions when there are many clients, so it is highly recommended to deploy a separate database。

[donaldzou]

Yes I do notice this problem, I will fix this problem either using MongoDB or switching to a newer version of TinyDB (the current database). I believe the newer version do have caching for the database, so it reduced the number of disk IO.

[heiye1024]

I would like to make a few more suggestions。

1. bulk export and import of configuration files。
2. automatic generation of client ip。

[ikidd]

1: agree, this wouldn't be too hard to implement though you would want some safeguards to make sure you're importing the correct peer list to a server as the IP range would need to match.

Frankly on #2, I'd be happy to just have a pop up list of peer-name - IP of all current peers available when I'm setting up a new peer, or sidebar with all the currently used IPs. Though a DHCP service would be glorious, I haven't seen anyone integrate that into WG yet.

3. I'd love to be able to build top level servers in the dashboard instead of having to drop to CLI.

[donaldzou]

1: agree, this wouldn't be too hard to implement though you would want some safeguards to make sure you're importing the correct peer list to a server as the IP range would need to match.

Frankly on #2, I'd be happy to just have a pop up list of peer-name - IP of all current peers available when I'm setting up a new peer, or sidebar with all the currently used IPs. Though a DHCP service would be glorious, I haven't seen anyone integrate that into WG yet.

3. I'd love to be able to build top level servers in the dashboard instead of having to drop to CLI.

For building top level servers, I'm still considering would it be a good idea to implement this into the dashboard, since there will be writing configuration file directly into /etc/wireguard. Trying to figure a way to add a server thru the wireguard CLI. And for showing a list for available IP when adding is the next thing to implement ;)

[ikidd]

I'd just write the /etc/wireguard/<new.tunnel>.conf file in plain text like you append peers currently. wg-quick start it like any other tunnel when you hit the slider button on the dashboard. Maybe add a button to every tunnel so you can choose whether it comes up on boot or not by executing a systemctl enable/disable wg-quick@<tunnelname>.

You'd want to validate the subnet used for the new tunnel against RFC private networks, and existing tunnel subnets. That could get a little involved. It would be similiar to the selection of a new address in a peer, where you'd want to suggest the next address available in that tunnel's subnet, and exclude existing ones. https://stackoverflow.com/questions/65351652/how-to-use-pythons-ipaddress-module-to-find-if-subnet-ip-is-within-a-bigger-sub. This could also be used to validate if a manually added peer IP is in the tunnel's address space.

Again, I know it's easy for me to armchair quarterback like this, wish I had the time to learn enough python to help.