Pakiet firewalla zainstalowany, reguły zniknęły po restarcie

Pakiet zainstalował się czysto, reguły przetestowano, a po następnym restarcie brama była szeroko otwarta. Nic w transakcji nie zawiodło; błąd tkwił w założeniu, co przetrwa. Instalacja narzędzi firewalla, decyzja, które reguły mają przetrwać, i przywrócenie ich w odpowiednim momencie to trzy osobne zadania.

Co właściwie mówi objaw

Zestaw reguł, który znika po restarcie, ma jednego z trzech właścicieli: nic go nie zapisało, coś innego go zastąpiło albo został przywrócony, zanim istniało to, od czego zależy. Pierwsze dwa widać w konfiguracji; trzeci ujawnia się tylko w kolejności. Dlatego restart może wyglądać jak utrata danych, choć w rzeczywistości jest problemem kolejności.

Zacznij od zapisania, co było prawdą przed restartem: która usługa trzymała reguły, który plik lub bazę czytała przy starcie i czy do tego źródła kiedykolwiek zapisano. Aktywny zestaw reguł, którego nikt nie zapisał, jest uzasadnionym wyjaśnieniem i najczęstszym.

Nie zaczynaj od reinstalacji pakietu.

Przeczytaj narzędzie trwałości, zanim go użyjesz

Narzędzia Debiana traktują trwałość jako problem wtyczek: każda wtyczka wie, jak zapisać własne reguły, a jedna otoczka je wywołuje. Akcja zapisu przechowuje wszystko, co jest wtedy załadowane, a akcja startu ładuje ten obraz z powrotem. Nic w obu akcjach nie sprawdza, co przechowuje.

To obraz, nie przegląd. Pozostałe zezwolenie z sesji debugowania, niedokończony eksperyment albo łagodna reguła wstawiona przez inne narzędzie stają się trwałe obok polityki, którą chciałeś zachować. Zapisanie stanu i zatwierdzenie stanu to różne działania, a tylko jedno z nich wymaga osądu. Najpierw przeczytaj załadowany zestaw, potem zdecyduj, które wiersze zasługują na przetrwanie.

Zapisuj świadomie, po przeczytaniu tego, co jest załadowane.

Zdecyduj, co ma przetrwać

Niektóre reguły należą do cyklu życia interfejsu i powinny zniknąć razem z nim. Inne muszą przetrwać tunel, a najjaśniejszy przykład to ograniczenie, które zabrania ruchowi klientów spadać z powrotem na interfejs fizyczny, gdy tunel pada. Te dwie kategorie potrzebują różnych wyzwalaczy przywracania, a nie jednego wspólnego obrazu.

Zapisz zamierzony wynik dla trzech momentów: rozruchu, aktywacji VPN i utraty tunelu. Potem sprawdź, czy wybrane narzędzie potrafi wyrazić każdy z nich. Pakiet trwałości, który ładuje statyczny obraz, obsługuje pierwszy i być może żadnego z pozostałych, ponieważ obraz nie wie, kiedy zmienił się stan tunelu. Jeśli nie potrafi ich wyrazić, luka należy do innego komponentu.

Odpowiedź rozstrzyga polityka, nie pakiet.

Sprawdź kolejność przywracania

Przywrócenie pliku to nie to samo co posiadanie wyniku. Inny menedżer może zastąpić reguły, wcześniejsze zezwolenie może je przyciemnić albo klienci mogą zacząć wysyłać, zanim ograniczenie wejdzie w życie. Przejrzyj zachowanie przy starcie i ponownym połączeniu, nie tylko obecność zapisanego pliku.

systemctl status netfilter-persistent
iptables -S

Nie zakładaj, że zatrzymanie usługi trwałości jest nieszkodliwe, bo pakiet dokumentuje warunkowe czyszczenie przy zatrzymaniu. Ustal rzeczywistą konfigurację usługi, zanim użyjesz zatrzymania lub restartu jako eksperymentu na bramie, którą administrujesz zdalnie. Sesja konsoli i udokumentowane wycofanie to minimum przed tym testem.

Kolejność jest cechą działającego systemu, a nie pliku na dysku.

Zaakceptuj trzy osobne wyniki

Zapisz instalację pakietu, załadowany zestaw reguł i egzekwowaną politykę jako osobne fakty. Nazwa pakietu w wątku pomocy odpowiada tylko na pierwsze, a to właśnie ono rzadko ma znaczenie.

nft list ruleset

Następnie przetestuj dozwoloną operację i wymagane odrzucenie.

Jeśli odrzucenie utrzymuje się po restarcie i po utracie tunelu, polityka przetrwa. Jeśli utrzymuje się tylko w jednym z tych stanów, znalazłeś problem kolejności, zamiast go naprawić.