Strona główna
» LINUX
»
Jak skonfigurować zaporę sieciową SLES 15 za pomocą polecenia firewall-cmd
Jak skonfigurować zaporę sieciową SLES 15 za pomocą polecenia firewall-cmd
Usługa może działać na serwerze SLES 15 i nadal przekraczać limit czasu dla klientów zdalnych, ponieważ zapora blokuje nowy ruch przychodzący. Rozwiązaniem jest zazwyczaj zidentyfikowanie aktywnej strefy firewalld i zezwolenie tylko na usługę lub port potrzebny aplikacji. Narzędziem wiersza poleceń SLES do tego zadania jest firewall-cmd.
Niniejszy przewodnik jest zgodny z dokumentem SUSE SLES 15 SP7 Security and Hardening Guide oraz dokumentem referencyjnym polecenia firewalld, sprawdzonym 7 października 2026 r. Wcześniejsze pakiety Service Pack i zaktualizowane systemy SLES 12 mogą mieć inne stany lub starszą konfigurację zapory. Obrazy terminala przedstawiają reprezentatywne przykłady, a nie wyniki uzyskane z rzeczywistego serwera; nazwy interfejsów, strefy i usługi należy zastąpić wartościami na hoście.
1. Sprawdź, czy zapora sieciowa jest uruchomiona
SUSE dokumentuje firewalld jako domyślnie zainstalowany i włączony w systemie SLES 15. YaST zazwyczaj uruchamia go po instalacji i umieszcza interfejsy w publicstrefie domyślnej. Mimo to, sprawdź komputer, zamiast zakładać, że ustawienia domyślne się nie zmieniły. Uruchom te polecenia z konta z uprawnieniami do korzystania z sudo:
sudo systemctl status firewalld
sudo firewall-cmd --state
Menedżer usług powinien zgłosić, że usługa firewalldjest aktywna, a firewall-cmd --statetakże zgłosić running. Jeśli usługa jest zainstalowana, ale zatrzymana, uruchom ją i włącz podczas rozruchu:
sudo systemctl enable --now firewalld
Jeśli firewall-cmdbrakuje, sprawdź, czy firewalldpakiet jest zainstalowany i dostępny w aktywnych repozytoriach SUSE. Nie instaluj ani nie wymieniaj komponentów zapory sieciowej bezmyślnie na serwerze zarządzanym.
Przykładowy terminal sprawdza status zapory sieciowej i pokazuje przykładową aktywną strefę publiczną z interfejsem eth0.
2. Znajdź strefę chroniącą interfejs serwera
Zapora sieciowa grupuje reguły w strefy , które reprezentują różne poziomy zaufania. publicStrefa jest powszechnie używana w przypadku sieci, które nie są zaufane. Usługa uruchomiona w jednej strefie nie otwiera się automatycznie w każdej innej, więc poprawna reguła w niewłaściwej strefie może sprawić, że aplikacja będzie niedostępna.
Użyj wyjścia active-zone, aby znaleźć strefę dołączoną do interfejsu obsługującego ruch kliencki. Nazwa interfejsu może brzmieć eth0, ens160lub inną nazwą. Jeśli chcesz sprawdzić jeden interfejs, uruchom:
sudo firewall-cmd --get-zone-of-interface=eth0
Zastąp eth0rzeczywistym interfejsem. Interfejs, który nie jest jawnie przypisany do strefy, jest obsługiwany przez strefę domyślną. Unikaj przypadkowej zmiany strefy domyślnej: może to wpłynąć na interfejsy od niej zależne. Na serwerze zdalnym zidentyfikuj strefę SSH lub inną strefę zarządzania i potwierdź jej regułę dostępu przed ponownym załadowaniem ustawień zapory. Zachowaj dostępną konsolę lub ścieżkę odzyskiwania poza pasmem, jeśli taka istnieje.
Lista stref pokazuje, który interfejs i usługi są skojarzone z przykładową strefą publiczną przed wprowadzeniem jakichkolwiek zmian.
3. Wybierz usługę nazwaną lub konkretny port
Usługa firewalld to nazwana definicja, która może obejmować jeden lub więcej portów i protokołów. Zazwyczaj łatwiej jest zezwolić na dostęp do znanej usługi po nazwie niż zapamiętać jej numer portu. Sprawdź listę zainstalowanych usług i przejrzyj definicję przed jej użyciem:
W przypadku serwera WWW predefiniowana httpusługa zazwyczaj obejmuje port TCP 80; httpsjest to oddzielna usługa dla ruchu WWW TLS. Dokumentacja SLES przedstawia tę samą metodę opartą na usługach, z przykładami takimi jak DHCP. Użyj rzeczywistej usługi wymaganej przez Twoją aplikację i w razie wątpliwości zweryfikuj definicję usługi lokalnie.
Jeśli żadna predefiniowana usługa nie spełnia wymagań, otwórz tylko wymagany port i protokół. Na przykład, aplikacja nasłuchująca na porcie TCP 8443 może zostać dopuszczona za pomocą --add-port=8443/tcp. Otwarcie portu w zaporze nie uruchamia aplikacji, nie wiąże jej z siecią ani nie zabezpiecza; sprawdź, czy sama usługa jest skonfigurowana do nasłuchiwania na zamierzonym adresie.
Najpierw przetestuj regułę tymczasową
W ramach krótkiego testu zastosuj regułę do konfiguracji środowiska wykonawczego. Zmiany w środowisku wykonawczym zaczną obowiązywać natychmiast, ale zostaną utracone po przeładowaniu zapory lub ponownym uruchomieniu usługi, chyba że zostaną również trwale zapisane. Firewalld obsługuje regułę ograniczoną czasowo, co jest przydatne, gdy chcesz, aby test automatycznie wygasł:
W przypadku jednorazowego testu portu użyj --add-port=8443/tcp --timeout=5mzamiast --add-service=http. Wybierz strefę, która faktycznie zawiera interfejs serwera; nie kopiuj, publicjeśli Twój host używa innej strefy.
Przykładowe polecenie dodaje usługę HTTP do stałej konfiguracji strefy publicznej, a następnie ponownie ładuje firewalld, aby ją zastosować.
4. Zapisz regułę i ponownie załaduj firewalld
Gdy będziesz gotowy zachować regułę, dodaj ją do stałej konfiguracji. Poniższy przykład zezwala na protokół HTTP w strefie publicznej:
W przypadku protokołu HTTPS powtórz polecenie permanent z --add-service=https. W przypadku niestandardowego portu aplikacji użyj polecenia takiego jak:
Te przykłady najpierw modyfikują konfigurację stałą, a następnie ją przeładowują, aby nowa reguła stała się aktywna. Przeładowanie zastępuje również ustawienia środowiska wykonawczego konfiguracją stałą. Wszelkie zmiany wprowadzone wyłącznie w środowisku wykonawczym w innych miejscach mogą zatem zostać odrzucone. Przed przeładowaniem systemu produkcyjnego należy sprawdzić ważne reguły środowiska wykonawczego i stałe, zwłaszcza dotyczące zdalnego dostępu administracyjnego.
Istnieje również przepływ pracy oparty na środowisku wykonawczym: przetestuj regułę w środowisku wykonawczym, potwierdź działanie usługi, a następnie dodaj tę samą regułę za pomocą --permanenti ponownie załaduj. Unikaj używania tej opcji --runtime-to-permanentjako skrótu, chyba że zamierzasz zapisać każdą bieżącą regułę w środowisku wykonawczym, w tym tymczasowe zmiany wprowadzone przez innych administratorów lub oprogramowanie.
Jak można sprawdzić, czy zmiana zadziałała?
Sprawdź zarówno aktywną regułę wykonawczą, jak i zapisaną regułę. W przypadku usługi HTTP w strefie publicznej uruchom:
Zapytanie powinno zwrócić yes, lista usług stałych powinna zawierać http, a sprawdzanie konfiguracji powinno zakończyć się pomyślnie. W przypadku reguły portu należy użyć komendy --query-port=8443/tcpi --list-portsw równoważnych poleceniach. Przeprowadź również test z poziomu oddzielnego klienta, który może połączyć się z serwerem; zapytanie do zapory lokalnej potwierdza obecność reguły, a nie poprawność DNS, routingu, zapór nadrzędnych lub nasłuchiwacza aplikacji.
Polecenia weryfikacyjne sprawdzają aktywną regułę usługi, zapisaną listę usług i stałą składnię konfiguracji.
Typowe problemy i bezpieczne rozwiązania
Reguła jest obecna, ale połączenia nadal przekraczają limit czasu: upewnij się, że została dodana do strefy dołączonej do interfejsu klienta. Następnie sprawdź, czy aplikacja nasłuchuje na oczekiwanym adresie i porcie oraz sprawdź zaporę sieciową nadrzędną.
Reguła działała do momentu ponownego załadowania: prawdopodobnie została dodana tylko do środowiska wykonawczego. Dodaj ją za pomocą --permanenti ponownie załaduj, a następnie przepytaj obie konfiguracje.
Dostęp SSH jest zagrożony: sprawdź usługi aktywnej i stałej strefy przed ponownym załadowaniem. Jeśli SSH jest wymagane i niedostępne, dodaj sshusługę do właściwej strefy na stałe przed ponownym załadowaniem. Nie zamykaj bieżącej sesji zdalnej, dopóki nie przetestujesz drugiego połączenia.
Migrujesz ze starszej wersji SUSE: SLES 15 zastąpił SuSEfirewall2 przez firewalld. SUSE ostrzega, że starsze profile zapory mają ograniczoną kompatybilność wsteczną; zapoznaj się z przewodnikiem migracji, zamiast zakładać, że wszystkie starsze reguły zostały przetłumaczone.
Reguły wydają się kolidować: firewalld ma zarządzać regułami zapory hosta. SUSE ostrzega przed modyfikowaniem tych samych reguł oddzielnie za pomocą narzędzi takich jak iptables, ponieważ może to zaburzyć aktywną konfigurację.
Aby usunąć zbędną stałą usługę lub port, użyj opcji dopasowania --remove-servicelub --remove-portz --permanent, a następnie przeładuj i ponownie zweryfikuj. Na przykład usuń HTTP ze strefy publicznej za pomocą , a sudo firewall-cmd --permanent --zone=public --remove-service=httpnastępnie sudo firewall-cmd --reload.
Sprawdź się przed zakończeniem
firewallddziała i uruchamia się po uruchomieniu serwera.