IPTables: как работает расширение condition match?

Аватар пользователя DRVTiny

Я фанатично отношусь к булевым переменным, флажкам и переключателям (сказывается моё тяжелое прошлое увлечённого асм-программиста Улыбка ), поэтому когда я узнал о том, что для IPTables существует расширение condition match, моей первой реакцией было: "так это именно то, о чём я мечтал!". Дело в том, что сейчас правила моего брандмауэра форимруются на основе значений нескольких десятков различных переменных, вынесенных в отдельный конфиг-файл. Причём среди этих переменных процентов 80, если не больше, составляют переменные-флаги. Для того, чтобы изменить поведение IPTables при обработке запросов, мне достаточно "всего лишь" перезапустить инициализационный скрипт, перезаписав таким образом все правила брандмауэра. Но это "всего лишь" меня совершенно не устраивает как минимум потому, что принудительная переинициализация брандмауэра негативно сказывается на всех установленных соединениях, раз через раз провоцирует неадекватное поведение DHCPD (он начинает "терять адреса", после чего некоторые особо нетерпеливые клиенты начинают самовольно присваивать своим ethernet-картам IP, лежащие внутри диапазона 169.254.0.0-169.254.255.255), да и просто слегка раздражает, поскольку скрипт мой растёт и ширится день ото дня, выводит много отладочной информации, а потому отрабатывает далеко не мгновенно.
В общем, по всем признакам мне нужно было именно такое решение, которое предлагают разработчики condition matcher'а: достаточно простого echo val > /proc/net/ipt_condition/файл-переключатель-режима - и политика пакетной фильтрации IPTables меняется динаимчески, т.е. мгновенно, без каких-либо перезапусков и прочих неприятных вещей!
И всё бы замечатеьлно, но я не понимаю только одного крайне сомнительного момента: из описания этого расширения (в переводе) я узнаю следующее:

Цитата:
- файл условий создается автоматически при первом упоминании нового условия;
- файл условий автоматически удаляется после удаления последней ссылки на соответствующее условие.

Я не понимаю, что значит "создаются автоматически" и "удаляются автоматически": а что же происходит в том случае, если в такой файл нужное значение будет записано перед запуском сервиса iptables и, соответственно, до загрузки правил, содержащих -m condition)? Ведь логично же, что все булевы переменные должны быть проинициализированы до того, как вступят в силу использующие их правила.... А эта загадочная формулировка: "файл условий СОЗДАЁТСЯ" совершенно сбивает меня с толку и наводит на подозрения: уж не производится ли при первом старте расширения condition match принудительная инциализация всех файлов-переключателей произвольным значением (например, FALSE)? Если это действительно так, то, по-видимому, инциализация всех переключателей каким-то образом должна производиться сразу после первоначальной установки всех правил IPTables при загрузке, иначе получится, что в промежутке времени между стартом сервиса iptables и началом работы скрипта, считывающего конфигурационный файл брандмауэра и последовательно записывающего нули и единицы в файлы-переключатели, фаерволл будет вести себя совершенно непредсказуемым образом! (ну или по крайней мере сосвем не так, как этого требует политика безопасности).
В связи со всем вышеизложенным у меня возник вопрос к нашим компетентным товарищам, имеющим опыт работы с расширением condition-matcher: так как же всё-таки происходит ннициализация и удаление файлов-переключателей на этапе запуска системы и при рестарте iptables, и что нужно сделать для того, чтобы эти в эти файлы всегда, при любых обстоятель ствах, содержали нужные мне, а не произвольные, значения???

Аватар пользователя DRVTiny

Re: IPTables: как работает расширение condition match?

Хорошо, я, пожалуй, зайду с другого конца: пожалуйста, те, кто хоть раз пользовался "-m condition", сообщите мне об этом хотя бы просто кратким сообщением в стиле "Ну, я пользовался, не понравилось, и чего ?", хорошо? Сделайте мне небольшое одолжение, напишите хоть что-нибудь о condition match, от вас не убудет ведь, правда?

Аватар пользователя DRVTiny

Re: IPTables: как работает расширение condition match?

Ну разве это не здорово (звучит по-моему очень многообещающе)???:

Цитата:
3.2 condition match

This patch by Stephane Ouellette adds a new match that is used to enable or disable a set of rules using condition variables stored in `/proc' files.

Notes:

* The condition variables are stored in the `/proc/net/ipt_condition/' directory.
* A condition variable can only be set to ``0'' (FALSE) or ``1'' (TRUE).
* One or many rules can be affected by the state of a single condition variable.
* A condition proc file is automatically created when a new condition is first referenced.
* A condition proc file is automatically deleted when the last reference to it is removed.

Supported options for the condition match are :

--condition [!] conditionfile

-> match on condition variable.

For example, if you want to prohibit access to your web server while doing maintenance, you can use the following :

# iptables -A FORWARD -p tcp -d 192.168.1.10 --dport http -m condition --condition webdown -j REJECT --reject-with tcp-reset

# echo 1 > /proc/net/ipt_condition/webdown

The following rule will match only if the ``webdown'' condition is set to ``1''.

Аватар пользователя wildsin

IPTables: как работает расширение condition match?

DRVTiny писал(а):
Ну разве это не здорово (звучит по-моему очень многообещающе)???:

я не пользовался, но уже интересно...
если кинешь ссылку на этот патч, постараюсь посмотреть...
прикрутить попробую к стандартному АСП 11 с последним дистрибутивным ядром из обновлений.
которое kernel-2.6.17-1.2142.1asp

Аватар пользователя DRVTiny

Re: IPTables: как работает расширение condition match?

Цитата:
если кинешь ссылку на этот патч, постараюсь посмотреть...

Дело в том, что этот патч отдельно от комплекта patch-o-matic не существует. А сейчас его даже из patch-o-matic исключили. Но и в тех POM'ах, где он был, почему-то возникали проблемы с установкой именно этого расширения, одного из самых революционных за всю историю существования UNIX'овых пакетных фильтров!
Начать хотя бы с того, что скрипт-инсталлятор POM'а расширение condition не видел в упор и не предлагал его установить ни в обычном, ни в extra-режиме, так что приходилось файлы в дерево исходников копировать вручную...

RSS-материал