Regelen legges inn, terminalen du allerede har fortsetter å svare, og neste innlogging avvises. Det gapet er hele vanskeligheten med å teste en brannmur-endring over forbindelsen du endrer. Tilkoblingssporing bestemmer én gang og slutter så å se, så en etablert flyt er den eneste prøven som ikke kan se den nye policyen. Det som følger sammenligner de tre veiene tilbake, og fastsetter deretter rekkefølgen reglene skal endres og kontrolleres i.

Hvorfor den overlevende økten er det svakeste beviset

En tilstandsfull brannmur evaluerer den første pakken i en flyt og beholder den dommen så lenge oppføringen lever. Regler som legges til etterpå, gjelder for flyter som starter senere, og derfor forblir vinduet du skriver i brukbart mens alle andre avvises. Det du lærer av det, beskriver policyen som gjaldt for noen minutter siden. Selv et opptak tatt på den flyten viser en beslutning maskinen allerede har tatt.

Behandle den fungerende økten som en nødutgang og ikke som en måling. Hver kontroll som er verdt å kjøre, må åpne en ny flyt fra en kilde den nye regelen vil evaluere, og den første kontrollen bør være den der et nederlag ville gjøre mest vondt. Når den økten er din eneste vei inn, er endringen ikke klar til å gjøres.

Tre veier tilbake, ordnet etter hva hver av dem avhenger av

Ranger alternativene etter hvor mye de avhenger av enheten som testes, fordi den rangeringen er det du griper til når regelen viser seg å være feil. En konsoll som aldri går gjennom brannmuren, er uavhengig, en innøvd tilbakerulling er nesten det, og økten som allerede er åpen, er det ikke.

Way back inWhat it survivesWhere it fails
out-of-band or hypervisor consolea policy that blocks new loginsneeds separate access you have already tried
rollback rehearsed on that platforma rule that breaks remote accessfails when nobody ever ran it
the session that is already openthe change itselfcannot show whether new flows work

Før endringen, logg inn via konsollen og bevis at den virker, fordi en out-of-band-vei du aldri har brukt, er et diagram og ikke en fallback. En tilbakerulling fortjener plassen sin først etter en øvelse på den plattformen, med det regelsettet, etter den godkjente prosedyren i stedet for improvisasjon på en levende maskin. Skriv ned trinnene og la noen andre lese dem tilbake. Hvis sekvensen trenger hukommelsen din for å bli ferdig, er den ikke en plan.

Én endring, deretter en forbindelse som må evalueres

Lagre det kjørende regelsettet og filen som eier det, og gjør deretter én smal endring. Én endring per test holder resultatet tilskrivbart; to samtidig etterlater deg med en fungerende maskin og ingen anelse om hvilken endring som gjorde jobben. Der plattformen kan analysere en konfigurasjon uten å laste den, gjør det først, slik at en skrivefeil feiler mens ingenting står på spill.

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

Start deretter en ny økt fra en kilde den endrede regelen vil matche, mens konsollen fortsatt er tilkoblet. Gjenta det én gang hvis det lykkes, fordi det første forsøket kan lande på en oppføring tabellen allerede hadde. Hvis det feiler, har du fortsatt en vei inn og en beslutning å rulle tilbake, og det er det billigste dårlige utfallet som finnes.

Tellere, tilstand og filen svarer på forskjellige spørsmål

Hver av de tre observasjonene kan se overbevisende ut alene og villede deg om de to andre. Tellerne viser om flyten du nettopp opprettet, nådde regelen du endret. Tilstandstabellen viser hvilke flyter maskinen mener allerede er etablert, og slik kan en ødelagt regel fortsatt se sunn ut. Den lagrede filen viser hva enheten vil gjøre etter neste innlasting, og det er kanskje ikke det det kjørende regelsettet gjør nå.

ss -tn state established

Les tellerne som en delta og ikke som en sum, fordi det eneste tallet som betyr noe, er det testflyten din flyttet. En regel der telleren aldri øker, samsvarer ikke, uansett hvor riktig den ser ut på papiret. Bekreft avvisningstilfellet også: en policy som aldri har avvist noe, har aldri bevist at den avviser det du ville blokkere. Gå gjennom ett grensesnitt i hver familie utrullingen faktisk bærer, fordi en v4-regel ikke sier noe om en v6-flyt.

Gjenopprett fra det lagrede regelsettet, og få deretter filen til å stemme

Når endringen feiler, last det lagrede regelsettet i stedet for å legge til tillatende regler til innlogginger virker igjen. Hver ekstra tillatelse demper symptomet og etterlater et hull som overlever hendelsen og minnet om den. Gjenopprett, koble til på nytt, og hold deretter den mislykkede sammenligningen ved siden av oversikten over hva du forsøkte.

Etter en vellykket endring, la filen på disken beskrive regelsettet som kjører, og bekreft at en ny innlasting gjengir det. Et kjørende regelsett som har drevet bort fra sin egen konfigurasjonsfil, er en felle satt for neste omstart.

Relaterte artikler