а) Учитывать IP–трафик в сети
б) Брать с кого–то за это деньги (опционально)
Грубо говоря, решением первой задачи занимаются системы учета трафика, второй задачи — системы биллинга.
С задачей учета трафика успешно справляется достаточно большое количество программ. Они имеют (или нет) средства, чтобы:
• Собрать циферки
• Суммировать циферки
• Положить сумму в базу или лог
• Отобразить циферки согласно (сложному) запросу
• Скомандовать внешней программе о превышении (редко)
Собрать циферки можно многими путями, из которых можно выделить следующие:
• Счетчики пакетов вашей операционной системы
• Можно делать опрос встроенных счетчиков на правилах ipfw/iptables, но сразу возникают вопросы: кто будет эти правила выставлять–убирать, как часто делать такой опрос (скорость vs. точность), насколько это все удобно и гибко
• Анализ потока NetFlow
• Фирма Cisco Systems придумала способ, как отдавать информацию о промаршрутизированном трафике наружу, другим программам. Это делается при помощи протокола NetFlow, который описан тут. Правильным образом настроенный маршрутизатор периодически отсылает на указанный сервер UDP–пакеты, содержащие Flow Records — информацию о прошедшем трафике, суммированную по разным признакам. Принимающей стороне остается лишь разобрать и переварить пакеты.
• Опрос другого сетевого устройства по SNMP
• Нельзя сказать, что это удачный метод, т.к. стандартные счетчики SNMP содержат только информацию по количеству байтов/пакетов, прошедших через интерфейс, без разделения на протоколы–порты– адреса.
• Встроиться вовнутрь ядра операционной системы и получать статистику «из первых рук»
• Очень быстро работает, но фактически приводит к экспорту логов/потока netflow из ядра, не больше.
• Слушать на интерфейсе
• Широко известная библиотека libpcap позволяет посмотреть на каждый пакет (и его заголовки), проходящий через роутер.
Суммировать (агрегировать) статистику просто необходимо, иначе большой объем первичной информации не даст быстро провести нужный запрос. Суммируют обычно по времени, номеру автономной системы, адресу получателя, протоколу, группе протоколов.
Чтобы статистика не потерялась после перезагрузки компьютера, ее надо хранить в базе данных, желательно SQL. При этом упрощается процесс получения выборок по заданному признаку.
Для отображения статистики часто пишется веб–интерфейс, работающий с базой данных, и позволяющий сделать выборку по заданному критерию (время, адреса и прочее).
Если требуется производить какие–либо действия по управлению трафиком (отключение клиента) по превышению значения счетчиков, эти счетчики должен периодически мониторить какой–нибудь демон или скрипт.
В природе существует большое количество «считалок», в разной степени попадающих под вышеприведенное описание. Их хороший обзор приведен тут: http://www.unixfaq.ru/index.pl? req=qs&id=247.
Дальнейшее развитие систем учета трафика — системы биллинга. Их основные свойства:
• Развитый интерфейс управления, настройки, запросов; клиентская часть
• Перевод счетчиков «считалок» в деньги согласно тарифному плану. Тарифные планы могут быть чрезвычайно хитрыми.
• Ведение счетов клиента (платежи, смена планов, блокировка, …)
• Поддержка бухгалтерии (акты, счета, сводки, …)
• Обязательна возможность отключения клиента (с уведомлением)
• Наличие сертификата Минсвязи
Для получения сертификата Минсвязи, позволяющего легально использовать установленную систему биллинга для обслуживания (читай — отъема денег) клиентов, и официально сдать в эксплуатацию узел связи, нужны большие средства. В природе есть несколько дорогих систем (Абсолют, CBOSS, Атлант, IpSoft Billing), и ряд более дешевых (NetUP, LanBilling). В большинстве случаев стоимость биллинговой системы определяется набором модулей (netflow, выделенные линии, VoIP, …), включенных в поставку.
Система биллинга, не имеющая сертификата Минсвязи, особо никому и не нужна.
Модуль биллинга, поставляемый с NeTAMS бесплатно, позволяет создавать новый тип объектов — аккаунт пользователя, привязывать к нему юниты, вести гибкие тарифные планы, управлять счетом клиента и т.д. Вместе с тем, сертификата Минсвязи на этот модуль НЕТ.
Файл префиксов и учет российского/зарубежного трафика
Для начала необходимо пояснить суть проблемы и рассказать, зачем такой учет вообще необходим.
Зачастую бывает, что ваш провайдер выставляет вам счет за пользование интернетом, состоящий из двух цифр: стоимость российского трафика и стоимость зарубежного, т.е. результат обмена информацией с зарубежными серверами. Дело в том, что сам провайдер каким–либо образом покупает трафик у более крупных, магистральных провайдеров которые не связываются с мелкими клиентами. При этом, обмен данными с российскими серверами ведется по одним каналам связи, а для общения с зарубежными серверами используются немногочисленный зарубежные каналы. Надо сказать, что суммарная полоса пропускания данных всех российских провайдеров «за рубеж» составляет всего несколько сот мегабит на всю страну, и таких каналов не так и много (десяток, наверное). Естественно, аренда этих каналов стоит существенно дороже по сравнению с внутрироссийскими и внутримосковскими каналами. Представьте на секунду, сколько стоит проложить трансатлантический подводный оптоволоконный кабель на несколько тысяч километров? Это вам не витую пару через этаж кинуть! :) Вот почему зарубежный трафик стоит дороже российского. Вообще, процентов 80 российского трафика прокачивается через АТС номер 9, что на ул.Губкина, в Москве.
Теперь надо определить, как отличить «российский» и «зарубежный» трафик, и как это делает ваш провайдер. Все основано на глобальной маршрутизации в Интернете, которая осуществляется по протоколу BGP. Грубо говоря, все сети, подключенные к интернету, принадлежат некоей Автономной Системе (AS), которая представляет собой набор IP–сетей (адресных пространств), находящихся под единым управлением. Владелец и руководитель автономной системы определяет политику маршрутизации своих подсетей через своих соседей–провайдеров или крупных организаций, имеющих свои автономные системы. Все такие системы соединены логическими связями друг с другом так, что любая машина в интернете может быть связана с любой другой машиной посредством нескольких (3–7) автономных систем, каждая из которых образована несколькими маршрутизируемыми сетями. Более того, протокол позволяет выбирать оптимальный путь пользуясь большим количеством передаваемой между автономными системами вспомогательной информации, и т.д. Возвращаясь к нашему случаю, ваш провайдер определил маршрутизацию российского трафика (т.е. сетей, принадлежащих российским AS, их список известен) через один канал, а всего остального — через другой, и за другие деньги. Соответственно, и со своих клиентов взимается разная плата.
Теперь, если вы хотите у себя учитывать разделение трафика так, как это делает у себя ваш провайдер, вам по–хорошему надо бы поднять у себя маршрутизатор (Cisco, FreeBSD/Zebra,…), поднять на нем сессию iBGP с провайдером, получать от него таблицу роутинга (она часто меняется) и импортировать ее в вашу
