| « Новый Год 2010 - Санкт-Петербург → Москва → Саранск | [Часть 2: Cisco 7206 BRAS/SSG] Внедряем профили SSG на Cisco 7206 с целью ограничения скорости и организации псевдо-локалки абонентам PPPoE » |
[Часть 3: заполняем базу, начинаем работу] Внедряем профили SSG на Cisco 7206 с целью ограничения скорости и организации псевдо-локалки абонентам PPPoE
Linux, Сети и администрирование, CiscoВ этой статье я вкратце расскажу вам о том, как правильно организовать управление абонентами с помощью SSG на Cisco 7206.
Фактически Cisco 7206 с IOS 12.2SR является полнофункциональным BRAS и SSG (Subscriber Service Gateway), на котором мы можем тонко управлять обслуживанием абонентов, используя функции SSG.
Если вы уже прочли часть 1 и часть 2, то смело читайте далее.
...
3. Заполнение базы RADIUS необходимыми данными
Прежде чем сесть пить кофе и смотреть на клиентов, ходящих в Internet и меняющихся свежескачанным Linux'ом в локалке через наш BRAS, нам необходимо завести этих клиентов и сопоставленные сервисные группы в базу RADIUS. Особое внимание заострим на заведении сервисных групп, но и про заведение клиента я тоже в этой расскажу.
Эта часть - последняя в статье о настройке связки Cisco BRAS/SSG + RADIUS. Однако она не последняя в цикле статей про Cisco BRAS/SSG.
В следующих статьях я расскажу вам, как перенаправлять "проштрафившихся" абонентов на определенный Web-сервер при заходе на любой сайт, а также - как динамически управлять скоростью и включением/отключением абонентов без разрыва их сессии PPPOE. "Ни единого разрыва" - утопия? Ни разу.
Немного отвлекшись и забежав вперед, давайте все-таки вернемся к теме этой статьи.
В предыдущей части статьй мы спроектировали сервисные группы и ACL, которые будем использовать. Вкратце напомню:
1. Набор групп SSG_ONLINE_<скорость>, приоритет 100 - для каждой скорости абонента
2. SSG_OFFLINE, приоритет 50 - для абонентов, ушедших в оффлайн по причине отрицательного баланса или еще чего
3. SSG_SERVERS, приоритет 25 - для доступа к серверам ушедших в оффлайн абонентов
4. SSG_LAN, приоритет 75 - для доступа к локальным ресурсам на локальной скорости
Для SSG_ONLINE мы используем именованный ACL - Service_Any_Online
Для SSG_OFFLINE мы используем именованный ACL - Service_Any_Offline
Для SSG_LAN мы используем именованные ACL - Service_LAN_In и Service_LAN_Out
Для SSG_SERVERS мы используем именованные ACL - Service_Servers_In и Service_Servers_Out
В описании заполнения базы мы будем активно пользоваться концепцией пользователей и групп RADIUS. Это очень сильно упрощает конфигурацию. Еще раз напоминаю, что каждая сервисная группа SSG является отдельным пользователем RADIUS.
Первым делом подготовим конфигурацию наших сервисных групп в RADIUS. Все сервисные группы должны "отзываться" на один пароль, а значит - самое время завести группу RADIUS для сервисных групп. Заводим.
INSERT INTO `radgroupcheck` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'SVC_GROUP', 'Password', '==', '<тот самый пароль, который мы в предыдущей части задали на Cisco для сервисных групп>');
Эта запись говорит нам о том, что у всех пользователей, принадлежащий группе SVC_GROUP, пароль сверяется с заданным нами в этой записи.
Теперь определим прочие группы RADIUS для разных сервисных групп SSG. Я предпочел использование концепта групп RADIUS для сервисных групп SSG, чтобы не захламлять таблицу radreply записями сервисных групп.
Начнем с групп SVC_ONLINE_* (скоростных групп). У этих групп SSG есть ряд общих параметров, которые мы вынесем в общую группу RADIUS SVC_ONLINE.
INSERT INTO `radgroupreply` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'SVC_ONLINE', 'Cisco-AVPair', '+=', 'ip:traffic-class=in access-group name Service_Any_Online priority 100'),
(NULL, 'SVC_ONLINE', 'Cisco-AVPair', '+=', 'ip:traffic-class=out access-group name Service_Any_Online priority 100'),
(NULL, 'SVC_ONLINE', 'Cisco-AVPair', '+=', 'subscriber:accounting-list=PPPOE'),
(NULL, 'SVC_ONLINE', 'Acct-Interim-Interval', ':=', '300');
Что мы видим? А видим то, что мы задали время периодического обновления аккаунтинга, и то, что надо собственно вести аккаунтинг (PPPOE - это название AAA-группы, созданной нами ранее).
ip:traffic-class - это параметр, позволяющий идентифицировать трафик, попадающий в данную сервисную группу. Все классы проверяются в порядке приоритета (priority), меньше значение приоритета - раньше проверка. Первая же найденная подходящая сервисная группа используется для определения параметров трафика.
Теперь создадим на базе группы SVC_ONLINE сервисные группы для наших абонентов. Предположим, что у нас есть абоненты со скоростью 1024/512 Кбит, и абоненты со скоростью 4096/4096 Кбит (здесь создавайте те варианты, что имеются у вас).
INSERT INTO `radreply` (`id`, `UserName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'SVC_ONLINE_1M_512K', 'Cisco-Service-Info', '+=', 'QU;1024000;D;512000');
INSERT INTO `usergroup` (`UserName`, `GroupName`, `priority`) VALUES
('SVC_ONLINE_1M_512K', 'SVC_GROUP', 1),
('SVC_ONLINE_1M_512K', 'SVC_ONLINE', 2);
INSERT INTO `radreply` (`id`, `UserName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'SVC_ONLINE_4M_4M', 'Cisco-Service-Info', '+=', 'QU;4096000;D;4096000');
INSERT INTO `usergroup` (`UserName`, `GroupName`, `priority`) VALUES
('SVC_ONLINE_4M_4M', 'SVC_GROUP', 1),
('SVC_ONLINE_4M_4M', 'SVC_ONLINE', 2);
Логика проста - мы заводим по пользователю для каждой сервисной группы SSG, запихиваем его в группы SVC_GROUP и SVC_ONLINE, а после - в radreply добавляем собственный параметр скорости для каждой сервисной группы. Это единственное место, где мы используем radreply для параметров сервисных групп SSG. Если есть особое желание - можно и этот момент переписать на группы RADIUS, в radgroupreply/usergroup, но у меня его в процессе не возникло 
Итого мы создали двух пользователей сервисных групп (две сервисные группы SSG) - SVC_ONLINE_1M_512K и SVC_ONLINE_4M_4M - по одной на каждый набор скоростных параметров пользователей.
Обращаю особое внимание на то, что скорость входящего трафика к абоненту задается как UP (U), а исходящего от абонента - как DOWN (D) - мы смотрим на трафик со стороны Cisco.
Теперь займемся группой оффлайновых пользователей, а также доступом к локальной сети.
INSERT INTO `radgroupreply` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'SVC_OFFLINE', 'Cisco-AVPair', '+=', 'ip:traffic-class=in access-group name Service_Any_Offline priority 50'),
(NULL, 'SVC_OFFLINE', 'Cisco-AVPair', '+=', 'ip:traffic-class=out access-group name Service_Any_Offline priority 50'),
(NULL, 'SVC_OFFLINE', 'Cisco-AVPair', '+=', 'ip:inacl=Service_Deny_Any'),
(NULL, 'SVC_OFFLINE', 'Cisco-AVPair', '+=', 'ip:outacl=Service_Deny_Any'),
(NULL, 'SVC_OFFLINE', 'Cisco-Service-Info', '+=', 'QU;10000;D;10000');
INSERT INTO `usergroup` (`UserName`, `GroupName`, `priority`) VALUES
('SVC_OFFLINE', 'SVC_GROUP', 1),
('SVC_OFFLINE', 'SVC_OFFLINE', 2);
Пилим все на 10 килобит (бессмысленно, все равно все заденаено ip:inacl/ip:outacl, но подстраховываемся). С помощью ip:inacl и ip:outacl блокируем весь проходящий через эту сервисную группу трафик - здесь нам пригождается access-list для блокировки трафика, который мы заблаговременно создали. Не забываем, что сервисная группа SSG - это тоже пользователь в RADIUS, и вешаем на этого "пользователя" наши группы SVC_GROUP и SVC_OFFLINE.
INSERT INTO `radgroupreply` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'SVC_LAN', 'Cisco-AVPair', '+=', 'ip:traffic-class=in access-group name Service_LAN_Out priority 75'),
(NULL, 'SVC_LAN', 'Cisco-AVPair', '+=', 'ip:traffic-class=out access-group name Service_LAN_In priority 75'),
(NULL, 'SVC_LAN', 'Cisco-Service-Info', '+=', 'QU;50000000;D;50000000');
INSERT INTO `usergroup` (`UserName`, `GroupName`, `priority`) VALUES
('SVC_LAN', 'SVC_GROUP', 1),
('SVC_LAN', 'SVC_LAN', 2);
Весь локальный трафик пилится на 50 Мбит для каждого абонента. Возможности пилить "на всех" пока что не требовалось, когда потребуется - напишу отдельной статьей, как это делается. Заметьте, что ACL тоже повешены инверсно - опять же, ACL поименованы In/Out с точки зрения абонента (так удобнее воспринимать их наименования), но мы-то смотрим со стороны Cisco.
Осталось создать группу доступа к серверам для заблокированных (оффлайновых) пользователей. Это так же просто:
INSERT INTO `radgroupreply` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'SVC_OFFLINE_SERVERS', 'Cisco-AVPair', '+=', 'ip:traffic-class=in access-group name Service_Servers_Out priority 25'),
(NULL, 'SVC_OFFLINE_SERVERS', 'Cisco-AVPair', '+=', 'ip:traffic-class=out access-group name Service_Servers_In priority 25'),
(NULL, 'SVC_OFFLINE_SERVERS', 'Cisco-Service-Info', '+=', 'QU;1000000;D;1000000');
INSERT INTO `usergroup` (`UserName`, `GroupName`, `priority`) VALUES
('SVC_OFFLINE_SERVERS', 'SVC_GROUP', 1),
('SVC_OFFLINE_SERVERS', 'SVC_OFFLINE_SERVERS', 2);
В целом аналогично локалке, только ACL другие, и пилим на мегабит - чтобы избежать DOS-атаки на серверы от "обиженных" и "ущемленных" пользователей, вовремя не пополнивших баланс.
Вот и все. Теперь все наши параметры сервисных групп готовы. Осталось только развесить сами сервисные группы и несколько прочих параметров по пользователям, для чего необходимо создать несколько RADIUS-групп, которые позволят это делать легко, и не напрягаясь.
Первая группа - группа User_ONLINE, для обычных подключенных пользователей.
INSERT INTO `radgroupcheck` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User_ONLINE', 'Auth-Type', ':=', 'Chap'),
(NULL, 'User_ONLINE', 'Simultaneous-Use', ':=', '1');
INSERT INTO `radgroupreply` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User_ONLINE', 'Session-Timeout', ':=', '3456000'),
(NULL, 'User_ONLINE', 'Acct-Interim-Interval', ':=', '300'),
(NULL, 'User_ONLINE', 'Cisco-Account-Info', '+=', 'ASVC_LAN');
Вешаем на онлайновых пользователей время сессии в 40 дней (больше месяца), время обновления общего аккаунтинга в 300 секунд (5 минут), и сервисную группу локальной сети. Заодно устанавливаем тип авторизации CHAP и запрещаем авторизоваться более 1 раза (правило 1 пользователь = 1 сессия).
Скоростные сервисные группы на каждого пользователя надо вешать отдельно, поэтому это оставим на потом, в группу их не включить.
Теперь - группа для "проштрафившихся" пользователей, ушедших в оффлайн.
INSERT INTO `radgroupcheck` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User_OFFLINE', 'Auth-Type', ':=', 'Chap'),
(NULL, 'User_OFFLINE', 'Simultaneous-Use', ':=', '1');
INSERT INTO `radgroupreply` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User_OFFLINE', 'Acct-Interim-Interval', ':=', '900'),
(NULL, 'User_OFFLINE', 'Cisco-Account-Info', '+=', 'ASVC_OFFLINE'),
(NULL, 'User_OFFLINE', 'Cisco-Account-Info', '+=', 'ASVC_OFFLINE_SERVERS'),
(NULL, 'User_OFFLINE', 'Session-Timeout', ':=', '604800');
С оффлайновыми юзерами проще - на них вешаем группы оффлайна и оффлайновых серверов, интервал аккаунтинга - побольше - 15 минут, все равно там аккаунтить нечего, ну и более 7 дней так сидеть без разрыва не даем (это уже по вкусу). Опять же - CHAP и ограничение в 1 сессию.
Не забываем про то, что адреса пользователям надо выдавать из пула.
INSERT INTO `radgroupreply` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'Pool_USERS', 'Cisco-AVPair', '+=', 'ip:addr-pool=users'),
Создаем группу пула адресов для юзеров, мало ли - вдруг надо будет всем разом пул сменить. А пока назначаем всех в созданный нами пул users.
Ура! Теперь осталось только завести наших пользователей. Процесс не сложный, но все равно опишем его - есть некоторые тонкости.
Кого заводим? Для примера, заведем нескольких пользователей с разными параметрами:
Пользователь User1 (пароль Test1): 1024K/512K, онлайн
Пользователь User2 (пароль Test2): 4M/4M, оффлайн
Пользователь User3 (пароль Test3): 4M/4M, статический IP 64.64.64.111, онлайн
Заводим первого юзера.
INSERT INTO `radcheck` (`id`, `UserName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User1', 'User-Password', '==', 'Test1');
INSERT INTO `radreply` (`id`, `UserName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User1', 'Cisco-Account-Info', '+=', 'ASVC_ONLINE_1M_512K');
INSERT INTO `usergroup` (`UserName`, `GroupName`, `priority`) VALUES
('User1', 'User_ONLINE', 1),
('User1', 'Pool_USERS', 1);
Обратите внимание - как все просто. Заводим пароль пользователя в radcheck. В radreply вешаем пользователю соответствующую скоростную сервисную группу SSG. В usergroup говорим, что пользователь принадлежит группе User_ONLINE, и берет пул согласно группе Pool_USERS. Вуаля. Он уже может логиниться.
Перейдем ко второму, "проштрафившемуся" пользователю.
INSERT INTO `radcheck` (`id`, `UserName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User2', 'User-Password', '==', 'Test2');
INSERT INTO `radreply` (`id`, `UserName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User2', 'Cisco-Account-Info', '+=', 'ASVC_ONLINE_4M_4M');
INSERT INTO `usergroup` (`UserName`, `GroupName`, `priority`) VALUES
('User2', 'User_OFFLINE', 1),
('User2', 'Pool_USERS', 1);
Отличия минимальны. Другая скоростная группа (4096/4096), да вместо User_ONLINE ставим User_OFFLINE, указывая на отключение пользователя. Просто?
Третий пользователь у нас онлайн, однако ему мы хотим выдать статический IP-адрес 64.64.64.111. Заметьте, что этот адрес не входит в наш пул - выдаваемые IP-адреса не обязаны входить в какие-либо пулы адресов. Заводим.
INSERT INTO `radcheck` (`id`, `UserName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User3', 'User-Password', '==', 'Test3');
INSERT INTO `radreply` (`id`, `UserName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User3', 'Cisco-Account-Info', '+=', 'ASVC_ONLINE_4M_4M'),
(NULL, 'User3', 'Framed-IP-Address', ':=', '64.64.64.111');
INSERT INTO `usergroup` (`UserName`, `GroupName`, `priority`) VALUES
('User3', 'User_ONLINE', 1),
Основное отличие в том, что мы не назначаем группу пула адресов в usergroup, а вместо этого - назначаем статический IP в radreply. Не пытайтесь совмещать пул и статический IP для одного пользователя - работать не будет, пользователь не сможет залогиниться - особенность Cisco IOS.
Вот и все - наслаждаемся работающим BRAS'ом и простотой его дальнейшей конфигурации под новых пользователей. Можно автоматизировать заведение пользователей, приделать личный кабинет - словом - реализовать все, что есть в ваших планах. Система получилась структурной и понятной интуитивно.
Аккаунтинг в этой системе тоже очевиден - взглянув в таблицу RadAcct во время работы пользователей, вы быстро разберетесь, что к чему. Хочу отметить одну особенность (глюк) Cisco IOS - общий аккаунтинг (с ServiceInfo = '') не учитывает дропнутые пакеты, а аккаунтинг по сервисным группам (ServiceInfo = 'SVC_ONLINE_*' в нашем случае) - учитывает. Поэтому трафик "внешний" легко может получаться немножко большим, чем трафик "общий" - будьте осторожны, отображая обе части информации клиенту - разница очень мала (обычно), но она все-таки может быть.
На этом хочу завершить данную статью. Надеюсь, она поможет вам создать или оптимизировать собственную систему доступа.
Осталось лишь пожелать всем работающим инженерами в провайдерах успехов в их нелегкой деятельности. Ждите обещанных продолжений.
Sincerely,
Alex/AT.
Трекбек адрес этой записи
URL трекбека (щелкните правой кнопкой мыши и скопируйте ссылку)
RSS лента комментариев этой записи
Имя сервиса в таблице будет соответствовать сервисной группе абонента для внешнего трафика, и останется пустым - для внутреннего трафика, это описано в статье.
А собственно учет трафика по сервисам включает следующее:
(NULL, 'SVC_ONLINE', 'Cisco-AVPair', '+=', 'subscriber:accounting-list=PPPOE'),
при этом на кошке настроены соответствующие группы учета.
Это тоже описано выше. Стоило все-таки читать не бегло, а вдумчиво (если оно вам нужно, конечно).
Отчет понравился, поэтому и сам задумался пользователей регистрировать в базе, сейчас они хранятся а файле.
У меня работает несколько PPtP серверов на основе Микротик, авторизация и аккаунтинг на Радиус (freeradius2). Пользователи хранятся в файле. На тестовых компах поднял PPTP сервер на др. компе Freeradius2 + MySQL-5
Пользователя я регистрирую в файле так
testsql Cleartext-Password := "test123", Simultaneous-Use := 1, Calling-Station-Id == "172.20.24.70", Pool-Name := "private_ip_pool"
Mikrotik-Rate-Limit += "8192k/8192k"
Для регистрации такого пользователя в базе, я в таблицу radchek добавил
| 1 | testsql | Cleartext-Password | := | test123
В таблицу radgroupcheck
dynamic | Auth-Type | := | Local
В таблицу radgroupreply
1 | dynamic | Service-Type | = | Framed-User |
| 2 | dynamic | Frame-Protocol | = | PPP |
| 3 | dynamic | Frame-Routing | = | Broadcast-Listen |
| 4 | dynamic | Framed-Filter-Id | = | "std.ppp" |
| 5 | dynamic | Framed-MTU | = | 1460 |
| 6 | dynamic | Framed-Compression | = | Van-Jacobsen-TCP-IP |
| 7 | dynamic | Fall-Through | = | Yes
С остальными таблицами не совсем все понятно. Сервера доступа оставил пока в файле clients.conf или лучше задействовать таблицу nas ?
Jun 14 13:28:24.660: RADIUS: Cisco AVpair [1] 18 "ip:addr-pool=102"
тоже самое и с сервисами, вроде они приходят, но не применяются. Что может быть не так?
Cisco IOS Software, 7200 Software (C7200P-JS-M), Version 12.2(31)SB12, RELEASE SOFTWARE (fc3)
ROM: System Bootstrap, Version 12.4(12.2r)T, RELEASE SOFTWARE (fc1)
Cisco 7206VXR (NPE-G2) processor (revision A) with 524288K/262144K bytes of memory.
w:/etc# freeradius -v
freeradius: FreeRADIUS Version 2.0.4, for host i486-pc-linux-gnu, built on Sep 7 2008 at 23:35:34
Еще бы неплохо show subscriber session detail и show subscriber service detail.
Да, у вас нумерованный IP Pool?
разобрался с пулом
дописал в глобал aaa authorization network PPPOE group MY_RADIUS
но сервисы всеравно не применяются, хоть и по радиусу приходят.
pppoe#show subscriber session detail
Current Subscriber Information: Total sessions 1
--------------------------------------------------
Unique Session ID: 15
Identifier: alexwp
SIP subscriber access type(s): PPPoE/PPP
Current SIP options: Req Fwding/Req Fwded
Session Up-time: 00:00:43, Last Changed: 00:00:43
Interface: Virtual-Access2.1
Policy information:
Context 06E1E6A0: Handle C3000019
AAA_id 0000001D: Flow_handle 0
Authentication status: authen
Non-datapath features:
Feature: IP Config
Peer IP Address: 0.0.0.0 (F/F)
Address Pool: 102 (F)
Unnumbered Intf: [None]
Feature: Session Timeout
Timeout value is 3456000 seconds
Time remaining is 3w3d
Configuration sources associated with this session:
Interface: Virtual-Template1, Active Time = 00:00:43
pppoe#
pppoe#show subscriber service detail
pppoe#
бебаг радиуса со стороны киски нужен? как лучше его запустить? (я про дебаг, ибо из того что включил не много видно)
Если можно вопрос: если у абонента при "живой" сессии изменить параметры в БД (например перевод на другой тариф, в оффлайн и т.п.), как я понимаю все эти изменения его никак не коснутся и он продолжит работать пока или сам не переконнектится (и получит уже новые параметры) или как-то его принудительно "сбросить" с линии. Немного непонятно как это сделать "налету". Если я бегу вперед паровоза и все это будет рассмотрено в продолжении - извиняюсь.
Заранее спасибо за ответ.
aaa authorization network PPPOE group MY_RADIUS
а без этого Framed-ipAddress не устанавливается
Если уж пишите так пишите пожалуйста без ошибок
))))
Добавил строчку в конфиг, спасибо :) Проверить уже не смогу - на данный момент Cisco 72xx в продакшне как BRAS не использую, только ATLAC (см. раздел в блоге).
А как изменить скорость абоненту "на лету"?
Как перевести его допустим из группы
SVC_ONLINE_1M_512K
в группу
SVC_ONLINE_4M_4M
не разрывая сессию?
Все сделано как в статье
Моя система:ISG= CISCO 7200 12.2(33)SRC, RADIUS+портад=CenOS5.5(Apache2,MySQL5,Freeradius2)
Основной показатель что все работает это наличие услуг в сессиях клиентов:
(смотрим sh sss sess det)
Если не идет, проверьте наличие
aaa authorization subscriber-service default group MY_RADIUS
в конфиге киски.
Теперь
Для обращения к киске с COA заводим клиента:
=конфиг=
...
aaa server radius dynamic-author
client 172.27.72.123 server-key 7 02050D480809
auth-type any
ignore session-key
ignore server-key
...
=/конфиг=
Для изменения активной услуги для клиента без разрыва сессии используем radclient (на примере изменения скорости) :
активация услуги:
[user@host bin]# /bin/echo "User-Name=\"user\",Acct-Session-Id=\"0/0/2/0_AC1B484500000067\",cisco-avpair=\"subscriber:command=activate-service\",cisco-avpair=\"subscriber:service-name=SVC_ONLINE_4M_4M\"" | /usr/bin/radclient -x4 Х.Х.Х.Х:1700 coa password
здесь:
0/0/2/0_AC1B484500000067 - ID сессии клиента, которому примеяем услугу;
Х.Х.Х.Х:1700 - IP и порт ISG ,на котором он слушает пакеты COA от радиуса.
password тот что задали выше.
деактивация отличается только AV парой subscriber:command=deactivate-service
Однажды активированные сервисы остаются в памяти ISG,
Все работает))). Пора перейти к оформлению портала.
Почему когда клиент коннектится pppoe киска отдает mac-адрес, а при pptp - нет.?
Как при схеме, описанной в данной статье привязать логин к mac-адресу?
Сегодня -редирект (перенаправляем проштрафившегося пользователя на определенный ресурс)
Напомню, если не говорил, что примеры конфигурации взяты мною в Интернете, так что на авторство не претендую, лишь собираю на стенде проверяю и если работает - выкладываю. Надеюсь и даже уверен что многим начинающим поможет.)))
Итак редирект: Если клиент у нас в OFFLINE, то соединение PPPOE проходит успешно, НО при попытке открыть любую страничку в интернет (в нашем случае именно службы www = 80 порт), делаем перенаправление на наш портал, на страницу, напоминающую что пора бы оплатить услуги )))
На CISCO :
=конфиг=
redirect server-group WWW_PORTAL
server ip ХХ.ХХ.ХХ.ХХ port 80
access-list 197 permit tcp any any eq www
access-list 197 permit tcp any eq www any
access-list 197 deny ip any any
/=конфиг=
На RADIUS:
INSERT INTO `radgroupreply` (`id`, `GroupName`, `Attribute`, `op`, `Value`) VALUES
(NULL, 'User_OFFLINE','Cisco-Account-Info','+=', 'ASVC_OFFLINE_REDIR');
(NULL, 'SVC_OFFLINE_REDIR', 'Cisco-AVPair', '+=', 'ip:traffic-class=in access-group 197 priority 20'),
(NULL, 'SVC_OFFLINE_REDIR', 'Cisco-AVPair', '+=', 'ip:traffic-class=out access-group 197 priority 20'),
(NULL, 'SVC_OFFLINE_REDIR', 'Cisco-AVPair', '+=', 'ip:traffic-class=in default drop'),
(NULL, 'SVC_OFFLINE_REDIR', 'Cisco-AVPair', '+=', 'ip:traffic-class=out default drop'),
(NULL, 'SVC_OFFLINE_REDIR', 'ip:l4redirect=redirect list 197 to group WWW_PORTAL');
INSERT INTO `usergroup` (`UserName`, `GroupName`, `priority`) VALUES
('SVC_OFFLINE_REDIR', 'SVC_GROUP', 1),
('SVC_OFFLINE_REDIR', 'SVC_OFFLINE_REDIR', 2);
Вот так работает. Ну если в URL не HTTP то думать придется долго , однако .... ;)))
Юзера авторизировала, пул назначила и пр.. По идеии должна авторизировать сервис "ASVC_ONLINE_1024K_512K", но увы тишина.
Прописываешь aaa authorization subscriber-service default group MY-RADIUS,
пытается авторизировать сервис, но в ответ: Received from id 1645/71 10.10.2.41:1812, Access-Reject, len 20
Что может быть? Куда копать?
вот дебаг:
*Mar 9 14:03:29.895: RADIUS/ENCODE: Best Local IP-Address 10.10.2.40 for Radius-Server 10.10.2.41
*Mar 9 14:03:29.895: RADIUS(0000005F): Send Access-Request to 10.10.2.41:1812 id 1645/70, len 130
*Mar 9 14:03:29.895: RADIUS: authenticator 21 E8 BC 60 EA 17 CE 37 - F4 18 67 FD 70 88 65 D9
*Mar 9 14:03:29.895: RADIUS: Framed-Protocol [7] 6 PPP [1]
*Mar 9 14:03:29.895: RADIUS: User-Name [1] 7 "User1"
*Mar 9 14:03:29.895: RADIUS: CHAP-Password [3] 19 *
*Mar 9 14:03:29.895: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
*Mar 9 14:03:29.895: RADIUS: NAS-Port [5] 6 0
*Mar 9 14:03:29.895: RADIUS: NAS-Port-Id [87] 10 "0/0/2/71"
*Mar 9 14:03:29.895: RADIUS: Service-Type [6] 6 Framed [2]
*Mar 9 14:03:29.895: RADIUS: NAS-IP-Address [4] 6 10.10.2.40
*Mar 9 14:03:29.895: RADIUS: Acct-Session-Id [44] 18 "0A0A022800000055"
*Mar 9 14:03:29.895: RADIUS: Nas-Identifier [32] 26 "Aktau.ATC-50.Core-SSG.40"
*Mar 9 14:03:29.903: RADIUS: Received from id 1645/70 10.10.2.41:1812, Access-Accept, len 143
*Mar 9 14:03:29.903: RADIUS: authenticator 5F 59 BC AF 0B 9A 9A 1E - FC 51 44 3D 69 D6 A3 6C
*Mar 9 14:03:29.903: RADIUS: Framed-IP-Address [8] 6 255.255.255.254
*Mar 9 14:03:29.903: RADIUS: Framed-MTU [12] 6 576
*Mar 9 14:03:29.903: RADIUS: Service-Type [6] 6 Framed [2]
*Mar 9 14:03:29.903: RADIUS: Framed-Protocol [7] 6 PPP [1]
*Mar 9 14:03:29.903: RADIUS: Framed-Compression [13] 6 VJ TCP/IP Header Compressi[1]
*Mar 9 14:03:29.903: RADIUS: Vendor, Cisco [26] 26
*Mar 9 14:03:29.903: RADIUS: Cisco AVpair [1] 20 "ip:addr-pool=users"
*Mar 9 14:03:29.903: RADIUS: Session-Timeout [27] 6 3456000
*Mar 9 14:03:29.903: RADIUS: Acct-Interim-Interva[85] 6 300
*Mar 9 14:03:29.903: RADIUS: Vendor, Cisco [26] 29
*Mar 9 14:03:29.903: RADIUS: ssg-account-info [250] 23 "ASVC_ONLINE_512K_512K"
*Mar 9 14:03:29.903: RADIUS: Vendor, Cisco [26] 26
*Mar 9 14:03:29.903: RADIUS: Cisco AVpair [1] 20 "ip:addr-pool=users"
*Mar 9 14:03:29.903: RADIUS(0000005F): Received from id 1645/70
*Mar 9 14:03:29.903: RADIUS/ENCODE(0000005F):Orig. component type = PPoE
*Mar 9 14:03:29.903: RADIUS: AAA Unsupported Attr: password [274] 6
*Mar 9 14:03:29.903: RADIUS: 61 73 73 32 [ ass2]
*Mar 9 14:03:29.903: RADIUS: AAA Unsupported Attr: interface [185] 8
*Mar 9 14:03:29.903: RADIUS: 30 2F 30 2F 32 2F [ 0/0/2/]
*Mar 9 14:03:29.903: RADIUS: AAA Unsupported Attr: client-mac-address[56] 14
*Mar 9 14:03:29.903: RADIUS: 38 38 61 65 2E 31 64 38 39 2E 63 66 [ 88ae.1d89.cf]
*Mar 9 14:03:29.903: RADIUS(0000005F): Config NAS IP: 0.0.0.0
*Mar 9 14:03:29.903: RADIUS/ENCODE(0000005F): acct_session_id: 85
*Mar 9 14:03:29.903: RADIUS(0000005F): Config NAS IP: 0.0.0.0
*Mar 9 14:03:29.903: RADIUS: Attribute 55 not sent, as system clock is not set
*Mar 9 14:03:29.903: RADIUS(0000005F): sending
*Mar 9 14:03:29.903: RADIUS/ENCODE: Best Local IP-Address 10.10.2.40 for Radius-Server 10.10.2.41
*Mar 9 14:03:29.903: RADIUS(0000005F): Send Access-Request to 10.10.2.41:1812 id 1645/71, len 138
*Mar 9 14:03:29.903: RADIUS: authenticator 17 A3 31 34 77 FB 0E 87 - DE 97 FD 51 89 D0 50 24
*Mar 9 14:03:29.903: RADIUS: User-Name [1] 22 "SVC_ONLINE_512K_512K"
*Mar 9 14:03:29.903: RADIUS: User-Password [2] 18 *
*Mar 9 14:03:29.903: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
*Mar 9 14:03:29.903: RADIUS: NAS-Port [5] 6 0
*Mar 9 14:03:29.903: RADIUS: NAS-Port-Id [87] 10 "0/0/2/71"
*Mar 9 14:03:29.903: RADIUS: Service-Type [6] 6 Outbound [5]
*Mar 9 14:03:29.903: RADIUS: NAS-IP-Address [4] 6 10.10.2.40
*Mar 9 14:03:29.903: RADIUS: Acct-Session-Id [44] 18 "0A0A022800000055"
*Mar 9 14:03:29.903: RADIUS: Nas-Identifier [32] 26 "Aktau.ATC-50.Core-SSG.40"
*Mar 9 14:03:34.259: RADIUS: Retransmit to (10.10.2.41:1812,1813) for id 1645/71
*Mar 9 14:03:34.259: RADIUS: Received from id 1645/71 10.10.2.41:1812, Access-Reject, len 20
*Mar 9 14:03:34.259: RADIUS: authenticator DD 8E 47 EC 94 CE 88 C9 - 45 D1 22 17 51 97 32 5D
*Mar 9 14:03:34.259: RADIUS(0000005F): Received from id 1645/71
1. Проверьте пользователя SVC_ONLINE_512K_512K в базе RADIUS
2. Проверьте пароль данного пользователя
3. Проверьте метод авторизации - PAP или CHAP, выставленный для данного пользователя
А вообще в данном вопросе может очень помочь утилита radtest. Прикиньтесь клиентом RADIUS, и попробуйте авторизоваться.
Спасибо!
Статья очень помогла разобраться принципами с SSG!
По юзал форумы. Пришёл к выводу, что одна 7206 нормально работает с 1500-2000 пользователями. Если клиентов становится больше, то челы с форумов добавляют ещё одну железку!!!
Погуглив, как такое делать, ничего не нашёл.
Не пробывал запускать паралельно ещё второй SSG?
Есть вариант разделить их в разные vlanы, но как то не хочется вланы плодить!
Если есть мысли как это сделать, поделись.
Сейчас уже с 72xx не работаю - у меня стоят свои концентраторы (@Net ATLAC, описаны на этом же блоге). Насчет 1500-2000 пользователей, такое возможно только при очень низких скоростях, поскольку на практике G1 не пропустит через себя больше гига трафика при двух SG на юзера, G2 - больше двух.
Sending CoA-Request of id 30 to 10.10.200.13 port 1700
получаю следующий ответ от циски
rad_recv: CoA-NAK packet from host 10.10.200.13:1700, id=30, length=39
Cisco-Command-Code = "\0202;adiltest"
никаких изменений в установленной сессии нету..
Спасибо за внимание!