Интеграция 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 описана здесь:
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 на эти запросы в случае, если в тарифе указан идентификатор внешней услуги, совпадающий с набором атрибутов, привязанных к сервису.
В нашем случае настройка биллинга сильно упрощается тем фактом, что нам не требуется разделять трафик на отдельные классы и соответственно применять к ним разные политики, а достаточно просто применить целиком к сессии атрибут полисера и аккаунтинг-листа.
Для этого в тарифе укажем требуемую скорость, а к ней привяжем следующий атрибут:
| 250 | account-info | QU;cir, normal burst, excess burst;D;cir,normal burst;exess burst |
Здесь 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 пакета пока сессия авторизовывается).
Код скрипта для деавторизации приведен ниже:
nas_id=10.254.241.12 nas_port=1700 nas_secret=хххххх sess_id="$1" /bin/echo "User-Name="$1", Cisco-Account-Info=S"$1", cisco-avpair=\"subscriber:command=account-logoff\"" | /usr/bin/radclient -x "$nas_id":"$nas_port" coa "$nas_secret"
В переменной $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.
Руководитель службы эксплуатации СПД (сети передачи данных)
Компании «Радист» (торговая марка ТВИНТЕЛ)
Холодилов Александр Олегович