Практический пример
Разберем теперь конкретные варианты технической реализации такой системы. Например - биллинг для небольшой локальной сети, продающей трафик.
Один из часто используемых способов простого учета трафика - использование счетчиков iptables на пограничном маршрутизаторе. Плюсы такого решения - простота и гибкость, возможность разграничения типов трафика на уровне правил пакетного фильтра. Минусы - прийдется весь трафик, который вы хотите учитывать, маршрутизировать через один PC, что, в общем-то, не сильно критично при небольшой загрузке. В качестве коллектора в таком случае может выступать небольшой PERL-скрипт, анализирующий вывод iptables. При этом рекомендую использовать флаг -Z, который обнуляет счетчики iptables после вывода их значений - так вы избежите потенциально возможного переполнения счетчиков, регистрируя лишь разницу между измерениями.
Рис. 2. Структура цепочек правил iptables
Модуль разграничения доступа, по сути, является простым скриптом, модифицирующий набор правил файрвола, что в результате открывает или закрывает доступ определенному клиенту.
В случае использования VPN (например, для продажи трафика это одно из наиболее оптимальных решений, т.к. в сетях, построенных на дешевых хабах без возможности Port Security, идентификация пользователя по IP является крайне ненадежным решением) вполне логично интегрировать модуль авторизации клиентов в скрипты /etc/ppp/ip-up и /etc/ppp/ip-down, которые вызываются демоном pppd при подъеме и опускании ppp интерфейса (а зачастую VPN-соединения представляют собой по сути, соединения, использующие PPP как транспорт для инкапсулированного трафика). Аналогичным образом можно организовать авторизацию для dial-up соединений.
Завершает основную часть системы небольшой демон (или просто программа, с определенной периодичностью вызываемая средствами crond), который анализирует оперативную информацию и на ее основе принимает решения об отключении абонентов, если у них на счету закончились средства (в таком случае просто соответствующее правило файрвола меняется на запрещающее). По сути, этот компонент и заключает в себя основную часть бизнес-логики, т.к. именно он ответственен за финансовые расчеты.
Модуль административного интерфейса и веб-статистики являются достаточно тривиальными задачами, и их вряд ли стоит подробно рассматривать. Единственное, на чем хочется акцентировать внимание - это то, что эти модули должны быть разработаны с максимальным учетом бизнес-спефики, которая обсуждалась выше.
