![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dadvДля управления пользователями компания использует IPSoft Billing, имеющий в своём составе RADIUS-сервер, тесно интегрированный с базой. В биллинге для NAS задаётся отдельно Secret key, которым NAS должен авторизовать свои RADIUS-запросы и отдельно POD key, которым биллинг должен авторизовать свои Packet Of Disconnect, посылаемые к NAS для сброса пользователей. Например, если для пользователя предусмотрено ограничение длительности сессии, в конце этой длительности биллинг обрывает сессию посылкой POD на NAS. Или если по какой-то причине техподдержке надо сбросить сессию - например, у юзера украли пароль, он пришел с паспортом и говорит об этом и в это время кто-то держит открытой сессию с его логином. И вообще, мало ли случаев бывает.
Есть куча работающих NAS, для которых всё давно настроено и работает - и биллинг автоматически сессии срубает, и техподдержка вручную по мере надобности. Ставлю новый NAS, настраиваю, прописываю в базе все ключи. В итоге:
- NAS авторизуется на RADIUS-сервере нормально;
- "автоматические" пакеты POD от биллинга авторизацию на NAS проходят;
- а вот те POD, что генерируются по ручным командам техподдержки
на новом NAS авторизацию не проходят, при этом со старыми NAS - никаких проблем.
Update 28.11.2010. Никогда нельзя верить тому, что написано в документации - всё надо тестировать, как минимум при возникновении проблем. В данном случае не верим ни формирователю пакета, ни проверятелю, ни передающей сети.
Берем в руки проверенный временем сетевой сниффер и захватываем полное тело POD-пакета, убеждаясь, что сеть доставляет его верно и без видимых невооруженным взглядом повреждений. Читаем RFC2866 на предмет изучения, как именно полагается вычислять MD5-хеш, которым подписывается пакет. Вручную выписываем последовательность байт, включающую в себя POD key и вручную же скармливаем её на вход проверенной временем утилите вычисления MD5, получаем хеш. Видим, что он, на самом деле, НЕ совпадает с хешем внутри пакета. В результате творческого озарения повторяем процедуру, взяв Secret key вместо POD key и получаем точное совпадение с хешем внутри пакета.
То есть, при ручном сбрасывании сессии при помощи операторского GUI этот гуй подписывает пакет, используя не POD key, а Secret key - очевидная бага используемой версии. А вот автоматически генерируемые биллингом POD подписываются верным ключём. Почему же на старых NAS всё работало верно? Потому, что для всех них в базе все ключи заполнены одинаковыми значениями. А для нового NAS я прописал разные.
Легко доказать, что в таких условиях (плюс отсутствие техподдержки для закрытого проекта имени IPSoft Billing) для корректной работы необходимо прописывать одинаковые значения для Secret Key и POD key, что в итоге и сделал. И всё заверте...
no subject
Date: 2010-11-26 01:25 (UTC)Ладно. Будем пробовать думать дальше.
no subject
Date: 2010-11-26 05:21 (UTC)"а вот те POD, что генерируются по ручным командам техподдержки на новом NAS авторизацию не проходят" - авторизация в RFC2866 предусмотрена только по ключу. Авторизовывать UDP-пакеты по IP вообще нельзя, потому что src ip в них спуфится с легкостью необычайной и не зря в RFC вариант проверки IP даже не упоминается.
no subject
Date: 2010-11-26 06:14 (UTC)Как-то я тестировал Junper ERX-310. И пробовал я CoA. В том числе проверял и POD.
Так вот, при настройке нужно было указывать не только secret
-тех, но и IP-адрес источника. Если пакет прилетал с невалидного адреса, на всё остальное Juniper клал. Таким образом, я выяснил, что BillAdmin не заставляет IPSoft Billing слать POD, а делает это сам.no subject
Date: 2010-11-26 06:52 (UTC)no subject
Date: 2010-11-28 09:40 (UTC)no subject
Date: 2010-11-29 01:38 (UTC)no subject
Date: 2010-11-29 04:53 (UTC)