Включил ufw и теперь SSH не подключается. Сервер потерян?

Нет. Сервер работает как ни в чём не бывало — ты просто закрыл дверь изнутри. Данные целы. Открой веб-консоль в панели (она пускает внутрь без SSH) и выполни `sudo ufw disable` — ты снова в деле. Переустанавливать не нужно.

Почему включение ufw убило SSH?

ufw по умолчанию блокирует весь входящий трафик, и если включить его, не разрешив сначала свой SSH-порт, твоя же сессия обрывается. Это самый частый способ запереть себя. Всегда `ufw allow ` до `ufw enable`.

Как починить ufw, если по SSH вообще не зайти?

Через веб-консоль (serial console) в панели — она идёт мимо SSH и даже мимо сетевого стека, поэтому правило файрвола её не заблокирует. Заходишь туда и делаешь `sudo ufw disable` (быстрее всего) или `sudo ufw allow `, чтобы поправить конкретное правило.

На NAT-VPS какой порт разрешать в ufw?

Разрешай 22, а не внешний порт. На NAT-тарифе ты подключаешься на высокий порт вроде 20266, но он проброшен на порт 22 внутри VM. ufw работает внутри VM и видит только 22. Разрешить 20266 бесполезно — разрешай 22.

`ufw reset` безопаснее, чем `ufw disable`?

`disable` просто выключает файрвол и сохраняет правила — самый быстрый способ вернуться. `reset` стирает все правила до умолчаний. Для восстановления используй `disable`, потом аккуратно верни правила. `reset` — только если набор правил превратился в кашу, которую хочется снести.

Заблокировали себе доступ к VPS через ufw? Вернитесь без переустановки

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

Это случается и с опытными. На прошлой неделе так залип один наш клиент — поэтому и пишу. Хорошая новость: всё чинится меньше чем за минуту, и переустанавливать или терять файлы не нужно. Вот как.

Сервер за стеной-файрволом, и светящееся окно консоли как путь обратно внутрь

Что на самом деле произошло

ufw (Uncomplicated Firewall) по умолчанию режет весь входящий. Как только ты делаешь ufw enable, всё, что ты явно не разрешил, отбрасывается — включая ту самую SSH-сессию, в которой ты сидишь. Забыл сначала ufw allow свой SSH-порт — и в момент применения правила обрубил себе связь.

Это классика. Есть ещё пара вариантов, на которых спотыкаются:

Разрешил не тот порт. Опечатка, или разрешил порт сервиса (скажем, 8080) и забыл про 22.
Разрешил 22, но выше по списку поставил правило deny, которое его перекрыло. ufw чувствителен к порядку.

В любом случае сам сервер в порядке — работает, диск цел, приложение так и гудит за стеной. Это чисто проблема сетевого доступа. Именно поэтому чинится легко.

Неверный ход: переустановка

Первый порыв часто — «да просто сброшу сервер и начну заново». Не надо — не в этом случае. Переустановка стирает всё ради того, чтобы вернуть рабочий SSH, тогда как блокирует его одна команда файрвола, которую можно отменить за десять секунд. Это как сжечь дом из-за того, что защёлкнул входную дверь.

Переустановка уместна, когда тебе нужен чистый лист. Для ufw-локаута это перебор.

Верный ход: веб-консоль

Любой приличный VPS даёт внеполосную консоль — вход в машину, который не идёт через SSH и даже через сетевой стек. На EQVPS это кнопка Console на странице сервера. Это serial-консоль: только текст, подключена прямо к VM, как монитор с клавиатурой. Правило файрвола над ней не властно — это не сетевой трафик.

Жмёшь, логинишься под root (или раскрываешь пароль в панели, если его нет под рукой) — и ты на машине, с файрволом или без.

Теперь откати последствия. Самый быстрый путь:

sudo ufw disable

Это выключает файрвол и сохраняет правила, так что позже можно включить его снова, поправив ошибку. SSH сразу возвращается.

Если не хочешь ронять файрвол целиком — просто открой пропущенный порт:

sudo ufw allow 22
sudo ufw status numbered

На status numbered стоит взглянуть: он показывает порядок правил — там и прячутся случаи «разрешил 22, а оно всё равно блокирует». Если deny стоит выше твоего allow, удали его: sudo ufw delete <номер>.

Подвох NAT, о котором молчат гайды

Если ты на NAT-тарифе, тут ловушка. По SSH ты заходишь на высокий порт — что-то вроде 20266 — и рука тянется написать ufw allow 20266. Это ничего не делает.

На NAT этот внешний порт проброшен на порт 22 внутри VM. ufw крутится внутри VM и видит только 22. Так что нужно именно:

sudo ufw allow 22

Разрешишь 20266 — будешь смотреть на всё так же не работающее соединение и гадать, почему. Разрешишь 22 — ты внутри. Та же логика для любого сервиса: разрешай порт, который процесс слушает внутри машины, а не проброшенный, на который ты подключаешься снаружи.

Как больше так не влипать

Починка занимает минуту, но лучше, когда она не нужна. Две привычки:

Разрешай SSH-порт до включения. Всегда в таком порядке:

sudo ufw allow 22
sudo ufw enable

Сделаешь наоборот — снова пойдёшь в консоль.

Держи вторую SSH-сессию открытой, пока правишь правила. Залогинься дважды. Меняешь в одном окне; если SSH умрёт, второе окно ещё живо и всё поправит. Старый трюк, спасает каждый раз.

А если поднимаешь свежую машину — наш чек-лист по безопасности нового VPS разбирает ufw в правильном порядке, вместе с SSH-ключами и парой других вещей, которые реально важны в первые десять минут.

Вывод

ufw-локаут выглядит страшно, а по сути — почти ничто. Сервер никуда не девался; нужна лишь дверь, которую файрвол не захлопнет — веб-консоль — и одна команда. Держи ufw disable и консоль в заднем кармане, разрешай порт до включения в следующий раз — и эта штука больше не заставит тебя нервничать.