Перейти до

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


Рекомендованные сообщения

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

 

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

 

 

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

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

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

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

 

...

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 61
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Чего печалька-то?

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

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

Ссылка на сообщение
Поделиться на других сайтах
С какого перепугу?

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

Не-ве-рю!

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

 

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

// Fix authorization process if user online

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

{

packet->packetType = RAD_REJECT_PACKET;

return 0;

}

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Не-ве-рю!

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

 

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

// Fix authorization process if user online

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

{

packet->packetType = RAD_REJECT_PACKET;

return 0;

}

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Не-ве-рю!

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

 

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

в случае конекта через радиус в функции 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 (или тот же пользователь в роли злоумышленника). После этого он остается в онлайне, даже если отключит все виды авторизации у него будет интернет и после окончания баланса у него будет интернет.

Ссылка на сообщение
Поделиться на других сайтах

...

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

в случае конекта через радиус в функции 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 (или тот же пользователь в роли злоумышленника). После этого он остается в онлайне, даже если отключит все виды авторизации у него будет интернет и после окончания баланса у него будет интернет.

Почему так?

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

"Юзер может быть авторизованным но не онлайн. GetConnected вернет 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 в таблице

 

 

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

Сори. учту.

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

 

как то так

Ссылка на сообщение
Поделиться на других сайтах

...

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

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

...

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

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

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

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

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

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

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...