Konfiguracja firewalld w Rocky Linux i AlmaLinux

Czym jest firewalld i dlaczego Rocky oraz AlmaLinux go dostarczają

firewalld to menedżer zapory sieciowej instalowany domyślnie w systemach Rocky Linux, AlmaLinux oraz innych dystrybucjach bazujących na Red Hat Enterprise Linux (RHEL). Obie dystrybucje odziedziczyły to ustawienie domyślne, co staje się zrozumiałe po zapoznaniu się z informacją w jaki sposób Rocky i AlmaLinux zaczęły odtwarzać prace Red Hat po zmianie kierunku projektu CentOS. Narzędzie to nie analizuje pakietów samodzielnie. Przechowuje zapisaną konfigurację i przekłada ją na reguły nftables. Jedno polecenie, firewall-cmd, pozwala na edycję konfiguracji bez przerywania pracy serwera. Treść tego przewodnika jest identyczna dla obu dystrybucji, ponieważ rzeczy, które faktycznie odróżniają Rocky od AlmaLinux, to obietnica kompatybilności oraz zakres wspieranych procesorów, a nie zapora sieciowa.

Jeśli znasz już zasadę działania ufw na serwerze VPS z Ubuntu, znasz cel tego narzędzia. firewalld wprowadza dwie koncepcje, których ufw nie posiada. Pierwszą są strefy: nazwane polityki, do których przypisywane są pakiety. Drugą jest podział na reguły aktywne i zapisane, co wiąże się z flagą --permanent i stanowi najczęstsze źródło nieporozumień przy korzystaniu z tego narzędzia.

Wszystkie poniższe polecenia należy wykonać na własnym serwerze. Każda zmiana powinna być testowana z poziomu drugiego urządzenia, ponieważ reguła, która wydaje się poprawna lokalnie, może być błędna z perspektywy Internetu.

Otwórz SSH przed wykonaniem jakichkolwiek innych działań

Większość instalacji Rocky i AlmaLinux posiada domyślnie zainstalowany i uruchomiony firewalld, a dostarczona konfiguracja zezwala na połączenia SSH. Niektóre minimalne obrazy chmurowe usuwają to ustawienie. Należy to sprawdzić, zamiast zakładać, że tak jest.

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --state

firewall-cmd --state wyświetla running. Jeśli usługa jest zatrzymana, każde inne wywołanie firewall-cmd zwraca FirewallD is not running i kończy działanie z kodem błędu. Jest to pierwsza rzecz do sprawdzenia, gdy polecenie wydaje się nie wywoływać żadnego efektu.

Teraz należy sprawdzić, co jest aktualnie dozwolone.

sudo firewall-cmd --list-all

Rzeczywiste wyjście zawiera kilka dodatkowych linii. Istotne są następujące:

public (active)
  target: default
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  rich rules:

ssh w linii services: jest powodem, dla którego bieżąca sesja nadal działa. Jeśli tego brakuje, należy dodać tę regułę przed wykonaniem jakichkolwiek innych zmian, ponieważ uruchomienie firewalla bez reguły SSH zakończy sesję i uniemożliwi ponowne połączenie.

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

target: default oznacza, że pakiet niepasujący do żadnej reguły jest odrzucany z odpowiedzią ICMP (internet control message protocol) typu host-prohibited, dzięki czemu klient próbujący połączyć się z zamkniętym portem natychmiast otrzymuje No route to host. Ustawienie celu na DROP sprawia, że serwer pozostaje „milczący”, a skanery oczekują na przekroczenie limitu czasu (timeout).

sudo firewall-cmd --permanent --zone=public --set-target=DROP
sudo firewall-cmd --reload

Przed wykonaniem tego polecenia należy znać konsekwencje: DROP powoduje również, że serwer przestaje odpowiadać na ping, przez co własne systemy monitoringu również przestaną otrzymywać odpowiedzi.

Dlaczego moja reguła zniknęła? Flaga --permanent

firewalld przechowuje jednocześnie dwie konfiguracje. Konfiguracja runtime to zestaw reguł egzekwowany przez jądro w danej chwili. Konfiguracja permanent to zestaw zapisany w /etc/firewalld/zones/public.xml, który jest przywracany po przeładowaniu lub restarcie systemu.

Polecenie bez flagi --permanent zmienia tylko konfigurację runtime. Zmiana działa natychmiast, ale znika po przeładowaniu lub restarcie. Polecenie z flagą --permanent zapisuje zmiany w pliku, ale nie wpływa na działające reguły, więc port pozostaje zamknięty do momentu przeładowania. Żadne z tych zachowań nie jest błędem. Oba zaskakują użytkowników, ponieważ polecenie w obu przypadkach wyświetla success.

Zawsze stosuj obie opcje jednocześnie.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

Można odczytać obie konfiguracje, co jest najszybszym sposobem na zdiagnozowanie popełnionego błędu.

sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --list-services

Pierwsze polecenie wyświetla aktywny zestaw reguł. Drugie wyświetla zestaw zapisany. Jeśli aktywny zestaw zawiera usługę, której nie ma w zestawie zapisanym, reguła zniknie przy następnym przeładowaniu. Jeśli zapisany zestaw zawiera usługę, której nie ma w aktywnym, oznacza to pominięcie przeładowania. Polecenie sudo firewall-cmd --runtime-to-permanent kopiuje wszystkie aktywne reguły do pliku zapisanego, co jest przydatne po zakończeniu sesji testowej.

Polecenie --reload zachowuje stan śledzenia połączeń, dzięki czemu sesja SSH nie zostanie przerwana. Polecenie --complete-reload przeładowuje również moduły jądra i traci ten stan, co zazwyczaj zrywa wszystkie otwarte połączenia, w tym bieżącą sesję. Należy używać zwykłego przeładowania.

Wbudowano jeden mechanizm bezpieczeństwa. Reguła runtime może wygasnąć automatycznie.

sudo firewall-cmd --add-service=http --timeout=5m

Ta reguła usuwa się sama po pięciu minutach. Nie można jej łączyć z flagą --permanent i o to właśnie chodzi: służy ona do testowania zmian, co do których nie ma pewności. Starszy mechanizm bezpieczeństwa jest skuteczniejszy. Podczas edycji reguł należy utrzymywać otwartą drugą sesję SSH i nie zamykać jej, dopóki nowe reguły nie zostaną zweryfikowane poprzez poprawne logowanie.

Strefy i dlaczego na VPS liczy się tylko strefa domyślna

Strefa to nazwany zestaw uprawnień z przypisanym poziomem zaufania. firewalld przypisuje każdy przychodzący pakiet do dokładnie jednej strefy. Najpierw dopasowuje adres źródłowy pakietu do listy sources: każdej strefy. Jeśli nie znajdzie dopasowania, używa strefy przypisanej do interfejsu, przez który wszedł pakiet. Jeśli interfejs nie jest przypisany do żadnej strefy, pakiet trafia do strefy domyślnej.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones

Na serwerze VPS z jednym interfejsem sieciowym odpowiedzią jest niemal zawsze public i jest to jedyna strefa, z której będziesz korzystać. firewall-cmd bez argumentu --zone= działa na strefie domyślnej, dlatego każde krótkie polecenie w tym przewodniku działa bez konieczności podawania nazwy strefy.

Oto błąd, który marnuje popołudnie. Jeśli interfejs jest przypisany do innej strefy, Twoje reguły trafiają do public, podczas gdy ruch jest obsługiwany gdzie indziej. W rezultacie dodane reguły nie działają, a system nie wyświetla żadnego ostrzeżenia. --get-active-zones pokazuje przypisanie:

public
  interfaces: eth0

Jeśli interfejs widnieje pod inną nazwą strefy, albo dopisz swoje reguły w tej strefie za pomocą --zone=, albo przenieś interfejs.

sudo firewall-cmd --permanent --zone=public --change-interface=eth0
sudo firewall-cmd --reload

NetworkManager zarządza interfejsami w systemach Rocky i AlmaLinux i przywraca strefę przy podnoszeniu połączenia. Ustaw strefę również tam, aby restart nie cofnął wprowadzonych zmian. Nazwę połączenia pobierz z pierwszego polecenia, ponieważ rzadko jest ona taka sama jak nazwa urządzenia.

sudo nmcli connection show
sudo nmcli connection modify "System eth0" connection.zone public

Dopasowanie źródła ma wyższy priorytet niż dopasowanie interfejsu, co pozwala na zastosowanie innej polityki dla konkretnego adresu. Wbudowana strefa trusted akceptuje wszystko.

sudo firewall-cmd --permanent --zone=trusted --add-source=203.0.113.10/32
sudo firewall-cmd --reload

Zachowaj ostrożność w tym przypadku. Otwiera to wszystkie porty na serwerze dla danego adresu, w tym bazę danych, która miała być prywatna. Użyj reguły typu rich rule, jeśli chcesz otworzyć jeden port, a nie cały host.

Czym jest usługa w firewalld?

Usługa to nazwany zestaw portów dostarczany w formie pliku XML. --add-service=https otwiera port 443/tcp, ponieważ /usr/lib/firewalld/services/https.xml definiuje, co oznacza https.

sudo firewall-cmd --get-services
sudo firewall-cmd --info-service=https

--info-service wyświetla porty ukryte pod daną nazwą:

https
  ports: 443/tcp

Należy używać nazwy, jeśli jest dostępna. Zwiększa to czytelność konfiguracji w --list-all po sześciu miesiącach, a pakiety takie jak Cockpit instalują własne pliki usług. Do wszystkiego, co nie posiada definicji, należy używać --add-port.

Należy uważać na różnice: usługa ssh oznacza wyłącznie port 22/tcp. Jeśli SSH zostało przeniesione na inny port w ramach utwardzania dostępu SSH do serwera, to --add-service=ssh nie otworzy portu, który jest faktycznie używany.

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

W systemach typu RHEL istnieje dodatkowe zabezpieczenie. SELinux (Security-Enhanced Linux) przypisuje etykiety do numerów portów, a sshd nie może powiązać się z portem wykraczającym poza jego etykiety. W takim przypadku usługa odmawia startu, a dziennik zawiera komunikat error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.. Należy najpierw nadać etykietę portowi.

sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

Jak sprawdzić, co jest obecnie otwarte?

sudo firewall-cmd --list-all
sudo firewall-cmd --list-rich-rules
sudo nft list table inet firewalld | head -n 40

Pierwsze dwa polecenia raportują stan według firewalld. Trzecie odczytuje reguły faktycznie załadowane do jądra w tablicy zarządzanej przez firewalld. Wyniki powinny być zgodne.

Żadne z nich nie stanowi ostatecznego dowodu. Należy przeprowadzić test z innej maszyny:

nc -zv 203.0.113.20 443

Nie należy uruchamiać testu na samym serwerze. firewalld akceptuje cały ruch przychodzący na interfejs loopback, więc curl http://localhost:8080 zakończy się powodzeniem niezależnie od ustawionych reguł. Taki test potwierdza jedynie, że usługa działa. Nie dostarcza żadnych informacji na temat konfiguracji firewalla.

Zezwalanie na port WWW

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Ostatnie polecenie powinno teraz wyświetlić http https obok wcześniejszych wpisów. Jeśli witryna nadal nie odpowiada, problemem prawdopodobnie nie jest firewall. Reguła jedynie zezwala na przepływ pakietów. Proces nadal musi nasłuchiwać na danym porcie.

sudo ss -tlnp

Gniazdo oznaczone jako 0.0.0.0:443 lub *:443 akceptuje połączenia z dowolnego adresu. Gniazdo oznaczone jako 127.0.0.1:443 odpowiada tylko na interfejsie loopback i żadna reguła firewalla nie sprawi, że będzie ono dostępne z zewnątrz. Artykuł Porty i gniazda nasłuchujące w systemie Linux szczegółowo omawia tę różnicę.

Jak ponownie zamknąć port?

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --reload

Zasada --permanent ma tutaj również zastosowanie i w tym kierunku jej skutki są bardziej dotkliwe. Usunięcie usługi wyłącznie z bieżącego środowiska uruchomieniowego sprawia, że port wydaje się zamknięty, jednak kolejne przeładowanie lub restart systemu otworzy go ponownie na podstawie zapisanego pliku. Jest to luka, której można nie zauważyć, ponieważ wykonana kontrola zakończyła się powodzeniem.

Usunięcie elementu, który nigdy nie istniał, powoduje wyświetlenie komunikatu Warning: NOT_ENABLED: http i nadal kończy się kodem wyjścia 0. Dodanie tego samego elementu dwukrotnie powoduje wyświetlenie komunikatu Warning: ALREADY_ENABLED: http. Oba przypadki są bezpieczne. Błędnie wpisana nazwa to inna sytuacja: Error: INVALID_SERVICE oznacza, że firewalld nie posiada definicji o takiej nazwie i żadne zmiany nie zostały wprowadzone.

Jeśli polecenie --list-all wykazuje cockpit, a konsola internetowa Cockpit na porcie 9090 nie jest używana, należy ją usunąć. Każdy otwarty port to usługa, którą trzeba utrzymywać w stanie aktualnym pod kątem poprawek bezpieczeństwa. W przypadku usług, które mają pozostać aktywne, dnf-automatic może instalować aktualizacje bezpieczeństwa zgodnie z harmonogramem, dzięki czemu to zadanie nie zależy od pamięci administratora. Instalacja poprawki nie jest jednak równoznaczna z jej uruchomieniem, dlatego needs-restarting wskazuje, które usługi nadal korzystają ze starych bibliotek po wdrożeniu aktualizacji.

Ograniczenie portu do jednego adresu źródłowego

Reguły typu rich rules stanowią rozszerzoną formę konfiguracji, stosowaną w sytuacjach, gdy nazwa usługi nie pozwala na precyzyjne określenie wymagań. Ograniczenie dostępu do SSH dla jednego adresu biurowego wymaga wykonania dwóch poleceń, przy czym drugie z nich jest często pomijane.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Strefa stanowi zbiór uprawnień, a nie listę numerowaną, która kończy działanie na pierwszym dopasowaniu. Reguła typu rich rule dodaje akceptację dla konkretnego adresu. Nie odrzuca ona nikogo innego. Dopóki ssh znajduje się w linii services:, cały Internet nadal ma dostęp do portu 22, a reguła typu rich rule nie zmienia niczego w mierzalny sposób. Należy usunąć ogólny wpis, w przeciwnym razie wpis szczegółowy będzie jedynie dekoracją.

W przypadku portu, który nie posiada nazwy usługi, należy wskazać numer portu.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="5432" protocol="tcp" accept'

Aby odrzucić ruch z uciążliwej sieci i zachować jego rejestrację, należy umieścić element log przed akcją, zgodnie z kolejnością wymaganą przez składnię reguł typu rich rule.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" log prefix="fw-drop " level="info" limit value="3/m" drop'
sudo firewall-cmd --reload
sudo journalctl -k -g fw-drop

Wartość limit zapobiega zalaniu dziennika zdarzeń przez nadmiar pakietów. Przed zablokowaniem dostępu do SSH dla pojedynczego adresu należy upewnić się, że adres ten jest stabilny. Połączenie domowe ze zmiennym adresem IP spowoduje utratę dostępu w momencie jego zmiany, dlatego należy najpierw przetestować i zapewnić działanie dostępu przez konsolę u dostawcy usług.

Polecenia ufw i ich odpowiedniki w firewall-cmd

Te same zadania, inne narzędzie. Każda linia --permanent wymaga użycia sudo firewall-cmd --reload, czego lista tego typu nie jest w stanie przedstawić.

• sudo ufw enable zmienia się w sudo systemctl enable --now firewalld
• sudo ufw disable zmienia się w sudo systemctl disable --now firewalld
• sudo ufw status verbose zmienia się w sudo firewall-cmd --list-all
• sudo ufw allow OpenSSH zmienia się w sudo firewall-cmd --permanent --add-service=ssh
• sudo ufw allow 443/tcp zmienia się w sudo firewall-cmd --permanent --add-port=443/tcp
• sudo ufw delete allow 443/tcp zmienia się w sudo firewall-cmd --permanent --remove-port=443/tcp
• sudo ufw allow from 203.0.113.10 to any port 22 zmienia się w przedstawioną powyżej regułę typu rich rule
• sudo ufw reload zmienia się w sudo firewall-cmd --reload
• sudo ufw default deny incoming to domyślne zachowanie strefy public, a --set-target=DROP jest jej cichą wersją
• sudo ufw logging on zmienia się w sudo firewall-cmd --set-log-denied=all

Warto wyraźnie zaznaczyć jedną różnicę. ufw utrzymuje numerowaną listę, co pozwala na wstawienie reguły na pierwszą pozycję. firewalld nie posiada numeracji reguł, więc polecenie "umieść tę regułę na początku" nie ma tutaj zastosowania. Gdy dwa wpisy w firewalld wydają się sprzeczne, wygrywa zezwolenie (accept), ponieważ w tym zestawie nie istnieje mechanizm odrzucenia (deny). Szeroki wpis należy usunąć samodzielnie.

Dlaczego mój kontener Docker jest dostępny, mimo że firewall wydaje się zamknięty?

Ponieważ opublikowany port kontenera nigdy nie dociera do części firewalla, którą zarządza Twoja strefa. docker run -d -p 8080:80 nginx nakazuje programowi Docker zapisanie własnych reguł NAT (network address translation) oraz przekierowań. Pakiet docierający na port 8080 jest przepisywany i kierowany bezpośrednio do kontenera, więc jest przekazywany (forwarded), a nie dostarczany do hosta. Linie services: oraz ports: w Twojej strefie regulują pakiety dostarczane do hosta. Reguły Dockera regulują ścieżkę przekazywania i akceptują ruch.

Efektem jest serwer, na którym sudo firewall-cmd --list-all nie wykazuje portu 8080, a polecenie nc -zv 203.0.113.20 8080 z innej maszyny mimo to nawiązuje połączenie. Sprawdź, co zainstalował Docker:

sudo iptables -t nat -L DOCKER -n

Rozwiązanie znajduje się we fladze publikowania. Powiąż port z interfejsem loopback i umieść przed nim reverse proxy.

docker run -d -p 127.0.0.1:8080:80 nginx

Kontener odpowiada teraz na curl http://127.0.0.1:8080 na serwerze i nie reaguje na połączenia z zewnątrz. Użytkownicy Ubuntu napotykają ten sam problem, opisany w dlaczego kontenery Docker publikują porty z pominięciem ufw. Podman działający z uprawnieniami root, który jest dostępny w podstawowych repozytoriach systemów Rocky i AlmaLinux, publikuje porty przy użyciu tego samego mechanizmu NAT, dlatego należy przeprowadzić test z innej maszyny, zamiast polegać na liście stref. To nakładanie się reguł jest również powodem, dla którego instalacja Docker Engine na tych dystrybucjach wymaga kilku kroków, o których nie wspominają poradniki dla Ubuntu, począwszy od faktu, że Podman już zajmuje komendę docker.

Zapewnienie trwałości po restarcie i typowe błędy

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

enabled oraz active (running) to polecenia, których należy użyć. Firewall, który działa, ale nie jest włączony do autostartu, chroni serwer tylko do pierwszego restartu. Weryfikacja tego stanu powinna znaleźć się na liście zadań wykonywanych w pierwszych dziesięciu minutach na nowym VPS, obok konfiguracji kluczy SSH i aktualizacji systemu.

Bezpośrednie polecenia nftables i firewalld nie współpracują ze sobą. firewalld zarządza tablicą o nazwie inet firewalld. sudo nft flush ruleset usuwa tę tablicę, co otwiera serwer na cały ruch, podczas gdy firewall-cmd --list-all nadal wyświetla zamierzoną konfigurację, ponieważ firewalld raportuje swój stan wewnętrzny, a nie faktyczny stan jądra systemu. sudo firewall-cmd --reload przywraca reguły. Reguły należy definiować za pomocą firewall-cmd, aby były one odtwarzane po przeładowaniu usługi.

Dwa systemy zarządzania firewallem na jednym serwerze. Instalacja ufw lub iptables-services obok firewalld powoduje, że dwa programy modyfikują reguły bez wzajemnej świadomości, a ostateczny stan zależy od tego, która usługa uruchomiła się jako ostatnia. Należy wybrać jedno rozwiązanie. W systemach Rocky i AlmaLinux wsparcie dystrybucji posiada firewalld.

Firewall dostawcy przed serwerem. Wiele paneli VPS posiada niezależny firewall sieciowy. Jeśli --list-all wskazuje, że port jest otwarty, a połączenie z zewnątrz nadal nie działa, należy sprawdzić panel przed wprowadzeniem zmian na serwerze. Działa to również w drugą stronę: otwarta reguła w panelu nie przyniesie efektu, jeśli firewalld odrzuca pakiety.

Uruchamianie firewall-cmd bez sudo. Każda zmiana wymaga uprawnień root. W przeciwnym razie żądanie zostanie odrzucone przez mechanizm autoryzacji i żadna zmiana nie zostanie wprowadzona, co na pierwszy rzut oka może wyglądać tak, jakby polecenie zostało zignorowane.

Sześć poleceń wystarcza do większości codziennych zadań: --list-all do odczytu stanu, --permanent --add-service lub --add-port do otwarcia portu, --permanent --remove-service do jego zamknięcia, --reload do zastosowania zapisanego pliku konfiguracji oraz --runtime-to-permanent po zakończeniu serii testów. Domyślna strefa to public, flaga to --permanent, a jedyną wiarygodną weryfikację połączenia można przeprowadzić z innej maszyny.

FAQ

Dlaczego moja reguła firewalld zniknęła po restarcie?

Reguła została dodana tylko do konfiguracji uruchomieniowej. sudo firewall-cmd --add-service=http działa natychmiast, ale jest odrzucana przy kolejnym przeładowaniu lub restarcie, ponieważ zapisana konfiguracja w /etc/firewalld/zones/public.xml nie została zmodyfikowana. Należy dodać --permanent, a następnie wykonać sudo firewall-cmd --reload. Aby zachować reguły dodane ręcznie, należy wykonać sudo firewall-cmd --runtime-to-permanent, co skopiuje bieżący zestaw reguł do pliku zapisanego.

Dlaczego nic się nie zmienia po dodaniu reguły z flagą --permanent?

Ponieważ --permanent zapisuje plik, ale nie modyfikuje działającego firewalla. Port pozostaje zamknięty, dopóki sudo firewall-cmd --reload nie załaduje zapisanej konfiguracji do jądra systemu. Należy porównać sudo firewall-cmd --list-services z sudo firewall-cmd --permanent --list-services: jeśli zapisana lista zawiera wpis, którego nie ma na liście aktywnej, oznacza to, że brakuje operacji przeładowania.

Czy używać --add-service czy --add-port?

Należy użyć --add-service, gdy istnieje nazwa dla uruchamianej usługi. Określa ona intencję, a sudo firewall-cmd --info-service=https pokazuje dokładnie, które porty obejmuje dana nazwa. Należy użyć --add-port, gdy usługa nie jest zdefiniowana lub nasłuchuje na niestandardowym porcie. Usługa ssh oznacza tylko 22/tcp, więc w przypadku przeniesienia SSH na port 2222 wymagane jest --add-port=2222/tcp oraz odpowiednia etykieta SELinux dla tego portu.

Dlaczego mój kontener Docker jest osiągalny, mimo że firewall-cmd pokazuje, iż port jest zamknięty?

Opublikowany port jest nadpisywany przez własne reguły NAT Dockera i przekierowywany do kontenera, więc pakiet nigdy nie trafia do hosta, a listy usług i portów strefy obejmują tylko pakiety dostarczane do hosta. Kontener odpowiada na zapytania z Internetu, podczas gdy --list-all nic nie wykazuje. Należy publikować porty na interfejsie loopback za pomocą docker run -d -p 127.0.0.1:8080:80 nginx i umieścić przed nimi reverse proxy.

Czy mogę zainstalować ufw na Rocky Linux zamiast firewalld?

Dwa menedżery firewalla na jednym serwerze tworzą reguły bez wzajemnej wiedzy o swoim istnieniu, a to, który zestaw przetrwa, zależy od tego, która usługa wystartowała jako ostatnia. firewalld jest wspieranym narzędziem w systemach Rocky Linux i AlmaLinux, jest zainstalowany domyślnie i steruje tym samym backendem nftables, co ufw. Wystarczy poznać domyślną strefę oraz flagę --permanent, aby w pełni opanować to narzędzie.