NoctisNode
← GuidesNetzwerk2026-10-238 Min.

WireGuard PersistentKeepalive 25 und PresharedKey auf einem VPS

PersistentKeepalive = 25 sendet alle 25 s ein Keepalive, damit NAT den Tunnel offen hält; setzen Sie es auf dem Client hinter NAT. PresharedKey ergänzt eine symmetrische Absicherung gegen Quantenangriffe.

Kurz gesagt: `PersistentKeepalive = 25` weist WireGuard an, alle 25 Sekunden ein winziges authentifiziertes Paket an den Peer zu senden. Das hält NAT- und Stateful-Firewall-Zuordnungen am Leben, sodass die Gegenseite Sie weiterhin erreicht. Normalerweise setzen Sie es nur auf dem Peer hinter NAT (Laptop, Smartphone oder Heimrouter), nicht auf einem VPS mit öffentlicher IP. `PresharedKey` ist ein optionales zusätzliches symmetrisches 256-Bit-Geheimnis pro Peer-Paar, erzeugt mit `wg genpsk`, das als Absicherung gegen künftige Quantenangriffe auf Curve25519 in den Handshake eingemischt wird.

Diese Anleitung erklärt beide Optionen und liefert eine funktionierende Server- und Client-Konfiguration für einen WireGuard-VPS. Für das komplette VPN-Setup mit NAT und DNS siehe die Anleitung zu WireGuard-VPN.

Was PersistentKeepalive = 25 tatsächlich bewirkt

WireGuard ist von Natur aus still: Fließen keine Daten, sendet es nichts. Das ist gut für Privatsphäre und Akku, aber Router mit NAT und Connection Tracking verwerfen inaktive UDP-Zuordnungen, oft nach 30 Sekunden, manchmal nach einigen Minuten. Ist die Zuordnung weg, erreichen Pakete vom Server einen Client hinter NAT nicht mehr, bis der Client wieder etwas sendet.

`PersistentKeepalive` ist ein Intervall in Sekunden. Mit `25` sendet der Peer ein leeres, verschlüsseltes Keepalive, sobald er 25 Sekunden lang nichts gesendet hat. Der Wert 25 wird in der WireGuard-Dokumentation empfohlen, weil er sicher unter den kürzesten üblichen UDP-Timeouts liegt. Die Einstellung ist standardmäßig aus (`0`), und der Overhead beträgt ein kleines Paket etwa alle 25 Sekunden pro Peer.

WertWirkungWann verwenden
0 oder nicht gesetztKeine Keepalives; der Tunnel ist im Leerlauf stillBeide Peers haben öffentliche IPs, oder nur der Client initiiert jemals Traffic
25Keepalive nach jeweils 25 s LeerlaufClient hinter NAT oder CGNAT, der erreichbar bleiben muss
15–20Häufigere KeepalivesNetze mit ungewöhnlich aggressiven UDP-Timeouts
60+Weniger Pakete, höheres Risiko, die Zuordnung zu verlierenSelten sinnvoll; die meisten NAT-Geräte laufen früher ab

Welche Seite PersistentKeepalive braucht

Setzen Sie das Keepalive auf dem Peer, der nicht direkt erreichbar ist — also dem hinter NAT. Dieser Peer sendet die Pakete nach außen und frischt so seine eigene NAT-Zuordnung auf. Vor einem VPS mit öffentlicher IPv4-Adresse liegt kein NAT, er braucht die Option also nicht, um erreichbar zu bleiben, und er kann ein entferntes NAT auch nicht selbst offen halten, weil er den Endpunkt des Clients nur aus dessen Paketen erfährt.

Surft der Client nur über den Tunnel, verbindet er sich sofort neu, sobald er Traffic sendet — ein Keepalive ist dann optional. Sie brauchen es, wenn der Server oder andere Peers Verbindungen zum Client aufbauen müssen, etwa SSH auf einen Rechner zu Hause, Monitoring oder eine Site-to-Site-Verbindung.

  • ▹Laptop oder Smartphone hinter NAT zum VPS: `PersistentKeepalive = 25` nur auf dem Client setzen.
  • ▹VPS zu VPS, beide mit öffentlichen IPs: meist nicht setzen; siehe [die Anleitung zum WireGuard-Mesh](/guides/wireguard-mesh-vps-cluster).
  • ▹Heimserver hinter CGNAT, über einen VPS veröffentlicht: auf dem Heimserver setzen, sonst verliert der VPS den Pfad innerhalb von Minuten.
  • ▹Mobile Clients: Ein Keepalive kostet etwas Akku; aktivieren Sie es nur, wenn das Gerät erreichbar sein muss.

PresharedKey: die optionale symmetrische Schicht

Der Handshake von WireGuard nutzt den Schlüsselaustausch Curve25519. Ein ausreichend großer Quantencomputer könnte diesen Austausch theoretisch brechen, und ein Angreifer könnte Traffic heute aufzeichnen und später entschlüsseln. `PresharedKey` mischt einen zusätzlichen symmetrischen 256-Bit-Schlüssel in den Handshake. Symmetrische Schlüssel dieser Größe gelten mit bekannten Quantenalgorithmen als praktisch nicht knackbar — bleibt der PSK geheim, bleibt aufgezeichneter Traffic also geschützt, selbst wenn der Public-Key-Teil gebrochen wird.

Der PSK gilt pro Peer-Paar, muss in den `[Peer]`-Abschnitten beider Peers identisch sein und sollte für jedes Paar einzigartig sein. Er ersetzt die privaten Schlüssel nicht, sondern ist eine zusätzliche Schicht. Stimmen die PSKs nicht überein, schlägt der Handshake stillschweigend fehl, und Sie sehen in `wg show` kein `latest handshake`.

  • ▹Erzeugen Sie ihn mit `wg genpsk`, das einen zufälligen, base64-kodierten 32-Byte-Schlüssel ausgibt.
  • ▹Übertragen Sie ihn über einen Kanal, dem Sie bereits vertrauen, etwa SSH — nie per Chat oder E-Mail.
  • ▹Nutzen Sie einen PSK pro Paar: In einem Mesh aus fünf Nodes sind das zehn verschiedene PSKs.
  • ▹Rotieren Sie ihn wie jedes andere Geheimnis, wenn ein Gerät verloren geht oder ausgemustert wird.

Schlüssel und einen PresharedKey erzeugen

Installieren Sie die Tools unter Debian 12/13 oder Ubuntu 24.04 mit `apt install wireguard` und erzeugen Sie die Schlüssel dann auf der Maschine, auf der der jeweilige private Schlüssel liegen wird. Den PSK können Sie auf einer der beiden Seiten erzeugen und auf die andere kopieren. `umask 077` stellt sicher, dass die Dateien nur für root lesbar sind.

umask 077
cd /etc/wireguard

# on the VPS
wg genkey | tee server.key | wg pubkey > server.pub

# on the client
wg genkey | tee client.key | wg pubkey > client.pub

# once, on either side; copy to the other over SSH
wg genpsk > client.psk

Server-Konfiguration auf dem VPS: /etc/wireguard/wg0.conf

Der Server hat einen festen Listen-Port, kein Keepalive und keinen `Endpoint` für den Client, weil er die aktuelle Adresse des Clients aus authentifizierten Paketen erfährt.

[Interface]
Address = 10.8.0.1/24, fd08::1/64
ListenPort = 51820
PrivateKey = <contents of server.key>

[Peer]
# laptop
PublicKey = <contents of client.pub>
PresharedKey = <contents of client.psk>
AllowedIPs = 10.8.0.2/32, fd08::2/128

Note · Öffnen Sie UDP 51820 in der VPS-Firewall und starten Sie den Tunnel mit `systemctl enable --now wg-quick@wg0`. Sichern Sie SSH wie in der Anleitung zur SSH-Härtung beschrieben ab und prüfen Sie die Schlüsselrechte mit der Anleitung zu StrictModes, bevor Sie irgendetwas anderes freigeben.

Client-Konfiguration hinter NAT

Der Client zeigt auf die öffentliche Adresse des VPS und trägt das Keepalive. Verwenden Sie `AllowedIPs = 10.8.0.0/24, fd08::/64` für einen rein privaten Tunnel oder `0.0.0.0/0, ::/0`, um sämtlichen Traffic über den VPS zu leiten.

[Interface]
Address = 10.8.0.2/32, fd08::2/128
PrivateKey = <contents of client.key>

[Peer]
PublicKey = <contents of server.pub>
PresharedKey = <contents of client.psk>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.8.0.0/24, fd08::/64
PersistentKeepalive = 25

Note · Ein NoctisNode-Wisp-VPS (1 vCPU, 1 GB RAM, $6 pro 28-Tage-Zyklus) mit dedizierter IPv4 reicht für einen persönlichen WireGuard-Endpunkt und lässt sich mit Monero oder anderer Krypto bezahlen — bei der Registrierung genügen E-Mail und Passwort.

Prüfen und Fehler beheben

Führen Sie `wg show` auf beiden Seiten aus. Ein gesunder Client zeigt für den Peer ein aktuelles `latest handshake`, `persistent keepalive: every 25 seconds` und `preshared key: (hidden)`.

  1. 01.Überhaupt kein Handshake: Prüfen Sie, ob UDP 51820 auf dem VPS offen ist und `Endpoint` die richtige IP und den richtigen Port nutzt.
  2. 02.Handshake klappt ohne PSK, aber nicht mit: Der PresharedKey unterscheidet sich zwischen den beiden Konfigurationen; kopieren Sie ihn erneut.
  3. 03.Der Tunnel funktioniert, aber nach einer Minute erreicht der Server den Client nicht mehr: Fügen Sie `PersistentKeepalive = 25` auf dem Client hinzu.
  4. 04.Keepalive ohne Neustart ändern: `wg set wg0 peer <server-public-key> persistent-keepalive 25`.
  5. 05.Einen PSK zur Laufzeit aus einer Datei hinzufügen: `wg set wg0 peer <public-key> preshared-key /etc/wireguard/client.psk`.

FAQ

QWas bedeutet PersistentKeepalive 25 in WireGuard?

ADer Peer sendet nach 25 Sekunden ohne sonstigen Traffic ein verschlüsseltes Keepalive-Paket. Das hält NAT- und Firewall-Zuordnungen offen, sodass der Tunnel von der Gegenseite erreichbar bleibt.

QGehört PersistentKeepalive auf den Server oder den Client?

AAuf den Peer hinter NAT, also fast immer den Client. Ein VPS mit öffentlicher IP braucht es nicht und kann die NAT-Zuordnung des Clients auch nicht selbst offen halten.

QIst ein WireGuard-PresharedKey Pflicht?

ANein, er ist optional. Er fügt dem Handshake ein symmetrisches Geheimnis als Absicherung gegen künftige Quantenangriffe auf Curve25519 hinzu und ist damit eine gute Standardwahl für langlebige Tunnel.

QWie erzeuge ich einen WireGuard-PresharedKey?

AFühren Sie `wg genpsk > peer.psk` aus und tragen Sie denselben Wert in die Zeile `PresharedKey` der `[Peer]`-Abschnitte beider Peers ein. Nutzen Sie für jedes Peer-Paar einen anderen PSK.

QVerbraucht PersistentKeepalive viel Bandbreite?

ANein. Es sendet etwa alle 25 Sekunden Leerlauf ein kleines Paket, was auf einem VPS vernachlässigbar ist, auf Smartphones aber die Akkulaufzeit leicht verringern kann.

WireGuard PersistentKeepalive 25 und PresharedKey auf einem VPS · NoctisNode