wireguard-go
wireguard-go copied to clipboard
device: initial DeviceOptions
These are some of the hooks we use in wireguard-go for using custom socket objects with unusual routing properties. The general structure can be used in future commits to provider library users more ways to use their WireGuard tunnel.
cc @danderson
This exposes a lot of internal machinery of WireGuard that isn't meant to be exposed. Are we sure we should be giving this to the user?
Some of this I believe is justifiable, some less so.
The main CreateEndpoint/CreateBind callbacks are very useful to several different kinds of projects, which generally fall under the umbrella of "the OS network stack does not have the features we need." We use it in Tailscale to do platform-independent STUN packet interception and TCP fallback routing. Another project I've considered doing with it is integration into a user-space network stack like DPDK (or something built on gVisor's netstack that I worked on), which would require avoiding the Go net package and OS system calls entirely.
The UnexpectedIP callback is useful GUI information, it can be used to inform the user that a trusted peer is misconfigured relative to the host because it's violating the AllowedIPs.
You're right about the SkipBindUpdate feature, I think it's a failed experiment of ours. I've put a TODO on it to remove and will do once I'm through my backlog of commits.
The HandshakeDone is halfway to something useful. As is, it's a bit of a hack, library users don't really need to know about the state of the WireGuard handshake with a peer. But they could use some more information about the connection with a peer. We are using it right now as a link status signal. I think there's some value in this, and we should evolve this into some kind of general callback along the lines of LinkChange(status LinkStatus)
. I've put a TODO in this commit set about that.
Okay. Let's hold off on merging this for a bit until we can fully study the use case. I'm very hesitant to introduce extensive internal apis without thinking about network implications.