From 777ac95c3f3f6bf4a3adffd16d06b2a72ee0a9ac Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Wed, 19 Aug 2026 16:00:15 +0200 Subject: [PATCH] TP13: Technikteil war seit TP28 falsch, plus ein Denkfehler Zwei Sachen standen in TP13, die so nicht stimmen. Erstens beschrieb der Technikteil noch Standalone-APs und wollte die Beacon-SSIDs in ap{1,2}-prov-base.rsc ergaenzen. Seit dem CAPsMAN-Cutover entstehen SSIDs am Manager auf dem Core -- was fuer TP13 sogar einfacher ist, ein Deploy statt zwei. Zweitens der eigentliche Fund: der Entwurf wollte "nur ssid=, kein Security" und begruendete das damit, dass Namens-SSIDs ohne offenen Zugang rechtlich unkritisch seien. Eine SSID ohne Security IST aber ein offenes WLAN, also genau der Fall, den der Rechtsvorbehalt ausschliessen will. Richtig ist ein PSK, den niemand kennt: beacont den Namen, niemand kommt rein. Kostet nichts. Dazu die Datapath-Falle: ein Slave-VAP ohne explizite vlan-id am Manager landet ungetaggt in der Bridge, weil der CAP vom Manager-Datapath nur die vlan-id uebernimmt. Gleiche Mechanik wie der 14-h-Ausfall. Die Botschafts-SSID braucht deshalb beides -- PSK und toten Datapath. VAP-Budget am Geraet nachgesehen statt geschaetzt: max-interfaces=16 je Radio, belegt sind 4 bzw. 5. Die Zahl ist also nicht die Grenze, Airtime ist es -- jeder VAP beacont eigenstaendig. Empfehlung steht im Runbook. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 11 ++- docs/tp13-botschafts-wlan-runbook.md | 142 +++++++++++++++++++++++++++ 2 files changed, 150 insertions(+), 3 deletions(-) create mode 100644 docs/tp13-botschafts-wlan-runbook.md diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 6f792df..e767b58 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -529,10 +529,15 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ### TP13 — „Botschafts-WLANs" ▸ 🔜 VORBEREITET (2026-08-08), fun/low-prio - **Idee:** eine/mehrere **Broadcast-only-SSIDs als „schwarzes Brett"** an die Funk-Nachbarschaft — der SSID-Name *ist* die Botschaft (z.B. `Kanal-11-bitte-freihalten`, `WLAN-Tuning-siehe-Portal`). Optional ein **offenes WLAN mit Captive-Portal** auf eine **statische Info-HTML** (Kanalabsprache, Auto-Kanalwechsel-Bitte). Leitgedanke: wer die SSID sieht, kann auch stören → die Infoseite erreicht genau die Zielgruppe. -- **Technik (jetzt einfach, da WLAN standalone seit TP3-Rebuild):** reine Namens-SSIDs = zusätzliche `/interface/wifi` Slave-VAPs auf wifi1/wifi2 mit eigener `configuration` (nur `ssid=`, kein Security/Datapath) bzw. in ein isoliertes Dummy-VLAN → reine Beacon-SSID (kein DHCP/Uplink). Captive-Portal-Variante: RouterOS-**Hotspot** auf eigenem isoliertem VLAN (Guest-Ableger) mit `walled-garden` auf die lokale Info-Seite (HTML als hotspot-Ordner am Gerät oder via NAS-nginx). -- **Umsetzungs-Skizze:** (1) SSID-Namen + Info-Text final; (2) Beacon-SSIDs in `routeros/.secrets/ap{1,2}-prov-base.rsc` ergänzen (identisch auf beiden APs, via Nautobot-GC generierbar); (3) optional Hotspot-VLAN + walled-garden + Info-HTML; (4) beide APs deployen. +- ~~**Technik (jetzt einfach, da WLAN standalone seit TP3-Rebuild):** reine Namens-SSIDs = zusätzliche `/interface/wifi` Slave-VAPs auf wifi1/wifi2 mit eigener `configuration` (**nur `ssid=`, kein Security/Datapath**)~~ ⚠️ **Überholt 2026-08-19, in zwei Punkten:** + - **(a) WLAN ist seit TP28 nicht mehr standalone.** SSIDs entstehen am **Manager `crs326-core`** (9 `configuration`-, 6 `datapath`-Objekte, 4 `provisioning`-Zeilen — live gelesen 08-19). Das ist für TP13 sogar einfacher: **ein** Deploy statt zwei. + - **(b) 🔴 „kein Security" *ist* ein offenes WLAN** — genau das, was der Rechtsvorbehalt unten ausschließen will. Richtig ist eine SSID **mit** WPA2/WPA3-PSK, den niemand kennt: sie beacont den Namen, ist aber nicht beitretbar. + - Captive-Portal-Variante (RouterOS-**Hotspot**, isoliertes VLAN, `walled-garden`) bleibt als Option bestehen — s. Rechts-Gate unten. +- ~~**Umsetzungs-Skizze:** … Beacon-SSIDs in `routeros/.secrets/ap{1,2}-prov-base.rsc` ergänzen …~~ → diese Dateien sind für den WLAN-Teil **Historie** (die CAPs sind auf die `cap`-Zeile eingedampft). **Aktuelle Umsetzung: `docs/tp13-botschafts-wlan-runbook.md`** (2026-08-19). + - 🔴🔴 **Die Falle, die dort ausführlich steht:** ein Slave-VAP **ohne explizite `vlan-id` am Manager** landet ungetaggt in `bridge` — weil der CAP vom Manager-Datapath **nur die `vlan-id`** übernimmt. Das ist dasselbe Leck wie TP3.1 (`cfg-main-2g` ohne datapath) und dieselbe Mechanik wie der 14-h-Ausfall vom 08-18. Die Botschafts-SSID braucht deshalb einen Datapath mit **totem** `vlan-id` — PSK **und** toter Datapath, nicht eines von beidem. + - ✅ **VAP-Budget geprüft (live 08-19), unkritisch:** `max-interfaces=16` je Radio, belegt sind 4 (5 GHz) bzw. 5 (2,4 GHz). **Die Grenze ist Airtime, nicht die Zahl** — jeder VAP beacont eigenständig. Empfehlung: **genau eine SSID, auf 2,4 GHz** (mehr Reichweite = mehr Nachbarn, und 5 GHz bleibt für Nutzverkehr frei). - ⚠️ **Recht vor Scharfschalten prüfen (User privat, AT):** offenes WLAN + Portal berührt Impressumspflicht/Störerhaftung — **reine Namens-SSIDs ohne offenen Zugang sind unkritisch** (kein Fremd-Datenverkehr); im Zweifel nur die Beacon-Variante. -- **Abh.:** TP3-Rebuild ✅ (Standalone-APs — SSID-Änderung = 1 Deploy/GC-Job); ideal nach TP21/TP22 (dann via Golden Config statt Direkt-Edit). +- **Abh.:** ~~TP3-Rebuild ✅ (Standalone-APs — SSID-Änderung = 1 Deploy/GC-Job)~~ → **TP28 ✅** (CAPsMAN auf dem Core) + **TP22 ✅** (GC-Deploy-Pipeline). SSID-Änderung = **ein** Deploy auf den Core; Direkt-Edit am Gerät ist durch den Governance-Entscheid ausgeschlossen. ### TP14 — Host/Container-IP-Migration VLAN1→VLAN20 (Docker-Cutover NAS+pve) ▸ ✅ DURCH (2026-07-13; live re-verifiziert 2026-08-08) — `docs/nas-vlan20/RUNBOOK.md`, Handoff `docs/nas-vlan20/handoff/` - ✅ **ABGESCHLOSSEN — Migration komplett** (Live-Check 2026-08-08 vom core: NAS `.20.10`, pve `.20.100`, Docker-LXC `.20.126`, platform-pg `.20.20`, Nautobot `.20.30` alle 0% Loss). Alle Hosts + Container auf VLAN20. **TP14.4** (CF-Access-Token-Rotation) = kleiner, nicht-blockierender Standalone-Follow-up (CF/TP11-Umfeld); **TP14.5** war nie ein eigener Change (nur ein Reihenfolge-Gate) → erfüllt, TP5 damit entblockt. diff --git a/docs/tp13-botschafts-wlan-runbook.md b/docs/tp13-botschafts-wlan-runbook.md new file mode 100644 index 0000000..425e1e1 --- /dev/null +++ b/docs/tp13-botschafts-wlan-runbook.md @@ -0,0 +1,142 @@ +# TP13 — „Botschafts-WLAN": Beacon-SSID als schwarzes Brett an die Nachbarschaft + +> **Stand 2026-08-19 · vorbereitet, nicht ausgeführt.** fun/low-prio, blockiert nichts. +> **Umgesetzt wird nur die Beacon-Variante** — die Captive-Portal-Variante steht am Ende als Option +> mit vorgelagertem Rechts-Gate, wird aber nicht geplant. + +--- + +## 1. Idee + +Eine SSID, deren **Name die Botschaft ist** — z.B. `Kanal-11-bitte-freihalten`. Leitgedanke: wer die +SSID sieht, ist nah genug, um zu stören; die Nachricht erreicht also genau die Zielgruppe. + +--- + +## 2. 🔴 Der Denkfehler im ursprünglichen Entwurf + +Der TP-Text sagte bisher: *„reine Namens-SSIDs = Slave-VAPs mit eigener `configuration` (nur `ssid=`, +**kein Security**/Datapath)"* — und begründete das damit, dass reine Namens-SSIDs **ohne offenen Zugang** +rechtlich unkritisch seien. + +**Beides zusammen geht nicht.** Eine SSID ohne `security` **ist** ein offenes WLAN. Genau das, was der +Rechtsvorbehalt (Impressumspflicht/Störerhaftung, User privat in AT) ausschließen will — Fremdgeräte +könnten sich verbinden. + +**Richtig ist:** die Botschafts-SSID bekommt **WPA2/WPA3 mit einem PSK, den niemand kennt.** Sie beacont +den Namen für jeden sichtbar, ist aber für niemanden beitretbar. Das ist der Unterschied zwischen +„unkritisch" und „offenes WLAN" — und er kostet nichts. + +--- + +## 3. Technik: es läuft über CAPsMAN, nicht mehr pro AP + +⚠️ **Der Technik-Abschnitt des TP stammt aus der Standalone-Ära und ist seit TP28 (2026-08-17) ungültig.** +Die APs sind reine CAPs; ihre lokale WLAN-Config ist auf die `cap`-Zeile eingedampft. +`routeros/.secrets/ap{1,2}-prov-base.rsc` ist für den WLAN-Teil **Historie**. + +**Ist-Stand am Manager `crs326-core` (live gelesen 2026-08-19):** + +``` +/interface wifi configuration 9 Objekte (cfg-main-5g-ap1/ap2, cfg-main-2g-ap1/ap2, + cfg-infra, cfg-iot, cfg-media, cfg-untrusted, cfg-guest) +/interface wifi datapath 6 Objekte (dp-main, dp-infra, dp-iot, dp-media, + dp-untrusted, dp-guest) -- alle bridge=bridge +/interface wifi provisioning 4 Zeilen, eine je Radio (ap1/ap2 x 5GHz/2,4GHz) +``` + +Eine neue SSID entsteht damit in **einem** Deploy auf den Core statt in zweien auf die APs — +für TP13 eine Vereinfachung gegenüber dem alten Entwurf. + +> 📌 `cfg-infra` existiert, steht aber in **keiner** `slave-configurations`-Liste — `dirtyvader-infra` +> ist seit TP25 bewusst offline. Nicht als Fehler „reparieren". + +### 3.1 🔴🔴 Die Datapath-Falle — der teuerste Punkt dieses Runbooks + +Auf den CAPs steht `slaves-datapath=dp-caps-slaves`: ein lokales Objekt mit `bridge=bridge` und +**ohne** `vlan-id`. Der Manager schickt seinen Datapath mit, **der CAP übernimmt davon aber nur die +`vlan-id`** (genau das war die Ursache des 14-Stunden-Ausfalls am 2026-08-18, s. TP28-Nachtrag). + +**Folge für eine Botschafts-SSID:** gibt man ihr am Manager **keinen** Datapath bzw. einen **ohne** +`vlan-id`, landet der VAP in `bridge` — und zwar ungetaggt, also faktisch im alten VLAN1. Das ist exakt +das Leck, das TP3.1 gekostet hat (`cfg-main-2g` ohne datapath). + +**Richtig:** ein eigener Datapath mit **explizitem, totem `vlan-id`** — eine VLAN-ID, die +- in **keinem** DHCP-Server vorkommt, +- in der Bridge-VLAN-Tabelle **nicht** auf den AP-Trunk-Ports getaggt ist, +- und in keinem der sieben produktiven Netze liegt (10/20/30/40/50/90/99). + +Dann laufen Frames dieses VAP ins Leere — was genau der Zweck ist. Der PSK verhindert schon den Beitritt; +der tote Datapath ist der zweite, unabhängige Riegel. **Beide setzen, nicht einen.** + +### 3.2 VAP-Budget — geprüft, unkritisch + +Live von `ap1` (`/interface wifi radio print detail`): + +``` +max-interfaces=16 max-vlans=128 max-station-interfaces=3 hw-type=QCA6018 +``` + +Belegt sind aktuell **4** VAPs auf dem 5-GHz-Radio (`wifi1` + 3 Slaves) und **5** auf dem 2,4-GHz-Radio +(`wifi2` + 4 Slaves). Es ist also reichlich Platz — **die Interface-Zahl ist nicht die Grenze.** + +⚠️ **Die echte Grenze ist Airtime, nicht die Zahl.** Jeder zusätzliche VAP sendet eigene Beacons +(~10×/s, auf 2,4 GHz mit niedriger Basisrate). Ein bis zwei Botschafts-SSIDs sind unproblematisch; +eine Handvoll kostet spürbar Airtime in einem Band, das laut TP25 ohnehin das engere ist. +→ **Empfehlung: genau eine SSID, auf 2,4 GHz** (größere Reichweite = mehr Nachbarn sehen sie, +und das 5-GHz-Band bleibt frei für Nutzverkehr). + +--- + +## 4. Umsetzung (alles via Nautobot Golden Config) + +Der Governance-Entscheid gilt: **keine Direkt-Changes am Gerät.** Die Objekte gehören ins Template, +nicht per MikroMCP an den Core. + +1. **SSID-Name + Botschaft final festlegen.** ⚠️ Der Name ist öffentlich sichtbar und dauerhaft — keine + Adresse, kein Nachname, nichts, was die Wohnung identifiziert. Er sollte eine *Bitte* transportieren, + keine Beschwerde. +2. **Datapath** `dp-botschaft` mit `bridge=bridge` und totem `vlan-id` (§3.1). +3. **Security** mit WPA2/WPA3-PSK — Passphrase zufällig, **wird nirgends verteilt**. Ablage bei den + übrigen WLAN-Secrets (`routeros/.secrets/wlan-psks.env`, gitignored). +4. **Configuration** `cfg-botschaft` (ssid, security, datapath) im Template + [`nautobot/mikrotik_routeros.j2`](../nautobot/mikrotik_routeros.j2) — dort, wo die anderen + `cfg-*`-Objekte stehen. +5. **Provisioning:** `cfg-botschaft` in die `slave-configurations` der beiden **2,4-GHz**-Zeilen + aufnehmen (ap1 `D0:EA:11:4D:40:E6`, ap2 `D0:EA:11:4D:40:3F`). +6. **Deploy** über `nautobot/gc-configplan.py`, danach **Backup → Intended → Compliance**, damit die + neue SSID sofort unter Drift-Kontrolle steht und nicht als Fremdkörper gilt. + +⚠️ **Nicht während eines Calls deployen.** Änderungen an der Provisioning-Liste re-applien die +Radios. *(Beim TP28-Cutover blieb das folgenlos, weil dynamische VAPs ihre Werte inline tragen — +verlassen sollte man sich darauf nicht.)* + +--- + +## 5. Abnahme + +🔴 **Nicht die Registration-Table** — sie zeigte während des 14-Stunden-Ausfalls 25 zufriedene Clients. + +| Prüfung | Erwartung | +|---|---| +| Fremdgerät sieht die SSID im Scan | ja — das ist der Zweck | +| Beitrittsversuch mit beliebigem Passwort | scheitert | +| **Die sechs produktiven SSIDs ziehen frische DHCP-Leases** | ja — **je SSID einzeln prüfen** | +| Compliance nach dem Lauf | wieder grün, neue Objekte im Soll | + +Der dritte Punkt ist der wichtige: er ist die Lehre aus dem 2026-08-18. Eine Änderung an der +Provisioning-Liste fasst **alle** Slave-VAPs an, nicht nur den neuen. + +--- + +## 6. Nicht geplant: die Captive-Portal-Variante + +Ein **offenes** WLAN mit Portal auf eine lokale Info-Seite (RouterOS-Hotspot, eigenes isoliertes VLAN, +`walled-garden`) wäre die ausführlichere Botschaft — aber es ist ein anderer Sachverhalt: + +- **Rechts-Gate zuerst** (User privat, AT): offenes WLAN + Portal berührt Impressumspflicht und + Störerhaftung, weil **Fremd-Datenverkehr** entsteht. Bei der Beacon-Variante entsteht keiner. +- **Technisch teurer:** Hotspot-Dienst, eigenes VLAN, DHCP dafür, Firewall-Zeilen unter + deny-by-default, Info-HTML irgendwo gehostet. + +→ Bleibt dokumentierte Option. **Erst das Rechts-Gate beantworten, dann planen** — nicht umgekehrt.