Paket požarnega zidu nameščen, pravila pa so po ponovnem zagonu izginila

Paket se je namestil brez napak, pravila so bila preizkušena, po naslednjem ponovnem zagonu pa so bila vrata popolnoma odprta. V transakciji ni spodletelo nič; spodletelo je tisto, kar je veljalo za trajno. Namestitev orodij požarnega zidu, odločitev, katera pravila naj preživijo, in njihova obnova ob pravem trenutku so tri ločena opravila.

Kaj vam simptom v resnici pove

Nabor pravil, ki po ponovnem zagonu izgine, ima enega od treh vzrokov: nihče ga ni shranil, nekaj drugega ga je nadomestilo ali pa je bil obnovljen, preden je obstajalo tisto, od česar je odvisen. Prva dva sta vidna v konfiguraciji; tretji se pokaže le v vrstnem redu. Zato je ponovni zagon lahko videti kot izguba podatkov, čeprav gre za težavo zaporedja.

Začnite tako, da zapišete, kaj je veljalo pred ponovnim zagonom: katera storitev je imela pravila, katero datoteko ali bazo je prebrala ob zagonu in ali je bil ta vir kdaj zapisan. Živ nabor pravil, ki ga ni nihče shranil, je veljavna razlaga in najpogostejša.

Ne začnite s ponovno namestitvijo paketa.

Pred uporabo preberite orodje za trajnost

Orodja Debian obravnavajo trajnost kot težavo vtičnikov: vsak vtičnik zna zapisati svoja pravila, en ovoj pa jih prikliče. Njegovo dejanje shranjevanja shrani vse, kar je v tistem trenutku naloženo, dejanje zagona pa ta posnetek znova naloži. Nobeno od obeh dejanj ne pregleda, kaj shranjuje.

To je posnetek, ne pregled. Pozabljena dovolitev iz seje razhroščevanja, nedokončan poskus ali popustljivo pravilo, ki ga je vstavil drug pomočnik, trajno postanejo del politike, ki ste jo hoteli obdržati. Shranjevanje stanja in odobritev stanja sta različni dejavnosti in le ena od njiju zahteva presojo. Najprej preberite naloženi nabor, šele nato odločite, katere vrstice si zaslužijo preživeti.

Shranjujte premišljeno, potem ko preberete, kaj je naloženo.

Odločite, kaj naj preživi

Nekatera pravila spadajo v življenjski cikel vmesnika in naj z njim tudi izginejo. Druga morajo preživeti tunel in najjasnejši primer je omejitev, ki prepoveduje, da bi promet odjemalcev padel nazaj na fizični vmesnik, ko tunel pade. Ti dve kategoriji potrebujeta različne sprožilce obnove, ne enega skupnega posnetka.

Zapišite želeni izid za tri trenutke: zagon, aktivacijo VPN in izgubo tunela. Nato preverite, ali lahko izbrano orodje izrazi vsakega od njih. Paket za trajnost, ki znova naloži statični posnetek, obvlada prvega in morda ne obvlada nobenega od ostalih, ker posnetek ne ve, kdaj se je stanje tunela spremenilo. Če jih ne zmore izraziti, vrzel spada v drugo komponento.

Odgovor določa politika, ne paket.

Preverite vrstni red obnove

Obnoviti datoteko ni isto kot imeti izid v rokah. Drug upravljalnik lahko pravila zamenja, prejšnji accept jih lahko zasenči ali pa odjemalci začnejo pošiljati, preden omejitev stopi v veljavo. Preglejte vedenje ob zagonu in ob ponovni povezavi, ne le prisotnosti shranjene datoteke.

systemctl status netfilter-persistent
iptables -S

Ne domnevajte, da je zaustavitev storitve za trajnost nenevarna, kajti paket dokumentira pogojno praznjenje ob zaustavitvi. Preden na prehodu, ki ga upravljate na daljavo, uporabite stop ali restart kot poskus, ugotovite dejansko konfiguracijo storitve. Konzolna seja in dokumentiran povrnitev sta pred tem preskusom najmanjši pogoj.

Vrstni red je lastnost delujočega sistema, ne datoteke na disku.

Sprejmite tri ločene izide

Zabeležite namestitev paketa, naloženi nabor pravil in uveljavljeno politiko kot ločena dejstva. Ime paketa v niti za podporo odgovori le na prvo in prav to je redkokdaj odločilno.

nft list ruleset

Nato preizkusite dovoljeno operacijo in zahtevano zavrnitev.

Če zavrnitev zdrži po ponovnem zagonu in po padcu tunela, je politika preživela. Če zdrži le v enem od teh stanj, ste odkrili težavo vrstnega reda, ne pa je odpravili.