|
|
|
Начало
Сетевая часть
Каким софтом можно считать траффик под FreeBSD?
Простые средства подсчета траффика
Под "простыми" мы понимаем "не дающими детализации". То есть можно
выяснить какой объем входящего и исходящего траффика был получен/отправлен
определенным IP адресом, за определенный срок. Но нельзя детализировать траффик.
Такой подсчет имеет свои плюсы - меньше требуется системных ресурсов и меньше
места занимает хранилище данных.
- Счетчики ipfw count
Скриптом, или руками генерируют список примерно вот таких правил:
${fwcmd} add 100 count ip from any to ${local_ip_1} in
${fwcmd} add 100 count ip from ${local_ip_1} to any out
Условия in и out важны, поскольку без них траффик будет считаться
2 раза. Затем пишутся скрипты, которые это все обсчитывают, либо берутся готовые.
Из готовых скриптов обработки можно посоветовать скрипты из пакета
Utcount.
См. ipfw(8)
- Dummynet
Как ни странно dummynet(4) можно приспособить для подсчета траффика, а не
только для шейпинга. Для этого нужно создать два пайпа - один для исходящего
траффика, и один для входящего. Пайпы следует сконфигурить таким образом, что
бы в первом для каждого уникального src создавалась отдельная очередь, а во
втором для каждого уникального dst:
${fwcmd} pipe 1 config mask src-ip 0xffffffff buckets 1024
${fwcmd} pipe 2 config mask dst-ip 0xffffffff buckets 1024
${fwcmd} add 650 pipe 1 ip from ${realnet} to any in
${fwcmd} add 651 pipe 2 ip from any to ${realnet} out
Теперь следует сказать, что бы очереди никогда не удалялись из памяти из-за
отсутствия траффика, это делается изменением sysctl net.inet.ip.dummynet.expire=0.
Также в большинстве случаев имеет смысл sysctl net.inet.ip.fw.one_pass=0.
Показания счетчиков снимаются командами ${fwcmd} pipe 1 show, ${fwcmd} pipe 2 show.
См. ipfw(8), dummynet(4)
Реализации ip accounting и их аналоги
ip accounting - способ подсчета траффика реализованный в Cisco и множестве других
роутеров. Суть заключается в том, что для каждого потока пакетов с уникальной
парой IP адресов создается отдельный счетчик. Во многих реализациях в качестве
критерия уникальности также используются TCP/UDP порты и IP протокол. Накапливаемая
таким образом статистика хранится в памяти роутера и периодически снимается и
обнуляется по запросу извне. Такой метод весьма прост, но имеет свои недостатки:
сильно нагруженному роутеру нужно много памяти, процесс снятия/обнуления статистики
сильно подгружает роутер, перезагрузка роутера приводит к потере данных накопленных
с момента последнего снятия.
- trafd aka bpft ,
автор Vladimir Vorobyev bob@turbo.nsk.su
trafd использует bpf для считания траффика, умеет работать в promiscuous mode,
поэтому подходит для подсчета траффика не проходящего непосредственно через роутер.
Статистика выдается по настраиваемому шаблону.
Пpеимущества:
- дампы таблицы для восстановления после пеpезагpузки
- гибкий фильтp пакетов
- гибкий вывод лога, логи за pазные пеpиоды
- возможность локального или удаленного пpосмотpа текущей таблицы
Hедостатки:
- Интерфейс bpf не гарантирует доставки всех пакетов из ядра в userland
процесс.
Поэтому на быстром канале могут быть потери пакетов.
- Траффик считается в userland, что приводит к серьезной загрузке роутера
- Моё личное мнение: код программы оставляет желать лучшего. Достаточно
посмотреть на патчи в порте. Кстати, собирать не из порта не рекомендуется.
См. bpf(4), tcpdump(1), /usr/porta/net-mgmt/trafd,
BPFT v2,
trafd v3
(ftp),
BPFT v4
- ipacctd ,
автор Roman V. Palagin romanp@wuppy.net.ru
ipacctd открывает диверт сокет и реализует ip accounting входящего в этот
сокет траффика. Это дает возможность включать ipacctd не на каком-то конкретно
интерфейсе, а "вливать" в него траффик из нужного места в конфигурации файрволла.
Например:
# Оставить себе вход на случай остановки демона ipacctd
ipfw add allow tcp from any to ${host} 22
ipfw add allow tcp ${host} 22 to any
ipfw add divert ${ipacctd_port} any from any to any
Важно помнить, что когда демон не работает, то не работает ничего. Поэтому в
ситуации, когда наличие интернета важнее чем потеря подсчета траффика следует
использовать правило tee, а не divert. ipacctd умеет отдавать логи в формате
src-ip dst-ip bytes packets [time] либо
src-ip src-port dst-ip dst-port proto bytes packets [time]
Пpеимущества:
- Траффик отправляется в демон из любого места конфигурации ipfw
Hедостатки:
- Траффик считается в userland, что приводит к серьезной загрузке роутера
См. ipfw(1), divert(4), /usr/ports/net-mgmt/ipacctd
- ng_ipacct ,
автор Roman V. Palagin romanp@wuppy.net.ru
Представляет собой netgraph node с двумя hooks - в один получает входящий траффик,
в другой исходящий. Таким образом перехват и подсчет траффика происходит целиком в
ядре. Модульная идеология netgraph позволяет заливать в ng_ipacct траффик из
различных источников, хотя классический вариант это просто прицепить ng_ipacct к
ng_ether и считать таким образом траффик на ethernet интерфейсе. Снятие/обнуление
траффика осуществляется с помощью утилиты ipacctctl, которая осуществляет импорт
накопленной статистики в userland.
Пpеимущества:
- наименее ресурсоемкий ip accounting, тк реализован целиком в ядре
- netgraph позволяет использовать ng_ipacct в самых разных конфигурациях
См. /usr/ports/net-mgmt/ng_ipacct, netgraph(4), ipacctctl(8), ngctl(8)
- ipcad ,
автор Lev Walkin vlm@spelio.net.ru
Является userland приложением, перехватывающим траффик c помощью различных механизмов
(см. ниже).
Преимущества:
- Так как написан портабельно и использует известные интерфейсы, то
работает практически на любой unix-like OC. Точно работает на линуксах и OpenBSD.
Должен работать на NetBSD, но пока не проверялось
- Умеет получать траффик с помощью различных механизмов:
pcap, bpf, divert, tee (как divert, только обратно ничего не пишется) a также
ulog и libipq под Linux.
- В отличие от классического ip accounting, при перезагрузке информация не
теряется
- Вывод точь в точь соответствует выводу Cisco. Снятие статистика делается
с помощью команд идентичных Cisco через rsh. Это позволяет использовать готовые
заточенные под Cisco скрипты и биллинги.
- Умеет аггрегировать траффик
- Понимает фильтры подобные tcpdump, это позволяет не тратить ресурсы CPU на
подсчет не интересующего траффика
- Умеет генерировать статистику Netflow v1, v5. (Описание NetFlow см. ниже)
Недостатки:
- Работает в userland и как следствие потребляет много CPU
См. ipcad.conf(5), pcap(3), tcpdump(1), /usr/ports/net-mgmt/ipcad
Реализации Cisco(c) Netflow
Механизм сбора статистики Netflow заключается в том, что роутер идетифицирует
уникальные потоки траффика текущие через него, аналогично ip accounting. Однако
по окончании потока накопленная статистика сразу отправляется в UDP датаграмме
в сторону т.н. коллектора. Таким образом в памяти роутера хранятся только те
потоки, которые активны в течение заданного времени. Кроме того, Netflow дает
больше информации нежели ip accounting - входящий и исходящий интерфейсы, маршрутные
маски, время начала и конца жизни потока и др. См.
Cisco Netflow pages
- softflowd , автор Damien Miller
Реализует Netflow v1, v5. userland демон слушающий интерфейс с помощью pcap.
Также может читать дампы сгенерированные с помощью tcpdump. Работает под Linux
и OpenBSD. Скорее всего будет работать и под FreeBSD.
См. softflowd
- pfflowd , автор Damien Miller
Разработка авторов softflowd реализующая Netflow на базе stateful алгоритмов
файрволла из OpenBSD - pf. Так как pf портирован в FreeBSD 5.3 и старше,
то можно ожидать, что pfflowd заработает на FreeBSD.
См. pfflowd
- fprobe , автор Slava Astashonok
userland демон слушающий интерфейс с помощью pcap. Интересен тем, что реализует
Netflow v1, v5 и v7.
См. /usr/ports/net-mgmt/fprobe
- ntop , автор Luca Deri
Одна из утилит в пакете инструментов ntop реализует Netflow. nProbe реализует
Netflow v5 и v9 и даже новый формат nFlow, обладающий множеством преимуществ перед
классическими версиями. nProbe работает через pcap, однако автор утверждает,
что используя некоторые современные методы экспорта данных из ядра можно
избавиться от потерь пакетов и загрузки. Он доказывает это в своих статьях и
приводит патчи. К сожалению, пока эти патчи на FreeBSD не портированы.
См. ntop, /usr/ports/net/ntop
- ng_netflow , автор Gleb Smirnoff
Это netgraph node к которой присоединяется несколько хуков, с каждого из которых
ожидается входящий траффик. Найденные потоки экспортируются в специальный хук,
на котором обычно висит ng_ksocket. ng_netflow реализует Netflow версии 5.
Перехват траффика и отсылка экспортов происходят в ядре, что дает большую
производительность по сравнению с userland решениями.
См. /usr/ports/net/ng_netflow
Скрипты, коллекторы, интерфейсы, биллинги
Обычно задача не ограничивается подсчетом. Данные нужно обрабатывать, хранить,
анализировать и т.п. ip accounting нужно чем-то снимать, netflow нужно чем-то
слушать. И в конце-концов, нужно получать биллинговую информацию по траффику.
- flow-tools , автор Mark Fullmer и др.
Это полный ящик инструментов необходимый для работы с Netflow. Все что
может понадобиться и даже больше. На домашней странице можно найти еще
много полезных вещей и ссылок.
См. flow-tools
/usr/ports/net-mgmt/flow-tools
- Cflowd
Считался готовым инструментом для реализации нижнего слоя биллинговой структуры.
С недавнего времени на сайте написано, что продукт больше не поддерживается и
рекомендуется переходить на flow-tools.
Cм. Cflowd
/usr/ports/net-mgmt/cflowd
- ehnt , авторы Nik Weidenbacher, Dmitry Morozovsky
Представляет собой два инструмента: ehntserv - udp2tcp proxy, позволяющий
слушать netflow поток несколькими клиентами одновременно, и ehnt - утилита
для просмотра того, что течет с роутера.
См. /usr/ports/net-mgmt/ehnt
- NeTAMS
Фактически является готовым биллинговым решением с открытыми исходниками. Вот
цитата из документации:
NeTAMS собирает в себя потоки информации о траффике, IP и не только, например,
путем перехвата проходящих пакетов через сетевой интерфейс (libpcap), divert
socket (ipfw divert), поток NetFlow или любой другой модуль. После обработки и
суммирования данных информация о статистике попадает в БД, откуда любая статистика
может быть запрошена посредством прямого запроса или через веб-интерфейс. Попутно
может осуществляться контроль доступа, квот и прав пользования. Управление
программой осуществляется посредством установления соединения на некий TCP порт
сервера клиентом telnet и ввода соответствующих команд. Имеется также
веб-интерфейс отображения статистики.
См. NeTAMS,
/usr/ports/net-mgmt/netams
- ipa , автор Andrey Simonenko
Набор инструметов для работы с файрволльными счетчиками.
Понимает ipfw, pf, ipf. Хранит данные в базе своего собственного формата.
Если не интересует детaлизация, то вероятно ipa будет самым удобным решением.
См. ipa,
/usr/ports/sysutils/ipa
- UTM , компания Netup.
Версии 3.0 и 4.0 представляют собой набор скриптов на perl, организующий хранение
и биллинг информации о траффике. Имеет расширенный веб-интерфейс для
администраторов и клиентов. Считается полностью готовым решением для провайдинга
домашних сетей, тк отвечает практически всем требованиям специфики этого рынка.
Однако является платным продуктом - все исполняемые файлы скомпилены с помощью
perl2exe. Написание генератора ключа не составляет труда, так же не составляет
труда декомпиляция. Но здесь этому учить не будут.
Моё субъективное мнение о продукте очень низкое - БД используется не рационально,
много глюков, код оставляет желать лучшего. В веб-интерфейсе
куча дыр,
которые разработчики даже не фиксят, а просто рекомендуют
закрыть admin с помощью .htaccess.
Однако, недавно вышла версия 5.0, которая написана с нуля.
Изначальная статья была написана Степаном Кольцовым в 2001 году, и была значительно
переписана и дополнена Глебом Смирновым в 2004 году.
Создано: Gleb Smirnoff Последнее обновление: Gleb Smirnoff
|
