143 lines
7.1 KiB
Markdown
143 lines
7.1 KiB
Markdown
# 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.
|