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