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>
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) |
ja — PrivateKey |
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.