Freebsd 7.2 виснет

[root]

А еще раз не напомните, почему не используете?

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

Насколько я знаю именно логи доступа по srcIP:port -> destIP:port интересуют органы и именно такие файлы надо хранить до 3х лет.
Или я не прав?

прав что srcIP:port -> destIP:port, а вот хранить надо 6 месяцев

Как вы тогда обходитесь в жтом случае?

а кто сказал что мы обходиvся, ipacctd так и собирает стату, пример:
Колонки: src-IP, src-port, dst-IP, dst-port, protocol, bytes, unixtime

Код: Выделить всё

 
192.168.15.18  48882   217.73.200.169  80      tcp     7       854     1265575909
217.73.200.169 80      192.168.15.18   48882   tcp     4       602     1265575909
192.168.6.242  4973    83.102.171.180  23400   tcp     3       144     1265575904
83.102.171.180 23400   192.168.6.242   4973    tcp     3       120     1265575904
192.168.26.18  4504    77.127.60.121   25396   tcp     4       438     1265575905
77.127.60.121  25396   192.168.26.18   4504    tcp     2       622     1265575906
192.168.15.21  65500   195.58.1.145    53      udp     1       65      1265575910
195.58.1.145   53      192.168.15.21   65500   udp     1       215     1265575910

[Андрей]

Спасибо за ответ. Радует, что это хранится до 6 месяцев.
А все таки, что должно храниться 3х года? Так как в ФЗ о связи указаны разные цифры на разные виды логирования.

потому что при большом потоке трафика, он начинает теряться

а ipacctd это не netflow?
Опят же вопрос - что используется в качестве аккумулятора статистики? Или ng_ipacctd сам себе коллектор + сниффер и вдобавок может кидать статистику на определенный порт?

Кстати, проблему с ipcad я решил. просто ушел с него на flow_fanout, который поставляется в комплекте с flow-tools.
Т.к. эта программа создана для "разветвления" трафика, то решение, в принципе, пришло само собой.
"Ветвление" происходит так:
Задача: скидывать статистику по трафику на билинг для обсчета + аккумулирование статистики.
Решение: mpd5 кидает данные на порт flow_fanout. Последний, в свою очередь, кидает статистику на порт flow_capture и на порт биллинга.

Если интересуют конфиги - могу привести их.

Подводя тему к логическому концу, раз уж упоминалось об ng_ipacctd и об использовании им всего пары правил, то логичный вопрос какие именно правила?
Я так понимаю, что это ipdivert? и вы предлагаете решать проблему по средствам pf (для защиты, т.к. я ег понимаю), а Ipfw только для нат?
Если так,то решение ясно.

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

[root]

А все таки, что должно храниться 3х года?

лично я не знаю
если тебя это так интересует, то ищи в законе о связи, ведь именно на него ссылается МВД когда присылает запрос

а ipacctd это не netflow?

нет, ipacctd это:

Port: ipacctd-1.47
Path: /usr/ports/net-mgmt/ipacctd
Info: IP accounting using divert socket
Maint: skv@FreeBSD.org

раз уж упоминалось об ng_ipacctd

я упоминал ipacctd, но он и ng_ipacct не совсем одно и тоже

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

когда ты уже научишся пользоваться поиском в блоге и гугле ? Есть сложные вопросы, на которые сложно найти ответ, а есть просты, ответ на который показывает google на первой же странице результатов поиска, в том числе и ссылку на наш блог и статью в нем:
Сбор статистики по трафику на FreeBSD при помощи ng_ipacct

Я так понимаю, что это ipdivert?

да, это правила с divert

и вы предлагаете решать проблему по средствам pf (для защиты, т.к. я ег понимаю), а Ipfw только для нат?

а) я ничего не предлагаю, я говорю, что использование двух типов фаирволов нормальная практика, когда этого требует решение тех или иных задач
б) ipfw для nat`а я не предлагал, причем тут nat вообще ? речь идет о сборе логов по трафику, которые должны собираться до nat`а, чтобы сохранился оригинальный источник

смелюсь предположить,что сам демон не справляется с большим объемом информации и как следствие это приводит к сбоям.

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

[Андрей]

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

Трафика на ng сессиях всегда по-разному, ну сам посуди. На 175 сессиях ничего, а на 150 сессиях дохнет.

Ну да ладно. поживем увидим, свалится ли на flow-fanout или нет.

Спасибо за ответы.