- PVSM.RU - https://www.pvsm.ru -
Когда-то давно, в далекой далекой галактике…Хотя если подумать, это было всего то 15 лет назад.
В общем были времена, когда в качестве центрального шлюза в сеть Интернет использовались решения на базе FreeBSD и Linux. И были эти решения любовно настроены, и обвешивались они всеми возможными и невозможными функциями (от межсетевого экрана и VPN серверов до TFTP+PXE-сервисов бездисковой загрузки)…и не было беды, и все было хорошо…
Но времена меняются, появляются новые решения, появляются компании, которые «дешево и сердито» готовят ядро Linux, обвешивают необходимым функционалом и продают это за весьма скромные деньги (сопоставимые со стоимостью аппаратной части).
Примером таких решения является компания Mikrotik и ее одноименные решения.
Итого текущая ситуация – купить и поставить Mikrotik в организацию, в которой от 10 до 5000 компьютеров, быстрее и экономичнее, чем брать «очередной системник» и собирать шлюз по частям (сетевухи, софт, сервисы и т.д.).
При этом задачи учета трафика как были, так и остаются. И тут на помощь приходит рядом стоящий сервер (обычно это NAS на базе Linux или FreeBSD).
Учет WEB-трафика прост и понятен – связка Squid + LightSquid позволяет просто и быстро собирать и агрегировать информации о том, кто какие сайты посещает, какие файлы качает и сколько в Youtube-е зависает. При необходимости можно и ограничить сайты, время и т.д. Простое, удобное решение, проверенное годами. В Mikrotik делается одно правило, выпускающее IP прокси-сервера в интернет. И все счастливы.
Но вот проблема – не все успешно проходит через Squid. Есть банк-клиенты, написанные без поддержки HTTP и Socks прокси. Есть сложные программы, которые для разных типов трафика используют разные соединения – итог – либо плохо работают через Proxy, либо вообще не работают. А есть отдельная категория так называемых VIP-персон…которым проще дать «Full NAT», чем обострять отношения, когда «что-то у них не открывается».
Таким образом, в Mikrotik рано или поздно, но будут появляться отдельные правила, выпускающие «особенных» напрямую через NAT, минуя прокси-сервер. И их трафик мы в статистике уже не видим.
Решение по учету такого трафика напрашивается следующее:
Для удобного анализа получаемых на NAS-сервере файлов, данное решение предлагается улучшить с помощью пары самописных скриптов:
Все просто и по документации:
/ip traffic-flow
set enabled=yes interfaces=WAN
/ip traffic-flow target
add dst-address= port=8787 v9-template-timeout=1m version=5
# Установка NetFlow сенсора:
pkg install flow-tools
# Настройка запуска:
echo 'flow_capture_enable="YES"' >> /etc/rc.conf.local
echo 'flow_capture_flags="-N-2"' >> /etc/rc.conf.local
# Запуск:
service flow_capture start
# Установим, запустим и настроим MySQL сервер:
pkg install mysql56-server
# Запуск службы
echo 'mysql_enable="YES"' >> /etc/rc.conf
service mysql start
# Начальная настройка СУБД:
mysql_secure_installation
# Установим Perl-модули для работы скрипта с СУБД:
pkg install p5-DBI p5-DBD-mysql
# Входим в СУБД и создаем базу и пользователя для работы с ней:
mysql -u root -p
# Создаем СУБД и пользователя:
mysql> create database netflow;
mysql> grant insert,create,update,select,delete on netflow.* to nfuser@'localhost' identified by '987654321';
mysql> flush privileges;
mysql> exit;
Скрипт был написан не с нуля – когда то давно, в 2005-м году на сайте OpenNET была выложена статья (ссылка [1]) о подсчете трафика на шлюзе FreeBSD с использованием NetGraph модуля ng_ipacct.
Скрипт загрузки был взят за основу и переписан на использование с NetFlow и flow-tools. Работает как на FreeBSD, так и на Linux (только пути переписать до программ flow-cat и flow-print).
Особенности скрипта – данный вариант предназначен для анализа всех ft-* файлов за прошедшие сутки и их загрузки в базу (построчно). При этом реализовано исключение строк по нескольким шаблонам, чтобы не грузить в MySQL избыточную информацию (например, исключить широковещательный трафик, трафик DNS-запросов, трафик с HTTP/Socks прокси (благо статистика по прокси есть в другом месте). По моим замерам, исключение позволяет сократить количество загружаемых в СУБД строк в 10, а то и в 20-30 раз.
Таблицы в СУБД создаются автоматически с началом нового месяца. К стандартному NetFlow v5 формату добавляется день, время записи (используется время создаваемых ft-файлов – например, каждые 15 минут), также указывается имя источника NetFlow и имя сетевого интерфейса.
В далеком 2005-м, когда использовались Perl-скрипты автора, для анализа данных в MySQL мы использовали SQL команды…и все всех устраивало.
Но рано или поздно настал момент, когда вводить запросы надоело. И, собравшись с мыслями, был написал небольшой PHP-код, который позволял проводить построение SQL-запросов более быстрым и простым способом.
Внешний вид:

Что позволяет сделать скрипт:
PS: Владелец файла netflow.php должен быть пользователь Web-сервера (например, Apache).
PSS: Доступ к СУБД указан в файле netflow.php явно – так что измените под себя.
Если таблицы получаются довольно большие (хотя никто Вам не мешает грузить в СУБД только то, что Вам нужно, исключая «шлак» и уменьшая размер), то есть интересный прием, позволяющий существенно уменьшить размер СУБД. Речь идет об использовании компрессии БД в формате MyISAM, а также об оптимизации индекса.
Для автоматического выполнения этих процедур был написан еще один Perl-скрипт, который первого числа каждого нового месяца запускается через Cron:
Итого после выполнения скрипта данная таблица станет ReadOnly, будет сжата (размер уменьшиться раза в 3), и будет построен новый отсортированный и оптимизированный индекс. Запросы в такую таблицу будут выполняться быстрее.
Все скрипты можно скачать по ссылке [2].
Автор: Егор Вершинин
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/php-2/279229
Ссылки в тексте:
[1] ссылка: https://www.opennet.ru/base/net/ng_billing_letter.txt.html
[2] ссылке: https://yadi.sk/d/uGdsIx3G3V5UA4
[3] Источник: https://habr.com/post/354720/?utm_source=habrahabr&utm_medium=rss&utm_campaign=354720
Нажмите здесь для печати.