Auslöser (User 2026-08-31): beim Core-Neustart war crs326-branch nicht mehr
erreichbar, weil sein Management ausschliesslich ueber den Core laeuft.
Live nachgemessen: auf dem Branch ist vlan99 tagged=ether1,ether24,bridge mit
untagged="" - es gibt also keinen Weg zu 10.40.99.2, der nicht durch den Core
fuehrt. Wer den Core zerkonfiguriert, verliert den Branch gleich mit und damit
die Moeglichkeit, es vom Branch aus zu reparieren.
Zweiter, unangenehmerer Befund: crs326-branch hat GAR KEINE input-Regeln (Kette
leer). Sein gesamter Schutz besteht heute darin, dass VLAN99 nur ueber den Core
erreichbar ist und dessen forward-Kette deny-by-default faehrt - die
Erreichbarkeitsbeschraenkung IST die Zugangskontrolle. Damit ist ein untagged
MGMT-Port ein physischer Generalschluessel, und das TP traegt eine explizite
Auflage: Port disabled im Normalbetrieb ODER input-Regeln auf beiden Switches
ODER physische Sicherung. Empfehlung im Abschnitt: die input-Regeln, weil sie
eine Luecke schliessen, die unabhaengig von diesem TP besteht.
Kandidat ether23 - auf core und branch beide running=false, also frei, und auf
beiden Geraeten dieselbe Nummer.
Abnahme im Abschnitt so formuliert, dass sie den Zweck prueft: Laptop an
branch ether23, Core-Trunk gezogen, 10.40.99.2 muss antworten. Alles andere
misst nur den Normalfall.
Quick-Index (nach TP36 einsortiert), TP-Abschnitt und Ist-Stand mitgezogen;
Handover 20260831 auf den angelegten TP umgestellt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nautobot: ap1 stand als einziges Geraet noch auf SoftwareVersion 7.24 (ap2,
ap3, core, branch waren bereits richtig) -> auf 7.24.1 gesetzt. Danach
Backup/Intended/Compliance.
Folge fuers Runbook: aus zwei container.npk wird EINE. Die Zwei-Dateien-Regel
vom 08-30 war rein versionsbedingt, nicht modellbedingt - cAP ax und hAP ax^2
teilen sich die arm64-Pakete. §0, §2.1, §3.1 und Falle 1 umgeschrieben.
Die Regel dahinter bleibt: npk muss exakt zur ROS-Version passen, sonst ist
das Paket nach dem Reboot inaktiv - ohne Fehlermeldung.
Neue Compliance-Drift, NICHT von dieser Session und bewusst offen gelassen:
crs326-core / wifi-security - sec-main hat am Geraet ft-over-ds=no, Soll ist
yes (ft=yes ist korrekt). Kam mit dem Upgrade. 134/135 compliant. Braucht eine
Entscheidung (Geraet korrigieren oder neuen Wert zum Soll erklaeren) plus
Re-Provisionierung der CAPs; ein Re-Baseline ohne Entscheid wuerde die
Drift-Erkennung wertlos machen.
Handover docs/handoff-20260831-tp16.3-vorort-session.md fuer die Folgesession
(§2/§3: npk, device-mode, Container). Enthaelt u.a. den Hinweis, dass ein
fehlschlagendes /tool fetch vom AP auf Caddy KEIN Fehler ist, sondern die
SNI-Abweisung - und dass der TLS-Alert sogar beweist, dass die Freigabe traegt.
Offen notiert, nicht angelegt: TP-Vorschlag "dedizierter untagged-VLAN99-Port
je Switch" (Out-of-Band-Mgmt) - Auslöser war, dass crs326-branch beim
Core-Neustart nicht erreichbar war. Wartet auf Christophs Okay.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A) bf-public-Ingress von http://10.40.20.40:80 auf https://10.40.20.40:443
umgestellt, originServerName je Regel. Die :80-Variante haette ueber
Cloudflare eine Redirect-Schleife gebaut (Caddy antwortet dort 308 auf
https, das Ziel laeuft zurueck in denselben Tunnel).
B) Freigabe vlan99 -> vlan20:443 auf crs326-core angelegt - ueber Nautobot
Golden Config, NICHT per Direkt-Write: ip-firewall-filter steht seit TP26
unter Drift-Kontrolle, und die zwei genehmigten Ausnahmen (#2 Bring-up,
#4 WireGuard-Keys) decken diesen Fall nicht.
- Backup vorher: core-pre-tp16.3-blockerB-20260831.backup (TP22-Regel 3)
- gc-manual-plan.py, Change-ID TP16.3-BlockerB, Plan Completed
- Position verifiziert: direkt vor TP5: log-only / TP5: deny-by-default
- Re-Baseline ingest-core-firewall.py --apply, dann --refresh-compliance
=> 135/135 compliant, 0 Drifts
- funktional: /tool fetch von ap3 erreicht Caddy und bekommt einen
TLS-Alert VON Caddy - ein Alert kann nur vom Server kommen, das Paket
ist also da. Der Alert ist die SNI-Abweisung (ohne SNI 000, mit
korrektem SNI 200) und damit genau der Grund fuer originServerName.
C) ROUTER_AP3_USER/_PASS in ~/.secrets/credentials.env nachgetragen (war nur
in ~/.claude.json), chmod 600, Sicherung .bak-20260831. REST-Auth gegen
ap3 = HTTP 200.
Vor Ort startet die Arbeit damit bei §2/§3 (container.npk, device-mode,
Container). Quick-Index, TP16.3-Abschnitt und Ist-Stand mitgezogen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CLAUDE.md und README.md behaupteten beide noch den Inventur-Stand vom
2026-08-27: "lokal, kein Gitea-Remote (Working-Copy). Verloren bei
Festplattencrash." bzw. "kein Gitea-Remote (Sicherheitsluecke, offen)".
Live geprueft: origin = https://gitea.emsenhuber.net/admin/bf-infra.git,
main lokal und remote identisch. Die Luecke ist zu.
Dazu der Hinweis, der die Aussage traegt: ein Remote ist nur so viel wert wie
der letzte Push - der Backup-Guard (TP35 Schicht 5) ist genau diese
Erinnerung und wird nicht mit --no-verify umgangen.
docs/handoff-20260827-inventur-und-architektur.md bleibt unveraendert - der
Handoff ist ein historischer Snapshot und war an dem Tag korrekt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Runbook docs/tp16.3-bf-public-ap-connector-runbook.md fuer die Vor-Ort-Session
geschrieben; docs/tp31-schritt5-runbook.md abgeloest (read-only-Header).
Live-Befunde 2026-08-30, die den Plan aendern:
- ap3 ist neu und NICHT baugleich: cAP ax (cAPGi-5HaxD2HaxD, 10.40.99.13),
arm64/96 MB frei, aber ROS 7.24.1 gegen 7.24 auf ap1/ap2 => zwei
verschiedene container.npk. device-mode=basic statt home (fetch bereits an).
- Blocker A: bf-public-Ingress zeigt auf :80, Caddy antwortet dort mit 308 auf
https => Redirect-Schleife ueber CF fuer alle vier Namen. Faellt heute nicht
auf, weil die Alttunnel an Caddy vorbei direkt aufs Backend gehen.
Fix: https://10.40.20.40:443 + originServerName je Regel (ueber 443 4x 200).
- Blocker B: es gibt KEINE Freigabe vlan99 -> vlan20:443. Die forward-Kette
wurde vollstaendig gelesen (36 Regeln); die einzige MGMT->INFRA-Regel ist ein
src-port=8728-Rueckweg. Der Vorgaenger-Runbook behauptet das Gegenteil
("Regel 27 deckt vlan99->vlan20:80 ab") - Regel 27 ist IOT->INFRA.
- Blocker C: ROUTER_AP3_PASS fehlt in ~/.secrets/credentials.env (nur in
~/.claude.json). Nebenbefund: credentials.env laesst sich in zsh nicht
sourcen (rohe WireGuard-Zeilen ab ~Z.69) - Variablen bleiben still leer.
- Kein PoE an beiden CRS326 => kein Remote-Power-Cycle, Bestaetigung physisch.
- Die sechs abzubauenden Container auf allen drei Hosts verifiziert;
terpene-cloudflared und fm.emsenhuber.net bleiben.
CF-Rollback-Snapshots unter docs/cf-backup/*-20260830-vor-tp16.3-schnitt.json
neu angelegt (vier Ingress-Configs + CNAMEs inkl. Record-IDs) - es gab sie
vorher nicht.
Quick-Index, TP16.3-Abschnitt und Ist-Stand-Block mitgezogen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christophs Kontext explodiert am Sessionende. Handoff bündelt:
- CF-Token-Audit-Befund: CF_DNS_API_TOKEN ungültig (Code 1000 'Invalid API Token'),
Christophs Verdacht 'falscher Token extrahiert' bestätigt.
- Globale MCP-Migration FQDN → IP für gitea-mcp + n8n-mcp; cloudflare bleibt
extern (User-Direktive explizit). WARP-Pfad statt Bearer-Header wenn der
Connector intern ohne Token lebt.
- terpene W5: n8n-mcp in blaueblueten-n8n/.mcp.json (User-Zustimmung).
- Domain-Korrektur: 420.teilzeitladen.xyz ist die echte terpene-Domain
(NICHT terpene.teilzeitladen.xyz) — User-Direktive, gilt für alle.
- W1/W6 bleiben User-blocked, W7 wartet auf TP31-Schritt 5/6.
Dringend beim Nachfolger: CF-Token-Validität zuerst klären, dann erst
MCP-Migration. STATUS.md im terpene-Repo ist auf die falsche Domain
korrigieren.
Container shelly-mcp läuft seit dem mcp<2-Pin-Fix auf DS923 (10.40.20.180,
macvlan vlan20). Eintrag in der projekt-spezifischen Config analog zu pve-mcp:
type=remote, kein Bearer (Container nimmt keine Auth entgegen, lebt im
BF-LAN hinter deny-by-default — s. TP5).
Abnahme: mcp list 11/11, shelly-mcp connected, /health antwortet
200 mit psk_configured:true.
Container crashte beim ersten Deploy mit 'No module named mcp.server.fastmcp':
PyPI hat mcp 2.x als aktuellste Version, FastMCP wurde dort zu MCPServer
umbenannt. Repo-Code (server.py) nutzt noch v1-API.
Fix: requirements.txt 'mcp[cli]>=1.0,<2' — hält den Server auf v1-kompatibel.
Deploy-Ergebnis:
- Container shelly-mcp auf DS923, IP 10.40.20.180 (macvlan vlan20)
- Health /health: 200, psk_configured:true, iot_ssid=dirtyvader-iot
- StreamableHTTP /mcp: serverInfo 'shelly-mcp 1.29.1'
- Live-Sweep 10.40.30.180-250: 23 Shellys erreichbar
TP30 Posten #3 (Shelly-Gerätepasswort) hochgestuft: SHELLY_DEVICE_PW ist im
Zuge dieses Deploys erneut in ein Sitzungstranskript geraten (sed-Pattern
'SHELLY_DEVICE_PW=.*' hat den Wert nicht maskiert, weil der Replacement-
String zu wenig greedy war — neuer Lessons-Block-Eintrag). Reihenfolge:
erst Werkzeug-Härtung (Stream-Filter statt cat+sed), dann Posten #3
rotieren. CLAUDE.md hat den Lessons-Eintrag, TP30 Posten #3 hat die
Hochstufungs-Begründung.
Portainer-Server (pve LXC 400): 2.40.0 → 2.42.0 via Image-Swap mit Volume-Erhalt.
Pre-Upgrade-Snapshot: docker commit :2.40.0-preupgrade-20260828 (Rollback 7 d
verfügbar) + Settings/Stacks/Endpoints-JSON-Dump (40 KB, 31 Stacks, 4 Endpoints).
Instance-ID + API-Token nach Bump identisch — kein Re-Auth, kein Settings-Verlust.
portainer-mcp: offizielles PyPI-Paket mcp-portainer~=2.42.0 (193 Tools), nur
in bf-infra/opencode.jsonc, via uvx-stdio. Tool-Gate: get_guidance() einmal pro
Session zwingend vor erstem Read. Andere Projekte unberührt.
Korrekturen ggü. Handoff 2026-08-28 README:
- mcp-portainer PyPI bis 2.42.6, Docker-Hub portainer/portainer-ce nur bis 2.42.0
(unterschiedliche Versionierungspfade).
- mcp/portainer/README.md ist auf 2.42.6 formuliert und sollte nachgezogen werden.
Bestand: mcp/INVENTORY.md portainer-mcp ⛔→🟢 + Header MCP-WARP-Direktive ergänzt.
.mcp.json (war getrackt aus Commit 3426366) entfernt: opencode nutzt opencode.jsonc,
nicht .mcp.json — Claude-Code-Konvention hier irrelevant.
Befund 2026-08-28 nach Skill-Verifikation in opencode:
- Der 'Nächster Schritt (2026-08-26)'-Absatz war zwei Tage veraltet
(drei Sessions waren parallel offen)
- Manuelle Doku mit Live-Daten verliert gegen die Realitaet, sobald
die Datei lang wird (1940 Zeilen, drei Stellen pro Edit)
Reaktion:
1. 'Nächster Schritt' umgeschrieben: drei Folge-Sessions A/B/C aus
dem gestrigen Handoff, klar als 'parallel' markiert. A ist erledigt
(TP35 Schicht 6), B+C offen.
2. TP36 als Folge-TP neu angelegt: SSoT via Nautobot fuer
teilprojekte-Live-Daten + Datei-Aufteilung (Index / Snapshot /
Archiv). Eigene Session, nicht heute.
3. CLAUDE.md: zwei Lessons-Eintraege:
a) opencode-TUI: fuehrendes Leerzeichen vor /command manchmal
noetig (Beobachtung, kein Skill-Bug)
b) Manuell gepflegte Doku verliert gegen Realitaet, Merkregel:
drei Stellen pro Edit mitlesen (Quick-Index, TP-Abschnitt,
Ist-Stand); strukturelle Antwort = TP36
Lessons-Block hat jetzt 7 Eintaege (Stand 2026-08-28).
- CLAUDE.md: zwei Lessons-Eintraege (opencode-Default-Pfad kopieren,
nicht symlinken; Kommentar in Code != Verhalten)
- teilprojekte.md: TP35 Quick-Index auf 'Schicht 6 erledigt, Rest offen',
Schicht-6-Befund im TP-Block, Ist-Stand auf 2026-08-28 mit MCP-Bestand-
Korrektur
- handoff-20260828-session-a-projektstatus.md: Session-A-Bericht mit
Drift, Befund, Entscheid, Lehren fuer Session B
Skill selbst liegt in ~/.config/opencode/skills/projektstatus/SKILL.md
(cp aus ~/.claude/skills/projektstatus/, byte-identisch) - opencode
scannt diesen Default-Pfad, kein skills.paths-Eintrag in der JSONC
noetig.
cloudflared-Konfigurationsmaterialien fuer TP16.3 (BFF-public-Tunnel
auf dem Edge statt cloudflared-QUIC-Workaround). Enthaelt:
- ap-bootstrap.rsc: RouterOS-Script fuer ap1/ap2 (veth, srcnat,
container-mounts, env-Vars). Token kommt aus ~/.secrets, wird per
SFTP auf den Router kopiert — kein Klartext im Script.
- cloudflared-bf-public-config.yml: tunnel-UUID + credentials-Pfad
(KEIN Secret). Ingress wird CF-Dashboard-gemanagt (config_src=cloudflare).
- .gitignore: credentials.json mit dem Tunnel-Secretbase64
(PrivateKey des Tunnels, niemals committen).
Status: vorbereitet, nicht ausgefuehrt. credentials.json bleibt lokal.
Vorbereitetes Runbook für TP31.5 (cloudflared-Container auf hAPs statt
TUN-Device-Workaround, da WARP-Connector auf ROS nicht möglich). Inhalt:
- Image-Build (RouterOS 7.x container, 70 MB Budget je AP)
- Pro AP: veth, interface-list-Mitgliedschaft, container-env
- CNAME-Flip von CF-Tunnel auf ap1/ap2 (DNS-Propagation, Rollback)
- Voraussetzungen: WAN-Healthcheck, Tunnel-Secret aus credentials.json
(siehe routeros/cloudflared/.gitignore im Folge-Commit)
Status: vorbereitet, nicht ausgeführt. Stand 2026-08-27.
Vorbereitung für Session B (Deploy auf DS923). Datei-Set reicht für
Image-Build ohne weitere Quellen aus dem Repo:
- Dockerfile: python:3.12-slim, mountbares /config ohne .env-COPY
- requirements.txt: mcp[cli]>=1.0, starlette>=0.36 (StreamableHTTP)
- BUILD.md: rsync → docker build → Portainer-Container-Deploy
- .gitignore: .env (Schema-Vorlage lokal) + __pycache__ ausklammern
Die Live-Instanz .env und der Container selbst werden in Session B
gebaut, nicht hier. Kein Secret in Git.
Eine Seite, die eine frische Session in 30 Sekunden auf Stand bringt:
TL;DR, Lese-Reihenfolge (Handoff → Anker → TP35), sofort-tun-Liste,
Übergabe-Mechanik, Mid-Action-Checkpoint, Commit-Hinweis-Regel, Was-offen.
Löst das 'Bahnhof'-Problem, das Christoph beim Session-Neustart
beobachtet hat.
TP16.3 existiert seit 2026-08-17 (Quick-Index Z. 194, Body Z. 401,
Runbook tp16.3-nautobot-mesh-only-runbook.md) und deckt 'alle Tools
über Caddy oder CF + Caddy (extern)' + Auth-Sanierung bereits ab.
Mein Fehler: ich habe im Index nicht nachgeschaut und einen Vorab-Punkt
formuliert, der TP16.3 doppelt. Anwender hat das in dieser Session
explizit markiert ('das darf dir kein 2. mal passieren').
Fix:
- Session-Anker: Vorab-Notiz entfernt, ersetzt durch Verweis auf TP16.3.
- TP16.3-Body: technische Notiz 'n8n-mcp Accept-Header-Strike +
Auth-Sanierung' eingepflegt (SSE-Header-Konsequenz für künftiges
Caddy-Fronting, Reihenfolge TP16.3 → TP35 Schicht 2).
Lehre: vor jeder Aussage 'gibt's noch nicht' oder 'neuer TP nötig':
erst grep auf den Quick-Index in teilprojekte.md.
n8n-mcp-Accept-Header-Strike wird mit dem noch kommenden CF-Tunnel-Punkt
gelöst, nicht heute. Bearer-Authentifizierung soll einmal sauber per
Caddy/CF-Access zentralisiert werden — TP35-Schicht-2 Endform hängt davon.
Inhalt: nur Doku, keine Migration, kein neuer TP, keine Config-Änderung.
Diagnose: n8n-mcp verlangt 'Accept: application/json, text/event-stream'
(StreamableHTTP-Modus). opencode mcp list schickt nur 'application/json',
kriegt 406, wertet als failed. Echter Tool-Aufruf nutzt richtigen Header,
deshalb Sidebar grün. Bearer-Token + Server sind gesund (200 OK mit
richtigem Accept-Header, serverInfo: n8n-documentation-mcp 2.57.1).
Konsequenz: 'failed' in mcp list ist nicht 'kaputt' sondern 'Probing-Header
zu strikt'. Sidebar-Status bleibt Wahrheit.
- Neue Handoff-Datei für den konkreten nächsten Schritt (im Gegensatz zur
Inventur-Handoff, die den Master-Plan zeigt).
- Dokumentiert: cannaleo/terpene-pg entfernt, n8n-mcp repariert,
shelly-mcp-Tote entdeckt, CLAUDE.md-Erweiterung.
- Liste der offenen Aktionen für die nächste Session: bf-network-r6
archivieren, terpene-Caddyfile-Block, STATUS.md Z.47 korrigieren,
n8n-mcp auch in ~/.claude.json, gitea-mcp-Init-Problem.
- shelly-mcp läuft auf keinem Host (kein Mac-Prozess, kein Container auf
NAS/pve). INVENTORY-Handoff hatte den Stand nicht aktualisiert.
Config jetzt enabled=false, neuer Punkt im Ist-Stand-Block.
- 3 neue Lessons-for-Sessions-Regeln: MCP-Änderungen aktiv melden,
Host vor Edit verifizieren, tote MCPs ins Projekt-Repo.
- 'Was du sofort wissen musst' um shelly-mcp-Tote ergänzt.
Die Datei war bereits im Working Tree, aber ohne klaren Zweck -- jetzt
umbenannt auf .snapshot.yaml und mit Marker-Kommentar versehen, der sagt:
- das ist KEINE Transaktions-Akte (kein .json)
- das ist auch KEIN Vor-Zustand zum heutigen nas.emsenhuber.net-Edit
- das ist die AGH-Komplett-Config mit bereits angewandtem Standortsuffix
(*.bf.emsenhuber.net), die beim Bau des AGH-Paars (110/111) in der
naechsten Session als Soll-Zustand gilt.
upstream_dns ist auf /bf.emsenhuber.net/ bedingt (Suffix-Form), 26 von
30 Rewrites haben .bf.-Suffix, 4 Public (vw/hass/n8n/gitea) bleiben ohne
Suffix.
Baut auf handoff-20260825 auf (AdGuard-Paar + Split-Horizon) und ergaenzt
den Auftrag um den heute eingefuehrten Standortsuffix-Sweep: alle BF-Hosts
in AGH heissen kuenftig <host>.bf.emsenhuber.net statt ohne Suffix.
nas.emsenhuber.net ist seit 1d569fa weg (Commit direkt vorher).
`nas.emsenhuber.net` war nur als AGH-Rewrite auf 10.40.20.10 vorhanden,
zeigte aber nirgends hin: kein CF-CNAME, kein Caddyfile-Eintrag (der
hatte von Anfang an ds-bf.emsenhuber.net fuer Synology DSM).
Mit dem TP23-Stufe-2-Cutover wandert die DNS-Aufloesung in ein
AdGuard-Paar und der Rewrite-Satz wird neu aufgebaut. Die Regel
ist ab jetzt: Hosts, die es an mehreren Standorten gibt, heissen
immer `<host>.<site>.emsenhuber.net` — kein gemeinsamer Name
ohne Suffix.
Andere namensgleiche Hosts (macmini/mfc/tv/docker/platform-pg/
core/ap1/ap2/branch) bleiben vorerst ohne Suffix in AGH und werden
einzeln in der TP23-Stufe-2-Session bewertet.
- adguard/AdGuardHome.yaml: AGH-Wizard-Setup (27 Rewrites ohne .bf, DoH zum CF-Gateway, conditional emsenhuber.net).
- nautobot/mikrotik_routeros.j2: DHCP dns-server=10.40.20.36,.37, domain=emsenhuber.net.
- docs/transaktionen/TP23-agh-firewall.commands.rsc: TP5-E2 LAN->AGH dns auf .16/.17 ersetzt durch .36/.37.
- docs/transaktionen/TP23-agh-dhcp-cutover.commands.rsc: DHCP-Cutover (dns-server + domain in einem Deploy).
Compliance 104/104, 0 Drifts. Core bleibt als Rückfallebene unangetastet.
[KEIN go fuer den Rest: Persistenz (CLAUDE.md/memory), Host.Naming (.host.emsenhuber.net),
add-dns-entries-Suffix, conditional-Upstream, lease-time-Transaktion, TP31-defer — alles im Plan,
Wartet auf separates go des Users.]
User-Entscheid. minarca, node-red, hms-mqtt-publisher und openproject
zerstoert, 28 PBS-Snapshots geloescht, 0 Fehler. Gegenprobe direkt am
Datastore: keine Spur von ct/103|109|115|201 mehr.
Ergebnis: auf pve laeuft jetzt jeder existierende Gast -- 11 LXC + 2 VMs,
kein einziger stopped. Der Datastore enthaelt nur noch aktuelle Gaeste.
Merkregel mitgeschrieben: die Snapshot-Liste VOR dem pct destroy
einsammeln. pvesm list --vmid liefert danach 0, obwohl die Backups noch
liegen -- der Filter braucht die Gast-Config. Genau deshalb lief der
104er-Loeschversuch vorhin ins Leere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Entscheid: auch die Grafana-Backups loeschen. Gegenprobe direkt am
Datastore (ct/104 = 0), nicht ueber 'pvesm list --vmid' -- dessen Filter
ist nach dem destroy nicht mehr aussagekraeftig.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christoph hat 10.40.41.10/32 (alte VLAN1-NAS) entfernt und den Stand als
stable bestaetigt - kein pending offen. Vertraut wird jetzt nur noch, was
tatsaechlich proxyt: 10.40.20.40 (Caddy) plus die drei cloudflared-Origins,
die mit Schritt 6 wegfallen. Abnahme: hass/vw/gitea/n8n je 200 ueber Caddy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
