Re: RFC: wg syncpeers wg0 wireguard.conf
Hi, walk_remove_by_peer does seem inefficient. Judging by the stack, I guess it walks the tree looking for addresses from a specific peer. That would be roughly O(A log A) operations for A addresses, in total O(N A log A) if removing all of them. A simple fix would be to know what you want to remove. Then you can find it fast in the search tree. Does showing peer configuration also scan the entire tree? If you need to store a list of addresses associated with a peer (seems like a good idea), memory needed should be no more and probably less than the tree itself. I can explain an algorithm, or tell you how to fix it, but I'm not saying I will code it (yet). WRT setconf/addconf/syncconf >From a user point of view, I do not see a reason to disconnect peers which are not modified when changing confguration. It seems excessive and not quite useful. After reading wg man page [1], I do have questions about what these commands do. 1) When setconf-ing an interface without optional parameters, and the interface was configured with a non-default values, do they remain or are they reset to defaults? I guess either would be fine as long as it is consistent. Both interface and peer configuration. a) Listen port - if not specified, I would leave as is. It has already been chosen (perhaps) randomly. 2) If a peer is connected and the configured endpoint changes, does the endpoint change? Does the peer get disconnected? If a peer has roamed, you edit another peer and run setconf, it doesn't seems nice to disconnect the roaming peers. OTOH, if you want change the address (e.g. to a another valid one), it would be nice if the peers moved to the new addresses in a reasonable time. 3) Regarding addconf - after reading the man page, I'm not sure what the intent is, or what does it do. a) It says only one interface section can be in a file, is changing the interface configuration permitted? If not, it should probably be called addpeers. b) Are multiple definitions of the same peer permitted? If so, what is the result - can I split the definitions, or are the previous ones discarded? What about ips, are they summed or overriden? Regards, Ivan [1] https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8 On 14. 6. 2019 20:09, Jason A. Donenfeld wrote: > Hey Lonnie, > > If your changes are user-facing, it's probably not a good idea to > create confusion by introducing distro-specific subcommands. > > I'm leaning toward Steven's suggestion of nixing addconf and making > setconf behave like syncconf. But two hurdles remain: > > - walk_remove_by_peer is very inefficient. That *must* be to be > improved for this to be feasible. There's some interesting algorithms > programming in allowedips.c to be tackled for that. Maybe > node->peer_list can be used. (CC'ing Ivan in case he wants to put his > mind to work on that.) > - A decision needs to be made on consistency: do we want to read back > the end result and compare it? Or will that kind of looping logic lead > to other types of DoS or latency spikes? > > Jason > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
Hi Jason, There are a few projects on github that show up under “Wireguard dynamic” and most have to do with the functionality I believe you guys are discussing here (please correct me if I’m wrong) which is how to update the peers on the wg interface (both add and remove) from the configuration. There is one called Wireguard-dynamic that has to do with configuring a mesh by using a key-value DHT or a shared kv store. https://github.com/segator/wireguard-dynamic/issues/2#issuecomment-502478520 There is also P2P-Wireguard in Rust that uses a STUN server to support nodes behind NAT. And wg-broker (another project) that is closer to what I’m looking for. The official wg-dynamic I think has to do with DHCP like functionality (from what I managed to read so far) so I understand its completely separate but the confusion around what “dynamic” is refers to is unfortunate (naming is always a tricky issue) Btw, may I suggest having two mailing lists: one for users like myself and another for contributors and core developers? In Tensorflow and other OSS we have such separation between the platform Developers and the users. On Fri, Jun 14, 2019 at 11:02 AM Jason A. Donenfeld wrote: > On Fri, Jun 14, 2019 at 8:01 PM Marc Fawzi wrote: > > p.s. does this overlap with similar planned in wg-dynamic? > > No, the topics have no similarities. > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
> On Jun 14, 2019, at 1:09 PM, Jason A. Donenfeld wrote: > > I'm leaning toward Steven's suggestion of nixing addconf and making > setconf behave like syncconf. But wouldn't the current 'setconf' (overwrite existing) always be faster than a combo 'setconf/syncconf' (sync with existing) ? I have this nagging feeling that both 'setconf' and 'syncconf' should exist, if not for efficiencies but for unforeseen reasons related to the different functionalities: Start 'setconf' and Reload 'syncconf'. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
Hey Lonnie, If your changes are user-facing, it's probably not a good idea to create confusion by introducing distro-specific subcommands. I'm leaning toward Steven's suggestion of nixing addconf and making setconf behave like syncconf. But two hurdles remain: - walk_remove_by_peer is very inefficient. That *must* be to be improved for this to be feasible. There's some interesting algorithms programming in allowedips.c to be tackled for that. Maybe node->peer_list can be used. (CC'ing Ivan in case he wants to put his mind to work on that.) - A decision needs to be made on consistency: do we want to read back the end result and compare it? Or will that kind of looping logic lead to other types of DoS or latency spikes? Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
<< I'm very much in favour of this (updating `setconf` to use this new syncronisation approach), if anything it feels more logical and is how I initially (wrongly) assumed `setconf` behaved when starting out with WireGuard a while back. >> +1 ... it's better to keep the same command if its definition can be expanded (fewer things to remember and less mental clutter) p.s. does this overlap with similar planned in wg-dynamic? On Tue, Jun 11, 2019 at 5:23 PM Steven Honson wrote: > On Wed, 12 Jun 2019, at 3:56 AM, Jason A. Donenfeld wrote: > > The other thing I was wondering is: aside from performance and races > > as described above, why not just make this the functionality of > > `setconf`? Then there's be no need to introduce a new subcommand. In > > otherwords, the idea would be to make `setconf` not destroy existing > > peers if we're going to be re-adding them again. > > I'm very much in favour of this (updating `setconf` to use this new > syncronisation approach), if anything it feels more logical and is how I > initially (wrongly) assumed `setconf` behaved when starting out with > WireGuard a while back. > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
> On Jun 11, 2019, at 12:28 PM, Jason A. Donenfeld wrote: > > I gave it a stab in this branch: > https://git.zx2c4.com/WireGuard/commit/?h=jd/syncconf Try it out and > let me know if it does what you had in mind? More testing, "syncconf" is working great. A real world example, connecting over WG to a remote instance, using a web interface for remote WG management: 1) "Restart WireGuard VPN" takes 35 seconds (using "setconf"), 17 seconds for the WG peer to reestablish and the rest of the time is most likely the TCP backoff timers for the HTTPS web interface session, totaling 35 seconds. 2) "Reload WireGuard VPN" takes << 1 second (using "syncconf"), no noticeable impact at all, even when editing the AllowedIPs of the peer tunnel used for access. Our project will be using Jason's elegant "syncconf" (above URL) as a patch, up until an official solution is committed. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
On Tue, Jun 11, 2019 at 11:08 PM Lonnie Abelbeck wrote: > > On Jun 11, 2019, at 12:28 PM, Jason A. Donenfeld wrote: > > > > One of the things that always goes wrong with "sync" algorithms in > > software -- and the commit above at the moment is no exception -- is > > that they're kind of racey. In order to synchronize, we have to read > > the current state, compare it, and then set our new state. But in > > between, the state could have changed out from underneath us. One > > strategy for this is to just do nothing and put some notice in the man > > page. Another strategy is to read back the result at the end, compare > > it, and loop like this until we reach the stable state. This then > > requires implementing some equality function. > > If "wg" does not offer "syncconf", users will be hacking together their own > sync solution and it will no doubt be more racey than your tight code. > +1 > > The other thing I was wondering is: aside from performance and races > > as described above, why not just make this the functionality of > > `setconf`? Then there's be no need to introduce a new subcommand. In > > otherwords, the idea would be to make `setconf` not destroy existing > > peers if we're going to be re-adding them again. > > I vote to keep "setconf" as is, with the addition of the "syncconf" > subcommand. > This keeps "setconf" faster, and unchanged, typically used for initial > configuration. > Then "syncconf" would typically be used for followup live updates. > I guess you've seen Cisco (an other) network devices having running and the startup config. I think this is quite similar idea here. While I understand the need to sync, looking at the code it is more of an `updateconf` (i.e. file -> memory) operation, while I'd expect sync to be 2-way sync where startup/saved/disk/file/whatever config is equal to the running/current/memory/state/whatever config by some automagic algorithm. Looking from a high place, a bit tired and before going to bed, these are my thoughts: AFAIR, the way to save config is `wg showconf wg0 >wg0.conf` (running -> startup)... Then why is `wg setconf` requiring a file, i.e. why not `wg setconf wg0 https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
> On Jun 11, 2019, at 12:28 PM, Jason A. Donenfeld wrote: > > I gave it a stab in this branch: > https://git.zx2c4.com/WireGuard/commit/?h=jd/syncconf Try it out and > let me know if it does what you had in mind? Hi Jason, This is *exactly* what I had in mind ! Impressive how little code it took you to add "syncconf", very elegant. I spent over an hour testing this, trying to break it ... worked perfectly. Active peers don't miss a beat and retain their counters. > One of the things that always goes wrong with "sync" algorithms in > software -- and the commit above at the moment is no exception -- is > that they're kind of racey. In order to synchronize, we have to read > the current state, compare it, and then set our new state. But in > between, the state could have changed out from underneath us. One > strategy for this is to just do nothing and put some notice in the man > page. Another strategy is to read back the result at the end, compare > it, and loop like this until we reach the stable state. This then > requires implementing some equality function. If "wg" does not offer "syncconf", users will be hacking together their own sync solution and it will no doubt be more racey than your tight code. Just a simple mention in the man page stating something like: Warning: unexpected results may occur with simultaneous background configuration changes during 'wg syncconf' Possibly also add a hint on the command help... "(assume no background configuration changes)" -- syncconf: Synchronizes a configuration file to a WireGuard interface (assume no background configuration changes) -- > The other thing I was wondering is: aside from performance and races > as described above, why not just make this the functionality of > `setconf`? Then there's be no need to introduce a new subcommand. In > otherwords, the idea would be to make `setconf` not destroy existing > peers if we're going to be re-adding them again. I vote to keep "setconf" as is, with the addition of the "syncconf" subcommand. This keeps "setconf" faster, and unchanged, typically used for initial configuration. Then "syncconf" would typically be used for followup live updates. Thanks again Jason! Please merge syncconf -> master Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
Hey Lonnie, I gave it a stab in this branch: https://git.zx2c4.com/WireGuard/commit/?h=jd/syncconf Try it out and let me know if it does what you had in mind? One of the things that always goes wrong with "sync" algorithms in software -- and the commit above at the moment is no exception -- is that they're kind of racey. In order to synchronize, we have to read the current state, compare it, and then set our new state. But in between, the state could have changed out from underneath us. One strategy for this is to just do nothing and put some notice in the man page. Another strategy is to read back the result at the end, compare it, and loop like this until we reach the stable state. This then requires implementing some equality function. The other thing I was wondering is: aside from performance and races as described above, why not just make this the functionality of `setconf`? Then there's be no need to introduce a new subcommand. In otherwords, the idea would be to make `setconf` not destroy existing peers if we're going to be re-adding them again. Thoughts? Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
Hi Lonnie, I agree. If a peer could push updated information of a remote peer (e.g. ip address, port) to all other peers it would be great, too. Regards, Renne Am 09.06.19 um 21:59 schrieb Lonnie Abelbeck: Hi List, Request For Comments: I would find it useful if "wg" would support a "syncpeers" subcommand. -- Usage: wg syncpeers -- Available subcommands: syncpeers: Synchronizes a configuration file of peers to a WireGuard interface -- Given: - A user creates a wireguard.conf file. - Uses "wg setconf wg0 wireguard.conf" to apply the configuration. Request: - Later, a user edits a wireguard.conf file: adds peers, deletes peers, and/or edits peers. - Use "wg syncpeers wg0 wireguard.conf" to synchronize the configuration file of peers with the current state. - Synchronize changes with minimal impact, determine peer differences and leave unchanged settings alone. - Basically internally using "wg set wg0 ..." to make the minimum changes. - If the [Peer] Endpoint is a DNS hostname, the Endpoint will be resolved and IP updated. Note: Interestingly, "wg setconf wg0 wireguard.conf" *almost* performs as requested except for a 17 second interruption of the tunnel *if* PersistentKeepalive is 0. Even if PersistentKeepalive is 3600, a "wg setconf wg0 wireguard.conf" will not effect an active tunnel except for resetting traffic counters. I understand a script could be created to perform this as well, but adding it to "wg" lowers the hurdle for many users. If the 17 second interruption of active tunnels while using "wg setconf wg0 wireguard.conf" could be eliminated, this request may be moot. Comments please. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
