SystemdDoctor
служба не работает безопасность брандмауэр

Служба блокировки не применяет правила: ключ доступа не принят

Схема из двух частей — служба принятия решений и исполнитель блокировок — ломается в месте их стыка. Признак в том, что решения принимаются и видны, а блокировки не применяются. Ключ доступа при этом действительно основная причина.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Ключ исполнителя не зарегистрирован или устарел

    После переустановки службы принятия решений старые ключи недействительны. Исполнитель получает отказ и молча ничего не делает.

  2. Исполнитель обращается не к тому адресу

    После смены адреса или порта службы принятия решений исполнитель продолжает стучаться по старому.

  3. Правила блокировки создаются, но не применяются брандмауэром

    Исполнитель создаёт правила в своей цепочке, а основные правила брандмауэра до неё не доходят.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Какие решения о блокировке приняты.

sudo cscli decisions list 2>/dev/null | head

Зарегистрированные исполнители и время их последнего обращения.

sudo cscli bouncers list 2>/dev/null

Сообщения исполнителя: отказы доступа видны сразу.

journalctl -u "*bouncer*" -n 30 --no-pager 2>/dev/null

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Ключ исполнителя не зарегистрирован или устарел
Почему происходит
После переустановки службы принятия решений старые ключи недействительны. Исполнитель получает отказ и молча ничего не делает.
Как проверить
Посмотрите список исполнителей и сообщения. 
sudo cscli bouncers list 2>/dev/null
journalctl -u "*bouncer*" -n 20 --no-pager 2>/dev/null | grep -iE "auth|401|403"
Как исправить
Зарегистрируйте исполнителя заново и подставьте новый ключ в его настройки. Ключ стоит подавать через механизм учётных данных systemd, а не хранить в файле с широкими правами.
2. Исполнитель обращается не к тому адресу
Почему происходит
После смены адреса или порта службы принятия решений исполнитель продолжает стучаться по старому.
Как проверить
Сравните адрес в настройках исполнителя и слушателя службы. 
sudo grep -iE "api_url|api_key" /etc/crowdsec/bouncers/*.yaml 2>/dev/null | sed "s/api_key.*/api_key: (скрыт)/"
sudo ss -tlnp | grep :8080
Как исправить
Приведите адрес в соответствие и перезапустите исполнителя. Проверять надо не только адрес, но и схему обращения.
3. Правила блокировки создаются, но не применяются брандмауэром
Почему происходит
Исполнитель создаёт правила в своей цепочке, а основные правила брандмауэра до неё не доходят.
Как проверить
Посмотрите цепочки и счётчики. 
sudo nft list ruleset 2>/dev/null | grep -iA5 crowdsec | head -20
Как исправить
Убедитесь, что цепочка исполнителя вызывается из основной и стоит до разрешающих правил. Порядок правил здесь решает всё.

Пример вывода

Ключ исполнителя не принят после переустановки. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

crowdsec-firewall-bouncer[7000]: level=error msg="auth-api: auth with api key failed return nil response, error: API error: access forbidden"
crowdsec-firewall-bouncer[7000]: level=fatal msg="unable to configure bouncer: unable to authenticate"
systemd[1]: crowdsec-firewall-bouncer.service: Main process exited, code=exited, status=1/FAILURE

Связанные ошибки

Где встречается чаще всего

Источники

  • Документация CrowdSec: исполнители блокировок документация программы
    сверено 15 сентября 2026
  • systemd.exec(5)
    LoadCredential= для передачи ключей службе.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено недействительным ключом исполнителя.     собственная проверка, systemd 255
    сверено 15 сентября 2026