So beheben Sie WireGuard-Handshake-Fehler (Fehlerbehebungsanleitung)

Der Handshake von WireGuard ist der anfängliche Schlüsselaustausch, der gelingen muss, bevor überhaupt Traffic durch den Tunnel fließen kann. Schlägt er fehl, erhalten Sie eine Verbindung, die korrekt konfiguriert wirkt, aber nie tatsächlich Daten überträgt, und die Fehlermeldungen sind meist wenig hilfreich, nur ein „handshake did not complete" oder gar nichts. So arbeiten Sie die tatsächlichen Ursachen in der Reihenfolge durch, in der sie am wahrscheinlichsten das Problem sind.

Was der Handshake tatsächlich macht

WireGuard nutzt ein kryptografisches Framework namens Noise, um eine sichere Sitzung zwischen Ihrem Gerät und dem Server aufzubauen, bevor überhaupt echter Traffic fließt. Beide Seiten müssen sich über UDP erreichen, gegenseitig ihre öffentlichen Schlüssel prüfen und diesen Austausch innerhalb weniger Sekunden abschließen. Ist irgendein Teil dieses Pfads blockiert, falsch konfiguriert oder inkonsistent, scheitert der Handshake still und versucht es in einer Schleife erneut, statt einen klaren Fehler zu werfen, weshalb die Ursachendiagnose eher methodisches Prüfen erfordert als das Lesen einer offensichtlichen Log-Meldung.

Schritt 1: Prüfen, ob die Schnittstelle überhaupt aktiv ist

Führen Sie unter Linux sudo wg show aus, oder prüfen Sie auf anderen Plattformen den Verbindungsstatus Ihrer App, um zu bestätigen, dass die WireGuard-Schnittstelle überhaupt aktiv ist. Ist die Schnittstelle selbst nicht aktiv, liegt das Problem in Ihrer Konfigurationsdatei oder App-Einrichtung, nicht im Netzwerkpfad, und der Rest dieser Fehlerbehebung gilt noch nicht. Beheben Sie zuerst alle an dieser Stelle gemeldeten Fehler. Ein einfacher Neustart des Netzwerkdienstes kann an diesem Punkt manchmal schon reichen, bevor Sie tiefer in die Konfiguration einsteigen.

Schritt 2: Auf einen blockierten UDP-Port prüfen

WireGuard läuft über UDP, standardmäßig meist über Port 51820, auch wenn Anbieter einen anderen Port verwenden können. Manche Hotel-, Flughafen-, Firmen- und Campus-Netzwerke blockieren oder beschränken ausgehenden UDP-Traffic gezielt stark, da UDP für normales Surfen weniger üblich ist und eher mit VPNs und Gaming assoziiert wird. Wechseln Sie testweise zu einem mobilen Hotspot, um das auszuschließen: Gelingt der Handshake in einem anderen Netzwerk sofort, ist die Firewall des ursprünglichen Netzwerks das eigentliche Problem, und keine Konfigurationsanpassung Ihrerseits behebt das. Manche Anbieter bieten speziell für solche restriktiven Netzwerke eine TCP-basierte Verschleierungsoption, die sich lohnt, wenn UDP dort konstant blockiert wird.

Alle VPNs im direkten Vergleich? Unser vollständiger VPN-Vergleich zeigt Bewertungen nach 18 Kriterien.

Schritt 3: Öffentlichen und privaten Schlüssel doppelt prüfen

Ein nicht zusammenpassendes Schlüsselpaar ist eine der häufigsten Ursachen für einen stillen Handshake-Fehler, besonders wenn Sie Schlüssel manuell zwischen einer Client- und einer Server-Konfiguration kopieren, statt die App eines Anbieters zu nutzen. Prüfen Sie, ob der PrivateKey des Clients zum öffentlichen Schlüssel passt, den der Server für Sie hinterlegt hat, und ob der öffentliche Schlüssel des Servers in Ihrer Client-Konfiguration dem entspricht, was der Server tatsächlich vorweist. Ein einzelnes zusätzliches Leerzeichen, ein fehlendes Zeichen oder ein durch Copy-Paste versehentlich abgeschnittener Schlüssel reicht, um den Handshake ohne jedes andere Symptom zu brechen.

Schritt 4: Endpunkt-Adresse und Port prüfen

Die Endpoint-Zeile Ihrer Konfiguration braucht die korrekte aktuelle IP-Adresse (oder den Hostnamen) und den Port des Servers. Hat ein Anbieter kürzlich Server-IPs rotiert, scheitert eine alte, zwischengespeicherte Konfiguration, die auf eine inzwischen nicht mehr existierende Adresse zeigt, still, statt einen klaren DNS- oder Verbindungsfehler zu melden. Eine frische Konfigurationsdatei erneut vom Anbieter herunterzuladen, statt eine ältere gespeicherte wiederzuverwenden, löst das in den meisten Fällen.

Schritt 5: PersistentKeepalive hinzufügen, wenn Sie hinter NAT sind

Ist Ihr Gerät hinter dem NAT eines Heimrouters, oder schlimmer, dem CGNAT eines Mobilfunkanbieters (Carrier-Grade NAT, verbreitet bei mobilen Datenverbindungen), kann der Server nach dem anfänglichen Handshake-Versuch die Fähigkeit verlieren, Sie zu erreichen, da die NAT-Zuordnung für diese Verbindung durch Inaktivität ablaufen kann. Das Hinzufügen von PersistentKeepalive = 25 im Peer-Abschnitt Ihrer Client-Konfiguration weist WireGuard an, alle 25 Sekunden ein kleines Keepalive-Paket zu senden, wodurch die NAT-Zuordnung offen bleibt und der Server Sie weiterhin erreichen kann. Diese einzige Zeile behebt einen großen Teil der Fälle von „verbindet sich, bricht dann ab" und sporadischen Handshake-Problemen speziell in mobilen Netzen.

Schritt 6: AllowedIPs-Einstellung überprüfen

Das Feld AllowedIPs bestimmt, welcher Traffic durch den Tunnel geleitet wird, und ein falsch konfigurierter Wert hier kann eine Routing-Schleife erzeugen, die verhindert, dass die Handshake-Pakete selbst die richtige Schnittstelle erreichen. Wenn Sie eher Fehler beheben als Split Tunneling feinjustieren, schließt ein testweises Setzen von AllowedIPs = 0.0.0.0/0 (aller Traffic durch den Tunnel) eine routing-spezifische Fehlkonfiguration als Ursache aus, und Sie können es wieder einengen, sobald die Grundverbindung funktioniert.

Schritt 7: MTU senken, wenn der Handshake gelingt, aber kein Traffic fließt

Meldet wg show einen erfolgreichen, aktuellen Handshake, aber es lässt sich trotzdem nichts laden, ist eine zu große MTU (maximale Übertragungseinheit), die zu Paketfragmentierung führt, ein häufiger Übeltäter, besonders bei Verbindungen mit zusätzlichem Overhead wie mobilen Daten oder bestimmten Konfigurationen von Internetanbietern. Versuchen Sie, die MTU in Ihrer Konfiguration auf 1280 oder 1380 zu senken (von WireGuards Standard von 1420) und neu zu verbinden. Dieses spezifische Symptom, ein erfolgreicher Handshake ohne tatsächlichen Datenfluss, ist eines der klareren Signale, das auf die MTU statt auf den Handshake-Prozess selbst hindeutet.

Schritt 8: Sauber neu starten statt auf eine feststeckende Sitzung erneut zu verbinden

Manchmal ist die Lösung tatsächlich Aus- und wieder Einschalten, aber es richtig zu machen zählt. Fahren Sie die Schnittstelle vollständig herunter (sudo wg-quick down wg0), bevor Sie sie wieder hochfahren, statt zu versuchen, sich über eine Sitzung hinweg erneut zu verbinden, die WireGuard noch für aktiv hält. Ein festgefahrener Zustand der Schnittstelle auf Kernel-Ebene, besonders nachdem ein Laptop aus dem Ruhezustand aufwacht, ist eine häufige und unspektakuläre Ursache, die ein sauberer Neustart löst, ohne dass eine der tiefergehenden Fehlerbehebungen oben nötig wäre.

Wenn es ein Problem beim Anbieter ist, nicht bei Ihnen

Wenn nichts davon hilft, und besonders wenn dieselbe Konfiguration gestern noch problemlos funktioniert hat, prüfen Sie, ob der konkrete Server, mit dem Sie sich verbinden, gerade einen Ausfall oder ein Wartungsfenster hat. Zu einem anderen Serverstandort über die App Ihres Anbieters zu wechseln, ist ein schnellerer Diagnoseschritt, als weiter eine Konfiguration zu debuggen, die vielleicht korrekt ist, aber auf einen schlicht ausgefallenen Server zeigt. Die meisten großen Anbieter veröffentlichen Server-Statusseiten oder Support-Kanäle, auf denen solche Ausfälle schnell bestätigt werden. Das ist eine Fünf-Minuten-Prüfung, die viel verschwendete Zeit erspart, in der man an einer Konfigurationsdatei zweifelt, die eigentlich nie das Problem war.

Eine kurze Checkliste für das nächste Mal

Behalten Sie diese grobe Reihenfolge im Kopf, falls es wieder passiert: prüfen, ob die Schnittstelle aktiv ist, einen blockierten UDP-Port durch Testen in einem anderen Netzwerk ausschließen, Schlüssel und Endpunkt-Adresse auf Aktualität prüfen, PersistentKeepalive hinzufügen, wenn Sie mobile Daten nutzen, und AllowedIPs sowie MTU nur prüfen, wenn die vorherigen Schritte nichts bringen. Die Ursachen ungefähr in dieser Reihenfolge durchzugehen, häufigste und am schnellsten zu prüfende zuerst, führt schneller zu einer Lösung, als bei den obskureren Möglichkeiten zu raten, bevor die einfachen ausgeschlossen sind.

Weiterlesen: WireGuard gegen OpenVPN: Was ist besser? und So richten Sie einen WireGuard-VPN-Server auf Ubuntu Linux ein.