Mikrotik.moscow [тема: Freeradius раньше показывал точную статистику пропускной способности.]

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

Fri, 03 Feb 2006 20:06:00 -0500

Freeradius раньше показывал точную статистику пропускной способности. RouterOS в форуме RouterOS.
Пожалуйста, прочитайте 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. Просто мысль. Посты вроде этих очень меня раздражают… извините.
03.02.2006 20:06:00, savage.

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

Fri, 03 Feb 2006 19:07:00 -0500

Freeradius раньше показывал точную статистику пропускной способности. RouterOS в форуме RouterOS.
Включил 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 упал.
03.02.2006 19:07:00, sublimespot.

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

Tue, 31 Jan 2006 11:43:00 -0500

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

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

Tue, 31 Jan 2006 02:20:00 -0500

Freeradius раньше показывал точную статистику пропускной способности. RouterOS в форуме RouterOS.
С днём рождения, тогда. В качестве заключительной мысли, да, я понимаю, что приведение в порядок/перенастройка 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
31.01.2006 02:20:00, savage.

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

Tue, 31 Jan 2006 00:42:00 -0500

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

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

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

Sun, 29 Jan 2006 16:47:00 -0500

Freeradius раньше показывал точную статистику пропускной способности. RouterOS в форуме RouterOS.
Выглядит хорошо. Причина, по которой ты не видишь отключений, когда они должны происходить… странная. 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
29.01.2006 16:47:00, savage.

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

Sun, 29 Jan 2006 13:19:00 -0500

Freeradius раньше показывал точную статистику пропускной способности. RouterOS в форуме RouterOS.
Ты прав. Мы используем 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 \"\"");
$t->cmd("/quit"); Ты также можешь использовать этот telnet-трюк, чтобы делать много других полезных вещей автоматически.
29.01.2006 13:19:00, jager.

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

Sun, 29 Jan 2006 12:25:00 -0500

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

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

Sun, 22 Jan 2006 20:13:00 -0500

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

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

Sun, 22 Jan 2006 19:15:00 -0500

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

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

Sun, 22 Jan 2006 03:08:00 -0500

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

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

Tue, 17 Jan 2006 10:49:00 -0500

Freeradius раньше показывал точную статистику пропускной способности. RouterOS в форуме RouterOS.
Я подозревал, что interim – это верный путь. Просто никак не мог понять, почему не работало с Freeradius. Оказывается, менеджерское приложение не обновляло необходимые поля базы данных, хотя и получало обновления. Спасибо за ответ, это направило меня в нужное русло.
17.01.2006 10:49:00, eugenevdm.

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

Sat, 14 Jan 2006 15:44:00 -0500

Freeradius раньше показывал точную статистику пропускной способности. RouterOS в форуме RouterOS.
Обновление Acct-Interm? Если установить его на 5 минут, MT будет отправлять обновление данных учета на Radius каждые 5 минут… Что ваш Radius-сервер будет с этим делать – ваше дело. Обычно он будет обновлять мои базы данных, содержащие данные учета.
14.01.2006 15:44:00, savage.

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

Sat, 28 Jan 2006 20:41:00 -0500

Freeradius раньше показывал точную статистику пропускной способности. RouterOS в форуме RouterOS.
У кого-нибудь есть пример синтаксиса сообщения о разрыве соединения Radius или что-то подобное для симуляций?
28.01.2006 20:41:00, bluestar.

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

Tue, 24 Jan 2006 07:16:00 -0500

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

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

Mon, 23 Jan 2006 09:47:00 -0500

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

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

Sat, 07 Jan 2006 12:24:00 -0500

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