wireguard: Add fallback to userspace implementation

[gandro]

WireGuard on Linux usually uses the kernel-mode implementation, as it is
faster and does not rely on a userspace process running to process
packets.

However, some kernels do not ship with WireGuard support, either because
they are too old, or because WireGuard support has explicitly compiled
out. For such cases, we can fall back to the WireGuard user-space
implementation based on a TUN device. While this is not recommended in
production, it can be useful for testing or in cases where some machines
cannot upgrade to a more recent kernel.

The userspace implementation requires a daemon which encrypts and
decrypts the packets sent over the TUN device. In Cilium, this task is
performed by the cilium-agent process which calls into the wireguard-go
library. This has the consequence that if cilium-agent is down,
connectivity between WireGuard peers, and therefore connectivity between
Cilium-managed pods will also be unavailable. Thus, running WireGuard in
userspace mode is not recommeneded for production workloads.

The fallback to userspace mode must be explicitly enabled via the
enable-wireguard-userspace-fallback option.

Review per commit. The first few commits contain drive-by cleanups.

[rolinh]

LGTM 🚀

[errordeveloper]

I wonder if it might be possible to unit test the functions that setup the server, you could run two servers on one host and simulate traffic between them, what do you think? That would only cover user-space server functionality, and won't cover more desirable setup where one node uses the kernel implementation and another relies on user-space fallback, but at least we could have some tests for this new functionality...

[gandro]

I wonder if it might be possible to unit test the functions that setup the server, you could run two servers on one host and simulate traffic between them, what do you think? That would only cover user-space server functionality, and won't cover more desirable setup where one node uses the kernel implementation and another relies on user-space fallback, but at least we could have some tests for this new functionality...

The reason why I actually started this work is to add WireGuard to the Clustermesh CI 3.0, which runs on VMs which don't have WireGuard support. That CI test will cover the functionality (and more) added by this PR much better than unit tests. Do you think that's a suitable alternative?

With regards to compatibility between userspace-mode and kernel-mode: This is something guaranteed by upstream (wireguard-go is developed by same people who are responsible for the kernel-mode). Do you have a particular concern in mind here? After all, there are no parameters for us to configure which could break this compatibility.

[tklauser]

Not directly related to this PR but something that came to my mind while reviewing:

In case the wireguard kernel implementation is built as a module (which seems to be the default configuration and is the case on the few systems I checked): do we check whether the module is loaded before attempting to set up wireguard or would it make sense to add such a check (similar to the way we check for iptables modules being loaded)? Or is it guaranteed to be autoloaded once we create the wgX interface?

[brb]

Cool!

[gandro]

/test

Regarding my last push: Rebased on master before running CI.

Job 'Cilium-PR-K8s-1.16-net-next' failed and has not been observed before, so may be related to your PR:

Click to show.

Test Name

K8sChaosTest Connectivity demo application Endpoint can still connect while Cilium is not running

Failure Output

FAIL: DNS entry is not ready after timeout

Edit:

• net-next hit CI: K8sBookInfoDemoTest Bookinfo Demo Tests bookinfo demo: DNS entry is not ready after timeout #17401
• Travis CI hit an issue with docker rate limitting
• Multicluster and External workloads both seem to experienced timeouts with the k8s apiserver, which indicates an infrastructure problem on GKE.

Edit 2: The net-next has been updated and some other workflows disabled. Rerunning tests.

[gandro]

/test

• ConformanceAKS (https://github.com/cilium/cilium/actions/runs/1353831358) hit multiple issues with the to-fqdns connectivity test, is however unrelated as WireGuard is not enabled there
• Travis CI (https://app.travis-ci.com/github/cilium/cilium/jobs/543651009) hit the docker rate limit (c.f. travis: login to Docker Hub #17569 )

[gandro]

/test

Had to rebase due to conflicts.

Job 'Cilium-PR-K8s-1.21-kernel-4.9' failed and has not been observed before, so may be related to your PR:

Click to show.

Test Name

K8sConformance Portmap Chaining Check connectivity-check compliance with portmap chaining

Failure Output

FAIL: unable to retrieve all nodes with 'kubectl get nodes -o json | jq '.items | length'': Exitcode: -1 

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-1.21-kernel-4.9 so I can create a new GitHub issue to track it.

Edit: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.21-kernel-4.9/1659/testReport/junit/Suite-k8s-1/21/K8sConformance_Portmap_Chaining_Check_connectivity_check_compliance_with_portmap_chaining/

This looks like a failiure with K8s itself, not Cilium. kube-controller-manager failed with 2021-10-20T15:31:35.000867000Z F1020 15:31:35.000592 1 controllermanager.go:284] leaderelection lost

[gandro]

test-1.21-4.9

Edit: Given the above flake is unrelated to WireGuard and I would like to get this PR in for the 1.11 feature freeze, I will restart the failed test.

[gandro]

Marking this ready-to-merge. It has gotten a lot of reviews and is blocking further CI work (#17453). Plus I also would like to get this into Cilium 1.11 before the feature freeze.