POD key & IPSoft Billing: задачка на смекалку

[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, что в итоге и сделал. И всё заверте...

Comments

[dadv.livejournal.com]

Обновил пост.

[mtg-nvkz.livejournal.com]

Это нечестно. )

[dadv.livejournal.com]

"Скажи вселенной, что это нечестно, а то вдруг она не знает." (c) Пратчетт