Privater Schlüssel hier, öffentlicher Schlüssel dort: WireGuard-Schlüssel
Der private Schlüssel bleibt auf dem Gerät; der Peer-Eintrag enthält den öffentlichen Schlüssel der Gegenseite. Geben Sie nur die öffentliche Hälfte weiter, und jedes Gerät bekommt eine eigene Identität.
Die meisten selbst gebauten WireGuard-Fehler laufen darauf hinaus, welcher Schlüssel wohin gehört. Der Interface-Abschnitt trägt den privaten Schlüssel des Geräts, das Sie konfigurieren, während ein Peer-Abschnitt den öffentlichen Schlüssel der Maschine am anderen Ende trägt. Wer diese Hälften vertauscht oder die falsche einfügt, bekommt einen Handshake, der nie fertig wird, und ein Log, das nie einen Schlüssel nennt. Arbeiten Sie die vier Prüfungen unten der Reihe nach ab, bevor Sie AllowedIPs oder DNS anfassen.
Zwei Schlüssel, zwei Richtungen
Ein privater Schlüssel gehört genau zu einem Gerät und bleibt im Interface-Abschnitt dieses Geräts. Seine öffentliche Hälfte braucht jeder andere Peer, um das Gerät zu erkennen, und das Werkzeug leitet sie ab, statt sie zu erfinden. Auf dem Server erscheint der öffentliche Schlüssel Ihres Geräts als Peer-Eintrag; auf Ihrem Gerät nimmt der öffentliche Schlüssel des Servers diese Rolle ein. Liest man eine Konfiguration laut in diesen Begriffen vor, fallen die meisten Verwechslungen auf, bevor sie einen Handshake erreichen.
Der Befehl wg zeigt an, was die lokale Schnittstelle tatsächlich verwendet, einschließlich beider öffentlicher Schlüssel. Damit ist er der schnellste Weg, einen Konfigurationsfehler von einem Verbindungsproblem zu trennen:
wg show
wg show interfacesDie erste Ausgabe listet jeden Peer mit seinem öffentlichen Schlüssel, dem zuletzt genutzten Endpunkt und dem Alter seines letzten Handshakes. Ein Handshake-Alter von nie auf der einen und ein frisches auf der anderen Seite deutet auf einen Schlüssel hin, den nur ein Ende akzeptiert hat. Der zweite Befehl nennt die Schnittstellen, die Sie weiter untersuchen können.
Was man teilt und was niemals
Ein öffentlicher Schlüssel ist zum Weitergeben gedacht, obwohl er weiterhin eine Gerätebeziehung kennzeichnet, deshalb ist es etwas anderes, ihn dem fragenden Administrator zu schicken, als ihn zu veröffentlichen. Ein privater Schlüssel verlässt das Gerät, das ihn erzeugt hat, nie. Ein exportiertes Profil oder ein QR-Code enthält die gesamte Konfiguration samt diesem privaten Schlüssel, also ist beides nicht sicher weiterzugeben, und den Text in einem Bild zu verstecken ändert daran nichts. Vorab geteilte Schlüssel sind optional und ebenso geheim, und beide Enden müssen denselben Wert tragen, sonst endet der Handshake an dieser Stelle.
Eine weitere Unterscheidung sollte man klar sagen: Ein Endpunkt ist eine Adresse und ein Port, niemals ein Schlüssel. Wer einen öffentlichen Schlüssel ins Endpunktfeld oder eine Adresse in ein Schlüsselfeld einfügt, erhält ein Profil, das sich parsen lässt und dann nichts tut. Das Werkzeug fängt das nicht ab, weil beide Felder nur Zeichenketten sind. Der WireGuard-Schnellstart zeigt die Erzeugen-und-Ableiten-Kette in einer Zeile.
Ein Gerät, ein Peer-Eintrag
Wo der Dienst es zulässt, sollte jedes Gerät seine eigene Peer-Identität tragen. Das komplette Profil eines Laptops auf ein Telefon zu kopieren, verwischt, welches Gerät diese Identität auf dem Server hält, und macht das Zurückziehen eines einzelnen verlorenen Telefons schwieriger. Wenn ein privater Schlüssel durchsickert, entfernen Sie die alte Peer-Berechtigung auf dem Server und beschaffen Sie Ersatz. Die lokale Datei zu löschen entfernt den Eintrag auf dem Server nicht, und ein neuer Client-Schlüssel hilft niemandem, bis der Server dessen öffentliche Hälfte kennt.
Halten Sie die Zuordnung von Gerät zu öffentlichem Schlüssel neben der Adressliste. Diese Liste macht aus einem Widerruf eine Aufgabe von zwei Minuten statt eines ganzen Nachmittags.
Was nach dem Handshake noch scheitert
Schlüsselpaare identifizieren Peers; sie entscheiden kein Netzwerkverhalten. AllowedIPs ordnet Adressbereiche einem Peer zu, und die Routen darum herum verwaltet der Client oder das Einrichtungswerkzeug. Das Symptom sagt meistens, welche Schicht als Nächstes zu öffnen ist:
| What you see | Which key problem it usually means | Where to look first |
|---|---|---|
| Handshake age stays at never on both ends | Peer public key missing, or an endpoint pointing at nothing | wg show, then the endpoint value |
| Handshake completes on one side only | The two ends hold different public keys for each other | wg show on both hosts |
| Handshake works, then no traffic | AllowedIPs or routes rather than keys | wg show and the route table |
| Worked until a key was regenerated | The peer entry still holds the old public key | Compare both public keys, then update the peer |
DNS kann fehlschlagen, nachdem sich beide Peers korrekt authentifiziert haben, und eine Anwendung kann fehlschlagen, während der Tunnel selbst gesund ist, ein funktionierender Handshake ist also nicht das Ende der Diagnose. Schlüssel sagen außerdem nichts über die Protokollierungspraxis eines Betreibers oder darüber, ob eine Website Ihr Konto erkennt, und diese Fragen gehören woanders hin. Gehen Sie zu den Netzwerkschichten über, sobald die vier Prüfungen bestehen, denn ein fehlender Schlüssel ist kein getarntes Routingproblem.