Initial import from bf-network-r6.opencode — opencode migration
This commit is contained in:
142
docs/tp13-botschafts-wlan-runbook.md
Normal file
142
docs/tp13-botschafts-wlan-runbook.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user