Incident-Nachgang 2026-07-16: ICMP über den cloudflared-WARP-Pfad ist strukturell
kaputt (TCP ok überall, Ping fm 36%/bf 100%/dw 100% Loss) — cloudflared ist ein
QUIC-L7-Proxy, kein WireGuard. Richtungsentscheid: Private Access (unterwegs ->
10.40.0.0/16 inkl. ICMP) wandert vom cloudflared-Proxy auf einen nativen
Cloudflare-Mesh-Node (WireGuard) auf ap1 -- kein Container/TUN/LXC/neue HW
(RouterOS-Container haben kein /dev/net/tun -> hAP ax3 löst es nicht, zudem WiFi6).
Public-FQDNs bleiben unverändert auf dem cloudflared-3-Tunnel-HA.
- Neu: docs/tp16.1-warp-mesh-native-ap1.md (Konzept + vollständiges Runbook +
gemessener Account-Ist-Stand, Team emsenhuber.cloudflareaccess.com)
- cf-tunnel-mapping.md §13: ICMP-Dreiländer-Befund; "bf-pve wegen USV" REVIDIERT
(Begründung invertiert -- bf-pve-Connectoren laufen auf NAS+macmini, nicht pve)
- cf-tunnel-mapping.md §14 + teilprojekte.md TP16.1: Richtungsentscheid dokumentiert
Scharfschalten = eigene Session (CF-Prereqs sind account-weit, treffen Live-WARP).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Incident 2026-07-16: User unterwegs, keine BF-IPs mehr über WARP. Root Cause:
cloudflared-bfnas/-bfpve auf macmini flappten unter QUIC/UDP (Docker-Desktop-
Bridge-NAT) -> bf-nas/bf-pve von 2 auf 1 Connector degradiert. Fix: beide auf
TUNNEL_TRANSPORT_PROTOCOL=http2 umgestellt, rollend, wieder volle HA.
Nebenbefund per Audit-Log: User hatte die WARP-Private-Network-Route selbst
neu angelegt, zeigt jetzt auf bf-pve statt bf-nas. Bewusst so belassen -
pve ist USV-gepuffert, NAS/macmini nicht. cf-tunnel-mapping.md §11 damit
überholt, §13 als neue Baseline.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vmbr0.20 (kaputte Netzadresse statt Host-IP) auf 10.40.20.100/24 korrigiert,
Default-GW live geflippt (ifreload -a, kein Reboot). CF-Ingress bf-pve
(pve/j44d6tua-ssh) + ap1-DNS nachgezogen; dabei Alt-Bug gefunden und gefixt
(pve-mcp.bf.lan zeigte noch auf .41.173 statt .20.173).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vw von bypass/everyone auf non_identity(Heim-IP)+allow(email:christoph) umgestellt
(reusable-Policy via App-PUT detacht). Neuer 🔴 Fund dokumentiert: Wildcard
*.emsenhuber.net login_method:github/google = jeder Eingeloggte erreicht alles
(user-gated). hass-400 = HA-Origin (nicht Access), gateway-dw WG offen. §10.6.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Root-Cause endgültig (User-Diagnose bestätigt): ein cloudflared ist blind NUR
für macvlan/ipvlan-Container auf seinem EIGENEN Host → mehrere Connectoren auf
1 Tunnel + Round-Robin = 1/N garantierte 1033 ("jeden 3. Schuss eine Niete").
Kein Route→Connector-Pinning innerhalb eines Tunnels → HA nur über getrennte
Tunnel: reziprokes Per-Host-Design (jeder Dienst von den anderen Hosts bedient,
3 Tunnel/2 cloudflared je Host = voll HA gegen Single-Host-Ausfall).
- cf-tunnel-mapping.md §9: Invariante + Live-Inventory v119 (Access-Modi,
DOWN-Origins pbs/nginx-bf/hermes×2) + Ziel-Design + Umsetzungsreihenfolge;
Abschnitte 1-8 als Historie markiert.
- teilprojekte.md TP16 umgeschrieben: Root-Cause, reziprokes HA, Access-Strang
(hass-400=CF-Access→WARP, vw=bypass→schützen), Status "dokumentiert,
Umsetzung = eigene Session".
- Reine Doku, keine Tunnel-/DNS-/Container-Änderung.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 6 NAS-Origins .41→.20 repointet (ha-mcp, NAS-ssh, gitea, vw, grafana, pve-mcp), v115→v116.
- Befund: pve-Connector erreicht VLAN20 (vw 200 via Tunnel); 502 direkt nach Ingress-PUT = transient.
- grafana 502 = Container exited, kein Routing-Problem. Kein pve-Static-Route nötig.
- Stufe-4-Connector-Vantage löst sich mit pve→VLAN20 (PVID1-Cutoff).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- docs/cf-tunnel-mapping.md: Single Source of Truth zur #1033-Diagnose
(bf-Tunnel = Round-Robin über 3 Connectors macmini/pve/NAS)
- mcp/cloudflare/: README + .env.example (echtes .env via mcp/.gitignore ausgeschlossen)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
