Короткий ответ

UFW — удобная обёртка над nftables (Ubuntu 22.04/24.04). ufw disable «на пять минут» часто забывают включить. Диагностика: слушает ли приложение (ss -tlnp), виден ли BLOCK, какое номерное правило и на каком интерфейсе (allow in on ens3). Default incoming deny плюс allow на другой NIC = ваш трафик падает. Не путайте с облачной SG: гостевой UFW может быть зелёный, а пакеты не доходят.

Хост host.example (10.0.20.10), сервис-пример TCP/5432, SSH пользователь admin.

Симптомы и как отличить

  • с самой машины ss -tlnp показывает 0.0.0.0:5432, с другой — timeout;
  • journalctl | grep UFW есть BLOCK с SRC вашего клиента;
  • ufw status inactive — тогда это не UFW, а nft напрямую или внешний FW;
  • SSH timeout — sshd.
statusСмысл
allow 22профиль OpenSSH
5432/tcp ALLOW IN Anywhereбез привязки NIC
DENY IN 5432явное запрещение, порядок важен
LIMITанти-brute, не полный deny

Возможные причины

  1. После ufw enable default deny, забыли OpenSSH — потеряли SSH (нужна консоль).
  2. Allow на eth0, интерфейс ens3.
  3. Приложение слушает 127.0.0.1 — firewall ни при чём.
  4. IPv6 allow нет, клиент ходит в AAAA.
  5. ufw-docker / форвардинг не настроен, контейнер.
  6. Параллельно ручной nft — расхождение.
  7. LOGGING=off, вы не видите BLOCK.

Диагностика

sudo ufw status verbose
sudo ufw status numbered
sudo ss -tlnp
ip -br addr
sudo journalctl -k --since '1 hour ago' | grep UFW | tail

Включение лога, если пусто:

sudo ufw logging medium

Счётчики nft, которыми пользуется UFW:

sudo nft list ruleset | grep -A2 -i ufw
sudo iptables -L -n -v 2>/dev/null | head

На 22.04/24.04 iptables может быть nft-обёртка. Источник истины — nft list ruleset и ufw status.

Проверка с клиента (подставьте порт):

nc -vz 10.0.20.10 5432

С сервера на себя:

nc -vz 127.0.0.1 5432
nc -vz 10.0.20.10 5432

Если localhost ок, внешний IP timeout — FW или bind.

IPv6:

sudo ufw status | grep v6
ss -tlnp | grep ':::'

Решение

Сценарий A. Нужен порт, firewall остаётся on

sudo ufw allow OpenSSH
sudo ufw allow from 10.0.0.0/16 to any port 5432 proto tcp comment 'pgsql lan'
sudo ufw status numbered

Не ufw allow 5432/tcp в интернет без необходимости.

Сценарий B. Неверный интерфейс

sudo ufw allow in on ens3 to any port 5432 proto tcp

Удалите ошибочное numbered:

sudo ufw status numbered
# sudo ufw delete 5

Подтверждайте номер дважды — нумерация сдвигается.

Сценарий C. Случайно disable

sudo ufw enable
sudo ufw status

Перед enable обязательно allow SSH, иначе консоль.

Сценарий D. IPv6

sudo ufw allow proto tcp from 2001:db8::/32 to any port 5432

Или отключите IPv6 у сервиса, если не используете — осознанно, не «ради firewall».

Сценарий E. Конфликт с ручным nft

См. статью nftables. Не правьте filter.ufw-* цепочки руками — UFW перезапишет. Либо UFW, либо чистый nft, не оба вразнобой.

Порядок правил, IPv6 и облако рядом с UFW

ufw status numbered читается сверху вниз. deny 5432 на строке 3 победит allow 5432 на строке 8. Вставка: ufw insert 1 allow ... для SSH, если enable уже грозит lockout.

IPV6=yes в /etc/default/ufw создаёт параллельные v6-правила. Клиент с AAAA ходит в v6-цепочку. Allow только IPv4 = timeout для счастливых обладателей AAAA.

Security group AWS/Yandex и UFW независимы. Диагностика: tcpdump на ens3 видит SYN? Если нет — SG/маршрут. Если SYN есть, нет accept в приложении — UFW/nft или bind.

ufw allow from 10.0.20.0/24 не покрывает VPN-клиентов из 10.8.0.0/24. После смены VPN-пула правило устаревает. Комментарии в ufw помогают ревизии.

Логи LOGGING=medium пишут каждый BLOCK. На сканере это гигабайты — rate и journald. Не logging=off полностью: тогда вы не отличите FW от мёртвого sshd.

После ufw enable существующие SSH-сессии обычно живут (ESTABLISHED). Новая сессия без allow OpenSSH — нет. Поэтому проверку allow делайте из третьего окна, не закрывая BMC.

ufw app list показывает профили в /etc/ufw/applications.d. Свой профиль для порта приложения лучше, чем голый номер: ревизия читаемее.

Не смешивайте iptables -I INPUT с UFW: reboot или ufw reload вернёт nft из UFW и «ручное» правило исчезнет или наоборот останется сиротой. Только ufw CLI либо только nftables.service.

ufw default deny outgoing без allow 53/tcp+udp, 123/udp, 80/443 до зеркал ломает apt, NTP и TLS. Если политика исходящая строгая, сначала список зависимостей (DNS, NTP, репо, мониторинг), потом enable. Проверка исходящего: curl -I https://archive.ubuntu.com с хоста.

Правила routed (forward) в ufw status появляются, если хост — роутер. На обычном app-сервере forward policy drop нормален. Не открывайте forward, чтобы «починить входящий 5432».

ufw show added vs status numbered — сверка, что добавленное совпадает с активным после reload.

Как проверить, что проблема устранена

С клиента:

nc -vz 10.0.20.10 5432
ssh admin@10.0.20.10 'sudo ufw status verbose'

ufw status active. Новых BLOCK на легитимный SRC нет. Политика Incoming: deny.

Если не помогло

  • UFW allow, timeout остался: SG/ACL гипервизора, маршрутизация, nft вне UFW.
  • Работает минуту и рвётся — не UFW, SSH idle / conntrack.
  • Docker published ports: документация ufw-docker, FORWARD chain.

Профилактика

  • Правила с comment и source CIDR.
  • ufw allow OpenSSH до первого enable на новом узле.
  • Ревью numbered после каждого change.
  • Логи BLOCK в SIEM, не logging off.

FAQ

UFW vs nftables?

UFW генерирует nft. Для сложных правил иногда чистый nft. Не дублируйте default deny в двух местах по-разному.

ufw reset?

Сносит все правила. Только с консоли и готовым списком allow.

Почему allow Anywhere не работает?

Сервис на 127.0.0.1, или default deny outgoing мешает (редко для inbound), или не тот порт.

LIMIT SSH банит меня?

Да, при шквале. Увеличьте лимит или allow с jump-хоста выше LIMIT.

DEFAULT_FORWARD_POLICY?

Нужен для routing/NAT. Для простого сервера не FORWARD.