 |
|
|
|
Биллинг на FreeBSD: пишем сами, используя PHP, trafd и MySQL
Биллинг на FreeBSD: пишем сами, используя PHP, trafd и MySQL Если пользователи жалуются, что Интернет «тормозит», а начальство ругается, что счета от провайдера слишком большие, покупка готового биллинга – не единственный выход. В настоящее время большинство юридических лиц – пользователей Интернета – оплачивают услуги исходя из количества принятого (и/или переданного) трафика. Для небольших организаций плата за трафик не является такой уж незначительной, и остро встаёт вопрос учета трафика, израсходованного конкретным пользователем, и целей, на которые этот трафик был потрачен. Проще говоря, руководству организации нужна информация о посещённых сайтах в случае использования протокола http, скачанных файлах в случае использования протокола ftp и т. д. Причём некоторых сотрудников бывает сложно убедить, что большой трафик – результат их собственных действий, если не предоставить подробного списка ресурсов с данными о трафике. По тем или иным причинам (забота организации об информационной безопасности, дефицит реальных IP-адресов у провайдера) подключение внутренней ЛВС организации к Интернету обычно происходит через роутер, установленный на границе между внутренней ЛВС организации и Интернетом. В качестве роутера может использоваться ПК с 2 сетевыми картами и специальным образом настроенной (включён сервис NAT) сетевой ОС (FreeBSD, Linux, Windows, Solaris и т. д.). Или же это может быть специально разработанное устройство (нередко также использующее одну из перечисленных выше ОС). Возможны и другие варианты, я рассмотрю наиболее распространенный. В своё время передо мной была именно такая задача – учёт и ограничение трафика. В качестве роутера использовался ПК с 2 сетевыми картами и установленной ОС FreeBSD. Несмотря на кажущуюся распространённость – почти банальность – задачи, полностью устраивающее готовое решение найти не удалось. (Рассматривались только бесплатные системы.) В результате было принято решение писать собственную биллинговую систему. Используемое ПО Для сбора трафика используется BPFT (http://bpft4.sourceforge.net). Система построена на основе библиотеки libpcap и использует механизм BPF (Berkley Packet Filter «pseudo-device») для захвата IP-трафика. При выборе СУБД я выбирал между MySQL и Firebird. За Firebird было:
Против:
В конечном счёте, я остановился на MySQL (4-я или 5-я версии, но, думаю, будет работать и с 3-й). Язык программирования для общения с базой данных – PHP, за C-подобный синтаксис, возможность использования программ на нём как просто в системе, так и внутри HTML-страниц. Система учёта IP-трафика Функционально в системе биллинга можно условно выделить три модуля: учёт трафика, вывод информации об учтённом трафике и модуль разрешения/запрещения пользования Интернетом. Поскольку данные в таблицы пишет первый из этих модулей, начнём раздел с описания структуры таблиц. Структура таблиц Создадим базу данных с именем traffic. В базе создадим две таблицы: Ip – данные о IP-адресе и Log – данные о трафике. Назначение полей этих таблиц понятно из их названий. Также создадим двух пользователей, имеющих право подсоединяться к базе данных только с локального компьютера: insert_user – пользователь, который имеет право только добавлять данные в базу и view_user – пользователь, который имеет право только читать данные из базы. Пароли, конечно же, только для статьи – при инсталляции системы рекомендуется сгенерировать более стойкие к взлому. Файл create_db_&_users_&_tables.sql CREATE DATABASE traffic DEFAULT CHARACTER SET koi8r DEFAULT COLLATE koi8r_general_ci; GRANT INSERT ON traffic.* TO 'insert_user'@'localhost' IDENTIFIED BY '123456789'; GRANT SELECT ON traffic.* TO 'view_user'@'localhost' IDENTIFIED BY '987654321'; USE traffic; CREATE TABLE Ip ( IP VARCHAR(15) NOT NULL PRIMARY KEY, QUOTA INTEGER, PCNAME VARCHAR(100), FNAME VARCHAR(100), MNAME VARCHAR(100), LNAME VARCHAR(100), EMAIL VARCHAR(200), INDEX(IP) ) ENGINE = MyISAM; CREATE TABLE Log ( NN INTEGER(12) UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY, IP_FROM VARCHAR(15) NOT NULL, IP_TO VARCHAR(15) NOT NULL, SRC_PORT VARCHAR(5) NOT NULL, DEST_PORT VARCHAR(5) NOT NULL, PROTO VARCHAR(4) NOT NULL, DATA_BYTES INTEGER NOT NULL, ALL_BYTES INTEGER NOT NULL, FIRST_TIME TIMESTAMP NOT NULL, LAST_TIME TIMESTAMP NOT NULL, INDEX(IP_FROM), INDEX(IP_TO), INDEX(SRC_PORT), INDEX(DEST_PORT), INDEX(PROTO), INDEX(ALL_BYTES), INDEX(FIRST_TIME), INDEX(IP_FROM,FIRST_TIME), INDEX(IP_TO,FIRST_TIME) ) ENGINE = MyISAM ROW_FORMAT = fixed; Как видно из скрипта create_db_&_users_&_tables.sql, в качестве формата базы был выбран – MyISAM, который обеспечивает большую скорость работы за счёт отсутствия транзакций. Параметр ROW_FORMAT определяет, каким образом должны храниться строки в файле базы данных. Задавая этому параметру значения fixed, мы предписываем MySQL под каждую переменную типа VARCHAR выделять не реально занимаемое её значением место, а максимально возможное. Например, если мы при создании базы определили поле IP_TO как VARCHAR(15), то независимо от длины помещённых в него данных, оно всегда будет занимать 15 байт. Хотя из-за этого файл базы данных будет занимать больше места, нам в этой ситуации важнее, что операции с базой будут проходить несколько быстрее. Настройка ОС FreeBSD Ядро системы FreeBSD должно включать поддержку pseudo-device BPF, для чего в файле конфигурации adc-kernel должна присутствовать строка: # The `bpf" device enables the Berkeley Packet Filter. device bpf #Berkeley packet filter Я рекомендовал бы устанавливать trafd, MySQL, PHP и прочее программное обеспечение из портов (как и любой софт под FreeBSD, кроме cvsup). Примечание: порт net/cvsup зависит от системы Modula-3, которой потребуется существенный объем времени и пространства на диске для загрузки и установки, поэтому обычно автор устанавливает cvsup из пакетов. Настройка trafd Настройка основных параметров trafd осуществляется в файле rc.conf, как и должно быть у всякого порядочного демона для системы FreeBSD. trafd_enable="YES" trafd_ifaces="rl0 xl0" trafd_flags="-p -r" trafd_pid="/var/run/trafd" Полезна возможность пакета программ trafd, позволяющая существенно сэкономить усилия при написании биллинга, который в качестве анализатора трафика использует trafd – не надо писать свой парсер логов. В состав пакета программ trafd входит утилита traflog, которая может экспортировать данные по трафику в любой текстовой файл в соответствии с форматом, заданным в её конфигурационном файле – traflog.format. В traflog.format был прописан формат sql-команды insert для нашей базы. my_sql { from:"insert into Log (ip_from,ip_to,src_port, dest_port,proto,data_bytes,all_bytes,first_time, last_time) values("%s"," to:""%s"," sport:""%s"," dport:""%s"," proto:""%s"," bytes:"%ld, " psize:"%ld, " ftime:""%y-%m-%d %T"," ltime:""%y-%m-%d %T"); " }; Командные файлы Были написаны два командных файла для связки trafd и MySQL: trafd_dump.sh и trafd_to_mysql.sh. Краткое описание выполняемых действий: trafd_dump.sh даёт команду trafd скинуть данные по трафику на всех прослушиваемых им интерфейсах во временные файлы. Информация об успехе или неуспехе подачи команды сохраняется в syslogd. Файл trafd_dump.sh #!/bin/sh . /etc/rc.conf for iface in ${trafd_ifaces}; do if [ -f ${trafd_pid}.${iface} ]; then kill -INT `cat ${trafd_pid}.${iface}` logger -t trafd_dump "signaling trafd on ${iface} dump to file" else logger -t trafd_dump "trafd on ${iface}: file ${c_pid} not found (trafd don't listen on ${iface}?)" fi done Trafd_to_mysql.sh импортирует данные по трафику на всех прослушиваемых trafd интерфейсах из временных файлов, созданных trafd_dump.sh, в базу MySQL. Информация об успехе или неуспехе подачи команды сохраняется в syslogd. Файл trafd_to_mysql.sh #!/bin/sh . /etc/rc.conf for iface in ${trafd_ifaces}; do if [ -f /var/trafd/trafd.${iface} ]; then logger -t trafd_to_mysql "inserting traffic data for ${iface} into mysql" /usr/local/bin/traflog -a -o my_sql -n -i rafd/trafd.$iface | /usr/local/bin/mysql -u insert_user -p123456789 traffic rm /var/trafd/trafd.$iface else logger -t trafd_to_mysql "failed to insert traffic data for ${iface} into mysql: file /var/trafd/trafd.${iface} not found" fi done Эти два файла должны регулярно запускаться. Насколько регулярно – зависит от интенсивности трафика на роутере. Для наших условий нормально делать это каждые пять минут. Прописываем в /etc/crontab: */5 * * * * root /usr/home/root/sbin/trafd_dump.sh && sleep 30 && /usr/home/root/sbin/trafd_to_mysql.sh Веб-интерфейс системы учёта трафика Просмотр статистики – как пользователем, так и администратором – производится через веб-интерфейс (выполнен в виде HTML-страниц с кодом на языке PHP внутри) любым браузером. При открытии в браузере ресурса, который размещён по назначенному администратором для страницы статистики адресу, пользователь сразу видит имеющуюся в базе данных информацию об IP-адресе, с которого он зашел на страницу статистики (см. рис. 1).
Рисунок 1. Интерфейс биллинговой системы, каким его видит пользователь Администратор открывает страницу admin.htm, находящуюся в том же каталоге, что и интерфейс пользователя, или в другом – по его желанию. Защита интерфейса администратора от несанкционированного доступа может быть реализована различными способами. Например, если в качестве веб-сервера используется Apache, можно воспользоваться файлами .htaccess и .htpasswd. Экран администратора разделён на две части: в верхней – меню, в нижней – таблица с результатами запроса. Сразу при открытии показывается таблица трафика за сегодняшний день и за текущий месяц (см. рис. 2).
Рисунок 2. Интерфейс администратора сразу после загрузки страницы В выпадающих списках «Период» задаётся период, по которому мы хотим получить информацию. Кнопка «Список IP-адресов сети + входящий и исходящий трафик» – выводит полную информацию обо всех имеющихся в базе данных IP-адресах внутренней сети, а также количество входящего и исходящего трафика для каждого из них за указанный период (см. рис. 3).
Рисунок 3. Список, выдаваемый в результате нажатия на кнопку «Список IP-адресов сети + входящий и исходящий трафик» Кнопка «Подробная для IP-адреса» – выводит список всех входящих и исходящих соединений для IP-адреса, заданного в поле ввода с таким же названием. По сути, это просто дамп базы данных с отбором по заданному IP-адресу. Зелёным цветом обозначен входящий трафик, желтым – исходящий (см. рис. 4).
Рисунок 4. Подробная статистика для IP-адреса Кнопка «Суммарная – по хостам – для IP-адреса» – выводит список всех входящих и исходящих соединений для IP-адреса, заданного в поле ввода с таким же названием. При этом для каждого IP-адреса из списка считается суммарный трафик, и таблица сортируется по убыванию. Зелёным цветом обозначен входящий трафик, желтым – исходящий (см. рис. 5.).
Рисунок 5. Статистика для IP-адреса с группировкой по хостам, с которыми были соединения Биллинг Итак, мы установили и запустили в эксплуатацию два модуля системы биллинга из трех. Но учитывать и выводить информацию об использованном трафике недостаточно: полноценная система биллинга должна также содержать в себе лимиты входящего и исходящего трафика, задаваемые для каждого пользователя, и обеспечивать отключение соответствующего пользователя при превышении им допустимых лимитов. Ниже рассматривается вопрос написания и установки основного модуля системы биллинга, который служит этим целям. Настройка ОС FreeBSD По результатам работы биллинга какие-то IP-адреса должны получать доступ в Интернет, а какие-то – нет. В системе это осуществляется путём добавления IP-адресов, которым разрешен доступ в Интернет, в таблицу №0 (table 0) встроенного firewall FreeBSD ipfw. Файл инициализации правил ipfw.rules может содержать среди прочих такие строки: # Переменные ${iif} и ${iip} заданы в файле rc.conf # ${iif} – имя интерфейса (сетевой карты) внутренней сети # роутера # ${iip} – внутренний IP-адрес роутера # # Disallow users access to our proxy ${fwcmd} add deny log ip from not table\(0\) to ${iip} 3128 # Disallow users to have Internet ${fwcmd} add deny log ip from not table\(0\) to any in via ${iif} Чтобы биллинг запускался при старте системы, во-первых, нужно прописать в /etc/rc.conf: adc_billing_enable="YES" Во-вторых, нужно создать в /usr/local/etc/rc.d/ файл adc_billing.sh с приведённым ниже содержанием: 1 : #!/bin/sh 2 : # PROVIDE: adc_billing 3 : # REQUIRE: mysql 4 : # KEYWORD: shutdown 5 : # Add the following lines to /etc/rc.conf to enable adc_billing: 6 : #adc_billing_enable="YES" 7 : . /etc/rc.subr 8 : name="adc_billing" 9 : rcvar=`set_rcvar` 10:command="/usr/home/root/sbin/adc_billing.php" 11: stop_cmd="adc_billing_stop" 12: adc_billing_enable=${adc_billing_enable:-"NO"} 13: adc_billing_stop() 14: { 15: echo 'Stopping '${name}'.' 16: } 17: load_rc_config $name 18: run_rc_command "$1" Давайте разберём построчно, что делается в скрипте adc_billing.sh. Номера строк приведены для удобства рассказа о его содержимом: 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) для выполнения действия, ради которого скрипт был запущен. При этом она (функция) будет использовать переменные и другие функции, определённые в скрипте. Обычно это последняя строка скрипта. Необходимо, чтобы основная программа биллинга запускалась каждые 10 минут и обновляла правила firewall в соответствии с информацией из базы данных. Для этого в файл /etc/crontab добавляется следующая строка: */10 * * * * root /usr/home/root/sbin/adc_billing.php Основная программа биллинга Краткое описание выполняемых действий: adc_billing.php запрашивает у MySQL сумму трафика за текущий месяц (из таблицы Log) по каждому IP-адресу (из перечисленных в таблице Ip), у которого поле Ip.quota не равно NULL, и затем, если число вычисленного трафика меньше значения Ip.quota, добавляет этот IP-адрес в таблицу №0 (table 0) firewall ipfw. #!/usr/local/bin/php <? $link = mysql_connect("localhost", "view_user", "987654321") or die("Could not connect: " . mysql_error()); mysql_select_db("traffic") or die("Could not select database"); $query = " SELECT Ip.ip, Ip.quota, Tbl.bytes FROM ( SELECT Log.ip_to, SUM(Log.all_bytes) AS bytes FROM Log WHERE Log.ip_to LIKE '192.168.0.%' AND Log.first_time LIKE '" . date("Y-m") . "-%' GROUP BY Log.ip_to ) Tbl RIGHT JOIN Ip ON Ip.ip = Tbl.ip_to WHERE Ip.quota IS NOT NULL AND (Tbl.bytes < Ip.quota OR Tbl.bytes IS NULL); "; $result = mysql_query($query) or die("Query N1 failed: " . mysql_error()); exec("/sbin/ipfw table 0 flush"); while ($row = mysql_fetch_object($result)) { exec("/sbin/ipfw table 0 add " . $row->ip); } ?> Надеюсь, что описанные в статье методика и набор программ, доведённые в процессе уже достаточно длительной эксплуатации до того уровня, на котором они существуют сегодня, помогут вам решать аналогичные задачи. Приложение Что такое adc_billing Назначение: система биллинга IP-трафика. Возможности:
Недостатки:
Альтернативные варианты биллинга использования Интернета Первый: proxy-сервер. Давать пользователям доступ в Интернет только через proxy-сервер Squid, без использования NAT. Преимущества:
Недостатки:
Второй: NeTAMS. Использовать биллинговую систему NeTAMS (http://www.netams.com) – очень мощную и гибкую, поддерживающую множество методов сбора информации о трафике (tee, divert, ip_queue, ulog, libpcap, netflow v5, netflow v9, netgraph) и её хранения (MySQL, PostgreSQL). Единственный недостаток – отсутствие подробной статистики посещённых пользователем ресурсов. То есть для этой системы это, наверное, и не недостаток – у неё несколько другие задачи, в первую очередь сбор информации о трафике с сетевых устройств фирмы Cisco, а для моего случая это недостаток. Третий: VPN или PPPoE. Доступ в Интернет можно предоставлять через VPN или PPPoE-подключение к роутеру. Для нашего случая при отсутствии видимых плюсов, оказалось много минусов:
Из истории развития стартовых скриптов BSD-систем Когда-то в BSD-системах был один стартовый скрипт – /etc/rc. Процесс init(8) вызывал его при запуске ОС для выполнения всех действий, которые надо сделать в однопользовательском окружении (проверка дисков, монтирование разделов, установка параметров сети, запуск различных демонов и т. д.). Конечно же, список этих действий не одинаков для различных систем, и администраторам приходилось подгонять его под свои нужды путём редактирования файла /etc/rc. Найти нужные строки в длинном файле было большой проблемой. Другим недостатком такой системы была невозможность перезапуска какого-либо одиночного сервиса. В связи с этим сообществом разработчиков NetSBD была создана система rc.d, которая позднее была импортирована во FreeBSD. Вот идеи, положенные в её основу:
Подробную информацию по 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. |
Александр Чагадаев
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
