+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Freeradius раньше показывал точную статистику пропускной способности.

Freeradius раньше показывал точную статистику пропускной способности., RouterOS

eugenevdm

Guest

07.01.2006 12:24:00

Я использую комбинацию PPPoE, Freeradius и MT для отслеживания использования трафика клиентами. Проблема в том, что клиенты не видят точную статистику, пока я не завершаю PPPoE-сессию. Судя по всему, таблица RADACCT обновляется только после окончания сессии клиента. Хотелось бы узнать, возможно ли, если используется отдельный Radius-сервер, предоставлять клиентам точную статистику в любое время, в режиме реального времени. На данный момент я обхожу эту проблему, автоматически завершая сессии каждые 24 часа с помощью атрибута session-timeout, но для большей "стабильности" я бы хотел никогда не отключать клиентские сессии, если это возможно.

tully

Guest

23.01.2006 09:47:00

В одном из сообщений поддержки: Мы не поддерживаем PoD, но у нас есть похожая функция — DM (Disconnect-Message), которая описана в RFC3576. Чтобы включить её, используйте команду “/radius incoming set accept=yes”. В этом меню можно также указать, на каком порту слушать.

savage Guest	#3 0 24.01.2006 07:16:00 FreeRadius, кажется, не поддерживает RFC3576. Я пока не встречал ни одного (бесплатного) Radius-сервера, который бы это делал... Интересная концепция, однако, после быстрого просмотра RFC... Почитаю позже, наверное.

bluestar Guest	#4 0 28.01.2006 20:41:00 У кого-нибудь есть пример синтаксиса сообщения о разрыве соединения Radius или что-то подобное для симуляций?

savage

Guest

14.01.2006 15:44:00

Обновление Acct-Interm? Если установить его на 5 минут, MT будет отправлять обновление данных учета на Radius каждые 5 минут… Что ваш Radius-сервер будет с этим делать – ваше дело. Обычно он будет обновлять мои базы данных, содержащие данные учета.

eugenevdm

Guest

17.01.2006 10:49:00

Я подозревал, что interim – это верный путь. Просто никак не мог понять, почему не работало с Freeradius. Оказывается, менеджерское приложение не обновляло необходимые поля базы данных, хотя и получало обновления. Спасибо за ответ, это направило меня в нужное русло.

sublimespot Guest	#7 0 22.01.2006 03:08:00 Я тоже использую Freeradius для отслеживания использования трафика. Сейчас ищу способ деактивировать аккаунт точки доступа Wi-Fi после того, как он исчерпал лимит трафика.

savage

Guest

22.01.2006 19:15:00

Невозможно. Используй Session-Timeout или другие атрибуты, чтобы ограничить объем данных, которые могут быть получены, переданы или время, которое пользователь может быть на сессии. Radius не подключает/отключает пользователей, это делает Mikrotik, и только когда Radius сообщает Mikrotik, когда это делать (во время AUTHETNICATION).

tully Guest	#9 0 22.01.2006 20:13:00 По-моему, мы поддерживаем отключение через RADIUS – RADIUS может отправлять пакет роутеру с инструкцией отключить клиента. Вам нужно будет уточнить у техподдержки, должно быть, это есть в руководстве. John

savage

Guest

#10

29.01.2006 12:25:00

Большинство Radius серверов это не поддерживают. Судя по всему, RFC очень скупа на детали о том, как сервер должен это реализовать. Но с помощью Radius Client можно отправлять эти атрибуты на Radius Server внутри MT – это должно отключить пользователей. Почитайте RFC, там есть всё, что нужно для отправки. ИМХО, это всё равно ненадежный способ отключения пользователей, так как используется протокол Radius, который основан на UDP, и сообщение об отключении может "потеряться" в перегруженной сети, так как UDP пакет может не дойти до NAS. Лучший вариант, ИМХО, — использовать (в случае FreeRadius) radzap и checkrad скрипты. – Chris.

jager

Guest

#11

29.01.2006 13:19:00

Ты прав. Мы используем PPPoE и radius, и живой пакет отправляется каждые 5 минут. Обычно Mtik правильно отключает пользователя, когда должен это сделать. Но иногда это не происходит, и пользователь остается онлайн. Мы отслеживаем использование пользователей каждые 5 минут, и у нас есть скрипт, который выполняется, если пользователь превышает свои лимиты. Скрипт telnet'ится на роутер и просто удаляет его интерфейс. Просто и примитивно, но работает. Вот скрипт: #!/usr/bin/perl

my $username = $ARGV[0];
my $found=0;

use Data::Dumper;
use Net::Telnet ();

$t = new Net::Telnet (
Host => "192.168.0.1",
Timeout => 10,
Dump_log => "./xyz",
Prompt => '/\[.+\] > $/');

$t->login("MTIKusername", "MTIKpasswd");

$t->cmd("/interface pppoe-server remove \"<pppoe-$username>\"");
$t->cmd("/quit"); Ты также можешь использовать этот telnet-трюк, чтобы делать много других полезных вещей автоматически.

savage

Guest

#12

29.01.2006 16:47:00

Выглядит хорошо. Причина, по которой ты не видишь отключений, когда они должны происходить… странная. Session-Timeout / Idle-Timeout / и т.д. передаются NAS в момент аутентификации, а не во время учетных сессий. Следовательно, если пользователь аутентифицирован, MT ДОЛЖЕН иметь значения тайм-аута. Если MT не слушает один, он не будет слушать ни один — протокол Radius вряд ли предусматривает исключения. Если бы я был тобой, я бы посмотрел журнал Auth-Reply Radius (предполагая, что ты используешь FreeRadius) для сессий, которые не отключаются. Возможно, для этих конкретных сессий значения Session-Timeout/Idle-Timeout не передаются в составе сообщения access-accept. Что касается скрипта… я бы посоветовал выложить его на WIKI. Нам нужно много маленьких подсказок, настроек и скриптов там. Для справки, ты, кажется, не используешь Data::Dumper где-либо в скрипте, удаление использования ускорит его. Я бы также, в принципе, рекомендовал использовать warnings и use strict. – Chris

jager

Guest

#13

31.01.2006 00:42:00

savage, спасибо огромное за твои предложения по скрипту! Конечно, я разберусь с проблемой и попрошу Mtik сделать отключение, как положено. Да, использую freeradius. Посмотрю, что пишет Auth-Reply, но копаться в этом не очень легко. У нас до 250 одновременных PPPoE-соединений, и старенький freeradius получает кучу запросов.

P.S. Сегодня я немного лениться работать... ради бога, сегодня у меня день рождения!

savage

Guest

#14

31.01.2006 02:20:00

С днём рождения, тогда. В качестве заключительной мысли, да, я понимаю, что приведение в порядок/перенастройка Radius-сервера – дело не из лёгких, особенно когда там куча активных сессий. Снова предполагая, что ты используешь MySQL, настройте другой Radius-сервер, используя те же конфигурации и те же базы данных. Затем просто записывайте данные ответа аутентификации на новом сервере для аккаунтов, которые не отключаются. Ты, скорее всего, сможешь протестировать это, просто запустив запросы, которые выполняет FreeRadius против базы данных, с правильными данными пользователя. Либо это твой user-reply (затронет только учётные записи отдельных пользователей – судя по всему, именно это ты и испытываешь), либо group-reply (который, конечно, затронет группы пользователей), который не отправляет правильные атрибуты в FR. Атрибуты, конечно, очень чувствительны к значениям, операторам, а также к регистру, но ты это, наверное, и так знаешь? Кстати, я сейчас не уверен, в каком порядке всё должно быть, без погружения в документацию, но ответ на атрибут в одной таблице перезапишет ответ в другой таблице (нужно использовать приоритеты, если ты указываешь один и тот же атрибут несколько раз). То есть, если user-reply выдаёт Session-Timeout := 10, а group-reply выдаёт Session-Timeout := 86400, результат может быть не таким, как ты хочешь. MT также может обрабатывать дублирующиеся атрибуты по-разному или даже игнорировать их полностью – не знаю, что MT делает внутренне с атрибутами. Наконец, существует также raddump (если я не ошибаюсь), это анализатор пакетов для протокола Radius. Мне самому никогда не приходилось его использовать, но он должен дать тебе полные данные о том, что FR получает и передаёт. Однако я довольно уверен, что те самые пользователи, которые не отключаются, просто имеют проблему с отсутствующим и/или неправильным атрибутом. – Chris

jager Guest	#15 0 31.01.2006 11:43:00 Дикий, спасибо тебе за все твои предложения, я их очень ценю! Поиграю со вторым радиус-сервером (отличная идея!), и выложу, что выясню…

sublimespot

Guest

#16

03.02.2006 19:07:00

Включил Radius с `/radius incoming set accept=yes`. Попробовал выполнить (Disconnect-Message) через командную строку: `echo 'User-Name = 00:00:00:00:00:00" | radclient 192.168.10.10:1700 “disconnect” radpasswd`. В логах Mikrotik пишет "Radius disconnect with no ip provided". Попробовал еще раз: `echo 'ip = 00:00:00:00:00:00" | radclient 192.168.10.10:1700 “disconnect” radpasswd`. И еще: `echo 'user = 00:00:00:00:00:00" | radclient 192.168.10.10:1700 “disconnect” radpasswd`. Результат – Radius incoming упал.

savage Guest	#17 0 03.02.2006 20:06:00 Пожалуйста, прочитайте RFC3576, раздел 2.1. Сообщения о разрыве соединения (DM). Пакет Disconnect-Request отправляется сервером RADIUS для завершения сессии пользователя на NAS и отбрасывания всего связанного контекста сессии. Пакет Disconnect-Request отправляется на UDP-порт 3799 и идентифицирует NAS, а также сессию пользователя, которую необходимо завершить, путем включения идентификационных атрибутов, описанных в разделе 3. Исходя из вышесказанного, на мой взгляд, понятно, что User-Name и один из атрибутов NAS-IP-Address, NAS-Identifier или NAS-IPv6-Address обязательны. Все эти атрибуты указаны и подробно описаны в разделе 3 RFC. ip = и user = даже не являются корректными атрибутами RADIUS. IP = на самом деле MAC-адрес, если вы, случайно, этого не заметили. Неудивлюсь, что это привело к падению MT’s Radius Incoming. Хотя, сотрудники MT, я бы рекомендовал отправлять NAC по любым входящим невалидным запросам – возможно, просто отбрасывать невалидные атрибуты, такие как user = или ip =. Вы, может быть, пробовали: echo 'Please MT will you disconnect MAC 00:00:00:00:00:00' \| radclient 192.168.10.10:1700 "disconnect" radpasswd. Просто мысль. Посты вроде этих очень меня раздражают… извините.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры