RedBack CLIPS
Материал из BiTel WiKi
CLIPS - это технология, используемая в оборудовании фирмы Ericsson для аутентификации, авторизации и аккаунтинга абонентов IPOE. Принципы CLIPS подробно описаны в документе "Clips HOWTO" ( http://shop.nag.ru/article/clips ).
В данной статье будет описана интеграция маршрутизатора SE100 с АСР BGBilling для работы с абонентами CLIPS.
Аутентификации абонентов происходит по порту коммутатора с использованием DHCP опции 82. В нашем случае SE100 является основным шлюзом и релеем для абонентов. Используется посервисный аккаунтинг, причем учитывается только внешний трафик.
Содержание |
Схема сети
Клиент - Коммутатор с Options.82 - SE100 - Мир | Сервер биллинга
Коммутатор проставляет Options.82 свой идентификатор, порт клиента и пересылает запрос на SE100 широковещательно. Из сети 172.16.23.0/24 выдаётся IP адрес авторизованным клиентам, из 172.16.25.0/24 - блокированным с установкой редиректа на страницу HTTP с ошибкой.
При необходимости блокировки сессии клиента устанавливается редирект на текущую сессию посредством CoA, делается пометка в DHCP сервере о истечении аренды. По следующему DHCP запросу отправляется NaK, после чего редбек завершает сессию и начинает новую. В новой сессии выдаётся уже адрес из пула фейковых адресов 172.16.25.0/24.
Сессия поднимается по Update пакету, т.к. в старт пакете отсутствует IP адрес. IP адрес перекладывается из атрибута Assigned-IP-Address в стандартный Framed-Ip-Address скриптов предобработки.
Из ответа авторизации Framed-Ip-Address удаляется, т.к. иначе редбек не шлёт DHCP запрос.
Трафики считаются суммарные по данным атрибутов Acct-Input/Output-Octets, Acct-Input/Output-Gigawords.
Процесс аутентификации
Когда клиент инициирует получение адреса, коммутатор вставляет в запрос опцию 82 и запрос попадает на интерфейс SE100.
Конфиг коммутатора (для примера возьмем D-link 3526):
# dhcp_local_relay позволяет вставлять в приходящие от абонентов DHCP-запросы опцию 82. enable dhcp_local_relay config dhcp_local_relay vlanid 2000 state enable # 2000 - вилан, настроенный на абонентских портах
Конфиг SE100:
context IPOE ! no ip domain-lookup ! # Интерфейс, к которому будут "биндиться" абоненты после авторизации interface CLIENTS multibind ip address 193.x.x.1/24 dhcp proxy 65535 ip arp secured-arp ! # Интерфейс, к которому будут "биндиться" абоненты, не прошедшие авторизацию (аналог Reject-To-Accept) interface NOAUTH multibind ip address 172.16.24.1/24 dhcp proxy 65535 ! # Интерфейс для общения с Radius-сервером interface loop0 loopback ip address 172.16.19.1/32 ip source-address radius dhcp-server no logging console logging syslog 194.xx.xx.2 facility local7 ! # Акцесс-лист для абонентов, не прошедших авторизацию. Разрешает работу DNS и DHCP, а также позволяет выйти на страницу управления и сайт провайдера. policy access-list HTTP-REDIRECT seq 10 permit tcp any host 194.xx.xx.10 eq www class CLS-NORMAL seq 19 permit udp any host 194.xx.xx.6 eq domain class CLS-NORMAL seq 20 permit tcp any host 194.xx.xx.3 eq www class CLS-NORMAL seq 21 permit udp any eq bootpc host 193.xx.xx.1 eq bootps class CLS-NORMAL seq 22 permit udp any eq bootpc host 172.16.24.1 eq bootps class CLS-NORMAL seq 30 permit tcp any any eq www class CLS-REDIRECT seq 40 permit ip any any class CLS-DROP ! # Классы для разделения трафика по зонам (локальный и внешний) policy access-list SUB-IN seq 10 permit ip any 194.xx.xx.0 0.0.1.255 class INTERNAL seq 20 permit ip any 193.xx.xx.0 0.0.3.255 class INTERNAL seq 30 permit ip any any class EXTERNAL ! policy access-list SUB-OUT seq 10 permit ip 194.xx.xx.0 0.0.1.255 any class INTERNAL seq 20 permit ip 193.xx.xx.0 0.0.3.255 any class INTERNAL seq 30 permit ip any any class EXTERNAL ! # Профиль http-редиректа (всех не прошедних авторизацию перенаправлять на страницу с ошибкой) http-redirect profile NOAUTH url "http://noauth.provider.ru/" # Настройки Radius aaa authentication administrator local aaa authentication administrator maximum sessions 1 aaa authentication subscriber radius aaa accounting subscriber radius aaa update subscriber 10 aaa accounting event dhcp aaa hint ip-address radius accounting server 194.xx.xx.10 encrypted-key 5FD62606082DAF92 port 11813 radius coa server 194.xx.xx.10 encrypted-key 5FD62606082DAF92 port 3799 ! radius server 194.xx.xx.10 encrypted-key 5FD62606082DAF92 port 11812 radius attribute nas-ip-address interface loop0 radius attribute nas-port format session-info radius attribute nas-identifier Redback-IPOE ! # Полиси по умолчанию для абонента (переопределяется через Radius-атрибуты) subscriber default qos policy policing DEF-IPOE-IN qos policy metering DEF-IPOE-OUT ! # Профиль сервиса. В нем задаются параметры подключения (скорость), а также указывается на то, что учет трафика необходимо вести по qos классу EXTERNAL radius service profile RSE-SVC-EXT parameter value Rate 100000 parameter value Burst 12500000 accounting in qos EXTERNAL accounting out qos EXTERNAL seq 10 attribute Dynamic-Policy-Filter "ip in forward class EXTERNAL qos" seq 20 attribute Dynamic-Policy-Filter "ip out forward class EXTERNAL qos" seq 30 attribute Dynamic-Qos-Parameter "meter-class-rate EXTERNAL rate-absolute $Rate" seq 40 attribute Dynamic-Qos-Parameter "meter-class-burst EXTERNAL $Burst" seq 50 attribute Dynamic-Qos-Parameter "police-class-rate EXTERNAL rate-absolute $Rate" seq 60 attribute Dynamic-Qos-Parameter "police-class-burst EXTERNAL $Burst" seq 70 attribute Service-Interim-Accounting 900 ! ip route 0.0.0.0/0 context local ! ! # Адрес DHCP-сервера dhcp relay server 194.165.18.17
После получения DHCP DISCOVER запроса, RedBack преобразует параметры запроса в Radius-атрибуты и отправляет Access-Request на указанный Radius-сервер. Запрос выглядит примерно следующим образом:
User-Name=f0:7d:68:82:59:27 NAS-Port-Id=2/1 vlan-id 2217 clips 169782 NAS-Identifier=Redback-IPOE User-Password=Redback NAS-IP-Address=172.16.19.1 NAS-Port=553650345 Service-Type=5 NAS-Port-Type=5 Platform-Type=4 Medium-Type=11 Agent-Remote-Id={01 06 1C BD B9 E6 48 78} DHCP-Option={3D 3D 07 01 F0 7D 68 82 59 27} DHCP-Option={0C 0C 07 44 49 52 2D 33 30 30} Agent-Circuit-Id={00 04 08 A9 00 01} OS-Version=6.5.1.3 Mac-Addr=f0-7d-68-82-59-27 NAS-Real-Port=553650345 UNKNOWN[3561--1]={02 0A 01 06 1C BD B9 E6 48 78} UNKNOWN[3561--1]={01 08 00 04 08 A9 00 01}
В качестве Radius-сервера используется приложение BGInetAccess. В качестве логина, SE подставляет MAC-адрес абонента. Параметры DHCP-опции 82 хранятся в атрибутах Agent-Remote-Id и Agent-Circuit-Id. Для того, чтобы авторизовать абонента по MAC-адресу коммутатора и порту, необходимо сгенерировать User-Name из этих параметров. Для этого используется динамический класс-обработчик процессора протокола (в биллинге задается в разделе "Типы устройств"), а именно метод preprocessAccessRequest:
public void preprocessAccessRequest( RadiusPacket request, RadiusPacket response, ConnectionSet connectionSet ) throws Exception { String macAddr = request.getStringAttribute( 2352, 145, null ); byte[] remoteId = request.getByteAttribute( 2352, 96, null ); byte[] circuitId = request.getByteAttribute( 2352, 97, null ); if( macAddr != null && remoteId != null && circuitId != null ) { String callingStation = macAddr.replaceAll( "\\-", "" ); String userName = ""; // Формируем User-Name формата <mac коммутатора>:<порт коммутатора> userName = Utils.bytesToHexString( remoteId ).substring(4, 16) + ":" + Utils.bytesToHexString( circuitId ).substring(10, 12); userName = userName.toLowerCase(); request.setStringAttribute( -1, 1, userName ); request.setStringAttribute( -1, 31, callingStation ); } }
При успешной аутентификации, BGInetAccess отправляет Access-Accept следующего вида:
Acct-Interim-Interval=900 Framed-IP-Address=193.106.88.119 # Атрибут, необходимый для получения абонентом IP-адреса DHCP-Max-Leases=1 # Атрибуты для включения сервиса для абонента. Устанавливают скорость соединения и включают посервисный аккаунтинг. Service-Name:1=RSE-SVC-EXT Service-Options:1=1 Service-Parameter:1=Rate=6000 Burst=750000 # Обязательный атрибут, указывает, к какому IP-интерфейсу "привязать" абонента IP-Interface-Name=CLIENTS
Для получения адреса по DHCP, в Radius ответе не должно быть атрибута Framed-IP-Address. Поэтому используется следующий метод для обработки ответа:
public void postprocessAccessRequest( RadiusPacket request, RadiusPacket response, ConnectionSet connectionSet ) throws Exception { response.removeAttributes( -1, 8 ); }
После успешной авторизации, SE посылает запрос на DHCP сервер. В качестве сервера DHCP используется то же самое приложение BGInetAccess. Для успешной привязки DHCP-запроса к сессии, необходимо предобработать его в соответствии с выбранным алгоритмом:
@Override public void preprocessDhcpRequest( DhcpPacket request, DhcpPacket response ) throws Exception { try { byte[] circuitId = request.getSubOption( (byte)1 ).value; byte[] remoteId = request.getSubOption( (byte)2 ).value; byte[] mac = new byte[6]; byte[] port = new byte[1]; System.arraycopy(circuitId, 5, port, 0, 1); System.arraycopy(remoteId, 2, mac, 0, 6); request.setSubOption( (byte)1, port); request.setSubOption( (byte)2, mac); } catch (java.lang.NullPointerException e) { return; } }
После этого абонент получает адрес и начинает работать.
Процесс аккаунтинга
После установления сессии, RedBack отправляет на Accounting-сервер сначала Start-пакет, и следом сразу же Update-пакет с Acct-Session-Time=0. Поскольку в Start-пакете отсутствует IP-адрес абонента, игнорируем его, в результате чего сессия стартует по первому Update-пакету.
IP адрес абонента приходит в VSA 132 ( Assigned-Ip-Address), поэтому для корректной работы биллинга необходимо скопировать его значение в параметр Framed-Ip-Address.
Поскольку при авторизации мы устанавливаем абоненту сервис RSE-SVC-EXT и включаем на нем посервисный аккаунтинг, SmartEdge помимо Accounting-пакетов для всей сессии, будет посылать пакеты для этого сервиса. Эти пакеты отличаются тем, что параметр Acct-Status-Type для Start, Stop и Update-пакетов равен 101, 102 и 103 соответственно. Параметр Acct-Session-Id формируется из Acct-Session-Id родительской сессии плюс строки вида RSE-SVC-EXT-1278BAF8. Идентификатор родительской сессии передается в параметре Acct-Multi-Session-Id.
Таким образом, для того чтобы учитывать у абонентов только внешний трафик, мы обнуляем значения параметров Acct-Input-Octets и Acct-Output-Octets для пакетов с Acct-Status-Type=3 и Acct-Status-Type=3.
У пакетов с Acct-Status-Type=102 и Acct-Status-Type=103 копируем параметр Acct-Multi-Session-Id в параметр Acct-Session-Id и устанавливаем Acct-Status-Type в 3. Таким образом посервисные пакеты выглядят для биллинга как обычные Update'ы.
Сессия останавливается по общему Stop-пакету с Acct-Session-Type=2.
Указанная логика реализуется в методе preprocessAccountingRequest класса SmartEdgeProtocolHandler:
@Override public void preprocessAccountingRequest( RadiusPacket request, RadiusPacket response, ConnectionSet connectionSet ) throws Exception { int acctStatusType = request.getIntAttribute( -1, 40, 0 ); // старты получается не обрабатываем, сессия стартует по апдейту if( acctStatusType != 1 && acctStatusType != 101 ) { preprocessAccessRequest( request, response, connectionSet ); Integer ipaddr = request.getIntAttribute( 2352, 132, null ); if( ipaddr != null ) { request.setIntAttribute( -1, 8, ipaddr ); } } if ( acctStatusType == 3 || acctStatusType == 2) { // обнуляем общие счетчики трафика (нас интересуют только посервисные) request.setIntAttribute(-1, 42, 0); request.setIntAttribute(-1, 43, 0); } if ( acctStatusType == 103 || acctStatusType == 102) { String sessionID = request.getStringAttribute(-1, 50, null); request.setStringAttribute(-1, 44, sessionID); } if ( acctStatusType == 103 || acctStatusType == 102) { request.setIntAttribute(-1, 40, 3); } }