TP31: hass-400 geloest - HA ignoriert den http-Block in der YAML

Ursache war nicht der fehlende Eintrag, sondern der falsche Ort: HA hat die
http-Konfiguration nach .storage/http migriert ("yaml_migration_done": true,
created_at 2026-08-05). Der YAML-Block wird seither kommentarlos ignoriert -
auch ein absichtlich ungueltiger Schluessel darin erzeugt keinen Fehler.

Die Logzeile fuehrt aktiv in die Irre: "untrusted proxy 10.40.20.40" faellt
laut Quelltext nur bei aktivem use_x_forwarded_for - beide Werte kamen aber
aus .storage, wo .20.10/.126/.167 (die cloudflared-Origins) standen und
Caddy fehlte.

Fix ueber den vorgesehenen Weg: http/config/configure (setzt pending, startet
HA neu) und binnen 5 Minuten http/config/promote. stable enthaelt jetzt
10.40.20.40/32, pending ist leer, hass/vw/gitea/n8n liefern 200 ueber Caddy.

Der wirkungslose Block in configuration.yaml ist durch einen Hinweis ersetzt.
Offen und bewusst vertagt: 10.40.41.10/32 (tote VLAN1-NAS) steht weiter in
der Trusted-Liste.

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

CLAUDE.md

@@ -132,6 +132,17 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
   - 🔴 **Zweite, unabhängige Ursache desselben Falls (08-25): die Sonos-App suchte gar nicht.** Nach der Relay-Reparatur lag weiter nichts an — der Mitschnitt auf der VLAN40-Leitung (`pct exec 108 -- tcpdump -i eth1 -n -s0 -A "udp and host <client>"`) zeigte: **jedes** SSDP-Paket des MacBooks kam von **Chrome** (`ST: urn:dial-multiscreen-org:…dial:1`, `USER-AGENT: Chromium`), **kein einziges** von Sonos. Die App hatte Sockets offen (`*:1900`, `*:6969`, `TCP *:3400`) und redete mit der Cloud, legte aber nichts auf die Leitung. Ursache war das **Local-Network-Gate von macOS**: es stand auf **„an" und griff trotzdem nicht**. Fix = Schalter unter *Datenschutz & Sicherheit → Lokales Netzwerk* **aus, App beenden, wieder an, App starten** (hart: `sudo tccutil reset LocalNetwork com.sonos.macController2`).
     ⇒ **Merkregel: „die App sucht hunderte Male" ist erst dann ein Befund, wenn der Mitschnitt sagt, WER sucht.** Im Handoff vom Vormittag waren die gezählten 291 Suchen Chrome + eigene Proben; die Zahl hat drei Stunden in die falsche Richtung gezeigt.
   - 🖥️ **Das MacBook ist dual-homed in VLAN10:** `en5` = **10.40.10.183** (USB-Dock, Default-Route) und `en0` = **10.40.10.82** (WLAN). Die früher als „zweiter Mac" gelesene `.183` ist **dasselbe Gerät** — beim Messen immer beide Beine prüfen.
+- 🏠 **Home Assistant: der `http:`-Block in `configuration.yaml` ist WIRKUNGSLOS** (Fund 2026-08-26,
+  TP31). HA hat die http-Config nach **`.storage/http`** migriert (`"yaml_migration_done": true`);
+  seither wird die YAML kommentarlos ignoriert — selbst ein ungueltiger Schluessel darin erzeugt
+  **keinen** Config-Fehler. 🔴 **Die Logzeile fuehrt aktiv in die Irre:** `Received X-Forwarded-For
+  header from an untrusted proxy <ip>` faellt laut Quelltext nur bei **aktivem**
+  `use_x_forwarded_for` — man haelt die Option fuer wirksam und die Liste fuer falsch und editiert
+  die falsche Datei. Richtig ist der WS-Zweischritt **`http/config/configure`** (setzt `pending`,
+  startet HA neu) → binnen **5 Minuten** **`http/config/promote`**, sonst Auto-Revert auf `stable`.
+  Merkregel zur Eingrenzung: ein Testskript in `<config>/python_scripts/` + `python_script.reload` —
+  taucht der Service auf, liest HA das Verzeichnis, und die Frage ist nicht mehr *welche Datei*,
+  sondern *warum ein gelesener Block nicht wirkt*.
 - 🐳 **Nautobot auf der DS923 braucht einen abgeschalteten Image-Healthcheck.** Der eingebackene Check ruft alle 10 s `nautobot-server health_check` = einen vollen Django-Start; unter Last dauert der >2 min, die Aufrufe **stapeln sich unbegrenzt** → Speicher alle → `fork()` mit ENOMEM → DSM räumt den ganzen Stack ab (am 2026-08-17 zweimal passiert, Load bis 73 bei 4 Kernen). Im Stack stehen deshalb `healthcheck: disable: true` auf worker+scheduler, `--concurrency=2` und `mem_limit`. **`cpus:` geht auf Synology nicht** (Kernel ohne CFS-Quota, der Stack-Deploy schlägt sonst fehl).
 - 📜 **~~Omada ES208G = Easy Managed~~ — gegenstandslos** (Gerät abgebaut 2026-07-23, Controller gelöscht).
 - **L3-Router = `crs326-core` (TP21.1 ✅ 2026-08-08, ersetzt ap1).** Bridge vlan-filtering=yes; VLAN-SVIs `.1` je VLAN mit DHCP (7 Server / 54 Leases); DNS über **DoH** zum CF-Gateway, `verify-doh-cert=yes` (TP23 Stufe 1 ✅ 2026-08-18). Die alte Notiz „core hat kein CA" war zu pessimistisch: es braucht kein Bundle, sondern **genau einen Root** (GTS Root R4, ~1 KB) — die Kette ist Leaf → GTS WE1 → R4. **Beide Firewall-Ketten enden seit 2026-08-18 mit `drop`** (TP5 E3/E4); `TP10-seal-lan` ist `disabled`, Mgmt-Input kommt nur noch aus VLAN10, von HA (`8728`), von Nautobot (`22`) und über `cf-mesh`. **ap1/ap2 sind NUR noch APs** — kein DHCP/DNS/NAT/Routing/WG dort. (Die frühere „TP4: ap1 ist L3-Router"-Zeile ist überholt.)

docs/handoff-20260825-agh-dns-cutover.md

@@ -23,16 +23,11 @@ Auflösung selbst das Kaputte ist. **Nicht ans Ende einer langen Sitzung legen**
   - ℹ️ `pve-mcp` 400 / `ha-mcp` 403 / `gitea-mcp` 404 sind **keine Proxy-Fehler** — dieselben Codes
     kommen direkt vom Origin. Nicht als Baustelle behandeln.
   - 🧹 Der Zertifikatsspeicher hält **17** Zertifikate bei 16 Sites: `grafana` ist verwaist (harmlos).
-- 🟡 **`hass` liefert weiter 400 — ungelöst, gehört VOR die CNAME-Umstellung** (nicht vor diesen Schritt).
-  `http:`-Block steht in `/homeassistant/configuration.yaml` (`use_x_forwarded_for: true`,
-  `trusted_proxies: 10.40.20.0/24` + `.10` + `.167`), Sicherung `configuration.yaml.bak-20260825-tp31`.
-  **Die Änderung ist seit 23:18 drin, HA läuft aber noch mit dem Stand von 22:40 — der Neustart fehlt.**
-  ⚠️ Sowohl der Schreibzugriff als auch der Restart wurden zuletzt vom Auto-Mode-Klassifikator
-  blockiert; entweder freigeben oder selbst ausführen:
-  `ha core restart` bzw. `homeassistant.restart`, danach
-  `curl -o /dev/null -w "%{http_code}\n" --resolve hass.emsenhuber.net:443:10.40.20.40 https://hass.emsenhuber.net/`
-  - 🔎 **Der Logtext ist der Befund, nicht der Statuscode:** `Received X-Forwarded-For header from an
-    untrusted proxy 10.40.20.40` ≠ „not set-up for reverse proxies" ⇒ die Option greift, die Liste nicht.
+- ✅ **`hass` liefert 200** (gelöst 2026-08-26). Ursache war **nicht** der fehlende YAML-Eintrag:
+  HA hat die http-Config nach **`.storage/http`** migriert, der `http:`-Block in `configuration.yaml`
+  ist seither **wirkungslos**. `10.40.20.40` ist über den WS-Zweischritt `http/config/configure` →
+  `http/config/promote` in die Trusted-Liste gekommen und als `stable` bestätigt. Details in TP31.
+  ⇒ **Damit ist die CNAME-Umstellung von `hass` nicht mehr blockiert.**
 - ✅ **Aufgeräumt** (TP31 Schritt 1): LXC `120/121/128/129/130(alt)/131` **und `104`** zerstört,
   72/72 PBS-Snapshots weg. Die **14 Snapshots von `ct/104` stehen bewusst** (einzige Grafana-Kopie).
 - ✅ **Startreihenfolge auf pve repariert** (TP32): HA startet nach MariaDB, Docker, MQTT, z2m25.

docs/teilprojekte.md

@@ -1490,24 +1490,30 @@ Dienst `active`+`enabled`, Probe von einem **zweiten Host** (pve, VLAN20) mit
   `grafana.emsenhuber.net` liegt noch da. Harmlos (Caddy erneuert es nicht mehr), beim
   Grafana-Wiederaufbau nach TP32 mit aufraeumen.
 
-🔴 **`hass` liefert weiterhin 400 — und der Fix ist NICHT der erwartete Einzeiler.**
-Der `http:`-Block ist eingetragen (`use_x_forwarded_for: true` + `trusted_proxies` mit
-`10.40.20.40`/`.10`/`.167`, Sicherung `configuration.yaml.bak-20260825-tp31`), Config-Check `valid`,
-**HA zweimal voll neu gestartet** — trotzdem antwortet es 400.
-- 🔎 **Der Logtext ist der Befund:** `Received X-Forwarded-For header from an untrusted proxy
-  10.40.20.40`. Das ist **nicht** die Meldung „not set-up for reverse proxies", die bei
-  abgeschaltetem `use_x_forwarded_for` kommt ⇒ **die Option greift, nur die Liste zieht nicht.**
-- ⚠️ **Was als Beweis NICHT taugt:** die `atime` der `configuration.yaml`. Sie steht auf dem
-  Schreibzeitpunkt, aber unter **`relatime`** wird sie nur nachgezogen, wenn sie *aelter* als die
-  `mtime` ist — bei `atime == mtime` bleibt sie stehen. „Datei seit dem Schreiben nicht gelesen"
-  laesst sich daraus **nicht** ableiten.
-- ⏭️ **Naechster Schritt (offen):** Block testweise auf `10.40.20.0/24` verbreitern und neu starten —
-  faellt der 400 dann weg, liegt es an der Listenauswertung; bleibt er, liest HA eine andere Datei
-  als die unter `/homeassistant/configuration.yaml`. **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.
+✅ **`hass` liefert 200 — gelöst 2026-08-26, und die Ursache ist eine Falle für jeden Reverse Proxy.**
+Der `http:`-Block in `configuration.yaml` war **wirkungslos**: Home Assistant hat die http-Konfiguration
+nach **`.storage/http`** migriert (`"yaml_migration_done": true`, `created_at` 2026-08-05). Seither wird
+der YAML-Block **ignoriert** — ohne Fehlermeldung.
+- 🔎 **Warum das so schwer zu sehen war:** die Logzeile lautet `Received X-Forwarded-For header from an
+  untrusted proxy 10.40.20.40` und **nicht** „not set-up for reverse proxies". Laut Quelltext fällt die
+  erste nur bei **aktivem** `use_x_forwarded_for` — was zur Annahme führt, die Option greife und nur die
+  Liste sei falsch. Tatsächlich kam beides aus `.storage`: `use_x_forwarded_for: true` stand dort längst,
+  die Liste enthielt `.20.10`, `.20.126`, `.20.167` (die drei cloudflared-Origins) — nur Caddy fehlte.
+- 🧪 **Was den Verdacht in die Irre führte, der Reihe nach ausgeschlossen:** Datei-Identität (ein
+  Testskript in `python_scripts/` tauchte sofort als Service auf ⇒ HA liest dieses Verzeichnis),
+  Blockposition (nach ganz oben verschoben — keine Änderung), Kommentare/Formatierung (minimaler Block —
+  keine Änderung), Prozesszeitpunkt (`.ha_run.lock` `start_ts` gegen die Datei-`mtime` gestellt) und
+  Schema-Validierung (ein absichtlich ungültiger Schlüssel im `http:`-Block erzeugte **keinen**
+  Config-Fehler — im Nachhinein der eigentliche Beweis).
+- ✅ **Der vorgesehene Weg ist ein WS-Zweischritt mit Auto-Revert:** `http/config` lesen →
+  `http/config/configure` mit der **vollständigen** Config (setzt `pending` und **startet HA neu**) →
+  innerhalb von **5 Minuten** `http/config/promote`, sonst fällt HA automatisch auf `stable` zurück.
+  ⚠️ Der Promote ist knapp: HA braucht hier ~2 min bis zur Erreichbarkeit, und der WS-Weg über das
+  MCP-Add-on antwortet währenddessen mit 502. **Erst promoten, wenn die Wirkung gemessen ist** — genau
+  dafür ist das Fenster da.
+- 🧹 In `configuration.yaml` steht jetzt ein Hinweis-Kommentar statt eines wirkungslosen Blocks.
+  📌 **Offen, bewusst nicht heute:** `10.40.41.10/32` (die alte VLAN1-NAS) steht weiterhin in der
+  Trusted-Liste — Aufräumen kostet denselben Zweischritt inkl. Neustart.
 
 #### 🧭 Wo liegt die Source of Truth? — beantwortet 2026-08-26
 > **User-Frage:** „schaffen wir es mit überschaubarem aufwand cf und caddy synchron zu halten? wo