Tulemüüri reegli muudatus ei toimi: reeglite järjekord ja ühenduse olek

Muutsite reeglit, laadisite reeglistiku uuesti ja tunnel käitub täpselt nagu enne. Sellel tulemusel on kaks tavalist põhjust ja need nõuavad erinevaid teste. Kas uus reegel asub pärast varasemat reeglit, mis on paketi juba vastu võtnud, või on vahetus, mida jälgite, jälgitav ühendus, mida muudatus kunagi uuesti ei hinda. Failis olev reegel väljendab kavatsust; paketi saatuse otsustab aktiivne tee, millega see kokku puutub. Käige allolevad kontrollid järjekorras läbi ja hoidke selle juures tagasiteed lahtisena.

Reeglite järjekord ja ühenduse olek on erinevad rikked

Järjestatud ahelaid hinnatakse ülalt alla ja esimene reegel, mis jõuab lõpliku otsuseni, lõpetab selle ahela läbimise. Asetage lai lubamine hoolikalt kirjutatud lukustusreegli kohale ja lukustusreeglist saab dokumentatsioon: see on reeglistikus, selle loendur on null ja ükski pakett ei jõua selleni kunagi. Sama tekst teisele ahelale rakendatuna ei tõesta samuti midagi. Nftablesis kinnituvad baasahelad konksudele prioriteetide järgi, seega ühes ahelas antud lubamine ei takista teist ahelat teisel konksul või prioriteedil sama paketti nägemast.

Ühenduste jälgimine tekitab teise sümptomi ja väljastpoolt näeb see identne välja. Kui voog on olekutabelis, naaseb ahela ülaosa lähedal asuv lubamine olekule established-or-related enne, kui teie uut reeglit üldse vaadatakse. NAT-i vastendustel on sama omadus: tõlge fikseeriti voo alguses, seega muudetud postrouting-reegel ei kirjuta üle juba töötavat seanssi. Seetõttu näib muudatus 09:00 toimivat uue ühenduse puhul ja näib mitte midagi tegevan seansi puhul, mille keegi avas 08:55.

Pilve turvagrupid lisavad kolmanda mudeli, mis püüab inimesi, kes õppisid iptablesi peal. Nende sissetulevad reeglid on lubatud loend, mida hinnatakse hulgana, mitte esimese vastega läbimisena, need on olekuga ja lubamisreegli eemaldamine ei lõpeta juba jälgitavaid vooge. Esimese vaste semantika eeldamine platvormil, kus seda pole, viib enesekindlate, valede järeldusteni.

Lugege aktiivset reeglistikku, mitte faili, mida muutsite

Alustage sellest, mida kernel praegu rakendab. Salvestatud konfiguratsioon, mida kunagi ei rakendatud, seletab üllatavalt palju muutumatuid käitumisi ja selle välistamine maksab ühe käsu:

nft list ruleset
iptables-save

Seejärel küsige, kas teie reeglini üldse jõutakse. Paketiloendurid vastavad sellele otse ja vastavad paremini kui ükskõik milline mõttekäik kavatsuse kohta:

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

Lukustusreegel, mille loendur on pärast tõelist testikat null, ei ole poliitika probleem, vaid positsiooni probleem. Selle liigutamine on ühe rea muudatus ja süntaks on täpselt see, mis algse vea põhjustas. Iptablesiga -I lisab ette ja -A lisab lõppu; nftablesiga insert paigutab reegli ahela algusesse, samal ajal kui add lisab lõppu. Kui reegel peab võitma, öelge seda selgesõnaliselt, selle asemel et usaldada järjekorda, mis juhtumisi laaditi.

Tõestage, kas voogu jälgitakse

Enne kui reeglit süüdistate, kontrollige, kas liiklus on üldse jälgitav ühendus. Küsige olekutabelilt konkreetset voogu, selle asemel et see tervikuna välja valada:

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

Loend näitab olekut ja järelejäänud ajalõppu ja nii eristate kehtestatud seanssi värskest katsest; sündmuste režiim trükib uuendusi nende toimumise ajal, mis on kasulik klienti uuesti ühendades. Kui voog on kehtestatud olekus juba enne, kui midagi puutusite, ei muuda ükski filtrite reeglite muudatus selle saatust. See ei ole tulemüüri viga, see on olekuga filtreerimise leping.

Vastustage kiusatust terviklik tabel tootmisväraval tühjendada. conntrack -F on saadaval ja see hävitab ka kõik jälgitavad vood masinas, sealhulgas haldusseansi, millest töötate, ja tunneli, mis teie kesta kannab. Üksikuid kirjeid saab kustutada, kui seda tõesti vajate, kuid värske voog uuelt lähtepordilt on tavaliselt puhtam katse.

Mõnda teed ei jälgita ja need käituvad vastupidises suunas. Liiklus, mis on märgitud notrack raw-tabelis, mõned tunnelid, mis lähevad tavalisest konksudest mööda, ja asümmeetriline marsruutimine, mis jagab voo kahe värava vahel, annavad kõik pakette, mida hinnatakse ükshaaval, või oleku, mida ei teki kunagi mõlemas otsas. Kui loendurid liiguvad iga paketi juures, kahtlustage sellist teed enne, kui kahtlustate järjekorda.

Testige värskest voost tagasiteega

Enne kui testite reeglit, mis võib kaugjuurdepääsu ära lõigata, looge taastetee: teenusepakkuja konsool, jadakonksol, välisvõrgu haldusaadress või teine liides, millega reegel sobida ei saa. Tagasipööramise taimer on mõistlik kaaslane, sest see taastab eelmise reeglistiku ka siis, kui teie seanss sureb keset testi.

Seejärel testige vahetusega, mida olek ei oleks saanud juba katta. Katkestage ja ühendage klient uuesti, et tekiks uus viisik, ja jälgige selle toimumise ajal mõlemat otsa:

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

Tehke test mõlemas suunas. Reegel, mis blokeerib uue sissetuleva kätlemise, võib siiski vastusetee lubada, või vastupidi, ja ühesuunaline tulemus on tavaline põhjus, miks lukustus töötab pooleldi. Pärast testi ühendage veel kord uuesti, et kinnitada püsivat olekut, ja kontrollige, kas seaduslik haldusjuurdepääs jäi alles; ühe pordi jaoks kirjutatud reeglil on komme sobida kavatsetust laiema vahemikuga.

Kirjutage eesmärk ja asukoht reegli juurde

Reegel ilma kirja pandud eesmärgita on reegel, mida keegi ei julge eemaldada. Iga lukustuskirje juurde hoidke voog, mida see kaitseb, ahel ja konks, milles see elab, positsioon, mida see peab laiemate lubamiste suhtes hoidma, ja test, mis seda tõestas. Kui keegi kuus kuud hiljem ümbritsevat reeglistikku muudab, on see märkus ainus hoiatus, et positsioon oli tahtlik.

Enne muudatuse sulgemist kinnitage nelja asja: töötav reeglistik vastab failile, uuel reeglil on värske katse järel nullist erinevad loendurid, vastassuund ja haldusjuurdepääs töötavad endiselt ning olete korra uuesti ühenduse loonud, et tõestada püsivat olekut, mitte muudatusest vanema seansi olekut. Kui midagi sellest on kontrollimata, ei ole muudatus lõpetatud, mida iganes tunnel teeb.