WireGuard-Standardroute-Schleife: den Endpunktpfad finden

Die Schnittstelle kommt hoch, die Peer-Konfiguration sieht korrekt aus, und kein Handshake wird jemals abgeschlossen. Das Hinzufügen einer Standardroute durch den Tunnel ist der Schritt, der dies oft verursacht: Dieselbe Routentabelle entscheidet nun, wohin die eigenen verschlüsselten Pakete des Tunnels gehen sollen, und die Antwort führt zurück in den Tunnel. Nichts kann das äußere Paket tragen, das das innere tragen würde, also bleibt die Verbindung stehen, bevor sie beginnt. Die Reparatur ist klein, aber sie hat eine Reihenfolge, und die Überprüfung ist wichtiger als die Änderung.

Bestätigen Sie die Schleife, bevor Sie eine Route ändern

Lesen Sie die aktuelle Endpunktadresse des Peers und fragen Sie dann den Routing-Stack, wohin ein Paket an diese Adresse gehen würde. Wenn die Antwort die Tunnelschnittstelle nennt, ist die Schleife bestätigt und keine weitere Diagnose nötig. Speichern Sie beide Ausgaben im Änderungsprotokoll, bevor Sie etwas anfassen, denn der Vergleich nach der Reparatur sind dieselben zwei Befehle. Eine Schleife ist nicht subtil, sobald man sie sieht; die Schwierigkeit ist, dass die Schnittstelle gesund aussieht, während es passiert.

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

Nehmen Sie die Policy-Regeln in diese Aufzeichnung auf. Eine Standardroute, die in der Haupttabelle korrekt aussieht, kann immer noch gegen eine Regel verlieren, die für markierten oder unmarkierten Verkehr eine andere Tabelle wählt, und die Schleife erscheint mit einer Routentabelle wieder, die in Ordnung aussieht.

Lesen Sie den Endpunktpfad, nicht den Tunnelpfad

Der Endpunktpfad ist die Route, die die verschlüsselten Datagramme zur öffentlichen Adresse des Peers nehmen, und er muss außerhalb des Tunnels bleiben, solange der Tunnel existiert. Der Tunnelpfad ist alles, was der Peer tragen darf. Diese beiden Pfade teilen sich eine Routentabelle, und genau deshalb kann ein einziger Catch-all-Eintrag sie ineinander kollabieren lassen. Den Tunnelverkehr und den eigenen Transport des Tunnels zu trennen, ist das ganze Designproblem, und jedes unterstützte Werkzeug löst es etwas anders.

Prüfen Sie beide Adressfamilien getrennt, wenn die Schnittstelle beide trägt. Eine funktionierende IPv4-Ausnahme sagt nichts darüber aus, ob der IPv6-Endpunkt noch erreichbar ist, und eine gemischte Konfiguration kann zu funktionieren scheinen, bis die IPv6-Adresse des Peers ausgewählt wird.

Stellen Sie den Endpunktpfad mit einer zusammenhängenden Änderung wieder her

Es gibt zwei unterstützte Ansätze, und sie zu mischen ist der Weg, auf dem eine funktionierende Einrichtung unvorhersehbar wird. Der erste ist, das Werkzeug, dem die Schnittstelle gehört, den gesamten Tunnel verwalten zu lassen: wg-quick hat eine eigene Behandlung für einen Standard-Peer-Bereich, die eine separate Tabelle, Policy-Regeln und eine Socket-Marke installiert, was die äußeren Pakete aus dem Tunnel heraushält. Lassen Sie diese Mechanik intakt, statt die Hälfte davon von Hand nachzubauen. Eine Einrichtung, die eine manuell hinzugefügte Standardroute mit einem Manager mischt, der bereits Marken und Regeln installiert, neigt nach dem erneuten Verbinden zum Scheitern, wenn der Manager Zustand überschreibt, den der manuelle Schritt vorausgesetzt hat.

Der zweite ist ein manuelles Design, bei dem der Endpunkt eine explizite Host-Route über das physische Gateway erhält. Fügen Sie diese Route vor der Standardroute hinzu, ersetzen Sie statt anzuhängen, damit ein veralteter Eintrag nicht gewinnen kann, und bestätigen Sie danach die Suche.

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

Überprüfen, dann einen Weg zurück behalten

Ein fortschreitender Handshake-Zeitstempel ist der erste Beweis, und er ist stärker als eine Schnittstelle, die bloß existiert. Lassen Sie einen Anwendungstest durch den Tunnel folgen, bringen Sie dann die Schnittstelle absichtlich herunter und bestätigen Sie, dass der Host in einen nutzbaren Zustand zurückkehrt, statt eine Standardroute zu behalten, die ins Leere zeigt. Diesen letzten Schritt überspringen die Leute, und er entscheidet, ob ein Neustart die Maschine ohne Verbindung zurücklässt.

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

Speichern Sie vor all dem den aktuellen Routing-Zustand und stellen Sie sicher, dass es einen Zugangsweg gibt, der nicht vom Tunnel abhängt: eine Konsole, eine Out-of-Band-Management-Adresse oder ein Kollege vor Ort. Eine entfernte Maschine, die ihre Standardroute verliert, ist über die Verbindung, die sie gerade verloren hat, nicht wiederherstellbar, und der sicherste Runbook-Schritt ist der, der vor dem ersten Befehl erfolgt.