Подсчёт трафика в Linux

[Rezedent12]

  Я хочу написать собственную биллинговую систему для Linux шлюза. Поскольку на C++ я не пишу, а пишу на FreeBasic... Есть ли у кого нить из вас модуль который бы перехватывал заголовки IP пакетов и транслировал бы клиенту на TCP порт или локльный сокет.
  Примерно в таком формате: "Куда, откуда, размер пакета"
  То что будет накодено выложу в сеть под лицензией GNU.

Жду советов и консультаций.

[Sel]

Вот и выложи, что уже "накодил".

[RXL]

Библиотека libpcap. Для винды ее порт - winpcap.

Стоит ли создавать велосипед? Подобные системы давно существуют. Лет 10-11 назад я наблюдал, как один из подобных проектов только вышел в релиз. За такой период не могли не доделать.

[Dimka]

Rezedent12, это приглашение к сотрудничеству в проекте открытого ПО или просто частный вопрос по сетям: как реализовать перехват трафика с целью его контроля?

Во втором случае я перемещу тему в раздел "Сети", где её быстрее заметят разбирающиеся в этом люди.

RXL, может он для себя хочет, чтобы разобраться, отработать свои навыки программирования.

[Rezedent12]

Это приглашение к сотрудничеству с целью создания свободного ПО. Проект некомерческий, но нужно мне это для полукоммерчиских целей. А ещё и попрактиковатся в программировании. В общем, преследую кучу целей.

Чтоб было понятно, что я хочу именно реализовать. Приведу рисунок: http://imageshost.ru/links/3af1ceac810c9d351a69897af2e83acb

ПО, которое я хочу разработать, нужно для шлюзов.

Планируется, что со временем в такой сети будет около 50 хостов. ПрименятЬся будут не только беспроводные каналы.

[Dimka]

Прежде, чем запрашивать модуль, хорошо бы чётко определить требования к нему.

Вот у тебя написано, что каждый пользователь авторизуется, чтобы получить трафик. На уровне протокола IP нет никаких пользователей, есть только адреса точек подключений. Если мне правильно показалось, модуль перехвата трафика в конечном счёте должен быть полезен именно для контроля трафика в разрезе пользователей. Поэтому прежде, чем браться за перехват трафика и определять требования к этому модулю, нужно дать чёткий ответ, каким боком этот модуль увязывается с требованиями верхнего уровня, в которых говорится про пользователей.

Иначе может так получиться, что ты, провозившись с какой-то библиотекой, даже получишь перехват пакетов, а потом обнаружишь, что она не позволяет добиться того, что тебе на самом деле нужно. Архитектура решения первична, модули и библиотеки вторичны.

[Rezedent12]

Модуль простой. Запускается с правами root,  открывает сокет и отправляет на него данные о пакетах (кому, куда, размер), к нему подключается прога учёта трафика. Авторизация проходит через Https протокол, после авторизации программа привязывает IP к счёту пользователя и за каждый прошедший пакет вычитает значение лимита. Как только лимит исчерпан, то программа при помощи IpTables комманды перекрывает траффик в инет.
Программа учёта трафика - это моя забота, накодить её максимум месяц работы. Но чтоб приступить к разработке, надо найти такой модуль.

[Dimka]

Что значит "отправляет"? О каждом пакете отправляется пакет? Или статистика как-то аккумулируется и имеет периодичность? Если каждый пакет, то производительность не смущает? А линия часом не гигабитная?

Что значит отправляет в сокет, к которому подключается прога? А если прога не подключается, куда он что отправляет?

P.S. Требования, вообще говоря, хорошо бы делать полными, освещая все аспекты работы: функции, производительность, ресурсоёмкость, безопасность, расширяемость/перспективы развития, особенности сред исполнения и разработки.

[Rezedent12]

Тогда всё по порядку.

   Про требуемый модуль: Я пока не определился, как именно должен работать модуль, поэтому ещё и не написал ничего. Это зависит от того, как модуль будет реализован. В сокет программе отправляется информация о заголовках. Программа запускается на том же шлюзе (Обмен в пределах LocalHost) Если программа к нему не подключается, то и отправлять не надо.
   После подключения к модулю, он должен начать отправку информации о пакетах. Думаю, что 12 байт о каждом пакете - это не много |Откуда IP||Куда IP||Размер| переменные типа Long удобны для 32 разрядных процессоров.
   
Собственно о программе:
   По умолчанию в IpTables трафик закрыт для всех IP с внутренней сети. Клиент через http или https или Telnet или можно специальные программы для авторизации зашифрованным ключём сделать. В общем, соединяется с программой. Программа узнаёт клиента и его IP. В зависимости от состояния его счёта, разрешает или запрещает трафик с его IP во внешнею сеть. И определяет переменную лимита.
   О переменной лимита. В ней содержится максимальное количество байт, которые могут быть получены и переданы для данного IP , как только лимит исчерпывается, то канал закрывается при помощи всё той же многострадальной IpTables.
   При отсоединении пользователя: Не пингуется его IP, истёк лимит, сам закрыл соединение. Израсходованное округляется до мегабайта или 100 килобайт. Также во избежание финансовых убытков через каждый мегабайт списывается бабло. Также во избежание глюков с IP и авторизацией (DHCP работает сам по себе) можно использовать не IP адреса для привязки пользователя, а MAC адреса.

Для тех, кто, возможно, не совсем правильно понял: После авторизации программа знае,т какому пользователю принадлежит какой IP. А модулю это знать не надо, поскольку он только предоставляет данные о проходящих через шлюз пакетах.

[McZim]

Я пока не определился, как именно должен работать модуль, поэтому ещё и не написал ничего. Это зависит от того, как модуль будет реализован.

Прочти внимательно что написал, сам себе противоречишь.   

По умолчанию в IpTables трафик закрыт для всех IP с внутренней сети.

Это утверждение или так будет настроено для работы твоего ПО?

Клиент через http или https или Telnet или можно специальные проги для авторизации зашифрованным ключём сделать. В общем, соединяется с прогой. Прога узнаёт клиента и его IP. В зависимости от состояния его счёта, разрешает или запрещает трафик с его IP во внешнею сеть. И определяет переменную лимита.

О RADIUS слышал?

канал закрывается при помощи всё той же многострадальной IpTables.

Причем тут вообще iptables если ты кругом используешь сокеты?

[Dimka]

Я пока не определился, как именно должен работать модуль, поэтому ещё и не написал ничего.

Ну вот я, собственно, и сподвигаю определиться

Прога запускается на том же шлюзе (Обмен в пределах LocalHost) Если прога к нему не подключается, то и отправлять не надо.

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

|Откуда IP||Куда IP||Размер|

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

Кстати, программа будет подключаться к модулю в единственном экземпляре, или, быть может, будет несколько экземпляров?

Так же во избежании глюков с IP и авторизацией (DHCP работает сам по себе) можно использовать не IP адреса для привязки пользователя, а MAC адреса.

Вот это серьёзнейшее дело, затрагивающее структуру передаваемых данных от демона к программе, т.е. межпрограммный интерфейс. Тут нужна определённость.

Это утверждение или так будет настроено для работы твоего ПО?

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

О RADIUS слышал?

А это так принципиально?

Причем тут вообще iptables если ты кругом используешь сокеты?

Сокеты только для мониторинга и внутренних коммуникаций программного комплекса, а управление трафиком через iptables. Перечитай внимательнее.

[Антон (LogRus)]

есть такая вещь DCCA - http://en.wikipedia.org/wiki/Diameter_Credit-Control_Application
это один из стандартных проколов взаимодействия.

небольшой сценарий взаимодействия систем с предоплатой трафика:
1. есть некая хрень которая умеет открывать и закрывать доступ или предоставлять доступ
2. другая хрень знает сколько денег/трафика или еще чего есть у абонента
3. это две совершенно разные вещи хотя и работают в тандеме (не путаем с аппаратной платформой HP NonStop)
4. клиент (абонент) обращается к софтине №1(не явно или явно): "Я такой-то такой-то, дай я подключусь к сети"
5. софтина №1: "погоди я проверю". далее выбрав одну из возможно нескольких софтин №2 обращается к ней: "Вот такой абонент, не твой случаем? Хочет проключиться на такой-то сервис, сколько ему можно предоставить ресурсов?"
6. софтина №2: "Абонент мой, проключай, трафик 100 мег (это не значит что у него денег на 100 мег, может их на 10000 мег, просто мы доверяем абону не более чем нужно, во избежание фрода), НО переспроси у меня остаток через 30 минут, вдруг он успеет свустить деньги на другие сервисы или тариф сменит"
7. софтина №1: "понятно, проключаю" далее она следит за расходом трафика и за 10% до исчерпания или через 29 минут (опять же во избежание фрода) переспросит у софтины №2 о доступных средствах.
8. не забываем про таймауты: в идеале запрос разрешения и получение доступа должен проходить за 0.1 секунды (на самом деле 1 секунда всех устроит)
9. также помним, что нужно вести базу абонентов, тарифов, логи списания средств, платежей и т.д. и т.п

Rezedent12, надеюсь желание реализовать эту хрень за месяц у тебя пропало.

[McZim]

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

Меня интересует ответ автора. Это утверждение или так нужно для него?

А это так принципиально?

Ага, зачем очередной велосипед?

Сокеты только для мониторинга и внутренних коммуникаций программного комплекса, а управление трафиком через iptables. Перечитай внимательнее.

Ну ради бога конечно, ИМХО, ничего нового, ничего интересного. Вот если интегрироваться в iptables и указав там правила подобные, по структуре, на iptables, управлять поведением этой прогой это более интересно.

Советую автору почитать о реализации Биллинг систем, хотя бы поверхностно.

[RXL]

По хорошему, лучше использовать VPN (pppoe и т.п., базирующиеся на ppp, протоколы), чем такую экзотическую авторизацию. Пользователям удобнее будет.

[Sla]

McZim, он же написал

А ещё и попрактиковатся в программировании. В общем, преследую кучу целей.

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

[McZim]

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

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

[Rezedent12]

Я чувствую, что капитально загружен....

Но чтоб было яснее... Модуль предоставляет программе информацию о проходящем трафике, программа рулит управляет трафиком при помощи IpTables (Да будь она проклята )

Всё... просто, как валенок. Алгоритмы программы и её концепт есть в уме, если хотите, то выложу общий алгоритм....

[McZim]

Rezedent12, валенок не так просто как ты думаешь, что бы сделать хороший валенок, нужно постраться, да и потом даже у самого хорошего валенка есть минусы.

[Rezedent12]

Алгоритм:

Const X = лимит пользователей

Dim Users (1 to X) as string*10 'Логины пользователей
Dim Limit (1 to X) as long 'Лимит трафика
Dim IP (1 to X) as string*15 ' IP пользователя 123/567/9(10)(11)/(13)(14)(15)
Dim MAC (1 to X) as string ' MAC адреса сетевух (в Бета версии не используется)

Главная процедура()

 -Соеденится с модулем, если ошибка то запустить его и повторить
 -После соединения закрыть трафик ' На всякий случай мало ли, вдруг админ забыл по умолчанию закрыть
 -Call Подсчёт

Конец()

Это конечно лишь эскиз общего алгоритма с базовыми возможностями


Процедура Подсчёт()

-Бесконечный цикл.

 -Ждать пакета от модуля или сигнала завершения программы, если такой есть то выйти из цикла.
 -Выбрать из пакета IPfrom, IPto, SizeBytes
 'IPfrom - откуда
 'IPto - куда
 'SizeBytes - Размер пакета
 -Если пакет идёт во внешнею сеть то вычесть его размер из лимита.
 -Через каждый мегабайт обновлять сведенья о его счёте в текстовом файле или базе данных.
 -Если лимит исчерпан то закрыть трафик
 
-Конец бесконечного цикла

Конец()


Событие Авторизация клиента()
 'Клиент уже авторизовался с помощью Web интерфейса или специальной проги
 -Найти в массиве Users() Пустое значение A
 -По данным из тестового файла или бызы данных установить лимит(не хочу на этапе бета версии заморачиватся с SQL) пользователю(A)
 -Установить его IP адрес и Mac адрес
 -Если лимит положительный то разрешить трафик
 
Конец события()


Событие Отключение клиента()
' Событие наступет если клиент сам даёт команду на интерфейсе авторизации
' или истекает лимит или на указаном IP меняется MAC адрес (В бета версии по
' MAC проверку не реализовывать, другие проблеммы есть)

 -Закрыть доступ
 -Округлить трафик
 -Записать в базу или текстовый файл
 -Очистить в массивах поля клиента
 -Записать событие в *.LOG

Конец события()

[Антон (LogRus)]

Всё... просто как валенок.

раскажи это сотрудникам
Alcatel
или Huawei

для поделки просто
для нормального решения нет

[Rezedent12]

И чем же это не нормальное решение? (Кроме авторизации по WEB)

[Dimka]

Слушайте, чего вы пристали к человеку и тыкаете его в разные уже имеющиеся решения? Не для вас пишет, для себя зачем-то. Преимущество того, чего он описал - простота и реализуемость малой кровью. В конце концов, ему надо - он в данном случае "заказчик" и имеет полное право сделать так, как хочет.

Наша помощь тут - лишь показать ограничения такого подхода к решению задачи. Вот плавно соберём полные требования - картина прояснится и у него самого. Тогда будет видно, сможет ли такое решение работать в конкретной сетевой конфигурации для конкретных 50-и компов (как заявлено автором), либо затея заранее обречена. А все эти декларации про GNU - будет одно из многочисленных решение "as is" - не нравится, не пользуйтесь, никто не заставляет.

[Антон (LogRus)]

Dimka, согласен.

по делу.
Пункт номер один: подсчёт трафика.
http://www.opennet.ru/base/net/ulog_traf.txt.html
http://www.linuxcenter.ru/lib/articles/networking/squid_sarg_traf.phtml
http://asplinux.net/node/3049
http://netams.com/
http://alldebian.ru/nat-podschet-trafika
и еще дофига всего по запросу: подсчёт трафика в поисковике.
+ аппаратные решения, но я так понимаю, не наш случай

Пункт 2: передача результатов в софтину.
тут нужно определиться с тем, какая латентность доставки информации о трафике тебя устроит
1 секунда, 5 секунд, минута
в одном случае тебе пойдёт модуль ядра передающий данные в user-space
в другом сойдёт и парсинг логов

Пункт 3: Управление iptables.
я бы поискал возможность управления в обход вызова iptables, например, через /proc или что-нибуть эдакое

Пункт 4: Идентификация.
в идеале сделать её не явной, т.е. при обнаружении пакета от нового пользователя производить идентификацию и выделение квоты,
но сойдёт и любой другой способ, я полагаю

Пункт 5: абонентские данные.
MySQL, но лучше иметь систему плагинов для работы с разными хранилищами (MySQL, Postgres, Oracle, DB2, plain text).

[Rezedent12]

Рад, что наконец-то начали понимать, что я хочу достичь целей малой кровью. Dimka, вы наверное неправильно поняли, хостов в сети будет около 50 (посмотрите на рисунок http://imageshost.ru/links/3af1ceac810c9d351a69897af2e83acb ). А клиентов, подключаемых к одному хосту, никак не будет больше 20, хотя бы потому, что на практике 20 Мбит/с практическая скорость Wi-Fi. Сеть не только для Интернет, а ещё и для локального обмена.

Примечание: Парсинг логов на i486 не лучшее занятие. Я читал про эту технологию, некоторые провайдеры просто отправляют весь трафик в Log потоком и читают его оттуда. Такое решение в корне неприемлЕмо. Нужно всего лишь |Откуда||Куда||Размер| такой поток данных. Простите, что излишний раз повторяюсь.

[Dimka]

Rezedent12, на свои вопросы, заданные в 10-м сообщении, я пока ответов не получил.

Появился новый вопрос, связанный с MAC: все хосты находятся в одном сегменте (т.е. нет никаких хостов, которые осуществляют выход через разные шлюзы (маршрутизаторы, NAT и т.п.)? Если это не так, то MAC-адреса нельзя будет использовать. Кроме того, MAC адреса используются во фреймах Ethernet, а IP-адреса - в пакетах одноимённого протокола. В общем случае соответствия между фреймами и пакетами нет. Ethernet трафик превышает по объёму IP трафик, так как передаёт IP пакеты в качестве данных внутри своих фреймов. По какому правилу будет устанавливаться соответствие Ethernet и IP трафика, чтобы адресацию брать у первого, а объём считать у второго?

[Антон (LogRus)]

Такое решение в корне не приемлимо. Нужно всего лишь |Откуда||Куда||Размер| такой поток данных.

а ты прочел, как работает ulog? 

[Dimka]

LogRus, спокойствие, только спокойствие Мы ещё даже требования не собрали Как соберём полные, тогда и будем всякими ulog'ами кидаться, если они удовлетворят

В данном случае автор попытался как-то примерно обозначить проблему производительности Плюс здесь в том, что проблему он видит, минус в том, как именно он её видит

[Антон (LogRus)]

Dimka, я спокоен. Я непоколебимая глыба.

premature optimization - корень всех зол

[Алексей++]

LogRus, спокойствие, только спокойствие

Offtopic:

Поставлю в угол.

[Rezedent12]

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

Ulog - это патч к ядру.. Касаемо пересборки ядра я не мастер и никогда этим не занимался. Я конечно вас понимаю, вы ламерство не поощряете и я не считаю что я знаю всё что надо. Но изначальная цель сделать простое с точки зрения пользователя средство. Чтоб запустил файл и всё заработало.

Касаемо вопроса про MAC и IP. Прочитайте внимательнее алгоритм и рассмотрите схему. Пожалуйста. Авторизация происходит на хосте и только после этого пакеты попадают в кольцо интрасети или интернет. Систему роуминга между хостами можно будет написать позже. Никакой связи с хостом через хост... Таким образом проблема о которой вы говорите не существует. (Спасибо модератору за склейку сообщения)