Peer names in configuration file possible?

Peer names in configuration file possible?

[Der PCFreak]

Hi,

this is my first post to this list, so hopefully I don't get anything 
wrong. Excuse me if so.

I don't know if this has ever been mentioned but I am asking myself how 
should I keep track of let's say 1000 Peers in the configuration file of 
a WireGuard server when the config file just shows me the public key of 
the peers to identify them?

Would it be possible to add something like 'identifier' which might or 
might not be unique:

Sample '/etc/wireguard/wg0-server.conf'

[Interface]
...
...

[Peer]
identifier=computer01
...
...

[Peer]
identifier=computer02
...
...

For example the command 'wg show wg0-server dump' could then maybe show 
the 'identifier' as column to make things easier?

I am thinking of possibly replacing/migrating a large OpenVPN server 
instance to WireGuard and I am currently thinking about the management of
the peers which on OpenVPN I do do with username/password + OTP. Just 
the public key in the config is not enough in my opinion, a descriptive 
field should be possible.

Also I assume when 'SaveConfig = true' is set in the servers 
configuration file any saves to the file currently remove manually added 
comments so doing it with comments is not a good option.

Regards

Peter aka PCFreak



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

Request for review: Add a short name attribute to peers for human friendly output

[Jaseem Abid]

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

Hello lovely WireGuard people,

I wrote a tiny patch to add a name attribute to peers because identifying
clients on my VPN just got very hard. Also hacking on wg source was a lot of
fun. I asked @zx2c4 about this a while ago and he was open to the idea.

It's not _really_ ready for a submission yet because of a few rough edges
but
I'd love to get some eyes on this if anyone is kind! I've never written any
kernel code before and my C is a bit rusty, so please feel free to be picky
about the review. I've added '*NOTE:*'s for the reviewer where I'm not sure
of
the approach.

A few other questions,

1. There are barely any inline code comments, is that intentional or
something
that the community would love to improve? I don't mean the really obvious
ones
but things that are tricky.

2. Is there any interest in a getting started guide for developers wanting
to
work on wireguard itself? Something like the usual CONTRIBUTING.md? I had
to dig
through a lot of netlink tutorials and old kernel newbie guides to make any
progress. It would be helpful to have it in one small doc.

The patch stays in the `name` branch here[1] and this commit does most of
the
work[2].

[1]: https://github.com/jaseemabid/WireGuard/tree/name
[2]: https://github.com/jaseemabid/WireGuard/commit/544e59b4

-- 
Regards,

Jaseem Abid
https://twitter.com/jaseemabid

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

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

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

Re: Peer names in configuration file possible?

[Ivan Labáth]

Hi all,

I would like to propose an idea, that if peer were keyed by an
identifier (e.g. string) insted of pubkey. E.g. from 

[Peer PubKeyWithBunchOfCharacters]
  Identifier = Gorge

[Peer AnotherPubkeyWithBuchOfCharacters]
  Identifier = Jane

..

we changed it to

[Peer George]
  Pubkey = BuchOfBase64

[Peer Jane]
  Pubkey = AnotherBuchOfBase64



It might not only
  * save people from doing reverse ip what was this peer guessing
    and/or lookup (e.g. in wg show)
  * discourage remembering pubkeys, while encouraging key rotation
  * perhaps make peers naturally sorted in a consistent manner
    (after changing keys)

but also:
  * enable lossless key turnover
    pubkey changes, session keys tied to peer -> no connection drop
    I think it should work fine, if privkey changed first, then
    pubkey on peer, with handshake complete before old keys
    become stale?


What do you think?


Regards,
Ivan

On Tue, Jan 22, 2019 at 12:50:17PM +0100, Der PCFreak wrote:
> Hi,
> 
> this is my first post to this list, so hopefully I don't get anything 
> wrong. Excuse me if so.
> 
> I don't know if this has ever been mentioned but I am asking myself how 
> should I keep track of let's say 1000 Peers in the configuration file of 
> a WireGuard server when the config file just shows me the public key of 
> the peers to identify them?
> 
> Would it be possible to add something like 'identifier' which might or 
> might not be unique:
> 
> Sample '/etc/wireguard/wg0-server.conf'
> 
> [Interface]
> ...
> ...
> 
> [Peer]
> identifier=computer01
> ...
> ...
> 
> [Peer]
> identifier=computer02
> ...
> ...
> 
> For example the command 'wg show wg0-server dump' could then maybe show 
> the 'identifier' as column to make things easier?
> 
> I am thinking of possibly replacing/migrating a large OpenVPN server 
> instance to WireGuard and I am currently thinking about the management of
> the peers which on OpenVPN I do do with username/password + OTP. Just 
> the public key in the config is not enough in my opinion, a descriptive 
> field should be possible.
> 
> Also I assume when 'SaveConfig = true' is set in the servers 
> configuration file any saves to the file currently remove manually added 
> comments so doing it with comments is not a good option.
> 
> Regards
> 
> Peter aka PCFreak

On Wed, Jan 30, 2019 at 03:29:33AM +0530, Jaseem Abid wrote:
> Hello lovely WireGuard people,
> 
> I wrote a tiny patch to add a name attribute to peers because identifying
> clients on my VPN just got very hard. Also hacking on wg source was a lot of
> fun. I asked @zx2c4 about this a while ago and he was open to the idea.
> 
> It's not _really_ ready for a submission yet because of a few rough edges
> but
> I'd love to get some eyes on this if anyone is kind! I've never written any
> kernel code before and my C is a bit rusty, so please feel free to be picky
> about the review. I've added '*NOTE:*'s for the reviewer where I'm not sure
> of
> the approach.
> 
> A few other questions,
> 
> 1. There are barely any inline code comments, is that intentional or
> something
> that the community would love to improve? I don't mean the really obvious
> ones
> but things that are tricky.
> 
> 2. Is there any interest in a getting started guide for developers wanting
> to
> work on wireguard itself? Something like the usual CONTRIBUTING.md? I had
> to dig
> through a lot of netlink tutorials and old kernel newbie guides to make any
> progress. It would be helpful to have it in one small doc.
> 
> The patch stays in the `name` branch here[1] and this commit does most of
> the
> work[2].
> 
> [1]: https://github.com/jaseemabid/WireGuard/tree/name
> [2]: https://github.com/jaseemabid/WireGuard/commit/544e59b4
> 
> -- 
> Regards,
> 
> Jaseem Abid
> https://twitter.com/jaseemabid
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard