Документация NetAMS

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

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

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

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

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

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

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

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

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

Поддержка 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 …», будет проводиться дополнительный контроль и по этому признаку.