From edb8013b98aadd2f322a38ce0749fdcc85458f72 Mon Sep 17 00:00:00 2001 From: bol-van Date: Tue, 15 Feb 2022 18:10:11 +0300 Subject: [PATCH] init.d : openrc +x --- docs/nftables_notes.txt | 184 ++++++++++++++++++++-------------------- 1 file changed, 92 insertions(+), 92 deletions(-) diff --git a/docs/nftables_notes.txt b/docs/nftables_notes.txt index c2fc571..9459a37 100644 --- a/docs/nftables_notes.txt +++ b/docs/nftables_notes.txt @@ -1,92 +1,92 @@ -nftables - это технология, пришедшая на замену iptables. -В ней собрали все, что относилось к различным iptables. А их немало. iptables, ip6tables, ebtables, arptables, ipset. -Весь код из разрозненных, но похожих компонент, собрали в одно целое с единым синтаксисом. -Добавили различные конструкции языка, позволяющие писать правила более лаконично, не повторяя одни и те же команды с небольшими различиями. -На nftables можно сделать почти все, что можно было сделать на iptables. Есть то, что можно сделать на nftables, но нельзя на iptables. -Удобно, красиво. - -К сожалению, не обошлось и без боли. 10 лет развития nftables казалось бы должны были вылизать все. Но не тут то было. - -Главная боль N1. Очень серьезная, актуальная для openwrt, и решения не видно. - -ipset-ы позволяли загонять пересекающиеся интервалы ip адресов или подсетей. -nftables sets это не позволяют. Любое пересечение вызывает ошибку. -Есть auto-merge, но это работает только в user mode в процессе nft, при условии, что весь блок адресов загоняется одной командой -и нет пересечений с уже имеющимся контентом в set. -Это не было бы критической проблемой, поскольку скрипты zapret и так загоняют ipset целиком. -Проблема в катастрофическом расходе памяти при операции загона больших интервальных листов, то есть с подсетями и диапазонами. -Чтобы загнать 100000 ipv4 записей, едва хватает 300 Mb памяти устройства. -При успехе операции в ядре список столько не занимает, но суть дела это не меняет. -Для традиционных linux систем это не проблема, но почти все роутеры загнутся. -Приемлемого решения не просматривается. -Сделать записи непересекающимися в листах - задача непростая. Потребуется переписать алгоритм auto-merge из nft, -но с пониженным расходом памяти. -Загонять записи по одному отдельными вызовами nft, игнорируя ошибки, займет вечность. -Загонять блоком отдельных команд, игнорируя ошибки, - nft такого не умеет. Похоже, при любой ошибке происходит откат всего скрипта. -К тому же при таком подходе будут неточности в итоговом результате. -Swap позволяет немного сгладить проблему, но лишь незначительно. -Скажем, если вдруг list загоняется без ошибок с 300 Mb памяти и с падением на 256 Mb, то swap спасает. -Если памяти становится 200 Mb, то swap уже не спасет. Все равно вызывается OOM killer, заодно убивая и другие процессы, кроме nft, -а это уже совсем плохо. Может быть убито что-то важное. - -Боль N2, но не такая смертельная. - -10 лет вылизывания кода, но при загоне больших листов в set-ы то и дело при вызовах nft list происходят seg faults. -Например, падать может nft -t list ruleset, но nft -t list table inet zapret может не падать. -Вроде это не влияет на функционал, но все равно создается неудобство. - -Боль N3, не смертельная, но тоже не айс. - -Какие-то нерациональные алгоритмы разбора таблиц в nft. -Например, есть 1 большой set на 100000 элементов и 1 маленький на 2 элемента. -Чтобы просто пролистать мелкий set или добавить туда еще что-то nft будет мусолить несколько секунд. -Что он делает за это время ? Тащит из ядра огромный блоб, в котором все в куче, и разбирает его, чтобы выделить искомую мелочь ? -В какой-то мере удается это сгладить, обьединяя несколько команд в единый скрипт. - - -Плюс N1, главный - -iptables хороши, когда ими пользуется кто-то один. Иначе это проходной двор. -Когда есть система управления фаерволом, то приходится как-то к ней прикручиваться, чтобы не нарушить ее работу -и управлять правилами синхронно. Нужно уметь внести и удалить отдельные правила когда это нужно, не трогая все остальное. -Некоторые системы управления фаерволом вообще не предполагают, чтобы кто-то еще лез в iptables, и это очень сильно портит жизнь. -У iptables есть предопределенный набор хуков netfilter с фиксированным приоритетом. -В nftables хуков можно создать неограниченное количество с выбранным приоритетом, управляя ими независимо в отдельных таблицах. -Система управления фаерволом может работать в одной таблице (fw4 в случае openwrt) и не трогать все остальное. -zapret может работать в другой таблице и не трогать систему управления фаерволом. Они друг другу не мешают. -Это снимает множество боли. - -Плюс N2 - -Возможность выбора приоритета хука позволяет легко решить проблему хаотической и принудительной дефрагментацией L3 ipv6, -без танцев с загрузкой модулей ядра со специальными параметрами или перекомпиляцией nftables-nft. - -Плюс N3 - -Наличие множеств (anonymous/named sets) позволяет не писать кучу однообразных правил там, где в iptables их пришлось бы написать. - -Плюс N4 - -Если у вас есть nftables, то там наверняка есть уже все или почти все. -Нет кучи разных модулей ядра и .so плагинов для iptables user-mode процесса. -Отдельные модули ядра есть, но их меньше, чем в iptables, и openwrt их делит на меньшее число пакетов, большинство из которых -и так ставятся по умолчанию. user-mode процесс nft и вовсе неделим. EXE-шник + lib. - -Плюс N5 - -Пишут, что nftables работают быстрее. - - -Выводы - -Честно говоря, лучше бы openwrt оставался на iptables. -Пусть они и старые, c недостатками, но как говорится ложка дегтя портит цистерну меда. -nftables - именно тот случай. Все хорошо, но все плохо из-за досадной особенности. -Без больших листов все почти прекрасно. Но большие ip листы убивают все. Не для домашних это роутеров. -А ipset-ы к nftables не прикрутить. -Делать нечего. Openwrt отошел от iptables. С этим придется как-то жить. -Поэтому пришлось сделать для openwrt поддержку и iptables, и nftables (только с версии openwrt 21.xx, в более старых будут проблемы). -iptables можно задействовать на любой openwrt версии. -Если используется fw3, применяется старый механизм интеграции в fw3. -Если он не используется, то правилами iptables управляем как в традиционных linux системах - то есть с возможностью -запуска и остановки, а скрипт запуска вносит в том числе и правила iptables. +nftables - это технология, пришедшая на замену iptables. +В ней собрали все, что относилось к различным iptables. А их немало. iptables, ip6tables, ebtables, arptables, ipset. +Весь код из разрозненных, но похожих компонент, собрали в одно целое с единым синтаксисом. +Добавили различные конструкции языка, позволяющие писать правила более лаконично, не повторяя одни и те же команды с небольшими различиями. +На nftables можно сделать почти все, что можно было сделать на iptables. Есть то, что можно сделать на nftables, но нельзя на iptables. +Удобно, красиво. + +К сожалению, не обошлось и без боли. 10 лет развития nftables казалось бы должны были вылизать все. Но не тут то было. + +Главная боль N1. Очень серьезная, актуальная для openwrt, и решения не видно. + +ipset-ы позволяли загонять пересекающиеся интервалы ip адресов или подсетей. +nftables sets это не позволяют. Любое пересечение вызывает ошибку. +Есть auto-merge, но это работает только в user mode в процессе nft, при условии, что весь блок адресов загоняется одной командой +и нет пересечений с уже имеющимся контентом в set. +Это не было бы критической проблемой, поскольку скрипты zapret и так загоняют ipset целиком. +Проблема в катастрофическом расходе памяти при операции загона больших интервальных листов, то есть с подсетями и диапазонами. +Чтобы загнать 100000 ipv4 записей, едва хватает 300 Mb памяти устройства. +При успехе операции в ядре список столько не занимает, но суть дела это не меняет. +Для традиционных linux систем это не проблема, но почти все роутеры загнутся. +Приемлемого решения не просматривается. +Сделать записи непересекающимися в листах - задача непростая. Потребуется переписать алгоритм auto-merge из nft, +но с пониженным расходом памяти. +Загонять записи по одному отдельными вызовами nft, игнорируя ошибки, займет вечность. +Загонять блоком отдельных команд, игнорируя ошибки, - nft такого не умеет. Похоже, при любой ошибке происходит откат всего скрипта. +К тому же при таком подходе будут неточности в итоговом результате. +Swap позволяет немного сгладить проблему, но лишь незначительно. +Скажем, если вдруг list загоняется без ошибок с 300 Mb памяти и с падением на 256 Mb, то swap спасает. +Если памяти становится 200 Mb, то swap уже не спасет. Все равно вызывается OOM killer, заодно убивая и другие процессы, кроме nft, +а это уже совсем плохо. Может быть убито что-то важное. + +Боль N2, но не такая смертельная. + +10 лет вылизывания кода, но при загоне больших листов в set-ы то и дело при вызовах nft list происходят seg faults. +Например, падать может nft -t list ruleset, но nft -t list table inet zapret может не падать. +Вроде это не влияет на функционал, но все равно создается неудобство. + +Боль N3, не смертельная, но тоже не айс. + +Какие-то нерациональные алгоритмы разбора таблиц в nft. +Например, есть 1 большой set на 100000 элементов и 1 маленький на 2 элемента. +Чтобы просто пролистать мелкий set или добавить туда еще что-то nft будет мусолить несколько секунд. +Что он делает за это время ? Тащит из ядра огромный блоб, в котором все в куче, и разбирает его, чтобы выделить искомую мелочь ? +В какой-то мере удается это сгладить, обьединяя несколько команд в единый скрипт. + + +Плюс N1, главный + +iptables хороши, когда ими пользуется кто-то один. Иначе это проходной двор. +Когда есть система управления фаерволом, то приходится как-то к ней прикручиваться, чтобы не нарушить ее работу +и управлять правилами синхронно. Нужно уметь внести и удалить отдельные правила когда это нужно, не трогая все остальное. +Некоторые системы управления фаерволом вообще не предполагают, чтобы кто-то еще лез в iptables, и это очень сильно портит жизнь. +У iptables есть предопределенный набор хуков netfilter с фиксированным приоритетом. +В nftables хуков можно создать неограниченное количество с выбранным приоритетом, управляя ими независимо в отдельных таблицах. +Система управления фаерволом может работать в одной таблице (fw4 в случае openwrt) и не трогать все остальное. +zapret может работать в другой таблице и не трогать систему управления фаерволом. Они друг другу не мешают. +Это снимает множество боли. + +Плюс N2 + +Возможность выбора приоритета хука позволяет легко решить проблему хаотической и принудительной дефрагментацией L3 ipv6, +без танцев с загрузкой модулей ядра со специальными параметрами или перекомпиляцией nftables-nft. + +Плюс N3 + +Наличие множеств (anonymous/named sets) позволяет не писать кучу однообразных правил там, где в iptables их пришлось бы написать. + +Плюс N4 + +Если у вас есть nftables, то там наверняка есть уже все или почти все. +Нет кучи разных модулей ядра и .so плагинов для iptables user-mode процесса. +Отдельные модули ядра есть, но их меньше, чем в iptables, и openwrt их делит на меньшее число пакетов, большинство из которых +и так ставятся по умолчанию. user-mode процесс nft и вовсе неделим. EXE-шник + lib. + +Плюс N5 + +Пишут, что nftables работают быстрее. + + +Выводы + +Честно говоря, лучше бы openwrt оставался на iptables. +Пусть они и старые, c недостатками, но как говорится ложка дегтя портит цистерну меда. +nftables - именно тот случай. Все хорошо, но все плохо из-за досадной особенности. +Без больших листов все почти прекрасно. Но большие ip листы убивают все. Не для домашних это роутеров. +А ipset-ы к nftables не прикрутить. +Делать нечего. Openwrt отошел от iptables. С этим придется как-то жить. +Поэтому пришлось сделать для openwrt поддержку и iptables, и nftables (только с версии openwrt 21.xx, в более старых будут проблемы). +iptables можно задействовать на любой openwrt версии. +Если используется fw3, применяется старый механизм интеграции в fw3. +Если он не используется, то правилами iptables управляем как в традиционных linux системах - то есть с возможностью +запуска и остановки, а скрипт запуска вносит в том числе и правила iptables.