- ADR-0004: Status akzeptiert; real gebaute Architektur v2 dokumentiert
(UniFi bietet kein WG-Site-to-Site -> UDM-Server + CFGMON als Client mit
'Networks Behind Client'), inkl. Messwerten aus dem Negativtest
- AAR Lab-Seite: 5 Befunde, Eingrenzungsmethodik, 5 Lehren (u.a. 'Server'-Auswahl
erfasst nur das Tunnel-Subnetz; Portbedingung gehoert in beide Portfelder)
- README: Uebergabe-Issue-Ausnahme als auslaufend markiert
- shared/lab-netzwerk.md: beide WG-Zugaenge tabellarisch
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Host-Neustart 2026-08-01 ~21:57 CEST. Tunnel, Bootfix (After=docker.service),
Firewall-Regeln und Split-DNS kamen ohne manuellen Eingriff hoch; Handshake
2 s nach Messbeginn. Bootfix und Persistenz damit im Ernstfall verifiziert.
Der Handshake stand am 2026-08-01 ~21:15. Ursache des tagelangen Schweigens
war der in management#2 (Kommentar 399) als bestaetigt uebergebene UDM-Server-
PublicKey, der zu keinem Server auf der UDM gehoert. Nachtrag 2 dokumentiert
Eingrenzungsweg (tcpdump beidseitig, wg show am Geraet), Endzustand und Lehren.
Der Portversatz Fritzbox/UDM war ein realer zweiter Fehler, allein aber nicht
hinreichend.
Der AAR und der Kommentar an management#2 legten nahe, der Tunnel komme nach
dem Reboot von allein wieder, weil wg-quick@lab "enabled" war. Der Neustart am
2026-08-01 hat das widerlegt: der Dienst war ab 19:36 failed, weil wg-quick vor
dockerd startet und die PostUp-Regel an der noch fehlenden Kette DOCKER-USER
scheiterte -- wg-quick raeumte das Interface daraufhin ab.
Nachtrag als Abschnitt 6 ergaenzt, Fundstellen in Abschnitt 1 und Pruefpunkt 5
verweisen darauf. Behebung (systemd-Drop-in After=docker.service plus
idempotentes "iptables -N DOCKER-USER" in lab.conf) ist dort dokumentiert und
auf CFGMON umgesetzt.
Schritte 1-3 ausgefuehrt, Tunnel gestartet und enabled. Kein Handshake --
der Public Key von CFGMON ist noch nicht als UniFi-Client hinterlegt.
Drei Befunde ueber den Auftrag hinaus:
- enp7s0 seit 18:11 DOWN, ausgeloest durch die Hetzner-Range-Umstellung
(NIC neu angehaengt, hc-net-ifup wegen unmet condition uebersprungen).
Zeitstempel belegen: 29 Minuten VOR dem Tunnelstart, kein Zusammenhang.
- ufw ist auf CFGMON inaktiv; das Briefing setzte eine erzwingende
Forward-Policy voraus. Regeln liegen jetzt als iptables-ACCEPT in
PostUp/PreDown der lab.conf statt in ufw.
- sudo ist aus einer Agenten-Session nicht bedienbar (kein TTY); die
Schritte liefen ueber die docker-Gruppe, die root-aequivalent ist.
Die sudo-Passwortabfrage ist damit keine wirksame Grenze -- Entscheidung
darueber liegt bei sorb.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach dem Deploy der CVE-Pipeline (gitops#47) als Verfahren festgehalten. Der
Stand war korrekt und gelintet; der Blocker entstand erst aus der Datenmenge,
gegen die er lief -- eine Alarm-Instanz pro CVE, real 126 CRITICAL und 1222
HIGH. So etwas faellt in keinem Diff auf, nur beim Messen vor dem Deploy.
Neu:
- .gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml -- Uebergabe-Issue mit
Pflichtfeldern Mengengeruest, vollstaendiges Deploy-Kommando, Verifikation
im laufenden Dienst, Aussenwirkung samt Not-Aus, Rollback
- verfahren/deploy-uebergabe.md -- Ablauf und Pruefliste
- verfahren/aar-vorlage.md -- AAR-Vorlage
- verfahren/aar/2026-08-01-cve-pipeline-gitops47.md -- der ausloesende AAR
Abgrenzung im README ergaenzt: hosts/ und shared/ halten offene Punkte,
verfahren/ haelt, wie wir arbeiten. Die Uebergabe-Issues laufen bewusst hier
statt im Projekt-Repo, weil das Verfahren repo-uebergreifend gilt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Thore CimbalandClaude Fable 5