README: MikroTik-Bouncer verliert Address-List-Eintraege (Workaround dokumentiert)
Gemessen: nur 11.597 von 25.564 aktiven Decisions standen tatsaechlich auf dem Router (45,4 %), darunter 30 von 58 eigenen Bans. Ursache ist der Cache des Bouncers: Eintraege laufen per Timeout auf dem Router ab, der Cache meldet weiterhin 'already present' und legt sie nie neu an. Kein Versionsproblem - :latest ist digest-identisch mit v0.7.3 (neuestes Release, Apr 2025). Workaround ist ein taeglicher Neustart per cron (30 4 * * *), der die Liste komplett neu synchronisiert: 11.597 -> 25.037 in ~60 s, danach keine Requests mehr von bereits gelisteten IPs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
35
README.md
35
README.md
@@ -52,6 +52,41 @@ Datenquellen pruefen: Traefik schreibt sein Access-Log ins geteilte Volume
|
||||
`traefik-logs`, CrowdSec liest es read-only. Die Synologies senden per
|
||||
DSM *Log Center → Log Sending* an `192.168.0.142:5514/udp`.
|
||||
|
||||
## Bekanntes Problem: MikroTik-Bouncer verliert Eintraege
|
||||
|
||||
**Symptom:** Gebannte IPs erreichen Traefik trotzdem noch, teils tagelang.
|
||||
|
||||
**Ursache:** Der Bouncer schreibt jeden Eintrag der Address-List `crowdsec` MIT
|
||||
Timeout. Laeuft der Timeout auf dem Router ab, glaubt sein In-Memory-Cache
|
||||
weiterhin, die Adresse sei vorhanden ("Address <IP> already present") und legt
|
||||
sie nie neu an. Die Liste schrumpft dadurch kontinuierlich.
|
||||
|
||||
Gemessen am 2026-08-09: nur **11.597 von 25.564** aktiven Decisions waren
|
||||
tatsaechlich auf dem Router (45,4 %) - auch 30 von 58 eigenen Bans fehlten.
|
||||
In den zwei Stunden davor kamen 386 von 390 Requests von IPs, die gebannt
|
||||
waren, aber nicht in der Liste standen.
|
||||
|
||||
**Kein Versionsproblem:** `:latest` ist identisch mit **v0.7.3** (neuestes
|
||||
Release, Apr 2025, upstream seitdem still). Ein Update behebt es nicht.
|
||||
|
||||
**Workaround** (cron, Benutzer lutz): ein Neustart baut den Cache neu auf und
|
||||
synchronisiert die komplette Decision-Liste (11.597 -> 25.037 in ~60 s,
|
||||
danach 100 % der IPv4-Decisions durchgesetzt).
|
||||
|
||||
```
|
||||
30 4 * * * /usr/bin/docker restart crowdsec-mikrotik-bouncer >/dev/null 2>&1
|
||||
```
|
||||
|
||||
Der Schwund betraegt rund 130 Eintraege/Stunde (~12 %/Tag), der taegliche
|
||||
Neustart begrenzt die Abdeckung also nach unten auf ca. 88 %. IPv6-Decisions
|
||||
werden generell nicht uebertragen (`MIKROTIK_IPV6: "false"`).
|
||||
|
||||
Nachpruefen laesst sich das ueber die RouterOS-API (api-ssl 8729, CA-Bundle
|
||||
`crowdsec/famfi-ca-bundle.pem`, SNI `mt-az.famfi.home`): Address-List-Eintraege
|
||||
mit `list=crowdsec` zaehlen und gegen `cscli decisions list` halten. Die
|
||||
Drop-Regel selbst (`/ip firewall raw`, chain=prerouting, in-interface-list=WAN)
|
||||
ist in Ordnung - davor steht nur ein Whitelist-Accept mit RFC1918-Adressen.
|
||||
|
||||
## Secrets
|
||||
|
||||
`.mikrotik.env` (RouterOS-Passwort + Bouncer-API-Key) ist git-ignoriert und
|
||||
|
||||
Reference in New Issue
Block a user