wireguardctrl: Go package that enables control of WireGuard devices on multiple platforms

wireguardctrl: Go package that enables control of WireGuard devices on multiple platforms

[Matt Layher]

Hi all,

It's been a couple of weeks since my previous thread, so I wanted to 
follow up with a new one now that my Go package has a new name and an 
extended scope:

https://github.com/mdlayher/wireguardctrl

wireguardctrl is a Go package that abstracts away the WireGuard kernel, 
userspace, and any future OS-specific interfaces.

At this point, I've got all of the device and peer retrieval 
functionality done, but I still need to implement device peer 
configuration for both the kernel and userspace interfaces.  There are a 
couple issues open around this topic.

I think this package is at a point where I'd feel comfortable having 
folks try it out and see what happens.  I've got some integration tests 
hooked up in Travis CI for both the kernel and userspace modules, and it 
seems to work well!  My next plan is to consider building some kind of 
one-shot utility for setting up a tunnel by running a small program on 
two machines.

Thanks for your time, and feel free to reach out here or on IRC for any 
questions.

- Matt Layher

PS: Jason, if you do end up making a language bindings page for the 
website, I'd still like this package to be listed there!  I also found 
the beginnings of a Python library today: https://github.com/apognu/wgctl.

Re: wireguardctrl: Go package that enables control of WireGuard devices on multiple platforms

[Matt Layher]

I suppose this would be a good place to poll the audience for feedback 
on a question as well!

Right now I expose methods to access devices by both name and interface 
index.  However, the userspace implementations don't have the concept of 
an interface index exposed.  You can access it by doing an interface 
lookup for the tap interface name (net.InterfaceByIndex in Go), but then 
my userspace package does an immediate name lookup after that anyway.

Does it makes sense to continue to expose a way to fetch a WireGuard 
device by its interface index?  Is this useful compared to fetching a 
device by its name?  If not, I could remove it and rename the method 
"DeviceByName" to just "Device".

See: https://github.com/mdlayher/wireguardctrl/issues/6

Thanks in advance for the feedback!

- Matt


On 08/07/2018 02:16 PM, Matt Layher wrote:
> Hi all,
>
> It's been a couple of weeks since my previous thread, so I wanted to 
> follow up with a new one now that my Go package has a new name and an 
> extended scope:
>
> https://github.com/mdlayher/wireguardctrl
>
> wireguardctrl is a Go package that abstracts away the WireGuard 
> kernel, userspace, and any future OS-specific interfaces.
>
> At this point, I've got all of the device and peer retrieval 
> functionality done, but I still need to implement device peer 
> configuration for both the kernel and userspace interfaces.  There are 
> a couple issues open around this topic.
>
> I think this package is at a point where I'd feel comfortable having 
> folks try it out and see what happens.  I've got some integration 
> tests hooked up in Travis CI for both the kernel and userspace 
> modules, and it seems to work well!  My next plan is to consider 
> building some kind of one-shot utility for setting up a tunnel by 
> running a small program on two machines.
>
> Thanks for your time, and feel free to reach out here or on IRC for 
> any questions.
>
> - Matt Layher
>
> PS: Jason, if you do end up making a language bindings page for the 
> website, I'd still like this package to be listed there!  I also found 
> the beginnings of a Python library today: 
> https://github.com/apognu/wgctl.
>