TP16 HA repariert; TP25 5-GHz-Scan + Empfehlung; TP17.2-Stub weg

TP16 -- Ursache war NICHT das erwartete QUIC-Flap: die beiden
macmini-Connectoren standen auf Exited(0), beide finishedAt auf
derselben Sekunde 2026-07-21T13:00:53, bei korrektem
restart=unless-stopped und http2. Also ein docker stop / compose down.
Fix = docker start. Abnahme: alle drei bf-Tunnel je 2 Connectoren /
8 conns, 36 Anfragen ueber 6 FQDNs beider Tunnel mit 530er=0.
- Datierung korrigiert: degradiert seit 07-21, nicht seit 08-16
  (der 08-16 war der Tag der Entdeckung) -- vier Wochen unbemerkt
- Nachweisluecke festgehalten: 1 von 2 Connectoren meldet healthy,
  nur die Connector-ANZAHL zeigt die Degradation -> Check nach TP11
- openclaw-Warnung korrigiert: welcher Tunnel einen Hostname bedient,
  entscheidet das DNS; kein CNAME zeigt auf die vier toten Tunnel,
  n8n zeigt korrekt auf bf-mm. Loeschen bleibt richtig als Hygiene
- Doku-Drift: bf-nas ist live 220c9958, nicht 70d6a4cf
- cf-tunnel-mapping.md Paragraph 15 als As-Built

TP25 -- 5-GHz-Umfeldscan am Manager: je EIN Fremdnetz pro AP, -86 bzw
-89 dBm. Band leer, Bloecke ueberlappungsfrei => beide ueblichen Gruende
fuer 20 MHz treffen nicht zu. Empfehlung: 20/40 behalten; der echte
Ausloeser ist die AP-Zahl (Band A = genau 2x40 MHz, mit zwei APs voll),
dann lautet die Wahl 20 MHz flottenweit gegen DFS akzeptieren.

TP30 -- neues Leak-Ereignis dokumentiert: list_wifi_interfaces gibt alle
Passphrasen im Klartext aus, damit sind fuenf WLAN-PSKs exponiert.
Als Falle aufgenommen. TP17.2-Stub entfernt (Verweise erklaeren den
Merge, ein Wegweiser ist nicht mehr noetig).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/cf-tunnel-mapping.md

@@ -346,3 +346,58 @@ Letzte in §9.2/§8 als „bleibt `.41`" geführte Origin-Klasse (`pve .41.100`,
 - vnet-Route `5546dcb6…` von `bf-pve` auf den Mesh-Tunnel umhängen (Rollback = PATCH zurück; bf-pve bleibt Fallback).
 - Team-Domain gemessen: `emsenhuber.cloudflareaccess.com` → Node-Identität `warp_connector@emsenhuber.cloudflareaccess.com`. Noch kein `warp_connector`-Tunnel im Account.
 - Governance „Config nur via Nautobot" (TP21): CRS326-WG-Zeilen regulär via Golden Config, sobald das Device dort adoptiert ist — die alte ap1-Ausnahme gilt hierfür **nicht**.
+
+## 15. Incident 2026-07-21 → ✅ GEFIXT 2026-08-24 — macmini-Connectoren gestoppt, HA fünf Wochen degradiert
+
+**Symptom (erhoben 2026-08-16, gefixt 2026-08-24):** `bf-nas` und `bf-pve` liefen auf **je einem**
+Connector statt zwei. Kein `530`, kein Round-Robin — reiner **Redundanzverlust**: die Dienste hinter
+diesen Tunneln hingen an einem einzigen cloudflared-Prozess.
+
+**Ursache — nicht das erwartete QUIC-Flap.** Die beiden macmini-Container standen auf
+`Exited (0)`, `finishedAt` **beide auf `2026-07-21T13:00:53`** (gleiche Sekunde, Exit 0,
+`restart=unless-stopped`, `TUNNEL_TRANSPORT_PROTOCOL=http2` korrekt gesetzt). Ein Absturz sieht anders
+aus: gleiche Sekunde + Exit 0 + kein Neustart trotz `unless-stopped` = **ein `docker stop` bzw.
+`compose down` auf genau diese zwei**. Die übrigen macmini-Container liefen die ganze Zeit, der Daemon
+ist seither auch neu gestartet — Docker hat die zwei also als „vom Benutzer gestoppt" geführt.
+⇒ **Die Datierung in TP16 war falsch: degradiert seit 2026-07-21, nicht seit dem 08-16.** Der 08-16 war
+nur der Tag, an dem es *aufgefallen* ist. Zwischen Eintritt und Entdeckung lagen **vier Wochen**.
+
+**Fix:** `docker start cloudflared-bfnas cloudflared-bfpve` auf dem macmini. Sonst nichts —
+Tokens, Transport und Restart-Policy waren korrekt.
+
+**Abnahme (2026-08-24):**
+- CF-API: `bf-mm` / `bf-nas` / `bf-pve` je **2 Connectoren / 8 conns**, alle `healthy`.
+- Connector-Log: `Registered tunnel connection … protocol=http2` (Konvention aus §13 gehalten).
+- **Smoke-Test gegen das Round-Robin-Muster: 6 FQDNs über beide betroffenen Tunnel
+  (`gitea`/`nautobot`/`grafana` = bf-nas, `portainer`/`hass`/`vw` = bf-pve), je 6 Läufe = 36 Anfragen,
+  `530er = 0`.** Das reziproke Design hält: macmini hostet weder NAS- noch pve-Origins, die
+  macvlan-Host-Isolation aus §9 kann dort also nicht zuschlagen.
+
+🔴 **Die eigentliche Lehre ist nicht der Fix, sondern die Nachweislücke.** Ein Tunnel mit einem von
+zwei Connectoren meldet `healthy` — die Degradation ist über den Tunnel-Status **nicht sichtbar**, nur
+über die **Connector-Anzahl**. Genau deshalb blieb sie vier Wochen unbemerkt und wurde beim
+Doku-Aufräumen zufällig gefunden. **Ein HA-Design ohne Zähler auf die Redundanz ist kein HA-Design.**
+⇒ Gehört als Check nach **TP11** (Monitoring): `connectoren < 2` je bf-Tunnel = Alarm.
+
+### Korrektur: die vier toten Alt-Tunnel sind harmloser als notiert
+Stand 2026-08-24, live erhoben: `openclaw`, `coolify`, `johnny2`, `TeilzeitCharlie` sind `down`,
+0 Connectoren. Ihre **Ingress-Configs beanspruchen weiterhin Hostnames** — `openclaw` unter anderem
+`n8n.emsenhuber.net` → `10.40.41.147:5678` (toter VLAN1-Origin), dazu `oc`, `dashboard`, `drawio`;
+`coolify` → `10.40.41.133`; `johnny2` → `jc`; `TeilzeitCharlie` → `charlie`.
+
+🔵 **Aber: kein einziger CNAME zeigt auf einen dieser vier Tunnel.** Alle 23 Tunnel-CNAMEs der Zone
+zeigen auf `bf-mm`/`bf-nas`/`bf-pve`/`fm`/`terpene-db`; **`n8n.emsenhuber.net` zeigt korrekt auf
+`bf-mm`**. ⇒ Die in TP16 notierte Sorge, ein wiederbelebter `openclaw` würde „exakt das alte
+Round-Robin-Muster auf diesem Hostname" erzeugen, ist **so nicht richtig**: **welcher Tunnel einen
+Hostname bedient, entscheidet das DNS**, nicht die Ingress-Config. Ein hochkommender `openclaw` wäre
+inert, solange niemand `cloudflared tunnel route dns` dafür ausführt (was den CNAME umschreiben
+*würde* — das ist der reale, aber aktive Angriffspfad). Das Round-Robin aus §9 war ein Problem
+**mehrerer Connectoren auf EINEM Tunnel**, nicht mehrerer Tunnel auf einem Namen.
+⇒ **Löschen bleibt richtig — als Hygiene und um die `route dns`-Falle zu entfernen, nicht als
+Störungsbehebung.** Weiterhin user-gated (Löschen ist nicht umkehrbar).
+
+📌 **Doku-Drift mitkorrigiert:** §10 führt `bf-nas` als `70d6a4cf`; live ist die Tunnel-ID
+**`220c9958`** (Tunnel am 2026-07-12 neu angelegt, s. §11). §10 gilt sonst unverändert.
+
+ℹ️ **Nicht Teil des BF-HA-Designs** (und daher kein Defekt, obwohl sie 1 Connector haben):
+`fm.emsenhuber.net` (Standort FM) und `terpene-db` (eigenes Projekt).