Brannmurpakken installert, reglene borte etter omstarten

Pakken ble installert rent, reglene ble testet, og etter neste omstart var gatewayen vidåpen. Ingenting i transaksjonen feilet; feilen lå i antakelsen om hva som ville bestå. Å installere brannmurverktøy, bestemme hvilke regler som skal overleve og gjenopprette dem i rett øyeblikk er tre separate jobber.

Hva symptomet egentlig forteller deg

Et regelsett som forsvinner ved omstart har én av tre eiere: ingenting lagret det, noe annet erstattet det, eller det ble gjenopprettet før det det er avhengig av fantes. De to første er synlige i konfigurasjonen; det tredje viser seg bare i rekkefølgen. Derfor kan en omstart se ut som datatap når det egentlig er et rekkefølgeproblem.

Begynn med å skrive ned hva som var sant før omstarten: hvilken tjeneste som holdt reglene, hvilken fil eller database den leste ved oppstart, og om den kilden noen gang var skrevet til. Et aktivt regelsett som ingen lagret, er en gyldig forklaring og den vanligste.

Ikke begynn med å installere pakken på nytt.

Les utholdenhetsverktøyet før du bruker det

Debian-verktøyene behandler utholdenhet som et plugin-problem: hver plugin vet hvordan den skriver sine egne regler, og én innpakning kaller dem. Lagre-handlingen lagrer alt som er lastet inn i det øyeblikket, og start-handlingen laster det øyeblikksbildet tilbake. Ingenting i noen av handlingene gjennomgår hva som lagres.

Det er et øyeblikksbilde, ikke en gjennomgang. En gjenværende tillatelse fra en feilsøkingsøkt, et halvferdig eksperiment eller en ettergivende regel som et annet hjelpemiddel satte inn, blir alle permanente ved siden av policyen du ville beholde. Å lagre tilstand og å godkjenne tilstand er forskjellige aktiviteter, og bare én av dem krever skjønn. Les det innlastede settet først, og bestem deretter hvilke linjer som fortjener å overleve.

Lagre med vilje, etter å ha lest hva som er lastet inn.

Bestem hva som skal overleve

Noen regler hører til livssyklusen til et grensesnitt og bør forsvinne med det. Andre må overleve tunnelen, og det klareste eksempelet er en begrensning som forbyr klienttrafikk å falle tilbake til det fysiske grensesnittet når tunnelen faller. De to kategoriene trenger forskjellige gjenopprettingsutløsere, ikke ett felles øyeblikksbilde.

Skriv det tiltenkte resultatet for tre øyeblikk: oppstart, VPN-aktivering og tunneltap. Kontroller deretter om verktøyet du valgte kan uttrykke hvert av dem. En utholdenhetspakke som laster inn et statisk øyeblikksbilde på nytt, håndterer det første og kanskje ingen av de andre, fordi et øyeblikksbilde ikke aner når tunnelens tilstand endret seg. Hvis den ikke kan uttrykke dem, hører gapet til en annen komponent.

Policyen, ikke pakken, avgjør svaret.

Kontroller gjenopprettingsrekkefølgen

Å gjenopprette filen er ikke det samme som å eie resultatet. En annen behandler kan erstatte reglene, en tidligere tillatelse kan skygge for dem, eller klienter kan begynne å sende før begrensningen trer i kraft. Gå gjennom oppstarts- og gjenoppkoblingsatferd, ikke bare tilstedeværelsen av en lagret fil.

systemctl status netfilter-persistent
iptables -S

Ikke anta at det er ufarlig å stoppe utholdenhetstjenesten, fordi pakken dokumenterer en betinget tømming når den stopper. Fastslå tjenestens faktiske konfigurasjon før du bruker stopp eller omstart som eksperiment på en gateway du administrerer eksternt. En konsolløkt og en dokumentert tilbakerulling er minimum før den testen.

Rekkefølge er en egenskap ved det kjørende systemet, ikke ved filen på disken.

Godta tre separate resultater

Registrer pakkeinstallasjonen, det innlastede regelsettet og policyen som håndheves som separate fakta. Et pakkenavn i en støttetråd svarer bare på det første, og det er det som sjelden betyr noe.

nft list ruleset

Test deretter en tillatt operasjon og en påkrevd avvisning.

Hvis avvisningen holder etter en omstart og etter et tunneltap, overlever policyen. Hvis den bare holder i én av disse tilstandene, har du funnet rekkefølgeproblemet i stedet for å rette det.