Добавление правил iptables без libiptc

ммм... а чем не устраивает использовать libiptc напрямую :-?

// wbr

GPL :)

> GPL :)

hm. а не пох :-?

// wbr

не, не пох. лицензионная чистота у нас блюдется. даже наш senior manager знает мол де есть такой GPL, который чего-то там запрещает. да и самому сие безобразие причиняет мучительные страдания :)

вопрос именно в том, как нменее затратно не нарушать GPL

спасибо вам за добротный материал для споров с быдлофсфщиками

это не мне спасибо, а Расти Расселу :)

> не, не пох. лицензионная чистота у нас блюдется. даже наш senior manager знает мол де есть такой GPL, который чего-то там запрещает. да и самому сие безобразие причиняет мучительные страдания :)

hm. ну хозяин барин.

> вопрос именно в том, как нменее затратно не нарушать GPL

посмотреть на принципы построения и нарисовать свою чистую обвязку. уверен, при прямых руках с вероятностью 3/4 получится даже лучше.

// wbr

Может имеет смысл написать свой модуль к iptables, и управлять этим модулем через proc? Ну то есть если правила простые, однотипные, допустим список src-ip адресов, то и сделать модуль которому этот список можно заливать через файл в /proc

Понятно, что код этого модуля выпустить под GPL, а может уже даже есть что похожее в сторонних патчах.

Так, ИМХО, лучше первый вариант. Здесь можно достичь максимальной производительности, то есть процесс заранее подготавливает "шаблоны" правил, загружет все необходимые модули iptables и потом только дергает нужные для добавления правила вызвов libiptc. Сам по себе протокол взаимодействия iptables с ядром простой, но передаются бинарные данные, поэтому вариант 3 не удобен с точки зрения дальнейшего развития. Вариант 4 дает вам 0.005 секунд при низкой нагрузке, а когда система будет сильно нагружена то время может заметно возрасти.

Подводные камни... Я ковырял относительно старый iptables 1.2.3--1.2.9, там было так, iptables подсоединяется к netlink-сокету, получает всю заданную таблицу (nat, filter, mangle) в двоичном виде, изменяет правила и возвращает эти данные ядру. При этом если в это время другая копия iptables обратилась к netlink-сокету, то изменения, вносимые первой копией приняты не будут. То есть при одновремом запуске двух команд iptables, например, "iptables -A INPUT ..." и "iptables -L -n" первая команда может не добавит правило.

Еще библиотека libiptc в основном тестируется с помощью iptables, то есть в режиме добавления одного правила. Поэтому если при добавлении правила возникает ошибка, то процесс, работающий с libiptc лучше перезапускать. То есть получается такая схема, что некоторый процесс принимает через IPC запросы на изменение iptables, и взаимодействует через pipe с дочерним процессом, который, непосрественно работает с libiptc и в случае ошибки завершает работу, сегфолтится и т.д.

Ну ещё сорока на хвосте пренесла, что в libiptc не очень удачные алгоритмы работы, поэтому когда правил много 9-10 тыс., то достаточно много времени уходит на чтение всех правил заданной цепочк. Причем именно не на передачу данных (таблицы) из ядра в user-space, а именно на внутренние алгоритмы libiptc, ищущие превое правило цепочки, последующее правило цепочки.

спасибо, очень основательный ответ еще я видел результаты тестов: http://people.netfilter.org/kadlec/nftest.pdf, где напсиано, что при > 512 правилах iptables производительность резко проседает, правда там правила в filter, а у меня nat, но, думаю, та же фигня

о! посмотрел на ipset, вроде то, что надо! надо подумать как все это теперь обвязать

ОМГ, так ты сетки добавлять-удалять собрался??? ipset однозначно! ктож делает тыщи правил в фаерволе!