Интеграция LANBilling c CISCO ISG (IPoE)

Компания «Сетевые Решения» благодарит Холодилова Александра Олеговича, руководителя службы эксплуатации СПД (сети передачи данных) компании «Радист» (торговая марка ТВИНТЕЛ) за предоставленный материал статьи. Статья носит ознакомительный характер и не является документацией. Начиная с версии 005, LANBilling 2.0 будет иметь свой встроенный DHCP сервер.

1. Введение

В данной статье приведен пример внедрения LANBilling для предоставления услуги доступа в интернет на базе модели IPoE и технологии Cisco ISG с идентификацией клиента по порту доступа. Данная статья не претендует на абсолютную верность, т.к. схема работы до сих пор дорабатывается. Но, тем не менее, общая концепция взаимодействия LB и ISG остается неизменной, и, надеюсь, поможет начинающим пользователям в процессе внедрения.

2. Общий принцип функционирования

Рисунок 1

1. Абонент при подключении к сети запрашивает адрес от DHCP-сервера.

2. Коммутатор доступа вставляет в DHCP-Request опцию 82, которая состоит из двух субопций – Remote-ID (идентификатор устройства, вставившего опцию, как правило, MAC-адрес или IP коммутатора) и Circuit-ID(номер модуля и номер порта на модуле, в который подключен клиент). Если не порту доступа обнаруживается DHCP-сервер, то ответы от него подавляются.

3. Далее broadcast-пакет попадает на коммутатор агрегации с настроенной функцией DHCP-Relay, откуда уже unicast-пакет пересылается на внешний DHCP-сервер. На коммутаторе агрегации делается запись в таблице DHCP-Snooping, на основе которой работает функция Dynamic ARP Inspection. Эта функция позволяет динамически создавать связку MAC+IP на основе данных DHCP-Snooping и отбрасывать трафик от клиентов, не получивших адрес от DHCP. Таким образом, уже на уровне агрегации получается верифицированный IP, по которому можно однозначно идентифицировать клиента.

4. Далее трафик попадает в ядро сети, откуда перенаправляется в BRAS c поддержкой функционала Cisco ISG.

5. На BRAS к трафику применяются политики ограничения согласно данным, полученным из биллинга. В случае, если сессия аутентифицирована, трафик заворачивается в NAT, иначе пользователю показывается страничка с информацией о блокировке.

В этой схеме биллинг занимается только аутентификацией и авторизацией пользователей, адресным пространством же занимается внешний DHCP-сервер, никак не связанный с биллингом.

Таким образом, для реализации описанной выше схемы нужно следующее:

•  Коммутаторы доступа с функцией DHCP-Snooping.
•  Коммутаторы агрегации с функционалом L3 и поддержкой DHCP-Snooping, DHCP-Relay и Dynamic ARP Inspection/IP Source Guard.
•  Функционал DHCP-Relay, DAI, IP Source Guard может быть вынесен на коммутаторы доступа, однако желательно все- таки оставить эти функции на коммутаторах агрегации.
•  На коммутаторах доступа и агрегации порты, направленные в сторону DHCP-сервера должны быть сделаны доверенными для того, чтобы ответы от DHCP-сервера пропускались коммутатором. Соответственно порты, направленные в сторону абонентов должны быть недоверенными для того, чтобы исключить появление неавторизованных DHCP-серверов.
•  DHCP-Snooping на коммутаторе агрегации не должен переписывать значение опции 82, вставленную коммутаторами доступа на недоверенных портах.
•  BRAS с поддержкой Cisco ISG (Cisco 7200/Cisco ASR10xx/Cisco ESR), настроенный на инициализацию сессии при прохождении трафика. Сервер DHCP с поддержкой опции 82 (к примеру, DHCPD).

Далее опишем процесс настройки DHCP-сервера, агента RADIUS и BRAS.

3. Настройка DHCP-сервера

В качестве DHCP-сервера используется ISC DHCPD версии 4.1.1-P1-15+ из стандартных репозиториев Debian Squeeze. К достоинствам DHCPD стоит отнести низкие требования к ресурсам – сервер, обслуживающий примерно 50-70 запросов в секунду, при размере конфига в 600 кб потребляет 11 мб памяти менее 0,1% ЦП.

Примерная конфигурация:

ddns-update-stylenone;
default-lease-time 600;
max-lease-time 600;
log-facility local7;
authoritative;

if exists agent.circuit-id
{
log (info, concat(
"Leased address ", binary-to-ascii (10, 8, ".", leased-address),
" for MAC ", binary-to-ascii(16, 8, "", substring(hardware, 1, 6)),
" at switch ", binary-to-ascii (16, 8, "", suffix( option agent.remote-id, 6)),
" on port ", binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) ,
" invlan ", binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 2, 2))));
}

subnet 10.0.0.0 netmask 255.0.0.0 {

class "0:e:5e:13:d8:e7-1"{
match if (binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "1")
# and (binary-to-ascii (10, 16, "", substring ( option agent.circuit-id, 2,2)) = "vlanid");
and (binary-to-ascii (16, 8, ":", suffix ( option agent.remote-id, 6)) = "0:e:5e:13:d8:e7");
}

pool {
allow members of "0:e:5e:13:d8:e7-1";
range 10.21.255.225;
option subnet-mask 255.255.255.244;
option routers 10.21.255.254;
}
}

Из примера видно, что для связки MAC коммутатора + номер порта выделяется отдельный класс, к которому привязывается пул из одного адреса со своим набором опции. Функция «suffix» берет последние 6 байт из поля RemoteID при вычленении MAC-адреса коммутатора доступа и 1 байт при вычленении номера порта. Затем эти значения конвертируются из бинарного вида в ASCII функцией «binary-to-ascii» и сравниваются с условиями. Если условие соответствия выполняется, то выдается адрес из привязанного пула.

Хотя конфиг DHCPD и кажется несколько громоздким, тем не менее, его генерация очень легко автоматизируется. Сгенерированный конфиг же меняется только в случае замены коммутатора. Таже DHCPD позволяет включать в конфиг произвольные текстовые файлы при помощи функции include, что позволяет структурировать конфиг.

В нашем случае при установке нового коммутатора под него выделяется подсеть и на основе шаблона создается конфигурационный файл, в котором заранее описываются все порты устройства. Далее конфиг коммутатораподключается к общему конфигу DHCPD через include.

В дальнейших планах у нас интеграция DHCPD и LBInventory с целью автоматизации генерации конфига DHCP-сервера. В дальнейшем абоненту выделяется порт и его адрес остается неизменным.

Более подробно настройка и работа DHCP-Snooping описана здесь:

DHCP-snooping;
82-DHCP

4. Настройка биллинга

При создании учетной записи в качестве логина указывается IP-адрес абонента, привязанный к порту коммутатора. Именно по sourceip и производится дальнейшая идентификация пользователей.

5. Настройка агента

Для организации взаимодействия биллинга с ISG BRAS необходимо запустить агент RADIUS с некоторыми изменениями в настройках. В частности, необходимо запретить отдачу атрибута Framed-IP-Address в Access-Accept, т.к. выдачей адресов занимается внешний DHCP-сервер.

Также необходимо установить таймаут зависшей сессии небольшим (60 секунд). Необходимо это для тех случаев, когда сессия по какой-то причине не завершается корректно. Если BRAS попробует заново аутентифицировать сессию до истечения таймаута, то биллинг ответит ему отказом т.к. будет считать ее работающей.

Скриншот настроек агента приведен ниже.

Рисунок 2

6. Настройка тарифов и сервисов

Помимо аутентификации сессии, к ней обычно требуется применить политику авторизации. Обычно на сессию применяется набор сервисов. Сервис классифицирует трафик по определенному ACL и указывает, что делать с трафиком.

Сервисы могут храниться как на BRAS, так и загружаться на BRAS через специально сформированный access-accept. Данные способы можно комбинировать.

Хранение сервисов в биллинге позволяет при изменении тарифов не трогать BRAS, однако механизм хранения сервисов в биллинге при большом количестве тарифов выглядит несколько громоздким.

Хранение сервисов на сервере доступа позволяет представить конфигурацию в более структурированном и наглядном виде, однако при любом изменении тарифов требуется вмешательство в конфигурацию BRAS.

Как правило, используется комбинированный подход и описание непосредственно тарифов хранится в биллинге, а вспомогательные сервисы (редирект, доверенные сайты и т.д.) описываются на BRAS т.к. изменяются нечасто.

Для того чтобы BRAS загрузил сервисы, их имена передаются через Cisco AVPair ssg-account-info c префиксом N для задания имени сервиса, который надо загрузить и префиксом A для активации сервиса на сессии (NInet3072 и AInet3072 соответственно). Атрибуты описания и активации сессии включаются в access-accept от RADIUS-сервера.

Загрузка сервисов производится методом посылки access-request со стороны BRAS, где в поле User-Name указывается имя сервиса, который надо получить. LANBilling позволяет ответить access-accept на эти запросы в случае, если в тарифе указан идентификатор внешней услуги, совпадающий с набором атрибутов, привязанных к сервису.

В нашем случае настройка биллинга сильно упрощается тем фактом, что нам не требуется разделять трафик на отдельные классы и соответственно применять к ним разные политики, а достаточно просто применить целиком к сессии атрибут полисера и аккаунтинг-листа.

Для этого в тарифе укажем требуемую скорость, а к ней привяжем следующий атрибут:

Здесь QU – скорость от абонента к BRAS, DU – от BRAS к абоненту.

Пример для 8 Мбит:

Рисунок 3

Для аккаунтинга применим на сессию следующий атрибут:

Рисунок 4

Также можно использовать атрибут 251, имеющий похожие опции.

Подробно RADIUS-интерфейс ISG описан тут.

7. Настройка CoA

Для взаимодействия с BRAS со стороны биллинга применятся RADIUS CoA. Для этого используется механизм внешних скриптов агента RADIUS и утилита radclient.

По событию блокировки, разблокировки, включения и выключения выполняется один и тот же скрипт, который уничтожает сессию.

Т.к. при использовании модели IPoE нет тоннеля, как в случае с L2TP/PPPoE, где создается PPP-соединение поверх L3/L2, то пользователь постоянно подключен к сети вне зависимости от состояния сессии. Поэтому в нашем случае достаточно просто уничтожить сессию и авторизовать ее заново, но уже с новыми параметрами. Динамическая замена сервисов на сессии не требуется. При этом данный процесс практически не заметен для пользователя (теряется 1-2 пакета пока сессия авторизовывается).

Код скрипта для деавторизации приведен ниже:

В переменной $1 передается логин пользователя, т.е. его IP-адрес. Стоит заметить, что при остановке сессии агент передает логин, т.е. идентификатор сессии вторым параметром. Соответственно это надо учесть в скрипте.

8. Настройка сервера доступа

IPoE BRAS реализован на базе маршрутизатора Cisco 7206 NPE-G1.

Стоит заметить, что функционал ISG реализован в ветке IOS 12.2SB. Дальнейшей эволюцией этой ветки является IOS 12.2SRC. В нашем случае используется IOS 12.3(4r)T3.

Далее приведен конфиг BRAS с комментариями.Части, не относящиеся к настройке ISG удалены.

aaa new-model
!
!Создаем две группы AAA - для авторизации администраторов через TACACS и для авторизации сессий через RADIUS.
!
aaa group server tacacs+ tac-int
server 10.201.0.4
!
aaa group server radius ISG-RADIUS
server 10.254.241.1 auth-port 1812 acct-port 1813
!
!Указываем, что для логина группы admin используется группа tac-int
!
aaa authentication login admin group tac-int local
!Соответвенно для авторизации группы ISG-AUTH-1 используется AAA-группа ISG-RADIUS
aaa authentication login ISG-AUTH-1 group ISG-RADIUS
!Указываем, что надо авторизовывать пользователей, подключающихся через консоль.
aaa authorization console
!Далее указываем, что переход в enable и вводимые команды авторизовываются через TACACS
aaa authorization exec admin group tac-int local
aaa authorization commands 15 admin group tac-int local
!Сетевые соединения авторизовываем через группу ISG-RADIUS
aaa authorization network ISG-AUTH-1 group ISG-RADIUS
!Сервисы пытаемся искать локально, иначе загружаем через RADIUS
aaa authorization subscriber-service default local group ISG-RADIUS
!Аккаунтинг сливаем раз в минуту
aaa accounting update newinfo periodic 1
!Аккаунтинг сливаем в группу ISG-RADIUS
aaa accounting network ISG-AUTH-1
action-type start-stop
group ISG-RADIUS
!
aaa accounting network ISG-RADIUS
action-type start-stop
group ISG-RADIUS
!
!Указываем сервер, которому позволено посылать CoA на BRAS
aaa server radius dynamic-author
client 10.254.241.1 server-key 7 xxxxxx
auth-type any
!
!Описываем куда перенаправлять трафик блокированных клиентов
!
service-policy type control ISG-CUSTOMERS-POLICY
redirect server-group REDIRECT_NOPAY
serverip 10.20.1.1 port 80
!
!Описываем классы для трафика.
!CLASS-TRUSTED - разрешенные при блокировке сайты, к примеру, интернет-банки или платежные системы.
!CLASS-TO-REDIRECT - трафик, который перенаправляется на страничку переадресации
!ISG-IP-UNAUTH - неаутентифицированный трафик, обратите внимание на таймер.
!
class-map type traffic match-any CLASS-TRUSTED
match access-group input 198
match access-group output 198
!
class-map type traffic match-any CLASS-TO-REDIRECT
match access-group input 197
match access-group output 197
!
class-map type control match-all ISG-IP-UNAUTH
matchauthen-status unauthenticated
match timer UNAUTH-TIMER
!
!Описываем, что делать с трафиком для блокированных клиентов
!Класс CLASS-TO-REDIRECT перенаправляем, остальной трафик не пропускаем
!
policy-map type service LOCAL_L4R
1 class type traffic CLASS-TO-REDIRECT
redirect to group REDIRECT_NOPAY
!
class type traffic default input
drop
!
!
!Указываем, что делать с трафиком на доверенные сайты - ограничиваем его на 64к. Остальной трафик не пропускаем.
!Остальной трафик не пропускаем.
!
policy-maptypeservice SERVICE-TRUSTED
1 class type traffic CLASS-TRUSTED
police input 64000 8000 16000
police output 64000 8000 16000
!
class type traffic default input
drop
!
!Описываем главную политику для трафика
!Неавторизованные сессии дропаем по таймеру через 3 минуты
!При инициализации сессии выполняем авторизацию сессии через группу ISG-IP-UNAUTH
!Идентифицируем сессию по ip-адресу
!Если авторизация не прошла (радиус ответил access-reject), устанавливаем таймер на 3 минуты
!На неавторизованную сессию вешаем сервисы SERVICE-TRUSTED и LOCAL_L4R.
!Важен порядок навешивания сервисов т.к. первый должен разрешать доверенные сайты,
!второй - перенаправлять веб-трафик на страницу блокировки,
!остальной трафик дропаем
!policy-map type control ISG-CUSTOMERS-POLICY
class type control ISG-IP-UNAUTH event timed-policy-expiry
1 service disconnect
!
class type control always event session-start
10 authorize aaa list ISG-AUTH-1 password ISG identifier source-ip-address
20 set-timer UNAUTH-TIMER 3
30 service-policy type service name SERVICE-TRUSTED
40 service-policy type service name LOCAL_L4R
!
class type control always event radius-timeout
1 service-policy type service name SERVICE-TRUSTED
2 service-policy type service name LOCAL_L4R
!
!Интерфейс в сторону RADIUS
interface GigabitEthernet0/2.10
encapsulation dot1Q 10
ip address 10.254.241.12 255.255.248.0
!
!Интерфейс в сторону NAT
interface GigabitEthernet0/2.11
encapsulation dot1Q 11
ip address 10.252.0.2 255.255.240.0
!
!Интерфейс в сторону страницы блокировки
interface GigabitEthernet0/2.17
descriptionRedirect_iface
encapsulation dot1Q 17
ip address 10.20.1.62 255.255.255.192
!
!Интерфейс, на который принимается трафик от абонентов.
!Навешиваем на него service-policy
!Инициируем сессию по факту прохождения трафика
interface GigabitEthernet0/3.8
encapsulation dot1Q 8
ip address 10.20.0.2 255.255.255.0
service-policy type control ISG-CUSTOMERS-POLICY
ip subscriber routed
initiator unclassified ip-address
!
!Заворачиваем маршрут по умолчанию в NAT
ip route 0.0.0.0 0.0.0.0 10.252.0.1
!
!Описываем ACL для редиректа http
!
access-list 197 permit tcp any anyeq www
access-list 197 permit tcp any eq www any
access-list 197 deny ip any any
!
!Разрешаем трафик для блокированных клиентов - DNS, ICMP, доверенные сайты
!
access-list 198 permit udp any anyeq domain
access-list 198 permit udp any eq domain any
access-list 198 permit tcp any host 91.197.107.200 eq www
access-list 198 permit tcp any host 91.197.107.200 eq 443
access-list 198 permit tcp any host 109.235.186.253 eq www
access-list 198 permit icmp any any
access-list 198 deny ip any any
!
!Указываем, что нужно указывать в access-request атрибуты:
!8(Framed-IP-Address )
!31(Calling-Station-Id)
!32(NAS-Identifier)
!44(Acct-Session-Id)
!55(Event-Timestamp)
!Хотя можно и без них
radius-server attribute 44 include-in-access-req
radius-server attribute 44 extend-with-addr
radius-server attribute 8 include-in-access-req
radius-server attribute 32 include-in-accounting-req
radius-server attribute 55 include-in-acct-req
radius-server attribute 31 mac format unformatted
radius-server host 10.254.241.1 auth-port 1812 acct-port 1813 key 7 yyyyyyyyyyy
radius-servervsa send cisco-nas-port
radius-servervsa send accounting
radius-servervsa send authentication
!

В случае успешной настройки BRAS должны быть сгенерирован access-request и соответствующий access-accept от биллинга. Пример:

Рисунок 5

Как видно, в качестве User-Name используется Source IP. В ответ приходит access-accept и атрибут с настройками полисинга.

В итоге должны появиться сессии:

Рисунок 6

Детали сессии можно посмотреть при помощи команды show sss session uid xx.

Руководитель службы эксплуатации СПД (сети передачи данных)
Компании «Радист» (торговая марка ТВИНТЕЛ)
Холодилов Александр Олегович