Как восстановить доступ к серверу после блокировки ufw

Восстановление доступа

Если ufw заблокировал вам доступ к VPS, единственный способ вернуться — использовать консоль провайдера или режим восстановления (rescue mode), так как после активации блокирующего правила исправить ситуацию через SSH невозможно. Ядро отбрасывает пакеты до того, как они доходят до sshd, поэтому подключиться или выполнить удаленное исправление нельзя. Откройте консоль в панели управления провайдера, авторизуйтесь в системе и выполните одну команду.

sudo ufw disable

Вы должны увидеть Firewall stopped and disabled on system startup. Новые SSH-соединения заработают снова через секунду или две. Все настройки сохраняются: disable выгружает правила из ядра и записывает ENABLED=no в /etc/ufw/ufw.conf, при этом ваши правила остаются на диске в /etc/ufw/user.rules в ожидании следующего ufw enable.

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

Для консоли требуется пароль, который может отсутствовать

Веб-консоль (VNC или последовательный порт) — это клавиатура, подключенная к машине. Это не сетевой путь, поэтому правила firewall не могут его заблокировать. Однако для доступа требуется локальный логин, и именно здесь возникают проблемы при настройке только по ключам: если вы не задали пароль для пользователя sudo, а вход под root заблокирован, консоль отобразит запрос, на который вы не сможете ответить. Установите этот пароль сейчас, пока у вас есть доступ по SSH: sudo passwd yourname. Большинство панелей управления также позволяют сбросить пароль root, что обычно требует перезагрузки.

Если консоль недоступна, загрузитесь в систему восстановления (rescue system) провайдера. Она запускает отдельную операционную систему, в которой ваш диск не примонтирован, что позволяет отключить ufw извне.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Сначала выполните lsblk, так как корневой раздел не всегда /dev/vda1. Перезагрузитесь в обычную систему, и ufw останется выключенным, пока вы не включите его вручную.

Минимальная последовательность восстановления

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

1. sudo ufw disable для выгрузки правил и восстановления доступа.
2. sudo ufw show added для вывода добавленных вами правил в виде команд, с помощью которых они были созданы. Это работает, когда ufw неактивен, в отличие от ufw status.
3. sudo sshd -T | grep -i '^port' для подтверждения порта, на котором действительно ожидает подключений sshd. Команда выводит port 22, если вы не меняли настройки.
4. sudo ufw allow 22/tcp с использованием вашего реального порта, чтобы при следующем включении не повторилась блокировка.
5. sudo ufw enable с предварительно запланированным откатом. Инструкция приведена ниже на этой странице.

Что на самом деле делает ufw reset

ufw reset — это крайняя мера, а не первый шаг. Команда отключает межсетевой экран, создает резервные копии всех файлов правил и возвращает настройки по умолчанию: запрет входящих и разрешение исходящих соединений. Для каждого файла выводится одна строка с информацией о резервной копии:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

После сброса все правила разрешения удаляются. Выполняйте эту операцию из консоли, а не через SSH, и добавьте правило для SSH перед повторным включением. Резервные копии представляют собой обычные текстовые файлы. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 позволяет увидеть старые правила, что помогает восстановить конфигурацию, если вы удалили её по ошибке.

Где ufw хранит свои правила

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

• /etc/ufw/user.rules и /etc/ufw/user6.rules: правила, которые вы добавили, в порядке их обработки.
• /etc/ufw/before.rules и /etc/ufw/after.rules, а также варианты 6: инфраструктура, которую ufw оборачивает вокруг ваших правил, включая разрешение установленных соединений и правила для loopback.
• /etc/default/ufw: политики по умолчанию и переключатель IPV6.
• /etc/ufw/ufw.conf: ENABLED и уровень логирования.
• /var/log/ufw.log: информация о заблокированных пакетах, если включено логирование.

ufw создает копию файла с отметкой времени перед его перезаписью, поэтому ls /etc/ufw/ заполняется именами вроде user.rules.20260813_101500. Это ваша история отмен, и ее стоит изучить, прежде чем пытаться вернуть настройки в исходное состояние.

Чтобы увидеть правила, загруженные в ядро, а не те, что находятся на диске, используйте sudo ufw show raw или sudo iptables -S и sudo ip6tables -S. В Ubuntu 22.04 и 24.04 эти команды используют бэкенд nft, поэтому sudo nft list ruleset выводит те же правила в новом синтаксисе.

Почему включение ufw прервало мою SSH-сессию?

Политика по умолчанию для входящего трафика — deny. Включение ufw без правила для вашего SSH-порта блокирует все новые соединения. ufw выводит предупреждение: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Ответ y без добавления правила разрешения SSH — самая частая причина всех проблем, описанных на этой странице.

Запутывает именно задержка. /etc/ufw/before.rules принимает пакеты в состоянии ESTABLISHED,RELATED до того, как будут обработаны ваши собственные правила, поэтому сессия, в которой вы ввели команду, продолжает работать в обычном режиме. Блокировка обнаруживается только при попытке следующего подключения, что может произойти через несколько часов, и к этому моменту изменение настроек файрвола уже не кажется связанным с проблемой. Всегда открывайте вторую SSH-сессию и проверяйте её работоспособность перед тем, как закрыть первую.

Почему apt и DNS перестали работать после изменения политики?

sudo ufw default deny outgoing блокирует исходящие DNS-запросы (domain name system) и исходящий HTTP, поэтому разрешение имен прекращается, а обновление пакетов останавливается. apt update сообщает об ошибке Temporary failure resolving 'archive.ubuntu.com'. Входящий SSH продолжает работать, так как ответы на него имеют статус ESTABLISHED и проходят через правила фреймворка, из-за чего межсетевой экран кажется исправным, хотя именно он является причиной проблемы.

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

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Без последнего правила часы начнут отставать, а неверное время нарушит проверку TLS-сертификатов (transport layer security), поэтому curl начнет выдавать ошибки из-за дат, а не из-за портов. Этот симптом проявляется через несколько дней после внесения изменений, поэтому политика запрета исходящего трафика подходит для машин, которые вы постоянно отслеживаете, а не для серверов, настроенных один раз.

Почему мое правило ufw не срабатывает?

ufw проверяет пользовательские правила по порядку и останавливается на первом совпадении. Правило deny, добавленное после широкого правила allow, никогда не сработает, так как решение о разрешении пакета уже принято. Выведите список правил с номерами, а затем вставьте новое правило в нужную позицию.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

Команда sudo ufw --dry-run allow 8080/tcp выводит правила, которые будут применены, не внося никаких изменений. Это безопасный способ проверить правило перед его активацией.

Еще одна ловушка кроется в профилях приложений. sudo ufw allow OpenSSH использует профиль из /etc/ufw/applications.d/openssh-server, который соответствует порту 22. Если sshd слушает порт 2222, правило откроет порт, который никто не использует, и вы потеряете доступ к серверу при внешне корректном наборе правил. Используйте номер порта, если вы изменили стандартный порт. Остальные аспекты синтаксиса описаны в основах работы с межсетевым экраном ufw для VPS.

Почему правила IPv4 не объясняют то, что я вижу?

Потому что половина трафика — это не IPv4. Ubuntu поставляет IPV6=yes в /etc/default/ufw, и ufw поддерживает параллельный набор правил v6 в /etc/ufw/user6.rules. Правило, написанное с использованием IPv4-адреса, например ufw allow from 203.0.113.10 to any port 22, не создает никакого правила для v6. Если у вашего VPS есть запись AAAA, клиент отдает предпочтение IPv6, и соединение прерывается по таймауту, хотя ufw status показывает правило, которое выглядит корректным. Проверьте разницу с помощью ssh -4 user@host для ssh -6 user@host. Если первая команда работает, а вторая нет, значит, проблема в наборе правил v6.

Обратная ситуация хуже для безопасности. При IPV6=no ufw вообще не управляет ip6tables, поэтому политика v6 остается на уровне стандартного значения ядра ACCEPT. Порт, который, как вы считаете, закрыт, отвечает на своем IPv6-адресе, и ни одна команда ufw не будет упоминать об этом. Проверьте это с помощью sudo ip6tables -S и ss -tlnp и прочитайте как ufw обрабатывает порты IPv6 для получения полной картины.

Почему порт Docker открыт, если ufw его блокирует?

Docker публикует порт, записывая правила DNAT (destination network address translation) в таблицу nat и добавляя собственную цепочку в FORWARD. Правила ufw находятся в пути INPUT. Трафик к контейнеру перенаправляется, а не доставляется на хост, поэтому он никогда не попадает в цепочку, где находится ваше правило запрета. docker run -p 5432:5432 доступен из Интернета, даже если ufw активен и блокирует всё остальное.

sudo iptables -t nat -S DOCKER

Самое простое решение — публиковать порт на loopback: -p 127.0.0.1:5432:5432 привязывает сторону хоста к 127.0.0.1, и никто извне не сможет получить к нему доступ, независимо от настроек ufw. В статье Публикация портов Docker в обход ufw рассматриваются случаи, когда сервису действительно необходим публичный доступ.

Запланируйте откат перед применением правила

Эта привычка делает работу с межсетевым экраном безопасной. Перед внесением любых рискованных изменений запланируйте их отмену. Если изменения заблокируют вам доступ, система восстановится через 5 минут, и вам не придётся открывать консоль.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd выведет Running timer as unit: ufw-rollback.timer. Теперь внесите изменения. Если после этого вы можете открыть новую SSH-сессию, отмените откат:

sudo systemctl stop ufw-rollback.timer

Если открыть сессию не удаётся, подождите. ufw отключится самостоятельно, и следующая попытка подключения будет успешной. Классический трюк с shutdown -r +5 не поможет в работе с ufw, так как при загрузке ufw снова загружает тот же набор правил.

Обеспечение резервного способа доступа

• Войдите в консоль провайдера один раз до того, как она вам понадобится, и убедитесь, что пароль работает. Консоль, которую вы никогда не проверяли, не является резервным вариантом.
• Создайте второго пользователя с правами sudo и собственным ключом, чтобы повреждение одного файла authorized_keys не привело к потере доступа.
• Проверьте, использует ли ваш провайдер сетевой межсетевой экран в панели управления, работающий независимо от ufw. Он блокирует те же порты, но ufw status никогда не сообщит об этом.
• Не делайте ufw allow from <your home address> единственным правилом SSH, если этот адрес динамический. Провайдер может изменить его ночью, и вы потеряете доступ.

Лучшее время для выполнения всех этих действий — работа с новым сервером, параллельно с другими задачами из раздела первые десять минут на новом VPS.

Отказ или тайм-аут указывают на уровень, на котором произошёл сбой

Connection refused означает, что пакет достиг сервера, но что-то отправило в ответ TCP reset. Сетевой путь исправен, поэтому sshd остановлен или ожидает соединение на другом порту. Межсетевой экран редко является причиной, так как ufw по умолчанию отбрасывает пакеты, а не отклоняет их.

Connection timed out означает, что ответа не поступило вовсе. Это признак отбрасывания пакетов: ufw, сетевой экран провайдера или неверный адрес. Правильная интерпретация этих двух ошибок экономит час догадок, а разница между connection refused и timed out поможет разобраться в оставшихся случаях.

Включите логирование перед внесением следующих изменений

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Заблокированный пакет выглядит следующим образом:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 с вашим собственным адресом в SRC= является доказательством того, что именно ufw блокирует соединение, а не сеть или sshd. В минимальных образах без rsyslog файл /var/log/ufw.log отсутствует, и те же строки поступают из sudo journalctl -k | grep UFW. ufw ограничивает частоту записи собственных правил логирования, поэтому отсутствие строки не является доказательством того, что пакет был разрешён.

Если вы обнаружили правила, которые не добавляли

Изменение набора правил без вашего участия не является проблемой межсетевого экрана. Это сделал кто-то с правами root. Запустите sudo grep ufw /var/log/auth.log, чтобы увидеть, какие команды sudo выполнялись и от какой учетной записи, затем last для проверки входов в систему в это время. Если учетные записи не принадлежат никому из известных вам лиц, прекратите отладку межсетевого экрана и вместо этого выполните инструкции по проверке скомпрометированного VPS. Повторное включение межсетевого экрана на сервере, который контролирует кто-то другой, лишь скрывает проблему.

Восстановление конфигурации

После того как причина установлена, включите ufw снова таким образом, чтобы исключить повторную блокировку доступа. Разрешите ваш текущий порт SSH, запланируйте откат изменений, включите фаервол, а затем откройте новую SSH-сессию из другого терминала и убедитесь, что соединение устанавливается. Только после успешного подключения новой сессии закрывайте текущую. Оставьте логирование включенным на сутки: логи позволяют обнаружить забытые правила гораздо быстрее, чем чтение user.rules.

FAQ

Удаляет ли ufw disable мои правила?

Нет. disable выгружает набор правил из ядра и записывает ENABLED=no в /etc/ufw/ufw.conf. Ваши правила остаются в /etc/ufw/user.rules и /etc/ufw/user6.rules, а sudo ufw show added отображает их, пока межсетевой экран неактивен. ufw reset — это команда, которая очищает их, предварительно создавая резервную копию каждого файла и выводя строку вида Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Отменит ли перезагрузка VPS блокировку ufw?

Нет. ufw запускается при загрузке из ENABLED=yes в /etc/ufw/ufw.conf, поэтому те же правила загружаются до поднятия сети, и вы снова окажетесь заблокированы. Перезагрузка поможет только после того, как вы выключите ufw или отредактируете этот файл в режиме восстановления с примонтированным диском. Используйте консоль провайдера и выполните там sudo ufw disable.

Почему мой Docker-контейнер доступен, хотя ufw запрещает порт?

Docker записывает собственные правила DNAT и FORWARD для каждого опубликованного порта. Этот трафик перенаправляется в контейнер, а не доставляется на хост, поэтому он не проходит через цепочку INPUT, где находится ваше правило запрета ufw. Публикуйте порты на loopback с помощью -p 127.0.0.1:5432:5432, если порт предназначен только для хоста, и проверяйте правила, установленные Docker, с помощью sudo iptables -t nat -S DOCKER.

У меня нет пароля от консоли и режима восстановления. Какие есть варианты?

Оставшиеся варианты зависят от вашего провайдера: сброс пароля через панель управления, который обычно перезагружает сервер, или подключение диска к другому экземпляру, чтобы вы могли отредактировать /etc/ufw/ufw.conf оттуда. Обратитесь в поддержку перед тем, как переустанавливать сервер, так как переустановка уничтожит все данные на нём. Как только вы вернёте доступ, выполните sudo passwd yourname и один раз протестируйте вход через консоль, чтобы следующая блокировка отняла у вас не более двух минут.