STG залипание юзверей после дисконнекта

[madf 279]

Ну про вланы и переброс IP я ничего не говорил у меня это вообще неиспользуеться.

 

Вопрос былв следующем:

 

 

Юзер выключил комп давным давно а в админилке горит что он в онлайне, помогает тока рестарт старгайзера. Stg-2.707-p1, FreeBSD 7.4 база на postgresql пользователей в базе 2106, онлайн всреднем 170.

Памагите люди добрые куда копать.

Я про вланы и интерфейсы писал чтобы показать кривость решения. Ваш вопрос я помню.

Как на счет обновления до 2.408?

 

...

не может ли эта проблема быть из за одновременного дисконекта 2-х пользователей ?

Крайней вероятно.

С какого перепугу?

[SpiderX 7]

С какого перепугу?

Потому, что проблема 100% повторяема из месяца в месяц 28 числа, после ротации IP адресов в сам знаешь какой сети

[madf 279]

С какого перепугу?

Потому, что проблема 100% повторяема из месяца в месяц 28 числа, после ротации IP адресов в сам знаешь какой сети

А какое отношение к этому имеют одновременные дисконнекты? Если бы проблема была в этом - она проявлялась бы чаще, особенно на участках сети с потерями и "семафорами" у абонов. А в сам знаешь какой сети проблема проявляется только при смене IP, при которой дисконнект... Ммм... Достаточно побочное явление. Да и вообще, имеет место только для InetAccess. А с AO проблема сходного характера. Так что скорее всего проблема где-то глубже.

[Роман Погосян 0]

да при смене IP с подключенным ИА тоже часто наблюдается этот глюк , кстате наблюдался он так же когда rlm_stg пускал онлайнового юзера подключатся по VPN

[Роман Погосян 0]

еще волнует то, что иногда ОнДисконнект не отрабатывает

[madf 279]

еще волнует то, что иногда ОнДисконнект не отрабатывает

Не-ве-рю!

[madf 279]

... кстате наблюдался он так же когда rlm_stg пускал онлайнового юзера подключатся по VPN

Можно более подробно?

[Роман Погосян 0]

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

[Роман Погосян 0]

еще волнует то, что иногда ОнДисконнект не отрабатывает

Не-ве-рю!

тогда как обьяснить следующее

 

клиент подключился , его IP был добавлен в таблицу файрвола

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

Случается крайне редко, но случается

[Роман Погосян 0]

в случае конекта через радиус в функции int RADIUS::ProcessAutzPacket(RAD_PACKET * packet)

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

 

подлечил так:

 

// Fix authorization process if user online

if(ui->GetConnected()!=0)

{

packet->packetType = RAD_REJECT_PACKET;

return 0;

}

[madf 279]

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

Не вижу здесь проблемы. СИстема как раз так построена что можно авторизоваться одновременно из разных мест.

 

еще волнует то, что иногда ОнДисконнект не отрабатывает

Не-ве-рю!

тогда как обьяснить следующее

 

клиент подключился , его IP был добавлен в таблицу файрвола

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

Случается крайне редко, но случается

Проблема в скриптах.

[madf 279]

в случае конекта через радиус в функции int RADIUS::ProcessAutzPacket(RAD_PACKET * packet)

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

 

подлечил так:

 

// Fix authorization process if user online

if(ui->GetConnected()!=0)

{

packet->packetType = RAD_REJECT_PACKET;

return 0;

}

Не понял про айпишник и почему это кому-то выносит мозг.

GetConnected, к стати, это не проверка на авторизацию.

[Роман Погосян 0]

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

Не вижу здесь проблемы. СИстема как раз так построена что можно авторизоваться одновременно из разных мест.

 

еще волнует то, что иногда ОнДисконнект не отрабатывает

Не-ве-рю!

тогда как обьяснить следующее

 

клиент подключился , его IP был добавлен в таблицу файрвола

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

Случается крайне редко, но случается

Проблема в скриптах.

В скрипте только ipfw table X add $IP и ifw table X del $ip. Там не может быть проблема

[Роман Погосян 0]

в случае конекта через радиус в функции int RADIUS::ProcessAutzPacket(RAD_PACKET * packet)

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

 

подлечил так:

 

// Fix authorization process if user online

if(ui->GetConnected()!=0)

{

packet->packetType = RAD_REJECT_PACKET;

return 0;

}

Не понял про айпишник и почему это кому-то выносит мозг.

GetConnected, к стати, это не проверка на авторизацию.

Когда юзер онлайн GetConnected возвращает 1 иначе 0. Так что с задачей он справляется.

про IP :

Есть юзер с прописным айпи 10.х.х.х он зашел через ИА и авторизовался стал онлайном. С другого компа злоумышленник подключился этим же логин и паролем через VPN (или тот же пользователь в роли злоумышленника). После этого он остается в онлайне, даже если отключит все виды авторизации у него будет интернет и после окончания баланса у него будет интернет.

[madf 279]

...

Проблема в скриптах.

В скрипте только ipfw table X add $IP и ifw table X del $ip. Там не может быть проблема

Да ладно! А код возврата ipfw проверяется?

[madf 279]

в случае конекта через радиус в функции int RADIUS::ProcessAutzPacket(RAD_PACKET * packet)

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

 

подлечил так:

 

// Fix authorization process if user online

if(ui->GetConnected()!=0)

{

packet->packetType = RAD_REJECT_PACKET;

return 0;

}

Не понял про айпишник и почему это кому-то выносит мозг.

GetConnected, к стати, это не проверка на авторизацию.

Когда юзер онлайн GetConnected возвращает 1 иначе 0. Так что с задачей он справляется.

Юзер может быть авторизованным но не онлайн. GetConnected вернет 0. Хотя юзер авторизован.

 

про IP :

Есть юзер с прописным айпи 10.х.х.х он зашел через ИА и авторизовался стал онлайном. С другого компа злоумышленник подключился этим же логин и паролем через VPN (или тот же пользователь в роли злоумышленника). После этого он остается в онлайне, даже если отключит все виды авторизации у него будет интернет и после окончания баланса у него будет интернет.

Почему так?

[Роман Погосян 0]

ага .. два раза одно IP ipfw в одну таблицу не ввернет. так что "почему так?"

[Роман Погосян 0]

"Юзер может быть авторизованным но не онлайн. GetConnected вернет 0. Хотя юзер авторизован."

 

в данном случае ничему это не грозит

[madf 279]

ага .. два раза одно IP ipfw в одну таблицу не ввернет. так что "почему так?"

Все равно непонятно. Как у вас файрвол работает?

 

"Юзер может быть авторизованным но не онлайн. GetConnected вернет 0. Хотя юзер авторизован."

 

в данном случае ничему это не грозит

Ну тогда надо говорить не об авторизации а о состоянии: подключен или нет. Это разные вещи.

[Роман Погосян 0]

Все равно непонятно. Как у вас файрвол работает?

 

ipfw allow all from any to table X

ipfw add allow table X to any

ipfw add deny all from any to any

при старте системы

 

stg остается только добавлять и удалять ip в таблице

 

 

Ну тогда надо говорить не об авторизации а о состоянии: подключен или нет. Это разные вещи.

Сори. учту.

[madf 279]

У юзеров в базе IP прописаны? Или у всех "*"?

Т.е. я не вижу ничего плохого: авторизнулся юзер через авторизатор, сработал OnConnect, адрес попал в файрвол. Авторизнулся он-же через VPN - т.к. уже авторизован то OnConnect второй раз работать не будет. Отключится авторизатор - будет продолжать работать через VPN. Отключится VPN - будет продолжать работать через авторизатор.

Но как только закончатся деньги, не важно уже как был авторизован и сколько раз, - сработает OnDisconnect и юзер работать перестанет. В чем проблема?

Единственную проблему вижу если адреса назначаются автоматом - тогда возможен конфликт IP. Но это уже не проблема биллинга.

[Роман Погосян 0]

я не говорил что это проблема билинга. Чел у которого на лан карте стоит 10.х.х.х получает тот же адрес. Систему глючит с непредсказуемым результатом. один из результатов залипание. из за IP конфликта тоже такое происходит. Происходит какое то не корректное завершение обработки выключения пользователя при получении какого-то кривого пакета от ИА клиента, он становится так сказать полузакрытым , Плугин считает что его нет в онлайне а ядро думает совсем иначе.

 

как то так

[Роман Погосян 0]

У юзеров в базе IP прописаны? Или у всех "*"?

это не важно, важно спертва подключтся ИА клинтом , потом ВПН

[madf 279]

...

Происходит какое то не корректное завершение обработки выключения пользователя при получении какого-то кривого пакета от ИА клиента, он становится так сказать полузакрытым , Плугин считает что его нет в онлайне а ядро думает совсем иначе.

Нет. Это работает не так.

Отключение авторизатора, в отличии от процесса авторизации очень простое:

1. Клиент шлет DISCONN_SYN.

2. Сервер переходит в фазу 4 и шлет DISCONN_SYN_ACK.

3. Клиент отвечает DISCONN_ACK.

4. Сервер снимает авторизацию и шлет FIN.

Если п.3 не происходит - сервер возвращается в фазу 3, т.е. "авторизован". Аналогично работает и клиент.

[Polo 0]

...

Происходит какое то не корректное завершение обработки выключения пользователя при получении какого-то кривого пакета от ИА клиента, он становится так сказать полузакрытым , Плугин считает что его нет в онлайне а ядро думает совсем иначе.

Нет. Это работает не так.

Отключение авторизатора, в отличии от процесса авторизации очень простое:

1. Клиент шлет DISCONN_SYN.

2. Сервер переходит в фазу 4 и шлет DISCONN_SYN_ACK.

3. Клиент отвечает DISCONN_ACK.

4. Сервер снимает авторизацию и шлет FIN.

Если п.3 не происходит - сервер возвращается в фазу 3, т.е. "авторизован". Аналогично работает и клиент.

 

Это все гуд, но что конкретно мона сделать? может таймауты увеличить между этими событиями? или еще че?