Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1 2 След.
RSS
iptables-restore - странности в поведении
 
Господа, не сталкивался ли кто с некой странностью в поведении утилиты iptables-restore? Странность эта заключается в том, что при выполнении операции COMMIT иногда (непредсказуемо) выдается сообщение об ошибке
Line XXXX failed
XXXX указывает на строку с командой COMMIT. При повторном запуске iptables-restore с тем же файлом правил в качестве параметра ошибка обычно не повторяется.

iptables v1.2.11 собрана из исходников, но подобные штуки наблюдались и с другими версиями, включая RPM-ные. Ядро 2.6.9, но проблема наблюдалась и при более ранних версиях. таблица правил достаточно велика (более 12К).
 
Никогда еще не видел чтобы просто так iptable-restore падала, обычно если валится, то это свидетельсвует об ошибке в правилах в файле с рулесами. У меня iptables-1.2.11-r3 на 2.6.9-r9 и проблемы были только когда ручками правил файл с правилами и допускал ошибки. Попробуй /etc/init.d/iptables save(или же iptables-save > /etc/sysconfig/iptables - я так понял что речь о redhat-based ибо RPM) чтобы переписать старый конфиг рулезов и посмотри что скажет iptables-restore.
 
2 r00t
Вы меня не поняли - проблема не в правилах, а именно в iptables-restore. При использовании утилиты с одним и тем же файлом правил она иной раз выдает ошибку, указывая на строку COMMIT, а иной раз не выдает. Т. е., если мы столкнулись с такой ошибкой и запустили программу еще раз с тем же файлом правил, в следующий раз ошибки скорей всего не будет.

Отмечу так же еще раз, что эта проблема наблюдалась и наблюдается с разными версиями ядра и iptables (как RPM-нами, так и собранными вручную).

Добавлю, что при выдаче сообщения об ошибке никаких проблем не возникает, просто сохраняется прежняя (ранее загруженная) таблица правил.
 
Не исключено, что это связанно с недавно обнаруженной ошибкой инициализации (CAN-2004-0986)
 
Цитата
m00nlight пишет:
Не исключено, что это связанно с недавно обнаруженной ошибкой инициализации (CAN-2004-0986)
Увы, ничего похожего.  
Буду копать дальше.
 
Никогда не сталкивался.
Если сам допускал ошибки в файле - оно конечно.

Рекомендую создать скриптик на sh, который будет пытатся загрузить правила либо до успеха либо до исчерпания счётчика попыток.

А то очень неприятно бывает остаться с побитыми правилами при удалённом админстве :-)
 
Цитата
less пишет:
А то очень неприятно бывает остаться с побитыми правилами при удалённом админстве :-)
Правила (старые) при этом сохраняются. В общем-то и проблемы особой нет. Напрягает лишь то, что при больших таблицах (как я писал, у меня более 12 тысяч правил) загрузка и проверка занимает достаточно много времени и когда в конце тебе говорят об ошибке в строке COMMIT, хочется грязно выругаться.

Просмотр исходников (беглый) ни на какие мысли меня не навел, увы. Потому и пришлось обратиться к участникам форума.
 
Убедись, что модули правильно подгружаются. Что показывает lsmod
1. До выполнения iptables-restore,
2. После некорректой отработки iptables-restore,
3. После корректой отработки iptables-restore?
 
Цитата
moonspell пишет:
Убедись, что модули правильно подгружаются. Что показывает lsmod
Все требуемые модули уже загружены.

Проблема состоит именно в том, что если несколько раз подряд запускать iptables-restore с одним и тем же файлом правил, то иногда программа выдает сообщение об ошибке, указывающее на строку COMMIT.
 
Рекомендую воспользоватся программами strace и ltrace чтобы выяснить где вознимает ошибка, в самом iptables ли в ядре. Врят ли они тестировались на таком больших наборах правил.

Т.к. пути счётчика команд неисповедимы ещё раз рекомендую просто сделать work-around для этого бага, а так же написать разработчикам о найденной вами проблеме.
 
less, спасибо, - это очень ценные мысли. Я пожалуй так и сделаю. Если накопаю что интересное, напишу здесь.
 
Обещал писать о результатах изысканий, вот первая странность которую удалось обнаружить при трассировке.

Для каждой пользовательской цепочки (точнее для каждого вызова таких цепочек) в файле правил iptables-rectore пытается найти библиотеку
/lib/iptables/libipt_<имя цепочки>.

Понятно, что такой библиотеки не находится. Программа умеет это обрабатывать и не выдает никаких сообщений об ошибках. Однако настораживает сам факт попытки поиска библиотеки с именем пользовательской цепочки. К тому же, сами понимаете, при большом количестве правил с вызовами пользователских цепочек будет изрядно тормозить загрузку правил из-за ненужных фаловых операций.
 
Цитата
nmalykh пишет:

Для каждой пользовательской цепочки (точнее для каждого вызова таких цепочек) в файле правил iptables-rectore пытается найти библиотеку
/lib/iptables/libipt_<имя цепочки>.
Гы гы гы - видимо оно так обрабатывает встроенные цели -j  :-)
Ибо не знает какие встроенные, а какие user-defined
 
Цитата
less пишет:
 
Цитата
nmalykh пишет:

Для каждой пользовательской цепочки (точнее для каждого вызова таких цепочек) в файле правил iptables-rectore пытается найти библиотеку
/lib/iptables/libipt_<имя цепочки>.
Гы гы гы - видимо оно так обрабатывает встроенные цели -j  :-)
Ибо не знает какие встроенные, а какие user-defined
Весьма похоже на истину и мне это активно не понравилось. Буду разбираться.
 
Трассировка процесса загрузки таблиц показала, что ошибка возникает при заключительном вызове setsockopts(). Ниже приведен фрагмент вывода при трассировке с ошибкой.

Код
setsockopt(7, SOL_IP, 0x40 /* IP_??? */, [1953261926], 1870060) = -1 EAGAIN (Resource temporarily unavailable)


Причем результат как и для случая без трассировки примерно 50/50.

Обнаружилась еще одна интересная вещь, поскольку из-за проблем с питанием пришлось перезагружать шлюз. Большую таблицу загрузить сразу мне просто не удалось (пробовал раз 5 и все время та же ошибка). При этом если загружать таблицу в несколько приемов с нарастанием числа правил, все проходит нормально (с учетом сказанного ранее).
 
> (Resource temporarily unavailable)
может срабатывает какое-то ограничение?
 
Цитата
r00t пишет:
> (Resource temporarily unavailable)
может срабатывает какое-то ограничение?
Вот только непонятно какое?  
Памяти на машине достаточно много и свопинг обычно не используется. Стало быть ограничения не глобальные (впрочем и трактовка ошибки говорит о временной проблеме).
 
Николай, к сожалению помочь в тейблсах пока ничем не могу, но результат изысканий интересен на будущее. Ибо прогресс идёт и было бы интересно услышать окончание сей бадяги. Насколько я понимаю (кстати, правильно?) COMMIT достаточно экспериментальная штука и досонально не испытывалась. И берётся из patch-o-matic. Посему возникает закономерный вопрос. Ты не пробовал ставить в известность разработчиков? Вохможно, есть проблемы в файлах блокировки. Но не уверен...
 
COMMIT с данном контексте это команда активизации правил, загруженных из файла утилитой iptables-restore. насколько мне удалось разобраться процесс идет следующим образом.
1. Программа считывает из файла правила, проверяет синтаксис и пишет в некий буфер бинарный вариант правила.
2. После прочтения всех правил этот буфер активизируется (сбрасываются старые правила и поднимаются новые) и в процессе этой активизации используется функций setsockopt, которая и возвращает ошибку, говорящую о временной недоступности ресурса.

К сожалению, я уже много лет как утратил всякую квалификацию в программировании, поэтому процесс исследования идет достаточно медленно. Дополнительное осложнение вызывает то, что все это происходит на работающем шлюзе, который обеспечивает безопасность моей сети. К тому же процесс перезапуска таблицы такого размера занимает минуты, поэтому особенно не поэкспериментируешь :-(
 
Кстати. Я к тебе приближаюсь по объёму файлов фарволла. На данный момент - 91 КБ. Но ipchains. ;)
Страницы: 1 2 След.
Читают тему