Włączyłem ufw i teraz SSH się nie łączy. Straciłem serwer?

Nie. Serwer działa bez zarzutu — po prostu zamknąłeś drzwi od środka. Twoje dane są nietknięte. Otwórz konsolę webową w panelu (wchodzi bez SSH) i uruchom `sudo ufw disable`; już jesteś z powrotem w środku. Reinstalacja niepotrzebna.

Dlaczego włączenie ufw ubiło mi SSH?

ufw domyślnie odrzuca cały ruch przychodzący, a jeśli włączysz go bez wcześniejszego zezwolenia na swój port SSH, twoja własna sesja zostaje przerwana. To najczęstszy sposób zamknięcia się na klucz. Zawsze `ufw allow ` przed `ufw enable`.

Jak naprawić ufw, jeśli w ogóle nie mogę wejść przez SSH?

Użyj konsoli webowej out-of-band (konsoli szeregowej) w panelu — nie idzie przez SSH ani nawet przez stos sieciowy, więc reguła firewalla nie może jej zablokować. Zaloguj się, potem `sudo ufw disable` (najszybciej) albo `sudo ufw allow `, by poprawić konkretną regułę.

Na VPS z NAT który port zezwolić w ufw?

Zezwól na 22, nie na port zewnętrzny. W planie NAT łączysz się przez wysoki port jak 20266, ale jest on przekierowany na port 22 wewnątrz VM. ufw działa wewnątrz VM i widzi tylko 22. Zezwolenie na 20266 nic nie daje — zezwól na 22.

Czy `ufw reset` jest bezpieczniejszy niż `ufw disable`?

`disable` tylko wyłącza firewall i zachowuje twoje reguły — najszybszy powrót. `reset` czyści wszystkie reguły do wartości domyślnych. Do odzyskania użyj `disable`, a potem ostrożnie dodaj reguły z powrotem. `reset` tylko gdy zestaw reguł to bałagan do usunięcia.

Zablokowany przez ufw na własnym VPS? Wróć do środka bez reinstalacji

Jest taki rytuał przejścia dla każdego, kto po raz pierwszy prowadzi własny serwer: postanawiasz postawić firewall, wpisujesz kilka poleceń ufw, wciskasz enable — i terminal milknie. SSH zniknęło. Nic nie zepsułeś i nie zostałeś zhakowany. Po prostu zamknąłeś drzwi, z sobą na zewnątrz.

Zdarza się to nawet dobrym administratorom. W zeszłym tygodniu przydarzyło się jednemu z naszych klientów, dlatego to spisuję. Dobra wiadomość: da się to w pełni odzyskać w niecałą minutę i nie musisz stawiać serwera od nowa ani tracić ani jednego pliku. Oto jak.

Serwer zapieczętowany za ścianą firewalla, ze świecącym oknem konsoli jako drogą powrotną

Co poszło naprawdę nie tak

ufw (Uncomplicated Firewall) domyślnie odrzuca cały ruch przychodzący. W chwili, gdy uruchamiasz ufw enable, wszystko, na co nie zezwoliłeś jawnie, zostaje odrzucone — w tym sesja SSH, w której właśnie siedzisz. Jeśli zapomniałeś najpierw ufw allow na swój port SSH, przeciąłeś własne połączenie w momencie, gdy reguła zadziałała.

To wersja klasyczna. Dwie inne też łapią ludzi:

Zezwoliłeś na niewłaściwy port. Literówka, albo zezwoliłeś na port usługi (powiedzmy 8080) i zapomniałeś o 22.
Zezwoliłeś na 22, ale wyżej na liście umieściłeś regułę deny, która go przesłania. ufw jest wrażliwy na kolejność.

Tak czy siak sam serwer ma się dobrze — działa, dysk nietknięty, twoja aplikacja wciąż mruczy za ścianą. To czysto problem dostępu sieciowego. Właśnie dlatego naprawa jest łatwa.

Zły ruch: reinstalacja

Pierwszy odruch to często „to zresetuję serwer i zacznę od zera". Nie rób tego — nie do tego. Reinstalacja wymazuje wszystko, byle odzyskać działające SSH, podczas gdy SSH blokuje jedno polecenie firewalla, które cofniesz w dziesięć sekund. To jak spalić dom, bo zatrzasnąłeś drzwi wejściowe.

Reinstalacja jest słuszna, gdy chcesz czystej karty. Przy zablokowaniu ufw to armata na muchę.

Dobry ruch: konsola webowa

Każdy porządny VPS daje ci konsolę out-of-band — dostęp do maszyny, który nie idzie przez SSH ani nawet przez stos sieciowy. W EQVPS to przycisk Console na stronie twojego serwera. To konsola szeregowa: tylko tekst, podłączona wprost do VM jak monitor i klawiatura. Reguła firewalla nie ma nad nią władzy, bo to nie jest ruch sieciowy.

Kliknij, zaloguj się danymi root (albo odsłoń hasło w panelu, jeśli nie masz go pod ręką) — i jesteś na maszynie, z firewallem czy bez.

Teraz cofnij szkody. Najszybsza droga:

sudo ufw disable

To wyłącza firewall i zachowuje twoje reguły, byś mógł go później znów włączyć po poprawieniu błędu. SSH wraca od razu.

Jeśli wolisz nie ściągać całego firewalla, otwórz tylko port, który pominąłeś:

sudo ufw allow 22
sudo ufw status numbered

Warto spojrzeć na status numbered: pokazuje kolejność reguł — to tu kryją się przypadki „zezwoliłem na 22, a i tak blokuje". Jeśli nad twoim allow siedzi deny, usuń go: sudo ufw delete <numer>.

Pułapka NAT, którą pomija niemal każdy poradnik

Jeśli jesteś na planie NAT, czai się tu pułapka. Łączysz się przez SSH na wysokim porcie — coś jak 20266 — więc naturalny odruch to ufw allow 20266. To nic nie robi.

W NAT ten zewnętrzny port jest przekierowany na port 22 wewnątrz VM. ufw działa wewnątrz VM i zawsze widzi tylko 22. Reguła, której naprawdę potrzebujesz, to więc:

sudo ufw allow 22

Zezwól na 20266 i będziesz się gapił na wciąż zepsute połączenie, zastanawiając się dlaczego. Zezwól na 22 i jesteś w środku. Ta sama logika dla każdej usługi: zezwól na port, którego proces nasłuchuje wewnątrz maszyny, nie na przekierowany, przez który łączysz się z zewnątrz.

Jak nigdy więcej tego nie zrobić

Naprawa zajmuje minutę, ale lepiej jej nie potrzebować. Dwa nawyki:

Zezwól na swój port SSH przed włączeniem. Zawsze w tej kolejności:

sudo ufw allow 22
sudo ufw enable

Zrób odwrotnie, a wracasz do konsoli.

Trzymaj otwartą drugą sesję SSH podczas zmiany reguł firewalla. Zaloguj się dwa razy. Zmiany rób w jednym oknie; jeśli SSH padnie, drugie wciąż żyje, by to naprawić. Stara sztuczka, ratuje za każdym razem.

A jeśli stawiasz świeżą maszynę, nasza lista kontrolna bezpieczeństwa nowego VPS omawia ufw we właściwej kolejności, wraz z kluczami SSH i tą garstką innych rzeczy, które naprawdę liczą się w pierwszych dziesięciu minutach.

Wnioski

Zablokowanie ufw wygląda groźnie, a jest niemal niczym. Serwer nigdy nie zniknął; potrzebujesz tylko drzwi, których żaden firewall nie zatrzaśnie — konsoli webowej — i jednego polecenia. Trzymaj ufw disable i konsolę pod ręką, następnym razem zezwól na swój port przed włączeniem, a ta rzecz nigdy więcej nie przyprawi cię o pot.