diff --git a/docs/handoff-20260831-tp16.3-vorort-session.md b/docs/handoff-20260831-tp16.3-vorort-session.md index b954b04..7a2a74d 100644 --- a/docs/handoff-20260831-tp16.3-vorort-session.md +++ b/docs/handoff-20260831-tp16.3-vorort-session.md @@ -84,13 +84,13 @@ kann nur vom Server kommen, die Firewall-Freigabe trägt also. cloudflared schic `ft-over-ds=no`, Soll `yes` (`ft=yes` ist korrekt). **Kam mit dem 7.24.1-Upgrade.** Braucht eine Entscheidung — Gerät korrigieren *oder* neuen Wert zum Soll erklären — plus Re-Provisionierung der CAPs. ⚠️ **Kein Re-Baseline ohne Entscheid**, das macht die Drift-Erkennung wertlos. -2. 🆕 **TP-Vorschlag (Christoph 2026-08-31, noch nicht angelegt): dedizierter untagged-VLAN99-Port - auf beiden Switches.** Auslöser ist eine reale Beobachtung: **beim Core-Neustart war `crs326-branch` - nicht mehr erreichbar**, weil das Management über den Core läuft. Ein Out-of-Band-Zugang je Switch - (ein Port, untagged VLAN99, Laptop direkt) macht den Branch unabhängig vom Core. - **Bewusst nicht eigenmächtig angelegt** (TP-Management-Konvention: vorschlagen, abstimmen, dann - anlegen). ⇒ Nummer vergeben und Abschnitt schreiben, sobald Christoph zustimmt. - 💡 Berührt TP16.3 direkt: die Vor-Ort-Session rebootet dreimal Geräte, deren Mgmt am Core hängt. +2. 🆕 **[TP37](teilprojekte.md#tp37) — OOB-Management, angelegt 2026-08-31.** Je ein untagged-VLAN99-Port + auf beiden Switches (Kandidat `ether23`, auf core **und** branch frei). Auslöser: beim Core-Neustart + war `crs326-branch` nicht erreichbar, weil sein Mgmt **ausschließlich** über den Core läuft. + 🔴 Nebenbefund mit eigenem Gewicht: **der Branch hat gar keine `input`-Firewallregeln** — sein Schutz + ist heute allein die Erreichbarkeit über den gehärteten Core. + 💡 **Berührt diese Session, ist aber keine Voraussetzung:** hier rebooten dreimal Geräte, deren Mgmt + am Core hängt. Wer vor Ort ist, kann `ether23` schon mal beschriften — gebaut wird TP37 separat. 3. 🟡 **`mcp/mikromcp/config/routers.yaml` hält `rosVersion: "7.24"`** für alle fünf — jetzt `7.24.1`. ⚠️ **Die Datei liegt auf `main`, nicht auf diesem Branch** (der Worktree hat eine ältere Kopie **ohne** ap3). Der Fix gehört auf `main`, nicht hierher — sonst gibt es einen Konflikt. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index fdbd37f..d5c336d 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -40,6 +40,11 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d unterstellte einen Registry-Pull (`fetch: no` auf ap1/ap2) und enthielt eine **falsche** Firewall-Freigabe-Behauptung. **CF-Stand:** `bf-public` `inactive` / 0 Connectoren; die vier öffentlichen Namen laufen noch über bf-mm/bf-nas/bf-pve **an Caddy vorbei** direkt aufs Backend. +- 🆕 **TP37 angelegt (2026-08-31):** OOB-Management — je ein untagged-VLAN99-Port auf beiden Switches. + Auslöser: beim Core-Neustart war `crs326-branch` nicht erreichbar, weil sein Mgmt **ausschließlich** + über den Core läuft (`vlan99` dort `tagged=ether1,ether24,bridge`, kein untagged-Member). + 🔴 **Nebenbefund mit eigenem Gewicht: `crs326-branch` hat gar keine `input`-Firewallregeln** — sein + Schutz ist heute allein die Erreichbarkeit über den gehärteten Core. Das ist die Hauptauflage des TPs. - 🆕 **ROS-Upgrade 7.24.1 auf allen fünf (2026-08-31, User).** In Nautobot nachgezogen: **ap1** stand als einziges Gerät noch auf `7.24` (die anderen vier waren schon richtig) ⇒ auf `7.24.1` gesetzt. 🔴 **Eine Drift kam mit dem Upgrade: `crs326-core` / `wifi-security`** — `sec-main` hat am Gerät @@ -252,6 +257,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na > | TP34 | 🔜 | Caddyfile via Nautobot/GC (Stub, Inventur-Handoff 2026-08-27) | — | > | TP35 | ⏳ | MCP-Schichtung + 3-Schicht-CLAUDE.md + Backup-Guard (Schicht 1+3+6 ✅) | — | > | TP36 | 🔜 | SSoT via Nautobot für teilprojekte.md-Live-Daten + Datei-Aufteilung | — | +> | TP37 | 🔜 | OOB-Mgmt: untagged-VLAN99-Port je Switch | — | > | — | — | **34 archivierte TPs** in `teilprojekte-archiv.md` | — | ### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt @@ -1869,6 +1875,78 @@ kann in Ruhe nachziehen. - **Verzahnt mit:** TP22 (Nautobot-GC als Vorbild), TP35 (geht Hand in Hand — beide sind „SSoT + Konsolidierung"), `bf-infra/CLAUDE.md`-Lessons. - **Referenzen:** Lessons-Block-Eintrag „Manuell gepflegte Doku mit Live-Daten verliert gegen die Realität" · Handoff Session A 2026-08-28. + +### TP37 — Out-of-Band-Management: ein untagged-VLAN99-Port je Switch ▸ 🔜 **ANGELEGT 2026-08-31** + +> **Auslöser (User 2026-08-31, aus eigener Anschauung):** *„ich durfte beim Neustart vom core gerade +> erleben, dass ich nicht mehr auf den branch zum verbinden kam. weil das eben alles über den core +> läuft."* + +#### Der Befund, live nachgemessen (2026-08-31) +Das Management des Standorts hat **einen einzigen Weg**, und der führt über den Core: + +| | `crs326-core` | `crs326-branch` | +|---|---|---| +| Mgmt-IP | `10.40.99.1` (VLAN99-SVI) | `10.40.99.2` (`vlan99` auf der Bridge) | +| VLAN99 auf der Bridge | SVI + Trunks | **`tagged=ether1,ether24,bridge`**, `untagged=""` | +| Weg dorthin | direkt | **nur über `ether1` → core `ether8`** | + +⇒ **`crs326-branch` ist ausschließlich durch den Core hindurch erreichbar.** Rebootet der Core, ist der +Branch für die Dauer weg — nicht weil er ausfällt, sondern weil der einzige Pfad zu ihm fehlt. Dasselbe +gilt für jeden Fehler, der den Core-Trunk oder dessen VLAN99-Konfiguration betrifft. **Wer den Core +zerkonfiguriert, verliert den Branch gleich mit** — und damit die Möglichkeit, es vom Branch aus zu +reparieren. + +🔴 **Der zweite Befund ist der unangenehmere: `crs326-branch` hat KEINE `input`-Firewallregeln** (Kette +leer, live gelesen). Sein gesamter Schutz besteht heute darin, dass VLAN99 nur über den Core erreichbar +ist und **dessen** `forward`-Kette seit TP5 deny-by-default fährt. **Die Erreichbarkeitsbeschränkung +IST die Zugangskontrolle.** Das ist für die Lösung unten kein Detail, sondern die Hauptauflage. + +#### Zielbild +**Je Switch ein Port, untagged in VLAN99** — ein Laptop direkt daran erreicht das Gerät ohne jeden +Umweg über den Core, ohne Trunk, ohne funktionierendes Routing. + +``` +Laptop ──(statische IP 10.40.99.x/24)── ether23 (untagged VLAN99) ── crs326-branch 10.40.99.2 + ^ funktioniert auch, wenn der Core steht +``` + +**Kandidat `ether23` auf beiden Geräten** — auf core **und** branch heute `running=false`, also frei, +und symmetrisch (ein Port, eine Nummer, an beiden Standorten dieselbe). *(Core hat reichlich freie +Ports; auf dem Branch sind `ether23` und die Reihe darunter frei, `ether24` ist ap2.)* + +#### Umsetzung (Skizze — eigene Session) +1. **Port aus dem Trunk-Verhalten nehmen und in VLAN99 untaggen:** + `bridge port` mit `pvid=99` + `frame-types=admit-only-untagged-and-priority-tagged`, + dazu `ether23` als `untagged`-Member in die `bridge vlan`-Zeile für VLAN99. +2. **Kein DHCP dort** — der VLAN99-DHCP läuft auf dem Core, und genau der soll ja nicht Voraussetzung + sein. ⇒ **statische IP am Laptop** (`10.40.99.50/24`), im Runbook mitschreiben. +3. **Beschriftung.** Ein OOB-Port, den niemand erkennt, wird im Zweifel für „ist ja frei" gehalten. +4. **Abnahme, die den Zweck wirklich prüft:** Laptop an `ether23` des Branch, **Core-Trunk `ether1` + gezogen** (oder Core im Reboot) → `10.40.99.2` muss antworten. Alles andere misst nur den Normalfall. + +#### 🔴 Auflage, ohne die das TP nicht gebaut werden darf +Ein untagged-MGMT-Port ist **ein physischer Generalschlüssel**: wer ihn steckt, steht ungefiltert im +Management-VLAN eines Geräts, das (Branch) keinerlei `input`-Filter hat. Deshalb gehört **eine** der +folgenden Absicherungen dazu, und die Entscheidung darüber in die Umsetzungs-Session: +- **Port `disabled=yes` im Normalbetrieb**, im Bedarfsfall am *anderen* Gerät freigeschaltet — schützt, + kostet aber genau dann Zugriff, wenn das andere Gerät weg ist (halbierter Nutzen, ehrlich benennen); +- **oder** `input`-Regeln auf beiden Switches nachziehen (der Branch braucht sie ohnehin — das ist die + eigentliche Lücke, die dieses TP nebenbei aufgedeckt hat); +- **oder** rein physisch: abschließbarer Schrank, Port beschriftet und dokumentiert. + +⚖️ **Meine Einschätzung:** die `input`-Regeln sind der richtige Weg, weil sie eine Lücke schließen, die +**unabhängig von diesem TP** besteht. Der OOB-Port macht sie nur sichtbar. + +#### Abgrenzung +- **Nicht** Teil von TP16.3 — dort wird nur festgestellt, dass dreimal Geräte rebooten, deren Mgmt am + Core hängt. TP37 entschärft das für künftige Sessions, ist aber **keine Voraussetzung** dafür. +- **Nicht** VLAN-Schema-Änderung (TP32 bleibt unberührt), **nicht** Konsolen-/Serial-Zugang (das wäre + echtes OOB im engeren Sinn; hier geht es um ein zweites *Netz*-Bein). +- **Abh.:** TP5 (Firewall-Systematik, liefert das Muster für die `input`-Regeln), TP15 (Portbelegung + beider CRS326), TP22 (die Umsetzung läuft über Golden Config, `ip-firewall-filter` und + `bridge`-Sektionen stehen unter Drift-Kontrolle). + --- ## Abgeschlossene Teilprojekte ▸ [`teilprojekte-archiv.md`](teilprojekte-archiv.md)