Перейти к содержимому
Spank

ipacc

Рекомендуемые сообщения

Может кому известна утилитка написанная еще под ядро 2.2, для детального учета трафика прошедшего через правила iptables. Ее то я и переделал, для того что бы она работала намано в ядрах 2.4, 2.6 и 64 битной архитектуре. Так же добавил несколько ключиков для команды ipacc. Кому интересно советую посмотреть. В ближайшее время есть мысли писать билинг с ее использованием, для того что бы можно было делать разные общеты на разные подсети и много других вкусностей.

Приемущества над чем то подобным, вообщем -j ULOG:

1. Пакеты не парсяться повторно

2. Если нестандартная длинна заголовка пакета он будет намано общитан.

3. На уровне ядра система работает быстрей.

Банальное использование это сделать детализацию трафика, что бы недовольные юзеры могли получить весь лог и сами разобраться что куда ушло...

Ознакомиться с проектом можно тут: http://litec.ru/wiki/index.php/Ipacc , там же есть и подробная документация как что делать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. Они работают не на уровне ядра(соотв медленнее).

2. Библиотеки снифера не рулят, так как будут щитать трафик задропаный в iptables.

3. Про ULOG я уже писал.

4. Все они повторно разбирают пакет уже разобранный системой. Зачем делать 2 раза одно и тоже, к тому же это может быть критично на слабых роутерах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Spank писал(а) Mon, 10 July 2006 13:31

2. Библиотеки снифера не рулят, так как будут щитать трафик задропаный в iptables.

Это с чего они себя будут так вести?

Цитата:

4. Все они повторно разбирают пакет уже разобранный системой. Зачем делать 2 раза одно и тоже, к тому же это может быть критично на слабых роутерах.

На слабых роутерах критична в первую очередь обработка прерываний для сетевых карт, поэтому при достаточно большом потоке трафика о слабых машинах можно забыть. К тому же в случае логирования сведений о пакете согласно заголовка, сколько же должно быть пакетов, чтоб была видна разница в скорости между решениями ядерным и пользовательского уровня?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Фильтрация пакетов IP идет на сетевом уровне, а как известно например tcpdump работает на канальном уровне. Тоесть если я пишу:

iptables -A FORWARD -d 1.1.1.1 -j ACCEPT то билланг основанный на libpcap это пощитает, а я не хочу. Ну и в таком же духе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Spank писал(а) Tue, 11 July 2006 09:00

Фильтрация пакетов IP идет на сетевом уровне, а как известно например tcpdump работает на канальном уровне. Тоесть если я пишу:

iptables -A FORWARD -d 1.1.1.1 -j ACCEPT то билланг основанный на libpcap это пощитает, а я не хочу. Ну и в таком же духе.

хм... tcpdump -i any dst not 1.1.1.1?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А не изврат?? то что в таблесе например дропается придется и здесь не щитать, тоесть 2 раза одно правило писать в разных приложениях. Лишнее время и путаница получается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

То есть ipacc считает то, что посчиталось бы по ULOG, будь он последним правилом в цепочке?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

для того что бы ipacc считал статистику добавляется правило например:

iptables -A FORWARD -i ppp+ -j ACC --mark 1

И будет вестись подсчет пакетов попавших под это правило.

Я те советую зайти на сайт и почитать, там все написано...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

×