Повторная аутентификация 5.3-002

ssslll · Сообщение **ssslll** » Чт авг 20, 2015 12:45

При переводе системы доступа на UTM5 5.3-002 столкнулись с неожиданной проблемой.
Некоторые, похоже случайные клиенты не могли поднять сессию pppoe c радиус аутентификацией. В логах радиуса присутствовали для них записи

Aug 20 13:41:29 ?Debug : a9ab3700 AuthQueue: Login 'g000139'
Aug 20 13:41:29 ?Debug : a9ab3700 LoginStorage: Acquire: login 'g000139' used 2 times

Aug 20 13:41:29 ?Debug : a9ab3700 AuthQueue: CHAP authentication OK

Aug 20 13:41:29 Info : a9ab3700 AuthQueue: Limit of simultaneous sessions for service ID 482 is exceed

Aug 20 13:41:29 ?Debug : a9ab3700 AcctQueue: lookup: session ID 11326 closed
Aug 20 13:41:29 ?Debug : a9ab3700 SessionManager: put: sessiond ID 11326 from NAS 25 is closed

Верно ли я понимаю, что этот пользователь пытается создать еще одну сессию авторизации при незакрытой предыдущей ( Limit of simultaneous sessions for service ID 482 is exceed ) и как с этим боротся, если на самом деле сессий для этого пользователя не NAS нет ?

Иногда лечиться пересозданием сервисной связки коммутированного доступа.

На 5.2-008 работает без проблем.

Конфиги радиуса

interim_update_interval=320

Остальное по умолчанию.

LoginStorage: Acquire: login 'g000139' used 2 times Видимо говорит о кол-ве открытых попыток наса авторизовать на радиусе.

Для некоторых пользователей число этих попыток может быть равно 6.

Буду рад любым мыслям.

Shiva · Сообщение **Shiva** » Чт авг 20, 2015 19:43

Значит NAS не прислал STOP...

ssslll · Сообщение **ssslll** » Пт авг 21, 2015 11:09

Он и старт не присылает. На этапе авторизации что то не получается и через 30 сек логин освобождается радиусом

Aug 20 13:52:14 ?Debug : a98b1700 LoginStorage: Release: login 'g000084' used 2 times

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

ssslll · Сообщение **ssslll** » Вт авг 25, 2015 08:10

Локализовал ошибку.
Acct-Session-Id служит единственным критерием определения существующих сессий в UTM-радиусе и на NAS. Для нашей связки RedBack - UTM5 5.3-002, по каким то причинам создаются некорректные связки Acct-Session-Id - логин. В итоге сессии не проходят авторизацию.
В отчете dial-up на один логин создается несколько непонятно откуда взявшиеся сессии ( видно из колонки вызывающий абонент )

Конфиг RedBack SE-100

aaa authentication administrator local
aaa authentication subscriber radius
aaa accounting subscriber radius
aaa accounting suppress-acct-on-fail
radius accounting server 192.168.1.254 encrypted-key 3F2D1C65
radius coa server 192.168.1.254 encrypted-key 3F2D1C65 port 3799
radius coa server 192.168.1.247 encrypted-key 3F2D1C65E port 3799

administrator dlink41 encrypted 1 $1$........$jHTkA9yWTSiQjS7i/
privilege start 15
privilege max 15
timeout session idle 60

radius server 192.168.1.254 encrypted-key 3F2D1C65E86DF6B4
radius max-retries 5
radius timeout 8
radius attribute nas-ip-address interface mng
radius attribute calling-station-id format description
radius attribute acct-session-id access-request
radius attribute nas-port format session-info
radius deadtime 30

С этим конфигом на версии 5.2-008 работает без проблем.
Что можно сделать для устранения ошибок?
В чем может быть причина некорректной

ssslll · Сообщение **ssslll** » Чт сен 03, 2015 12:29

Еще раз.
Версия UTM5 рабочая 5.2-009
Для ее базы делаю запрос на уникальность Acct-Session-ID

SELECT count(`Acct_Session_Id`) as c, `Acct_Session_Id` , from_unixtime(`last_update_date`) FROM `dhs_sessions_log` where 1 group by `Acct_Session_Id` having c> 1

В результате чисто. Все Acct_Session_Id уникальны, т.е. единственны.

Обновляю систему до UTM5 5.3-002

Идут отказы в аутентификации.

Для ее базы делаю запрос на уникальность Acct-Session-ID

SELECT count(`Acct_Session_Id`) as c, `Acct_Session_Id` , from_unixtime(`last_update_date`) FROM `dhs_sessions_log` where 1 group by `Acct_Session_Id` having c> 1

В результате куча повторяющихся Acct_Session_Id.

Почему? И как с этим бороться?

maxxsoft

ssslll писал(а):Почему? И как с этим бороться?

для начала посмотреть в услуге по передачи IP трафика, чтобы была не установлена галочка "разрешать множественное подключение", а также установить "лимит одновременных сессий 1"

ssslll · Сообщение **ssslll** » Пт сен 04, 2015 07:07

maxxsoft писал(а):
ssslll писал(а):Почему? И как с этим бороться?
для начала посмотреть в услуге по передачи IP трафика, чтобы была не установлена галочка "разрешать множественное подключение", а также установить "лимит одновременных сессий 1"

Лимиты установлены. Галочки нет.

banec · Сообщение **banec** » Пт сен 04, 2015 10:16

Похожая ситуация после перехода.
с cisco , лечим малым временем аренды, чтоб радиус освобождал ip и клиент мог подключится.
В отчетах по диалапу сессии открываются и закрываются. и так куча записей.
НО на линуксойдном VPN c accel pptp - всё работает как положено,
+ lISG тоже без проблем.
т.е. где-то с железяками нахимичили.

LovingFox

ssslll писал(а):Еще раз.
Почему? И как с этим бороться?

Если есть возможность, то нужно снять дампы трафика PPPoE_client->BRAS и BRAS->Radius-server. Одновременно в момент проблемного подключения. И прислать их сюда, посмотрим.

ssslll · Сообщение **ssslll** » Ср сен 16, 2015 07:31

Это лог на неудачное подключение.

Sep 16 09:22:03 ?Debug : e2b06700 AuthQueue: Login 'bukazl'
Sep 16 09:22:03 ?Debug : e2b06700 LoginStorage: Acquire: login 'bukazl' used 1 times
Sep 16 09:22:03 ?Debug : e2b06700 AuthQueue: Login info found, slink_id 269829
Sep 16 09:22:03 ?Debug : e2b06700 AuthQueue: Using CHAP authentication method
Sep 16 09:22:03 ?Debug : e2b06700 AuthQueue: CHAP authentication OK
Sep 16 09:22:03 Info : e2b06700 AuthQueue: authorization request from 192.168.1.12:1812 succeeded
Sep 16 09:22:03 ?Debug : e2b06700 AuthQueue: Service ID 421 type 5; account ID 89
Sep 16 09:22:03 ?Debug : e2b06700 TimeBasedTariffCalculator: calculate_duration: result 311877 truncated 86400
Sep 16 09:22:03 ?Debug : e2b06700 AuthQueue: Calculated maximum session time: 86400
Sep 16 09:22:03 ?Debug : e2b06700 IPPoolManager: IP 91.235.188.6 is leased from NamedPool 'pool5'
Sep 16 09:22:03 ?Debug : e2b06700 CustomAttrs: custom attributes for NAS ID 25 have been added to the reply
Sep 16 09:22:03 ?Debug : e2b06700 CustomAttrs: custom attributes for DIALUP_SERVICE ID 421 have been added to the reply
Sep 16 09:22:03 ?Debug : e2b06700 AcctQueue: lookup: session ID 13285 for login 'bukazl'
Sep 16 09:22:03 ?Debug : e2b06700 AcctQueue: lookup: session ID 13285 for IP 91.235.188.6
Sep 16 09:22:03 ?Debug : e2b06700 SessionManager: put: session ID 13285 timeout scheduled at 1442377353
Sep 16 09:22:03 ?Debug : e2b06700 SessionManager: put: session ID 13285 from NAS 25 OK
Sep 16 09:22:03 ?Debug : e2b06700 AuthQueue: Reply

Строчки

Sep 16 09:22:03 ?Debug : e2b06700 TimeBasedTariffCalculator: calculate_duration: result 311877 truncated 86400
Sep 16 09:22:03 ?Debug : e2b06700 AuthQueue: Calculated maximum session time: 86400

говорят о превышении максимального времени сессии 86400

Как это может быть?

Сессии для этого аккаунта все закрыты.

Очень похожая ситуация

viewtopic.php?p=63661

Я уже не знаю, как с этим бороться. Надо обновляться, а купленное обновление не работает толком.
[/code]