admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b3b23c8b10537753c08a00753885dc1305f44059
bf-infra/docs/teilprojekte.md

19 KiB
Raw Blame History

BF-Netzwerk — Teilprojekte (kanonische Steuerung, Stand 2026-06-10)

Zweck: Das große Netz-Projekt in einzeln durchziehbare Teilprojekte (TP) zerlegt — jedes mit klarem Scope, aktuellen Entscheidungen, Abhängigkeiten und Status. Jedes TP ist so geschnitten, dass es eine frische Session mit sauberem Kontext straight abarbeiten kann. Architektur/Historie: ~/.claude/plans/ich-will-das-delegieren-atomic-sunrise.md.

Kanonisches VLAN-Modell (gültig — überschreibt ältere Tabellen)

VLAN Name Subnetz (Ziel) Zweck
10 MAIN 10.40.10.0/24 Trusted (Handy/Laptop/Apple Watch)
20 INFRA 10.40.20.0/24 NAS/VMs/Docker/HA
30 IOT 10.40.30.0/24 Smart-Home (HA-managed), Waage, Fitness-Tracker
40 MEDIA 10.40.40.0/24 Sonos, AppleTV, TV, VuPlus, Cast-Ziele (getauscht ggü. früher)
50 UNTRUSTED 10.40.50.0/24 Spielekonsole, eBook-Reader, Low-Trust-Internet
90 GUEST 10.40.90.0/24 nur Internet
99 MGMT 10.40.99.0/24 Switch/AP/Hypervisor-Mgmt
100 WAN (FB-Transfer) zur FritzBox
IP-Blöcke: .1–10 Router/APs (ap1=.1, ap2=.2) · .11–20 Switches (ALLNET=.11, Omada=.12). GW je VLAN = .1.

Ist-Stand (Kurz)

ALLNET-Core .11 (FW2.2.1, VLANs 10/20/30/40/50/90/99/100; GE1/GE2/GE8 Trunk; TP1 ✅ 2026-06-15). Omada-Switch .12 (adopted, TP2 ✅ 2026-06-15; Trunk-ALL auf P1+P2, Access-Profile auf P3-P8; Profile noch PVID=1 bis Omada-PVID-Fix). Omada-Controller .175 (DS923/macvlan, mbentley 6.2, 🟢 live). omada-mcp .176 (pve-LXC, StreamableHTTP, 🟢 live, 84 read-Tools; Controller-API v2 intern via christoph@emsenhuber.com). 2× hAP ax² (7.23.1): ap1 .1 (ALLNET P1) — TP4 ✅ 2026-06-15: L3-Router aktiv (VLAN-Subinterfaces, DHCP, DNS, NAT). ap2 .2 (Omada P2 — Trunk). FB6660 = Double-NAT-Upstream bis FB-Bridge-Mode. AP4.1 (FB-Bridge, 2026-06-16): Public-IP 86.56.201.104 per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live auf ap1 (routeros/wan-cutover-*.rsc + Runbook; scheduler-frei, Disk-Log wan-test.0.txt). ⚠️ FB-Bridge bleibt vorerst nur TEST (reversibel) — die FB hält 2 produktive VPN-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WG) → permanenter Bridge-Mode gegated auf TP10 (VPN-Migration auf 2× WG/ap1). Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Controller + omada-mcp 🟢. Nächster Schritt: Omada-PVID-Fix (MAIN→PVID10, INFRA→PVID20, untagNetworkIds bereinigen) + IP-Migration Geräte.

⚠️ HW-Constraint hAP ax²: 1 GB RAM, aber nur 128 MB Flash + KEIN USB → Container auf dem Router NICHT praktikabel. Folge: native RouterOS-Features bevorzugen (z.B. Built-in-mDNS statt Container); Container (mDNS-Reflector, BIND9-DNS, Omada-Controller) laufen auf NAS/pve, nicht am hAP.

Teilprojekte

TP1 — ALLNET Core-Switch finalisieren ▸ ✅ FERTIG (2026-06-15)

  • ✅ GE8 Trunk (native vlan1, tagged 10/20/30/40/50/90/99/100) — war bereits aktiv.
  • ✅ VLAN 40 umbenannt: UNTRUSTED → MEDIA (switch/cli/04-vlan50-media-untrusted.cli).
  • ✅ VLAN 50 angelegt + benannt: UNTRUSTED.
  • ✅ GE1/GE2 (AP-Trunks) um VLAN 50 ergänzt; GE8 auto-includiert (Trunk).
  • Ergebnis: Core trägt alle VLANs (10/20/30/40/50/90/99/100) an P1/P2/P8.

TP2 — Omada Access-Switch + Controller ▸ ✅ FERTIG (2026-06-15)

  • ✅ Omada Controller 6.2.10.17 auf DS923 (macvlan .175): omada/docker-compose.yml, Stack via Portainer endpointId=14. Wizard abgeschlossen (configured=true), Creds in mcp/omada/.env.
  • ✅ pve-mcp (samik081) in Claude Code eingetragen (~/.claude/settings.json, SSE .173:3000).
  • ✅ omada-mcp live auf pve-LXC (.126, endpointId=2), ipvlan-IP .176, Stack Id=200, URL in ~/.claude/settings.json.
    • Transport: StreamableHTTP http://10.40.41.176:3000/mcp (Health /health → 200). Settings-Bug (doppelter Eintrag) behoben 2026-06-15.
    • Auth: Omada Open API Client-Credentials. Creds in mcp/omada/.env. Token-Format: Authorization: AccessToken=<token> (nicht Bearer). OMADA_TOOL_CATEGORIES=all (alle 84 read-Tools aktiv; write für VLANs/Ports nicht im MCP implementiert → direkte Open API oder Controller-UI).
    • omadac_id=adbef8fa…, site_id=6a2fe68e….
  • ✅ VLANs im Controller: 1/10/20/30/40/50/90/99/100 — alle angelegt, Switch adopted (switchConsistent=true).
  • ✅ Port-Plan (ES208G, alle 8 Ports konfiguriert):
    Port Name Profil Gerät Status
    1 uplink Trunk-ALL → ALLNET GE8 ✅ korrekt
    2 ap2 Trunk-ALL hAP ax² #2 ✅ korrekt
    3 Port3 Access-MAIN — (frei) ⚠️ PVID=1
    4 dock/monitor Access-MAIN Docking-Station ⚠️ PVID=1 · Lifeline-Port, nicht anfassen
    5 drucker Access-MAIN Drucker ⚠️ PVID=1
    6 Port6 Access-MAIN — (frei) ⚠️ PVID=1
    7 macmini Access-INFRA Mac mini ⚠️ PVID=1 · fixe IP 10.40.41.x, nicht anfassen
    8 ds923+ Access-MAIN NAS (2. Port) ⚠️ PVID=1 · nicht anfassen
  • ⚠️ Profile-PVID-Constraint (bis TP4 offen): NAS, Mac mini und andere Geräte haben fixe IPs im Bereich 10.40.41.x (VLAN-1-Subnetz der FritzBox). Solange diese nicht auf VLAN-10/20-Subnetze migriert sind, muss nativeNetworkId=Default(VLAN 1) in allen Access-Profilen bleiben — sonst kein DHCP, kein Internet für diese Geräte. Fix nach TP4.
  • ⚠️ Bekannter Fehler untagNetworkIds (Analyse 2026-06-15 via Controller-API v2): Access-MAIN hat untagNetworkIds=[VLAN1, VLAN20, VLAN10] (3 untagged!) statt [VLAN10]. Access-INFRA hat untagNetworkIds=[VLAN20, VLAN1] statt [VLAN20]. Geräte erhalten Frames aus mehreren VLANs ungetaggt → Inter-VLAN-Tests verfälscht. Fix erst sinnvoll nach TP4 zusammen mit PVID-Korrektur.
  • Sichere Testports (kein kritisches Gerät): P3, P5, P6.
  • ✅ Portainer-Ablösung: Komodo empfohlen (einzige Option mit nativem MCP mcp-server-komodo). Eigener Task.
  • Abh. erfüllt: TP1 (GE8 Trunk ✅).
  • → TP4 wird vorgezogen: Alle VLANs im Controller definiert (status=false = kein Management-IP, normal). Traffic läuft noch auf VLAN 1 bis TP4 die L3-Interfaces + DHCP-Server je VLAN aktiviert.

TP3 — WLAN / CAPsMAN ▸ teilweise blockiert

  • bound-Problem sauber lösen (MikroMCP, doku-gegründet) → Test-WLAN „BF-Main" → SSID→VLAN-Datapaths.
  • DoH-Upstream auf APs = Cloudflare (/ip dns use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes). Rest der AP-Config noch ~default.
  • SSID-Strategie (Entscheid): NICHT naiv 1 SSID je VLAN + MAC-Filter. Besser: eine 802.1X-SSID mit dynamischer VLAN-Zuweisung (RADIUS, → TP8) für fähige Geräte; PSK-SSIDs für IoT/Guest/Media (Geräte ohne 802.1X). Hidden ≠ Sicherheit (nur Obscurity); MAC-Filter = schwaches Minimum, EAP-TLS/Zert deutlich besser (TP8).
  • SSID-Nomenklatur (Entscheid 2026-06-17): Prefix dirtyvader + -<vlanname> (lowercase), also dirtyvader-main (10), dirtyvader-media (40), dirtyvader-iot (30), dirtyvader-guest (90). INFRA (20) + MGMT (99) hidden (broadcast unterdrückt — Obscurity reicht gegen Script-Kiddies, kein Sicherheitsmerkmal). Prefix bewusst standort-neutral (kein Hinweis aufs Haus).
  • Mesh = NEIN (beide APs wired-trunk → Loop-Risiko via Router/LAN; Mesh nur sinnvoll ohne wired backhaul). Research bestätigt in TP-R.
  • Abh.: TP8 (für 802.1X). research: CAPsMAN-bound, mesh.

TP4 — Router-Cutover (hAP#1 = Router) ▸ ✅ L3-Infra FERTIG (2026-06-15) — FB-Bridge ausstehend

  • ✅ Bridge VLAN-Filtering aktiviert (vlan-filtering=yes); VLAN-Tabelle: VLAN1 untagged bridge+ether2, VLANs 10/20/30/40/50/90/99/100 tagged bridge+ether2.
  • ✅ VLAN-Subinterfaces: vlan10/20/30/40/50/90/99 auf bridge; je GW .1 (10.40.10.1 … 10.40.99.1).
  • ✅ DHCP: dhcp-v10…dhcp-v99 je auf eigenem VLAN-Interface, pools .100-.200, GW+DNS = VLAN-GW.
  • ✅ DNS: RouterOS-nativ, allow-remote-requests=yes. Upstream seit 2026-06-16: DoH Cloudflare Gateway (use-doh-server=https://px35ynlol3.cloudflare-gateway.com/dns-query, verify-doh-cert, servers=1.1.1.1 als Bootstrap; FB-Upstream abgelöst). Statische Einträge für alle Infra-Hosts unter bf.lan (13 Einträge, Transition-IPs bis PVID-Fix).
    • ⚠️ Auto-Suffix .lan (RouterOS-Einschränkung, kann nicht auf leer gesetzt werden) — TP5-Cleanup.
  • ✅ NAT: srcnat masquerade out-interface=bridge (ap1 → FB → Internet, Double-NAT Interim-Lösung).
  • ✅ Routing-Tabelle: 0.0.0.0/0 via 10.40.41.254%bridge; alle 7 VLAN-Subnetze als Connected-Routes aktiv.
  • ⏳ FB-Bridge-Mode (AP4.1) — ether1 als WAN ist vorkonfiguriert (DHCP-Client, NAT out=ether1, Fallback-Route bridge distance=2). Test 2026-06-16: Public-IP 86.56.201.104 per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live (routeros/wan-cutover-test.rsc/-macclone-test.rsc + wan-cutover-runbook.md; scheduler-frei wg. device-mode, Disk-Log wan-test.0.txt). User-Befund „nach Gateway .1 ging nichts mehr" → Root-Cause offen (Hypothese DoH-Bootstrap). ⚠️ Bridge bleibt nur TEST/reversibel; permanenter Umstieg gegated auf TP10 (FB hält bis dahin 2 VPN-Tunnel + Telefon). Bis dahin: Double-NAT via bridge (funktioniert).
  • DNS-Entscheidung (Technitium und externer BIND verworfen): RouterOS-DNS als Resolver, keine DHCP→DNS-Auto-Registrierung (soweit möglich). Infra-Hosts als statische /ip dns static-Einträge unter bf.lan; dynamische Clients bewusst ohne Namen. Filtering/DNSSEC via DoH-Upstream (TP3). HA: 2. Resolver auf ap2, statische Einträge beidseitig pflegen.
  • Abh.: TP1 ✅. TP3-Abhängigkeit entfällt (WLAN läuft weiterhin über FB bis TP3).
  • Ermöglicht jetzt: PVID-Fix in Omada-Profilen (MAIN→PVID10, INFRA→PVID20), untagNetworkIds-Bereinigung, DHCP-Reservierungen für NAS/macmini/pve auf neue VLAN-Subnetze migrieren.

TP5 — Firewall & Inter-VLAN-Policy

  • Deny-by-default + least-privilege. MAIN→INFRA nur Whitelist-Dienste; MAIN↔MEDIA allow (+mDNS); UNTRUSTED/GUEST nur Internet; MGMT isoliert; Router-input gehärtet.
  • IoT→INFRA-Rückmeldung (deine Frage): IoT darf aktiv zu INFRA-Diensten initiieren — Firewall-Allow IoT→INFRA NUR auf MQTT (1883/8883), HA-API, InfluxDB (8086) o.ä.; Antworten via established/related; IoT→MAIN bleibt deny. So pusht ein Sensor Daten an HA/MQTT/Influx, ohne dass IoT „frei" ist.
  • Abh.: TP4.

TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ DAS Ziel

  • CAKE am WAN-Upload (~85–95 % Linerate) → Bufferbloat weg. Verifikation waveform.com → A/A+.
  • ⚠️ Vor „Erfolg": A/B-Test, denn Kollegen-Befund sagt DE-Calls = internat. Pfad AT↔DE, nicht Heimnetz → ggf. WARP statt/zusätzlich CAKE. Nicht am einen Telefonat festmachen.
  • Abh.: TP4.

TP7 — Media-Discovery (mDNS) für VLAN 40 ▸ ✅ Kern FERTIG (2026-06-17) — docs/tp7-mdns.md

  • ✅ Built-in mDNS-Repeater aktiv: /ip/dns set mdns-repeat-ifaces=vlan10,vlan40 (RouterOS 7.23.1). MAIN↔MEDIA. Reversibel (Feld leeren). Realbestand: MAIN=MacBook, MEDIA=2× SonosZP .199/.200.
  • 💡 TP5-Abhängigkeit entschärft: Repeater re-originiert mDNS vom Router (input→output), kein Client-forward → Deny-by-default blockt die Discovery nicht. TP5 muss nur (a) MAIN↔MEDIA-Nutzdaten-forward erlauben (ohnehin geplant) und (b) beim Input-Härten UDP 5353 von vlan10/vlan40 an den Router offenlassen.
  • ⏳ Funktionaler Test ausstehend: Sonos-App/AirPlay auf MAIN-Client → Sonos müssen erscheinen.
  • SSDP/Cast (UDP 1900) deferred: nur mDNS nativ; SSDP bräuchte Reflector-Container auf NAS/pve (nicht am hAP). Für Sonos/AirPlay (mDNS) nicht nötig. IOT bewusst nicht im Repeater (Scope=MAIN↔MEDIA).
  • Abh.: TP4 ✅. TP5 = Folge-Anschluss (Firewall-Holes), nicht blockierend für den Kern.

TP8 — Identity & Access-Control ▸ research-gated

  • RADIUS = FreeRADIUS auf der NAS (✏️ User-Manager v5 kann KEIN LDAP → openldap nur via FreeRADIUS anbindbar).
  • EAP-TLS (Zert) je Gerät + dynamische VLAN-Zuweisung (RADIUS-Attribut Tunnel-Private-Group-ID). Einfachste Heim-Alternative: pro VLAN eine SSID mit WPA3-PSK (kein RADIUS) — Abwägung Komfort vs. Admin-Aufwand.
  • Abh.: TP3. (Research erledigt, s. TP-R.)

TP9 — Gateway-/Router-HA ▸ research-gated

  • „Was, wenn ap1 ausfällt?" → VRRP löst Gateway-Failover je VLAN ~gratis (kreuzweise Master/Backup). ⚠️ Haken (nicht Last): DHCP/Firewall/NAT/DNS müssen auf BEIDEN APs identisch gepflegt sein, sonst „Gateway up, Internet tot". Empfehlung: VRRP nur für MAIN/INFRA, sonst ap2 als Kalt-Ersatz + Backup. DHCP/DNS schon redundant (Split + 2 Resolver).
  • Abh.: TP4. (Research erledigt, s. TP-R + Config-Skizze im Report.)

TP10 — Multi-Site VPN ▸ 🅿️ VERTAGT — gebündelt mit Bridge-Cutover (docs/tp10-vpn-migration.md)

  • 🅿️ ENTSCHEIDUNG 2026-06-17: TP10 vertagt und mit dem permanenten FB-Bridge-Cutover gebündelt (statt Parallelbetrieb vorher). Begründung: VPN-auf-FB und FB-Bridge schließen sich aus (Bridge = Modem = keine VPN- Terminierung) → die Migration MUSS am Bridge-Tag passieren, nicht davor. Macht man beides in einem Cutover, hat ap1 dann die echte Public-IP → kein FB-Port-Forward-Umweg nötig (Spokes zeigen direkt auf ap1/DDNS). FM-PoC ✅ hat den WG-Spoke-Fix bewiesen → Migration de-risked. Park-Zustand ap1: Peers disabled, WG-Routen entfernt (FM/DW laufen wieder über die FB), wg-hub bleibt (Key erhalten), Firewall-Regeln bleiben (TP5-Vorarbeit). Beide VPN vorerst über die FB (10.40.41.254): FM = IPsec, DW = FB-WG.
  • ✅ Phase A (2026-06-16): ap1-WG-Hub wg-hub live (UDP 51821, MTU 1412, keine IF-IP). 2 Peers vorkonfiguriert: FM 10.101.0.0/24 (war IPsec) = peer1 · DW/Geli 192.168.178.0/24 CGNAT (war WG) = peer2. Routen + Firewall (input/forward) gesetzt; NAT braucht nichts (Egress wg-hub ≠ masq-Interface). Hub-Pub P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=, Endpoint xvbeo64jqlqd9gfo.myfritz.net:51821. Spoke-Configs in routeros/.secrets/wg-{fm,dw}.conf (Private-Keys, nicht im Git). FB-Portfreigabe 51821→ap1 gesetzt.
  • ⛔→💡 Phase-B-Versuch FM gescheitert, ROOT CAUSE gefunden (2026-06-16): .conf importiert, IPsec voreilig aus → FM weg, revertiert. Echt-Host-Test (WG reaktiviert): Ping realer Host 10.101.0.10 → Antwort aus 10.255.255.2 → FB-NAT bestätigt. Ursache: unsere .conf nutzte eine Transfernetz-Adresse (10.255.255.2/32) → FRITZ!OS behandelt das als Einzelgerät → masqueradet. AVM nutzt Proxy-ARP, KEIN Transfernetz → FB-WG-Interface-Address muss die FB-LAN-IP sein (FM 10.101.0.254/24, DW 192.168.178.1/24), Transfernetz streichen, AllowedIPs 10.40.0.0/16. → Ansatz machbar. Configs routeros/.secrets/wg-{fm,dw}.conf korrigiert. FM aktuell auf IPsec (Sicherheitsnetz); ap1-WG-Hub bleibt (inert).
  • ⏳ Resume = Bridge-Tag (ein Cutover): Liwest-Anruf → FB wird Modem, ap1 = Edge mit Public-IP. Dann WG-Hub auf ap1-Endpoint (DDNS) aktivieren, Spokes neu anlegen via Klickanleitung routeros/fritzbox-wg-lanlan-klickanleitung.md (FB-LAN-IP als Interface-Adresse!), Echt-Host-Test gegen 10.101.0.10. DW: kein Parallelbetrieb möglich (Geli-FB lehnt 2 WG zum selben Zielnetz ab) → direkter Swap via temporärem Admin-Tunnel (anderes Zielnetz, da CGNAT-Fernzugang/MyFRITZ fehlt). Spoke-Keys/-Configs bleiben in routeros/.secrets/wg-{fm,dw}.conf.
  • Empfehlung: Hybrid — WireGuard Site-to-Site-Backbone (BF/hAP = WG-Hub, FM/DW = FritzBox-Spokes, hub&spoke, KEINE Zusatz-HW) + WARP für Remote-User (ergänzt, ersetzt nicht).
  • WARP kann FBs NICHT direkt ansprechen → bräuchte Connector-Host hinter der FB (an reinen-FB-Standorten FM/DW unattraktiv).
  • Vorab-Check (User, entscheidend): WAN je Standort — public/dynamisch (OK: DynDNS/MyFRITZ) vs. CGNAT/DS-Lite am BF-Hub (= K.O. → dann CF/WARP-Pfad, CGNAT-immun).
  • WG-Gotchas: keine IP aufs WG-IF (MikroTik), AllowedIPs=Tunnel+LAN-CIDRs, MTU 1412, Keepalive 25. ap1 hat noch KEIN WG (Neuaufbau).
  • IST-Zustand (User 2026-06-16): Die BF-FritzBox terminiert AKTUELL 2 produktive Site-to-Site-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WireGuard). Migrationsziel: 2× WireGuard mit Hub auf ap1, FB-Standorte als Spokes.
  • ⚠️ TP10 ist Voraussetzung für den permanenten FB-Bridge-Mode (AP4.1/TP4). Solange die FB die 2 Tunnel terminiert, muss sie Router bleiben → FB-Bridge nur reversibel testbar, nicht dauerhaft.
  • Abh.: WAN-Check; Hub sinnvoll nach TP4 (Router-Cutover). Blockiert: permanenten FB-Bridge-Mode.

TP11 — Monitoring & Mgmt-Control-Plane ▸ research-gated

  • MikroMCP + omada-mcp + SNMP/icinga-mikrotik, RoMON, NTP, E-Mail-Alerts, Netwatch. → Teil von docs/research/routeros-capabilities.md.

TP12 — IPv6 (intern + extern, 3 Standorte) ▸ research-gated

  • Konzept für FM/BF/DW. → TP-R.

TP13 — „Botschafts-WLANs" ▸ fun, low-prio

  • Nutzlose SSIDs mit Botschaft („Kanal 500 bitte nicht nutzen"), offenes WLAN mit Captive-Portal das auf statische Info-HTML zeigt (Nachbarschafts-WLAN-Tuning, Auto-Kanalwechsel). Idee: wer's sieht, kann auch stören → Infoseite = beste Adresse. ⚠️ Recht prüfen (Impressum/TMG, Störerhaftung bei offenem WLAN — User privat). RouterOS-Hotspot/Captive-Portal kann das.

TP-R — Router-Capabilities-Sweep ▸ FERTIG (docs/research/routeros-capabilities.md)

  • Leitsatz: nativ vor Container, NAS vor Router (128MB-Flash-Limit).
  • Sofort nativ (~0 RAM): RoMON · Netwatch · Scheduler + Auto-Backup/Mail · SNMP→externes Monitoring · mDNS-Repeater · spectral-scan · CAPsMAN + 802.11r/k/v (Fast-Roaming statt Mesh) · Back-to-Home/WireGuard.
  • Auf NAS: FreeRADIUS(+LDAP) · NPM · icinga/Grafana · CF-Tunnel.
  • Weglassen: LoRa (keine HW) · OpenFlow · CALEA · ZeroTier (CPU-Fresser bis ~60 % → WireGuard) · lokales dude.
  • ✏️ Korrektur Reverse-Proxy: RouterOS 7.22+ HAT einen nativen (/ip/reverse-proxy, ACME/SNI) — aber ersetzt NPM NICHT (kein WebSocket/gRPC/Sticky, nur IPv4-Backends, TLS frisst Router-CPU) → NPM bleibt auf NAS.
  • Speist TP8/9/11/12.

Reihenfolge / Abhängigkeiten

  1. Jetzt: TP1 (GE8) → TP2 (Omada Controller). ✅ erledigt 2026-06-15.
  2. TP4 (Router-Cutover L3-Infra). ✅ erledigt 2026-06-15. FB-Bridge-Mode noch offen (physisch).
  3. Jetzt: Omada-PVID-Fix — Omada Access-Profile korrigieren (PVID 10/20, untagNetworkIds bereinigen, sicher P3/P5/P6 zuerst), dann IP-Migration NAS/macmini/pve auf VLAN-Subnetze + DNS-Einträge updaten.
  4. Dann: TP5 (Firewall/Deny-by-default) → TP6 (QoS/CAKE) → TP7 (mDNS) ✅ vorgezogen 2026-06-17 → TP3 (WLAN/CAPsMAN). ⚠️ TP5 muss die TP7-Firewall-Holes mitnehmen (s. TP7: MAIN↔MEDIA-forward + UDP 5353 input).
  5. Nachgelagert/Research-getrieben: TP8 (Access), TP9 (HA), TP10 (VPN), TP11 (Monitoring), TP12 (IPv6), TP13 (Spaß).
Reference in New Issue View Git Blame Copy Permalink