soumya92/barista

[vpn] Wireguard Support

shibumi opened this issue · 5 comments

I have checked out your VPN implementation and tested it with my Wireguard interface. It looks like that your VPN module is not handling the netlinks correctly or (this case is more likely) Wireguard is not doing netlink correctly. Would be nice to have Wireguard support in the future (either as a single module or as component of the VPN module)

vpn.Wireguard makes sense to me. I will look into this after themes, but feel free to put any ideas/comments here for me to find :)

Hi,
I've played a bit around with the netinfo module and I think the netinfo module is maybe enough if you follow a certain policy:

  • All wireguard interfaces have to start with wg-

Because then you can do something like this:

	barista.Add(netinfo.Prefix("wg").Output(func(s netinfo.State) bar.Output {
		switch {
		// we are using the unknown state for now, because wireguard supports only operstate Unknown
		case s.Unknown():
			return outputs.Textf("%s", s.Name).Color(colors.Scheme("good"))
		default:
			return outputs.Textf("%s", s.Name).Color(colors.Scheme("bad"))
		}
	}))

This works fine for me.. It's just sad that wireguard only supports one interface state UNKNOWN. this sucks kind of..I hope the wireguard devs will fix this.

WGH- commented

It's just sad that wireguard only supports one interface state UNKNOWN. this sucks kind of..I hope the wireguard devs will fix this.

One interface might have connection to multiple peers. This is usually the case for servers, but strictly speaking there's no clear distinction: all parties may have connections to many peers.

Depending on the use case, just existence of the interface might be a good indicator.

If you want to know current connection status, you might want to look at WireGuard-specific data (which wg shows), specifically "latest handshake". But keep in mind that WireGuard doesn't do handshakes with other peers unless you send traffic to them (or have persistent keep-alive enabled).

One interface might have connection to multiple peers. This is usually the case for servers, but strictly speaking there's no clear distinction: all parties may have connections to many peers.

I would suggest that you spawn different wireguard interfaces for each connection, I don't think this would introduce any further disadvantage despite having to enable them all manually (this is scriptable).

I had a discussion with the wireguard devs regarding adding more specific information to the interface status, but sadly they don't think that they are going to introduce a change there.

Parsing wg shows was something that I didn't want to do, because calling subcommands from a go programm is kind of ugly. Maybe there will be a better solution for tackling this with a wireguard API(?)

WGH- commented

Parsing wg shows was something that I didn't want to do, because calling subcommands from a go programm is kind of ugly. Maybe there will be a better solution for tackling this with a wireguard API(?)

https://github.com/WireGuard/wgctrl-go