Schnittstelle ist oben, aber wg-quick ist gescheitert: was nun

Die Unit ist rot, die Schnittstelle existiert, und der Tunnel funktioniert weitgehend — die verwirrendste Kombination, die es gibt. Die Einrichtung ist eine Abfolge: Zuerst wird die Schnittstelle erzeugt, dann folgen Adressen, Routen, Resolver-Einstellungen und etwaige Hook-Befehle. Ein Fehler im vierten Schritt lässt die ersten drei stehen, der Schnittstellenname belegt also, dass der Start begann, nicht dass er endete. Eine einzige zusätzliche Angabe hätte die Verwirrung erspart: der Schritt, der fehlschlug.

Teilzustand ist der normale Fehler

Dieses Verhalten sollte man erwarten, statt es als Beschädigung zu behandeln. Die Schnittstelle ist der billigste Teil der Einrichtung und der am leichtesten zurückgelassene, und sie ist auch der Teil, der die Maschine halb funktionierend aussehen lässt.

Was noch nicht existiert, ist alles, was nach dem fehlschlagenden Schritt kam. Wenn der Fehler in der Resolver-Phase lag, sind Adressen und Routen vorhanden und DNS nicht. Handelte es sich um eine Route, hat der Tunnel eine Adresse und keinen Weg hindurch.

Die Folge ist eine Maschine, die manche Prüfungen beantwortet und andere nicht, weshalb Leute schließen, der Dienst flackere, obwohl er nie erfolgreich gestartet ist. Ein Dienst, der nie fertig wurde, kann nicht flackern. Er kann nur immer wieder aus demselben Grund scheitern.

Finden Sie den ersten fehlschlagenden Schritt

Lesen Sie das Journal der Unit statt nur den aktuellen Status, und lesen Sie es vom Anfang des gescheiterten Laufs. Die letzte Zeile nennt den Exit-Code; der erste Fehler nennt, was zu reparieren ist.

Diese Befehle geben den Zustand der Unit, das Boot-Journal für diese Unit und den Live-Zustand des Tunnels aus:

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0

Ein Resolver-Fehler, eine bereits vorhandene Route, ein Hook, der mit einem Wert ungleich null endete, und ein Fehler beim Einlesen der Konfiguration erscheinen alle in diesem Fenster, und jeder nennt seine eigene Komponente. Wer nur aus dem Zustand der Schnittstelle rät, ignoriert all diese Informationen.

Drei Bedingungen, die die Reparatur entscheiden

Entscheiden Sie, ob Sie aufräumen, an Ort und Stelle reparieren oder die Unit aus dem Startpfad entfernen, und entscheiden Sie es, bevor Sie etwas tippen.

Ist die Schnittstelle defekt, die Konfiguration aber richtig, räumen Sie auf und beginnen Sie neu. Ist die Konfiguration falsch, korrigieren Sie sie und räumen Sie trotzdem zuerst auf, denn einen zweiten Manager über einem Teilzustand zu starten erzeugt zwei Eigentümer für eine Schnittstelle. Ist der Fehler eine fehlende Systemkomponente wie ein Resolver-Helfer, den die Maschine nicht hat, installieren oder entfernen Sie die Abhängigkeit bewusst, statt die Unit zu bearbeiten, bis sie aufhört zu klagen.

Diese drei Fälle decken das meiste ab, was wie eine rätselhafte rote Unit aussieht. Die entscheidende Frage ist, ob derselbe Fehler auf einer Maschine mit sauberem Zustand aufträte, und die Antwort kommt meist aus der ersten Fehlerzeile.

Räumen Sie auf, bevor Sie es erneut versuchen

Ein neuer Versuch über bestehendem Zustand kann aus einem neuen Grund scheitern und den ursprünglichen verbergen. Bringen Sie die Schnittstelle mit demselben Werkzeug herunter, das sie erzeugt hat, und bestätigen Sie dann, dass nichts übrig ist.

Löschen Sie keine unbeteiligten Schnittstellen und setzen Sie nicht den Netzwerk-Stack des Hosts zurück. Beides sind große Eingriffe, um ein kleines Objekt zu reparieren, und sie machen aus einem gescheiterten Tunnel eine Maschine, deren andere Verbindungen neu aufgebaut werden müssen. Der richtige Umfang ist eine Schnittstelle und die Unit, die sie besitzt. Alles Weitere braucht einen Grund, der vorher aufgeschrieben wird.

Beweisen Sie den Tunnel, nicht die Unit

Eine grüne Unit bedeutet, dass die Startsequenz mit null beendet wurde. Sie bedeutet nicht, dass ein Paket die andere Seite erreicht hat, und nicht, dass der Resolver so gesetzt wurde, wie Sie es beabsichtigt hatten.

Senden Sie eine Anfrage durch den Tunnel und lesen Sie den Zustand, der sie erzeugt hat:

systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.net

Ein Handshake ohne Antwort sagt Ihnen immer noch, dass der Tunnel entstanden ist und die Gegenseite still ist, was ein anderes Problem ist als eine Unit, die nie startete. Halten Sie Unit-Zustand, Handshake und Anfrageergebnis in einem Datensatz fest, denn sie scheitern unabhängig voneinander, und nur die Kombination beschreibt das System.