База знаний / Документация NetAMS

Веб–интерфейс Admintool

ВНИМАНИЕ!

Admintool не избавляет вас о необходимости начального создания и настройки конфигурационного файла NeTAMS. С его помощью можно лишь управлять параметрами уже существующих юнитов в плане настройки IP–адресов, квот, параметров логинов и прочего.

Admintool тесно связан с существующим сервисом создания статических HTML–страниц так, что в вновь создаваемых страницах появляется ссылка на скрипт:

Допустим, сервис html настроен следующим образом:

service html 0

path /usr/local/www/stat

language en

run hourly

При нормальной работе в этом каталоге находятся следующие файлы:

srv:/usr/local/www/stat#ls–la

drwxr–xr–x 4 root wheel 512 Jul 12 14:31 .

drwxr–xr–x 11 root wheel 1536 Jul 19 11:41 ..

drwxr–xr–x 7 root wheel 512 Jul 12 14:30 2004

drwxr–xr–x 118 root wheel 2048 May 31 14:11 clients

drwxr–xr–x 2 root wheel 512 Jul 21 21:14 images

— rwxr–xr–x 1 root wheel 139 Jul 19 12:59 index.html

Для инсталляции Admintool необходимо скопировать в каталог /usr/local/www/ из дистрибутива NeTAMS подкаталог /cgi–bin/

Необходимо отредактировать верхние строки скрипта admintool.cgi, указав параметры соединения с NeTAMS:

# Data required to do a script login, change this

$sc_host=«localhost»; $sc_port=20001; $sc_user=«anton»; $sc_passwd=«aaa»;

Необходимо настроить веб–сервер (Apache), чтобы он разрешал выполнение CGI–скриптов в каталоге /usr/local/www/stat. Отредактируйте /usr/local/etc/apache/httpd.conf (или где там он у вас есть):

Options FollowSymLinks ExecCGI

Alias /stat/ /usr/local/www/stat/

Убедитесь что скрипт работает, набрав

http://webservername/stat/admintool.cgi

Вы должны увидеть нечто вроде следующего:

В левом верхнем углу указано:

Версия работающей программы NeTAMS

Время выполнения программы NeTAMS (из show version)

Текущее локальное время в системе.

Если вместо пунктов 1 и 2 изображены пустые строки, значит или NeTAMS не запущен в настоящий момент, или скрипту не удалось с ним связаться (не совпадают логин/пароль/номер порта).

Настоятельно рекомендуется:

Запускать NeTAMS, Apache и Admintool на одной машине. Открыть доступ в NeTAMS только с локальной машины (service server … login local).

Средствами Apache разграничить доступ к статистике и к скрипту только для тех, кому это действительно необходимо (и использовать опцию htaccess yes для сервиса html).

Утилита ascii2netflow

Начиная с версии NeTAMS 3.4.0 (build 3018) в дистрибутиве присутствует утилита ascii2netflow, которая предназначена для преобразования входящей статистики в поток данных в формате Cisco NetFlow

Автоматическое создание юнитов

Зачастую бывает проблематично или неудобно вручную создавать весь список юнитов для большой сети. Для решения этой проблемы в netams–3.1(2000.204) была введена функциональность auto–units, или возможность автоматического создания юнитов при появлении IP–трафика на заданные адреса. Для этого необходимо:

Необходимо создать специальную запись в конфигурации сервиса processor, с именем auto–units и уникальным номером, и описать ее поведение

Создать юнит типа сеть (net) и указать параметр «auto–units N» для него.

Опционально создать для каждого использующегося ip–адреса запись в обратной зоне DNS.

Например:

service processor

auto–units 1 type host naming by–dns

auto–units 2 type user naming prefix1 ip–auto–units 3 type user naming prefix2 user_

unit net name OFFICE ip 192.168.0.0 mask 255.255.255.0 auto–units 1

unit net name CLIENTS ip 192.168.100.0 mask 255.255.255.0 auto–units 2

unit net name USERS ip 172.16.0.0 mask 255.255.0.0 auto–units 3

Допустим, что для подсети 192.168.0.0 у вас уже настроена обратная зона DNS (например, для работы DHCP, или через Dynamic DHS от Windows2000). В этом случае возможно обратное преобразование IP–адреса в FQDN, т.е. команда

host 192.168.0.123

выдает что–то вроде

pupkin.office.domain.ru

Допустим также, что у вас настроен и работает сервис data–source, и трафик для подсетей 192.168.0 и 172.16 попадает через этот сервис в NeTAMS.

Что должно происходить, когда пакет с адресом DST=192.168.0.123 попадает на обработку. Если соответствующий сервис имеет тип ip–traffic, то, поскольку юнита для данного IP еще не существует, прохождение или блокировка этого пакета будет определяться значением параметра restrict сервиса processor, наличием no–local–pass, sys–policy, fw–policy на юнит OFFICE. Если сервис data–source не осуществляет фильтрацию, пакет проходит. В любом случае, из–за действия механизма потоков информация о трафике на IP–адрес 192.168.0.123 рано или поздно попадет на обработку s_datasource и связана с юнитом типа «сеть» с именем OFFICE. Если для него установлено значение параметра auto–units, то:

Будет установлено, что адрес 192.168.0.123 принадлежит искомой сети 192.168.0.0/24

Юнита с адресом 192.168.0.123 пока еще не существует, и его надо создать

Поскольку для записи auto–units 1 установлен type==host, будет создан юнит типа host

Для определения имени для этого юнита будет использован DNS (т.к. параметр naming==by–dns), который преобразует IP–адрес 192.168.0.123 в имя pupkin.office.domain.ru. В качестве имени будет выбрано «pupkin». На совести администратора обеспечить уникальность имен в подсети.

Если в качестве типа юнита установлено type==user, будет применен этот тип.

Если в качестве параметра присвоения имени (naming) указано prefix1 или prefix2, то для выбора имени будет использоваться указанная затем подстрока в сочетании с последним (prefix1) или двумя последними (prefix2) октетами рассматриваемого IP–адреса. Таким образом, для проходящих пакетов с адресами 192.168.100.123 и 172.16.0.23 будут созданы юниты:

unit user name ip–123 ip 192.168.100.123

unit user name user_0.23 ip 172.16.0.23

Учтите также, что процесс преобразования IP–адресов в имена хостов может занимать время, и основан на механизме, описанном в man resolver. Это может сказаться на времени реакции системы и производительности NeTAMS.

Автоматически созданные юниты будут расположены в конфигурационном файле «в памяти» и иметь уникальные автоматически присвоенные значения OID. Вы должны время от времени сохранять «растущий» конфигурационный файл на место, чтобы новые юниты и их статистика не потерялась. Эту операцию можно автоматизировать:

schedule time 1hour action save

После того как все IP–адреса «присвоены» новым юнитам, рекомендуется отключить описанный здесь механизм auto–units, путем удаления параметра auto–units с юнита типа «сеть»:

service processor

unit net name OFFICE auto–units 0

Зачем нужен break flag [%] при описании policy

Для версий netams 3.1.xx, 3.2.xx и 3.3.xx до build 2117:

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

service processor

policy name all–ip target proto ip

policy name tcp target proto tcp

unit host name HOST1 ip 192.168.1.5 fw–policy !tcp all–ip

вы все равно не сможете открыть для этой машины ТОЛЬКО TCP–трафик, на следующем совпавшем правиле all–ip пакет зарежется. Для того чтобы после совпадения политики дальнейший поиск прекратился, поставьте

unit host name HOST1 ip 192.168.1.5 fw–policy !%tcp all–ip

Если вы задаете последовательность из нескольких политик подсчета трафика подряд, то по умолчанию подсчет ведется для каждой политики, т.е. в случае

service processor

policy name ip target proto ip

policy name tcp target proto tcp

policy name udp target proto udp

policy name other target proto ip

unit host name HOST1 ip 192.168.1.5 acct–policy ip tcp udp other

вы все равно не сможете явно посчитать для этой машины весь не udp и не tcp трафик, который назовем other, так как пакет все равно посчитается по политике ip. Чтобы при совпадении политики дальнейший подсчет прекратился, поставьте

unit host name HOST1 ip 192.168.1.5 acct–policy ip %tcp %udp other

Для версий netams 3.3.xx после build 2117, в частности 3.3.0–release и далее:

По многочисленным пожеланиям пользователей и для упрощения конфигурационного файла, действие политики fw–policy было инвертировано. Теперь код вида:

unit host name HOST1 ip 192.168.1.5 fw–policy www icmp

разрешает данному юниту общение по политикам www и icmp, блокируя все остальное. Вам теперь не нужно городить сложные комбинации с участием break flag и инвертирования. Помните, что весь остальной трафик, не описанный в политиках fw–policy, будет блокирован.

Управления карточками экспресс–оплаты

Поддержка карточек экспресс–оплаты появилась в NeTAMS 3.3.1 (RELEASE) начиная с номера билда 2811 (25 ноября 2005г.)

Что и зачем

В наборе скриптов управление системой NeTAMS появилось два новых скрипта — управления карточками, и активации карточек пользователем. Владелец (администратор) сети, в которой установлен и работает NeTAMS+модуль биллинга, генерирует базу карточкек эксперсс–оплаты, печатает и реализует их, и использует активацию карточек как средство пополнения баланса абонента в системе биллинга. Активация карточек возможна как оператором системы, так и непосредственно самим абонентом через отдельный скрипт. Возможно также блокировать–разблокировать как отдельные карточки, так и серии карточек, экспортировать номера карточек во внешний файл, проверять годноть и статус карточки, и так далее. Курс преобразования номинала карточки в условные единицы биллинга также управляется из администраторского скрипта.

Каждая карточка имеет десятизначный номер (первые три цифры — номер серии, остальные семь — случайное число), ПИН–код (двадцать случайных чисел в четырех группах по пять чисел, разделенных дефисом), номинал (число от 10 до 10000, задается при создании), время создания, статус (неактивирована, уже активирована, блокирована), время изменения статуса.

Случайные числа, испольованные при генерации номеров — действительно случайные, построенные с использованием системного устройства энтропии вроде /dev/urandom.

Как поставить

Необходимо поставить Netams 3.3.1–release, хотя сам скрипт будет работать и с предыдущими версиями. Необходимо правильно настроить скрипты admintool.cgi, config.cgi из каталога admin/cgi–bin дистрибутива. Фактически, модуль работы с карточками вызывается оттуда и использует чаcть общих функций Admintool и NeTAMS Perl API.

Система управления карточками привязана к MySQL, но легко может быть перенесена на PostgreSQL или Oracle. Она состоит из следующих файлов:

• addon/cardtool_schema.sql — схема базы данных (описание таблицы cards). Вы должны создать эту новую таблицу в вашей базе данных посредством следующей команды:

mysql netams < addon/cardtool_schema.sql

(предполагается, что имя вашей база данных «netams»)

• admin/cardtool.cgi — основной скрипт работы с карточками. В его первых строках указан относительный путь до файла с курсом перерасчета у.е. По умолчанию это «ratefile.txt» в такущем каталоге.

• admin/ratefile.txt — файл содержит одну строку с курсом перерасчета у.е. при пополнении баланса биллинга. Вы ДОЛЖНЫ сами создать этот файл вручную, и присвоить ему права доступа, гарантирующие запись в него из скрипта. Дальнейшие модификации этого файла будут проводиться самим скриптом cardtool.cgi.

• activate.cgi — скрипт активации карточки пользователем. Начало файла содержит ссылку на файл с курсом у.е., а также имя шаблона страницы, которая будет показана пользователью перед активацией (форма с запросом) и после (результат активации).

• activate.tmpl — форма (шаблон) страницы пользователя, проводящего активацию самостоятельно.

В файле config.cgi проверяем наличие:

#enable or disable prepaid card processing services

$have_cards=«yes»;

Все, можно работать. Заходим в Admintool и видим появившийся пункт меню:

Как использовать

Создать новую серию карточек

Необходимо указать номинал карточки, количество карточек, и нажать кнопку «Применить». Номер серии присвоится автоматически (следующий незанятый начиная с 1), и вы увидите что–то вроде:

Просмотреть всю серию

В таблице серий карточек кликнуть на номер серии, появится таблица со сведениями о серии, плюс информация о каждой карточке:

Работа с серией

В том же окне можно блокировать и разблокировать все карточки серии, а также ссылаться на управление произвольной (еще не активированной) карточкой. Можно также полностью удалить всю серию карточек из базы.

Получить список карточек

Нажать на кнопку «Экспортировать», во всплывшем окне (оключить блокиратор!) появистся список карточек вместе с номером, кодом и номиналом. Его можно потом скопировать и сохранить в отдельном файле.

Курс перерасчета

В основном окне «Prepaid cards» можно выбрать режим изменения курса перерасчета. Карточки выпускаются с номиналом в рублях, а на баланс абонента средства заносятся путем деления номинала карты на этот курс. Величина курса хранится в текстовом файле admin/ratefile.txt

Активация карты

Администратор/оператор системы может сам активировать карту (по звонку абонента), путем ввода всей информации в верхней части основного окна. Необходимо указать номер, ПИН, имя аккаунта абонента, и нажать кнопку «Применить». Будет произведена проверка, и в открывшемся окне можно или подтвердить операцию, или посмотреть сообщение об ошибке:

Кнопка «Применить» (пополнить счет абонента) появится только в случае, если все нормально.

Операции с картой

По номеру карты можно посмотреть ее статус, а также произвести блокировку и разблокировку:

Операция блокировки обратима, операция активации карты — нет.

Активация карты абонентом

Вам бедет необходимо исправить шаблонный файл cgi–bin/activate.tmpl, поместим в него макет страницы, которую должен видеть пользватель. Шаблон состоит из двух половинок (код HTML), разделенных строкой ########. Верхняя часть содержит форму активации, нижняя — информацию об операции.

Пользователью необходимо предоставить ссылку на скрипт cgi–bin/activate.cgi

В шаблоне по умолчанию присутствует следующая таблица:

После выполнения операции абонент получает одно из следующих сообщений:

Управление базой данных

Можно настроить автоматическую или ручную очистку быстрорастущих таблиц raw и monitor при помощи этих нехитрых SQL–команд:

delete from raw \

where t_to < unix_timestamp(date_add(now(), interval–6 MONTH));

delete from monitor \

where time < unix_timestamp(date_add(now(), interval–6 MONTH));

При этом удаляются записи, которым более полугода.

Надо отметить, что таблица summary растет достаточно медленно, и при нынешних ценах на дисковую память можно не особо беспокоиться.

Если вы делаете бизнес при помощи NeTAMS и целостность данных критична, рекомендую подумать о резервном копировании. Это можно сделать следующими средствами:

• Поставить в сервер два жестких диска, и организовать аппаратный или программный RAID. Это не спасет, если упадет ОС (придется тратить время на переустановку), разрушится или случайно сотрется содержимое файловой системы или кто–то грохнет базу, или сервер украдут;

• Организовать автоматическое резервное копирование базы через mysqldump/mysqlhotcopy, на соседний сервер или удаленный компьютер;

• Средствами NeTAMS писать одновременно в два хранилища:

service processor

storage 1 all

storage 2 summary

В дополнение к этому в дистрибутиве идет скрипт очистки БД: addon/mysql_rotate.pl

Правила для data–source

В случае использование FreeBSD правила должны выглядеть следующим образом:

Случай использования «честных» адресов:

rule number «ip from any to any via ifname»

где:

number — относительно любой номер правила в таблице ipfw, например 100

ifname — название внешнего интерфейса, через который трафик идет к провайдеру

Случай использования «левых» адресов и их трансляции:

rule number1 «ip from any to any via ifname»

rule number2 «ip from any to any via ifname»

где:

number1 и number2 — номера правил в таблице ipfw, так чтобы ваше правило по трансляции адресов (заворот пакетов в divert socket NATD) имело номер МЕЖДУ НИМИ.

ifname — название внешнего интерфейса, через который трафик идет к провайдеру

Это сделано для того, чтобы учитывать трафик на не оттранслированные адреса.

В случае Linux, независимо от наличия трансляции адресов (маскарадинга), правила имеют вид:

rule number1 «INPUT–p all–j QUEUE»

rule number2 «FORWARD–p all–j QUEUE»

rule number3 «OUTPUT–p all–j QUEUE»

причем номера number1, 2 и 3 совершенно произвольные так как никак не используются.

Этими действиями выполняется следующее: вы задаете правила для ipfw/iptables, по которым пакеты ядром направляются пихаются в некую виртуальную трубу (которая называется queue), откуда их потом берет программа, прокачивает через себя (смотря на заголовки и делая подсчет) и отдает обратно в систему, после чего они спокойно идут себе дальше.

ВАЖНО!!!

Если вы остановили программу так что она не смогла после себя убрать эти поставленные правила (через kill–9) или она сама неожиданно померла, то все пакеты по прежнему система будет заворачивать туда откуда их никто не заберет, и они пропадут. С точки зрения системы это будет выглядеть как полная потеря работы с сетью. НИКОГДА не экспериментируйте с этим сидя за удаленной машиной. Тренируйтесь непосредственно за консолью, или в крайнем случае на icmp–трафике. Сделайте для доступа «дырку» перед всеми правилами, пропускающую для вас SSH. Это не касается data–source других (неблокирующих) типов, например libpcap или netflow.

Java API и сервлеты

Для управления системой NeTAMS существует прикладной интерфейс для языка Java. Он повторяет по функциональности интерфейс для Perl, и при этом содержит процедуры разбора конфигурационного файла для получения списка политик и юнитов (с привязанными политиками). На базе этого интерфейса разработано тестовое приложение NetamsView–ShowTable, которое представляет собой веб–интерфейс для доступа к статистике из БД и представления ее в таблично–календарном виде (скриншот 1, скриншот 2).

Если вы хотите разработать свой модуль интерфейса с NeTAMS на языке Java, или просто смотреть таблички как на скриншоте, вам необходимо будет сделать следующее:

Поставить Java SDK

Поставить Apache Tomcat

Поставить драйвер JDBC (MysqlJ)

Поставить сервлет

(опционально) поставить NeTAMS–CURRENT

Теперь по порядку.

1. Java SDK нужно для того, чтобы запускать приложения, написанные на языке Java. Этими приложениями будут сам сервлет, отдающий таблицу, и веб–сервер Tomcat. Установка JDK описана много где, очень рекомендую: http://www.freebsd.org/doc/en_US.ISO8859–1/articles/java–tomcat/. Там написано про версию JDK 1.3, на настоящий момент последняя версия имеет номер 1.4.2 (и 1.5.0 скоро выйдет). После успешной инсталляции вы сможете успешно набрать «java–version» и получить потребный вывод.

2. Apache Tomcat — это такой веб–сервер, написанный целиком на языке Java, и позволяющий исполнять сервлеты (приложения Java для серверной стороны). Скачать можно тут: http://jakarta.apache.org/tomcat/index.html. Проверялось на версии 5.0.26

3. Для «прямого» доступа к базе данных вашему сервлету понадобится механизм взаимодействия с MySQL, при помощи «родного» JDBC–драйвера по имени Mysql Connector/J. Берется тут: http://dev.mysql.com/downloads/connector/j/3.0.html

4. Необходимо скачать и настроить наш сервлет NetamsView. Дистрибутив в виде WAR файла находится тут: NetamsView.war. Скачайте его. Для установки сервлета в систему необходимо зайти в интерфейс Manager управления Tomcat, выбрать там «Select WAR file to upload», указать на файл и нажать кнопку «Deploy». После этого необходимо поправить параметры доступа сервлета к NeTAMS и базе, которые находятся в файле netams.properties. У меня этот файл установлен в каталоге /usr/local/jakarta–tomcat5.0/webapps/NetamsView/WEB–INF/

Внутри этого файла находятся строки вида:

netams–hostname router

netams–port 20001

netams–login admin

netams–password abc

mysql–hostname router

mysql–login netams

mysql–password secretpass

5. После этого должен заработать доступ к сервлету. Наберите в бровсезе:

http://www.myserver.ru:8180/NetamsView/netams

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

6. Если вы хотите получать «нормальные» ссылки на таблицы из статических страниц, генерируемых сервисом html, вам надо будет поставить и настроить NeTAMS–CURRNET, и прописать в параметрах сервиса html строку

servlet–url http://www.myserver.ru:8180

Не забудьте положить картинку showtable–logo.gif в каталог images.

Если у вас что–то не работает — извините. Никакой поддержки по NetamsView не оказывается. Исключение составляют лишь серьезно желающие взяться за доведения этого сервлета до ума!
Мониторинг

Начиная с версии 1120.5 NeTAMS поддерживает мониторинг заданных юнитов для сбора информации по относящемуся к ним трафику. Для включения этой функции необходимо задать сервис monitor и направление вывода статистики. Она может сохраняться как в текстовом файле, так и в базе данных, определенной одним из сервисов storage. Для включения мониторинга необходимо задать команду

service monitor NN

monitor to file /path/to/output/file

или

service monitor NN

monitor to storage N

где N — номер соответствующего сервиса storage

После этого задайте список юнитов, трафик которых вы хотите записывать. Можно указывать как имя юнита, так и его номер (OID), каждый юнит определяется отдельной командой на своей строке. Например:

monitor unit server_1

monitor unit net_real

monitor unit 02ffad

В результате мониторинга с выводом в текстовый файл создаются записи вида:

29.04.2002 22:27:27.4898 user_1 041BEF

06 s:172.16.0.1:2174 d:172.16.13.1:23 60

29.04.2002 22:27:30.4800 user_1 041BEF

06 s:172.16.0.1:2174 d:172.16.13.1:23 60

30.04.2002 10:37:55.9553 user_1 041BEF

01 s:172.16.13.2 d:172.16.0.1 84

30.04.2002 10:39:43.4137 user_1 041BEF

17 s:172.16.13.2:1031 d:212.69.119.4:53 59

30.04.2002 10:39:43.4146 user_1 041BEF

17 s:212.69.119.4:53 d:172.16.13.2:1031 145

30.04.2002 10:39:43.4424 user_1 041BEF

06 s:172.16.13.2:1032 d:213.180.194.129:80 48

30.04.2002 10:39:43.4512 user_1 041BEF

06 s:213.180.194.129:80 d:172.16.13.2:1032 44

Первое — второе поля: дата и время, после точки — доли секунды

Третье — четвертое поля: имя юнита и его OID

Пятое поле — номер протокола (01–icmp, 06 — tcp, 17 — udp)

Шестое — седьмое поля: IP–адрес и номер порта src и dst полей пакета

Восьмое поле: длина пакета (или потока) в байтах

Вы можете использовать NeTAMS как сборщик детальной информации о трафике или записей NetFlow, применив упрощенную для этого случая конфигурацию:

# configuration file example 3 begin

debug none

user name admin real–name Admin email root@localhost password aaa permit all

service server 0

login any

listen 20001

max–conn 6

service processor 0

lookup–delay 20

flow–lifetime 120

policy name ip target proto ip

unit net name u_all ip 0.0.0.0 mask 0.0.0.0 acct–policy ip

service data–source 1

type netflow

source 192.168.0.254

listen 20001

service monitor 1

monitor to file /var/netflow.log

monitor unit u_all

# configuration file example 3 end

Поскольку NeTAMS 3.2 получает внутри себя уже агрегированную по потокам статистику, то попакетной детализации получить нельзя. Вместо этого будет сохранена информация о каждом потоке, прошедшем через data–source, что существенно сокращает размер базы или лог–файла.

Сбор данных через NETGRAPH

Начиная с версии NETAMS–CURRENT build 2340 (03 марта 2005 г.) работает метод сбора статистики и фильтрация трафика через модуль NETGRAPH.

Технология NETGRAPH доступна для операционной системы FreeBSD версий 4.хх и 5.хх. Входящий в поставку модуль совместим с веткой 5.хх. NETGRAPH представляет собой механизм объединения различных сетевых модулей ядра FreeBSD в произвольные структуры (образующие граф), для последовательной обработки пакетов данных. Таким образом, представляется возможным написать и использовать достаточно произвольную схему обработки данных в ядре ОС, пользуясь стандартным интерфейсом программирования. Более того, легко осуществить связь модуля ядра с user–level программой. Через NETGRAPH работают, например, ng_netflow, user–level ppp, различные механизмы инкапсуляции пакетов, и многое другое. Для более глубокого ознакомления можно порекомендовать следующие источники:

http://www.daemonnews.org/200003/netgraph.html и man 4 netgraph

Пользователей других операционных систем вынуждены огорчить: ничего подобного у вас нет. Тем же, кому повезло, могут читать дальше:

Принципы работы

Как настроить

Как проверить

Результаты испытаний

Заключение

Принципы работы

Работа netams в случае использования модуля NETGRAPH (далее–модуль) заключается в установке модуля в ядро (и подключения его к интерфейсу, через который идет трафик), и настройке программы netams (далее–демона) для корректного соединения с модулем.

Модуль и демон могут работать в двух режимах (они должны быть одинаковы в настройках!): tee и divert.

В режиме tee модуль ядра получает пакеты с использованием «дубликатора» ng_tee, который отсылает на обработку «копию» проходящего через интерфейс пакета. Понятное дело, в таком случае фильтрация трафика невозможна. Проходящие через модуль пакеты подвергаются анализу заголовков, формируются записи в хэш–таблице, которые периодически «устаревают» и отправляются на обработку демону. Он получает пакеты с данными о трафике и обрабатывает их примерно так же, как происходит с потоками netflow (работают учет и мониторинг).

В режиме divert модуль ядра подключается непосредственно к ethernet–интерфейсу. Весь трафик проходит через обработку, однако НЕ IP трафик пропускается прозрачно без учета. Каждый пакет также проходит проверку на соответствие с уже имеющимся в системе потоком данных, и:

• если соответствующего потока не найдено, т.е. рассматриваемый пакет–первый в потоке данных (начало соединения), то для данного потока создается очередь. пакет помещается в конец очереди. создается запрос вида FWREQUEST, содержащий заголовки пакета, и передается через контрольный сокет демону netams. заметим, что в этот момент оригинальный IP пакет никуда не передается, он «застревает» в модуле. потоку присваивается статус QUEUED.

• если поток найден, то проверяется его статус:

• QUEUED — рассматриваемый пакет добавляется в конец цепочки пакетов данного потока. при этом делаются проверки на ряд ограничений по количеству потоков/пакетов/байт/очередей, для предотвращения атаки DoS

• PASS — пакет передается дальше

• DROP — пакет уничтожается

Возникает вопрос, что же происходит с пакетами в очереди, и откуда берутся статусы PASS и DROP?

Статус DROP является единственно возможным для режима работы TEE.

Когда демон получает запрос FWREQUEST из модуля ядра, происходит разбор заголовков и полный анализ возможности блокировки пакета с использованием таблиц юнитов, политик, системных политик, словом всего обычного набора действий. По окончании проверки, формируется решение по данному потоку: PASS или DROP, и оно передается обратно в ядро через сообщение FWREPLY. За время такой обработки в ядре уже может накопиться несколько пакетов в очереди для данного потока. По получении ответа от демона, модуль ядра во–первых ставит соответствующий флаг для данного потока, а затем пытается или отправить все пакеты из очереди, или очистить очередь.

Если по каким–то причинам демон недоступен, то по истечении некоторого таймаута (сейчас это NG_NETAMS_DEFAULT_TIMEOUT равный 2 секундам) производится принудительная очистка очереди для потока и принятие «решения по умолчанию» (сейчас: пропускать). Таким образом предотвращается залипание потока и выедание памяти у ядра (что может быть очень опасным!)

В режиме divert, как и в tee, проводится периодическое устаревание потоков и отправка их на учет «наверх», демону.

Рассмотренный механизм работает, по сути, аналогично Multilayer Switching, реализованному в Cisco Catalyst 6000 и подобных ящиках. Там «быстрый» Switch Engine направляет первый пакет потока «медленному» Route Processor, который определяет, куда маршрутизировать пакет, и проводит проверку правил доступа (access lists). Все последующие после ответа пакеты идут через SE напрямую, и только через некоторое время «наверх» передается статистика о прошедшем потоке. В нашем случае решения о маршрутизации принимать не нужно, в роли «быстрого» движка выступает ядро с его механизмом форвардинга пакетов, в роли «медленного» решателя — демон NeTAMS.

Как настроить

Для начала, вам надо скомпилировать netams, как обычно. Получившийся модуль src/ng_netams.ko необходимо переписать в /boot/kernel/

В дистрибутиве есть скрипт addon/netams–netgraph.sh, который устанавливает в ядро сам модуль ng_netams.ko, устанавливает его режим работы (TEE или DIVERT), вывод отладочной информации, производит подключения к другим нодам NETGRAPH (интерфейсу и ng_tee, если надо)

Запускается этот скрипт через

./netams–netgraph.sh start

останавливается через

./netams–netgraph.sh stop

Для настройки самого NeTAMS необходимо добавить соответствующий сервис в /usr/local/etc/netams.cfg:

service data–source 1

type netgraph

source netams: divert

При этом 'netams:' - это имя модуля NETGRAPH, совпадающее с тем, что написано в скрипте netams–netgraph.sh. Не забываем про двоеточие!

Модуль ядра должен быть запущен ДО демона. В противном случае демон не заработает, как следует. Однако, в процессе работы допускается останавливать и запускать демон NeTAMS, равно как и выгружать и загружать снова модуль ядра (при этом будет 20–секундная задержка в приеме статистики).

Как проверить

Если что–то будет идти совсем не так, упадет ядро :) или блокируется весь трафик!

Работу демона netams можно проверить через просмотр состояния сервиса data–source:

netamsctl show ds

Data–source ID=1 type NETGRAPH source netams::9 loop 0 average 0 mcsec

Perf: average skew delay 0 mcsec, PPS: 0, BPS: 0

IP tree: 7 nodes [12] + 4 dlinks [1024] + 4 unodes [24] = 4276 bytes

Flows: 0/0 act/inact entries (0 bytes), 3 flows sent

HASH: size=65536, 0 flows hashed, 0 nodes used, max chain= 0

FIFO: 0/2 used/ready messages, each 108, total 216 bytes

ds_netgraph data messages: 3

netams: mode=2, pkt_rx=201, pkt_tx=169

flows: active(now)=3, queued(now)=0, blocked(total)=0, total=4

Работа модуля ядра видна через ngctl:

ngctl msg netams: info

Rec'd response «info» (1) from «[3bb]:":

Args: { packets/in=254 packets/out=202 mode=2 debug=1 active_flows=3 total_flows=9 default_policy=2 }

При включенной отладке модуля (через ngctl msg netams: debug 1) на консоли и в dmesg видно много подобных строк:

info/1109893460: sent to daemon [961] with error=0

callout/1109893461+ active 1, checked 1, queued=0, flushed 0

callout/1109893462+ active 1, checked 1, queued=0, flushed 0

callout/1109893463+ active 1, checked 1, queued=0, flushed 0

callout/1109893464+ active 1, checked 1, queued=0, flushed 0

callout/1109893465+ active 1, checked 1, queued=0, flushed 0

callout/1109893466+ active 1, checked 1, queued=0, flushed 0

callout/1109893467+ active 1, checked 1, queued=0, flushed 0

callout/1109893468+ active 1, checked 1, queued=0, flushed 0

callout/1109893469+ active 1, checked 1, queued=0, flushed 0

netams: created flow record id=14, hash=00766, time=1109893469, proto=6

netams: created queue 0xc1a15250 for id=14, hash=00766

netams fwreply for entry id=14, flags=0, queue 1/102

netams: flush queue for entry id=14, hash=766, size=1, action=1

netams: created flow record id=15, hash=00254, time=1109893469, proto=6

netams: created queue 0xc1355240 for id=15, hash=00254

netams fwreply for entry id=15, flags=0, queue 1/102

netams: flush queue for entry id=15, hash=254, size=1, action=1

Результаты испытаний

Зачем все это нужно? Чтобы быстрее работало! Ниже приведены результаты небольших стендовых испытаний.

Все работы проводились с ОС FreeBSD 5.3–RELEASE, которая работала внутри виртуальной машины VmWare 4.5.2. Сама виртуальная машина работала на компьютере DUAL P4 Xeon 3.4GHz, 4Gb RAM под управлением Windows Server 2003. Виртуальная машина и хост–машина связаны через виртуальный адаптер vnmat (хотя в тестах трансляции адресов не было).

Скорость передачи данных измерялась при помощи iperf 1.7.0

На самой машине с Windows Server 2003 запущен сервер iperf, там же запускаем клиента:

C:\>iperf.exe–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 8.00 KByte (default)

— -----------------------------------------------------------

[1948] local 192.168.56.1 port 3027 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[1948] 0.0–1.0 sec 97.8 MBytes 821 Mbits/sec

[1948] 1.0–2.0 sec 96.1 MBytes 807 Mbits/sec

[1948] 2.0–3.0 sec 97.7 MBytes 820 Mbits/sec

[1948] 3.0–4.0 sec 93.0 MBytes 780 Mbits/sec

[1948] 4.0–5.0 sec 93.2 MBytes 782 Mbits/sec

[1948] 5.0–6.0 sec 96.9 MBytes 813 Mbits/sec

[1948] 6.0–7.0 sec 98.4 MBytes 825 Mbits/sec

[1948] 7.0–8.0 sec 97.4 MBytes 817 Mbits/sec

[1948] 8.0–9.0 sec 96.0 MBytes 806 Mbits/sec

[1948] 9.0–10.0 sec 98.2 MBytes 824 Mbits/sec

[1948] 0.0–10.0 sec 965 MBytes 808 Mbits/sec

Как видим, скорость передачи данных через локальный виртуальный интерфейс просто гигантская. Пробуем, как передаются данные между Windows и установленной FreeBSD, через VmWare, безо всяких побочных эффектов (NeTAMS и модуль ядра выключены):

freebsd–vm:~/netams#iperf–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 32.5 KByte (default)

— -----------------------------------------------------------

[ 3] local 192.168.56.17 port 51925 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0–1.0 sec 27.6 MBytes 232 Mbits/sec

[ 3] 1.0–2.0 sec 28.4 MBytes 238 Mbits/sec

[ 3] 2.0–3.0 sec 28.1 MBytes 236 Mbits/sec

[ 3] 3.0–4.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 4.0–5.0 sec 28.4 MBytes 238 Mbits/sec

[ 3] 5.0–6.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 6.0–7.0 sec 28.0 MBytes 235 Mbits/sec

[ 3] 7.0–8.0 sec 28.1 MBytes 236 Mbits/sec

[ 3] 8.0–9.0 sec 28.7 MBytes 240 Mbits/sec

[ 3] 9.0–10.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 0.0–10.0 sec 282 MBytes 237 Mbits/sec

Естественно, медленнее. Теперь запустим NeTAMS и модуль ядра вместе, в режиме divert и убедимся, что это была не подстава:

freebsd–vm:~/netams#iperf–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 32.5 KByte (default)

— -----------------------------------------------------------

[ 3] local 192.168.56.17 port 56639 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0–1.0 sec 20.9 MBytes 175 Mbits/sec

[ 3] 1.0–2.0 sec 23.4 MBytes 196 Mbits/sec

[ 3] 2.0–3.0 sec 23.5 MBytes 197 Mbits/sec

[ 3] 3.0–4.0 sec 23.5 MBytes 197 Mbits/sec

[ 3] 4.0–5.0 sec 23.6 MBytes 198 Mbits/sec

[ 3] 5.0–6.0 sec 23.6 MBytes 198 Mbits/sec

[ 3] 6.0–7.0 sec 23.4 MBytes 196 Mbits/sec

[ 3] 7.0–8.0 sec 23.8 MBytes 200 Mbits/sec

[ 3] 8.0–9.0 sec 23.6 MBytes 198 Mbits/sec

[ 3] 9.0–10.0 sec 23.3 MBytes 196 Mbits/sec

[ 3] 0.0–10.0 sec 233 MBytes 195 Mbits/sec

freebsd–vm:~/netams#ngctl msg netams: info

Rec'd response «info» (1) from «[3c5]:":

Args: { packets/in=85515 packets/out=169244 mode=2

debug=1 active_flows=4 total_flows=4 default_policy=2 }

Налицо падение производительности на 100*(237–195)/237=17.7% или в 1.2 раза. Теперь заменим фильтрование через модуль ядра на стандартное, через ipfw divert и data–source ip–traffic:

freebsd–vm:~/netams#iperf–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 32.5 KByte (default)

— -----------------------------------------------------------

[ 3] local 192.168.56.17 port 55410 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0–1.0 sec 2.96 MBytes 24.8 Mbits/sec

[ 3] 1.0–2.0 sec 3.59 MBytes 30.1 Mbits/sec

[ 3] 2.0–3.0 sec 3.73 MBytes 31.3 Mbits/sec

[ 3] 3.0–4.0 sec 3.62 MBytes 30.3 Mbits/sec

[ 3] 4.0–5.0 sec 3.70 MBytes 31.0 Mbits/sec

[ 3] 5.0–6.0 sec 3.69 MBytes 30.9 Mbits/sec

[ 3] 6.0–7.0 sec 3.65 MBytes 30.6 Mbits/sec

[ 3] 7.0–8.0 sec 3.71 MBytes 31.1 Mbits/sec

[ 3] 8.0–9.0 sec 3.71 MBytes 31.1 Mbits/sec

[ 3] 9.0–10.0 sec 3.73 MBytes 31.3 Mbits/sec

[ 3] 0.0–10.0 sec 36.1 MBytes 30.2 Mbits/sec

freebsd–vm:~/netams#ipfw show 10 11

00010 26136 39197956 divert 199 tcp from any to any dst–port 5001

00011 13069 679600 divert 199 tcp from any 5001 to any

В данном случае мы видим потерю производительности на 100*(237–30.2)/237=87.2% или в 8 раз. Выгода налицо!

Заключение

Велосипед мы не изобрели, это понятно. Результаты ожидаемы. Использование модуля ядра более опасно, чем обычного data–source ip–traffic, а уже тем более сбора по libpcap или netflow. В случае ошибок или переполнения буферов зависает ядро вместе со всеми процессами, или блокируются все сокеты. Было проведено тестирование на предмет поддержки «нехороших ситуаций» вроде ping–f или nmap–sS–PS 80–iR 100. Однако стабильность работы не гарантируется, тестируйте модуль со всей осторожностью!

Кто–нибудь особенно умный может спросить: «А собственно зачем вы это делали? Фильтровать можно и в ядре, через тот же ipfw deny, pfctl и прочее. Все будет быстро и надежно.»

Возможно. Однако вам придется как–то синхронизировать таблицу юнитов и политик учета с правилами firewall, фактически городить зоопарк скриптов и дублировать одно и то же дважды. Зачем? Использование NeTAMS позволяет хранить всю информацию о правилах в одном месте, без проблем применяя всякие хитрости вроде break flag, prefix table и срабатывание по времени суток. Совершенно прозрачно работают сервисы квот, системные политики, биллинг, и так далее.

Возможные направления улучшения и развития:

• Создать аналогичный продукт для Linux, видимо на базе ULOG

• Сделать поддержку RAW IP пакетов, PPP и так далее

• Проверить работоспособность в случае нескольких модулей ядра, работающих одновременно

Зачем нужно no–local–pass

Этот параметр при конфигурировании юнита был сделан для того, чтобы предотвратить ненужную маркировку пакета как «локального», если по замыслу он таковым не является. Рассмотрим случай, когда у вас есть некая локальная сеть с непрерывным диапазоном адресов, но вы хотите разрешить пользоваться сервером только тем компьютерам сети, которые определены в конфигурационном файле. При этом хочется считать трафик для всей подсети в целом. Вот типичная конфигурация:

service processor

policy name all–ip target proto ip

restrict all drop local pass

unit net name LAN ip 192.168.1.0 mask 255.255.255.0 acct–policy all–ip

unit host name USER1 ip 192.168.1.10

unit host name USER2 ip 192.168.1.12

unit host name USER3 ip 192.168.1.13

В таком случае, машина из локальной сети с адресом 192.168.1.20 сможет пройти наружу, так как она попадает в сеть LAN (unit net name LAN) и пакеты маркируются локальными (restrict local pass). Вы можете избежать этого, создав группу и пометив все указанные компьютеры из этой подсети как принадлежащие группе, однако есть более красивое решение:

unit net name LAN ip 192.168.1.0

mask 255.255.255.0 no–local–pass acct–policy all–ip

В этом случае пакеты от 192.168.1.20 не будут считаться за локальные и не пропустятся.

OID, их автоматическая генерация и перезагрузки

При создании конфигурационного файла, и при добавлении юнитов вручную oid можно не указывать. При этом значение oid генерируется автоматически, так что если набрать show config, значения oid выставятся каким–то случайным образом. ГАРАНТИРУЕТСЯ уникальность номеров OID. Чтобы после рестарта NeTAMS oid остались теми же (и старая статистика не потерялась), необходимо после редактирования конфига или любых изменений в нем через интерфейс программы набирать save, тогда конфигурационный файл перезапишется на тот, что выполняется в данный момент, вместе со значениями oid, и после рестарта статистика продолжит собираться и суммироваться правильно.

Причина подобного требования в том, что OID является также уникальным ключом (PRIMARY KEY) в базе данных, и счетчики привязаны к нему. Кстати, из этого следует, что никто не мешает переименовывать юниты по ходу работы.

Perl API

NeTAMS представляет собой достаточно гибкий инструмент учета трафика и установки некоторых ограничений на работу пользователей. Круг задач, которые можно решить с использованием данной программы, чрезвычайно широк, и у каждого администратора есть свои пожелания по организации работы программы и тому, как она взаимодействует с пользователями. Для облегчения задачи настройки и использования NeTAMS под ваши конкретные задачи был создан интерфейс в виде ряда функций, который позволяет управлять программой и получать от нее данные из ваших написанных самостоятельно Perl–скриптов и CGI–программ.

Для применения интерфейса вы должны включить в начало вашей программы строку:

require «netams_api.pl»

Вот список функций, которые определены в этом интерфейсе:

• $result=netams_login($hostname, $port, $username, $password); — осуществляет соединение с программой, используя указанные параметры. Если $result начинается со слов «Welcome», то соединение прошло успешно

• netams_send($command); — отправляет команду $command на исполнение

• $result=netams_read(); — считывает в переменную $result результат выполнения команды

• $result=netams_readline(); — то же самое, но программа ожидает вывода признака конца строки (перевод строки, "\n»). использовать не рекомендуется

• netams_logout(); — осуществляет разрыв соединения.

Вот список идущих с программой скриптов, которые можно применять на практике или рассматривать как примеры программирования общения с NeTAMS:

• netams_example.cgi — выводит результат выполнения команды show version в виде cgi–программы. после небольшой модификации превращается в утилиту командной строки.

• login.cgi — интерфейс к сервису login.

• netams_graph.cgi — программа, динамически создающая картинки в формате PNG с графическим отображением статистики для заданного юнита и всех его политик учета, за последние неделю или месяц. параметры вызова (метод GET):

• unit=UNIT_NAME — обязательный параметр, определяет имя юнита, для которого будет рисоваться картинка

• policy=POLICY_NAME — имя политики, которая будет отображаться. при отсутствии параметра policy будут отрисованы все активные политики.

• prefix=PREFIX — буква, определяющая временной период графика, W (неделя) или M (месяц) соответственно, по умолчанию =W

• nolegend=FLAG — при любом установленном значении запрещает отрисовку легенды с отображением цвета, которым будет отрисовываться данные о политике.

• Данный скрипт использует модули GD.pm и библиотеку libgd. Для FreeBSD вам надо выполнить что–то вроде cd /usr/ports/graphics/p5–GD ; make install. В текущем каталоге необходимо иметь файл lucon.ttf, это TrueType–шрифт Lucida Console из дистрибутива Windows XP.

Место NeTAMS среди других считалок

Вокруг вертится много разных непонятных названий: ipcad, netflow, NetUP, Cisco, netgraph, биллинг и прочее. Что это все значит и с чем это едят?

Если вы попали на этот сайт, значит вам наверняка надо:

а) Учитывать IP–трафик в сети

б) Брать с кого–то за это деньги (опционально)

Грубо говоря, решением первой задачи занимаются системы учета трафика, второй задачи — системы биллинга.

С задачей учета трафика успешно справляется достаточно большое количество программ. Они имеют (или нет) средства, чтобы:

• Собрать циферки

• Суммировать циферки

• Положить сумму в базу или лог

• Отобразить циферки согласно (сложному) запросу

• Скомандовать внешней программе о превышении (редко)

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

• Счетчики пакетов вашей операционной системы

• Можно делать опрос встроенных счетчиков на правилах ipfw/iptables, но сразу возникают вопросы: кто будет эти правила выставлять–убирать, как часто делать такой опрос (скорость vs. точность), насколько это все удобно и гибко

• Анализ потока NetFlow

• Фирма Cisco Systems придумала способ, как отдавать информацию о промаршрутизированном трафике наружу, другим программам. Это делается при помощи протокола NetFlow, который описан тут. Правильным образом настроенный маршрутизатор периодически отсылает на указанный сервер UDP–пакеты, содержащие Flow Records — информацию о прошедшем трафике, суммированную по разным признакам. Принимающей стороне остается лишь разобрать и переварить пакеты.

• Опрос другого сетевого устройства по SNMP

• Нельзя сказать, что это удачный метод, т.к. стандартные счетчики SNMP содержат только информацию по количеству байтов/пакетов, прошедших через интерфейс, без разделения на протоколы–порты–адреса.

• Встроиться вовнутрь ядра операционной системы и получать статистику «из первых рук»

• Очень быстро работает, но фактически приводит к экспорту логов/потока netflow из ядра, не больше.

• Слушать на интерфейсе

• Широко известная библиотека libpcap позволяет посмотреть на каждый пакет (и его заголовки), проходящий через роутер.

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

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

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

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

В природе существует большое количество «считалок», в разной степени попадающих под вышеприведенное описание. Их хороший обзор приведен тут: http://www.unixfaq.ru/index.pl?req=qs&id=247.

Дальнейшее развитие систем учета трафика — системы биллинга. Их основные свойства:

• Развитый интерфейс управления, настройки, запросов; клиентская часть

• Перевод счетчиков «считалок» в деньги согласно тарифному плану. Тарифные планы могут быть чрезвычайно хитрыми.

• Ведение счетов клиента (платежи, смена планов, блокировка, …)

• Поддержка бухгалтерии (акты, счета, сводки, …)

• Обязательна возможность отключения клиента (с уведомлением)

• Наличие сертификата Минсвязи

Для получения сертификата Минсвязи, позволяющего легально использовать установленную систему биллинга для обслуживания (читай — отъема денег) клиентов, и официально сдать в эксплуатацию узел связи, нужны большие средства. В природе есть несколько дорогих систем (Абсолют, CBOSS, Атлант, IpSoft Billing), и ряд более дешевых (NetUP, LanBilling). В большинстве случаев стоимость биллинговой системы определяется набором модулей (netflow, выделенные линии, VoIP, …), включенных в поставку.

Система биллинга, не имеющая сертификата Минсвязи, особо никому и не нужна.

Модуль биллинга, поставляемый с NeTAMS бесплатно, позволяет создавать новый тип объектов — аккаунт пользователя, привязывать к нему юниты, вести гибкие тарифные планы, управлять счетом клиента и т.д. Вместе с тем, сертификата Минсвязи на этот модуль НЕТ.

Файл префиксов и учет российского/зарубежного трафика

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

Зачастую бывает, что ваш провайдер выставляет вам счет за пользование интернетом, состоящий из двух цифр: стоимость российского трафика и стоимость зарубежного, т.е. результат обмена информацией с зарубежными серверами. Дело в том, что сам провайдер каким–либо образом покупает трафик у более крупных, магистральных провайдеров которые не связываются с мелкими клиентами. При этом, обмен данными с российскими серверами ведется по одним каналам связи, а для общения с зарубежными серверами используются немногочисленный зарубежные каналы. Надо сказать, что суммарная полоса пропускания данных всех российских провайдеров «за рубеж» составляет всего несколько сот мегабит на всю страну, и таких каналов не так и много (десяток, наверное). Естественно, аренда этих каналов стоит существенно дороже по сравнению с внутрироссийскими и внутримосковскими каналами. Представьте на секунду, сколько стоит проложить трансатлантический подводный оптоволоконный кабель на несколько тысяч километров? Это вам не витую пару через этаж кинуть! :) Вот почему зарубежный трафик стоит дороже российского. Вообще, процентов 80 российского трафика прокачивается через АТС номер 9, что на ул.Губкина, в Москве.

Теперь надо определить, как отличить «российский» и «зарубежный» трафик, и как это делает ваш провайдер. Все основано на глобальной маршрутизации в Интернете, которая осуществляется по протоколу BGP. Грубо говоря, все сети, подключенные к интернету, принадлежат некоей Автономной Системе (AS), которая представляет собой набор IP–сетей (адресных пространств), находящихся под единым управлением. Владелец и руководитель автономной системы определяет политику маршрутизации своих подсетей через своих соседей–провайдеров или крупных организаций, имеющих свои автономные системы. Все такие системы соединены логическими связями друг с другом так, что любая машина в интернете может быть связана с любой другой машиной посредством нескольких (3–7) автономных систем, каждая из которых образована несколькими маршрутизируемыми сетями. Более того, протокол позволяет выбирать оптимальный путь пользуясь большим количеством передаваемой между автономными системами вспомогательной информации, и т.д. Возвращаясь к нашему случаю, ваш провайдер определил маршрутизацию российского трафика (т.е. сетей, принадлежащих российским AS, их список известен) через один канал, а всего остального — через другой, и за другие деньги. Соответственно, и со своих клиентов взимается разная плата.

Теперь, если вы хотите у себя учитывать разделение трафика так, как это делает у себя ваш провайдер, вам по–хорошему надо бы поднять у себя маршрутизатор (Cisco, FreeBSD/Zebra,…), поднять на нем сессию iBGP с провайдером, получать от него таблицу роутинга (она часто меняется) и импортировать ее в вашу программу учета трафика. Существует возможность пользоваться менее точной, но более короткой базой ru–networks.txt, построенной на основании таблицы выделенных организациям блоков IP–адресов, которую у себя поддерживает RIPE. В настоящий момент она содержит в себе список около 400 сетей, которые можно назвать «Российскими». Никто не гарантирует, что ваш провайдер будет получать трафик от некоторых таких сетей не через зарубежные каналы, однако я надеюсь, что точность такого разделения будет вполне приемлемой.

Файл ru–networks.txt находится в каталоге addon дистрибутива. К сожалению, летом 2004 года RIPE прекратило поддержку файла, используемого скриптом для построения этого списка, так что дальнейшее расширение базы «русских сетей» нетривиально.

NeTAMS поддерживает файл префиксов в форматах:

A.B.C.D /mask

A.B.C.D/mask

A.B.C.D/masklen

A.B.C.D /masklen

(разница — в пробеле перед маской). Где mask это представление в виде X.X.X.X, а masklen — в битовом, например: /24.

Также возможно использование символов ! — исключить сеть из списка, и # - комментарий (работает только в начале строки).

Таким образом один и тот же файл можно использовать и для NeTAMS, и для FreeBSD: ipfw table

Чтобы подсчитать RU трафик необходимо прописать:

policy name russian target file /usr/local/etc/ru–networks.txt

unit host name myhost ip 192.168.1.10 acct–policy russian

Помните, что совпадение пакета с прописанной сетью в файле означает совпадение политики: для подсчета зарубежного трафика используйте флаг инвертирования(!)

Расхождение в статистике с провайдером

Иногда пользователи NeTAMS задают вопрос: «У меня расхождение в статистике с провайдером 3%. А у моего друга вообще 30%. Почему это ваш NeTAMS неправильно считает?»

NeTAMS считает правильно.

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

В общем случае все выглядит следующим образом: к провайдеру извне (Интернет) на пограничный роутер приходят один или несколько линков, дальше трафик попадает в провайдерскую внутреннюю сеть, после чего перенаправляется на роутер доступа, к которому подключены вы сами. Способ такого подключения может быть очень разным: это или ваш персональный выделенный канал, или разделяемый ресурс (беспроводная сеть или общий ethernet). Далее, трафик попадает на ваш сервер учета (где работает NeTAMS или его flow–коллектор), далее трафик доставляется абонентам вашей сети.

Вы, понятное дело, считаете трафик при помощи NeTAMS. Как это делает провайдер? Вариантов несколько:

• NetFlow (на роутере Cisco)

• SNMP (Cisco или поддерживающее такой механизм устройство)

• ip accounting (на роутере Cisco)

• RADIUS (любое поддерживающее устройство)

По определению, NetFlow учитывает трафик ТОЛЬКО НА ВХОДЕ НА ИНТЕРФЕЙС. Это значит, что посчитанный (читай — добавленный вам в счет) трафик может потом быть отброшенным или модифицированным различными механизмами: access–list, policy routing, NAT, и т.п. С другой стороны, сгенерированный самим роутером или кем–то еще в провайдерской сети трафик в вашу сторону — не посчитается.

Счетчики SNMP, наоборот, снимаются на выходе с интерфейса, однако в них нет разделения по протоколам и портам, зачастую единственно что возможно получить — это количество переданных байт в обе стороны. Если вы связаны с провайдером по ethernet, например, то вам посчитаются все ethernet–броадкасты и IP–броадкасты. Вам зачтутся за полезную нагрузку ethernet–заголовки пакета и ip–заголовки: на маленьких пакетах это до 50%. NeTAMS считает только unicast–пакеты, причем берет за полезную нагрузку длину IP–пакета без layer2–заголовка. ip accounting вроде бы также считает на выходе.

Для учета через RADIUS нужно соединение, поддерживающее aaa accounting, т.е. это применимо только к (псевдо)коммутируемым соединениям вроде dialup или VPN–туннелей, а не к типичному ethernet–подключению.

Итак, то что вас насчитал ваш провайдер — это совсем не то, что оказалось на входе канала в вашу сторону. Далее, при передаче трафика к вам данные имеют большой шанс потеряться. Это касается перегруженных каналов, или таких где ошибок по определению много. Если у вас xDSL–подключение на 2 мегабита, а пользователей ЛВС сотни, это означает что трафик в вашу сторону из интернета к провайдеру может временами превышать эти 2Мбит/с, и он учтётся, но при попадании в низкоскоростной канал к вам — будет неизбежно потерян при переполнении пакетных буферов марштуризатора провайдера. При использовании радиоканала данные могут просто «потеряться» в эфире. Кто говорит вам «мы вас по радио подключили на 11 мегабит, какие там потери?» — смело гоните в шею обманщиков. 11 мегабит — это канальная скорость при максимальном уровне сигнала в режиме точка–точка. На практике получается–50% за счет коррекции ошибок, еще–5%..30% за счет коллизий (вы конечно не одни в сети), еще–5%-30% за счет неустойчивой связи (расстояние, помехи, кривые антенны) и снижении скорости передачи. В итоге вместо «11 мегабит» легко может оказаться 200 килобит и 50% ретрансмитов пакетов.

Наиболее надежным и «безопасным» можно считать подключение к выделенному порту коммутатора провайдера через оптической волокно и пару трансиверов на скорости 100 мегабит или 1 гигабит: в таком канале вряд ли что «пропадет».

Даже если на входящую сетевую плату вашего сервера пришло ровно то, что вам посчитал провайдер, это еще не значит что вы сами все посчитали верно. Сплошь и рядом встречаются ошибки настройки файервола, когда какой–то трафик просто не попадает на учет, какой–то попадает дважды. Ваш сервер тоже генерирует трафик, особенно если у вас там почта или веб. Трансляция адресов также может слегка искажать подсчет. Вывод: нарисуйте схему своей сети и распечатайте таблицы правил firewall, посмотрите что считается, а что летит мимо. Проверьте, что в конфигурационном файле NeTAMS заведены все клиенты. Используйте учет по всей внутренней подсети с параметром no–local–pass.

Наконец, никто не застрахован от влияния «человеческого фактора». Автору известен случай, когда провайдер «случайно» приписал в своем биллинге чужую подсеть, и просил платить за нее.

Подведем итоги. Если расхождения «в вашу пользу», можно, в меру совести, забыть о проблеме. Если вам начисляют «больше», то все зависит от того, «на сколько больше»:

• 0.1% до 1% - вам повезло — это очень хороший показатель точности, можно ничего не делать

• 1% до 10% - ошибки в канале — проверьте загрузку линка в сторону провайдера, ошибки в эфире, «неправильные» правила firewall, неучтенный юнит в конфигурации NeTAMS

• 10% до 30% - возможно это «человеческая» ошибка — неучтенный юнит или недонастроенный firewall

• 100% - трафик посчитан дважды — проверьте правило учета пакетов в NeTAMS

В случае необходимости детального разбирательства можно порекомендовать вести мониторинг юнита типа «сеть» средствами service monitor, запрашивать лог–файлы провайдера и вручную сравнивать цифры, делать выборки из таблиц RAW и SUMMARY вручную и опять же сравнивать с провайдерской детализацией, и думать, думать, думать…

Поддержка RADIUS

Поддержка RADIUS появилась в NeTAMS 3.3.0 (CURRENT) начиная с номера билда 2378 (8 апреля 2005г.)

Что именно поддерживается

В NeTAMS реализована поддержка авторизации доступа к ресурсам внешний сервер–доступа и радиус–сервер, когда последний обращается за паролем и атрибутами к внутренним структурам netams через его Telnet API. Также возможно использование RADIUS–сервера для контроля доступа к статическим веб–страницам. Таким образом, с точки зрения организации провайдерства NeTAMS является базой данных для радиус–сервера. Прозрачно поддерживаются любые методы проверки паролей (PAP/CHAP/MS–CHAP/EAP), т.к. это дело FreeRADIUS а не NETAMS; любое число внешних серверов доступа.

Поддерживается отправка аккаунтинга (данных о трафике) в сторону радиус–сервера через новый тип сервиса storage… type radius (документация).

С версии 3.4.0 появилась поддержка получения аккаунтинга радиус–сервером со стороны NAS, с последующей обратоткой через data–source raw.

Что не поддерживается

Не поддерживается контроль доступа и проверка паролей для пользователей NeTAMS посредством радиус–сервера (т.е. функциональность радиус–клиента; по всей видимости этого и не требуется).

Как работает

Новые функции сосредоточены в:

поддержке авторизации через telnet–интерфейс и/или командную строку

модуле rlm_netams, расширяющего сервер FreeRADIUS

поддержке авторизации доступа к HTML–страницам через mod_auth_radius+новая команда сервиса html (опционально)

В качестве сервера доступа, используемого в качестве клиента нового механизма авторизации, проверялись pppoe+ppp (FreeBSD 5.3) и Windows 2003 RRAS. Таким образом, NeTAMS может успешно авторизовывать и контролировать трафик dialup–и pppoe–и прочих коммутируемых соединений, без необходимости дублировать логины/пароли/настройки в текстовых конфигах и базах данных.

Порядок работы с сервером доступа:

При поступлении запроса на соединение сервер доступа осуществляет проверку прав звонящего (логин/пароль) у радиус–сервера.

Радиус–сервер вызывает код модуля rlm_netams, который извлекает требуемые атрибуты из запроса аутентификации, формирует сообщение, и передает его работающему демону NeTAMS посредством Telnet API.

На основании полученного запроса демон NeTAMS разрешает или запрещает доступ. Если доступ разрешен, в сторону rlm_netams (т.е. радиус–сервера) передаются ряд атрибутов, в частности IP–адрес клиента и набор фильтров. Если сервер передал параметр «Caller–ID» (для PPPoE это МАС–адрес звонящего), и для юнита установлен параметр «mac …», будет проводиться дополнительный контроль и по этому признаку.

rlm_netams копирует ответ демона, формируя RADIUS–ответ для сервера доступа.

сервер доступа отвергает или принимает клиента, устанавливая необходимые параметры соединения.

Порядок работы при авторизации веб–доступа:

Сервис HTML генерирует статические HTML–страницы с данными о трафике, админскую часть и пользовательскую часть. При этом создаются также файлы .htaccess со списком «правильных» пользователей данного URI, файл паролей .htpasswd не поддерживается — заместо него в глобальном конфигурационном файле apache присутствуют записи о RADIUS–авторизации.

HTTP–клиент (бровзер) пытается обратиться к защищенному при помощи .htaccess ресурсу. Происходит запрос пароля (через код 401)

Apache вызывает модуль mod_auth_radius, сообщая тому логин–пароль клиента. Запрос на авторизацию передается радиус–серверу.

Радиус–сервер вызывает код модуля rlm_netams, который извлекает логин–пароль из запроса аутентификации, формирует сообщение, и передает его работающему демону NeTAMS посредством Telnet API.

На основании полученного запроса демон NeTAMS проверяет свою базу пользователей и юнитов, разрешает или запрещает доступ. Ответ пересылается в RADIUS–сервер.

rlm_netams копирует ответ демона, формируя RADIUS–ответ для Apache.

Apache пускает пользователя (бровзер) на страницу, или не пускает его.

Порядок работы при получении accounting пакетов (Start, Stop, Alive) радиус–сервером:

радиус–сервер вызывает код модуля rlm_netams, который извлекает требуемые атрибуты из пакета, формирует сообщение, и передает его работающему демону NeTAMS посредством Telnet API.

Если в пакете Start присутствует In Out, они записываются as–is, если для юнита типа user в пакете присутствует Framed–IP–Address, этот IP–адрес будет установлен данному юниту.

Если в пакете Stop присутствует In Out, они записываются incremental, для юнита типа user IP–адрес обнуляется.

При поступлении пакета Alive, данные In Out записываются incremental.

Если в любом из трех пакетов присутствует Filter–ID=Policy данные будут записаны в эту политику.

Как настроить

Настройка PPPoE/PPP

Очень рекомендуем почитать теорию и примеры и настроить доступ безо всякого netams+radius, для начала.

Допустим что NeTAMS, FreeRADIUS, PPP, PPPoE крутятся на одной машине 192.168.0.1, внешний интерфейс fxp0.

### /etc/ppp/ppp.conf #####################################

default:

enable dns # request DNS info (for resolv.conf)

pppoe:

set log Phase Chat LCP IPCP CCP tun command

set radius /etc/ppp/radius.conf

set speed sync

set timeout 240

set ctsrts off

set accmap 000a0000

enable lqr

set cd 5

enable pap chap

set ifaddr HISADDR 192.168.0.253 # .253 is the server's end

#############################################################

### /etc/ppp/radius.conf ####################################

auth 192.168.0.1 secretkey 5 3

#############################################################

Запуск сервера PPPoE:

/usr/libexec/pppoed–p \* -l pppoe fxp0

Настройка FreeRADIUS

Для начала надо собрать FreeRADIUS из портов или исходников. Пакет не подойдет, т.к. там отсутствуют необходимые заголовочные файлы для сборки нашего собственного модуля.

cd /usr/ports/net/freeradius/

make && make install

Переходим в дистрибутив NeTAMS и копируем наш модуль rlm_netams куда следует; потом собираем:

cd ~/netams/addon/

cp–rp rlm_netams /usr/ports/net/freeradius/work/freeradius–1.0.1/src/modules/

cd /usr/ports/net/freeradius/work/freeradius–1.0.1/src/modules/rlm_netams

gmake

gmake install

Правим конфигурацию FreeRADIUS, чтобы использовать локальный сервер доступа с правильными паролями:

### /usr/local/etc/raddb/clients.conf #######################

client 192.168.0.1 {

secret = secretkey

shortname = pppoe_server

}

#############################################################

И чтобы использовать наш rlm_netams:

### /usr/local/etc/raddb/radius.conf #######################

modules {

netams {

server = «192.168.0.1» # netams server IP

port = 20001 # netams server port

login = «freeradius» # netams access username

password = «ABCDEF» # netams access password

swap–inout = «yes» # swap IN and OUT counters for accounting

defaultpolicy = «RadAcc»# policy for rawdata

billing–login = «no» # check username from unit or billing

}

}

authorize {

netams

}

authenticate {

netams

}

accounting {

netams

}

#############################################################

Настройка NeTAMS

Очень желательно добавить специального пользователя, от имени которого будет идти подключение к NeTAMS:

### /usr/local/etc/netams.cfg ###############################

user oid 0832ED name freeradius password ABCDEF permit radius

#############################################################

Если вы хотите использовать авторизацию доступа к веб–страницам со статистикой через mod_auth_radius, измените:

### /usr/local/etc/netams.cfg ###############################

service html

htaccess radius

#############################################################

Настройка Apache (опционально)

Берем mod_auth_radius отсюда: http://www.freeradius.org/mod_auth_radius/

Компилируем, ставим:

apxs–i–a–c mod_auth_radius.c

Настраиваем апач:

AddRadiusAuth 192.168.0.1:1812 secretkey 5:3

AddRadiusCookieValid 5

AllowOverride All

Запускаем все хозяйство. Допустим, в конфигурационном файле у нас присутствует юнит с именем client1 и паролем abc, у него установлен адрес 192.168.0.111, и есть политика фильтрации с именем filter1 и OID ABCFEF.

Можно проверить работоспособность NeTAMS через утилиту netamsctl:

~#netamsctl radius auth nas login client1 password abc nas–id TEST

1 2

Framed–IP–Address: 192.168.0.111

Filter–ID: ABCFEF filter1

Здесь в первой строке вывода число «1» означает «успешно», далее «2» говорит от том, что последуют две строки параметров.

Первая строка передает IP–адрес этого юнита, Вторая — OID и имя фильтра (может быть затем использовано вашим скриптом if–up). В случае неправильного пароля:

~#netamsctl radius auth nas login client1 password abcef nas–id TEST

0 password incorrect for client1

В обоих случаях информация о событии попадет в лог–файл и таблицу EVENTS базы SQL.

Узнать, как происходит работа RADIUS–сервера, что кому куда передается, можно запустив этот сервер с ключом–X:

/usr/local/sbin/radiusd–X

TODO

• Сделать обработку аккаунтинга, поступающего от NAS–сервера. Видимо, для этого придется сделать новый тип data–source.

• Протестировать работу сервера доступа Cisco (никто не хочет дать тестовый доступ?)

• Сделать более жестким ограничение на тип передаваемого фильтра: сделать новый target radius–filter XXX. Сделать пример скрипта, который этот XXX обрабатывает.

• Сделать аналог rlm_netams для другого RADIUS–сервера? FreeRADIUS считается наиболее распространенным.

Сбор произвольных данных через ds_raw

Начиная с версии NeTAMS 3.4.0 (build 3018) появилась возможность учета произвольных данных с использованием сервиса

service data–source 3

type raw

Команда:

rawdata unit name XXX policy YYY in AAA out BBB as–is [time]

Где XXX и YYY — имена юнита и политики

AAA и BBB — значения в байтах, допускается использование окончаний K, M, G.

As–is означает, что переданные значения напрямую добавятся в поток для данного юнита и присуммируются к статистике.

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

Time — время. Если опущено данные будут учтены с текущим временем.

Вопросы безопасности

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

• Взлом всей системы через программу

• Взлом защиты самой программы

• Действия, приводящие к неверному учету трафика

Автор программы не несет никакой ответственности за ее использование и за тот ущерб, который (явно или неявно) может быть нанесен кому–либо в результате работы этой программы или ее компонентов. Если вы несогласны с этим утверждением, деинсталлируйте программу и все ее компоненты немедленно!

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

Несанкционированный доступ к программе может быть получен путем узнавания пароля и присоединения к программе через telnet. Для защиты от этого пароли на доступ шифруются через crypt(); в статических HTML–страницах пароли заменяются звездочками (show config unsecure). Однако рекомендуется выполнить следующие действия:

• Установите права на чтение конфигурационного файла и лог–файлов только для пользователя root

• Отмените права на чтение локальных файлов HTML–статистики тем, кому не нужно

• Установите (средствами http–сервера) права на просмотр статистики «извне» только тем, кому нужно

• Отмените возможность логина в программу не с локальной машины:

• service server 0

• login localhost

• Отрежьте правилами firewall вашей системы нелокальное подключение к программе:

• ipfw add 100 allow ip from any to any via lo0

• ipfw add 110 deny tcp from any to me 20001

Неправильный учет трафика возможен при неверном расположении правил ipfw/iptables и при получении статистики netflow от неизвестного источника. Для избежания этого:

• Подумайте, как данные ходят по вашей сети

• Нарисуйте схему сети с именами интерфейсов

• Выпишите список имеющихся правил ipfw/iptables и придумайте номер (место) вашего правила, через которое будет осуществляться «заворачивание» трафика

• Если вы используете трансляцию адресов или bridging, подумайте еще раз

• Если вы используете прозрачный http–прокси, подумайте снова

• Если вы используете подсчет потока NetFlow, ОБЯЗАТЕЛЬНО укажите ip–адрес присылающего статистику роутера в описании соответствующего сервиса data–source.

Сбор статистики по протоколу SNMP

Начиная с версии NeTAMS 3.4.0 (build 3018) появилась возможность учета трафика путем опроса счетчиков SNMP удаленных устройств. Данная схема работает при наличии:

• Коммутатора или маршрутизатора, имеющего работающий SNMP–агент и поддерживающий MIB–II (фактически, любое устройство поддерживает этот MIB).

• Сервера UNIX, на котором установлены:

• NeTAMS нужной версии

• Пакет net–snmp версии 5

• Perl–модули к net–snmp

• Perl–модуль Net::Telnet

• Настроенного скрипта addon/snmp2netams.pl

• Настроенного data–source … type raw

Принципы работы

Скрипт addon/snmp2netams.pl опрашивает перечисленные в его заголовке SNMP–устройства, используя заданное значение community. Запрашиваются имена интерфейсов и значения 64–битных счетчиков байт, прошедших через интерфейс:

ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName =

= 1.3.6.1.2.1.31.1.1.1.1

ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInOctets =

= 1.3.6.1.2.1.31.1.1.1.6

ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutOctets =

= 1.3.6.1.2.1.31.1.1.1.10

Полученная таблица преобразуется в формат, приемлемый для команды rawdata сервиса data–source. При этом имя юнита составляется из имени устройства, дефиса и имени интерфейса:

rawdata unit name catalyst1–fa0/1 policy ip

in 1234567 out 7654321 incremental

Название политики учета также задается в скрипте.

При помощи модуля Net::Telnet осуществляется подключение к демону netams, которому передаются команды rawdata. Использование параметра incremental приводит к корректному увеличению счетчиков учета netams (show lift full name catalyst1–fa0/1) при постоянном росте значений SNMP–счетчиков устройства.

Настройка

В заголовке скрипта addon/snmp2netams.pl необходимо:

@devices=(«catalyst»);

Перечислить через запятую заключенные в кавычки имена (hostname) устройств, откуда вы хотите собирать статистику.

$community=«public»;

Коммьюнити для чтения.

$netams_host=«localhost»;

$netams_port=20001;

$netams_login=«admin»;

$netams_password=«aaa»;

Параметры подключения к демону NeTAMS.

$policy_name=«ip»;

Имя политики учета, которая будет использоваться для счетчиков.

Настроить NeTAMS на новый источник данных:

service data–source 2

type raw

Настроить SNMP–устройство для того, чтобы оно могда отдавать статистику по протоколу SNMP. Допустим, что на сервере с адресом 192.168.0.1 работают snmp2netams.pl и сам демон NeTAMS. Для коммутатора Cisco Catalyst его настройки выглядят так:

access–list 1 permit 192.168.0.1

snmp–server community public RO 1

snmp–server ifindex persist

Протестировать скрипт и прописать его периодический запуск (раз в 5…15) минут в cron.

Вы можете включить режим вывода отладочной информации сервисом data–source…raw этой командой:

debug ds_raw

В ответ можно будет наблюдать следующее:

|ds_raw: unit catalyst–fa0/01(004FE6) policy ip(023CAA)

in=1234567, out 7654321,

time=1147365439, type=2, ds=data–source:3

Подробнее об использовании data–source…raw смотрите тут.

Примечания

Дополнительные сведения о настройке протокола SNMP на коммутаторах Cisco Catalyst можно почитать тут. Часто задаваемые вопросы о поддержке SNMP на Cisco собраны тут.

Значения счетчиков SNMP снимаются по длине пакетов на 2 уровне OSI. Это значит, что в суммарную длину входят заголовки IP пакета, и Ethernet–кадра. Также будут учтены все IP и Ethernet броадкасты и мультикасты, коих может быть много. На практике расхождения показателей IP–счетчиков и SNMP–счетчиков могут достигать 30%.

По 10 правил и юнитов

Здесь собрана «лучшая десятка» наиболее интересных и полезных правил (политик) учета трафика, и 10 описаний различных юнитов. Этот документ поможет вам а) лучше понять механизм работы netams и б) наиболее правильным образом создать ваш конфигурационный файл для ваших задач.

политики учета трафика

Задаются в настройках сервиса processor, формат команды имеет вид:

policy name NNNNN target ….

• policy name ip target proto ip

• позволяет выделить весь IP–трафик. простейший случай, т.к. под это правило попадает все, что проходит через netams

• policy name www target proto tcp port 80 81 8080 3128

• определяет TCP–трафик по списку портов, фактически сюда попадет весь WWW–трафик

• policy name t_dns target proto tcp port 53 addr 1.2.3.4

• policy name u_dns target proto udp port 53 addr 1.2.3.4

• policy name extdns target policy–or t_dns u_dns

• если вам вдруг хочется посчитать трафик с/до определенного DNS–сервера, расположенного вне вашей сети и имеющего адрес 1.2.3.4, можно воспользоваться этим примером. для начала определите две политики, отдельно для UDP и TCP (DNS использует оба!), затем скомбинируйте их при помощи правила с логическим ИЛИ

• policy name remote target units oid 0ABCDF

• unit net oid 0ABCDF name remotelan ip 215.236.28.0/24

• если у вас есть удаленный офис, в котором работает подсеть 215.236.28.0/24, можно выделить весь трафик между машинами вашей сети и этой удаленной подсетью. юните назначения target может быть любым — хостом, сетью, кластером. полезно также, если вас интересует трафик до какого–то вашего сервера, расположенного снаружи у провайдера, на collocation.

• policy name anekdotes target addr 217.16.28.51

• аналогичный предыдущему, если вас интересует трафик только до одного определенного ip–адреса, возможно обойтись даже без задания отдельного соответствующего юнита.

• policy name rus target file /etc/ru_networks.txt

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

• policy name cust1_in target proto ip ifindex s10

• policy name cust1_out target proto ip ifindex d10

• policy name isp_up_in target proto ip ifindex s8

• policy name isp_up_out target proto ip ifindex d8

• если ваш маршрутизатор Cisco работает с несколькими каналами «наружу», и каждый подключен через свой физический интерфейс, возможно использовать поле номера интерфейса из потока NetFlow.

• policy name worktime target time 9–18 day Mon–Fri

• по этой политике учтётся только трафик, прошедший с 9 до 18 часов в дни с понедельника по пятницу — рабочее время

• policy name sun_night target day Sun time 00:00–06:00

• по этой политике учтётся только трафик, прошедший с 0 до 6 утра воскресенья

• policy name smb target proto tcp port 135 139 445

• policy name day target time 8–20

• policy name daynotsmb target policy–and day !smb

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

создание юнитов

Задаются в настройках сервиса processor ПОСЛЕ политик, формат команды имеет вид:

unit user oid XXX параметры ….

• unit host name server ip 192.168.0.1 acct–policy ip

• Создается запись о компьютере с IP–адресом 192.168.0.1, ведется учет всего IP–трафика с/на этот адрес

• auto–units 1 type user naming prefix2 «IP — " group CLIENTS

• unit group name CLIENTS acct–policy ip

• unit net name LAN ip 192.168.0.1/24 auto–units 1 acct–policy ip www

• Производится «автодобавление» в конфигурацию всех работающих в сети ip 192.168.0.1/24 юнитов. Юниты получают свои имена на базе двух последних октетов адреса, политики учета ip и www, и помещаются в группу CLIENTS.

• restrict all drop local pass

• unit net name LAN ip 192.168.0.1/24 no–local–pass

• acct–policy ip www

• unit host name pupkin ip 192.168.0.18 acct–policy ip www

• Пользователь Пупкин будет иметь доступ наружу с адреса 192.168.0.18. При этом если юнита с адресом, например, 192.168.0.19, в системе не прописано, этот юнит будет блокирован несмотря на то что адрес проходит по юниту типа «сеть» (192.168.0.1/24). Причина — параметр «no–local–pass».

• unit host name pupkin ip 192.168.0.18 mac 00:03:47:c5:81:33

• acct–policy ip

• Задает MAC–адрес юниту. Если включена проверка соответствия MAC–адресов, то при появлении в сети «вредителя» с другим MAC–адресом, поставившим себе IP–адрес Пупкина, юнит будет блокирован. Также, если пользователи выходят в сеть через PPPoE и RADIUS, то возможно организовать дополнительную проверку на основе этого адреса.

• unit host name pupkin ip 192.168.0.18

• description «Вася Пупкин, д.32 кв.169, тел. 333–22–77»

• email pupkin@gmail.com acct–policy ip

• Значение параметра «description» будут появляться в HTML–страницах со статистикой, что добавляет удобства администратору. Адрес электронной почты юнита используется для сообщения тому о, например, превышении квоты.

• unit host name pupkin ip 192.168.0.18 bw 64K in acct–policy ip

• Пупкин не сможет ничего скачать со скоростью более чем 64 килобита в секунду.

• ВАЖНО! Чтобы ограничение скорости работало, необходимо пересобрать NeTAMS с включенной опцией HAVE_BW. Это делается так: make distclen && FLAGS=-DHAVE_BW make

• unit user name pupkin ip 0.0.0.0 password ABCDEF

• acct–policy ip parent CLIENTS

• Пупкин, имея пустой IP–адрес по умолчанию, может использовать сервис логинов со включенным параметром set–user–ip, для выхода в сеть с любого локального компьютера, используя веб–интерфейс и указанный пароль.

• policy name ip target proto ip

• policy name russian target file /etc/ru–networks.txt

• policy name www target proto tcp port 80 81 8080 3128

• policy name non–www1 target proto ip

• policy name non–www2 target proto tcp port 80 81 8080 3128

• unit host name pupkin ip 192.168.0.18

• acct–policy ip !russian %www non–www1

• Для Пупкина будем считать статистику по IP–трафику, по разубежному трафику, по WWW–трафику, и по всему остальному кроме WWW. Обратите внимание на политику учета non–www1: на самом деле это «весь IP–трафик», однако до учета дойдет только не–WWW–трафик из–за флага "%". Аналогичного эффекта можно добиться, если применить политику «non–www2». Это такая же по сути политика, что и www, однако применена в инвертированном ("!») виде:

• unit host name pupkin ip 192.168.0.18

• acct–policy ip !russian www !non–www2

• Обратите внимание на то что нельзя указывать одно и то же имя политики два раза с разными флагами (например «acct–policy www !www» — неправильно), так как в базе данных статистика сохраняется на основании policy oid, которые должны быть разными

Протоколирование запрошенных ссылок (URL)

Поддержка этой долгожданной возможности появилась в NeTAMS 3.3.3

Что протоколируется

При работе ряда сервисов data–source (кроме netflow) есть возможность «заглянуть» вовнутрь IP–пакета и проанализировать протоколы «выше» чем TCP/IP. Так, к примеру, пользовательский запрос к веб–сайту происходит согласно спецификации протокола HTTP/1.1. При должном анализе проходящих пакетов средствами NeTAMS стало возможным «запоминать» запрашиваемую ссылку и сохранять ее в таблице monitor. В комплекте поставки NeTAMS идет «недоразвитый» скрипт, позволяющий как–то просматривать собранную информацию.

Как включить

Собрать и поставить новую версию NeTAMS

Скачать, как обычно, дистрибутив, распаковать, скомпилировать, установить. При компиляции по умолчанию сборка будет вестись с ключом–DLAYER7_FILTER. Не забудьте установить новые CGI–скрипты, особенно monitor.cgi.

Настроить сервис data–source

Пропишите в конфигурацию нужного сервиса новый параметр: layer7–detect urls

Создать новую политику учета

В конфигурации сервиса processor добавьте описание новой политики:

policy name urls target layer7–detect

Указать политику учета для тех юнитов, которые надо отслеживать

В конфигурации сервиса processor для нужных юнитов добавьте новую политику учета:

unit host name pupkin ip 172.16.1.3 acct–policy urls

или, для всех юнитов

default acct–policy urls

Настроить сервис мониторинга

Как описано в этом документе. Дополнительных действий не требуется. Специально указывать юниты, которые хочется мониторить на layer7, не требуется. Если же вас интересует полный мониторинг какого–то юнита (по–старому), тогда такой юнит указывать все же необходимо.

(Опционально) обновить SQL–таблицу сервиса monitor

Если вы использовали мониторинг ранее (таблица monitor уже существует), ее необходимо обновить:

mysql netams

alter table monitor add column layer7 varchar(80);

Запустить NeTAMS

Проверка работы

Работоспособность механизма мониторинга ссылок можно проверить командами:

#netamsctl show ds

host: localhost port: 20001 login: anton password: aaa

cmd: show ds

Data–source ID=1 type LIBPCAP source xl1:0 loop 82356480 average 35 mcsec

Perf: average skew delay 2676 mcsec, PPS: 1060, BPS: 904985

IP tree: 258 nodes [12] + 4 dlinks [1024] + 254 unodes [20] = 12272 bytes

Flows: 1644/2507 act/inact entries (796992 bytes), 3332872 flows sent

HASH: size=65536, 1644 flows hashed, 1622 nodes used, max chain= 2

FIFO: 0/1871 used/ready messages, each 152, total 284392 bytes

Libpcap xl1 : EN10MB: 83735013 packets received, 488394 dropped

Эта команда показывает, что data–source действительно получает трафик и выдает сервису processor информацию о прошедших потоках.

#netamsctl show monitor

host: localhost port: 20001 login: anton password: aaa

cmd: show monitor

service monitor 1

Monitoring to storage: 1

Units:

Packets monitored: 1985769

Эта команда показывает, что сервис мониторинга получает информацию о потоках и пишет ее в базу.

debug ds_ip

debug monitor

Покажет, определяются ли ссылки в проходящем трафике и идет ли присвоение атрибута LAYER7 информации о потоках.

mysql netams

select count(*) from monitor where layer7 != NULL;

Показывает, сколько строк собралось в таблице мониторинга с информацией о ссылках.

Проблемы

• Мониторинг в SQL базу активно пожирает дисковое пространство! Например, за неделю работы программы, при общем количестве прошедшего трафика порядка 40 гигабайт (82 миллиона пакетов), в таблице мониторинга образовалось 2 миллиона записей). Размер SQL–таблицы и индекса составляет 240 мегабайт.

• Статистика по трафику для записанных в мониторинге ссылок относится не с скаченной информации, а к запросам на скачивание. Т.е. не надо обращать на цифры большого внимания. К сожалению, это обусловленно нессимитричностью хэш–функции преобразования данных IP–заголовка в индекс потока, т.е. трафик «запроса» и «ответа» попадет в разные потоки и длина «ответа», т.е. фактически скаченной по данному запросу информации, в таблице мониторинга не учтется. Изменить такое поведение технически очень непросто.

Отображение статистики

Отображением статистики занимается скрипт monitor.cgi, входящй с дистрибутив. Как им пользоваться — очевидно из его интерфейса. Пара скриншотов:




  • oldrussian.ru/collaborazioni-a-quotidiani-e-periodici-bibliografia-degli-scritti.html
  • oldrussian.ru/v-celyah-zashiti-interesov-kreditorov-procedurami-vneshnego-nablyudeniya-s-nachala-goda-bilo-ohvacheno-148-neplatezhesposobnih-organizacij-stornka-70.html
  • oldrussian.ru/o-k-antonov-100-let-so-dnya-rozhdeniya-aviaciya-i-vremiya-2006-specvipusk.html
  • oldrussian.ru/hvorobi-endokrinno-sistemi-tipovij-navchalnij-plan-programa-specalzac-nternaturi-vipusknikv-vishih.html
  • oldrussian.ru/komentar-do-gospodarskogo-kodeksu-ukrani-znamenskij-mamutov-stornka-52.html
  • oldrussian.ru/translational-research-for-the-prevention-and-control-of-diabetes-and-obesity-r18.html
  • oldrussian.ru/new-titles-added-to-the-catalogue-in-june-2008-6.html
  • oldrussian.ru/tema-53-navchaln-programi-tehnolog-dlya-10-12-klasv-zagalnoosvtnh-navchalnih-zakladv.html
  • oldrussian.ru/konspekt-lekcj-4-metodichn-vkazvki-pp-nazvi-discipln-za-navchalnim-planom.html
  • oldrussian.ru/rozvitku-rinku-fnansovih-poslug-pro-stan-vikonannya-programi-dyalnost-kabnetu-mnstrv-ukrani-ukranskij.html
  • oldrussian.ru/mistress-of-the-empire-25.html
  • oldrussian.ru/department-of-exercise-and-sport-science.html
  • oldrussian.ru/robocha-programa-navchalno-disciplni-dlya-studentv-za-napryamkom-pdgotovki-040104-geografya-specalnstyu-geografya-lvv-lnu-men-vana-franka-2010-23-s-rozrobnik-stornka-2.html
  • oldrussian.ru/global-text-project-topic-4.html
  • oldrussian.ru/drives-power-control-systems-communications-information-engineering.html
  • oldrussian.ru/cherngvskij-derzhavnij-pedagogchnij-unversitet-men-t-g-shevchenka-vsnik-cherngvskogo-derzhavnogo-pedagogchnogo-unversitetu-stornka-35.html
  • oldrussian.ru/iadjective-like-adverbs-the-typology-of-adverbial-agreement.html
  • oldrussian.ru/other-contributions-of-lasswell-lazarsfeld-and-schramm-with-particular-reference-to-the-needs-of-ireland.html
  • oldrussian.ru/simona-evrar-vdohnovitelnica-marata-kogda-lyubov-bila-sankyulotom.html
  • oldrussian.ru/it-was-getting-dark-prakticheskaya-grammatika-sovremennogo-anglijskogo-yazika.html