Closed qupfer closed 1 year ago
I don't fully understand the way that keys are stored in the database. Am I correct in thinking that I can safely add peers to the bottom of the db without disturbing existing keys? I am pretty sure that changing the order or adding a peer to the top would mess things up.
It's to long, I wrote this cr**. I will check next week about the real behavior. But if I remember correctly, you can add more hosts in the database, as new keys only added if not enough exit. However, as its a "mesh", you need to update all hosts anywhere for full connectivity.
Fair. The stability of shared keys still matters in a mesh though. If I replace the config with new keys and restart wireguard to load the new config, all existing devices will disconnect. If the keys don't change, the network will keep working while I do the maintenance.
Though, I am actually misusing this in a partial mesh where most of the clients are behind NAT :rofl:
It's an awful hack in my case because most of these preshared keys in the db are never read. I'll edit it at some point.
Hi again, I closed it and created a new approchach (will create PR later).
This (the closed one) branch started in a full dynamic option, there - on the fly - PSKs created during genconfig. As allways chaning PSK was annoying, I tried to make it more or less "stable". Was enough for me, but yes: Too much code and to compicated.
I wrote a much simpler, static way but just want to look one or more times on it before open the PR.
This will add a PSK feature to wg-meshconf. It can be activated with "--with-psk" like
wg-meshconf --with-psk init
or wg-meshconf --with-psk genconfig.If no or not enough PSKs are in the Database, they will created on-the-fly. This works well, but every hosts needs to use the new config files afterwards, as the PSKs didn't match anymore.
If enough keys are in the Database, it has a semi-static behaviour. As long no peer is removed (or switch position), the used PSKs should be he same on every
genconfig
run. Use the--with-psk init
to fill up the database. Be aware. As it creates for every peer<-->peer combination an individual key, the number of keys can grow fast with every addional peer (5 peers -> 10 Keys, 10 peers -> 45 Keys, 20 peers -> 190 Keys)FYI: This is one of my first real-use python programming. So feel free to make changes/optimizations. I'm happy it works as expected for me :-)