77 lines
5.3 KiB
Markdown
77 lines
5.3 KiB
Markdown
# Ü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)
|