Firewallveranderinge toets sonder om jouself uit te sluit

Jou reël word ingesit, die terminal wat jy reeds het, bly antwoord, en die volgende aanmelding word geweier. Daardie gaping is die hele moeilikheid om ’n firewallverandering oor die verbinding te toets wat jy verander. Verbindingsnasporing besluit een keer en hou dan op kyk, so ’n gevestigde vloei is die een probe wat nie die nuwe beleid kan sien nie. Wat volg vergelyk die drie maniere om terug te kom en bepaal dan die volgorde waarin die reëls verander en nagegaan moet word.

Waarom die oorlewende sessie die swakste bewyse is

’n Toestandsvolle firewall evalueer die eerste pakket van ’n vloei en behou daardie uitspraak solank die inskrywing leef. Reëls wat daarna bygevoeg word, geld vir vloei wat later begin, en daarom bly die venster waarin jy tik bruikbaar terwyl almal anders geweier word. Wat jy daaruit leer, beskryf die beleid wat minute gelede gegeld het. Selfs ’n opname op daardie vloei wys ’n besluit wat die masjien reeds geneem het.

Behandel die werkende sessie as ’n nooduitgang eerder as ’n meting. Elke toets wat die moeite werd is, moet ’n nuwe vloei open van ’n bron wat die nuwe reël sal evalueer, en die eerste toets moet die een wees wat die seerste sou wees om te faal. Wanneer daardie sessie jou enigste weg in is, is die verandering nie gereed om gemaak te word nie.

Drie maniere om terug te kom, gerangskik volgens waarvan elkeen afhang

Rangskik die opsies volgens hoeveel hulle op die toestel onder toets staatmaak, want daardie rangorde is waarna jy gryp wanneer die reël verkeerd blyk te wees. ’n Konsole wat nooit deur die firewall gaan nie, is onafhanklik, ’n geoefende terugrol byna so, en die sessie wat reeds oop is, is nie.

Meld voor die verandering by die konsole aan en bewys dat dit werk, want ’n buitebandse pad wat jy nooit gebruik het nie, is ’n diagram eerder as ’n terugval. ’n Terugrol verdien sy plek eers ná ’n oefening op daardie platform, met daardie reëlstel, volgens die goedgekeurde prosedure in plaas van improvisasie op ’n lewendige masjien. Skryf die stappe neer en laat iemand anders dit teruglees. As die volgorde jou geheue nodig het om te voltooi, is dit nie ’n plan nie.

Een verandering, dan ’n verbinding wat geëvalueer moet word

Stoor die lewendige reëlstel en die lêer wat dit besit, en maak dan ’n enkele noukeurige wysiging. Een verandering per toets hou die uitkoms toeskryfbaar; twee gelyk laat jou met ’n werkende masjien en geen idee watter wysiging die werk gedoen het nie. Waar die platform ’n konfigurasie kan ontleed sonder om dit te laai, doen dit eerste, sodat ’n tikfout faal terwyl niks op die spel is nie.

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

Begin dan ’n nuwe sessie vanaf ’n bron waarop die veranderde reël sal pas, terwyl die konsole nog aangeheg is. Herhaal dit een keer as dit slaag, want die eerste poging kan op ’n inskrywing beland wat die tabel reeds gehad het. As dit faal, het jy steeds ’n weg in en ’n besluit om om te keer, wat die goedkoopste slegte uitkoms is wat beskikbaar is.

Tellers, toestand en die lêer antwoord verskillende vrae

Elkeen van die drie waarnemings kan op sy eie oortuigend lyk en jou oor die ander twee mislei. Tellers wys of die vloei wat jy pas geskep het die reël bereik het wat jy gewysig het. Die toestandtabel wys watter vloei die masjien glo reeds gevestig is, en so kan ’n stukkende reël steeds gesond lyk. Die gestoorde lêer wys wat die toestel ná die volgende herlaai sal doen, en dit is dalk nie wat die lopende reëlstel nou doen nie.

ss -tn state established

Lees tellers as ’n verskil eerder as ’n totaal, want die enigste getal wat saak maak, is die een wat jou toetsvloei beweeg het. ’n Reël waarvan die teller nooit toeneem nie, pas nie, hoe reg dit ook al op papier lyk. Bevestig ook die weieringsgeval: ’n beleid wat nog nooit iets geweier het nie, het nog nooit bewys dat dit weier wat jy wou blokkeer nie. Werk deur een koppelvlak in elke familie wat die ontplooiing werklik dra, want ’n v4-reël sê niks oor ’n v6-vloei nie.

Herstel uit die gestoorde reëlstel, maak dan die lêer ooreenstem

Wanneer die verandering faal, laai die gestoorde reëlstel in plaas daarvan om toelatende reëls by te voeg totdat aanmeldings weer werk. Elke ekstra toelating sus die simptoom en laat ’n gat wat die voorval en die herinnering daaraan oorleef. Herstel, herverbind en hou dan die mislukte vergelyking langs die rekord van wat jy probeer het.

Ná ’n suksesvolle verandering moet die lêer op skyf die reëlstel beskryf wat loop, en bevestig dat ’n herlaai dit weergee. ’n Lewende reëlstel wat van sy eie konfigurasielêer weggedryf het, is ’n lokval vir die volgende herbegin.