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.