Uredili ste pravilo, znova naložili nabor pravil in tunel se obnaša točno tako kot prej. Ta izid ima dva pogosta vzroka in zahtevata različna testa. Ali novo pravilo stoji za prejšnjim pravilom, ki je paket že sprejelo, ali pa je izmenjava, ki jo opazujete, sledena povezava, ki je sprememba nikoli znova ne ovrednoti. Pravilo v datoteki izraža namero; o usodi paketa odloča aktivna pot, na katero naleti. Pojdite skozi spodnje preveritve po vrsti in pri tem ohranite pot nazaj.

Vrstni red pravil in stanje povezave sta različni napaki

Urejene verige se vrednotijo od zgoraj navzdol in prvo pravilo, ki doseže končno razsodbo, konča prehod skozi to verigo. Postavite široko odobritev nad skrbno napisano pravilo zaklepanja in pravilo zaklepanja postane dokumentacija: je v naboru, njegov števec je nič in noben paket ga ne bo nikoli dosegel. Isto besedilo, uporabljeno na drugi verigi, prav tako ničesar ne dokaže. V nftables se osnovne verige pritrdijo na kavlje po prioritetah, zato odobritev v eni verigi ne prepreči drugi verigi na drugem kavlju ali prioriteti, da vidi isti paket.

Sledenje povezav ustvari drugi simptom in od zunaj je videti enako. Ko je tok v tabeli stanj, se odobritev za established-or-related blizu vrha verige vrne, preden se vaše novo pravilo sploh upošteva. Preslikave NAT imajo isto lastnost: prevod je bil določen ob začetku toka, zato urejeno pravilo postrouting ne prepiše seje, ki že teče. Zato se sprememba zdi, da deluje ob 09:00 za novo povezavo, in se zdi, da ne naredi ničesar za sejo, ki jo je nekdo odprl ob 08:55.

Varnostne skupine v oblaku dodajo tretji model, ki ujame ljudi, ki so se učili na iptables. Njihova vhodna pravila so seznam dovoljenj, ki se vrednoti kot množica in ne kot prehod po prvem ujemanju, so stanjska, in odstranitev pravila dovoljenja ne konča tokov, ki se že sledijo. Predpostavljanje semantike prvega ujemanja na platformi, ki je nima, vodi do samozavestnih, napačnih sklepov.

Berite aktivni nabor pravil, ne datoteke, ki ste jo uredili

Začnite s tem, kar jedro pravkar uveljavlja. Shranjena konfiguracija, ki ni bila nikoli uporabljena, pojasni presenetljivo veliko nespremenjenega vedenja, in izločiti jo stane en ukaz:

nft list ruleset
iptables-save

Nato vprašajte, ali je vaše pravilo sploh doseženo. Števci paketov odgovorijo neposredno in odgovorijo bolje kot kakršno koli razmišljanje o nameri:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Pravilo zaklepanja z nič paketi po resničnem poskusu testa ni problem politike, je problem položaja. Premakniti ga je sprememba ene vrstice, sintaksa pa je natanko tisto, kar je povzročilo prvotno napako. Z iptables -I vstavi, z -A doda na konec; z nftables insert postavi pravilo na začetek verige, medtem ko add doda na konec. Ko mora pravilo zmagati, povejte to izrecno, namesto da bi zaupali vrstnemu redu, ki se je slučajno naložil.

Dokažite, ali se tok sledi

Preden okrivite pravilo, preverite, ali je promet sploh sledena povezava. Vprašajte tabelo stanj za konkreten tok, namesto da bi jo izlili v celoti:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

Seznam prikazuje stanje in preostali časovni limit, in tako ločite vzpostavljeno sejo od novega poskusa; način dogodkov izpisuje posodobitve, ko se zgodijo, kar je uporabno, medtem ko znova povezujete odjemalca. Če je tok prisoten v vzpostavljenem stanju, preden ste se česar koli dotaknili, nobena sprememba filtrov ne bo spremenila njegove usode. To ni hrošč v požarnem zidu, to je pogodba stanjskega filtriranja.

Uprite se skušnjavi, da bi na produkcijskem prehodu izpraznili celotno tabelo. conntrack -F je na voljo in uniči tudi vsak sleden tok na stroju, vključno s sejo upravljanja, iz katere delate, in tunelom, ki nosi vašo lupino. Posamezne vnose je mogoče izbrisati, ko resnično potrebujete, vendar je nov tok z novega izvornega vrat običajno čistejši poskus.

Nekatere poti se ne sledijo in se obnašajo obratno. Promet, označen kot notrack v tabeli raw, nekaj tunelov, ki obidejo običajne kavlje, in asimetrično usmerjanje, ki razdeli tok med dva prehoda, vsi ustvarjajo pakete, ki se vrednotijo eden za drugim, ali stanje, ki na obeh koncih nikoli ne nastane. Če se števci premikajo pri vsakem paketu, sumite na takšno pot, preden sumite na vrstni red.

Testirajte iz novega toka s potjo nazaj

Preden preizkusite pravilo, ki bi lahko odrezalo oddaljen dostop, vzpostavite pot za obnovitev: konzolo ponudnika, serijsko konzolo, naslov upravljanja zunaj pasu ali drugi vmesnik, ki ga pravilo ne more zadeti. Časovnik za razveljavitev je razumen spremljevalec, saj bo obnovil prejšnji nabor pravil, tudi če vaša seja med testom umre.

Nato testirajte z izmenjavo, ki je stanje še ni moglo pokriti. Prekinite in znova povežite odjemalca, da nastane nova peterica, in med tem opazujte oba konca:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Izvedite test v obeh smereh. Pravilo, ki blokira novi dohodni rokovanje, lahko še vedno dovoli pot odgovora, ali obratno, in enosmerni izid je običajen razlog, da zaklep deluje na pol. Po testu se povežite še enkrat, da potrdite ustaljeno stanje, in preverite, ali je zakonit dostop upravljanja preživel; pravilo, napisano za ena vrata, ima navado ujemati širši razpon, kot je bilo mišljeno.

Zabeležite namen in položaj skupaj s pravilom

Pravilo brez zabeleženega namena je pravilo, ki si ga nihče ne upa odstraniti. Ob vsakem vnosu zaklepa hranite tok, ki ga ščiti, verigo in kavelj, v katerem živi, položaj, ki ga mora držati glede na širše odobritve, in test, ki je to dokazal. Ko nekdo čez pol leta uredi okoliški nabor pravil, je ta zapis edino opozorilo, da je bil položaj nameren.

Preden zaprete spremembo, potrdite štiri stvari: delujoči nabor pravil se ujema z datoteko, novo pravilo ima po svežem poskusu števce, ki niso nič, nasprotna smer in dostop upravljanja še delujeta, in enkrat ste se znova povezali, da bi dokazali ustaljeno stanje in ne stanja seje, starejše od spremembe. Če kar koli od tega ni preverjeno, sprememba ni končana, ne glede na to, kaj počne tunel.

Sorodni članki