WG: ideas/features

WG: ideas/features

[ST]

Hello,

as I mentioned before I'm learning WireGuard and there are certain
things that I need but didn't find them yet in the docs (either because
I didn't read enough yet or because it's just not there). I'll list them
here and you'll tell whether it is worth for a new feature or not; or
whether I should continue reading...


1. Labels.

Is it possible to add an optional label to a peer to make it a bit more
usable for humans (who tend not to remember IPs or keys). A label
associated with a peer is just a string (could be a first/last name,
email, "NY Office" or whatever). So if you read through the .conf file
or query wg for that label - you can get the right IP to SSH to, if
needed.

In the .conf file it could probably be realized through some sort of
comments before each [Peer] section (didn't check whether # or something
actually work). But querying wg from command line for a label is also
handy...


2. Includes in .conf files.

Is it possible to include .conf files in the main wg0.conf file? Like:

[Interface]
...

Include ./us_peers.conf
Include ./eu_peers.conf

[Peer]
...

This way you can group peers into pools, so there will be a bit more
order/structure...

But what I envision it for is easy maintenance of an N:N mesh of nodes
where each node can communicate with all others. Each node's .conf file
will consist of only 2 things: its own [Interface] with private data and
one Include ./my_complete_mesh.conf with the public data of all [Peer]s.
This single Include file can be put in a central location (or mirrored
to several locations for failover) and all peers will pull it from there
once in a while through a cron job or it can be pushed to them with
rsync/ansible/ssh or whatever.

What do you think?

Thanks.

Re: WG: ideas/features

[Luis Ressel]

On Mon, 26 Mar 2018 20:17:17 +0300
ST <smntov@gmail.com> wrote:

> Hello,
> 
> as I mentioned before I'm learning WireGuard and there are certain
> things that I need but didn't find them yet in the docs (either
> because I didn't read enough yet or because it's just not there).
> I'll list them here and you'll tell whether it is worth for a new
> feature or not; or whether I should continue reading...

Don't ask whether you should read the docs. Of course you should,
that's the whole purpose of documentation! :)

> 1. Labels.
> 
> Is it possible to add an optional label to a peer to make it a bit
> more usable for humans (who tend not to remember IPs or keys). A label
> associated with a peer is just a string (could be a first/last name,
> email, "NY Office" or whatever). So if you read through the .conf file
> or query wg for that label - you can get the right IP to SSH to, if
> needed.

This has been suggested a few times already, but so far noone has
bothered to implement it. I don't see any fundamental issues with the
idea, though.

> In the .conf file it could probably be realized through some sort of
> comments before each [Peer] section (didn't check whether # or
> something actually work). But querying wg from command line for a
> label is also handy...

As documented in wg(8), wireguard's config files can indeed contain
comments.

> 
> 2. Includes in .conf files.
> 
> Is it possible to include .conf files in the main wg0.conf file? Like:
> 
> [Interface]
> ...
> 
> Include ./us_peers.conf
> Include ./eu_peers.conf
> 
> [Peer]
> ...
> 
> This way you can group peers into pools, so there will be a bit more
> order/structure...

The config parser doesn't support file inclusion. It doesn't seem to be
worth the hassle to add it either, since there's another way to combine
multiple config files: wg's "addconf" verb. It'll load a config file
without wiping out prior configuration, so you can combine config files
by chaining multiple "wg addconf" verbs.

If atomicity is desired, you could also concatenate the config files to
a temporary file which you then supply to wg setconf (or perhaps even
pipe the concatenated files to "wg setconf /proc/self/fd/0").

Cheers,
Luis

Re: WG: ideas/features

[wireguard]

On Mon, Mar 26, 2018 at 08:17:17PM +0300, ST wrote:
> 1. Labels.
> 
> Is it possible to add an optional label to a peer to make it a bit more
> usable for humans (who tend not to remember IPs or keys). A label
> associated with a peer is just a string (could be a first/last name,
> email, "NY Office" or whatever). So if you read through the .conf file
> or query wg for that label - you can get the right IP to SSH to, if
> needed.
> 
> In the .conf file it could probably be realized through some sort of
> comments before each [Peer] section (didn't check whether # or something
> actually work). But querying wg from command line for a label is also
> handy...
> 

I would probably just use a hosts file for this. That way, applications
don't have to worry about "how do I get this info from wg," they just
resolve it in the normal way. Am I missing something?

Re: WG: ideas/features

[ST]

On Mon, 2018-03-26 at 15:15 -0400, wireguard@eldondev.com wrote:
> On Mon, Mar 26, 2018 at 08:17:17PM +0300, ST wrote:
> > 1. Labels.
> > 
> > Is it possible to add an optional label to a peer to make it a bit more
> > usable for humans (who tend not to remember IPs or keys). A label
> > associated with a peer is just a string (could be a first/last name,
> > email, "NY Office" or whatever). So if you read through the .conf file
> > or query wg for that label - you can get the right IP to SSH to, if
> > needed.
> > 
> > In the .conf file it could probably be realized through some sort of
> > comments before each [Peer] section (didn't check whether # or something
> > actually work). But querying wg from command line for a label is also
> > handy...
> > 
> 
> I would probably just use a hosts file for this. That way, applications
> don't have to worry about "how do I get this info from wg," they just
> resolve it in the normal way. Am I missing something?

This way you'll have to maintain two files, hope that Peers' IPs do not
change too often, so you have to re-map them. But generally it's a
solution. Thank you!

Re: ideas/features

[Jason A. Donenfeld]

Hi ST,

On Mon, Mar 26, 2018 at 7:17 PM, ST <smntov@gmail.com> wrote:
> 1. Labels.
>
> Is it possible to add an optional label to a peer to make it a bit more
> usable for humans (who tend not to remember IPs or keys). A label
> associated with a peer is just a string (could be a first/last name,
> email, "NY Office" or whatever). So if you read through the .conf file
> or query wg for that label - you can get the right IP to SSH to, if
> needed.
>
> In the .conf file it could probably be realized through some sort of
> comments before each [Peer] section (didn't check whether # or something
> actually work). But querying wg from command line for a label is also
> handy...

A lot of people have asked for this; there's some discussion on the
list. I'm not entirely opposed to it, but the use case does seem
extremely limited. Often times you want a label so that you can then
correlate it with another piece of information to find more info in a
database or in an API. But in that case, why not use the public key as
the piece of correlating information? On the other hand, it would make
things a bit nicer from an administrative perspective if you're using
the basic wg utility and want a bit more information in there.

I've implemented this feature in a branch, but keep hesitating each
time I think about merging it. I should revisit it and come up with
something definitive one way or another.

>
>
> 2. Includes in .conf files.
>
> Is it possible to include .conf files in the main wg0.conf file? Like:
>
> [Interface]
> ...
>
> Include ./us_peers.conf
> Include ./eu_peers.conf

Seems useful, though a bit awkward to have in the .ini syntax. Many
systems, instead of include directives, choose to either go with an
external preprocessor (m4, cpp, bash, etc) for this kind of thing, or
go with the conf.d approach:
/etc/wireguard/someserver.conf.d/{001-something,002-anotherpart,003-alsothis}.
The conf.d approach has the advantage of being very easy to understand
and deal with, and one can see clearly how it would work with
wireguard -- `wg setconf wg0 <(cat
/etc/wireguard/someserver.conf.d/*)`. Would that handle your use case?

Jason