Teste brannmur-endringar utan å låse deg sjølv ute
Ranger gjenopprettingsvegane dine før regelen blir lagd inn, og verifiser deretter med ein flyt som den nye policyen må evaluere, ikkje med økta som overlevde.
Regelen blir lagd inn, terminalen du allereie har held fram med å svare, og neste innlogging blir avvist. Det gapet er heile vansket med å teste ei brannmur-endring over sambandet du endrar. Tilkoplingssporing avgjer éin gong og sluttar så å sjå, så ein etablert flyt er den einaste prøven som ikkje kan sjå den nye policyen. Det som følgjer samanliknar dei tre vegane tilbake, og fastset deretter rekkjefølgja reglane skal endrast og kontrollerast i.
Kvifor den overlevande økta er det svakaste beviset
Ein tilstandsfull brannmur evaluerer den første pakken i ein flyt og held på den dommen så lenge oppføringa lever. Reglar som blir lagde til etterpå, gjeld for flytar som startar seinare, og difor blir vindauget du skriv i brukbart medan alle andre blir avviste. Det du lærer av det, skildrar policyen som galdt for nokre minutt sidan. Sjølv eit opptak teke på den flyten viser ei avgjerd maskinen allereie har teke.
Handter den fungerande økta som ein naudutgang og ikkje som ei måling. Kvar kontroll som er verdt å køyre, må opne ein ny flyt frå ei kjelde den nye regelen vil evaluere, og den første kontrollen bør vere den der eit nederlag ville gjere mest vondt. Når den økta er din einaste veg inn, er endringa ikkje klar til å bli gjord.
Tre vegar tilbake, ordna etter kva kvar av dei er avhengig av
Ranger alternativa etter kor mykje dei er avhengige av eininga som blir testa, fordi den rangeringa er det du grip til når regelen viser seg å vere feil. Ein konsoll som aldri går gjennom brannmuren, er uavhengig, ei innøvd tilbakerulling er nesten det, og økta som allereie er open, er det ikkje.
| Way back in | What it survives | Where it fails |
|---|---|---|
| out-of-band or hypervisor console | a policy that blocks new logins | needs separate access you have already tried |
| rollback rehearsed on that platform | a rule that breaks remote access | fails when nobody ever ran it |
| the session that is already open | the change itself | cannot show whether new flows work |
Før endringa, logg inn via konsollen og prov at han verkar, fordi ein out-of-band-veg du aldri har brukt, er eit diagram og ikkje ein fallback. Ei tilbakerulling fortener plassen sin først etter ei øving på den plattforma, med det regelsettet, etter den godkjende prosedyren i staden for improvisasjon på ein levande maskin. Skriv ned trinna og la nokon andre lese dei tilbake. Viss sekvensen treng hukommelsen din for å bli ferdig, er han ikkje ein plan.
Éi endring, deretter eit samband som må evaluerast
Lagre det køyrande regelsettet og fila som eig det, og gjer deretter éi smal endring. Éi endring per test held resultatet tilskriveleg; to samstundes etterlet deg med ein fungerande maskin og inga aning om kva endring som gjorde jobben. Der plattforma kan analysere ein konfigurasjon utan å laste han, gjer det først, slik at ein skrivefeil feilar medan ingenting står på spel.
nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf
Start deretter ei ny økt frå ei kjelde den endra regelen vil matche, medan konsollen framleis er tilkopla. Gjenta det éin gong viss det lukkast, fordi det første forsøket kan lande på ei oppføring tabellen allereie hadde. Viss det feilar, har du framleis ein veg inn og ei avgjerd å rulle tilbake, og det er det billegaste dårlege utfallet som finst.
Teljarar, tilstand og fila svarer på ulike spørsmål
Kvar av dei tre observasjonane kan sjå overtydande ut aleine og villleie deg om dei to andre. Teljarane viser om flyten du nettopp oppretta, nådde regelen du endra. Tilstandstabellen viser kva flytar maskinen meiner allereie er etablerte, og slik kan ein øydelagd regel framleis sjå sunn ut. Den lagra fila viser kva eininga vil gjere etter neste innlasting, og det er kanskje ikkje det det køyrande regelsettet gjer no.
ss -tn state established
Les teljarane som ein delta og ikkje som ein sum, fordi det einaste talet som betyr noko, er det testflyten din flytta. Ein regel der teljaren aldri aukar, samsvarar ikkje, uansett kor riktig han ser ut på papiret. Stadfest avvisingstilfellet òg: ein policy som aldri har avvist noko, har aldri prova at han avviser det du ville blokkere. Gå gjennom eitt grensesnitt i kvar familie utrullinga faktisk ber, fordi ein v4-regel ikkje seier noko om ein v6-flyt.
Gjenopprett frå det lagra regelsettet, og få deretter fila til å stemme
Når endringa feilar, last det lagra regelsettet i staden for å leggje til tillatande reglar til innloggingar verkar igjen. Kvar ekstra tillating dempar symptomet og etterlet eit hol som overlever hendinga og minnet om ho. Gjenopprett, kople til på nytt, og hald deretter den mislukka samanlikninga ved sida av oversynet over kva du forsøkte.
Etter ei vellukka endring, la fila på disken skildre regelsettet som køyrer, og stadfest at ei ny innlasting gjev det att. Eit køyrande regelsett som har drive bort frå si eiga konfigurasjonsfil, er ei felle sett for neste omstart.