Глобальная проблема с UTM5

[vel]

Столкнулся с жёсткой проблемой UTM5 при использовании VPN доступа.
Проблема наблюдается в версии: utm5-2.1.005 и utm5-2.1.006.
Проблема заключается в следующем: перезагружаем utm5_core (СУБД не перезагружаем)

Код: Выделить всё

/usr/local/etc/rc.d/utm5_core.sh stop
/usr/local/etc/rc.d/utm5_core.sh start

и VPN пользователи не проходят авторизацию до тех пор, пока не залезешь в админку или web-оболочку и не поменяешь руками пароль. При чём в памятке пользователя отображается валидный пароль, с которым он проходил авторизацию до перезагрузки ядра UTM5. Если залезть в web-оболочку и поменять пароль указав этот ж самый пароль в поле "старый пароль", то пароль успешно изменяется. Всё это говорит о том что в базе действительно хранится валидный пароль пользователя, который никаким образом не меняется после перезагрузки utm5_core.
У меня у одного такая проблема что ли? Мне ещё раза 2 точно мигрировать придётся СУБД с сотней пользователей и останавливать ядро UTM5. Мне всем пользователям после миграции пароли руками в параметрах IP-группы заново прописывать что ли?
Тестировал выше указанные версии биллинга на OS FreeBSD 7.2 и 6.4, СУБД: PostgreSQL 8.4.2, MySQL 5.5.0 и 5.0.89, проблема наблюдалась везде.
В тех. поддержке NetUP'а просят логи, только к чему они в данном случае? В Качестве pptp-сервера у меня MPD5, в mpd.log очевидная ошибка:

Код: Выделить всё

...
Jan 23 19:06:07 srv mpd: [L-1] RADIUS: Authenticating user 'test'
Jan 23 19:06:07 srv mpd: [L-1] RADIUS: Rec'd RAD_ACCESS_REJECT for user 'test'
Jan 23 19:06:07 srv mpd: [L-1] AUTH: RADIUS returned: failed
Jan 23 19:06:07 srv mpd: [L-1] AUTH: Trying INTERNAL
Jan 23 19:06:07 srv mpd: OpenConfFile: Can't open file '/usr/local/etc/mpd5/mpd.secret': No such file or directory
Jan 23 19:06:07 srv mpd: [L-1] AUTH: User "test" not found in secret file
Jan 23 19:06:07 srv mpd: [L-1] AUTH: INTERNAL returned: failed
Jan 23 19:06:07 srv mpd: [L-1] AUTH: ran out of backends
Jan 23 19:06:07 srv mpd: [L-1] CHAP: Auth return status: failed
Jan 23 19:06:07 srv mpd: [L-1] CHAP: Reply message: E=691 R=0 M=Authorization failed.
Jan 23 19:06:07 srv mpd: [L-1] CHAP: sending FAILURE #1 len: 37
Jan 23 19:06:07 srv mpd: [L-1] LCP: authorization failed
...

Всё понятно без слов, pptp-сервер не проходит RADIUS-аутентификацию.
В '/netup/utm5/logs/debug.log' одна лишь запись, добавление записи в СУБД о журналировании пользователя при попытке подключения:

Код: Выделить всё

?Debug : Jan 23 19:35:26 DBCtx: SQL query: INSERT INTO dhs_access_log(recv_date,User_Name,Service_Type,Framed_Protocol,NAS_IP_Address,NAS_Id,is_success) VALUES('1264264526','test','0','0','0','127.0.0.1','0')

Может информативным будет '/netup/utm5/logs/radius.log':

Код: Выделить всё

?Debug : Jan 23 19:35:26 RadiusSocket: RADIUS packet successfully received
?Debug : Jan 23 19:35:26 RadiusSocket: RADIUS raw data obtained
?Debug &#58; Jan 23 19&#58;35&#58;26 RADIUS Packet&#58; Size <263>; HDR.Size <263>
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Recv...
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Packet from NAS <127.0.0.1>
?Debug &#58; Jan 23 19&#58;35&#58;26 RADIUS DBA&#58; NAS found. Data size <0>
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Packet from <127.0.0.1> packet dump&#58; RPacket&#58;
Code&#58; 1; ID&#58; 209
<Vendor&#58; 0; Attr&#58; 1>&#91;4&#93;&#58; 74657374
<Vendor&#58; 0; Attr&#58; 5>&#91;4&#93;&#58; 00000001
<Vendor&#58; 0; Attr&#58; 6>&#91;4&#93;&#58; 00000002
<Vendor&#58; 0; Attr&#58; 7>&#91;4&#93;&#58; 00000001
<Vendor&#58; 0; Attr&#58; 30>&#91;0&#93;&#58; 
<Vendor&#58; 0; Attr&#58; 31>&#91;0&#93;&#58; 
<Vendor&#58; 0; Attr&#58; 32>&#91;19&#93;&#58; 7372762d6d312e6d6178636f6d74656c2e7275
<Vendor&#58; 0; Attr&#58; 44>&#91;11&#93;&#58; 343236343532362d4c2d31
<Vendor&#58; 0; Attr&#58; 61>&#91;4&#93;&#58; 00000005
<Vendor&#58; 0; Attr&#58; 64>&#91;4&#93;&#58; 00000001
<Vendor&#58; 0; Attr&#58; 65>&#91;4&#93;&#58; 00000001
<Vendor&#58; 0; Attr&#58; 66>&#91;12&#93;&#58; 31302e35302e31302e323030
<Vendor&#58; 0; Attr&#58; 67>&#91;10&#93;&#58; 31302e35302e31302e31
<Vendor&#58; 0; Attr&#58; 80>&#91;16&#93;&#58; d8bed49363ee30e11b068eb4828a7ab0
<Vendor&#58; 0; Attr&#58; 87>&#91;3&#93;&#58; 726c30
<Vendor&#58; 0; Attr&#58; 91>&#91;19&#93;&#58; 7372762d6d312e6d6178636f6d74656c2e7275
<Vendor&#58; 311; Attr&#58; 11>&#91;16&#93;&#58; bb1e68e9dd637a5c75c2683ea66778a6
<Vendor&#58; 311; Attr&#58; 25>&#91;50&#93;&#58; 010057a1bfa170692ab22a089b64f5a313170000000000000000654077f8edbfe53fccaeb1af95419ac43c2b413ab035c157
<Vendor&#58; 12341; Attr&#58; 12>&#91;3&#93;&#58; 4c2d31
 
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; User <test> connecting
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Session for sessionid <test> not found in <127.0.0.1> cache
?Debug &#58; Jan 23 19&#58;35&#58;26 RADIUS DBA&#58; Info for login <test> found. type <1>
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Auth scheme&#58; MS-CHAPv2
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; MS-CHAPv2&#58; Authorized user <test> 
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; MS-CHAPv2&#58; MPPE Keys send
 Warn  &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Unable to claim IP&#58; No such file or directory
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Calling fill radius attributes for NAS. Attr storage size <0>
 Notice&#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Login incorrect <test> from NAS <127.0.0.1> CLID <> Calling-station <>
 Notice&#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Authorization failed for user <test>
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Auth reply&#58; RPacket&#58;
Code&#58; 3; ID&#58; 209
<Vendor&#58; 0; Attr&#58; 18>&#91;21&#93;&#58; 417574686f72697a6174696f6e206661696c65642e
<Vendor&#58; 311; Attr&#58; 7>&#91;4&#93;&#58; 00000001
<Vendor&#58; 311; Attr&#58; 8>&#91;4&#93;&#58; 00000006
<Vendor&#58; 311; Attr&#58; 16>&#91;34&#93;&#58; 82680d2861218063b966695e570851e6942d60380af68089693f63b5d39b764af1f9
<Vendor&#58; 311; Attr&#58; 17>&#91;34&#93;&#58; 88abfce1de3c8dc518db60a20acd9675f513a43f274a055216f7f568d34417b9beb5
<Vendor&#58; 311; Attr&#58; 26>&#91;43&#93;&#58; 81533d41303831433132354142394545413135433032334243464532384531393443444144433643334538

?Debug &#58; Jan 23 19&#58;35&#58;26 RADIUS Packet&#58; raw data constructed! size <202>
?Debug &#58; Jan 23 19&#58;35&#58;26 RadiusSocket&#58; Moving RADIUS packet into send queue
?Debug &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Next...
?Trace &#58; Jan 23 19&#58;35&#58;26 AuthServer&#58; Process loop step
?Debug &#58; Jan 23 19&#58;35&#58;26 RadiusSocket&#58; Waiting for RADIUS raw data
?Debug &#58; Jan 23 19&#58;35&#58;26 RadiusSocket&#58; RADIUS raw data sent

Есть подозрение что проблема с какими-то внутренними системами кэширования биллинга, скрытых от администратора, о которых рассказывали в NetUP в своё время. Если это так, то мы откажемся от внедрения биллинговой системы UTM5.

[NShut]

не у всех пользователей но была такая же проблема. по 10 раз перебивали пока непоняли что проще сменить. в чем заключалась незнаю. сейчас версия 007upd10 вроди уже нет таких проблем. И да у нас без vpn авторизации. глюк был в винтрей авторизации

[Slad]

радиус надо настраивать,а не пароли менять.

[vel]

Нашёл такую штуку:

Код: Выделить всё

interim_update_interval=61

Может я и лентяй, но и документация своей конструктивностью не блещет. В NetUP говорят скоро будет новая.

[z0rg]

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

[mikkey finn]

другой радиус использовать

[f0ma]

было такое же, сделал вот такое значение контроля сессии
interim_update_interval=240
и все излечилось

[novich]

другой радиус использовать

имхо другой билинг надо использовать...