Brandväggspaketet installerades, reglerna försvann efter omstarten

Paketet installerades rent, reglerna testades och efter nästa omstart var gatewayen helt öppen. Inget i transaktionen misslyckades; det som misslyckades var antagandet om vad som skulle bestå. Att installera brandväggsverktyg, avgöra vilka regler som ska överleva och att återställa dem i rätt ögonblick är tre separata jobb.

Vad symtomet faktiskt berättar

En regeluppsättning som försvinner vid omstart har en av tre ägare: ingen sparade den, något annat ersatte den, eller så återställdes den innan det den är beroende av fanns. De två första syns i konfigurationen; det tredje syns bara i ordningen. Därför kan en omstart se ut som dataförlust när det egentligen är ett sekvensproblem.

Börja med att skriva ned vad som gällde före omstarten: vilken tjänst som höll reglerna, vilken fil eller databas den läste vid start och om den källan någonsin hade skrivits. En aktiv regeluppsättning som ingen har sparat är en giltig förklaring och den vanligaste.

Börja inte med att installera om paketet.

Läs beständighetsverktyget innan du använder det

Debian-verktygen ser beständighet som ett pluginproblem: varje plugin vet hur det skriver sina egna regler och ett omslag anropar dem. Dess sparåtgärd lagrar allt som är inläst i det ögonblicket och startåtgärden läser in den ögonblicksbilden igen. Ingen av åtgärderna granskar vad den lagrar.

Det är en ögonblicksbild, inte en granskning. En kvarglömd tillåtelse från en felsökningssession, ett halvfärdigt experiment eller en tillåtande regel som en annan hjälpare lade in blir alla permanenta vid sidan av den policy du tänkte behålla. Att spara tillstånd och att godkänna tillstånd är olika aktiviteter och bara en av dem kräver omdöme. Läs den inlästa uppsättningen först och avgör sedan vilka rader som förtjänar att överleva.

Spara medvetet, efter att ha läst det som är inläst.

Bestäm vad som ska överleva

Vissa regler tillhör ett gränssnitts livscykel och bör försvinna med det. Andra måste överleva tunneln och det tydligaste exemplet är en begränsning som förbjuder klienttrafik att falla tillbaka till det fysiska gränssnittet när tunneln bryts. De två kategorierna behöver olika återställningsutlösare, inte en gemensam ögonblicksbild.

Skriv det avsedda resultatet för tre ögonblick: start, VPN-aktivering och förlorad tunnel. Kontrollera sedan om verktyget du valde kan uttrycka vart och ett av dem. Ett beständighetspaket som läser in en statisk ögonblicksbild hanterar det första och kanske inget av de andra, eftersom en ögonblicksbild inte vet när tunnelns tillstånd ändrades. Om det inte kan uttrycka dem hör gapet hemma i en annan komponent.

Policyn, inte paketet, avgör svaret.

Kontrollera återställningsordningen

Att återställa filen är inte samma sak som att äga resultatet. En annan hanterare kan ersätta reglerna, ett tidigare accept kan skugga dem, eller så kan klienter börja skicka innan begränsningen träder i kraft. Granska beteendet vid start och återanslutning, inte bara förekomsten av en sparad fil.

systemctl status netfilter-persistent
iptables -S

Anta inte att det är ofarligt att stoppa beständighetstjänsten, eftersom paketet dokumenterar en villkorad tömning när den stoppas. Fastställ tjänstens faktiska konfiguration innan du använder stop eller restart som experiment på en gateway du administrerar på distans. En konsolsession och en dokumenterad återställning är minimum före det testet.

Ordningen är en egenskap hos det körande systemet, inte hos filen på disken.

Acceptera tre separata resultat

Registrera paketinstallationen, den inlästa regeluppsättningen och den genomdrivna policyn som separata fakta. Ett paketnamn i en supporttråd besvarar bara den första och det är den som sällan spelar roll.

nft list ruleset

Testa sedan en tillåten åtgärd och en nödvändig blockering.

Om blockeringen håller efter en omstart och efter att tunneln fallit, överlever policyn. Om den håller i bara ett av dessa tillstånd har du hittat ordningsproblemet i stället för att åtgärda det.