TP10/CF 📄 Übergabe für CF-Tunnel #1033-Fix (Track A) in neue Session

Ursache verifiziert: 1 Tunnel, gleicher Token auf 2 Connectors (pve+nas) →
Round-robin trifft Origins, die nur von einem Host routbar sind → sporadisch #1033.
Ziel: HA-Connector-Paar in VLAN20, Origins auf 10.40.20.x, Rogues weg.
Reihenfolge: #1033 → FB-Bridge → IP-Migration. cf-mcp (Remote-OAuth) braucht
frische Session; Handoff ist self-contained mit Startschritten + Fallback.

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

docs/handoff-cf-tunnel-1033.md

@@ -0,0 +1,76 @@
+# Übergabe → neue Session: CF-Tunnel #1033-Fix (Track A)
+
+> **Erstellt:** 2026-06-30 · **Grund:** der `cloudflare`-MCP war in der Vorsession nicht
+> verbunden (Remote-OAuth, braucht frische Session). Diese Übergabe ist self-contained —
+> zusammen mit `~/.claude/plans/du-wei-t-ja-inzwischen-piped-blanket.md` (Gesamtplan) hast du
+> alles. Reihenfolge laut User: **#1033 ZUERST**, dann FB-Bridge, dann IP/VLAN-Migration.
+
+## 0. Als Erstes: cf-mcp-Verfügbarkeit prüfen
+Diese Übergabe existiert nur, weil der `cloudflare`-MCP gebraucht wird. Prüfe sofort:
+`ToolSearch` mit `cloudflare account tunnel zone dns` → es müssen **`mcp__cloudflare__*`-Tools**
+erscheinen. Wenn nicht: User bitten, in interaktivem `claude`-Terminal `/mcp` → `cloudflare`
+→ *Authenticate*, dann Session neu. (Verbunden in der Vorsession: mikromcp, omada-mcp,
+hostinger-api, ollama, cannaleo, playwright. NICHT verbunden: **cloudflare**, **home-assistant**.)
+
+## 1. Das Problem (verifiziert)
+Sporadische **Cloudflare-Fehler #1033** bei BF-Diensten. Ursache-Hypothese (hoch):
+- **Ein** Tunnel, **gleicher Token** auf **2 laufenden Connectors**: `pve` (Portainer
+  endpoint 2) und `nas-bf`/DS923 (endpoint 14). Beide `cloudflare/cloudflared:latest`,
+  `tunnel --no-autoupdate run`, Token in ENV, **keine Volume-Mounts** → Ingress ist
+  **token-managed = liegt im CF-Dashboard**, nicht lokal/im Repo.
+- Bei ≥2 Connectors round-robined Cloudflare die Requests. Zeigt eine Ingress-Origin auf
+  `localhost:port` / einen Docker-internen Namen / eine nur von **einem** Host routbare IP,
+  schlägt ~50 % der Requests am „falschen" Connector fehl → sporadisch 1033/502. = exakt
+  Christophs „nicht jeder Tunnel kommt auf jede IP".
+- Zusätzlich **Leichen/Rogue-Connectors**: `openclaw_cloudflared` auf odroid-m1 (endpoint 19,
+  OFFLINE), Alt-Einträge in `inventory/bf.md` (.30/.132/.145/.169 — teils veraltet).
+
+## 2. Ziel-Topologie (vom User entschieden)
+**1 Tunnel, HA-Connector-Paar (NAS + pve), BEIDE in VLAN20-INFRA**, sodass jeder Connector
+jede Origin erreicht. Rogue-Connectors weg. Origins auf konkret routbare IP:Port (Zielbild
+10.40.20.x). Ergebnis als **`docs/cf-tunnel-mapping.md`** dokumentieren (Single Source of Truth).
+
+## 3. Konkrete erste Schritte (mit cf-mcp)
+1. **Accounts/Tunnel auflisten** via `mcp__cloudflare__*` → Tunnel-ID(s), Status, aktive
+   Connector-Connections (`cfd_tunnel`). Bestätige: genau 1 Tunnel, welche Connectors live.
+2. **Ingress/Config auslesen** → vollständige `public-hostname → service (IP:Port)`-Liste.
+3. **DNS prüfen** → welche Hostnames als CNAME auf `<tunnel-id>.cfargotunnel.com` zeigen.
+4. **Reachability-Map** bauen: je Origin → von NAS routbar? von pve routbar? → asymmetrische
+   Routen markieren (= #1033-Verursacher).
+5. **Fixes vorschlagen** (NICHT blind anwenden — erst mit User): Origins normalisieren,
+   Rogue-Connectors abmelden, ggf. beide Connector-Container nach VLAN20 ziehen.
+
+### Fallback ohne cf-mcp (nur wenn OAuth partout nicht geht)
+Portainer-API (`https://10.40.41.126:9443`, Key in `mcp/portainer/.env`, `PORTAINER_TLS_VERIFY=0`):
+- Container-Liste je Endpoint 2 (pve) + 14 (nas): `GET /api/endpoints/{id}/docker/containers/json?all=1`
+- Logs des cloudflared: `.../containers/{cid}/logs?stdout=1&stderr=1&tail=300` → zeigt
+  fehlschlagende Origins / „error proxying" / 1033.
+- Inspect: `.../containers/{cid}/json` → Netz-Anbindung/ENV.
+⚠️ Fallback zeigt NICHT die Dashboard-Ingress-Regeln (token-managed). Deshalb cf-mcp bevorzugen.
+⚠️ Vorsession-Lektion: NICHT vorschnell in den Fallback springen — erst cf-mcp sicherstellen.
+
+## 4. Antworten auf Christophs 3 Eingangsfragen (bereits geklärt)
+- **admin-vlan 16?** → Nein, existiert nirgends (Repo + ap1 verifiziert: nur
+  10/20/30/40/50/90/99 + Bridge-VLAN1). War sein pve-interner Container-Zweit-IP-Trick;
+  Abschottung gehört über VLAN20 + TP5-Firewall, nicht zweite IP. Kann entfallen.
+- **VLAN-20-Trennung?** → Aktuell GAR NICHT. `/ip/firewall/filter chain=forward` endet ohne
+  abschließendes `drop` → RouterOS-Default=accept. Trennung erst mit **TP5** (deny-by-default
+  + Whitelist). Nur Drops heute: `invalid`, unsolicited-WAN.
+- **Morgen nativ bridgen?** → machbar, TP10-Kern durch (WG FM+DW live, WAN-Seal gestaged).
+  Offen: WAN-Seal anwenden + ether1→LAN4-Passthrough + DDNS `bf4.emsenhuber.net` + opt. Liwest.
+  Bridge ändert nur WAN-Edge, nicht interne Origins → #1033 davon unabhängig, vorher fixbar.
+
+## 5. Danach (Track B/C — Details im Plan-File)
+- **Track B (Bridge, „morgen"):** `routeros/tp10-cutover-apply.rsc` (Block C WAN-Seal) +
+  `routeros/fritzbox-bf-bridge-cutover-klickanleitung.md` Schritte 3–7. Console-Pfad während
+  Cutover: FB-WiFi → 10.40.41.1 via ether2. Rollback: ether1 zurück, Passthrough aus.
+- **Track C (IP-Migration):** `docs/ip-plan.md` Phasen; cloudflared-Connectors landen dabei
+  in VLAN20; **TP5-Firewall ZULETZT** (erst wenn alle Origins/Connectors in VLAN20, sonst
+  killt die Trennung die Tunnel).
+
+## 6. Referenzen
+- Gesamtplan: `~/.claude/plans/du-wei-t-ja-inzwischen-piped-blanket.md`
+- `docs/teilprojekte.md` (kanonischer TP-Stand), `docs/ip-plan.md`, `inventory/bf.md` (teils stale)
+- `routeros/tp10-cutover-apply.rsc`, `routeros/fritzbox-bf-bridge-cutover-klickanleitung.md`,
+  `routeros/wan-cutover-runbook.md`
+- Portainer-Creds: `mcp/portainer/.env` · ap1 via mikromcp (default router)