В продолжении темы о ядерной подсистеме графов Netgraph FreeBSD Netgraph на примере Ethernet тоннеля попробуем посчитать трафик используя протокол Сisco netflow.

В прошлом обзоре мы познакомились с модулями ng_bridge, ng_ether и ng_ksocket и построили на их базе Ethernet тоннель через интернет, а сегодня я расскажу как, используя дополнительные модули netgraph, посчитать трафик, проходящий по этому тоннелю.

По вопросу статистики в общем, и netflow в частности, есть довольно много довольно обширных статей (изучение которых требует приличного времени). Здесь я приведу свои скрипты as-is для не очень сложного ТЗ по сбору и отправке месячной статистики арендаторам.

Вводная

Несколько арендаторов получают интернет через NAT (сам NAT завязан через policy-routing на двух провайдеров). У каждого арендатора свой вилан. Вилан «разворачивается» в сеть арендатора через управляемый коммутатор. Каждому арендатору выдаётся свой сегмент локальной сети с запретом ходить в соседние сегменты.

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

Инструменты: используется netflow на циске, flow-tools на линуксе, MTA, cron.

Последняя, заключительная статья цикла о том, как считаются ресурсы облака. Предыдущие: процессор, память, диски.

Учёт интернет-трафика, наверное, самая простая тема из всех. Сколько байт на сетевой интерфейс пришло — такой и входящий трафик. Сколько байт ушло — такой и исходящий.

Необычным, наверное, является только то, что учитывается трафик не на третьем (сетевом) уровне, а на втором (канальном). Никакого сакрального смысла выбор уровня не несёт, просто в используемой технологии наиболее точный и простой учёт осуществляется именно по числу байт, переданных на канальном уровне. С технической точки зрения это учёт переданных байтов через VIF (виртуальный сетевой интерфейс машины). Единственным неприятным побочным эффектом является то, что всякий служебный трафик, такой как исходящие бродкасты, ARP и т.д. так же учитывается. Но, с учётом стоимости трафика (10^-6 рубля за килобайт) я с трудом себе представляю, как можно служебным трафиком намотать хотя бы на копейку.

А положительным аспектом (для нас, а в каком-то смысле и для клиента) является то, что если клиент поднимает тяжёлое приложение на втором уровне (l2tp, PPPoE, ATAoE), то оно посчитается так же, как и любой другой L3 протокол, без необходимости «довить» на клиента и принуждать его к прекращению использования неудобного для учёта протокола, не укладывающегося в модель «считать по IP».

Любой администратор рано или поздно получает инструкцию от руководства: «посчитать, кто ходит в сеть, и сколько качает». Для провайдеров она дополняется задачами «пустить кого надо, взять оплату, ограничить доступ». Что считать? Как? Где? Отрывочных сведений много, они не структурированы. Избавим начинающего админа от утомительных поисков, снабдив его общими знаниями, и полезными ссылками на матчасть.
В данной статье я постараюсь описать принципы организации сбора, учёта и контроля трафика в сети. Мы рассмотрим проблематику вопроса, и перечислим возможные способы съема информации с сетевых устройств.

Общие сведения

• ipt-netflow — это самый быстрый netflow-сенсор (счётчик) для Линукса.
• Состоит из двух модулей: для ядра и для iptables.
• В стандартные ядро и iptables пока не входит — требует сборки из исходных текстов!
• Обсуждается включение в Debian — см. lists.debian.org/debian-mentors/2011/04/msg00070.html и bugs.debian.org/cgi-bin/bugreport.cgi?bug=620511

Файервол представляет из себя bash-скрипт, который интегрирует с помощью соответствующих пакетов следующие функции:

1. Файервол внешний и внутренний (пакет iptables).
2. Учёт трафика внешнего и внутреннего (пакет iptables).
3. Прокси-сервер для локальных сетей (пакет Squid).
4. Контент-фильтр для локальных сетей (пакет DansGuardian).
5. DNS-сервер для локальных сетей (пакет BIND).

Сегодня мы запускаем официальный блог на Хабре. Здесь не будет пресс-релизов и корпоративных новостей — для них есть официальный сайт. «Смарт-Софт» выпускает Traffic Inspector — популярное комплексное решение для организации, контроля и защиты интернет-доступа — и некоторое количество сопутствующих программ.

Разработка флагманского продукта началась в 2002 году, а сама компания основана 17 марта 2003 года. Днем ее рождения мы считаем дату первой продажи Traffic Inspector, которая, по счастливому стечению обстоятельств, состоялась ровно через два месяца после официальной регистрации юридического лица — 17 мая 2003 года.

Продажи, кстати, идут неплохо — за 9 лет (статистика последнего года еще не готова) разошлось более 55000 копий программ и дополнительных модулей. По нашим оценкам, более 3 000 000 человек работают в использующих решения «Смарт-Софт» сетях. И это только пользователи легальных версий — сколько пиратских копий ходит по просторам нашей необъятной родины, учету не поддается.

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

И тут причина была не только в недостаточной осведомленности клиентки, но и администраторов, которые банально не заметили разницы, либо также не осознавали её. Именно по этой причине мы решили разобрать данный случай.