Integrate Wireguard Support? #158
Replies: 6 comments
-
I'd say +1 on adding a flag to integrate wireguard modules. But instead of integrating wireguard configuration tasks in this role, how about letting the user specify another role and including that? In fact, it may be a good idea to be more flexible here and just allow running another role with |
Beta Was this translation helpful? Give feedback.
-
Is it possible to include a role via vars? like
|
Beta Was this translation helpful? Give feedback.
-
I haven't actually tried, but I don't see why it wouldn't be possible. |
Beta Was this translation helpful? Give feedback.
-
I think wiregard or openvpn are may be less done for that than Tinc ? |
Beta Was this translation helpful? Give feedback.
-
Even when the first reason for this issue was the problem to have a VPN between the nodes, I think, the idea from @lae is better to just have a "hook" after the reboot. This is a very general solution for different problems not only for installing the newest Wireguard kernel modules. Adding support for all the different VPN solutions on this planet is not in scope of the role (one role for one problem). Edit: the task above with include_role {{ hook }} works. I forgot to create a PR. |
Beta Was this translation helpful? Give feedback.
-
+1 to @lae and @trickert76, this role shouldn't become bloated. |
Beta Was this translation helpful? Give feedback.
-
In my production setup, I'm using wireguard to setup a private network over all Proxmox hosts (my hosts are all public root servers on some different provider sites). Even when Wireguard is not yet official supported (coming with the next major release) it is possible to use it already via the unstable tree. Wireguard is nice, because it is really fast (in comparison to other VPN solutions) and the setup is really easy.
The setup is easy. There must be a wireguard-kernel module, a configuration file all known other peers and a service to listin on a given UDP port. All or some traffic can then be routed via that port to other peers/hosts.
The issue is - I've bootstrap problem together with the lae.proxmox role. And I'm not sure, how to resolve it without changing this role or by making "manual" changes on the hosts.
First - to join an existing cluster the new host needs access to the Wireguard network. Currently this works by enabling the module in the Debian Kernel. When I then start this role on that new empty host, the Proxmox kernel is installed and the system reboots. I can also add the pve-headers package to
pve_extra_packages
so the Wireguard module can be build. But - before I can enable the module again with modprobe on the newly booted kernel I need to run a "dkms autoinstall" on Proxmox to generate the module in the correct place under /lib/modules/... Only then the kernel will find the module and start the tunnel and the role can use it to do what ever is necessary to do (join the cluster).So my problem is the different behaviour after switching the kernel.
Is there a good way to integrate that? Currently I stop the play before the reboot, reboot manually, make the "dkms autoinstall" and start the role again.
I'd like to integrate the wireguard support with some flags. If the flag is set, then it compares the kernels before and after the reboot, checks if it is a linux->pve switch and runs the tasks to reconfigure wireguard. I could also integrate the complete setup of the wireguard (a single template and some key generations).
Beta Was this translation helpful? Give feedback.
All reactions