WireGuard-VPN auf dem eigenen VPS einrichten

Was Sie einrichten

Ein WireGuard-VPN auf einem eigenen Server umfasst etwa vierzig Konfigurationszeilen: ein Schlüsselpaar, eine Schnittstellendatei, einen sysctl-Wert, eine NAT-Regel und eine Firewall-Freigabe. Die Installation ist unkompliziert. Daher behandelt dieser Leitfaden hauptsächlich Fehlerquellen, Berechtigungen für Schlüssel, AllowedIPs, Weiterleitung und DNS.

WireGuard ist ein Layer-3-Tunnel im Kernel und seit Linux 5.6 im Mainline-Kernel enthalten. Ubuntu 24.04 und Debian 13 liefern es daher ohne externes Modul aus. Es gibt keine Aushandlung von Verschlüsselungsverfahren, keine Zertifizierungsstelle und keine Anmeldung mit Benutzername und Passwort. Ein Peer besteht aus einem öffentlichen Schlüssel und den IP-Adressen, die dieser Schlüssel verwenden darf. Ein Paket, dessen MAC-Prüfung fehlschlägt, wird ohne Antwort verworfen. Daher antwortet der Port nicht auf Scans. Der Nachteil: Es gibt keinen Authentifizierungsserver. Um den Zugriff zu entziehen, müssen Sie einen Peer auf dem Server löschen.

Prüfen Sie zuerst die Virtualisierung

WireGuard benötigt einen Kernel, in den ein Modul geladen werden kann. Auf einem KVM-VPS funktioniert es direkt nach der Installation. Bei containerbasierter Virtualisierung mit gemeinsam genutztem Host-Kernel, etwa OpenVZ oder LXC, schlägt der erste Befehl mit RTNETLINK answers: Operation not supported fehl. Verwenden Sie in diesem Fall die Userspace-Implementierung wireguard-go. Prüfen Sie die Umgebung zuerst mit sudo modprobe wireguard && echo ok.

Schlüssel erzeugen, ohne sie offenzulegen

Ein für alle lesbarer /etc/wireguard/server.key entspricht einem VPN, das überhaupt nicht vorhanden ist. Die übliche umask 077 && wg genkey | sudo tee ...-Zeile funktioniert: Sofern sudoers umask_override nicht setzt, was standardmäßig deaktiviert ist, kombiniert sudo Ihre umask mit dem eigenen Standardwert 0022 und setzt die Berechtigungen niemals weiter herab. Die von tee erzeugte Datei hat daher den Modus 600. Schlüssel werden offengelegt, wenn Sie diese Pipe ohne umask 077 und mit einer normalen umask von 022 ausführen oder wenn sudoers auf dem System umask_override aktiviert. Setzen Sie den Modus explizit. Dann spielt dies keine Rolle mehr.

sudo apt update && sudo apt install -y wireguard nftables
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key'
sudo sh -c 'wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'
sudo chmod 600 /etc/wireguard/server.key

Erzeugen Sie das Client-Schlüsselpaar auf dieselbe Weise. wg genpsk fügt einen optionalen Pre-Shared Key hinzu, der in jeder Konfiguration in einer eigenen Zeile steht.

Die Server-Schnittstelle: /etc/wireguard/wg0.conf

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <contents of /etc/wireguard/server.key>

[Peer]
PublicKey = <laptop public key>
PresharedKey = <psk, optional>
AllowedIPs = 10.8.0.2/32

chmod 600; eine Warnung beim Start, dass die Datei für alle Benutzer zugänglich ist, bedeutet, dass Sie diesen Schritt übersprungen haben. Address ist die Serveradresse innerhalb des Tunnels und enthält die Netzmaske des gesamten VPN-Subnetzes. Wählen Sie einen Bereich, der in realen Netzwerken möglichst nicht vorkommt. 192.168.1.0/24 überschneidet sich mit der Hälfte der Heimrouter, hinter denen Ihre Clients sitzen. Der Tunnel verliert dann unbemerkt gegen die lokale Route.

Der AllowedIPs eines Peers auf der Server-Seite ist ein /32, also die eine Tunneladresse, die diesem Client gehört. Wenn Sie zwei Peers dieselbe zulässige IP-Adresse zuweisen, wird sie dem Peer zugeordnet, der zuletzt konfiguriert wurde. Der erste Peer empfängt dann keinen Datenverkehr mehr, ohne dass irgendwo eine Fehlermeldung ausgegeben wird. Lassen Sie SaveConfig nicht gesetzt. Andernfalls überschreibt wg-quick down diese Datei anhand des aktuellen Laufzeitstatus.

Den Server als Router einrichten

Ein Linux-Server verwirft Pakete, die nicht an ihn adressiert sind. Weiterleitung und Source-NAT sind standardmäßig nicht aktiviert.

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\n' \
  | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Ein einzelnes sysctl -w funktioniert nur bis zum nächsten Reboot und wird danach stillschweigend deaktiviert. Für NAT ist das ausgehende Interface erforderlich, also die Netzwerkkarte mit Internetzugang, nicht wg0. Gehen Sie nicht von eth0 aus. Ermitteln Sie den Wert mit ip route show default, da aktuelle Images Namen wie enp1s0 oder ens3 verwenden.

Firewall: der Port und der Weiterleitungspfad

Eine nftables-Datei deckt Filterung und NAT ab. Wenn Sie /etc/nftables.conf ausführen, wird der vorhandene Regelsatz geleert. Überspringen Sie diesen Schritt daher auf einem System, das bereits von ufw oder Docker verwaltet wird.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    udp dport 51820 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "enp1s0" accept
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" masquerade
  }
}

Wenden Sie die Konfiguration mit sudo systemctl enable --now nftables an und halten Sie dabei eine zweite SSH-Sitzung offen: policy drop plus ein Tippfehler in der SSH-Regel sperrt Sie aus Ihrem eigenen Server aus. Beachten Sie, was die Forward-Kette nicht erlaubt, nämlich wg0 zu wg0. Peers erreichen das Internet, aber nicht einander. Fügen Sie iifname "wg0" oifname "wg0" accept für ein Peer-to-Peer-VPN hinzu. Welche Ziele ein Peer auf dem Server selbst erreichen darf, ist nicht Aufgabe dieser Kette: An den Server adressierte Pakete durchlaufen den Input-Hook, niemals die Forward-Kette. Daher entscheidet die Input-Kette. In der gezeigten Konfiguration darf ein Peer SSH erreichen, aber nichts anderes, nicht einmal einen Ping an 10.8.0.1. Fügen Sie dort iifname "wg0" icmp type echo-request accept hinzu. Ergänzen Sie außerdem je eine iifname "wg0"-Regel für jeden Dienst, der nur über den Tunnel erreichbar sein soll. Das ist relevant, wenn der Server zugleich als Remote-Entwicklungsserver mit Claude Code in tmux dient und dieser Bereich nicht öffentlich erreichbar sein soll.

Auf einem System mit ufw: ufw allow 51820/udp, DEFAULT_FORWARD_POLICY="ACCEPT" in /etc/default/ufw sowie eine *nat POSTROUTING-MASQUERADE-Regel an erster Stelle von /etc/ufw/before.rules.

Unter systemd starten

sudo systemctl enable --now wg-quick@wg0
sudo wg show

wg-quick erstellt das Interface, weist die Adressen zu und richtet die aus AllowedIPs abgeleiteten Routen ein. enable --now ist der entscheidende Teil: Ein manuell ausgeführtes wg-quick up wg0 ist nach dem nächsten Reboot nicht mehr vorhanden, und Kernel-Upgrades erfordern Reboots. Eine Unit, die nach einem dieser Reboots nicht erneut startet, bleibt unbemerkt, bis jemand versucht, eine Verbindung herzustellen. Ein OnFailure=-Drop-in für wg-quick@wg0 mit einem Verweis auf Ihren eigenen ntfy-Server ist daher die kostengünstigste Möglichkeit, die Meldung auf Ihrem Telefon zu erhalten, statt von einem ausgesperrten Benutzer darauf hingewiesen zu werden.

Die Client-Konfiguration und die Einstellung, die fast alle falsch setzen

[Interface]
PrivateKey = <laptop private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

AllowedIPs erfüllt gleichzeitig zwei verschiedene Aufgaben. Wenn diese Aufgaben vermischt werden, entstehen die meisten Missverständnisse bei WireGuard.

Ausgehend ist die Einstellung eine Routingtabelle. Ein Paket, dessen Ziel zu AllowedIPs eines Peers passt, wird verschlüsselt und an diesen Peer gesendet. 0.0.0.0/0, ::/0 leitet sämtlichen Datenverkehr durch den Tunnel. Das ist ein vollständiger Tunnel, bei dem der Server als Standardroute dient. Ein Split-Tunnel enthält eine engere Liste: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 überträgt den VPN-Datenverkehr sowie ein privates Netzwerk hinter dem Server. Für alles andere bleibt die lokale Route bestehen. Diese engere Liste ermöglicht es, Dienste vollständig aus dem öffentlichen Internet herauszuhalten. So bleiben beispielsweise eine private Nextcloud-Instanz auf einem VPS, die an die Tunneladresse gebunden ist, oder die VMs des verschachtelten Virtualisierungslabors, die auf demselben System laufen, für Peers erreichbar und für alle anderen unsichtbar.

Eingehend ist die Einstellung eine Zugriffskontrollliste. Ein entschlüsseltes Paket von einem Peer wird verworfen, wenn seine Quelladresse nicht in AllowedIPs dieses Peers enthalten ist. Deshalb trägt der Server für den Laptop 10.8.0.2/32 ein: Ein Eintrag von 0.0.0.0/0 an dieser Stelle würde es dem Client ermöglichen, jede Adresse im Tunnel zu fälschen.

PersistentKeepalive ist für Clients hinter NAT vorgesehen. Der Router hält die UDP-Zuordnung nur offen, solange Datenpakete übertragen werden. Nach ihrem Ablauf kann der Server den Client nicht mehr erreichen. PersistentKeepalive = 25 hält die Zuordnung offen. Setzen Sie diese Einstellung auf dem Client, nicht auf einem Server mit öffentlicher IP-Adresse.

DNS und das Leck, das niemand bemerkt

Mit AllowedIPs = 0.0.0.0/0 und ohne eine Zeile mit DNS = verwendet der Client weiterhin den Resolver, den er aus dem lokalen Netzwerk gelernt hat, also den Router des Cafés unter 192.168.1.1. Diese Route ist spezifischer als die Standardroute. Daher verlassen DNS-Abfragen die Verbindung über den lokalen Link im Klartext, während der gesamte übrige Datenverkehr durch den Tunnel geleitet wird. Der Datenverkehr ist privat. Die Liste der abgefragten Namen ist es nicht.

Es gibt zwei praktikable Optionen. Verweisen Sie DNS auf einen öffentlichen Resolver (DNS = 9.9.9.9). Dann laufen die Abfragen durch den Tunnel und verlassen ihn über Ihren Server. Dieser Resolver kann die Abfragen jedoch weiterhin sehen. Oder führen Sie unbound oder dnsmasq aus, gebunden an 10.8.0.1, setzen Sie DNS = 10.8.0.1 und fügen Sie udp dport 53 iifname "wg0" accept zur Input-Kette hinzu. Setzen Sie diese Zeile und ignorieren Sie den Resolver. Dann wird überhaupt nichts aufgelöst.

Auf Linux-Clients gilt wg-quick für DNS bis resolvconf. Fehlt es, erhalten Sie resolvconf: command not found. Installieren Sie openresolv oder setzen Sie PostUp = resolvectl dns %i 10.8.0.1 auf einem Client mit systemd-resolved.

Peers hinzufügen und entfernen, ohne den Tunnel zu unterbrechen

Wenn Sie zum Hinzufügen eines Benutzers das Interface neu starten, werden alle bestehenden Verbindungen getrennt. Hängen Sie den Block [Peer] an wg0.conf an und laden Sie anschließend die Peer-Konfiguration direkt neu.

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg-quick strip gibt die Konfiguration ohne die nur von wg-quick verwendeten Schlüssel (Address, DNS, PostUp) aus, und syncconf übernimmt die Änderungen, ohne bestehende Sitzungen zu unterbrechen. Der Befehl aktualisiert nur die Peers: Ein geändertes Address erfordert weiterhin ein vollständiges Down/Up. Widerrufen Sie den Peer mit sudo wg set wg0 peer <public key> remove und löschen Sie anschließend den Block aus der Datei. Andernfalls wird er beim nächsten Neuladen erneut übernommen.

Fehlerbilder und die dabei angezeigten Meldungen

Handshake wird nie abgeschlossen. wg show führt den Peer ohne latest handshake auf, und die Client-Logs enthalten:

Handshake for peer 1 (10.0.0.10:51820) did not complete after 5 seconds, retrying (try 2)

Es kommen keine Pakete an oder sie werden nicht akzeptiert. Prüfen Sie in dieser Reihenfolge: Ist UDP 51820 in der VPS-Firewall und in der Netzwerk-Firewall Ihres Providers geöffnet? Bei den meisten Control Panels ist das eine separate Einstellung. Stimmen die Endpoint-Adresse und der Port? Sind die Schlüssel vertauscht? Der Schlüssel im [Peer]-Block des Clients muss der öffentliche Schlüssel des Servers sein und umgekehrt. Wenn Sie dort einen privaten Schlüssel oder den öffentlichen Schlüssel des Clients einfügen, tritt genau dieses Fehlerbild auf. sudo tcpdump -ni any udp port 51820 auf dem Server zeigt, ob überhaupt Pakete eintreffen. Das Kernelmodul protokolliert standardmäßig nichts. WireGuard-Meldungen erscheinen erst nach Aktivierung des dynamischen Debuggings (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) in dmesg. Bei aktiviertem Debugging wird ein Schlüsselkonflikt als Verwerfen wegen einer ungültigen MAC angezeigt.

Handshake funktioniert, kein Internetzugriff. ping 10.8.0.1 ist erfolgreich, aber ping 1.1.1.1 läuft ab: Weiterleitung oder NAT fehlt. Prüfen Sie, ob sysctl net.ipv4.ip_forward den Wert 1 enthält. Beobachten Sie anschließend die Zähler, während der Client pingt, mit sudo nft list ruleset oder sudo iptables -t nat -L POSTROUTING -n -v. Null Pakete in der Masquerade-Regel bedeuten, dass der Name der Ausgangsschnittstelle falsch ist. Ein steigender Zähler ohne Antworten weist auf die Policy der Forwarding-Kette hin.

Internetzugriff funktioniert, Namensauflösung nicht. ping 1.1.1.1 ist erfolgreich, und curl https://example.com liefert Could not resolve host. Die DNS-Zeile fehlt oder nennt einen Resolver, der aus dem Tunnel nicht erreichbar ist.

Einige HTTPS-Sites bleiben hängen. SSH und Ping funktionieren, große Seiten bleiben jedoch stehen. Die Ursache ist die Pfad-MTU: Der Tunnel fügt zusätzlichen Overhead hinzu, und ein Link auf dem Übertragungsweg verwirft möglicherweise übergroße Pakete, ohne dass eine ICMP-Meldung zurückkommt. Setzen Sie MTU auf dem Client [Interface]. Bei einer normalen Verbindung mit 1500 Byte wählt wg-quick bereits 1420 (1500 abzüglich 80 Byte Overhead). Das Eintragen von 1420 ändert daher nichts. Probieren Sie 1380 und anschließend 1280. Wenn eine niedrigere MTU die Unterbrechungen behebt, der Durchsatz aber weiterhin enttäuscht, raten Sie nicht mit runden Werten. Arbeiten Sie stattdessen die tatsächliche Pfad-MTU durch Halbierung ermitteln und die TCP-MSS begrenzen durch. Damit schließen Sie auch Ursachen aus, die nicht im Tunnel liegen.

Schnittstelle startet nicht. Address already in use bedeutet, dass ein anderer Prozess UDP 51820 verwendet. Cannot find device wg0 nach einem fehlgeschlagenen up bedeutet meist, dass die Konfiguration abgelehnt wurde. Lesen Sie journalctl -u wg-quick@wg0 -n 50.

Migration von Streisand oder OpenVPN

Streisand wird nicht mehr gewartet, und sein Repository wurde archiviert. Ein VPN auf nicht mehr gepflegter Automatisierung zu betreiben, ist ein schleichendes Sicherheitsproblem. Es gibt kein Upgrade am bestehenden System, und die PKI von OpenVPN lässt sich nicht konvertieren: WireGuard verwendet keine Zertifikate, keine CA und keine Ablaufdaten. Daher erhält jeder Client ein neues Schlüsselpaar.

Führen Sie die Migration parallel durch. WireGuard auf UDP 51820 kann auf demselben System neben OpenVPN auf 1194 betrieben werden. Richten Sie wg0 ein, migrieren Sie die Clients einzeln und beenden Sie anschließend den alten Dienst. Das Benutzername-/Passwortmodell und das Sperrmodell von OpenVPN lassen sich nicht übernehmen. Wenn Sie Benutzerkonten oder eine Prüfspur benötigen, setzen Sie diese oberhalb von WireGuard um.

Backups, Upgrades und Belastungen bei größerem Umfang

/etc/wireguard ist der Server. Sichern Sie ihn (sudo tar czf wg-backup.tgz -C /etc wireguard, Modus 600, außerhalb des Servers aufbewahrt). Dann können Sie ihn innerhalb weniger Minuten auf einem frischen VPS neu aufbauen. Wenn Sie den privaten Schlüssel des Servers verlieren, müssen Sie jede Client-Konfiguration neu ausstellen, weil die Clients den öffentlichen Schlüssel des Servers fest hinterlegen. Upgrades bestehen aus einem normalen apt upgrade und einem Reboot für Kernel-Updates. wg-quick@wg0 wird automatisch wieder aktiv, wenn Sie es aktiviert haben.

Der Zustand pro Peer ist klein, und die Kryptografie läuft im Kernel. Die Obergrenze wird daher durch die CPU- und Bandbreitenressourcen Ihres VPS bestimmt, nicht durch etwas in dieser Konfiguration. Messen Sie sie mit iperf3 über den Tunnel, statt einer veröffentlichten Angabe zu vertrauen. Bei größerem Umfang wird der Betrieb anspruchsvoll. Jeder Peer benötigt eine eindeutige Tunnel-IP. Sechzig [Peer]-Blöcke von Hand zu bearbeiten, führt leicht zu doppelten AllowedIPs. Generieren Sie die Konfigurationen daher mit einem Skript. Ein Server bedeutet einen UDP-Endpunkt und einen einzelnen Ausfallpunkt. WireGuard bietet kein Clustering. Redundanz bedeutet einen zweiten Server mit eigenen Schlüsseln. Der Schlüsselaustausch bleibt manuell. Dokumentieren Sie daher, wer welchen Schlüssel besitzt und wie Sie einen Schlüssel widerrufen. Wenn diese Verwaltung den Umfang einer Textdatei überschreitet, ist eine Control Plane auf derselben Kernel-Data-Plane die übliche Lösung. Ein selbst gehosteter NetBird-Server übernimmt die Adresszuweisung, die Verteilung der Peers und die Setup-Schlüssel, die Sie sonst von Hand verwalten müssten. Wenn der eigene Betrieb dieser Control Plane einen weiteren Server bedeutet, hosts Tailscale eine für Sie. Der kostenlose Personal-Tarif umfasst sechs Benutzer mit unbegrenzt vielen Geräten pro Benutzer und zunächst bis zu 50 markierten Ressourcen wie Servern. Das reicht aus, sodass die meisten privaten Umgebungen dafür nie bezahlen. Darüber hinaus richtet sich die Abrechnung nach Personen und nicht nach Geräten. Was ein Haushalt oder ein kleines Team tatsächlich bezahlt, hängt also davon ab, wie viele Personen Anmeldedaten besitzen, nicht davon, wie viele Peers Sie von Hand in wg0.conf eintragen müssten. Auf dieser Seite wird die Verwaltung des Split-Tunnels mit AllowedIPs zu der Ankündigung Ihrer privaten Bereiche über einen Subnet Router. Die Ankündigung erfolgt einmalig von einem VPS und wird zentral genehmigt, statt in jede Client-Datei kopiert zu werden. Ob sich dieser Wechsel lohnt, hängt davon ab, welche Ziele eine gehostete Control Plane tatsächlich erreichen kann. Sie besitzt niemals die Schlüssel, die Ihren Datenverkehr verschlüsseln, entscheidet aber, welche Peers voneinander erfahren.

Für all dies benötigen Sie einen Linux-Server, den Sie kontrollieren, eine öffentliche IP-Adresse, einen Kernel, in den Sie ein Modul laden können, sowie eine Firewall, die Sie vollständig selbst verwalten.

FAQ

Warum wird der WireGuard-Handshake nie abgeschlossen?

wg show Wenn ein Peer ohne latest handshake gelistet wird, bedeutet dies, dass keine Pakete ankommen oder nicht akzeptiert werden. Prüfen Sie UDP 51820 sowohl in der VPS-Firewall als auch in der separaten Netzwerk-Firewall Ihres Anbieters, bestätigen Sie den Endpoint-Host und -Port und stellen Sie sicher, dass die Schlüssel nicht vertauscht sind. Der [Peer]-Block des Clients muss den öffentlichen Schlüssel des Servers enthalten. sudo tcpdump -ni any udp port 51820 auf dem Server zeigt, ob überhaupt Pakete ankommen; dmesg meldet WireGuard-Handshake-Fehler erst, nachdem Sie das dynamische Debugging aktiviert haben (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control). Ein Schlüssel-Mismatch erscheint dann als invalid-MAC-Drop.

Der Tunnel steht, aber ich habe kein Internet. Was fehlt?

Wenn ping 10.8.0.1 funktioniert, aber bei ping 1.1.1.1 Timeouts auftreten, deutet dies auf Probleme mit Forwarding oder NAT hin. Bestätigen Sie, dass sysctl net.ipv4.ip_forward auf 1 steht und dies in /etc/sysctl.d/ gesetzt ist, nicht nur mit einem sysctl -w, der nach einem Neustart verloren geht. Prüfen Sie dann die Masquerade-Regel, die Ihr tatsächliches Ausgangs-Interface aus ip route show default, enp1s0 oder ens3 benennt, selten eth0.

Benötige ich die DNS =-Zeile in meiner Client-Konfiguration?

Bei einem Full-Tunnel ohne DNS =-Zeile behält der Client den Resolver bei, den er aus dem lokalen Netzwerk gelernt hat. Diese Anfragen verlassen das System im Klartext über die lokale Verbindung, während der gesamte restliche Datenverkehr getunnelt wird. Setzen Sie DNS auf einen öffentlichen Resolver oder betreiben Sie unbound/dnsmasq gebunden an 10.8.0.1 und öffnen Sie udp dport 53 iifname "wg0" in der Input-Chain.

Was steuert AllowedIPs eigentlich?

Es erfüllt zwei Aufgaben. Ausgehend fungiert es als Routing-Tabelle: Datenverkehr, der auf das AllowedIPs eines Peers passt, wird verschlüsselt und an diesen Peer gesendet. Eingehend fungiert es als Access-Control-List: Ein entschlüsseltes Paket, dessen Quelle außerhalb des AllowedIPs dieses Peers liegt, wird verworfen. Deshalb listet die Serverseite ein /32 pro Client, während die Clientseite 0.0.0.0/0 listen kann.

Läuft WireGuard auf jedem VPS?

Auf einem KVM-VPS funktioniert es mit dem In-Kernel-Modul ohne zusätzliche Einrichtung. Bei Container-Virtualisierungen, die sich den Host-Kernel teilen, wie OpenVZ oder LXC, schlägt modprobe wireguard mit Operation not supported fehl, und der Fallback ist die wireguard-go-Userspace-Implementierung. Führen Sie sudo modprobe wireguard && echo ok vor allen anderen Schritten aus.