BiTel

Коллеги, добрый день !

По просьбе вновь образованного регионального провайдера сейчас провожу выбор и опытную эксплуатацию системы биллинга. Есть небольшой затык с WPA2/Radius авторизацией точек доступа. Прошу совета, в каком направлении двигаться дальше.

Коротко условия задачи.

1. В районах области ставятся операторские точки доступа WiFi типа WBSn в режиме бриджа. За ними стоят микротики, которые делают NAT. Центральный микротик используется только для управления.

2. Идеологию доступа Inet.WIFI они использовать не хотят (и не могут - нет центрального сервера). Поэтому хотят авторизацию пользователей через Radius в биллинге.

Что сделано:

1. Установлен Billing, InetAccess и прочее. Сконфигурированы модули, услуги, заведено оборудование, сделан тестовый клиент и тарифный план.

2. Через radius-client проверено, что биллинг дает Access-Accept при посылке Plaintext-Password (клиент активен)

3. Сгенерированы при помощи EasyRSA корневой ключ CA и серверный ключ для BGBilling

4. Корневой ключ CA добавлен в доверенные центры авторизации на тестовый ноутбук Win7

5. Серверный ключ и CA сконфигурированы временно во FreeRaduis и проверено, что пользователь может через EAP успешно авторизоваться

6. Через KeyTool ключи добавлены в keystorage для bgbilling и включена опция EAP в InetAccess конфиге.

7. FreeRadius выключен.

Что не работает:

- Не проходит авторизация через Radius BGBilling. После нескольких обменов пакетами, в логах видно tls error без какой-либо расшифровки, что именно ему не нравится (уровень дебага поставили TRACE).

Вопросы:

- Должна ли работать такая схема, как мы собрали (авторизация через Radius и EAP с WiFi точками доступа) ? У кого она работает ? Стоит ли продолжать ей заниматься - и если да, что как понять, что не нравится tls (где еще увеличивать уровень отладки и где смотреть) ?

- Есть в голове резервная схема, при которой мы заставляем точки доступа работать с FreeRadius с SQL модулем, который будет проверять пароли прямо по базе BgBilling. Но придется написать небольшой модуль к FreeRadius, чтобы при правильном пароле он посылал Access-Request пакет с Plaintext Password на Radius BGBilling и окончательный ответ по авторизации и Value-пары брал из ответа BGBilling и их посылал клиенту. По предварительной оценке, это сохраняет все преимущества биллинга (в том числе подсчет и управление сессиями), но избавляет нас от проблем EAP в BGBilling-Radius. Какие тут есть недостатки, и что мы можем потерять ? Accounting будет обрабатывать сразу же BGBilling.

- Если все совсем плохо, то будем смотреть в сторону решения с Captive Portal прямо на точках WBSn, но оно нравится пока меньше всего.

Кто (и особенно, разработчики) что думает ?

Публичный WiFi на ключах.
Месье знает толк в извращениях!

Я говорю "извращения" не как что-то плохое.

Нет, авторизация по логину и паролю. Но WPA2/Radius предполагает аутентификацию сети для абонента. То есть, по моему пониманию, они внутри Radius протокола гоняют инкапсулированный EAP, внутри которого кладут между собой TLS и уже внутри этого туннеля гоняют PAP или MSChap. В такой ситуации нужен только подписанный каким-нибудь доверенным CA сертификат сервера, а сертификаты клиентов отсутствуют.

Так вот у нас этот самый TLS внутри EAP внутри Radius почему-то не работает.

Я понимаю, что вы хотите выдавать всем абонентам ключи для подключения к сети. Вы мне другое скажите, как вы себе представляете обслуживание этой сети потом? Ведь надо будет регулярно, практически каждому абоненту объяснить, что именно нужно с этими ключами делать, а так же выдавать дубликаты ключей в случае их "утери" (переустановка ОС, сброс телефона/планшета в дефолт и вот это вот все). Не кажется ли вам, что вы своими собственными руками хотите усложнить себе жизнь?
Я бы предложил вам не рыть себе яму, а сделать доступ к сети открытым. Это избавит вас от описанных выше проблем с ключами, а так же позволит привлечь к себе больше абонентов благодаря банальной страничке рекламы "подключитесь к нам и получите скоростной WiFi интернет" рисуемой каптив порталом при подключении абсолютно всем. Про монетизацию подобной странички я, с вашего позволения, умолчу.

Нет, такой идеи не было.

Все абоненты идут по имени пользователя и паролю. То, что мы в эксперименте генерировали свой CA и импортировали его в клиент - это издержки эксперимента. Потому что заказывать для теста настоящий сертификат где-нибудь в VeriSign долго и дорого.

Если бы такой ключ уже был, то со стороны клиента это выглядело бы так:

- Устанавливается связь на уровне радиоканала
- Внутри Radius протокола происходит обмен EAP, клиент проверяет валидность подписанного сторонним CA серверного ключа
- Устанавливается TLS, внутри TLS предъявляется пароль
- Выдается Access-Accept

То есть конфигурация клиента абсолютно стандартная.

БГБ поддерживает PEAP+MSCHAPv2, во всяком случае dialup точно поддерживает, а раз inet - это дальнейшее развитие dialup, то и он должен.
Какой именно тип авторизации вы ставили на тестовом устройстве?

На WBSn никаких настроек по этому поводу нет. В Win7 (клиенте) - стандартные настройки WiFi, ничего не меняли кроме установки CA. У меня в этой части главный вопрос - как отлаживать TLS error ? Я же сейчас не понимаю, что именно там у них происходит. Со стороны Win7 диагностики ждать не приходится. Может быть есть какие-то опции отладки со стороны BGBilling/Java ?

Если это нетривиально - тогда прошу совета по альтернативным решениям.

Про логирование в БГБ написано здесь (старый формат доки) или здесь (новый формат доки).

Log4j мы и сами используем. Уровень уже подняли до TRACE. Все DEBUG сообщения мы видим. Но кроме TLS Error ничего нет. Ни кода ошибки, ни Exception - просто констатация факта... Больше всего изумляет, что с FreeRadius авторизация идет !

вы покажите хоть ошибку целиком для начала. А что удивляться , eap периодически что-то вылезает.

Я бы оставил EAP на FreeRadius, а на БГБ только аутентифицировал и авторизовывал.

Повторили весь эксперимент. Результаты следующие:

1. EAP не работает, но удалось в логах найти ArrayOutOfBounds Exception - файл eap.log прилагается.

2. Удалось терминировать EAP на FreeRadius, и пробрасывать внутренний MSChap на bgbilling. Но тут новая засада - Bgbilling согласен авторизовывать по PAP, по CHAP, и не согласен по MSCHAP. Пользователь proba, пароль proba. В файле mschap.log кусок журнала, где bgbilling авторизует по chap и тут же отказывает с теми же реквизитами по mschap.

Какая версия MS-CHAP?

MS-CHAP V1 не поддерживается БГБиллингом.

http://forum.bitel.ru/viewtopic.php?f=44&t=10555

На сколько я помню для EAP нужен MS-CHAPv2.