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:
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 = 126.96.36.199 [Peer] # Home servers PublicKey = <public key of the server> AllowedIPs = 10.8.10.0/188.8.131.52.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 = 184.108.40.206 [Peer] # Home servers PublicKey = <public key of the server> AllowedIPs = 10.8.10.0/220.127.116.11.0/18.104.22.168.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 22.214.171.124. The VPN works without a DNS entry, but name resolution does not take place. A ping to 126.96.36.199 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.
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:
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: