WireGuard-Tunnel prüfen¶

Ungeprüft

Diese Anleitung ist noch nicht durchgespielt worden; Befehle, Bezeichnungen und erwartete Ausgaben können abweichen. Was noch zu prüfen ist, steht in todo/doku.md.

Ziel¶

Der WireGuard-Tunnel zwischen werner und dem Gateway im Maschinendorf steht wieder, und werner erreicht containerhost.

Voraussetzungen¶

SSH-Zugang zu werner (Arbeitsrechner einrichten)
gelesen: Netzwerk, vor allem WireGuard-Tunnel

Typische Anzeichen: Das Backup meldet connection refused oder timeout zum rest-server (Backup-Meldung von healthchecks.io), oder im Monitoring fehlen alle Messwerte von werner.

Hier wird nur die Seite von werner geprüft. Das Gateway steht nicht im Repo und wird hier nicht betreut; liegt der Fehler dort, hilft nur jemand mit Zugang zum Gateway (Signal).

Alle Befehle laufen auf werner, nach ssh werner.garage-lab.de.

Schritte¶

1. Verbindung prüfen¶

Bash
ping -c 3 vm-containerhost.garage-lab.net

Erwartet: drei Antworten (3 received). Dann steht der Tunnel, und der Fehler liegt woanders, etwa am Container resticserver auf containerhost (Container-Status und Logs ansehen).

Ohne Antwort oder mit Name or service not known weiter mit Schritt 2; den Namen löst ein DNS-Server auf, den werner nur durch den Tunnel erreicht.

2. Zustand des Tunnels ansehen¶

Bash
nmcli connection show --active | grep wg0
wg show wg0

Erwartet: nmcli listet die Verbindung wg0 als aktiv; wg show zeigt einen peer mit endpoint, latest handshake und transfer.

Was du siehst	Bedeutung	Weiter
`latest handshake` vor höchstens zwei, drei Minuten	Der Tunnel steht	zurück zu Schritt 1; ist er trotzdem stumm, liegt es am Gateway
`latest handshake` vor längerer Zeit oder fehlt ganz	Das Gateway antwortet nicht	Schritt 3
`wg0` fehlt in `nmcli`, `wg show` meldet `No such device`	Die Verbindung ist nicht aktiv	Schritt 4

3. Adresse des Gateways vergleichen¶

Das Gateway ist über einen DynDNS-Namen erreichbar, dessen Adresse sich ändern kann:

Bash
dig +short maschinendorf.resolve.bar
wg show wg0 endpoints

Erwartet: dieselbe IP-Adresse in beiden Ausgaben. Unterscheiden sie sich, hat sich die Adresse des Gateways geändert, und werner verbindet sich noch mit der alten; weiter mit Schritt 4. Sind sie gleich, ist das Gateway selbst oder der Internetanschluss im Maschinendorf gestört; frag in Signal nach.

4. Verbindung neu aufbauen¶

Bash
nmcli connection down wg0
nmcli connection up wg0

Erwartet: Connection successfully deactivated und Connection successfully activated. Das ändert keine Konfiguration; die Verbindung löst den Namen des Gateways dabei neu auf.

Warte eine halbe Minute und sieh mit wg show wg0 nach, ob ein neuer latest handshake da ist.

Prüfen¶

wg show wg0 zeigt latest handshake vor wenigen Sekunden und wachsende Werte bei transfer.
ping -c 3 vm-containerhost.garage-lab.net bekommt drei Antworten.
Das nächste Backup läuft durch, oder du startest es von Hand wie in Backup-Meldung von healthchecks.io, Schritt 5.

Wenn etwas schiefgeht¶

nmcli connection up wg0 meldet unknown connection 'wg0': Die Verbindung ist auf werner nicht eingerichtet; siehe WireGuard-Tunnel einrichten.
Handshake klappt, aber ping auf containerhost nicht: Prüf, ob wg0 in der firewalld-Zone trusted steht (firewall-cmd --zone=trusted --list-interfaces); sonst liegt es an den Regeln auf dem Gateway.
Kein Handshake, obwohl die Adressen stimmen: Ist der WireGuard-Port in der Firewall bei Netcup offen (Netcup)? Dann liegt es am Gateway; frag in Signal nach.
Allgemeines: WireGuard: Quick Start und NetworkManager: nmcli