93 lines
5.1 KiB
Markdown
93 lines
5.1 KiB
Markdown
# Die WLAN-`access-list` — von Grund auf erklärt
|
||
|
||
> **Warum es dieses Dokument gibt:** die `access-list` taucht in diesem Projekt an drei Stellen auf
|
||
> (TP25 Fund E, der Mess-Pin `tp25-pin-s22.sh`, der gescheiterte DTU-Versuch vom 2026-08-23) — und sie
|
||
> ist genau das Werkzeug, mit dem man sich still ins Knie schießt, wenn man ihr Wesen nicht kennt.
|
||
> Stand 2026-08-23.
|
||
|
||
## In einem Satz
|
||
|
||
Die `access-list` ist eine **Türsteher-Liste am WLAN**: für jeden Client, der sich anmelden will, geht
|
||
sie von oben nach unten durch und entscheidet **ja oder nein** — pro AP, pro Funkschnittstelle, pro
|
||
Gerät.
|
||
|
||
## Wo sie lebt
|
||
|
||
`/interface wifi access-list` — und bei uns **auf dem Manager `crs326-core`**, nicht auf den APs.
|
||
Unter CAPsMAN besitzen ap1/ap2 ihre Radios nicht; sie fragen den Manager. *(Dieselbe Regel wie bei der
|
||
Registration-Table: der Manager führt die Tabellen.)*
|
||
|
||
## Der eine Satz, den man wirklich verstehen muss
|
||
|
||
> 🔴 **Eine `access-list`-Regel kann einem Gerät nur „nein" sagen. Sie kann es nicht irgendwo
|
||
> hinschicken.**
|
||
|
||
Das klingt trivial und ist die Quelle fast aller Überraschungen. Wer einen Client „auf ap2 umziehen"
|
||
will, verbietet ihm in Wahrheit **ap1** — und hofft, dass er von selbst zu ap2 geht. Ob er das tut,
|
||
entscheidet **das Gerät**, nicht der Router:
|
||
|
||
| Gerätetyp | Reaktion auf ein `reject` |
|
||
|---|---|
|
||
| Telefon, Laptop | sucht sofort einen anderen AP → der Umzug klappt |
|
||
| einfaches IoT-Gerät | hängt am gespeicherten AP fest, versucht es weiter — **oder gibt ganz auf** |
|
||
|
||
**Am 2026-08-23 live erlebt:** der PV-Wechselrichter wurde auf ap1 abgewiesen, ging **nicht** zu ap2,
|
||
und kam auch nach dem Entfernen der Sperre nicht zurück. Er musste über die Hersteller-App neu
|
||
provisioniert werden. Zehn Minuten Ausfall der PV-Telemetrie. **Ein „nein" an ein Gerät ohne
|
||
Suchlogik ist ein Abschalten.**
|
||
|
||
## Wann sie greift
|
||
|
||
**Nur im Moment der Anmeldung** (Association) — nicht laufend. Zwei Folgen:
|
||
- Eine neue Regel wirft bestehende Verbindungen **nicht automatisch** raus … *außer* RouterOS wertet
|
||
sie neu aus, was es bei Änderungen an der Liste tut: im Log steht dann
|
||
`disconnected, access-list changed`.
|
||
- Wer eine Regel testet, muss den Client **einmal trennen**, sonst misst er den alten Zustand.
|
||
|
||
## Was eine Regel matchen kann
|
||
|
||
| Feld | Bedeutung |
|
||
|---|---|
|
||
| `mac-address` | genau ein Gerät |
|
||
| `interface` | ein bestimmtes Radio bzw. eine bestimmte SSID (bei uns `cap-wifiN` / `cap-wifiN-virtualM`) |
|
||
| `signal-range` | **nur Clients innerhalb dieses dBm-Fensters** — das Werkzeug gegen klebende Clients |
|
||
| `time` | Uhrzeit/Wochentag |
|
||
|
||
Und als Aktion im Kern: **`accept`** oder **`reject`**. Dazu kommt eine Besonderheit, die
|
||
kein Verbot ist, sondern eine Ausnahme: eine Regel kann einem einzelnen Gerät ein **eigenes
|
||
WLAN-Passwort** zuweisen (`passphrase`) — der Trick, mit dem sich ein PSK-Wechsel ohne Stichtag machen
|
||
lässt (neues Passwort aufs Profil, Altgeräte übergangsweise per MAC mit dem alten weiter).
|
||
|
||
## Die drei Dinge, für die wir sie brauchen
|
||
|
||
1. **Signal-Boden gegen klebende Clients** (TP25 „Fund E"). Ein Client, der bei −85 dBm an einem
|
||
fernen AP klebt, obwohl zwei Meter weiter ein besserer steht, wird mit einem `signal-range`-Fenster
|
||
frühzeitig abgewiesen — er sucht sich dann den stärkeren. ⚠️ **Wirkt nur, wenn es einen besseren AP
|
||
gibt.** Auf der Terrasse gab es keinen; dort hätte ein Boden die Lage *verschlechtert*.
|
||
2. **Messen** (`tp25-pin-s22.sh`): ein Testgerät gezielt auf **einen** AP zwingen, um den Gegen-AP zu
|
||
vermessen. Genau hierfür ist sie gebaut — Testgeräte haben Suchlogik.
|
||
3. **PSK-Wechsel ohne Flag-Day** (s. `passphrase` oben) — vorgemerkt für die Rotation.
|
||
|
||
## Governance in diesem Projekt
|
||
|
||
Seit **2026-08-23** steht `/interface wifi access-list` unter der ComplianceRule `wifi-access-list`.
|
||
Das heißt: **jeder Eintrag erzeugt Drift** und gehört als Transaktion geführt
|
||
(`nautobot/gc-transaktion.py begin …`), sonst sieht ein Versuch aus wie ein Versehen.
|
||
Der Soll-Zustand ist **leer**.
|
||
|
||
## Merkregeln, jede aus einem echten Fehlgriff
|
||
|
||
- 🔴 **`reject` ist kein Umzug, sondern ein Rausschmiss.** Vorher fragen: *kann und will dieses Gerät
|
||
woanders hin?*
|
||
- 🔴 **Signalstärke ist kein Nachweis für Assoziationsfähigkeit.** „Der andere AP hört ihn mit −59 dBm"
|
||
belegt einen Funkpfad — nicht, dass das Gerät dort hingeht.
|
||
- 🔴 **Ein abgewiesener Verbindungsversuch ist in Ping-Daten nicht von einem Funkloch zu
|
||
unterscheiden**, und der Manager protokolliert ihn auf `info`-Ebene **gar nicht**. Wer mit einem Pin
|
||
misst, braucht eine eigene Alarmierung für „Gerät hängt nirgends".
|
||
- 🔴 **Die `cap-wifiN`-Nummern sind nicht stabil** — sie werden in der Reihenfolge vergeben, in der
|
||
sich die CAPs anmelden. Eine Regel, die auf `cap-wifi4` zeigt, kann nach einem AP-Neustart ein
|
||
anderes Radio meinen. **Vor jedem Eingriff die Zuordnung über `radio-mac` neu bestimmen.**
|
||
⚠️ Besonders relevant, sobald die zwei neuen APs dazukommen: dann wird neu durchnummeriert.
|
||
- ⚠️ **Für den PV-Wechselrichter ist die Liste gesperrtes Gebiet** — nicht wegen des Kanals, sondern
|
||
weil er nach einem `reject` aufgibt und einen Vor-Ort-Einsatz braucht.
|