 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Serge 2:5020/400 24 Dec 2003 16:06:05 To : Vladimir V. Ivanov Subject : Re: так ли необходим сетевой экран? точнее где он необходим и какой? -------------------------------------------------------------------------------- .ua> From: Serge <genie@nsk.ru> Vladimir V. Ivanov wrote: >>Соответственно очень интересует ответ на вопрос вот именно в таком >>понимании... > Э... на какой вопрос? Hа сабжевый? Или об "устойчивости процесса > фильтрации в момент перестройки внутренней таблицы правил"? Hууу.. с тем, что в поле "Тема" вроде более-менее разобрались (в общем случае, частности-то как раз только намечаются...) Поэтому вопрос пока об "...устойчивости процесса..." > Кстати, проврил, что в случае нескольких транзакций (то есть нескольких > таблиц) на входе iptables-restore (1.2.9) выполняет и коммитит все > транзакции до встречи первой ошибки - при этом транзакция с ошибкой не > коммитится, а последующие транзакции не рассматриваются. > Для редких случаев, в которых правила в _разных_таблицах_ > логически взаимосвязаны (то есть вышеописанное поведение не есть > желательным) можно делать скриптом с примерно следующей идеей: Да, такие случаи бывают. Когда одновременно с разрешением на доступ к определенному интерфейсу необходимо включить еще и маскарад. Hо. Логически в iptables-restore _всё_равно_ вызываются несколько последовательных изменений таблицы. > check_wait_and_create_lock_file... > iptables-save > iptables.$$.undo || { remove_lock_file; exit 333; } > > if generate_new_config | iptables-restore; then > rm -f iptables.$$.undo > remove_lock_file... > exit 0 > else > echo "Error detected. Rolling back... " >&2 > iptables-restore < iptables.$$.undo || \ > echo "Critical error, should never happen!" >&2; > rm -f iptables.$$.undo > remove_lock_file... > exit 666 > fi Тогда, учитывая логику работы фильтра, генерировать лучше сразу правила для добавления и для удаления одновременно. Если добавление не получилось по каким-то причинам, вызывать удаление без контроля ошибок. (хотя сам понимаю, что это как раз будет ой как неправильно..?) -- wbr, Serge --- ifmail v.2.15dev5.1 * Origin: Magistral Telecom JV. (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор Архивное /ru.linux/11846c87e2bb8.html, оценка из 5, голосов 10
|
|
|