WireGuard zeigt keinen letzten Handshake: was zuerst zu prüfen ist

Ein leerer Handshake kann schlicht bedeuten, dass nichts gesendet wurde. Lösen Sie ein erlaubtes Paket aus und prüfen Sie dann die Route, das Schlüsselpaar und den äußeren UDP-Pfad.

Ein leeres Feld für den letzten Handshake bedeutet meist, dass die Schnittstelle seit ihrem Hochfahren keinen Handshake abgeschlossen hat, was weniger über die Konfiguration aussagt, als es scheint. WireGuard bleibt still, bis ein Paket die Schnittstelle verlassen muss, daher meldet ein untätiger Peer ohne Sendewunsch genau das. Klären Sie, ob überhaupt etwas angeboten wurde, bevor Sie die Schlüssel untersuchen.

Der Test ist ein erlaubtes Paket zu einem Ziel, das der Peer tragen soll. Alles andere auf diesem Statusbildschirm beschreibt Absicht statt Aktivität.

Eine untätige Schnittstelle hat nichts zu melden

WireGuard führt Handshakes träge aus: Das erste Paket, das den Tunnel braucht, löst den Austausch aus, und die Schnittstelle bleibt bis dahin still. Ein Peer, der konfiguriert und nie genutzt wurde, zeigt einen leeren Handshake, null empfangene Bytes und eine wachsende Lücke seit dem letzten. Dieser Zustand ist für einen untätigen Client gesund und nur dann alarmierend, wenn Sie erwartet haben, dass bereits Verkehr geflossen ist. Prüfen Sie auch die Übertragungszähler, denn sie trennen nichts-gesendet von versucht-und-gescheitert.

Stehen die Zähler auf beiden Seiten bei null, liegt das Problem oberhalb des Tunnels. Nichts erreichte die Schnittstelle, um etwas auszulösen.

Lösen Sie Verkehr aus, den der Peer tragen darf

Wählen Sie eine Adresse innerhalb der erlaubten Präfixe des Peers auf dem lokalen Rechner und bestätigen Sie, dass die Routingtabelle sie über die Schnittstelle senden würde. Ein Ziel außerhalb dieser Präfixe erzeugt eine gewöhnliche geroutete Anfrage ganz ohne WireGuard-Beteiligung. Verwenden Sie einen Dienst, der schnell antwortet, etwa einen Ping oder eine kurze TCP-Verbindung, damit der Versuch einen sichtbaren Anfang und ein Ende hat. Lesen Sie dann die Handshake-Zeile erneut, statt auf den Bildschirm zu starren und zu warten.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

Die Routenabfrage ist wichtiger als der Ping. Nennt sie die physische Schnittstelle, ist das Paket nie in den Tunnel gelangt, und der leere Handshake ist eine Routing-Antwort, keine kryptografische. Reparieren Sie die Route, bevor Sie den Peer debuggen.

Vergleichen Sie Schlüsselpaar und Endpunkt

Sobald Verkehr wirklich angeboten wird, ist die Identität die nächste Prüfung. Der lokale private Schlüssel muss zum öffentlichen Schlüssel passen, den die Gegenseite autorisiert, der konfigurierte entfernte öffentliche Schlüssel muss den gemeinten Peer identifizieren, und ein vorab geteilter Schlüssel muss auf beiden Seiten übereinstimmen. Ein einziges abweichendes Zeichen in einem base64-Schlüssel erzeugt einen Peer, der konfiguriert aussieht und nie einen Austausch abschließt. Vergleichen Sie mit dem Bereitstellungsdatensatz, statt Schlüssel neu zu erzeugen, denn ein neuer Schlüssel entwertet jeden Peer, der dem alten vertraut hat.

Der Endpunkt braucht dieselbe Prüfung: Hostname, Adresse, UDP-Port und die Familie, über die er erreicht wird. Eine veraltete Adresse oder der falsche Port erzeugt Schweigen statt einer Meldung.

Behalten Sie den äußeren UDP-Pfad im Blick

Der Handshake reist als UDP zum Endpunkt, also muss der äußere Pfad ihn tragen. Die folgenden Befehle prüfen, ob ein Listener existiert, ob der lokale Stack das Datagramm abgeschickt hat und welcher Endpunkt konfiguriert ist. Führen Sie die Aufzeichnung während des Auslösens von Verkehr aus, nicht davor.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

Eine Aufzeichnung, die die Initiierung ohne Antwort zeigt, weist aus der Maschine hinaus, weil die Gegenseite entweder nicht lauscht, gefiltert ist oder falsch adressiert wurde. Eine Aufzeichnung, die gar nichts zeigt, bedeutet, dass das Paket nie hinausging, was Sie zur Route und zu einer etwaigen Socket-Marke zurückführt. Wenn Sie beide Seiten administrieren, korrelieren Sie den Versuch per Zeitstempel mit einer engen Aufzeichnung auf dem Server statt mit einer allgemeinen. Ein TCP-Porttest beweist hier nichts, denn das Protokoll ist reines UDP.

Sobald ein Handshake erscheint, testen Sie eine Anwendung über den Tunnel, denn ein abgeschlossener Austausch belegt Identität und Erreichbarkeit, nicht nutzbaren Durchsatz oder korrektes DNS. Bewahren Sie die Statusausgabe vor und nach der Änderung auf, und die Differenz wird Ihr Beweis.

Ähnliche Artikel