ivan999 Опубликовано 29 апреля, 2011 (изменено) · Жалоба Понимаю, что данную тему разжевывали много раз , но я смотрю часть форума выпилена невозбранно... Кто четко владеет нюансами работы Free radius. Есть схемка - Radius Сервер в связке с NAS (MikrotikOS 5) Юзеры коннектяться на NASы с помощью L2TP. Бывают случаи, что юзерская сессия некорректно прервана (сейчас не важно почему)- т.е. на NAS юзера уже нет, а на Radius сервере он висит. Потом юзер пытается переподключиться - но его не пускает, потому что запрещено под одним логином несколько юзеров. Можно ли решить это на уровне радиус протокола (с учетом FreeRadius + Mikrotik)? Либо нужны костыли сторонние ввиде скриптов, дополнительных проверок...? Есть наработки у кого по этому поводу? _____________________ Какие мысли? Изменено 4 июля, 2011 пользователем ivan999 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 29 апреля, 2011 · Жалоба Стандартный freeradius'овый checkrad.pl умеет опрашивать mikrotik по telnet и по snmp. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ivan999 Опубликовано 30 апреля, 2011 · Жалоба целый день думал и много читал. Получается много костылей - если несколько NASов - не очень надежно. Лучший вариант - не давать коннектиться второй раз с любого NAS - если на сервере Radius - такой login числиться активным. С повисшей сессией броться так - если нет с насов радиус пакетов с id Этого юзера более 15 минут - очищать в базе. И через это время юзер сможет переподключиться. А чтобы не долюили разные роутеры типа длинк дир-100 - нужно запретить количество попытко коннектов чаще чем , например 5 в минуту. Если больше - в черный список фаеравола на 15 минут. Но вот оказалось не так просто для L2TP это сделать - потому что во-первых он юзает UDP - т.е. статус "новое соединение" -весьма условно. Баловоство в conntrack с UDP таймацтами приносит только негативные результаты. А во-вторых - для передачи полезных данных юзается тот же порт, что и для установления тунеля. В итоге данные перед тем как попасть в форвард - все равно будут в input (в туннеле заходить). В отличие от PPTP - где GRE и TCP - разные протоколы для поддержки тунеля и для данных - там было бы проще. Есть только вариант отловить с помощью регулярного выражения пакеты на уровне L7 - именно содержашие признаки начало установления тунеля L2TP. Пока не осилил создать regexp Для микротика. есть дамп трафика. Вижу нужный пакет. Вижу hex значения - но пока не получается в тик его грамотно записать. Кто поможет, подскажет? Даже отдельную тему создам рядом... топег Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ivan999 Опубликовано 30 апреля, 2011 · Жалоба Регулярные выражения не прокатят - все тоже из-за UDP, контрэк и особенностей поиска регулярных выражений в потоке (только первые N пакетов потока....) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 1 мая, 2011 · Жалоба ivan999, фигней страдаешь. Не нужно тебе никаких черных списков и 15-минутных блокировок. Пусть роутеры долбятся, мешать они не будут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ivan999 Опубликовано 1 мая, 2011 · Жалоба ivan999, фигней страдаешь. Не нужно тебе никаких черных списков и 15-минутных блокировок. Пусть роутеры долбятся, мешать они не будут. Если бы так. Сам NAS - куда долбиться юзер - действительно не страдает никак - жует и не чихает. Но вот он делает запросы через радиус на биллинг. А там генерируются события, запускаются скрипты, делаются запросы в базу и потом отсылают результы опять на NAS. Вот на этом этапе и возникает постепенное запаздываение и накопление в очереди этих событий (они выстравиааются в очередь и выполняются последовательно). Т.е. биллинг медленнееобрабатывает факт логина - потому что ему нужно сделать больше операций. и тут страдают другие юзеры - задержка растет. Вот долбил глючный роутер несколько часов - через некоторое время очередь собралась такая, что радиус запросы превышали время таймаута - и тут уже лавниа - перезапросы от всех насов и юзеров. очередь сообщений вижу в биллинге в консоли - ipcs. В штатном режиме она пустая, либо там очень мало сообщений, которые быстро обрабатываются.... Ну, понятно, что нужно разбираться с биллингом а не с NASами - там нужно оптимизировать алгоритмы и там сделать защиту от DoS. А это именно и есть отказ в обслуживании - хоть и "нечайный"..... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...