система биллинга IP-трафика

• Единая база данных по ИТ-ресурсам предприятия: ФИО пользователей, IP-адреса и названия их компьютеров, лимиты на пользование сетью Internet, любые другие данные.
• При заходе на определённый администратором адрес, любой пользователь может самостоятельно просмотреть свои данные и свою статистику.
• Подсчёт IP (TCP/UDP) трафика.
• Встроенные отчёты для администратора:

1. суммарное количество байт, переданных с каждого и принятых на каждый из IP-адресов контролируемой сети с группировкой по IP-адресам внешней сети за произвольный промежуток времени;
2. список IP-адресов контролируемой сети с количеством байт, переданных с каждого и принятых на каждый из них за произвольный промежуток времени;
3. список IP-адресов контролируемой сети с количеством байт, переданных с каждого и принятых на каждый из них за текущий месяц и сегодняшний день.

• Отключение IP-адресов от сети Internet согласно месячной таблице лимитов.
• Легкость расширения системы (новые отчёты, новые модули) за счёт прозрачной структуры таблиц и использованного языка программирования - PHP.

• Аутентификация пользователей производится только по IP-адресам. Соответственно, никак не контролируется возможная смена пользователем IP-адреса. Эта особенность, если в конкретном случае она является недостатком, может быть относительно легко устранена путём добавления в таблицу 'IP' поля 'MAC-адрес' и написания маленького скрипта, в котором производится отключение автоматического присваивания соответствия MAC и IP-адресов и происходит принудительное присваивание соответствия MAC и IP-адресов для протокола ARP (т.н. статический ARP).
• По указанной выше причине в текущей реализации невозможно работа на одном ПК нескольких пользователей, у каждого из которых установлен собственный лимит. Поскольку на самостоятельную добровольную смену IP-адреса пользователем рассчитывать особенно не приходится, представляется возможным реализовать смену адреса с помощью скрипта.
• Текущие SQL-запросы рассчитаны на использование только одной внутренней подсети.
• Отсутствует специальный HTML-интерфейс для редактирования данных (в т. ч. лимитов) пользователей; редактирование происходит путём непосредственного изменения данных в БД. Этот недостаток легко устраним путём написания соответствующего модуля.

В настоящее время большинство юридических лиц - пользователей сети Internet подключены к ней по тарифам с оплатой исходя из количества принятого (и/или переданного) трафика. Причём три года тому назад, когда было начато написание системы, безлимитных тарифных планов практически не было, а лимитные были более дорогими.

Для сравнительно небольших организаций плата за трафик не является такой уж незначительной, и остро встаёт вопрос выявления количества трафика, израсходованного конкретным пользователем, и целей, на которые этот трафик был потрачен. Проще говоря, руководству организации нужна информация о посещённых сайтах в случае использования протокола http, скаченных файлах в случае использования протокола ftp и т. д. Причём некоторых людей, особенно - далёких от компьютера, бывает сложно убедить, что такой большой трафик есть продукт работы их компьютеров - читай, результат их собственных действий, если не предоставить подробного списка ресурсов с данными о трафике с каждого/на каждый из них.

По тем или иным причинам (забота организации об информационной безопасности, дефицит реальных IP-адресов у провайдера) подключение внутренней ЛВС (локальной вычислительной сети) организации к сети Internet обычно происходит через роутер, установленный на границе между внутренней ЛВС организации и сетью Internet.

В качестве роутера может использоваться ПК с 2-мя сетевыми картами и специальным образом настроенной (включён сервис NAT - Network Address Translation) сетевой ОС (FreeBSD, Linux, Windows, Solaris и т.д.). Или же это может быть специально разработанное устройство (нередко также использующее одну из перечисленных выше ОС, например FreeBSD или Linux). Возможны также другие варианты, но упоминать о них не представляется возможным в силу ряда причин, начиная с их меньшей распространённости и кончая выходом за рамки темы и ограниченностью размеров данной статьи.

В своё время перед автором встала именно такая задача - учёт и ограничение трафика. В качестве роутера использовался ПК с 2-мя сетевыми картами и установленной ОС FreeBSD. Несмотря на кажущуюся распространённость - почти банальность - задачи, полностью устраивающее готовое решение найти не удалось. (Оговорюсь, что рассматривались только бесплатные системы.) В результате, было принято решение писать собственную биллинговую систему.

• Первый: proxy-сервер. Давать пользователям доступ в Internet только через proxy-сервер Squid, без использования NAT.

          Преимущества:

1. широкие возможности аутентификации;
2. очень гибкая возможность ограничения доступа к определённым ресурсам;
3. наличие в свободном доступе в сети Internet обновляемых баз ресурсов порнографического/эротического, развлекательного и т. п. характера;
4. полный протокол всех посещенных пользователем страниц (а не только серверов, как в случае протоколирования TCP-трафика) c указанием даты, времени и количества байт;
5. возможность блокировки рекламных баннеров, что позволяет тем самым экономить трафик как организации, так и пользователям;
6. кэш единожды загруженных страниц, позволяющий экономить трафик при посещении одним пользователем ресурса, который уже смотрел другой;
7. наличие мощной и гибкой системы построения отчётов и несложного биллинга SARG (Squid Analysis Report Generator).

          Недостатки:

1. не все программы поддерживают работу через proxy-сервер;
2. невозможность отключения пользователя сразу при превышении им установленного лимита трафика. Дело в том, что трафик пользователя считается путём анализа протоколов (log-файлов) работы proxy-сервера, а в них информация о скаченных данных (файлах) записывается только по завершении загрузки. Например, лимит пользователя - 70 Mb, он уже израсходовал 45 Mb, начинает скачивать файл 60 Mb. Данные об этой загрузке попадут в log-файл только после её завершения и, соответственно, пользователь будет отключён тоже только по завершении загрузки.

• Второй: NeTAMS. Использовать биллинговую систему NeTAMS (Network Traffic Accounting and Monitoring Software) - очень мощную и гибкую, поддерживающую множество методов сбора информации о трафике (tee, divert, ip_queue, ulog, libpcap, netflow v5, netflow v9, netgraph) и её хранения (MySQL, PostgreSQL). Единственный недостаток - отсутствие подробной статистики посещённых пользователем ресурсов. То есть для этой системы это, наверное, и не недостаток - у неё несколько другие задачи, в первую очередь сбор информации о трафике с сетевых устройств фирмы Cisco, а для моего случая это недостаток.
• Третий: VPN или PPPoE. Доступ в Internet можно предоставлять через VPN или PPPoE подключение к роутеру. Для нашего случая при отсутствии видимых плюсов, оказалось много минусов:

1. переучивание пользователей процедуре подсоединения к сети Internet;
2. перенастройка всех компьютеры пользователей;
3. освоение отдельной большой темы системным администратором (возможно, его придётся отправлять на курсы повышения квалификации, возможно - он освоит это сам, но в любом случае, больше знания/умения - больше заработная плата; в случае ухода - сложнее найти и дороже нанять нового);
4. усложнение системы (а значит, снижение надёжности - это аксиома) из-за наличия и связывания большего количества программ на роутере - на сервер придётся установить большое количество дополнительно программного обеспечения (за найденными уязвимостями и выпущенными обновлениями для которого тоже необходимо следить);
5. дополнительная нагрузка на сервер за счёт использования дополнительно программного обеспечения;
6. дополнительная нагрузка на сетевую инфраструктуру предприятия из-за увеличения объёма трафика за счёт шифрования.

• Для сбора трафика используется BPFT. Система построена на основе библиотеки libpcap и использует механизм BPF (Berkley Packet Filter "pseudo-device") для захвата IP-трафика.
• При выборе СУБД автор колебался между MySQL и Firebird.

За Firebird было:

1. большой опыт работы с ним автора; 
2. наличие очень удобного инструмента IBExpert.

Против:

1. работа текущей на тот момент версии (1.5) только из-под inetd. На сервере этот демон не использовался и поднимать его только ради биллинга не хотелось;
2. поддержка транзакций, обеспечивающих большую надёжность в ущерб скорости, что для нашей системы совершенно неоправданно.

В конечном счёте, остановились на MySQL (4-я или 5-я версии, но, думаю, будет работать и с 3-й).

• Язык программирования для общения с базой данных - PHP, за C-подобный синтаксис, возможность использования программ на нём как просто в системе, так и внутри HTML-страниц.

Функционально в системе биллинга можно условно выделить три модуля: учёт трафика, вывод информации об учтённом трафике и модуль разрешения/запрещения пользования сетью Internet. Поскольку данные в таблицы пишет первый из перечисленных выше модулей, раздел с описанием структуры таблиц логично отнести именно в данный раздел.

Создадим базу данных с именем 'traffic'. В базе создадим две таблицы: 'Ip' - данные о IP-адресе и 'Log' - данные о трафике; назначение полей этих таблиц понятно из их названий.

Также создадим двух пользователей, имеющих право подсоединяться к базе данных только с локального компьютера: 'insert_user' - пользователь, который имеет право только добавлять данные в базу и 'view_user' - пользователь, который имеет право только читать данные из базы. Пароли, конечно же, только для статьи - при инсталляции системы рекомендуется сгенерировать более стойкие к взлому путём перебора.

Как видно из скрипта create_db_&_users_&_tables.sql, в качестве формата базы был выбран - MyISAM, который обеспечивает большую скорость работы за счёт отсутствия транзакций.

Параметр "ROW_FORMAT" определяет, каким образом должны храниться строки в файле базе данных. Задавая этому параметру значения "fixed", мы предписываем MySQL под каждую переменную типа VARCHAR выделять не реально занимаемое её значением место, а максимально возможное. Например, если мы при создании базы определили поле "IP_TO" как VARCHAR(15), то, независимо от длины помещённых в него данных, оно всегда будет занимать 15 байт. Хотя из-за этого файл базы данных будет занимать больше места, нам в этой ситуации важнее, что операции с базой будут проходить несколько быстрее.

Ядро системы FreeBSD должно включать поддержку pseudo-device BPF, для чего в файле конфигурации должна присутствовать строка

Автор рекомендовал бы устанавливать trafd, MySQL, PHP и прочее программное обеспечение из портов (как и любой софт под FreeBSD, кроме cvsup).

Сноска после слова cvsup: Порт net/cvsup зависит от системы Modula-3, которой потребуется существенный объем времени и пространства на диске для загрузки и установки, поэтому обычно автор устанавливает cvsup из пакетов.

Демон trafd, собранный из порта net-mgmt/bpft настроен на немного другие пути, чем все наши скрипты. Поэтому перед сборкой необходимо заменить в дистрибутиве файл pathnames.h на прилагающийся в архиве и отредактировать Makefile, задав значение переменной PATH_TOSAVE равным /var/trafd/ (PATH_TOSAVE=/var/trafd/).

Порт net-mgmt/bpft содержит много дополнительных файлов, никак не применяемых в нашей задаче. Поэтому автор не устанавливает его нормальным образом (make install), а просто копирует два нужных файла - trafd и traflog в /usr/local/sbin/.

Настройка основных параметров trafd осуществляется в файле rc.conf, как и должно быть у всякого порядочного демона для системы FreeBSD.

Крайне полезна возможность пакета программ trafd, позволяющая существенно сэкономить усилия при написании биллинга, который в качестве анализатора трафика использует trafd - не надо писать свой парсер логов. В состав пакета программ trafd входит утилита traflog, которая может экспортировать данные по трафику в любой текстовой файл в соответствии с форматом, заданном в её конфигурационном файле - traflog.format.

В traflog.format был прописан формат sql-команды insert для нашей базы.

Были написаны два командных файла для связки trafd и MySQL: trafd_dump и trafd_to_mysql.

Краткое описание выполняемых действий: trafd_dump даёт команду trafd скинуть данные по трафику на всех прослушиваемых им интерфейсах во временные файлы. Информация об успехе или неуспехе подачи команды сохраняется в syslogd.

Краткое описание выполняемых действий: trafd_to_mysql импортирует данные по трафику на всех прослушиваемых trafd интерфейсах из временных файлов, созданных trafd_dump, в базу MySQL. Информация об успехе или неуспехе подачи команды сохраняется в syslogd.

Эти два файла должны регулярно запускаться. Насколько регулярно - зависит от интенсивности трафика на роутере. Для наших условий нормально делать это каждые пять минут. Прописываем в /etc/crontab

Просмотр статистики - как пользователем, так и администратором - производится через web-интерфейс (выполнен в виде HTML страниц с кодом на языке PHP внутри) любым браузером.

При открытии в браузере ресурса, который размещён по назначенному администратором для страницы статистики адресу, пользователь сразу видит имеющуюся в базе данных информацию об IP-адресе, с которого он зашел на страницу статистики (рис. 1.).

Рис. 1. Интерфейс биллинговой системы, каким его видит пользователь

Интерфейс администратора предлагается расположить в другом виртуальном домене или, по крайней мере, в другой директории. Его защита от несанкционированного доступа может быть реализована различными способами. Например, если в качестве Web-сервера используется Apache, можно использовать такую схему

Файл с именами пользователей и паролями создаётся командой:

Экран администратора разделён на две части: в верхней - меню, в нижней - таблица с результатами запроса. Сразу при открытии показывается таблица трафика за сегодняшний день и за текущий месяц (рис. 2.).

Рис. 2. Интерфейс администратора сразу после загрузки страницы

В выпадающих списках "Период" задаётся период, по которому мы хотим получить информацию.

Кнопка "Список IP-адресов сети + входящий и исходящий трафик" - выводит полную информацию обо всех имеющихся в базе данных IP-адресах внутренней сети, а также количество входящего и исходящего трафика для каждого из них за указанный период (рис. 3.).

Рис. 3. Список, выдаваемый в результате нажатия на кнопку "Список IP-адресов сети + входящий и исходящий трафик"

Кнопка "Суммарная - по хостам - для IP-адреса" - выводит список всех входящих и исходящих соединений для IP-адреса, заданного в поле ввода с таким же названием. При этом для каждого IP-адреса из списка считается суммарный трафик, и таблица сортируется по убыванию. Желтым цветом обозначен входящий трафик, зелёным - исходящий (рис. 4.).

Рис. 4. Статистика для IP-адреса с группировкой по хостам, с которыми были соединения

Кнопка "Подробная для IP-адреса" - выводит список всех входящих и исходящих соединений для IP-адреса, заданного в поле ввода с таким же названием. По сути, это просто дамп базы данных с отбором по заданному IP-адресу. Желтым цветом обозначен входящий трафик, зелёным - исходящий (рис. 5.).

Рис. 5. Подробная статистика для IP-адреса

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

Ниже рассматривается вопрос написания и установки основного модуля системы биллинга, который служит этим целям.

По результатам работы биллинга какие-то IP-адреса должны получать доступ в Internet, а какие-то - нет. В данной системе это осуществляется путём добавления IP-адресов, которым разрешен доступ в Internet, в таблицу № 0 (table 0) встроенного firewall'а FreeBSD ipfw. Файл инициализации правил firewall'а ipfw может содержать среди прочих такие строки:

Чтобы биллинг запускался при старте системы, во-первых, нужно прописать в /etc/rc.conf:

Во-вторых, нужно создать в /usr/local/etc/rc.d/ файл с приведённым ниже содержанием.

Давайте разберём построчно, что делается в скрипте adc_billing. Номера строк приведены для удобства рассказа о его содержимом, в реальном командном файле они отсутствуют.

1 : "Магическая последовательность" символов "#!", сообщающая текущему командному интерпретатору, что за ней следуют путь и имя того командного интерпретатора, в котором данный сценарий должен выполняться. Лучше всего стартовые скрипты (в каталог /usr/local/etc/rc.d) писать на языке sh - в противном случае теряется, во-первых, очень удобная возможность задания очередности пуска скрипта (см. пояснение к строкам 3 и 4, а также rcorder(8)), во-вторых, приходится заново писать весь код, уже существующий в rc.subr и, в-третьих, в силу во-первых и во-вторых, это противоречит идеологии системы.

2 : Имя сервиса, с которым работает данный скрипт.

3 : Имя одного или нескольких сервисов, которые должны быть запущены до данного скрипта. Регистр имеет значение, поэтому имя сервиса должно быть указано точно так, как оно написано в соответствующем скрипте в # PROVIDE

4 : Ключевое слово. В нашем скрипте оно одно - shutdown. Благодаря его присутствию, наш скрипт будет вызываться скриптом /etc/rc.shutdown при выключении и перезагрузке системы.

5, 6: Напоминание об имени и возможных значениях переменной, которая, будучи добавлена в rc.conf, управляет работой данного скрипта.

7 : В файле /etc/rc.subr содержатся функции для выполнения типичных операций. Ими рекомендуется пользоваться всем rc.d скриптам. Естественно, для того, чтобы ими пользоваться, нужно включить их в текущий скрипт, что и делается в этой строке.

8 : Задание обязательной для rc.subr переменной "name" значения - имени скрипта. Должна быть установлена до вызова любой из функций, содержащихся в rc.subr.

9 : Получение имени переменной, изменением значения которой разрешается или запрещается запуск нашего сервиса. (Причиной существования функции "set_rcvar" являются различия в соглашении об именовании таких переменных во FreeBSD и NetBSD. Во FreeBSD в rc.conf пишут service_enable="YES", в то время как в NetBSD - service="YES".)

10: Переменная, значение которой - командная строка для запуска нашего сервиса. Если она задана, rc.subr будет действовать по сценарию обслуживания стандартного демона. В частности, предоставляются методы по умолчанию для следующих аргументов скрипта: start, stop, restart, status, poll, rcvar.

11: Определение имени функции, которая будет вызвана при запуске нашего скрипта с аргументом "stop". Как видно из строк 13-16, в ней ничего не делается, кроме вывода сообщения. В принципе, это не является строго необходимым, но автору представляется, что так правильнее и красивее ;-), к тому же, это задел на будущее - если биллинг так разовьётся, что нужно будет делать какие-либо действия при его выключении.

12: Если переменная, определяющая запуск нашего скрипта, в rc.conf не декларирована, то она объявляется и ей присваивается значение "NO". Тем самым мы избегаем запуска скрипта.

17: Загрузить переменные из rc.conf

18: Вызов основной функции из rc.subr(8) для выполнения действия, ради которого скрипт был запущен. При этом она (функция) будет использовать переменные и другие функции, определённые в скрипте. Обычно это последняя строка скрипта.

Когда-то в BSD-системах был один стартовый скрипт - /etc/rc. Процесс init(8) вызывал его при запуске ОС для выполнения всех действий, которые надо сделать в однопользовательском окружении (проверка дисков, монтирование разделов, установка параметров сети, запуск различных демонов и т. д.). Конечно же, список этих действий не одинаков для различных систем, и администраторам приходилось подгонять его под свои нужды путём редактирования файла /etc/rc. Найти нужные строки в длинном файле было большой проблемой. Другим недостатком такой системы была невозможность перезапуска какого-либо одиночного сервиса.

В связи с этим сообществом разработчиков NetSBD была создана система rc.d, которая позднее была импортирована во FreeBSD. Вот идеи, положенные в её основу.

Модульность - для каждой задачи свой скрипт, используя который можно запустить, остановить или узнать статус сервиса.

Повторное использование кода - типичные операции, выполняемые большинством скриптов, выполнены в виде функций на языке sh и собраны в /etc/rc.subr. Благодаря этому типовые rc.d скрипты могут быть длиной всего лишь в несколько строк.

Более подробную информацию (на английском языке) по rc.d скриптам можно найти в руководстве по FreeBSD - темы rc(8), rc.subr(8), rcorder(8), rc.conf(5), а также в статье Yar Tikhiy "A practical guide to BSD rc.d scripting" по адресу http://people.freebsd.org/~yar/rcng/article.html.

Необходимо, чтобы основная программа биллинга запускалась каждые 10 минут и обновляла правила firewall'а в соответствии с информацией из базы данных. Для этого в файл /etc/crontab добавляется следующая строка:

Краткое описание выполняемых действий: adc_billing запрашивает у MySQL сумму трафика за текущий месяц (из таблицы 'Log') по каждому IP-адресу (из перечисленных в таблице 'Ip'), у которого поле 'Ip.quota' не равно NULL, и затем, если число вычисленного трафика меньше значения 'Ip.quota', добавляет этот IP-адрес в таблицу № 0 (table 0) firewall'а ipfw.

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

P.S. Статья была опубликована в журнале "Системный администратор" за август 2006 года.

P.P.S. Архив со всеми скрипами.