Фаервол UFW на сервере: частые ошибки и решения

MAATRIX

UFW прост в базовой настройке, но на практике подкидывает неочевидные проблемы: можно запереть себя без SSH, правила будто не работают, а Docker вообще обходит фаервол стороной. Разберём частые ошибки фаервола UFW на сервере по симптому, причине и решению с командами. Знание этих граблей избавит от паники, когда сервер вдруг перестанет пускать или, наоборот, останется открытым вопреки правилам.

Заперли себя: нет доступа по SSH после включения

Самая частая и болезненная ошибка: вы включили UFW и потеряли доступ к серверу — SSH больше не пускает. Причина в том, что политика deny incoming заблокировала SSH-подключение, потому что перед включением фаервола не было добавлено правило, разрешающее порт SSH. Соединение обрывается, и зайти обычным способом уже нельзя.

Если это случилось, обычный SSH не поможет — нужен доступ через панель провайдера. Практически все хостинги дают консоль VNC или аварийный доступ к серверу через веб-панель, минуя SSH. Зайдите через неё и исправьте правила.

ufw allow OpenSSH
ufw status

После добавления правила SSH заработает снова. Чтобы такого не повторялось, запомните железный порядок: сначала ufw allow OpenSSH, проверка правила, и только потом ufw enable. Хорошая привычка — перед любыми экспериментами с фаерволом держать открытой запасную SSH-сессию: если новое правило разорвёт связь, вторая сессия останется живой и позволит откатить изменения.

Правило добавлено, но не работает

Вы открыли порт командой ufw allow, но сервис снаружи всё равно недоступен. Причин несколько, и они не всегда очевидны. Первая — фаервол вообще не включён: команда allow добавляет правило, но если UFW в состоянии inactive, правила не действуют. Проверьте статус.

ufw status verbose
ss -tlnp

Если статус inactive, включите фаервол командой ufw enable (не забыв про SSH). Вторая причина — сервис не слушает порт: фаервол пропускает трафик, но принимать его некому. Команда ss покажет, слушает ли что-нибудь нужный порт; если пусто — проблема не в UFW, а в самом сервисе. Третья причина — вы открыли не тот протокол: например, разрешили TCP, а сервису нужен UDP. Проверьте, что протокол в правиле совпадает с тем, что использует сервис. Частая путаница именно здесь: игровые серверы обычно работают по UDP, а правило по привычке ставят на TCP.

Docker обходит UFW и открывает порты наружу

Коварная и опасная проблема: вы настроили UFW, закрыли всё лишнее, но контейнеры Docker всё равно доступны из интернета на своих портах, будто фаервола нет. Это не ошибка в ваших правилах — так устроен Docker. Он управляет iptables напрямую, вставляя свои правила раньше правил UFW, и публикация порта контейнера через параметр -p открывает его в обход фаервола.

Убедиться в проблеме можно, проверив правила iptables и попробовав достучаться до контейнера снаружи.

iptables -L DOCKER -n

Решений несколько. Простейшее и безопасное — публиковать порты контейнеров только на локальный адрес, указывая в маппинге 127.0.0.1, а наружу отдавать через обратный прокси, который уже под контролем UFW. Более системное решение — специальная настройка, которая заставляет Docker уважать правила UFW, через правку конфигурации и дополнительные правила. Но самое важное — знать об этой особенности: многие годами держат базы данных в контейнерах открытыми в интернет, не подозревая, что UFW их не защищает. Всегда проверяйте доступность портов контейнеров снаружи независимо от правил фаервола.

Конфликт UFW с ручными правилами iptables

Вы добавили правила напрямую через iptables, и теперь поведение фаервола стало непредсказуемым: часть трафика блокируется или проходит вопреки настройкам UFW. Причина в том, что UFW сам управляет iptables, и ручные правила, добавленные в обход, конфликтуют с ним. Два инструмента борются за одну и ту же таблицу правил.

Правильный подход — выбрать один инструмент. Если вы используете UFW, управляйте всеми правилами через него, а не через прямые команды iptables. UFW поддерживает и сложные сценарии: для нестандартных правил есть конфигурационные файлы, куда можно вписать свои строки, и они корректно встроятся в общую цепочку. Смешивать ручной iptables и UFW не стоит — это путь к трудноуловимым проблемам. Если вам нужен полный контроль через iptables или nftables, тогда откажитесь от UFW совсем, но не используйте оба одновременно.

Правила пропали после перезагрузки

Вы настроили фаервол, но после перезагрузки сервера правила исчезли или UFW выключился. Причина обычно в том, что фаервол не был включён командой enable, которая и обеспечивает автозапуск, а правила лишь добавлялись. UFW при правильном включении сам поднимается после перезагрузки. Проверьте, включён ли автозапуск сервиса.

ufw status
systemctl is-enabled ufw

Если ufw status показывает inactive после перезагрузки, значит, фаервол не был активирован как надо. Выполните ufw enable — эта команда не только включает фаервол сейчас, но и настраивает его автозапуск при загрузке системы. Если же UFW включён, но правила ведут себя странно после ребута, проверьте, не вмешивается ли другой инструмент вроде Docker или ручного iptables, который мог изменить цепочки при старте. В норме корректно включённый UFW полностью восстанавливает свои правила после перезагрузки без вашего участия.

Порядок правил приводит к неожиданному поведению

Трафик блокируется или проходит не так, как вы ожидали, хотя нужные правила есть. В UFW порядок правил имеет значение: они проверяются сверху вниз, и срабатывает первое подходящее. Если общее запрещающее правило стоит выше частного разрешающего, разрешение не сработает, потому что запрет применится раньше.

Посмотрите правила с номерами и при необходимости вставьте новое в нужную позицию.

ufw status numbered
ufw insert 1 allow from ВАШ_IP to any port 22

Команда с номерами показывает порядок, а ufw insert позволяет вставить правило на конкретную позицию, а не в конец списка. Типичный случай — вы заблокировали подсеть, но хотите разрешить один адрес из неё: разрешающее правило для адреса должно стоять выше запрещающего для подсети, иначе адрес попадёт под общий запрет. Планируйте порядок: сначала узкие разрешения для конкретных адресов, потом широкие запреты. Понимание, что правила проверяются по порядку, снимает большинство загадок с поведением фаервола.

Частые вопросы