Simult Chek: различия между версиями
Строка 82: | Строка 82: | ||
===Дополнительный процедуры и таблицы=== |
===Дополнительный процедуры и таблицы=== |
||
+ | |||
Таблица для хранения текущих сессий авторизации |
Таблица для хранения текущих сессий авторизации |
||
Строка 93: | Строка 94: | ||
</PRE> |
</PRE> |
||
− | Таблиа для хранения блокировок авторизующихся пользователей |
+ | Таблиа для хранения блокировок авторизующихся пользователей, единственное назначение - блокировка строк таблицы auth_sessions для нужного пользователя |
− | единственное назначение - блокировка строк таблицы auth_sessions для нужного пользователя |
||
− | |||
<PRE> |
<PRE> |
||
create table auth_sessions_users( |
create table auth_sessions_users( |
||
Строка 114: | Строка 113: | ||
DECLARE radacct_count INTEGER; |
DECLARE radacct_count INTEGER; |
||
set autocommit=0; |
set autocommit=0; |
||
− | SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; |
||
start transaction; |
start transaction; |
||
insert into auth_sessions_users values(SQLUserName,1) on duplicate key update ulock=1; -- lock |
insert into auth_sessions_users values(SQLUserName,1) on duplicate key update ulock=1; -- lock |
||
Строка 131: | Строка 129: | ||
delimiter ; |
delimiter ; |
||
</PRE> |
</PRE> |
||
+ | |||
− | Таблица для логгирования (используется при отладке) |
+ | Таблица для логгирования (используется только при отладке) |
<PRE> |
<PRE> |
||
CREATE table check_simul_log |
CREATE table check_simul_log |
||
Строка 138: | Строка 137: | ||
SimulCheck integer NOT NULL, |
SimulCheck integer NOT NULL, |
||
Time integer NOT NULL |
Time integer NOT NULL |
||
+ | )engine=InnoDB; |
||
− | ); |
||
</PRE> |
</PRE> |
||
− | + | Удалении сессии авторизации после неуспешной по причине too many connections авторизации. |
|
<PRE> |
<PRE> |
||
drop procedure postauth; |
drop procedure postauth; |
||
Строка 159: | Строка 158: | ||
end; |
end; |
||
</PRE> |
</PRE> |
||
+ | |||
===Изменения в sql.conf=== |
===Изменения в sql.conf=== |
||
<PRE>authorize_check_query = "CALL radius_authorize_check_query('%{SQL-User-Name}')"</PRE> |
<PRE>authorize_check_query = "CALL radius_authorize_check_query('%{SQL-User-Name}')"</PRE> |
Версия 16:59, 30 апреля 2009
Описание проблемы
В сети используется VPN (accel-pptp) с авторизацией на центральном radius-сервере (freeradius). При попытке авторизации 2 и более клиентов с одинаковыми UserName может возникнуть ситуация когда пытающиеся авторизоваться (или часть из них) пройдут авторизацию успешно.
Это связано с особенностью провеки одновременности подключений - запрос
simul_count_query = "SELECT COUNT(*) FROM ${acct_table1} WHERE UserName=\'%{SQL-User-Name}\' AND AcctStopTime = 0"
проверяет тольк наличие сессий в таблице acct_table1 (обычно radacct). Сессии в таблице acct_table1 создаются только при получении Acct-пакета от NAS-а (VPN-серверов в моем случае ). В результате, возможна ситуация когда из-за различных причин, как например, нагрузка NAS-a или потерь в сети, в результате возникает некоторый промежмежуток времени, в течении которого возможно авторизоваться повторно.
Следующяя схема илюстрирует эту ситуацию:
С UserName=test пробуют соединиться 2 различных клиента.
mysql> select * from radcheck where username='test'; +-------+-----------+------------------+----+-----------+ | id | UserName | Attribute | op | Value | +-------+-----------+------------------+----+-----------+ | 9295 | test | Pool-Name | := | ippool_1 | | 9294 | test | Password | == | password | | 9293 | test | Auth-Type | := | MS-CHAP | | 9296 | test | Simultaneous-Use | := | 1 | +-------+-----------+------------------+----+-----------+ 4 rows in set (0.00 sec)
Время ("кванты") | Первый клиент (UserName=test) | Второй клиент (UserName=test) | Radius-Сервер |
1 | Установка соединения (ppp) | ||
2 | Запрос к радиусу Auth-Request | Установка соединения (ppp) | Получение запроса от Клиента 1, проверка атрибутов, Вычисление значения Simultaneous-Use (=1 т.к. пользователь не был подключен, отправка Access-Accept на NAS) |
3 | Получение Access-Accept, авторизация клиента, создание интерфейса, и т.п. | Запрос к радиусу Auth-Request | Получение запроса от Клиента 2, проверка атрибутов, Вычисление значения Simultaneous-Use (=1 т.к. сессия первого клиента еще не попала в acct_table1) |
4 | NAS формирует пакет Acct-Start, задержка с отправкой из-за нагрузки на CPU | Получение Access-Accept, авторизация клиента, создание интерфейса, и т.п. | Ожидание Acct-Start от NAS |
5 | Отправка Acct-Start | Отправка Acct-Start | Занесенеее 2 сессий в acct_table1 |
Несмотря на то, что на первый взгляд такая ситуация кажется маловероятной, это совсем не так. Я столкнулся в своей сети с тем, что абоненты согласовывая (вероятно, по телефону) время включения, использовали 1 аккаунт 2 раза. В тестовых условиях при подключении нескольких компьютеров в одной комнате удавалось подключить 4 одновременных сессии с одним UserName.
Варианты решения
Простой
Наиболее простое решение - это внести задержку, для того что бы к моменту проверки simul_count_query сессия от одного из других пытающихся авторизоваться клиентов уже попала в acct_table1.
Для внесения задержки можно модифицировать запрос
authorize_check_query = "SELECT id, UserName, Attribute, Value, op \ FROM ${authcheck_table} \ WHERE Username = '%{SQL-User-Name}' \ ORDER BY id"
следующим образом
authorize_reply_query = "SELECT id+sleep(FLOOR(0 + (RAND() * 10))), UserName, Attribute, Value, op \ FROM ${authreply_table} \ WHERE Username = '%{SQL-User-Name}' \ ORDER BY id"
Этот запрос будет выполняться с задержкой 0-10 секунд.
Данное решение оказалось полностью функциональным, и после внесения модификации добиться множественных подключений не удавалосю.
Однако, присутвуют следующие недостатки:
- Существует вероятность отличная от нуля что функция RAND() вернет 2 раза одинаковые значения и запросы все же остануться "одновременными".
- Внесение задержки создает неудобства для абонентов (были жалобы).
- Слишком большое значение множителя ( более 10 секуд) может приводить к ошибкам авторизации по таймауту.
Под "одновременными" запросами авторизации подразумевается что времени между запросами окажется недостаточно для внесения данных в acct_table1 по той или инной причине.
Вариант решения основанный на транзакциях
Автор решения - voron, хотя нельзя сказать что я совсем не принимал участия в разработке ) Основная идея этого решения - при авторизации создавать в дополнительной таблице записи о "текущих сессиях авторизации", и использовать транзакции для блокировок строк таблицы.
Дополнительный процедуры и таблицы
Таблица для хранения текущих сессий авторизации
create table auth_sessions( username varchar(64), time integer not null, key username(`username`(64)), key time(`time`) )engine=InnoDB;
Таблиа для хранения блокировок авторизующихся пользователей, единственное назначение - блокировка строк таблицы auth_sessions для нужного пользователя
create table auth_sessions_users( username varchar(64), ulock integer not null, primary key username(`username`(64)) )engine=InnoDB;
AuthLifeTime - время жизни сесии авторизации, по истечении которого незавершенная сессия авторизации независимо от результата удалиться, ascount - auth session count, кол-во сессий сессий авторизации (активных попыток авторизоваться в текущий момент). Закомментарены запросы которые использовались для отладки.
drop procedure check_simul; delimiter // create procedure check_simul(in SQLUserName varchar(64), in AuthLifeTime int) begin declare ascount integer; DECLARE radacct_count INTEGER; set autocommit=0; start transaction; insert into auth_sessions_users values(SQLUserName,1) on duplicate key update ulock=1; -- lock delete from auth_sessions where username=SQLUserName and time<(UNIX_TIMESTAMP()-AuthLifeTime); -- delete too old auth sessions select count(*) into ascount from auth_sessions where username=SQLUserName; -- Count active auth sessions (0 if no other auth sessions ) insert into auth_sessions values(SQLUserName,UNIX_TIMESTAMP()); update auth_sessions_users set ulock=0 where username=SQLUserName; -- INSERT into check_simul_log values(SQLUserName,ascount,UNIX_TIMESTAMP(),-1); commit; set autocommit=1; SELECT COUNT(*) INTO radacct_count FROM radacct WHERE UserName=SQLUserName AND AcctStopTime = 0; -- INSERT into check_simul_log values(SQLUserName,radacct_count+ascount,UNIX_TIMESTAMP(),radacct_count); SELECT (radacct_count+ascount); end; // delimiter ;
Таблица для логгирования (используется только при отладке)
CREATE table check_simul_log ( UserName varchar(64) NOT NULL, SimulCheck integer NOT NULL, Time integer NOT NULL )engine=InnoDB;
Удалении сессии авторизации после неуспешной по причине too many connections авторизации.
drop procedure postauth; delimiter // create procedure postauth(in SQLUserName varchar(64),in PacketType varchar(64),in ReplyMessage varchar(255) ) begin INSERT into radpostauth(user, pass, reply, date, ReplyMessage) values (SQLUserName, 'Chap-Password', PacketType, NOW(), ReplyMessage); if ((strcmp(lower(PacketType),"access-reject")=0) and ((lower(ReplyMessage) REGEXP lower("You are already logged in - access denied"))=1)) then set autocommit=0; start transaction; insert into auth_sessions_users values(SQLUserName,1) on duplicate key update ulock=1; delete from auth_sessions where username=SQLUserName order by time desc limit 1; update auth_sessions_users set ulock=0 where username=SQLUserName; commit; set autocommit=1; end if; end;
Изменения в sql.conf
authorize_check_query = "CALL radius_authorize_check_query('%{SQL-User-Name}')"
simul_count_query = "CALL check_simul('%{SQL-User-Name}',60)"
postauth_query = "CALL postauth('%{User-Name}', '%{reply:Packet-Type}', '%{reply:Reply-Message:-EmptyReplyMessage}')"
Add
- показать нужный код sql.conf - убрать SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; и autocommit в 4-х местах - назначение postauth - уделение сессий авторизации при "долбёжке", это мона указать - check_simul_log энжин иннодб - неплохо бы поформатать sql, единственное что я нашёл это http://www.sqlinform.com/, java нужна