Ugniasienės taisyklės pakeitimas neveikia: taisyklių tvarka ir ryšio būsena
Pakeista taisyklė gali stovėti už ankstesnio leidimo arba būti praleista ryšių sekimo. Atskirkite du bandymus, naudokite naują srautą ir palikite kelią atgal.
Pakeitėte taisyklę, iš naujo įkėlėte taisyklių rinkinį, o tunelis elgiasi lygiai taip pat kaip anksčiau. Šis rezultatas turi dvi įprastas priežastis, ir joms reikia skirtingų bandymų. Arba nauja taisyklė yra po ankstesne taisykle, kuri jau priėmė paketą, arba stebimas mainas yra sekamas ryšys, kurio pakeitimas niekada iš naujo neįvertina. Taisyklė faile reiškia ketinimą; paketo likimą lemia aktyvus kelias, kurį jis sutinka. Atlikite toliau pateiktus patikrinimus iš eilės ir tuo metu laikykite atvirą kelią atgal.
Taisyklių tvarka ir ryšio būsena yra skirtingi gedimai
Surikiuotos grandinės vertinamos iš viršaus į apačią, ir pirmoji taisyklė, pasiekusi galutinį sprendimą, baigia ėjimą per tą grandinę. Įdėkite platų leidimą virš kruopščiai parašytos blokavimo taisyklės, ir blokavimo taisyklė tampa dokumentacija: ji yra rinkinyje, jos skaitiklis nulis, ir joks paketas jos niekada nepasieks. Tas pats tekstas, pritaikytas kitai grandinei, taip pat nieko neįrodo. nftables bazinės grandinės jungiamos prie kabliukų pagal prioritetus, todėl leidimas vienoje grandinėje netrukdo kitai grandinei kitame kabliuke ar prioritete matyti to paties paketo.
Ryšių sekimas sukuria antrą simptomą, ir iš išorės jis atrodo identiškai. Kai srautas atsiduria būsenų lentelėje, leidimas established-or-related netoli grandinės viršaus grįžta dar prieš tai, kai jūsų nauja taisyklė apskritai patikrinama. NAT susiejimai turi tą pačią savybę: vertimas buvo nustatytas srautui prasidėjus, todėl pakeista postrouting taisyklė neperrašo jau veikiančios sesijos. Štai kodėl pakeitimas atrodo veikiantis 09:00 naujam ryšiui ir atrodo nieko nedarantis sesijai, kurią kas nors atidarė 08:55.
Debesų saugos grupės prideda trečią modelį, kuris pagauna žmones, mokytus su iptables. Jų įeinančios taisyklės yra leidimų sąrašas, vertinamas kaip aibė, o ne kaip ėjimas pagal pirmą atitikimą, jos yra būsenos, ir leidimo taisyklės pašalinimas nenutraukia jau sekamų srautų. Pirmo atitikimo semantikos prielaida platformoje, kuri jos neturi, veda prie užtikrintų, klaidingų išvadų.
Skaitykite aktyvų taisyklių rinkinį, o ne failą, kurį pakeitėte
Pradėkite nuo to, ką branduolys vykdo dabar. Išsaugota konfigūracija, kuri niekada nebuvo pritaikyta, paaiškina stebėtinai daug nepakitusio elgesio, ir ją atmesti kainuoja vieną komandą:
nft list ruleset
iptables-saveTada paklauskite, ar jūsų taisyklė apskritai pasiekiama. Paketų skaitikliai atsako tiesiogiai ir atsako geriau nei bet koks samprotavimas apie ketinimą:
iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forwardBlokavimo taisyklė su nuliu paketų po tikro bandymo nėra politikos problema, tai pozicijos problema. Perkelti ją yra vienos eilutės pakeitimas, o sintaksė yra būtent tai, kas sukėlė pradinę klaidą. Su iptables -I įterpia, o -A prideda pabaigoje; su nftables insert padeda taisyklę grandinės pradžioje, o add prideda pabaigoje. Kai taisyklė turi laimėti, pasakykite tai aiškiai, o ne pasikliaukite tvarka, kuri buvo įkelta atsitiktinai.
Įrodykite, ar srautas sekamas
Prieš kaltindami taisyklę, patikrinkite, ar srautas apskritai yra sekamas ryšys. Klauskite būsenų lentelės apie konkretų srautą, o ne išliekite ją visą:
conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194Sąrašas rodo būseną ir likusį laiką, ir taip atskiriate nusistovėjusią sesiją nuo naujo bandymo; įvykių režimas spausdina atnaujinimus jiems vykstant, kas naudinga, kai iš naujo prijungiate klientą. Jei srautas jau yra nusistovėjusios būsenos prieš jums ką nors palietus, joks filtro taisyklių pakeitimas nepakeis jo likimo. Tai ne ugniasienės klaida, tai būseninio filtravimo sutartis.
Atsispirkite pagundai išvalyti visą lentelę produkcinėje šliuzoje. conntrack -F yra prieinama, ir ji taip pat sunaikina kiekvieną sekamą srautą mašinoje, įskaitant valdymo sesiją, iš kurios dirbate, ir tunelį, kuris neša jūsų apvalkalą. Atskirus įrašus galima ištrinti, kai tikrai reikia, bet naujas srautas iš naujo šaltinio prievado paprastai yra švaresnis eksperimentas.
Kai kurie keliai nėra sekami, ir jie elgiasi priešingai. Srautas, pažymėtas notrack raw lentelėje, kai kurie tuneliai, apeinantys įprastus kabliukus, ir asimetrinis maršrutizavimas, padalijantis srautą tarp dviejų šliuzų, visi sukuria paketus, vertinamus po vieną, arba būseną, kuri niekada nesukuriama abiejuose galuose. Jei skaitikliai juda su kiekvienu paketu, įtarkite tokį kelią anksčiau, nei įtarsite tvarką.
Bandykyte iš naujo srauto su keliu atgal
Prieš bandydami taisyklę, kuri galėtų nutraukti nuotolinę prieigą, sukurkite atkūrimo kelią: teikėjo konsolę, nuosekliąją konsolę, valdymo adresą už juostos arba antrą sąsają, kurios taisyklė negali atitikti. Grąžinimo laikmatis yra protingas palydovas, nes jis atkurs ankstesnį taisyklių rinkinį, net jei jūsų sesija mirs bandymo viduryje.
Tada bandykite mainu, kurio būsena jau negalėjo padengti. Atjunkite ir vėl prijunkite klientą, kad būtų sukurtas naujas penketas, ir stebėkite abu galus, kol tai vyksta:
tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pagerAtlikite bandymą abiem kryptimis. Taisyklė, blokuojanti naują įeinančio rankos paspaudimo, vis tiek gali leisti atsakymo kelią, arba atvirkščiai, ir vienkryptis rezultatas yra įprasta priežastis, kodėl blokavimas veikia pusiau. Po bandymo prisijunkite dar kartą, kad patvirtintumėte pastovią būseną, ir patikrinkite, ar teisėta valdymo prieiga išliko; taisyklė, parašyta vienam prievadui, linkusi atitikti platesnį diapazoną nei numatyta.
Užrašykite tikslą ir poziciją kartu su taisykle
Taisyklė be užrašyto tikslo yra taisyklė, kurios niekas neišdrįsta pašalinti. Prie kiekvieno blokavimo įrašo laikykite srautą, kurį ji saugo, grandinę ir kabliuką, kuriame ji gyvena, poziciją, kurią ji turi išlaikyti platesnių leidimų atžvilgiu, ir bandymą, kuris tai įrodė. Kai po pusės metų kas nors redaguos aplinkinį taisyklių rinkinį, ta pastaba bus vienintelis įspėjimas, kad pozicija buvo sąmoninga.
Prieš užbaigdami pakeitimą, patvirtinkite keturis dalykus: veikiantis taisyklių rinkinys atitinka failą, naujos taisyklės skaitikliai po naujo bandymo nėra nuliai, priešinga kryptis ir valdymo prieiga vis dar veikia, ir jūs kartą prisijungėte iš naujo, kad įrodytumėte pastovią būseną, o ne sesijos, kuri senesnė už pakeitimą, būseną. Jei kas nors iš to nepatikrinta, pakeitimas nebaigtas, kad ir ką daro tunelis.