Імя ланцуга — не хук: iptables супраць nftables
Ланцуг — гэта кантэйнер; хук вырашае, ці звяртаецца да яго ядро. Параўнайце ўбудаваныя ланцугі iptables з базавымі ланцугамі nftables перад змяненнем правілаў.
Абодва файрволы могуць фільтраваць перанакіраваны трафік VPN, і яны далучаюць правілы да шляху пакета па-рознаму. У iptables ёсць убудаваныя ланцугі ўнутры табліцы, таму FORWARD існуе як названая кропка хука. nftables аддзяляе імя ланцуга ад яго тыпу, хука і прыярытэту, а гэта значыць, што звычайны ланцуг з назвай FORWARD не фільтруе наогул нічога. Параўнанне дзвюх мадэляў тлумачыць, чаму запіс, які выглядае правільным у адным інструменце, не мае эфекту ў другім.
Ланцуг — гэта кантэйнер. Ці звяртаецца да яго ядро, залежыць ад рэалізацыі і ад таго, як набор правілаў далучае яго.
Дзве мадэлі, два розныя далучэнні
У iptables табліца filter мае тры ўбудаваныя ланцугі — INPUT, FORWARD і OUTPUT, а -N стварае ланцуг, вызначаны карыстальнікам, які дзейнічае толькі тады, калі да яго пераходзяць з аднаго з іх. Кіраўніцтва nftables замест гэтага вызначае базавыя ланцугі, якія абвяшчаюць свой тып, хук і прыярытэт, і звычайныя ланцугі, якія гэтага не робяць. Базавы ланцуг можа мець любое імя, а звычайны ланцуг з назвай FORWARD не атрымлівае ніякіх уласцівасцяў ад сваёй назвы. У гэтым уся розніца, і яна нябачная ў падручніку, які паказвае толькі тэкст правілаў.
Бэкенды сумяшчальнасці дадаюць другую прычыну не рабіць высновы пра паводзіны з назвы каманды. Дакументацыя iptables адзначае аперацыі, якія адрозніваюцца пад iptables-nft, таму разглядайце натыўны nftables, iptables-nft і стары набор правілаў як тры сістэмы, а не як тры напісанні адной.
Чытайце памылку ў яе рэальным кантэксце
Адсутная табліца, памылка правоў, недаступная магчымасць ядра і адсутны названы ланцуг — гэта чатыры розныя знаходкі, і толькі адна датычыцца ланцуга. Запішыце версію інструмента, запытаныя сямейства адрасоў і табліцу, прастору імёнаў сеткі і першую дакладную памылку. Затым праверце, які кампанент валодае наборам правілаў: служба файрвола або шлюз пад кіраваннем прадукту можа ствараць свае ланцугі і парадак. Даданне натыўнага ланцуга побач з імі пакідае кіраваную палітыку некранутай і робіць інвентар яшчэ больш заблытаным.
Прастора імёнаў кантэйнера можа ўтрымліваць іншы набор правілаў, чым хост, таму каманда, выкананая ў няправільным кантэксце, не можа паказаць, які ланцуг бачыў перанакіраваны пакет. Павышэнне правоў таму, што чаканы ланцуг не быў бачны, — не дыягностыка.
Лічыльнікі даказваюць дасягненне, а не вердыкт
Лічыльнікі правілаў паведамляюць, што правіла было дасягнута. Яны не паведамляюць, што наступнае правіла дазволіла аперацыю, і не даказваюць, што ўсе альтэрнатыўныя шляхі былі адхілены. Чытайце іх падчас аднаго бясшкоднага дазволенага патоку, разам з парадкам правілаў і далучэннем ланцуга, і стаўцеся да іх як да аднаго назірання, а не вердыкту. Ненулявы лічыльнік на правіле скіду азначае, што трафік патрапіў у яго; гэта нічога не кажа пра трафік, які не патрапіў.
Перанакіраванне IP у ядры — цалкам асобная налада. Існаванне ланцуга не ўключае перанакіраванне, а адсутнасць знаёмай назвы не азначае, што перанакіраванне спынілася.
Апішыце паток, які вы разлічваеце абараніць
Запішыце адзін запыт кліента пасля дэкапсуляцыі: яго крыніцу, прызначэнне, сямейства адрасоў і тое, ці ён завяршаецца на шлюзе або праходзіць праз яго. Увод лакальнай службы і перанакіраваны трафік назіраюцца ў розных кропках, таму ім патрэбныя розныя правілы і розныя тэсты. Для VPN праз мост праверце таксама шлях моста, бо ланцуг узроўню IP не кантралюе кадры Ethernet аўтаматычна.
Захавайце незалежны доступ для аднаўлення перад змяненнем аддаленага шлюза. Затым пацвердзіце меркаваны паток і неабходныя адмовы ў адным і тым жа наборы правілаў. Новы пусты ланцуг са знаёмай назвай — гэта не рамонт.
Параўнанне сканчаецца адным пытаннем: які хук ядро насамрэч выклікае для гэтага пакета? Адкажыце на яго, і імя ланцуга перастане мець значэнне.