[patch] add support for peer names using a file in userspace

[Lonnie Abelbeck]

On Dec 7, 2017, at 10:23 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:

> Thanks for sending this to the mailing list. Indeed it got lost in the
> fold of disorganized email filters when you sent it to me directly
> twice earlier; sorry about that.

The latest patch is reworked, disabled by default and requires WITH_PEERDATA=yes to be enabled.

> I'm not certain this is the right approach -- having wg(8) rely on
> fixed filesystem paths, and splitting peer configuration information
> across three places (original config file, peer data file, kernel).

I'm just trying to find a solution with traction.  My latest patch works perfectly fine on our Linux appliance, but alternate approaches could be a more general solution.

> I think the way forward for this kind of feature would be what I
> proposed in an earlier thread, of attaching it to the kernel object,
> just like ifalias does or netfilter's comment target. However, the
> question I'm still faced with is -- is this really necessary?

Yes, Jason, I think it is necessary.

Consider a GUI showing a list of peers that you can click on to edit, there needs some sort of human-memerable "name" associated with each peer.

Additionally, the "wg show" output is sorted by "handshake time" (a good thing), so remembering your peer config order does not help identifying the peers.

While I would be happy with a compile-time option to support peer-names via a userspace file (per my patch), a kernel object would be better.

Suggested configuration syntax:

1) Support either [Peer] or [Peer-some_custom_name] in "wg setconf" configurations.

2) Make "wg showconf" parrot back any [Peer-some_custom_name] context names.

3) Make "wg show" display either "peer: orQ..." or "peer-some_custom_name: orQ..."

4) Any spaces in the "some_custom_name" text are ignored and truncated to 64 characters.

Thanks for your consideration.

Lonnie