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>
- pve-mcp „Failed to connect" = mcp-pve 0.4.8 kann nur 1 MCP-Session
("Server already initialized") → Upgrade 0.6.1 (Per-Session), ✔ Connected.
omada-mcp war/ist gesund (frische Session-ID pro Init).
- Kollateral: VLAN20-Host-DNS auf NAS+LXC zeigte noch auf totes .41.254
→ docker-pull scheitert; LXC pct set .20.1, NAS Synology-DHCP-DNS-Falle.
Neuer Gotcha in CLAUDE.md.
- TP16 (neu, hochdringlich): FQDNs via CF „sehr unsicher" = #1033-Round-Robin
zurück; Live-Snapshot 2026-07-10: bf-Tunnel 2 statt 3 Connectoren, alle
frisch (2026.7.1), Origins nach VLAN20-Move erneut asymmetrisch zu auditieren.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Requirements/Architektur zur Ablösung von ALLNET-Core + 2 Branch-Switches:
Strom-Baseline, Energieeffizienz, zentrales Management, DC-USV-Konzept.
Status: Entwurf; verweist auf TP15 in teilprojekte.md.
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>
Diagnose der Docker-Container-Fehler nach NAS-NIC-Wechsel auf VLAN20:
- Config-Only-Macvlan-Falle (Portainer 2-Schritt, Driver=null → kein Attach)
- Macvlan-Parent ovs_eth0 exklusiv → default_external muss weg für vlan20
- default_internal (172.18) existiert nicht mehr (Range von gitea_default belegt)
RUNBOOK: IP-Mapping .41.X→.20.X (Oktett behalten), Phase-A-Teardown,
Post-Steps (ap1-DNS, CF-Ingress-Repoint, omada-Inform .20.175), CF-Access
claude-mcp-Profil-Status.
Stack-Compose-Files + Inspect-JSONs (docs/nas-vlan20/stacks/, inspect_*.json)
via .gitignore ausgeschlossen — enthalten Live-Secrets.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
TP3.2 = P750W/Discovery erledigt; offene Coverage-Kur (Dead-Spot-Map →
Platzierung/3.AP/Outdoor, Nachbar-Kanal-Scan, INFRA-auf-ap1) als
kaltstart-taugliches TP3.3 für die Fortsetzungs-Session ausgelagert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
macOS-Desktop-Sonos-App braucht SSDP über VLAN-Grenze; iOS/HA reichen für den
Alltag nicht, sobald der User die Desktop-App nutzen will. Reflector-Container
auf NAS/pve (nicht am hAP), Scope vlan10↔vlan40.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Alle Sonos jetzt auf VLAN40 (10.40.40.0/24), IPs per MAC DHCP-reserviert.
Korrigierte IPs (Arbeitszimmer .199/.200 → .191/.192, Arc hält .199).
Discovery-Merkregel dokumentiert: iOS-App + Home Assistant = mDNS/zeroconf
(_sonos._tcp.local.) → über Repeater lösbar; macOS-Desktop-App = SSDP
(quert VLAN nicht, kein Reflector gebaut); Spotify = Cloud.
Passend zur Router-Änderung (nicht im Repo): mdns-repeat-ifaces=
vlan10,vlan20,vlan40 (vlan20 für HA ergänzt) + forward/input-Regeln
vlan20<->vlan40. HA discovert per zeroconf selbst → self-healing der IPs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Root cause: ap2 (CAP, local forwarding) hatte bridge vlan-filtering=no →
datapath.vlan-id wurde nie getaggt → alle WLAN-Clients (main/media/iot/…)
egressten ungetaggt in VLAN1 → OG-iPhone-Drops beim Roaming ap1↔ap2.
Fix wie ap1: VLAN1 untagged=bridge,ether2 (Mgmt), 10/30/40/50/90 tagged
auf ether2 + wifi1/wifi2 als tagged-Member (nur Master-Radios sind
Bridge-Ports, CAPsMAN legt das auf dem CAP nicht an). As-built +
teilprojekte.md TP3.1 + CLAUDE.md-Gotcha. OG-Funktionstest offen (User).
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>
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>
peer dw gesund, aber dw→BF stumm: .41-Infra hat FB-Default-GW (ap1-DHCP
auf bridge disabled) → Antworten an Spoke-Netze landen bei der FB ohne
Route → Blackhole. "Funktionierende" Gegenrichtung war WARP, nicht Tunnel.
Fix (Interim, Double-NAT): 2 Statikrouten auf der BF-FB,
10.95.10.0/24 + 10.101.0.0/24 → 10.40.41.1 (ap1). Transparent, FM mit
abgedeckt. DW ohne WARP getestet ✅. Beim Bridge-Cutover obsolet.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DW/Geli on-site abgeschlossen (2026-06-27): Geli auf 10.95.10.0/24
renumbert, FB-WG single 10.95.10.1/24, alter FB↔FB-WG geswappt.
End-to-End verifiziert (macmini/Linz → Gelis 24/7-APs .246/.247,
echte LAN-IPs, kein 10.255.255.x-NAT-Leak). FM+DW live im Double-NAT.
Doku/Status von "🅿️ vertagt/geparkt" auf Ist-Stand gezogen, Bridge-Gate
an allen Stellen aufgelöst, stale 192.168.178-Referenzen bereinigt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- tp10-vpn-migration.md zur Single Source of Truth umgeschrieben: widerspruechliche
alte Transfernetz-Tabelle/MyFRITZ-Endpoint entfernt, aktueller Stand (Proxy-ARP
LAN-IP, DDNS bf4.emsenhuber.net, dual-range DW, geparkter ap1-Hub, vertagt+
gebuendelt mit Bridge-Cutover, v6-Variante) konsolidiert.
- teilprojekte.md TP10-Eintrag von verbose Saga auf kompakten Status + Verweis gekuerzt.
- tp10-context-digest.md neu: ultrakompakter Handoff (lokal via Ollama nemotron-3-nano:4b
destilliert, fakten-gegengeprueft) fuer kleines Kontextfenster.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
/ip/dns mdns-repeat-ifaces re-originiert mDNS vom Router (input→output),
daher unabhängig von TP5-forward. Verifikation + Rollback + offene TP5-Punkte
(forward MAIN↔MEDIA, input UDP 5353) und SSDP/IOT-Defer dokumentiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- mcp/sonos/sonos-inv.py: SSDP + ZoneGroupTopology-API, Seed-je-VLAN-Partition,
--json / --verify. Kein MCP-Container (User-Entscheid), kein Daemon, stdlib-only.
- docs/sonos-inventar.md: Bestand + Migrationsklassen.
- Kernbefund: echter WLAN-Umzug = 6 Geräte (3× One SL + HT-Bond Arc/Amp/Sub);
Schlafzimmer-Paar nur Switch-Port; Arbeitszimmer-Paar fertig. Alle S2 →
:1400/wifictrl tot → Umzug via TP3-Cutover, nicht am Gerät.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Entscheidung: TP10 nicht mehr als Parallel-Migration vorab, sondern zusammen
mit dem permanenten FB-Bridge-Cutover. Grund: VPN-auf-FB und FB-Bridge
schließen sich aus (Bridge = Modem = keine VPN-Terminierung) -> Migration muss
am Bridge-Tag passieren; dann hat ap1 die echte Public-IP -> kein
Port-Forward-Umweg, Spokes zeigen direkt auf ap1/DDNS. FM-PoC hat den
WG-Spoke-Fix bewiesen (de-risked).
Park-Zustand ap1: Peers disabled, WG-Routen entfernt (FM/DW wieder über die FB),
wg-hub bleibt (Key erhalten), Firewall bleibt (TP5-Vorarbeit). Beide VPN vorerst
über die FB: FM=IPsec, DW=FB-WG. Resume = Bridge-Tag (Klickanleitung,
FB-LAN-IP als Interface-Address).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Gelis CGNAT ist nur v4 → ihre FB über natives v6 erreichbar (Port offen).
WARP (schon im Einsatz) liefert Christoph outbound-v6 trotz Liwest-v4-only.
- PoC = ad-hoc Fernwartung; Daueform = direktes WG ap1↔Geli-FB über echtes
v6 (HE-6in4, da Liwest auch mit Fiber kein v6) statt Hub-Spoke-Gymnastik.
- Endgeräte (Note10, Cudy) bleiben v6-agnostisch: v6 nur äußerer Transport,
LAN bleibt IPv4. Nicht für Telefonie.
- teilprojekte.md: TP10 von ⏸ PAUSIERT auf 🅿️ VERTAGT (Bridge-Cutover-Bündelung).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
FM-Cutover-Versuch gescheitert: .conf importiert, Handshake grün, IPsec voreilig
deaktiviert -> FM unerreichbar. Diagnose-Fehler: nur FB-eigene .254 gepingt (FB
antwortet aus Tunnel-IP 10.255.255.2 -> OS verwirft); echte FM-LAN-Hosts nie
getestet -> NAT-These unbewiesen. Research (Bouni) bestätigt FB<->MikroTik
LAN-LAN ohne NAT ist machbar. FM auf IPsec zurückgestellt; ap1-WG-Hub bleibt inert.
- routeros/fritzbox-wg-lanlan-klickanleitung.md: Diagnose->Fix->Verify, Echt-Host-
Test ZUERST (10.101.0.10, nicht .254), IPsec bleibt Sicherheitsnetz.
- teilprojekte.md / tp10-vpn-migration.md: Status ⏸ + Incident dokumentiert.
Spoke-.conf mit Private-Keys bleiben gitignored in routeros/.secrets/ (die
ungetrackten Duplikate in routeros/ Root sind bewusst NICHT committet).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Verifiziert am VLAN1-Host (FB-nah): FB annonciert 2002::-Prefix per RA,
curl -6 klappt, ping6 Google v6 = 100% Loss (flatterhaftes 6to4).
Intern NICHT durchgereicht: Mac mini (VLAN20 hinter ap1) v6-los —
ap1 kein RA/DHCPv6-PD, Branch-Switch nicht v6-konfiguriert,
Core-Switch v6-Fähigkeit unklar. 6to4 untauglich für RT-Medien;
saubere Alt = 6in4-Tunnelbroker (HE). Geli-CGNAT-Bypass unberührt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Liwest bietet kein natives IPv6 (techn. Support bestätigt).
- Christophs 6to4-Versuch am Mac mini/LAN NICHT nutzbar (stf0 down,
keine globale v6, kein v6-Route/Internet) → kein funktionierendes
v6 auf Christophs Seite; ap1/TP4 bleibt v4-only.
- 6to4 = legacy/relay/hohe Latenz → keine Basis für Echtzeit-Medien;
saubere Alt bei Bedarf = 6in4-Tunnelbroker (HE).
- Geli-seitiger CGNAT-Bypass (ihr natives v6, Telegram-Reflector-Leg)
bleibt davon unberührt — der billige Hebel braucht Christoph-v6 nicht.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- pve: Hypervisor zählt zu INFRA (User-Entscheid) → 10.40.20.100 (VLAN20),
MGMT/VLAN99 = nur noch Switch/AP-Mgmt.
- Mac mini ✅ live auf 10.40.20.167 (Omada Access-INFRA ohne VLAN1).
Kontext (live, nicht im Repo):
- Omada: Access-IOT/-UNTRUSTED/-GUEST/-MGMT Profile angelegt (Satz komplett).
- ap1 DNS: macmini.bf.lan → 10.40.20.167.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Eigenständiges Arbeitspaket: finale statische IPs je Gerät in den
Ziel-VLANs (INFRA 20 / MGMT 99), Host-Oktett beibehalten, Vorschläge
zum Bestätigen.
Kontext (live in dieser Session umgesetzt, nicht im Repo):
- Omada PVID-Fix Teil 1: P3/P6 Sonos→Access-MEDIA (VLAN40),
P5 Drucker→Access-MAIN10 (VLAN10).
- ap1 srcnat: accept 10.40.0.0/16 vor Masquerade → Inter-VLAN ohne SNAT.
- Voraussetzung erfüllt: VLAN1↔VLANx-Routing via statischer FB-Route → ap1.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
