Support was enabled automatically if a WireGuard package was found or could have been made available. But if the WireGuard kernel module is not available, it needs to be compiled. The required kernel headers are only reliably known for Raspberry Pi (Raspbian) and for amd64. This commit resolves the related issue where linux-image-amd64 was attempted to be installed on non-amd64 systems: https://github.com/pivpn/pivpn/issues/1180
Additionally this commit resolves the issue that kernel headers were required and a DKMS build done, even if the module was builtin, when no WireGuard package was found.
The $NEED_WIREGUARD_REPO variable has been replaced with $AVAILABLE_WIREGUARD, which practically serves the same information and allows a simpler support check.
Signed-off-by: MichaIng <micha@dietpi.com>
- On Raspbian, /lib is not a symbolic link to /usr/lib, so the WireGuard unit won't be found.
Therefore changed to /lib/... (which is the default location for units of installed packages).
This commit allows PiVPN scripts to revoke certificates with common names like "José" better. Prior to this commit, names like "José" could not be revoked using PiVPN tools.
This commit allows PiVPN scripts to display certificates with common names like "José" better. Prior to this commit, names like "José" would be shown as "Jos\xC3\xA9".
From the man page of dnsmasq:
--local-service
Accept DNS queries only from hosts whose address is on a local subnet,
ie a subnet for which an interface exists on the server. This option only
has effect if there are no --interface, --except-interface, --listen-address
or --auth-server options. It is intended to be set as a default on installation,
to allow unconfigured installations to be useful but also safe from being
used for DNS amplification attacks.
- Letting dnsmasq additionally listen on a specific VPN interface when Pi-hole is
listening on the physical interface only may be more secure than letting dnsmasq
listen on all interfaces, however, dnsmasq will stop listening on the physical
interface (breaking LAN resolution) if the user changes the listening behavior
at a later time.
For the target audience of PiVPN, it is more likely that users will set the
listening behavior to all when deciding to use Pi-hole via VPN (which is suggested
in the Pi-hole guide and most guides on the web), instead of digging into
configuration file.
This option is safe if the Raspberry Pi is inside the local network and the user
has not forwarded port 53 on their router, which is unlikely as they are installing
PiVPN precisely to avoid doing that.
