wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
* RFC: wg syncpeers wg0 wireguard.conf
@ 2019-06-09 19:59 Lonnie Abelbeck
  2019-06-10 12:34 ` Rene 'Renne' Bartsch, B.Sc. Informatics
  2019-06-11 17:28 ` Jason A. Donenfeld
  0 siblings, 2 replies; 13+ messages in thread
From: Lonnie Abelbeck @ 2019-06-09 19:59 UTC (permalink / raw)
  To: WireGuard mailing list

Hi List, Request For Comments:

I would find it useful if "wg" would support a "syncpeers" subcommand.
--
Usage: wg syncpeers <interface> <configuration filename>
--
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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-09 19:59 RFC: wg syncpeers wg0 wireguard.conf Lonnie Abelbeck
@ 2019-06-10 12:34 ` Rene 'Renne' Bartsch, B.Sc. Informatics
  2019-06-11 17:28 ` Jason A. Donenfeld
  1 sibling, 0 replies; 13+ messages in thread
From: Rene 'Renne' Bartsch, B.Sc. Informatics @ 2019-06-10 12:34 UTC (permalink / raw)
  To: wireguard

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 <interface> <configuration filename>
> --
> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-09 19:59 RFC: wg syncpeers wg0 wireguard.conf Lonnie Abelbeck
  2019-06-10 12:34 ` Rene 'Renne' Bartsch, B.Sc. Informatics
@ 2019-06-11 17:28 ` Jason A. Donenfeld
  2019-06-11 21:06   ` Lonnie Abelbeck
                     ` (3 more replies)
  1 sibling, 4 replies; 13+ messages in thread
From: Jason A. Donenfeld @ 2019-06-11 17:28 UTC (permalink / raw)
  To: Lonnie Abelbeck, Luis Ressel; +Cc: WireGuard mailing list

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-11 17:28 ` Jason A. Donenfeld
@ 2019-06-11 21:06   ` Lonnie Abelbeck
  2019-06-11 21:41     ` Kalin KOZHUHAROV
  2019-06-12  0:22   ` Steven Honson
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 13+ messages in thread
From: Lonnie Abelbeck @ 2019-06-11 21:06 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: Luis Ressel, WireGuard mailing list



> On Jun 11, 2019, at 12:28 PM, Jason A. Donenfeld <Jason@zx2c4.com> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-11 21:06   ` Lonnie Abelbeck
@ 2019-06-11 21:41     ` Kalin KOZHUHAROV
  0 siblings, 0 replies; 13+ messages in thread
From: Kalin KOZHUHAROV @ 2019-06-11 21:41 UTC (permalink / raw)
  To: Lonnie Abelbeck; +Cc: Luis Ressel, WireGuard mailing list

On Tue, Jun 11, 2019 at 11:08 PM Lonnie Abelbeck
<lists@lonnie.abelbeck.com> wrote:
> > On Jun 11, 2019, at 12:28 PM, Jason A. Donenfeld <Jason@zx2c4.com> 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 <wg0.conf` ??  (to be able to use easily sudo?) If nothing
special, I'd rather see `wg setconf` read from STDIN.
We have also `wg addconf` ... hmm

I'd suggest drop addconf altogether and rename the proposed syncconf
to `updateconf` (other software uses reload, but it is not clear in
this usecase).
Do we need the reverse of `wg setconf` without the redirect like `wg
saveconf wg0 wg0.conf` ? I don't think so.
Yes, I am sure it "will break userspace", but it is better to do it
now than later.

Cheers,
Kalin.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-11 17:28 ` Jason A. Donenfeld
  2019-06-11 21:06   ` Lonnie Abelbeck
@ 2019-06-12  0:22   ` Steven Honson
  2019-06-12  0:25     ` Marc Fawzi
  2019-06-13 23:15   ` Lonnie Abelbeck
  2019-06-14 18:09   ` Jason A. Donenfeld
  3 siblings, 1 reply; 13+ messages in thread
From: Steven Honson @ 2019-06-12  0:22 UTC (permalink / raw)
  To: wireguard

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-12  0:22   ` Steven Honson
@ 2019-06-12  0:25     ` Marc Fawzi
  2019-06-14 18:01       ` Jason A. Donenfeld
  0 siblings, 1 reply; 13+ messages in thread
From: Marc Fawzi @ 2019-06-12  0:25 UTC (permalink / raw)
  To: Steven Honson; +Cc: wireguard


[-- Attachment #1.1: Type: text/plain, Size: 1312 bytes --]

<<
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 <steven@honson.id.au> 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
>

[-- Attachment #1.2: Type: text/html, Size: 1930 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-11 17:28 ` Jason A. Donenfeld
  2019-06-11 21:06   ` Lonnie Abelbeck
  2019-06-12  0:22   ` Steven Honson
@ 2019-06-13 23:15   ` Lonnie Abelbeck
  2019-06-14 18:09   ` Jason A. Donenfeld
  3 siblings, 0 replies; 13+ messages in thread
From: Lonnie Abelbeck @ 2019-06-13 23:15 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: Luis Ressel, WireGuard mailing list


> On Jun 11, 2019, at 12:28 PM, Jason A. Donenfeld <Jason@zx2c4.com> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-12  0:25     ` Marc Fawzi
@ 2019-06-14 18:01       ` Jason A. Donenfeld
  2019-06-16 19:43         ` Marc Fawzi
  0 siblings, 1 reply; 13+ messages in thread
From: Jason A. Donenfeld @ 2019-06-14 18:01 UTC (permalink / raw)
  To: Marc Fawzi; +Cc: Steven Honson, WireGuard mailing list

On Fri, Jun 14, 2019 at 8:01 PM Marc Fawzi <marc.fawzi@gmail.com> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-11 17:28 ` Jason A. Donenfeld
                     ` (2 preceding siblings ...)
  2019-06-13 23:15   ` Lonnie Abelbeck
@ 2019-06-14 18:09   ` Jason A. Donenfeld
  2019-06-14 20:48     ` Lonnie Abelbeck
  2019-06-14 21:14     ` Ivan Labáth
  3 siblings, 2 replies; 13+ messages in thread
From: Jason A. Donenfeld @ 2019-06-14 18:09 UTC (permalink / raw)
  To: Lonnie Abelbeck, Luis Ressel, Steven Honson, Ivan Labáth
  Cc: WireGuard mailing list

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-14 18:09   ` Jason A. Donenfeld
@ 2019-06-14 20:48     ` Lonnie Abelbeck
  2019-06-14 21:14     ` Ivan Labáth
  1 sibling, 0 replies; 13+ messages in thread
From: Lonnie Abelbeck @ 2019-06-14 20:48 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list



> On Jun 14, 2019, at 1:09 PM, Jason A. Donenfeld <Jason@zx2c4.com> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-14 18:09   ` Jason A. Donenfeld
  2019-06-14 20:48     ` Lonnie Abelbeck
@ 2019-06-14 21:14     ` Ivan Labáth
  1 sibling, 0 replies; 13+ messages in thread
From: Ivan Labáth @ 2019-06-14 21:14 UTC (permalink / raw)
  To: Jason A. Donenfeld, Lonnie Abelbeck, Luis Ressel, Steven Honson
  Cc: WireGuard mailing list

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC: wg syncpeers wg0 wireguard.conf
  2019-06-14 18:01       ` Jason A. Donenfeld
@ 2019-06-16 19:43         ` Marc Fawzi
  0 siblings, 0 replies; 13+ messages in thread
From: Marc Fawzi @ 2019-06-16 19:43 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: Steven Honson, WireGuard mailing list


[-- Attachment #1.1: Type: text/plain, Size: 1444 bytes --]

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 <Jason@zx2c4.com> wrote:

> On Fri, Jun 14, 2019 at 8:01 PM Marc Fawzi <marc.fawzi@gmail.com> wrote:
> > p.s. does this overlap with similar planned in wg-dynamic?
>
> No, the topics have no similarities.
>

[-- Attachment #1.2: Type: text/html, Size: 2183 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-06-18 15:10 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-09 19:59 RFC: wg syncpeers wg0 wireguard.conf Lonnie Abelbeck
2019-06-10 12:34 ` Rene 'Renne' Bartsch, B.Sc. Informatics
2019-06-11 17:28 ` Jason A. Donenfeld
2019-06-11 21:06   ` Lonnie Abelbeck
2019-06-11 21:41     ` Kalin KOZHUHAROV
2019-06-12  0:22   ` Steven Honson
2019-06-12  0:25     ` Marc Fawzi
2019-06-14 18:01       ` Jason A. Donenfeld
2019-06-16 19:43         ` Marc Fawzi
2019-06-13 23:15   ` Lonnie Abelbeck
2019-06-14 18:09   ` Jason A. Donenfeld
2019-06-14 20:48     ` Lonnie Abelbeck
2019-06-14 21:14     ` Ivan Labáth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).