Files
axion1337.chat-gitops/host-config/wireguard-lab
Thore CimbalandClaude Opus 4.8 60aaf0e068 feat(host-config): give the lab WireGuard tunnel a repo home
These files existed only on CFGMON, so rebuilding the host meant reconstructing
them from AAR prose (management #0027, W4 point 4). Follows the maintenance-notify
pattern: .example for anything carrying a secret, real files for the rest.

The private key stays out of the repo by design — it lives on the host and nowhere
else, and is reissued from the UDM if lost. The template carries the structural
values from ADR-0004 and the zone set from ADR-0017, with the reasoning inline:
why the direction is reversed, why AllowedIPs is narrow, why the port is 51841,
and why ping is the wrong reachability check.

Both files are derived from the ADRs rather than copied off the host, which the
README says plainly along with the redacted dump command to reconcile them.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-15 12:00:00 +00:00
..

wireguard-lab — Site-to-Site-Tunnel CFGMON ↔ Lab

Host-Konfiguration für den WireGuard-Tunnel aus ADR-0004 (Zonen: ADR-0017).

Läuft auf dem Host, nicht als Pod — deshalb hier unter host-config/ und nicht als Flux-Manifest (siehe die Erklärung in der Repo-CLAUDE.md). Angelegt, weil diese Dateien bisher nur auf dem Host existierten: ein Neuaufbau von CFGMON hätte sie aus AAR-Prosa rekonstruieren müssen (management #0027, W4 Punkt 4).

Was wohin gehört

Datei hier Ziel auf dem Host Secret?
lab.conf.example /etc/wireguard/lab.conf (Mode 0600, root) jaPrivateKey
10-after-docker.conf /etc/systemd/system/wg-quick@lab.service.d/ nein
— (liegt in ci/lab-ca-chain.crt) /usr/local/share/ca-certificates/axionlabs-root.crt nein

Der Private Key steht bewusst nicht im Repo. Er wird auf dem Host eingesetzt und ist nirgends sonst hinterlegt — geht er verloren, wird auf der UDM ein neues Keypair für den Client „Hetzner" erzeugt und hier eingetragen. Gleiches Muster wie maintenance-notify (config.example / msmtprc.template).

Einrichten

# 1. Konfiguration ablegen und Key eintragen
sudo install -m 0600 -o root -g root lab.conf.example /etc/wireguard/lab.conf
sudo vi /etc/wireguard/lab.conf          # PrivateKey + PublicKey eintragen

# 2. Start-Reihenfolge: der Tunnel muss nach Docker hoch (sonst fehlen die iptables-Ketten)
sudo mkdir -p /etc/systemd/system/wg-quick@lab.service.d
sudo cp 10-after-docker.conf /etc/systemd/system/wg-quick@lab.service.d/
sudo systemctl daemon-reload

# 3. Root-CA in den Truststore (Zertifikat liegt im Repo unter ci/)
sudo cp ../../ci/lab-ca-chain.crt /usr/local/share/ca-certificates/axionlabs-root.crt
sudo update-ca-certificates

# 4. Starten
sudo systemctl enable --now wg-quick@lab

Prüfen

sudo wg show                                   # Handshake jünger als ~2 min?
resolvectl domain                              # gerouteten Zonen (siehe ADR-0017)
curl -sI https://git.lab/users/sign_in | head -1   # 302 = Tunnel + DNS + CA stimmen

⚠️ Nicht mit ping prüfen. Durch den Tunnel sind nur HTTPS (443 auf 10.58.73.17) und DNS (53 auf 10.58.73.1) offen; ICMP ist gesperrt. Ein fehlgeschlagener Ping bedeutet hier nicht, dass etwas kaputt ist — das hat schon eine Session in die falsche Richtung geschickt.

Noch aus dem Live-Stand zu ergänzen

Diese Dateien sind aus ADR-0004/ADR-0017 abgeleitet, nicht vom laufenden Host kopiert (von außerhalb ist /etc/wireguard/ nicht lesbar). Vor dem ersten Einsatz als Vorlage einmal gegen CFGMON abgleichen:

# auf CFGMON, Private Key geschwärzt:
sudo sed 's/^PrivateKey.*/PrivateKey = <REDACTED>/' /etc/wireguard/lab.conf
cat /etc/systemd/system/wg-quick@lab.service.d/10-after-docker.conf

Abweichungen hier einpflegen; danach diesen Abschnitt entfernen.