Ü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)

Accounts/Tunnel auflisten via mcp__cloudflare__* → Tunnel-ID(s), Status, aktive Connector-Connections (cfd_tunnel). Bestätige: genau 1 Tunnel, welche Connectors live.
Ingress/Config auslesen → vollständige public-hostname → service (IP:Port)-Liste.
DNS prüfen → welche Hostnames als CNAME auf <tunnel-id>.cfargotunnel.com zeigen.
Reachability-Map bauen: je Origin → von NAS routbar? von pve routbar? → asymmetrische Routen markieren (= #1033-Verursacher).
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)

5.3 KiB Raw Blame History Unescape Escape