На шаг впереди

С каждым годом требования со стороны потребителей все выше. Проблемы с настройкой абонентских устройств оказывают непосредственное влияние на удовлетворенность пользователя широкополосными сервисами оператора связи. Зачастую, абонент хочет подключить свое оборудование и начать пользоваться услугами оператора, не производя дополнительных настроек. Поэтому провайдеры услуг вынуждены идти на более прозрачные способы предоставления доступа к сети Интернет для абонентов.

Перед оператором связи возникает задача нахождения грани между надежностью, стабильностью, защищенностью, легкостью для клиента и сложностью эксплуатации. Единого мнения в пользу применения той или иной модели предоставления доступа к сети нет. У каждой модели и ее вариаций есть свои плюсы и минусы, и их обсуждение не входит в задачу этой статьи. Каждый оператор выбирает модель в зависимости от существующей инфраструктуры, оборудования, планов модернизации и социального развития абонентов. С каждым годом все больше операторов смотрят в сторону IPoE (IP over Ethernet).

В отличие от туннелированных протоколов предоставления доступа, IPoE не имеет механизмов аутентификации, назначения ip адресов, мониторинга состояния абонента, поэтому вынужден делегировать эти функции на другие протоколы, такие как Extensible Authentication Protocol (EAP), Dynamic Host Configuration Protocol (DHCP).

Современные устройства BNG позволяют использовать многокритериальную идентификацию абонентов. Сводная информация по возможным вариантам идентификации, аутентификации абонента и назначения ip адресов представлена в таблице:

Рассмотрим возможные варианты аутентификации абонентов по технологии IPoE:

•    Аутентификация протокола (EAP);
•  Transparent Auto Logon (TAL); аутентификация на основе сетевых идентификаторов, имеющих отношение к трафику абонента (например, source IP, DHCP opt. 82);
•    Web-logon.

Зачастую при динамическом распределении адресов предоставление доступа к сети разбивается на два последовательных этапа:

•  Аутентификация (Radius сервер);
•  Получение ip адреса (DHCP сервер).

В этом случае одной из важнейших задач становится синхронизация DHCP и radius серверов. Многие сталкивались с этой проблемой, решая ее либо скриптовыми методами (например, анализ dhcp.log) либо же выбирая асинхронное взаимодействие (ручное). Синхронизация первым способом носит зачастую односторонний характер.

Поэтому нами предлагается следующие решение синхронизации в рамках версии АСР LANBilling 1.9:

При получении пакета DHCP-Discover DHCP сервер преобразует запрос в запрос к radius серверу. Далее при получении пакета access-accept от radius сервера происходит преобразование запроса в DHCP-Offer. Преобразование запросов осуществляется с помощью патча DHCP сервера – dhcp2radius. Таким образом, получается, что в случае двухэтапного предоставления доступа абоненту radius сервер должен обработать 2 access-request от абонента (запрос на аутентификацию и назначение сетевого адреса). Нами была добавлена опция radius-агента, при которой по получению второго access-request агент не создает сессию, а назначает абоненту ip адрес и обновляет параметры сессии абонента (ip адрес). Идентификация абонента происходит по mac-адресу.

Стоит отметить, что предложенный нами метод подходит не только в случае использования современных BNG, поддерживающих механизмы идентификации и управления сессиями абонентов, но и для connectionless-моделей, уже хорошо зарекомендовавшим себя. Примером таких моделей могут быть:

•  Аутентификация по протоколу EAP, назначение ip адресов по протоколу DHCP, шейпер на аутентификаторах и/или soft routers. (с примером настройки этой модели можно ознакомиться в статье).
•  Аутентификации по dhcp opt.82, шейпер на soft routers. (с примером настройки этой модели можно ознакомиться в статье).

В версии LANBilling 2.0 OSS планируется выпуск собственного DHCP сервера – агента LBdhcp, который будет напрямую взаимодействовать с LBserver. У агента LBdhcp будут 2 режима работы:

•  Основной (аутентификация будет производиться непосредственно агентом LBdhcp – опция 82);
•   В эмуляции (аутентификацию будет осуществлять агент LBarcd, а агент LBdhcp будет отвечать только за выдачу ip адреса).

Компания «Сетевые решения» предлагает гибкий механизм, обеспечивающий единую точку контроля и управления абонентской сессией, что в значительной степени облегчает эксплуатацию сервисного уровня оператора связи.