Handshake läuft, Adresse weg: drei WireGuard-Zustände

WireGuard kann gleichzeitig einen frischen Handshake und keine Adresse haben, und dieser Zustand ist stimmig statt widersprüchlich. Der Handshake ist ein Peer-Ereignis, die Adresse gehört zur Schnittstelle, und die Route entscheidet, über welchen Uplink ein Paket hinausgeht. Drei Schichten, drei Eigentümer, und jede kann ausfallen, während die anderen zwei gesund aussehen.

Sie als einen Status zu lesen, verwandelt eine Zwei-Minuten-Diagnose in einen ganzen Nachmittag voller Dienstneustarts.

Ein Handshake ist ein Peer-Ereignis, kein Adressierungsereignis

Der Handshake von WireGuard beweist, dass der konfigurierte Peer mit einem gültigen Schlüssel geantwortet hat und dass die Sitzungsschlüssel aktuell sind. Über die lokale Adresse der Schnittstelle sagt er nichts, und nichts darüber, ob eine Route dorthin zeigt. Ein Helfer oder Netzwerkmanager weist die Adresse zu, während die Protokollkonfiguration nur Peers und Schlüssel benennt. Beides zu verwechseln ist der Grund, warum ein gesunder Handshake als funktionierender Tunnel gelesen wird.

Deshalb kann wg show einen sekundenalten Handshake auf einer Schnittstelle melden, die kein einziges Paket von einer Anwendung annehmen kann.

Ein Manager, der die Schnittstelle neu erzeugt, kann die Adresse verwerfen, ohne die Peer-Konfiguration anzufassen, und der nächste Handshake gelingt sofort, weil sich die Schlüssel nie geändert haben. Die Logzeile über einen erfolgreichen Handshake ist korrekt und für den Fehler irrelevant.

Die Schnittstellenadresse hat ihren eigenen Eigentümer

Eine Adresse auf dem Tunnelgerät kann aus der Address Zeile eines Helfers kommen, von einem DHCP-Client, der auf der Schnittstelle läuft, oder von einem Verwaltungsdaemon, der sie beim Verbinden erzeugt. Was auch immer es ist, diese Komponente besitzt die Adresse und stellt sie nach ihrer eigenen Logik wieder her oder nicht. Die Adresse zu lesen, ohne ihren Eigentümer zu benennen, lässt Sie ohne Erklärung, warum sie verschwand.

Zwei Eigentümer auf einer Schnittstelle sind der klassische Fehler. Ein Helfer und ein Desktop-Netzwerkmanager über demselben Gerät zu starten erzeugt ein Rennen, bei dem der eine entfernt, was der andere gerade konfiguriert hat, und der Endpunkt antwortet durchgehend weiter.

Wählen Sie einen Eigentümer und lassen Sie das andere Werkzeug beobachten statt verwalten. Diese Entscheidung gehört aufgeschrieben, weil das Symptom Wochen später auftaucht und wie ein zufälliger Adressverlust aussieht.

Eine Route wählt einen Uplink, die Schnittstelle nicht

Eine innere Route, die auf wg0 zeigt, entscheidet, dass der Verkehr in den Tunnel geht. Eine separate Entscheidung schickt die verschlüsselten äußeren Pakete zum Peer, und auf einem Host mit mehreren Uplinks kommt diese Entscheidung aus der Weiterleitungstabelle und den Policy-Regeln. Ein Wi-Fi-Roaming kann den äußeren Pfad ändern, ohne die innere Adresse anzufassen.

Ein funktionierender Tunnel und ein nicht erreichbarer Peer sind also vereinbare Zustände, und ebenso ein korrekter Peer und eine kaputte innere Route. Die drei Beobachtungen müssen zusammen, im selben Moment genommen werden, sonst ist der Vergleich sinnlos.

Vergleichen Sie die drei Zustände in einem Durchgang

Drei reine Lesebefehle beantworten die drei Fragen in der Reihenfolge, die den Fehler am schnellsten isoliert. Führen Sie sie aus, ohne dazwischen etwas zu ändern.

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

Der erste zeigt, ob die Schnittstelle überhaupt eine Adresse hat, und der zweite, welches Gerät ein bestimmtes Ziel gerade jetzt benutzen würde. Der dritte meldet die Zeit des letzten Handshakes und die Byte-Zähler, und er ist der einzige der drei, der den Peer statt des lokalen Hosts beschreibt.

Lesen Sie die Zähler ebenso wie den Zeitstempel. Ein Handshake, der sich ständig erneuert, während der Transfer flach bleibt, bedeutet, dass der Peer antwortet, aber nichts Nützliches durchkommt, was auf Routing oder eine ACL statt auf Schlüssel hindeutet. Ein Zeitstempel, der stehen bleibt, während eine Adresse vorhanden ist, deutet stattdessen stromaufwärts. Beide Lesarten stammen aus derselben Ausgabezeile, und keine ist sichtbar, wenn Sie nur prüfen, ob ein Handshake existiert.

Korrigieren Sie den konkreten Zustand, der falsch ist, und testen Sie dann die Anwendung statt den Tunnel. Ein frischer Handshake ist Peer-Beweis, und Beweis über den Peer ist kein Beweis dafür, dass die nächste Anfrage Ihres Browsers eine Adresse, eine Route und einen funktionierenden Uplink findet. Das wg-quick-Handbuch sagt ausdrücklich, was davon der Helfer einrichtet und was zum Protokoll gehört.