Комментарии 61
Очень заинтересован в подобной информации. Особенно было бы интересно услышать о решениях без ВПН =)
Без впн можно, просто пропускаете пункт с настройкой PPTPD и везде заменяете сеть 10.1.0.0/24 на вашу локальную.
не в тему, но если нужно NAT'ить VPN трафик, то не забудьте сделать:
/sbin/modprobe ip_nat_pptp
/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)Для мускля. 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) дело в том, что если хранить from_ip и to_ip в базе, то она довольно быстро разрастается до неприличных размеров, особенно, если пользователей под сотню, думаю, достаточно преопределить интересующие направления в отдельной таблице и группировать трафик по ним. Напишу в следующей статье.
3) Спасибо за идею, думаю, попробую :)
4) Честно говоря, не вижу в этом смысла. Любые отчеты можно вытащить из data.
2) Там только инт поля + одно с датой, кроме этого в течении дня у нас данные по направлению суммируются. Даже с парой миллионов запесей такая таблица будет небольшая. Тем более хранить вряд ли актуально данные больше чем на месяц.
4) Только за какое время :) использование sum(blabla) с GROUP BY не использует индекс. То есть сначала по условиям в where будет создана таблица потом по ней будет filesort
4) Только за какое время :) использование sum(blabla) с GROUP BY не использует индекс. То есть сначала по условиям в where будет создана таблица потом по ней будет filesort
Перенес в «Linux для всех»
Жду продолжения с нетерпением
Отличный пост. Понравилось. Пиши ещё и подробнее, информация действительно очень полезна для начинающих.
Есть ли варианты отброса парсера логов и напрямую с ulog кидать статистику в MySQL?
Есть, AFAIK, такое умеет ulogd, но объем базы уже через сутки будет космическим, к тому же записывать каждую запись в БД довольно накладно по производительности.
в принципе — да
ulogd-mysql — MySQL extension to ulogd
ulogd-pgsql — PostgreSQL extension to ulogd
ulogd-sqlite3 — SQLite 3 extension to ulogd
Но это дело логи просто напрямую в базу пишет.
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
# 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-pgsql.
Тем более, что в постгресе есть специальный тип данных для адресов и там очень удобно потом делать детализацию по направлениям — трафик внутри сети провайдера, трафик внешний.
Где-то у меня даже валялась схемка такой базы (с активным использование хранимых процедур для автоматизации работы) и скрипт для создания итоговых значений по дням с удалением детализации каждого пакета (точнее скрипт просто дергал хранимки.)
Тем более, что в постгресе есть специальный тип данных для адресов и там очень удобно потом делать детализацию по направлениям — трафик внутри сети провайдера, трафик внешний.
Где-то у меня даже валялась схемка такой базы (с активным использование хранимых процедур для автоматизации работы) и скрипт для создания итоговых значений по дням с удалением детализации каждого пакета (точнее скрипт просто дергал хранимки.)
Спорный вопрос, что будет быстрее, парсер или хранимки постгреса.
скажем так —
20 пользователей. Машинка семпрон 2200+ (еще которая на сокете А), полгига оперативки. Помимо всего прочего файлопомойка с кучей одинэсных баз.
Нагрузки от прогона хранимок была не больше 5% ресурсов процессора. И то я тогда стормозил и с индексами не заморачивался.
20 пользователей. Машинка семпрон 2200+ (еще которая на сокете А), полгига оперативки. Помимо всего прочего файлопомойка с кучей одинэсных баз.
Нагрузки от прогона хранимок была не больше 5% ресурсов процессора. И то я тогда стормозил и с индексами не заморачивался.
Часто на сервере уже используется мускул для других целей, специально ставить еще и постгрес нет желания
Отличная статья!
а если необходимо сделать это в масштабе офиса с виндовыми машиными чтоб авторизация шла через samba AD и на выходе биллинга трафик разделялся и считался по типам сетей (бесплатные-городские-внешние) можете такую инструкцию написать?
кто знает готовую софтину для анализа этих логов? с рисованием графиков и воборкой временных интервалов?
да, можно и самому написать, но боюсь, что придется свой велосипед изобретать.
да, можно и самому написать, но боюсь, что придется свой велосипед изобретать.
Статья простая и хорошая — вот хорошо было бы с нее начать цикл статей, в котором модернизировать решение по функциональности и скорости.
Все отлично, но вкралась опечатка в последнем слове: «Сохраним скрипт скрипт как /usr/bin/ulog-parser.pl и установим атриьуты:»
Спасибо за статью. Интересно. С нетерпением жду продолжения.
Было бы неплохо осветить такие моменты:
1. Использование cacti, а еще лучше кастомный скриптик на rrdtool для визуальной отрисовки загрузки общего канала, а также загрузки каждой пользовательской машины.
2. Оповещение по email при наличии подозрительного исходящего трафика на одной из пользовательских машин (такая активность бывает когда юзверь подхватил какойнть вирь или червь, очень удобно для админа)
3. открытие/закрытие определенных сервисов для всех сразу и для определенного юзера в часности (smpt, pop3, ftp, torrent и т. п.)
4. Проброс портов для возможности доступа извне на внутреннюю пользовательскую машину.
Было бы неплохо осветить такие моменты:
1. Использование cacti, а еще лучше кастомный скриптик на rrdtool для визуальной отрисовки загрузки общего канала, а также загрузки каждой пользовательской машины.
2. Оповещение по email при наличии подозрительного исходящего трафика на одной из пользовательских машин (такая активность бывает когда юзверь подхватил какойнть вирь или червь, очень удобно для админа)
3. открытие/закрытие определенных сервисов для всех сразу и для определенного юзера в часности (smpt, pop3, ftp, torrent и т. п.)
4. Проброс портов для возможности доступа извне на внутреннюю пользовательскую машину.
спасибо
Очередное изобретение велосипеда с квадратными колесами.
+1
согласен.
перечислите предыдущие велосипеды, пожалуйста.
перечислите предыдущие велосипеды, пожалуйста.
Мой личный велосипед:
code.google.com/p/cakebilling/
Я лично осуществлял порядка 5 установок. Работает на автопилоте уже пару лет там, пить есть не просит.
code.google.com/p/cakebilling/
Я лично осуществлял порядка 5 установок. Работает на автопилоте уже пару лет там, пить есть не просит.
Цель статьи — не создание «велосипеда», а разъяснение принципов работы этих самых велосипедов на конкретном примере.
П. С.: раз уж на то пошло, то мой «велосипед» назывался SubBilling, я его года полтора назад пустил в «свободное плаванье», люди подхватили, правили баги, дополняли. Ссылку дать не могу, т. к. «официальный сайт» раз 5 переезжал и сейчас вообще непонятно где.
П. С.: раз уж на то пошло, то мой «велосипед» назывался SubBilling, я его года полтора назад пустил в «свободное плаванье», люди подхватили, правили баги, дополняли. Ссылку дать не могу, т. к. «официальный сайт» раз 5 переезжал и сейчас вообще непонятно где.
Ваш велосипед плох тем, что использует не самые лучшие колеса. Использование ulog это не сильно хорошая идея. Оно конечно есть, но лучше не использовать. Лучше использовать ipcad и собственно любые другие шутки которые учитывают трафик не через firewall а при помощи libpcap или при помощи счетчиков на интерфейсе (pppd имею ввиду) или с netflow. Это исключает проблему не попадания трафика в учет.
У ipcad точно такой же формат вывода лога, прикрутить его вместо ulog'a не составляет проблемы.
ipcad позволяет снимать трафик с помощью нескольких разных методов, в т. ч. и ULOG.
А использовать ULOG можно только если трафик небольшой. Когда-то несколько лет назад и я писал свой велосипед :) Так вот на больших загрузках ULOG начинал нещадно врать в меньшую сторону на радость клиентам-халявщикам. В итоге перешел на IPQueue и все стало ок.
А использовать 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
>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
flow-tools рулит
в какойто момент хватает SAMS
если автор собирается продолжить тему (а тема очень актуальна, спасибо)
хотелось бы, простого мануала с примерами «как грамотно настроить шейпер»:
1. как правильно разделить трафик по приоритетам с помощью iproute2 т. е в первую очередь пускать пакеты с DNS, открывающие и закрывающие tcp соединения, потом http, а затем уже фтп и пиринг
2. как настроить шейпер htb (желательно, что б он делил канал динамически в зависимости от подключенных пользователей: т. е. сидит 1 чел. — канал весь его, 2 чел, канал делиться пополам, но при этом не по кол-ву сессий, а по ip, потому что пользователь может поставить на закачку торент и при этом еще серфить)
3. как настроить авторизацию и самый простой учет трафика для небольшой сети 5-10 машин
хотелось бы, простого мануала с примерами «как грамотно настроить шейпер»:
1. как правильно разделить трафик по приоритетам с помощью iproute2 т. е в первую очередь пускать пакеты с DNS, открывающие и закрывающие tcp соединения, потом http, а затем уже фтп и пиринг
2. как настроить шейпер htb (желательно, что б он делил канал динамически в зависимости от подключенных пользователей: т. е. сидит 1 чел. — канал весь его, 2 чел, канал делиться пополам, но при этом не по кол-ву сессий, а по ip, потому что пользователь может поставить на закачку торент и при этом еще серфить)
3. как настроить авторизацию и самый простой учет трафика для небольшой сети 5-10 машин
Тоже как-то такую штуку писал, если кому-то интересно можно посмотреть здесь http://sourceforge.net/projects/usimstat/. Все вполне работоспособно, но нет документации пока что :)
Не пойму, почему в account.log ничего не пишется :(
При установке на 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.
*** 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.
Карма не позволяет ссылку вставить.)
packages.debian.org/ru/sid/ulog-acctd
packages.debian.org/ru/sid/ulog-acctd
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рулим трафиком в Linux. Аккаунтинг, сбор статистики