Увімкнув 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 і консоль у задній кишені, дозволяй порт до вмикання наступного разу — і ця штука більше не змусить тебе нервувати.