Каким софтом можно считать трафик под FreeBSD?

  • 13.11.2020
  • 4 212
  • 0
  • 28.03.2021
  • 1
  • 1
  • 0
Каким софтом можно считать трафик под FreeBSD?

Вступление

В данной статье рассмотрены многие популярные способы подсчета трафика на ОС FreeBSD. Изначальная статья была написана Степаном Кольцовым в 2001 году, и была значительно переписана и дополнена Глебом Смирновым в 2004 году.

Часть информации в этой статье уже сильно устарела, поэтому не забывайте проверять актуальность программ перед использованием!

Простые средства подсчета трафика

Под "простыми" мы понимаем "не дающими детализации". То есть можно выяснить какой объем входящего и исходящего трафика был получен/отправлен определенным 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

trafd использует bpf для считания трафика, умеет работать в promiscuous mode, поэтому подходит для подсчета трафика не проходящего непосредственно через роутер. Статистика выдается по настраиваемому шаблону.

  • Дампы таблицы для восстановления после пеpезагpузки
  • Гибкий фильтp пакетов
  • Гибкий вывод лога, логи за pазные пеpиоды
  • Возможность локального или удаленного пpосмотpа текущей таблицы

  • Интерфейс bpf не гарантирует доставки всех пакетов из ядра в userland процесс. Поэтому на быстром канале могут быть потери пакетов.
  • трафик считается в userland, что приводит к серьезной загрузке роутера
  • Моё личное мнение: код программы оставляет желать лучшего. Достаточно посмотреть на патчи в порте. Кстати, собирать не из порта не рекомендуется.

См. bpf(4), tcpdump(1), /usr/porta/net-mgmt/trafd, BPFT v2, trafd v3 (ftp), BPFT v4

ipacctd

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]

  • трафик отправляется в демон из любого места конфигурации ipfw

  • трафик считается в userland, что приводит к серьезной загрузке роутера

См. ipfw(1), divert(4), /usr/ports/net-mgmt/ipacctd

ng_ipacct

Представляет собой netgraph node с двумя hooks - в один получает входящий трафик, в другой исходящий. Таким образом перехват и подсчет трафика происходит целиком в ядре. Модульная идеология netgraph позволяет заливать в ng_ipacct трафик из различных источников, хотя классический вариант это просто прицепить ng_ipacct к ng_ether и считать таким образом трафик на ethernet интерфейсе. Снятие/обнуление трафика осуществляется с помощью утилиты ipacctctl, которая осуществляет импорт накопленной статистики в userland.

  • Наименее ресурсоемкий ip accounting, тк реализован целиком в ядре
  • Netgraph позволяет использовать ng_ipacct в самых разных конфигурациях

  • Не указано

См. /usr/ports/net-mgmt/ng_ipacct, netgraph(4), ipacctctl(8), ngctl(8)

ipcad

Является 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

Реализует Netflow v1, v5. userland демон слушающий интерфейс с помощью pcap. Также может читать дампы сгенерированные с помощью tcpdump. Работает под Linux и OpenBSD. Скорее всего будет работать и под FreeBSD.

pfflowd

Разработка авторов softflowd реализующая Netflow на базе stateful алгоритмов файрволла из OpenBSD - pf. Так как pf портирован в FreeBSD 5.3 и старше, то можно ожидать, что pfflowd заработает на FreeBSD.

fprobe

userland демон слушающий интерфейс с помощью pcap. Интересен тем, что реализует Netflow v1, v5 и v7.
См. /usr/ports/net-mgmt/fprobe

ntop

Одна из утилит в пакете инструментов ntop реализует Netflow. nProbe реализует Netflow v5 и v9 и даже новый формат nFlow, обладающий множеством преимуществ перед классическими версиями. nProbe работает через pcap, однако автор утверждает, что используя некоторые современные методы экспорта данных из ядра можно избавиться от потерь пакетов и загрузки. Он доказывает это в своих статьях и приводит патчи. К сожалению, пока эти патчи на FreeBSD не портированы.
См. ntop, /usr/ports/net/ntop

ng_netflow

Это netgraph node к которой присоединяется несколько хуков, с каждого из которых ожидается входящий трафик. Найденные потоки экспортируются в специальный хук, на котором обычно висит ng_ksocket. ng_netflow реализует Netflow версии 5. Перехват трафика и отсылка экспортов происходят в ядре, что дает большую производительность по сравнению с userland решениями.
См. /usr/ports/net/ng_netflow

Скрипты, коллекторы, интерфейсы, биллинги

Обычно задача не ограничивается подсчетом. Данные нужно обрабатывать, хранить, анализировать и т.п. ip accounting нужно чем-то снимать, netflow нужно чем-то слушать. И в конце-концов, нужно получать биллинговую информацию по трафику.

flow-tools

Это полный ящик инструментов необходимый для работы с Netflow. Все что может понадобиться и даже больше. На домашней странице можно найти еще много полезных вещей и ссылок.
См. /usr/ports/net-mgmt/flow-tools

Cflowd

Считался готовым инструментом для реализации нижнего слоя биллинговой структуры. С недавнего времени на сайте написано, что продукт больше не поддерживается и рекомендуется переходить на flow-tools.
Cм. Cflowd /usr/ports/net-mgmt/cflowd

ehnt

Представляет собой два инструмента: 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

Набор инструметов для работы с файрволльными счетчиками. Понимает ipfw, pf, ipf. Хранит данные в базе своего собственного формата. Если не интересует детaлизация, то вероятно ipa будет самым удобным решением.
См. ipa, /usr/ports/sysutils/ipa

UTM

Версии 3.0 и 4.0 представляют собой набор скриптов на perl, организующий хранение и биллинг информации о трафике. Имеет расширенный веб-интерфейс для администраторов и клиентов. Считается полностью готовым решением для провайдинга домашних сетей, тк отвечает практически всем требованиям специфики этого рынка. Однако является платным продуктом - все исполняемые файлы скомпилены с помощью perl2exe. Написание генератора ключа не составляет труда, так же не составляет труда декомпиляция. Но здесь этому учить не будут.
Моё субъективное мнение о продукте очень низкое - БД используется не рационально, много глюков, код оставляет желать лучшего. В веб-интерфейсе куча дыр, которые разработчики даже не фиксят, а просто рекомендуют закрыть admin с помощью .htaccess.
Однако, недавно вышла версия 5.0, которая написана с нуля.

Была ли эта статья Вам полезна?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Напоминаем Вам, что Ваше сообщение будет опубликовано только после проверки администратором сайта. Обычно это занимает 1-2 рабочих дня.