TP31: Caddy laeuft (17/17 Zertifikate); grafana als tot entlarvt

Caddy in LXC 130 ist produktiv: 17 von 17 Zertifikaten per DNS-01 von
Let's Encrypt, Dienst active+enabled, Proxy gegen Host-Header verifiziert
(nautobot 302, gitea 200, pve 200, portainer 200). deploy.sh laeuft
End-to-End; Token per Fingerprint gegengeprueft -- eigenes Zone:DNS:Edit,
nicht das account-weite.

🔴 Fund beim Durchtesten: grafana war seit Langem tot und Cloudflare
Access hat es maskiert. LXC 104 stopped, konfigurativ noch auf VLAN1
(10.40.41.109), waehrend die Ingress-Zeile auf 10.40.20.109 zeigte -- eine
Adresse die es fuer Grafana nie gab. Der FQDN lieferte trotzdem 302, weil
das der Access-Login war. Exakt die Falle aus TP16.3 Paragraph 8, diesmal
in freier Wildbahn: ein toter Dienst sieht hinter Access monatelang
gesund aus.
=> Caddy-Zeile raus (16 Sites), LXC 104 zerstoert, aus dem Backup-Job.
Die 14 PBS-Snapshots bleiben bewusst stehen -- einzige Kopie etwaiger
Dashboards.

hass liefert 400: bekannter trusted_proxies-Punkt aus TP16, gehoert vor
die CNAME-Umstellung.

Split-Horizon entschieden (User): in AdGuard zusammen mit TP23 Stufe 2.
Dokumentiert, was das bedeutet -- heute liefert der DHCP in allen sieben
VLANs den Core als DNS; AGH bekommt niemand. Der Schritt verschiebt die
Aufloesung des ganzen Hauses in einen Container, deshalb als Paar
110/111 bauen. Die geloeschten Altlasten hiessen nicht zufaellig
adguard-bf1/-bf2.

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

caddy/Caddyfile

@@ -43,9 +43,9 @@ nautobot.emsenhuber.net {
 	reverse_proxy http://10.40.20.30:8080
 }
 
-grafana.emsenhuber.net {
-	reverse_proxy http://10.40.20.109:3000
-}
+# grafana.emsenhuber.net — 2026-08-25 entfernt: LXC 104 war seit Langem gestoppt und stand
+# noch auf VLAN1 (10.40.41.109); die Ingress-Zeile zeigte auf 10.40.20.109, das es nie gab.
+# Wiederaufbau spaeter als eigener Punkt, dann nach TP32-Systematik.
 
 ds-bf.emsenhuber.net {
 	reverse_proxy http://10.40.20.10:8080

docs/teilprojekte.md

@@ -1425,13 +1425,41 @@ Alles andere ist intern; **19 Ingress-Zeilen über drei Tunnel werden EINE Catch
    `CF_DNS_API_TOKEN` in `~/.secrets/credentials.env`, Ausrollen per **`caddy/deploy.sh`** — das
    liest den Wert von dort und schreibt ihn in die Container-Env, **ohne ihn je auf stdout oder in
    eine Kommandozeile zu bringen** (dieselbe Regel wie `sshpass -e`).
-4. **Split-Horizon**: Service-FQDNs → Caddy. 🔗 **Vorher entscheiden: Core (`/ip dns static`) oder
-   AdGuard?** Sobald AGH nach **TP23 Stufe 2** scharf ist, gehören die Einträge dorthin — sonst zweimal gebaut.
+4. **Split-Horizon → ✅ ENTSCHIEDEN 2026-08-25: in AdGuard, zusammen mit TP23 Stufe 2.**
+   Begruendung des Users: nichts zweimal bauen. **Konsequenz, die man kennen muss:** AdGuard wird
+   damit vom Nebendarsteller zum **Resolver des Standorts** — heute liefert der DHCP in **allen
+   sieben VLANs** `dns-server = <VLAN>.1`, also den Core; AGH auf `10.40.20.16` bekommt niemand.
+   ⇒ Der Schritt ist groesser als „ein paar Eintraege": er verschiebt die DNS-Aufloesung des ganzen
+   Hauses vom grundsoliden Core in einen Container.
+   🔑 **Deshalb als Paar bauen** — TP32 reserviert `110`/`111` fuer DNS, und die geloeschten
+   Altlasten hiessen nicht zufaellig `adguard-bf1`/`adguard-bf2`: die Redundanz war urspruenglich
+   schon einmal geplant. **Ein einzelner AGH waere ein DNS-SPOF auf pve.**
 5. **Tunnel `bf-public`** + Connectoren auf ap1/ap2, CNAMEs umhängen (`n8n` → `gitea` → `hass` → `vw`).
 6. **Abbau:** `bf-nas`/`bf-pve`/`bf-mm` löschen, sechs Container weg, SSH-Browser-Rendering entfällt,
    **MCP-Clients auf FQDN umstellen** (`~/.claude.json` spricht heute `10.40.20.105:9583` und
    `10.40.20.173:3000` roh; `n8n-mcp`/`gitea-mcp` kommen dabei wieder in Betrieb).
 
+#### ✅ Stand 2026-08-25 nach dem Bau — Caddy laeuft, zwei Backends fielen dabei auf
+**17 von 17 Zertifikaten** per DNS-01 von Let's Encrypt geholt, Dienst `active`+`enabled`,
+Proxy-Funktion gegen den Host-Header verifiziert: `nautobot` 302 · `gitea` 200 · `pve` 200 ·
+`portainer` 200. `caddy/deploy.sh` laeuft End-to-End (Token wird aus `~/.secrets` gelesen, per
+Fingerprint gegengeprueft: **eigenes Token, nicht das account-weite**).
+
+🔴 **Fund: `grafana` war seit Langem tot — und Cloudflare Access hat es maskiert.**
+LXC 104 `alpine-grafana` stand auf `stopped` und konfigurativ noch auf **VLAN1**
+(`10.40.41.109`); die CF-Ingress-Zeile zeigte auf `10.40.20.109:3000` — eine Adresse, die es fuer
+Grafana **nie gab**. Im FQDN-Smoke-Test lieferte `grafana.emsenhuber.net` trotzdem ein sauberes
+**302** — das war der **Access-Login**, nicht der Dienst.
+⚠️ **Das ist exakt die Falle aus TP16.3 §8, diesmal in freier Wildbahn:** ein Statuscode vom
+oeffentlichen FQDN sagt nichts ueber das Origin, solange Access davor steht. **Ein toter Dienst
+sieht monatelang gesund aus.** ⇒ Caddy-Zeile entfernt (16 Sites), **LXC 104 zerstoert** und aus dem
+Backup-Job genommen — die **14 PBS-Snapshots bleiben bewusst stehen**, sie sind die einzige Kopie
+etwaiger Dashboards. Wiederaufbau spaeter als eigener Punkt, dann nach TP32-Systematik.
+
+🟡 **`hass` liefert 400** — der bekannte offene Punkt aus TP16: Home Assistant braucht
+`10.40.20.40` in `http.trusted_proxies` plus `use_x_forwarded_for: true`, sonst weist es den neuen
+Proxy ab. **Gehoert vor die CNAME-Umstellung von `hass`.**
+
 🎯 **Kernabnahme: WAN trennen, dann alle Dienste per FQDN.** Das ist die Autarkie, um die es geht.
 ⚠️ **Preis, offen benannt:** mit Split-Horizon greift **Access innerhalb des Netzes nicht mehr**; dort
 tragen TP5-Segmentierung und die App-eigene Auth.