BiTel

Стоит задача запустить услугу wifi на существующие интернет-договоры.
Т.е. у всех желающих должна быть возможность подключить опцию в ЛК и получить доступ в инет через городской wifi.

Привязка wifi-сессии должна быть к существующему договору, авторизация wifi по логину/паролю через EAP, далее авторизация сессии ISG по mac-адресу.

Собрали такую схему:

1. Клиент подключается к wifi-точке, вводит логин и пароль, подтверждает использование сертификата.
2. Wifi-точка отправляет запрос на авторизацию на радиус. Freeradius используем потому-что не смогли
подружить BG-Radius с EAP. В радиус-запросе имеем логин и mac-адрес.
3. Freeradius проксирует запрос на БГ, но уже без EAP. БГ авторизует сессию по логину и паролю и отправляет Access-Accept обратно.
После авторизации, wifi-точка шлёт Start-пакет, в итоге получаем "EAP-сессию" в БГ с username и callingStationId=mac-адресу клиента.
4. Клиент получает IP от standalone dhcp-сервера, который никак с БГ не связан. Framed-Ip-Address wifi не умеет.
5. При первом пакете, NAS пытается поднять ISG-сессию.
6. В радиус-запросе от NAS мы имеем mac-адрес в поле User-Name (на кошке стоит ip subscriber l2-connected, initiator unclassified mac-address)
и только по нему мы можем авторизовать ISG-сессию на основе авторизованной EAP-сессии. Для этого в preprocessAccessRequest
ищутся все активные сессии с callingStationId=User-Name и если такая сессия находится, то в обратку посылаем Access-Accept. Далее серсвисная сессия
уже привязывается к ISG-сессии как обычно.

Первый вопрос - не изобрели-ли мы велосипед? Может можно как-то проще и стандартнее что-ли?
Не нравится костыль по поиску EAP-сессий для авторизации ISG-сессии. Не нравится, что ip выдаёт отдельный dhcp (не БГ-шный) и мы никак не управляем
привязкой IP.

По этой схеме в БГ имеются две независимые сессии и если прекращается EAP-сессия, то ISG продолжает жить до таймаута.
Можно-ли как-то биллингу сказать, что это зависимые сессии? Конкретно хочется чтобы при получаении Stop-пакета от wifi, разрывалась бы и ISG-сессия.

Ну и хочется услышать критику/замечания, будет-ли такая схема реально работать? На стенде пока работает...

А у вас есть связка логин/пароль?
Разве не только IPoE?

Биллинг умеет выдавать адрес во Framed-IP-Address, а затем выдавать этот адрес по DHCP, т.к. подобное нужно для IPoE ISG и CLIPS.
Хотя в вашем случае возможно что-нибудь нужно подправить - там обычно не только MAC, а по option82 доступны еще порт/VLAN.

Связка только по логин/пароль.
Про выдачу IP по Framed-IP-Address через DHCP не могли-бы подробнее описать? option82 wifi не умеет. VLAN для всех wifi общий.

Bazhutyan



А можно поинтересоваться - как клиент подтверждает использование сертификата и какую wifi-точку вы тестируете? У меня стоит похожая задача, но я, когда пробовал EAP-авторизацию, ничего не придумал лучше, чем добавлять сертификат в мобильные устройства абонентов вручную, а это достаточно неудобно, как мне кажется.

На самом деле, с сертификатами пока не заморачивался. Сейчас в случае iPhone, отдаётся сертификат от freeradius'а, и клиент просто жмёт на кнопку подтвердить использование.
Wifi точки Ubiquiti, контроллер Unifi

Нужно использовать ru.bitel.bgbilling.modules.inet.radius.InetRadiusHelperProcessor вместо обычного.
В конфиге корневого устройства указать
radius.key.deviceTypeIds=типы устройств, c которых идет авторизация по IP-пакету.
В этом случае при получении Access-Request с такого устройства - сначала будет идти поиск активной сессии с таким IP-адресом, как в User-Name.


Нужно использовать ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor2 (или InetDhcpHelperProcessor) вместо обычного.
В конфиге корневого устройства указать
dhcp.key.deviceTypeIds=типы устройств - wifi точки, т.е. те, что шлют RADIUS-accounting для wifi-соединения.
dhcp.key.pattern=$mac - чтобы привязка шла только по MAC-адресу или попробовать
dhcp.key.pattern=$deviceId:$mac - чтобы привязка была по wifi-точке и MAC-адресу.

В этом случае при получении DHCP-запроса с wifi-точки будет найдена связанная RADIUS-сессия от wifi-точки и в DHCP-ответе выдан тот адрес, что был выдан в Access-Accept.

В первом приближении так.
Какие проблемы возникли с EAP?

Вот не могу даже сказать что конкретно с EAP, он просто не заработал "из коробки", поэтому перешли сразу на freeradius. Благо у последнего debug куда более обширный.
К БГ EAP я еще вернусь, пока задача быстрее запустить услугу.

Бывают ситуации, когда при переходе соединения от одной точки wifi к дургой, первая не посылает Stop-пакет.
Я эту ситуацию отслеживаю при Start-пакете от новой точки.
Вопрос - как правильно закрыть соединение/сессию от первой точки? Ожидать таймаут не могу, иначе возможно появление дублированного ISG-соединения.

А как отслеживаете? По MAC?

Mac + username