VPNSmith
Contabo-VPS
self-host-vpnINFO

Zwei Geräte, ein WireGuard-Schlüssel: Was wirklich kaputtgeht und warum es zufällig wirkt

Eine Client-Konfiguration auf Handy und Laptop zu kopieren funktioniert, bis beide verbunden sind. Dann geht der Verkehr an das Gerät mit dem letzten Handshake, der Server kann sie nicht unterscheiden, und du kannst keines sperren, ohne das andere abzuschneiden. Was das Protokoll macht, und die Lösung in drei Befehlen.

Von Eric Gerard · Gründer · VPNSmith - Spezialist für selbstgehostete VPNs & DSGVO-VPS4 Min. LesezeitFoto via Pexels

Du richtest WireGuard auf einem Laptop ein, es funktioniert, und dieselbe Konfiguration aufs Handy zu kopieren dauert zehn Sekunden. Beide verbinden sich. Eine Weile sieht nichts falsch aus.

Dann sind beide gleichzeitig verbunden, und eines bekommt keinen Verkehr mehr. Ohne Fehlermeldung, nicht reproduzierbar, und meistens dann, wenn du gerade etwas anderes erledigen willst.

Die Lösung ist ein Schlüsselpaar pro Gerät. Unser kostenloser WireGuard-Konfigurationsgenerator erzeugt in deinem Browser für jeden Peer ein eigenes Schlüsselpaar, eine eigene Adresse und eine eigene Konfiguration, und falls der Server selbst noch gemietet werden muss: Ein Contabo Cloud VPS 4 für 5,50 €/Monat (Affiliate-Link) kommt mit eigener öffentlicher IPv4. Wenn dir ein US-Host mit 30 Tagen Geld-zurück-Garantie lieber ist, kostet Ultahost VPS Basic 5,52 $ im Monat bei 24 Monaten Laufzeit (1 GB RAM, dedizierte IPv4, gelesen am 21. Oktober 2026), genug für einen WireGuard-Server für ein paar Geräte. Der Generator ist bis 10 Geräte kostenlos; darüber hinaus hebt WireGuard Pro (unser eigenes Produkt, einmalig 9 EUR, kein Abo) die Grenze auf 250 an und liefert ein ZIP mit jeder Client-.conf und ihrem QR-Code als PNG, praktisch, um ein ganzes Büro oder eine Familie in einem Rutsch einzurichten.

Was der Server sieht

WireGuard erkennt einen Peer an seinem öffentlichen Schlüssel. Nicht an der IP, nicht am Gerät, nicht am Namen. Zwei Geräte mit demselben privaten Schlüssel sind für den Server ein Peer, der ständig umzieht.

Jeder Handshake aktualisiert den für diesen Peer gespeicherten Endpoint, also Adresse und Port, an die der Server antwortet. Das Handy macht einen Handshake, die Antworten gehen ans Handy. Der Laptop macht einen Handshake, die Antworten gehen an den Laptop. Das Gerät ohne den jüngsten Handshake schickt weiter Pakete, die problemlos ankommen, und bekommt nichts mehr zurück.

Das ist der ganze Mechanismus, und er erklärt das Symptom genau: eine Verbindung, die in Abständen, die niemand steuert, zwischen zwei Geräten hin und her springt, weil du das Handshake-Intervall nicht planst.

Die drei Folgen, sortiert danach, was sie dich kosten

Du kannst sie nicht unterscheiden. wg show listet einen Peer, eine Handshake-Zeit, einen Transferzähler. Der Verkehr von Handy und Laptop wird zusammengezählt. Musst du je wissen, welches Gerät etwas getan hat, gibt es diese Information schlicht nicht.

Du kannst nicht eines allein sperren. Den Schlüssel vom Server zu entfernen entzieht jedem Gerät, das ihn besitzt, den Zugang. Ein verlorenes Handy heißt, auch den Laptop abzuschneiden und dann beiden neu auszustellen.

AllowedIPs wird mehrdeutig. Auf dem Server ordnet AllowedIPs ein Paket einem Peer zu. Zwei Geräte hinter einem Peer-Eintrag teilen sich eine Tunneladresse, also erreicht alles, was an diese Adresse geroutet wird, das Gerät, das gerade den Endpoint hält.

Ein Schlüsseldienst arbeitet an einer Werkbank in seiner Werkstatt und schneidet einen Schlüssel auf einer Maschine, hinter ihm hängen Hunderte Schlüsselrohlinge an einer Lochwand
Ein Schlüsseldienst arbeitet an einer Werkbank in seiner Werkstatt und schneidet einen Schlüssel auf einer Maschine, hinter ihm hängen Hunderte Schlüsselrohlinge an einer Lochwand

Die Lösung: ein Schlüssel und eine Adresse pro Gerät

Auf dem Client, oder auf dem Server, wenn du für jemand anderen erzeugst:

wg genkey | tee phone.key | wg pubkey > phone.pub

Auf dem Server einen Peer-Block pro Gerät hinzufügen, jeder mit eigener Adresse:

[Peer]
# laptop
PublicKey = <laptop.pub>
AllowedIPs = 10.10.0.2/32

[Peer]
# phone
PublicKey = <phone.pub>
AllowedIPs = 10.10.0.3/32

Im laufenden Betrieb hinzufügen, ohne jemanden zu trennen:

wg set wg0 peer <phone.pub> allowed-ips 10.10.0.3/32

⛔ Dann trag es auch in die Konfigurationsdatei ein. wg set ändert das laufende Interface und nichts auf der Platte; ein Neustart verliert es. Diese Falle und der restliche Lebenszyklus eines Peers stehen in einen WireGuard-Peer hinzufügen.

Ein Gerät später zu entfernen ist dann ein einziger Befehl, und er berührt nichts anderes:

wg set wg0 peer <phone.pub> remove

Die Kommentarzeile ist keine Deko

Nichts im Protokoll trägt einen Gerätenamen, eine Peer-Liste aus zwölf öffentlichen Schlüsseln ist sechs Monate später also unlesbar. Ein Kommentar # phone über jedem Block ist die einzige Beschriftung, die es je geben wird, und an dem Tag, an dem du einen davon schnell sperren musst, wirst du sie haben wollen.

Zwei benachbarte Fälle, die etwas anderes sind

Ein Preshared Key wird absichtlich geteilt. PresharedKey ist symmetrisch und muss auf beiden Enden eines Peer-Paars identisch sein. Das ist keine Wiederverwendung eines Schlüssels über Geräte hinweg, und die beiden werden leicht verwechselt: siehe die Anleitung zum Preshared Key.

Ein Gerät, mehrere Tunnel ist ebenfalls kein Problem. Ein Laptop kann für verschiedene Server verschiedene Schlüssel haben, ohne Konflikt, weil die Identität pro Tunnel gilt und nicht pro Rechner.

Wenn du regelmäßig Konfigurationen an Geräte verteilst, ist das Erzeugen des QR-Codes der schnelle Teil, und es verdient dieselbe Disziplin: der WireGuard-QR-Code enthält den privaten Schlüssel vollständig, also ein Code pro Gerät und nie ein geteilter.

★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200-Mbit/s-Port

Hoste dein VPN auf deinem eigenen VPS → ContaboVoller Root-Zugriff · öffentliche IPv4 · wähle deine Region→

Häufig gestellte Fragen

Können zwei Geräte denselben WireGuard-Schlüssel nutzen?
Sie können sich verbinden, und genau das führt in die Irre. Der Server erkennt einen Peer an seinem öffentlichen Schlüssel, zwei Geräte mit einem gemeinsamen Schlüssel sind für ihn also ein einziger Peer. Nur der jüngste Handshake hält den Endpoint, deshalb geht der Rückverkehr immer nur an ein Gerät.
Was genau geht kaputt, wenn ich einen Schlüssel mehrfach verwende?
Der Rückverkehr folgt dem Gerät mit dem letzten Handshake, das andere scheint also zufällig die Verbindung zu verlieren. Der Server kann die beiden weder in wg show noch in irgendeinem Log unterscheiden. Und wenn du einem Gerät den Zugang entziehst, entziehst du ihn beiden, weil es nur einen Schlüssel zum Entfernen gibt.
Ist ein geteilter Schlüssel ein Sicherheitsproblem oder nur ein Routingproblem?
Beides, und die Sicherheitsseite wiegt länger als die Unannehmlichkeit. Ein Schlüssel auf einem Handy, das später verloren geht, ist derselbe Schlüssel, der noch auf dem Laptop installiert ist, also bleibt nur, ihn überall zu sperren und neu auszustellen. Ein Schlüssel pro Gerät macht daraus eine Änderung in einer Zeile.
Wie viele Peers kann ein WireGuard-Server haben?
In der Praxis gibt es keine kleine feste Grenze; die Peer-Liste liegt im Speicher, und Tausende sind auf gewöhnlicher Hardware machbar. Einen Peer pro Gerät hinzuzufügen kostet nichts, und damit fällt das letzte Argument fürs Teilen weg.
Können zwei Peers dieselbe AllowedIPs-Adresse haben?
Nein. AllowedIPs ist auf dem Server das Mittel, mit dem er entscheidet, zu welchem Peer ein Paket gehört. Zwei Peers, die beide 10.10.0.2/32 beanspruchen, erzeugen eine Mehrdeutigkeit, die der Kernel auflöst, indem er einen von ihnen nimmt. Jedes Gerät braucht seine eigene Tunneladresse.