Змена правіла фаервала не працуе: парадак правілаў і стан злучэння

Вы змянілі правіла, перазагрузілі набор правілаў, і тунель паводзіць сябе дакладна так, як раней. У гэтага выніку дзве частыя прычыны, і ім патрэбны розныя тэсты. Або новае правіла стаіць пасля папярэдняга правіла, якое ўжо прыняло пакет, або абмен, за якім вы назіраеце, — гэта адсочванае злучэнне, якое змена ніколі не пераацэньвае. Правіла ў файле выяўляе намер; што вырашае лёс пакета — гэта актыўны шлях, які ён сустракае. Прайдзіце праверкі ніжэй па парадку і трымайце шлях назад, пакуль робіце гэта.

Парадак правілаў і стан злучэння — розныя няспраўнасці

Упарадкаваныя ланцугі ацэньваюцца зверху ўніз, і першае правіла, якое дасягае канчатковага вердыкту, спыняе праход па гэтым ланцугу. Пастаўце шырокі дазвол вышэй за старанна напісанае правіла блакіроўкі, і правіла блакіроўкі становіцца дакументацыяй: яно ёсць у наборы правілаў, яго лічыльнік нулявы, і ніводзін пакет да яго не дабярэцца. Той самы тэкст, ужыты да іншага ланцуга, таксама нічога не даказвае. У nftables базавыя ланцугі далучаюцца да хукаў на пэўных прыярытэтах, таму дазвол у адным ланцугу не перашкаджае іншаму ланцугу на іншым хуку ці прыярытэце бачыць той самы пакет.

Адсочванне злучэнняў стварае другі сімптом, і знешне ён выглядае цалкам так сама. Як толькі паток апынуўся ў табліцы станаў, дазвол для ўсталяваных або звязаных вяртаецца блізка да верху ланцуга яшчэ да таго, як ваша новае правіла будзе разгледжана. У адлюстраванняў NAT тая самая ўласцівасць: пераўтварэнне замацавалася, калі паток пачынаўся, таму змененае правіла postrouting не перапісвае сеанс, які ўжо ідзе. Менавіта таму змена выглядае працуючай у 09:00 для новага злучэння і выглядае нічога не робячай для сеанса, які хтосьці адкрыў у 08:55.

Хмарныя групы бяспекі дадаюць трэцюю мадэль, якая ловіць тых, хто вучыўся на iptables. Іх уваходныя правілы — гэта спіс дазволаў, які ацэньваецца як мноства, а не як праход па першым супадзенні, яны захоўваюць стан, і выдаленне правіла дазволу не спыняе патокаў, якія ўжо адсочваюцца. Калі меркаваць пра семантыку першага супадзення на платформе, дзе яе няма, можна прыйсці да ўпэўненых, але памылковых высноў.

Чытайце актыўны набор правілаў, а не файл, які вы змянілі

Пачніце з таго, што ядро ўжывае прама зараз. Захаваная канфігурацыя, якая ніколі не была ўжытая, тлумачыць дзіўна шмат нязменных паводзін, і выключыць яе каштуе адной каманды:

nft list ruleset
iptables-save

Затым спытайце, ці дасягае ваша правіла хоць нейкага выканання. Лічыльнікі пакетаў адказваюць на гэта напрамкі і адказваюць лепш за любое разважанне пра намер:

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

Правіла блакіроўкі з нулём пакетаў пасля рэальнай спробы тэсту — гэта не праблема палітыкі, а праблема пазіцыі. Перамясціць яго — змена ў адзін радок, і сінтаксіс — менавіта тое, што выклікала першапачатковую памылку. З iptables -I устаўляе, а -A дадае ў канец; з nftables insert ставіць правіла ў пачатак ланцуга, а add дадае ў канец. Калі правіла павінна перамагчы, скажыце пра гэта яўна, замест таго каб давяраць парадку, які выпадкова загрузіўся.

Дакажыце, ці адсочваецца паток

Перш чым вінаваціць правіла, праверце, ці трафік увогуле з'яўляецца адсочваным злучэннем. Спытайце табліцу станаў пра канкрэтны паток, а не вывальвайце яе цалкам:

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

Вывад паказвае стан і астатні тайм-аўт, і менавіта так вы адрозніваеце ўсталяваны сеанс ад новай спробы; рэжым падзей друкуе абнаўленні ў момант іх узнікнення, што карысна, пакуль вы перавызначаеце кліента. Калі паток прысутнічае ў стане ўсталяванага яшчэ да таго, як вы нешта чапалі, ніводнае змяненне правілаў фільтрацыі не зменіць яго лёс. Гэта не памылка ў фаервале, гэта дамова фільтрацыі са станам.

Супраціўляйцеся спакусе цалкам скінуць табліцу на прадукцыйным шлюзе. conntrack -F даступны, і ён таксама знішчае кожны адсочваны паток на машыне, уключаючы сеанс кіравання, з якога вы працуеце, і тунель, што нясе вашу абалонку. Асобныя запісы можна выдаляць, калі гэта сапраўды патрэбна, але новы паток з новага зыходнага порта звычайна чысцейшы эксперымент.

Некаторыя шляхі не адсочваюцца, і яны паводзяць сябе наадварот. Трафік, пазначаны notrack у табліцы raw, некаторыя тунелі, што абыходзяць звычайныя хукі, і асіметрычная маршрутызацыя, якая раздзірае паток паміж двума шлюзамі, — усё гэта дае пакеты, якія ацэньваюцца па адным, або стан, які ніколі не ствараецца на абодвух канцах. Калі лічыльнікі рухаюцца на кожны пакет, падазрайце такі шлях раней, чым падазраць парадак.

Тэстуйце з новага патоку і з шляхам назад

Перш чым тэставаць правіла, якое можа адрэзаць аддалены доступ, забяспечце шлях аднаўлення: кансоль правайдэра, паслядоўную кансоль, адрас кіравання па-за асноўным каналам або другі інтэрфейс, які правіла не можа закрануць. Таймер адкату — разумны спадарожнік, бо ён верне папярэдні набор правілаў, нават калі ваш сеанс загіне пасярод тэсту.

Затым тэстуйце абменам, які не мог быць ужо пакрыты станам. Адключыце і зноў падключыце кліента, каб стварылася новая пяцёрка, і назірайце за абодвума канцамі, пакуль гэта адбываецца:

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

Правядзіце тэст у абодвух напрамках. Правіла, якое блакуе новае ўваходнае рукапоцісканне, можа ўсё яшчэ дазваляць шлях адказу, або наадварот, і аднабаковы вынік — звычайная прычына таго, што блакіроўка працуе напалову. Пасля тэсту падключыцеся яшчэ раз, каб пацвердзіць устойлівы стан, і праверце, што законны доступ кіравання выжыў; правіла, напісанае пад адзін порт, мае звычку супадаць з шырэйшым дыяпазонам, чым задумана.

Запісвайце мэту і пазіцыю разам з правілам

Правіла без запісанай мэты — гэта правіла, якое ніхто не адважыцца выдаліць. Побач з кожным запісам блакіроўкі трымайце паток, які ён абараняе, ланцуг і хук, у якім ён жыве, пазіцыю, якую ён павінен займаць адносна шырэйшых дазволаў, і тэст, які гэта даказаў. Калі праз шэсць месяцаў хтосьці зменіць навакольны набор правілаў, гэтая нататка — адзінае папярэджанне, што пазіцыя была наўмыснай.

Перш чым закрыць змену, пацвердзіце чатыры рэчы: працоўны набор правілаў адпавядае файлу, новае правіла мае ненулявыя лічыльнікі пасля новай спробы, зваротны напрамак і доступ кіравання ўсё яшчэ працуюць, і вы адзін раз перападключыліся, каб даказаць устойлівы стан, а не стан сеанса, які старэйшы за змену. Калі хоць нешта з гэтага не праверана, змена не скончана, што б ні рабіў тунель.