Rozwiązanie społecznościowe

Zapora sieciowa hosta ZFW w ZimaOS: bezpieczne stosowanie zmian, filtrowanie Dockera, IPv6 i bieżąca kompatybilność

A May-July 2026 community module thread introducing ZFW as a ZimaOS dashboard firewall with host INPUT filtering, Docker DOCKER-USER rules, IPv6 handling, exposure visibility, and a 120-second Safe-Apply rollback. The thread documents multiple real compatibility bugs and fixes as ZimaOS moved from legacy iptables to nf_tables.

ZFW to tworzona przez społeczność zapora hosta dla ZimaOS, a nie wbudowana funkcja opracowana przez IceWhale. Instaluje się jako rozszerzenie systemowe na poziomie hosta, pojawia się jako kafelek w panelu i próbuje rozwiązać rzeczywistą lukę ZimaOS: natywne usługi oraz porty publikowane przez Dockera mogą być dostępne w całej sieci LAN, jeśli inna zapora lub urządzenie sieciowe nadrzędne ich nie ogranicza.

Wpis źródłowy dotyczył wersji ZFW v1.0.10, ale ta wersja nie jest już właściwym punktem odniesienia dla bieżącej instalacji. ZFW nadal szybko się zmieniało wraz ze zmianami w samym ZimaOS. Obecna wersja upstream to v1.0.25, a projekt naprawił już problemy ze zgodnością dotyczące nf_tables backend, zmiany tokenów sesji w ZimaOS 1.7.x, ekspozycję Dockera przez IPv6 oraz ruch Zima Net na tun0.

Panel zapory ZFW w ZimaOS pokazujący aktywny stan, ujawnione porty, zablokowane porty, wykryte problemy i elementy sterujące bezpiecznym zastosowaniem
ZFW integruje stan zapory, liczbę ekspozycji i mechanizmy awaryjnego wycofania zmian w stylu ZimaOS z panelem.

ZFW to oprogramowanie społecznościowe, a nie zapora IceWhale

Lintux samodzielnie stworzył i utrzymuje ZFW. Wątek źródłowy zawiera szeroko zakrojone testy społeczności, w tym użytkowników, którzy potwierdzili trwałość reguł, blokowanie portów, działanie wycofywania zmian oraz późniejsze poprawki zgodności, ale żadne ogłoszenie IceWhale nie czyni z ZFW oficjalnej zapory ZimaOS.

To rozróżnienie ma znaczenie, ponieważ ZFW bezpośrednio manipuluje stosem sieciowym hosta. Nieprawidłowa lub niezgodna reguła może zablokować SSH, interfejs WebUI, aplikacje Dockera lub zdalny dostęp.

ZFW oddziela usługi hosta od portów publikowanych przez Dockera

Architektura ZFW rozpoznaje, że ruch Dockera różni się od zwykłego ruchu INPUT hosta:

  • natywne usługi ZimaOS/hosta są kontrolowane za pomocą reguł w stylu INPUT;
  • Porty publikowane przez Docker są filtrowane przez DOCKER-USER;
  • IPv6 ma własne odpowiadające łańcuchy i sposób działania.

Jest to dokładniejsze niż poradnik dotyczący zapory, który sprawdza wyłącznie INPUT i zakłada, że Docker korzysta z tej samej ścieżki.

Bezpieczne zastosowanie to najważniejsza funkcja bezpieczeństwa

Źródło wprowadziło mechanizm awaryjnego wycofania zmian po 120 sekundach. Po zastosowaniu zestawu reguł użytkownik musi potwierdzić go przed upływem odliczania. Jeśli reguła przypadkowo odetnie użytkownika od systemu, zapora automatycznie wycofa zmiany.

Jest to szczególnie istotne w przypadku bezgłowowego serwera NAS, ponieważ błąd konfiguracji zapory może w przeciwnym razie zmienić się w konieczność odzyskiwania systemu za pomocą lokalnego monitora i klawiatury.

Wątek ujawnił rzeczywistą lukę w domyślnym zezwalaniu dla terminala ZimaOS

Użytkownik zgłosił, że ZFW blokowała port TCP 7681, czyli domyślny port terminala ttyd. Lintux wyjaśnił, że pierwotna lista startowa zawierała porty takie jak SSH, HTTP/HTTPS, SMB oraz kilka usług ZimaOS, ale nie obejmowała portu 7681.

To przydatne przypomnienie: przed włączeniem zasady domyślnej odmowy zinwentaryzuj usługi, na których faktycznie polegasz. Zapora może działać poprawnie, a mimo to blokować usługę pominiętą w profilu domyślnym.

ZimaOS 1.6.2 zmienił backend iptables

Jedna z najważniejszych aktualizacji opisanych w wątku źródłowym pojawiła się po tym, jak ZimaOS 1.6.2 przełączył efektywną ścieżkę iptables Dockera na nf_tables backendu. Starsze kompilacje ZFW mogły zapisywać reguły w nieużywanej starszej tabeli, podczas gdy kafelek nadal wyglądał poprawnie.

Późniejsze wydania dodały wykrywanie backendu i dodatkową walidację reguł Dockera. Dlatego starych instrukcji instalacji ZFW nigdy nie należy traktować jako niezmiennej recepty.

Wątek doprowadził do wykrycia i naprawienia rzeczywistego problemu typu fail-open w Dockerze

Podczas testów v1.0.16 użytkownik odkrył, że DOCKER-USER mogły kończyć się prostym RETURN bez oczekiwanych reguł domyślnego odrzucania. Lintux potwierdził, że była to rzeczywista, nieoczekiwana ścieżka typu fail-open, i zmienił logikę inwentaryzacji portów.

Później ten sam użytkownik ponownie zainstalował v1.0.19, ponownie zastosował zaporę i potwierdził obecność oczekiwanych reguł dla poszczególnych portów oraz obsługi UDP.

IPv6 wymagał kilku rund poprawek opartych na rzeczywistym użytkowaniu

W wątku źródłowym opisano przypadki, w których ochrona IPv6 była aktywna, ale raportowana nieprawidłowo, a także inne przypadki, gdy publikowane przez Dockera porty IPv6 były nieoczekiwanie blokowane. Nie były to teoretyczne obawy; użytkownicy publikowali rzeczywisty wynik łańcuchów, a opiekun projektu odtworzył i naprawił konkretne ścieżki.

W przypadku domowego łącza obsługującego IPv6 przetestuj dostęp z rzeczywistej zewnętrznej sieci IPv6, zamiast zakładać, że test z sieci LAN przez IPv4 potwierdza tę samą politykę.

Najnowsze wersje ZFW musiały również dostosować się do zdalnego dostępu Zima Net

W późniejszym wydaniu upstream ustalono, że wbudowany w ZimaOS ruch zdalnego dostępu Zima Net na tun0 mogły zostać odrzucone przez starsze kompilacje ZFW. ZFW v1.0.24 dodał niezbędną obsługę wyjątków we wszystkich odpowiednich łańcuchach.

To kolejny powód, aby aktualizować ZimaOS i ZFW jednocześnie oraz weryfikować zdalny dostęp po aktualizacji zapory.

Korzystaj z bieżącego wydania ZFW, nie z v1.0.10

We wrześniu 2026 r. upstream wymienia ZFW v1.0.25 jako najnowsze wydanie. Przed instalacją lub aktualizacją zapoznaj się z bieżącymi wydaniami ZFW i historią zgodności.

Zweryfikuj działanie zapory, a nie tylko zielony kafelek pulpitu

Po włączeniu ZFW przetestuj:

  • SSH i WebUI z sieci LAN;
  • terminal ZimaOS;
  • ważnych portów publikowanych przez Dockera;
  • Tailscale/ZeroTier/Zima Net, jeśli są używane;
  • IPv6 spoza sieci LAN, jeśli ma to zastosowanie;
  • trwałości po ponownym uruchomieniu.

Historia źródeł pokazuje, dlaczego poprawnie wyglądający interfejs nie powinien być jedynym dowodem na to, że reguły dotarły do aktywnego backendu.

FAQ ZFW

Czy ZFW jest oficjalną zaporą IceWhale?

Nie. To społecznościowy moduł zapory hosta, który głęboko integruje się z ZimaOS.

Czy obecni użytkownicy powinni zainstalować v1.0.10 z pierwotnego wpisu?

Nie. Od tej wersji projekt otrzymał wiele poprawek zgodności i bezpieczeństwa.

Dlaczego ZFW korzysta z DOCKER-USER?

Ruch opublikowany przez Docker może ominąć zwykłe filtrowanie INPUT hosta, dlatego ZFW korzysta z dedykowanej ścieżki filtrowania Dockera dla portów kontenerów.