The question why you need a VPN is easy to answer, it offers the possibility to use your own infrastructure sensibly on the go. Concrete examples:

• Secure use of the Internet in public HotSpots
• Access to the home network hard drive

PiVPN switched from OpenVPN to Wireguard as the default some time ago. The significantly better performance of Wireguard justified this step. Here I briefly describe how to install Wireguard and configure it for home use.
Our server is a Raspberry Pi 4 with Raspberry Pi OS. In the following, I assume that the actions are carried out with the user root, which saves me the trouble of writing „sudo“ before each command.
Raspberry Pi OS ships with a kernel compatible with Wireguard. A kernel older than 5.6 is expressly not recommended. Oh, what kernel do I have?

uname -a | cut -d" " -f3

provides the desired information

apt install wireguard

Yes, that's about it Wireguard is now installed and ready to use. The configuration takes place in the directory /etc/wireguard and consists of a single file with the extension .conf (e.g. wg0.conf)

Both client and server require a configuration file.
Server and client authenticate each other using a private/public key pair. These keys can be generated as described on the Wireguard website. Here are short examples in which the server always has the first IP address and the clients are numbered starting with „2“
Server configuration, this provides a connection to our home network (in this case 192.168.178.0/24) and to the Internet

/etc/wireguard/zuhause.conf:
[Interface]
# Home servers
Address = 10.8.10.1/24
SaveConfig = false
ListenPort = 51196
PrivateKey = <Server's private key>
[Peer]
# Client cli2_home
PublicKey = <Public key of client 2>
AllowedIPs = 10.8.10.2/32
[Peer]
# Client cli3_home
PublicKey = <Public key of client 3>
AllowedIPs = 10.8.10.3/32

Client 2 configuration, this client only uses the VPN to access the home network:

[Interface]
# Client cli2_home
PrivateKey = <private key of client 2>
Address = 10.8.10.2/24
# DNS = 9.9.9.9
[Peer]
# Home servers
PublicKey = <public key of the server>
AllowedIPs = 10.8.10.0/24.192.168.178.0/24
Endpoint = your.dyndns.de:51196
PersistentKeepalive = 30

Client 3 configuration, this client uses the VPN for all network traffic:

[Interface]
# Client cli3_home
PrivateKey = <Client 3's private key>
Address = 10.8.10.3/24
DNS = 9.9.9.9
[Peer]
# Home servers
PublicKey = <public key of the server>
AllowedIPs = 10.8.10.0/24.192.168.178.0/24.0.0.0.0/0
Endpoint = your.dyndns.de:51196
PersistentKeepalive = 30

The parameter „Endpoint =“ in the client configuration specifies the (Dyn)DNS name or the public IP address of your router.
If all traffic (client 3) is chased via the VPN, a DNS must be specified. This can be your router (usually the first IP in your local home network, in the example 192.168.178.1) or a public DNS such as 9.9.9.9. The VPN works without a DNS entry, but name resolution does not take place. A ping to 9.9.9.9 will work, but a ping to dns9.quad9.net will not, because the name cannot be resolved.
The Wireguard server process is started with

systemctl start wg-quick@home

If the server is to be started automatically as part of the Raspberry Pi boot, this is how it works:

systemctl enable wg-quick@home

„home“ is the first part of the name of the /etc/wireguard/home.conf file

If you don't feel like making the configuration files, the keys, etc. yourself, you can also have this done using a script on the Raspberry Pi. You can find my solution on Gitlab.
The tool provides a directory with all the necessary files and a few auxiliary files that make life easier.

• Private and public keys for servers and clients
• A QR code for each client, which can be easily scanned with the Wireguard app on the client
• A .csv file that makes it easy to remember (and manage) which person you're providing a client for which device.

Have fun

Stolperfallen gibt es immer. Insbesondere das Routing ist im Rahmen eines VPN Einsatzes ein gerne falsch konfigurierter Stolperstein. Im Zweifel funktioniert keinerlei Internet Zugriff mehr. Hier ein paar Gedanken dazu:

• Der Server stellt für die Clients zum Einen den Zugriff auf das Heimnetz und zum Anderen aufs Internet zur Verfügung. „AllowedIPs“ wird auf dem Server nur benötigt, um die Clients auseinander zu halten. Wer hier rumfummelt, was durchaus Sinn machen kann falls ein Client Zugriff auf ein weiteres privates Netz hat, ohne zu wissen, was er tut verliert mit hoher Wahrscheinlichkeit den Netzwerk Zugriff auf seinen Raspberry Pi.
  
• Route ist nicht gleich Route. Routen werden normalerweise mit einem Ziel und einem Gateway konfiguriert, Dabei ist das Gateway die IP Adresse eines einzelnen Routers, während das Ziel ein einzelner Rechner oder ein Netzwerk sein kann. Eine andere Art des Routings findet ohne spezifisches Gateway statt und überlässt das Auffinden eines passenden Routers Anderen. Diese Interface Routen werden von der Wireguard Software unterstützt da Wireguard die Netzverbindungen aller Clients kennt.
  
• Wireguard unterstützt im Gegensatz nur das UPD Protokoll, TCP kann nicht verwendet werden. Ein „Verstecken“ des VPN hinter Port „443“, wie bei OpenVPN, ist nicht möglich.
  

There are always stumbling blocks. The routing in particular is a frequently misconfigured stumbling block when using a VPN. If in doubt, no Internet access works anymore. Here are a few thoughts:

• The server provides the clients with access to the home network on the one hand and to the Internet on the other. „AllowedIPs“ is only needed on the server to tell the clients apart. If you fiddle around here, which can make sense if a client has access to another private network without knowing what he is doing, there is a high probability that he will lose network access to his Raspberry Pi.
  
• Route is not always the same route. Routes are typically configured with a destination and a gateway, where the gateway is the IP address of a single router, while the destination can be a single machine or a network. Another type of routing takes place without a specific gateway and leaves finding a suitable router to others. These interface routes are supported by the Wireguard software because Wireguard knows the network connections of all clients.
  
• In contrast, Wireguard only supports the UPD protocol, TCP cannot be used. It is not possible to „hide“ the VPN behind port „443“, as with OpenVPN.