Ŝanĝo de fajroŝirma regulo ne funkcias: ordo de reguloj kaj konekta stato

Vi redaktis la regulon, reŝutis la regulan aron, kaj la tunelo kondutas ĝuste kiel antaŭe. Tiu rezulto havas du oftajn kaŭzojn, kaj ili postulas malsamajn testojn. Aŭ la nova regulo staras post pli frua regulo, kiu jam akceptis la paketon, aŭ la interŝanĝo, kiun vi observas, estas spurata konekto, kiun la ŝanĝo neniam ree taksas. Regulo en dosiero esprimas intencon; tion, kio decidas pri la paketo, faras la aktiva vojo, kiun ĝi renkontas. Trapasu la subajn kontrolojn laŭ ordo kaj konservu vojon reen dum vi faras tion.

Ordo de reguloj kaj konekta stato estas malsamaj paneoj

Ordigitaj ĉenoj estas taksataj de supre malsupren, kaj la unua regulo, kiu atingas finan verdikton, finas la iradon tra tiu ĉeno. Metu larĝan permeson super zorgeme verkita ŝlosa regulo, kaj la ŝlosa regulo fariĝas dokumentado: ĝi estas en la regula aro, ĝia nombrilo estas nulo, kaj neniu paketo iam atingos ĝin. La sama teksto aplikita al alia ĉeno ankaŭ pruvas nenion. En nftables bazaj ĉenoj alkroĉiĝas al hokoj laŭ prioritatoj, do permeso en unu ĉeno ne malhelpas alian ĉenon sur alia hoko aŭ prioritato vidi la saman paketon.

Konekta spurado produktas la duan simptomon, kaj de ekstere ĝi aspektas idente. Post kiam fluo estas en la stata tabelo, permeso por establita-aŭ-rilata proksime al la supro de la ĉeno revenas antaŭ ol via nova regulo estas konsultita. NAT-mapoj havas la saman econ: la traduko fiksiĝis kiam la fluo komenciĝis, do redaktita postrouting-regulo ne reskribas sesion, kiu jam funkcias. Tial ŝanĝo ŝajnas funkcii je 09:00 por nova konekto kaj ŝajnas fari nenion por la sesio, kiun iu malfermis je 08:55.

Nubaj sekurecaj grupoj aldonas trian modelon, kiu kaptas homojn, kiuj lernis per iptables. Iliaj envenaj reguloj estas permeslisto taksata kiel aro anstataŭ kiel irado laŭ unua kongruo, ili konservas staton, kaj forigo de permesa regulo ne finas fluojn, kiuj jam estas spurataj. Supozi semantikon de unua kongruo sur platformo, kiu ne havas ĝin, kondukas al memfidaj, malĝustaj konkludoj.

Legu la aktivan regulan aron, ne la dosieron, kiun vi redaktis

Komencu per tio, kion la kerno nun efektivigas. Konservita agordo, kiu neniam estis aplikita, klarigas surprize multajn senŝanĝajn kondutojn, kaj ekskludi ĝin kostas unu komandon:

nft list ruleset
iptables-save

Poste demandu, ĉu via regulo entute estas atingata. Paketaj nombriloj respondas tion rekte, kaj ili respondas pli bone ol iu ajn rezonado pri intenco:

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

Ŝlosa regulo kun nulo da paketoj post reala testprovo ne estas politika problemo, ĝi estas pozicia problemo. Movi ĝin estas ŝanĝo de unu linio, kaj la sintakso estas ĝuste tio, kio kaŭzis la originalan cimon. Kun iptables -I enmetas kaj -A aldonas ĉe la fino; kun nftables insert metas regulon ĉe la komenco de la ĉeno dum add aldonas ĉe la fino. Kiam regulo devas venki, diru tion eksplicite anstataŭ fidi la ordon, kiu hazarde ŝargiĝis.

Pruvu, ĉu la fluo estas spurata

Antaŭ ol kulpigi la regulon, kontrolu, ĉu la trafiko entute estas spurata konekto. Demandu la statan tabelon pri la konkreta fluo anstataŭ elverŝi ĝin tutan:

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

La listo montras la staton kaj la restantan tempolimon, kaj tiel vi distingas estabitan sesion de freŝa provo; la eventa reĝimo presas ĝisdatigojn dum ili okazas, kio utilas dum vi rekonektas klienton. Se la fluo ĉeestas kun establita stato antaŭ ol vi tuŝis ion ajn, neniu redakto de la filtraj reguloj ŝanĝos ĝian sorton. Tio ne estas cimo en la fajroŝirmilo, tio estas la kontrakto de stata filtrado.

Rezistu la fuĝon malplenigi la tutan tabelon sur produktada enirejo. conntrack -F estas disponebla, kaj ĝi ankaŭ detruas ĉiun spuratan fluon en la maŝino, inkluzive de la administra sesio, el kiu vi laboras, kaj de la tunelo, kiu portas vian ŝelon. Unuopaj rikordoj povas esti forigitaj kiam vi vere bezonas, sed freŝa fluo el nova fonta pordo kutime estas pli pura eksperimento.

Iuj vojoj ne estas spurataj, kaj ili kondutas la kontraŭan manieron. Trafiko markita kiel notrack en la tabelo raw, iuj tuneloj, kiuj preterpasas la normalajn hokojn, kaj nesimetria enkursigo, kiu dividas fluon inter du enirejoj, ĉiuj produktas paketojn taksatajn unuope, aŭ staton, kiu neniam kreiĝas ĉe ambaŭ finoj. Se la nombriloj moviĝas por ĉiu paketo, suspektu tian vojon antaŭ ol suspekti la ordon.

Testu el freŝa fluo kun vojo reen

Antaŭ ol testi regulon, kiu povus tranĉi malproksiman aliron, starigu reakiran vojon: la konzolon de la provizanto, serian konzolon, administran adreson eksterbendan, aŭ duan interfacon, kiun la regulo ne povas kongrui. Ruligo-tempigilo estas racia kunulo, ĉar ĝi restarigos la antaŭan regulan aron eĉ se via sesio mortas meze de la testo.

Poste testu per interŝanĝo, kiun la stato jam ne povus kovri. Malkonektu kaj rekonektu la klienton tiel, ke kreiĝu nova kvinkopo, kaj observu ambaŭ finojn dum tio okazas:

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

Plenumu la teston en ambaŭ direktoj. Regulo, kiu blokas la novan envenan manpremon, ankoraŭ povas permesi la respondan vojon, aŭ la malon, kaj unudirekta rezulto estas la kutima kialo, ke ŝloso duone funkcias. Rekonektu unufoje post la testo por konfirmi la stabilan staton, kaj kontrolu, ĉu la laŭleĝa administra aliro pluvivis; regulo verkita por unu pordo kutimas kongrui pli larĝan intervalon ol intencite.

Registru celon kaj pozicion kune kun la regulo

Regulo sen registrita celo estas regulo, kiun neniu kuraĝas forigi. Apud ĉiu ŝlosa rikordo konservu la fluon, kiun ĝi protektas, la ĉenon kaj hokon, en kiu ĝi vivas, la pozicion, kiun ĝi devas teni rilate al pli larĝaj permesoj, kaj la teston, kiu pruvis ĝin. Kiam iu post ses monatoj redaktos la ĉirkaŭan regulan aron, tiu noto estas la sola averto, ke la pozicio estis intenca.

Antaŭ ol fermi la ŝanĝon, konfirmu kvar aferojn: la kuranta regula aro kongruas kun la dosiero, la nova regulo havas nombrilojn malsamajn de nulo post freŝa provo, la inversa direkto kaj la administra aliro ankoraŭ funkcias, kaj vi rekonektis unufoje por pruvi la stabilan staton anstataŭ la staton de sesio pli malnova ol la ŝanĝo. Se io el tio ne estas kontrolita, la ŝanĝo ne estas finita, kion ajn la tunelo faras.