Comments 61
Очень заинтересован в подобной информации. Особенно было бы интересно услышать о решениях без ВПН =)
Без впн можно, просто пропускаете пункт с настройкой PPTPD и везде заменяете сеть 10.1.0.0/24 на вашу локальную.
не в тему, но если нужно NAT'ить VPN трафик, то не забудьте сделать:

/sbin/modprobe ip_nat_pptp
Мне вот тоже интересно, особенно было бы интересно услышать о решениях без vpn, и с авторизацией через Active Directory. =) Заранее спасибо, всенепременнейше ждём. =)
Огромное спасибо! :) Добавлю в закладки, чуть позже точно пригодится.
Несколько замечаний по поводу mysql и perl

1)Для мускля. inet_aton('123.124.123.123') сохраняем ипишник как int usnigned
2)Делаем таблицу data
traf_date DATE, from_ip INT UNSIGNED, to_ip INT UNSIGNED, traf INT UNSIGNED. индекс по всем полям кроме traf
Сюда не нужно складывать ид пользователя. Пуской он живет в отдельной таблице.
3)Грузим данные через LOAD DATA INFILE в темповую таблицу от туда INSERT INTO… ON DUPLICATE KEY UPDATE traf+VALUES(traf).
4)Опционально создаем еще одну табличку где просто дата, ип пользователя и кол-во трафика. Так как это будет самый востребованный отчет.
1) я патчил ulog-acctd для вывода айпи сразу в десятичной форме, прирост производительности был довольно существенный. Не стал пока рассматривать, чтобы не захламлять статью.

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

3) Спасибо за идею, думаю, попробую :)
4) Честно говоря, не вижу в этом смысла. Любые отчеты можно вытащить из data.
2) Там только инт поля + одно с датой, кроме этого в течении дня у нас данные по направлению суммируются. Даже с парой миллионов запесей такая таблица будет небольшая. Тем более хранить вряд ли актуально данные больше чем на месяц.

4) Только за какое время :) использование sum(blabla) с GROUP BY не использует индекс. То есть сначала по условиям в where будет создана таблица потом по ней будет filesort
Отличный пост. Понравилось. Пиши ещё и подробнее, информация действительно очень полезна для начинающих.
Есть ли варианты отброса парсера логов и напрямую с ulog кидать статистику в MySQL?
Есть, AFAIK, такое умеет ulogd, но объем базы уже через сутки будет космическим, к тому же записывать каждую запись в БД довольно накладно по производительности.
Т. е. гибкой настройки легирования не добиться? Я не имел опыта работы с ulogd, интересны минусы и плюсы.
минусы — объем базы. ulogd нужен только для анализа атак и invalid packets.
Не знаю деталей лога, но думаю при помощи тригера возможно отсеять мусор.
Ну если делать тупо INSERT каждый раз, то да. а если граматно UPDATE организовать, то объемы не такие будут :)
в принципе — да

ulogd-mysql — MySQL extension to ulogd
ulogd-pgsql — PostgreSQL extension to ulogd
ulogd-sqlite3 — SQLite 3 extension to ulogd

Но это дело логи просто напрямую в базу пишет.
Всем спасибо, оказывается такая штука существует:

# aptitude search ulog
p fprobe-ulog — export captured traffic to remote NetFlow Collector (ULOG version)
p ulog-acctd — Accounting daemon for Linux 2.4+ netfilter
p ulogd — The Netfilter Userspace Logging Daemon
p ulogd-mysql — MySQL extension to ulogd
p ulogd-pcap — pcap extension to ulogd
p ulogd-pgsql — PostgreSQL extension to ulogd
p ulogd-sqlite3 — SQLite 3 extension to ulogd
Штука существует, но она крайне неполезна. При более-менее существенном объеме трафика биллинг благополучно умрет. Лучше формировать из ULOG netflow-поток, который затем и складывать в базу. А еще лучше, если база и сервер доступа будут жить на разных машинах.
я бы заменил мускул на постгрес, тем более что есть пакеть ulog-pgsql.
Тем более, что в постгресе есть специальный тип данных для адресов и там очень удобно потом делать детализацию по направлениям — трафик внутри сети провайдера, трафик внешний.

Где-то у меня даже валялась схемка такой базы (с активным использование хранимых процедур для автоматизации работы) и скрипт для создания итоговых значений по дням с удалением детализации каждого пакета (точнее скрипт просто дергал хранимки.)
Спорный вопрос, что будет быстрее, парсер или хранимки постгреса.
скажем так —
20 пользователей. Машинка семпрон 2200+ (еще которая на сокете А), полгига оперативки. Помимо всего прочего файлопомойка с кучей одинэсных баз.
Нагрузки от прогона хранимок была не больше 5% ресурсов процессора. И то я тогда стормозил и с индексами не заморачивался.
Часто на сервере уже используется мускул для других целей, специально ставить еще и постгрес нет желания
а если необходимо сделать это в масштабе офиса с виндовыми машиными чтоб авторизация шла через samba AD и на выходе биллинга трафик разделялся и считался по типам сетей (бесплатные-городские-внешние) можете такую инструкцию написать?
Прикрутите к PPTPD Freeradius, а к нему — авторизацию в домене (не знаю, возможно ли). Детализацию трафика по типа сетей озвучу в следующей статье.
да, действительно. Радиус, кибериос-авторизацию и для удобства сразу netams ;-)
я кстати не понимаю, для чего писать статьи для систем, у которых вполне таки внятная документация?

Единственный минус — у такого рода систем достаточно высокий порог вхождения, и они предназначены явно не для той целевой аудитории, для которой была написана эта статья.
кто знает готовую софтину для анализа этих логов? с рисованием графиков и воборкой временных интервалов?
да, можно и самому написать, но боюсь, что придется свой велосипед изобретать.
Статья простая и хорошая — вот хорошо было бы с нее начать цикл статей, в котором модернизировать решение по функциональности и скорости.
Все отлично, но вкралась опечатка в последнем слове: «Сохраним скрипт скрипт как /usr/bin/ulog-parser.pl и установим атриьуты:»
Спасибо за статью. Интересно. С нетерпением жду продолжения.

Было бы неплохо осветить такие моменты:
1. Использование cacti, а еще лучше кастомный скриптик на rrdtool для визуальной отрисовки загрузки общего канала, а также загрузки каждой пользовательской машины.
2. Оповещение по email при наличии подозрительного исходящего трафика на одной из пользовательских машин (такая активность бывает когда юзверь подхватил какойнть вирь или червь, очень удобно для админа)
3. открытие/закрытие определенных сервисов для всех сразу и для определенного юзера в часности (smpt, pop3, ftp, torrent и т. п.)
4. Проброс портов для возможности доступа извне на внутреннюю пользовательскую машину.
Цель статьи — не создание «велосипеда», а разъяснение принципов работы этих самых велосипедов на конкретном примере.

П. С.: раз уж на то пошло, то мой «велосипед» назывался SubBilling, я его года полтора назад пустил в «свободное плаванье», люди подхватили, правили баги, дополняли. Ссылку дать не могу, т. к. «официальный сайт» раз 5 переезжал и сейчас вообще непонятно где.
Ваш велосипед плох тем, что использует не самые лучшие колеса. Использование ulog это не сильно хорошая идея. Оно конечно есть, но лучше не использовать. Лучше использовать ipcad и собственно любые другие шутки которые учитывают трафик не через firewall а при помощи libpcap или при помощи счетчиков на интерфейсе (pppd имею ввиду) или с netflow. Это исключает проблему не попадания трафика в учет.
У ipcad точно такой же формат вывода лога, прикрутить его вместо ulog'a не составляет проблемы.
ipcad позволяет снимать трафик с помощью нескольких разных методов, в т. ч. и ULOG.

А использовать ULOG можно только если трафик небольшой. Когда-то несколько лет назад и я писал свой велосипед :) Так вот на больших загрузках ULOG начинал нещадно врать в меньшую сторону на радость клиентам-халявщикам. В итоге перешел на IPQueue и все стало ок.
Классная статья, для новичков типо меня очень полезна. Планирую опробовать на днях.
Да, статья полезная. Спасибо автору.
Хотелось бы так же почитать, каким образом можно лимитировать трафик пользователей в определенный отрезок времени (день/месяц).
Некоторые замечания

>iptables -A INPUT -s 192.168.0.0/24 -p tcp -m state --state NEW -m tcp --dport 1723 -j ACCEPT

пакеты в цепочке INPUT, насколько я помню, имеют state NEW по-умолчанию. Можно сократить до:
iptables -A INPUT -s 192.168.0.0/24 -p gre -j ACCEPT
{-p gre} = {-p tcp --dport 1723}

>iptables -t nat -A POSTROUTING -s 10.1.0.0/24 -j MASQUERADE
Маскарад не всегда гибкое решение. Ибо гонит траф в дефолтный интерфейс

Жизненный вариант:
iptables -t nat -A POSTROUTING -s 10.1.0.0/24 -o eth0 -j SNAT --to xxx.xxx.xxx.xxx
(тут eth0 — интерфейс в интеренет, а xxx.xxx.xxx.xxx его адрес. Иногда бывает несколько ip на внешнем интерфейсе, тут можно выбрать от какого будут юзеры ходить наружу)

И еще по моему стоило бы добавить:
iptables -A FORWARD -i ppp+ -s 10.1.0.0/24 -j ACCEPT
И если у вас этого не было
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
если автор собирается продолжить тему (а тема очень актуальна, спасибо)
хотелось бы, простого мануала с примерами «как грамотно настроить шейпер»:
1. как правильно разделить трафик по приоритетам с помощью iproute2 т. е в первую очередь пускать пакеты с DNS, открывающие и закрывающие tcp соединения, потом http, а затем уже фтп и пиринг
2. как настроить шейпер htb (желательно, что б он делил канал динамически в зависимости от подключенных пользователей: т. е. сидит 1 чел. — канал весь его, 2 чел, канал делиться пополам, но при этом не по кол-ву сессий, а по ip, потому что пользователь может поставить на закачку торент и при этом еще серфить)
3. как настроить авторизацию и самый простой учет трафика для небольшой сети 5-10 машин
При установке на Ubuntu из родных репозиториев, в account.log пишется следующая строчка:

*** invalid %N$ use detected ***

Решением проблемы является установка формата вывода вида:

accountingformat="%h\t%t\t%p\t%s\t%S\t%d\t%D\t%P\t%b\t\"%i\"\t\"%o\"\t\"%f\"\t%x\n"

Но если такой вариант Вас не устраивает и вы хотите установить формат, указанный в статье или свой, то необходимо установить ulog-acctd из deb пакета со страницы Debian Packages.
Only those users with full accounts are able to leave comments. Log in, please.