SystemdDoctor
мешает работе брандмауэр сеть

UFW BLOCK в журнале: брандмауэр режет нужный трафик

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

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

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

  1. Правило для нужного порта отсутствует

    Политика по умолчанию отбрасывает входящие соединения. Без правила служба недоступна снаружи при работающем слушателе.

  2. Правило есть, но не для того направления или протокола

    Правило для одного протокола не действует на другой, а исходящие и входящие правила независимы.

  3. Блокируется служебный трафик, а не прикладной

    Часть протоколов нужна для работы сети: объявления, обнаружение, проверки доступности. Их блокировка даёт странные последствия.

Диагностика

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

Что блокируется: интерфейсы, адреса, порты, протоколы.

journalctl -k -b --no-pager | grep -i "UFW BLOCK" | tail -20

Действующие правила с номерами.

sudo ufw status numbered

Самые частые блокируемые порты.

journalctl -k -b --no-pager | grep -i 'UFW BLOCK' | grep -oE 'DPT=[0-9]+' | sort | uniq -c | sort -rn | head

Решение

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

1. Правило для нужного порта отсутствует
Почему происходит
Политика по умолчанию отбрасывает входящие соединения. Без правила служба недоступна снаружи при работающем слушателе.
Как проверить
Посмотрите записи блокировки и правила. 
journalctl -k -b --no-pager | grep -i "UFW BLOCK" | tail -5
sudo ufw status numbered 2>/dev/null | head -20
Как исправить
Добавьте правило для нужного порта, ограничив его источником. Открывать порт всему миру стоит только для служб, которым это действительно нужно.
2. Правило есть, но не для того направления или протокола
Почему происходит
Правило для одного протокола не действует на другой, а исходящие и входящие правила независимы.
Как проверить
Сравните запись блокировки и правила. 
journalctl -k -b --no-pager | grep -i "UFW BLOCK" | tail -3
sudo ufw status verbose 2>/dev/null | head -20
Как исправить
Составьте правило по данным из записи блокировки: направление, протокол, порт. В записи есть всё нужное.
3. Блокируется служебный трафик, а не прикладной
Почему происходит
Часть протоколов нужна для работы сети: объявления, обнаружение, проверки доступности. Их блокировка даёт странные последствия.
Как проверить
Посмотрите, что именно блокируется чаще всего. 
journalctl -k -b --no-pager | grep -i 'UFW BLOCK' | grep -oE 'PROTO=[A-Z0-9]+' | sort | uniq -c | sort -rn | head
Как исправить
Разрешите нужный служебный трафик в локальной сети. Блокировка объявлений и обнаружения ломает отказоустойчивость и печать.

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

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

kernel: [UFW BLOCK] IN=eth0 OUT= MAC=52:54:00:12:34:56 SRC=192.0.2.55 DST=198.51.100.10 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=41229 DF PROTO=TCP SPT=51422 DPT=8080 WINDOW=64240 RES=0x00 SYN URGP=0

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

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

Источники

  • ufw(8)
    Правила брандмауэра и запись блокировок в журнал.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено обращением на порт без разрешающего правила.     собственная проверка, systemd 255
    сверено 15 сентября 2026