Включих ufw и сега SSH няма да се свърже. Загубих ли сървъра?

Не. Сървърът работи добре — просто заключи вратата отвътре. Данните ти са недокоснати. Отвори уеб конзолата в контролния си панел (тя те вкарва без SSH) и пусни `sudo ufw disable`, и си обратно. Не е нужна преинсталация.

Защо включването на ufw уби SSH-а ми?

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

Как да поправя ufw, ако изобщо не мога да вляза по SSH?

Използвай out-of-band уеб конзолата (серийна конзола) в панела си — тя не минава през SSH, нито дори се нуждае от мрежовия стек, така че firewall правило не може да я блокира. Влез там, после `sudo ufw disable` (най-бързо) или `sudo ufw allow `, за да поправиш конкретното правило.

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

Разреши 22, не външния порт. На NAT план се свързваш на висок порт като 20266, но той е пренасочен към порт 22 вътре във VM-а. ufw работи вътре във VM-а и вижда само 22. Разрешаването на 20266 не прави нищо; разреши 22.

По-безопасен ли е `ufw reset` от `ufw disable`?

`disable` просто изключва firewall-а и запазва правилата ти — най-бързият път обратно вътре. `reset` изтрива всяко правило до по подразбиране. Използвай `disable`, за да се възстановиш, после добави правилата отново внимателно. `reset` само ако правилата са бъркотия, която искаш да изчезне.

Заключен извън VPS-а си от ufw? Върни се вътре без преинсталация

Има обред на посвещение за всеки нов в пускането на собствен сървър: решаваш да настроиш firewall, набираш няколко ufw команди, натискаш enable — и терминалът ти замлъква. SSH го няма. Не си сринал нищо, не си хакнат. Просто заключи вратата със себе си отвън.

Случва се и на добри sysadmins. Случи се на един от клиентите ни миналата седмица, затова го записвам. Добрата новина: напълно възстановимо е за под минута, и не ти трябва преинсталация, нито губиш нито един файл. Ето как.

VPS, запечатан зад firewall стена, със светеща конзолна прозорец като пътя обратно вътре

Какво всъщност се обърка

ufw (Uncomplicated Firewall) по подразбиране отказва целия входящ. В мига, в който пуснеш ufw enable, всичко, което не си разрешил изрично, се изхвърля — включително SSH сесията, в която седиш. Ако си забравил да ufw allow SSH порта си първо, си прекъснал собствената си връзка в момента, в който правилото влезе в сила.

Това е класическата версия. Има още две разновидности, които хващат хората:

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

И в двата случая самият сървър е наред — работещ, диск непокътнат, приложението ти все още жужи зад стената. Чисто проблем с мрежов достъп е. Точно затова поправката е лесна.

Грешният ход: преинсталация

Първият инстинкт често е „просто нулирай сървъра и започни отначало.“ Недей — не за това. Преинсталацията изтрива всичко, за да върне работещ SSH, когато нещото, което блокира SSH, е една firewall команда, която можеш да отмениш за десет секунди. Ще изгориш къщата, защото си заключил входната врата.

Преинсталацията е правилният избор, когато искаш чист старт. За ufw заключване е прекалено много.

Правилният ход: уеб конзолата

Всеки VPS, който си струва, ти дава out-of-band конзола — начин към машината, който не се движи през SSH, нито дори мрежовия стек. На EQVPS това е бутонът Console на страницата на сървъра ти. Това е серийна конзола: само текст, свързана направо към VM-а, както монитор и клавиатура биха били. Firewall правило няма власт над нея, защото не е мрежов трафик.

Щракни го, влез с root credentials-ите си (или покажи паролата в панела, ако не ти е под ръка), и си на машината — firewall или не.

Сега отмени щетата. Най-бърз път:

sudo ufw disable

Това изключва firewall-а и запазва правилата ти, така че можеш да го включиш пак по-късно, щом поправиш грешката. SSH се връща веднага.

Ако предпочиташ да не изключваш firewall-а изцяло, просто отвори порта, който си пропуснал:

sudo ufw allow 22
sudo ufw status numbered

Изгледът status numbered си струва да се погледне — той показва реда на правилата, където се крият случаите „разреших 22, но все още блокира“. Ако deny седи над твоя allow, изтрий го с sudo ufw delete <number>.

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

Направи го наопаки и си обратно в конзолата.

Дръж втора сесия отворена, докато сменяш firewall правила. Влез два пъти. Направи промените в един прозорец; ако SSH умре, другият прозорец е все още жив, за да го поправи. Стар трик, спасява те всеки път.

И ако настройваш свежа машина, нашият checklist за сигурност на нов VPS покрива ufw в правилния ред, заедно със SSH ключове и шепата други неща, които реално имат значение в първите десет минути.

Изводът

ufw заключване изглежда страшно и е почти нищо. Сървърът никога не си е тръгвал; просто ти трябва врата, която firewall не може да затръшне — уеб конзолата — и една команда. Дръж ufw disable и конзолата в задния си джоб, разреши порта си, преди да включиш следващия път, и никога повече няма да се потиш за това.