[ivan999]

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

 

Кто четко владеет нюансами работы Free radius.

Есть схемка - Radius Сервер в связке с NAS (MikrotikOS 5)

Юзеры коннектяться на NASы с помощью L2TP.

 

Бывают случаи, что юзерская сессия некорректно прервана (сейчас не важно почему)- т.е. на NAS юзера уже нет, а на Radius сервере он висит.

Потом юзер пытается переподключиться - но его не пускает, потому что запрещено под одним логином несколько юзеров.

 

Можно ли решить это на уровне радиус протокола (с учетом FreeRadius + Mikrotik)?

Либо нужны костыли сторонние ввиде скриптов, дополнительных проверок...?

Есть наработки у кого по этому поводу?

 

 

 

_____________________

Какие мысли?

Изменено 4 июля, 2011 пользователем ivan999

[littlesavage]

Стандартный freeradius'овый checkrad.pl умеет опрашивать mikrotik по telnet и по snmp.

[ivan999]

целый день думал и много читал. Получается много костылей - если несколько NASов - не очень надежно.

Лучший вариант - не давать коннектиться второй раз с любого NAS - если на сервере Radius - такой login числиться активным.

С повисшей сессией броться так - если нет с насов радиус пакетов с id Этого юзера более 15 минут - очищать в базе. И через это время юзер сможет переподключиться.

А чтобы не долюили разные роутеры типа длинк дир-100 - нужно запретить количество попытко коннектов чаще чем , например 5 в минуту. Если больше - в черный список фаеравола на 15 минут.

 

Но вот оказалось не так просто для L2TP это сделать - потому что во-первых он юзает UDP - т.е. статус "новое соединение" -весьма условно. Баловоство в conntrack с UDP таймацтами приносит только негативные результаты.

А во-вторых - для передачи полезных данных юзается тот же порт, что и для установления тунеля. В итоге данные перед тем как попасть в форвард - все равно будут в input (в туннеле заходить).

В отличие от PPTP - где GRE и TCP - разные протоколы для поддержки тунеля и для данных - там было бы проще.

 

Есть только вариант отловить с помощью регулярного выражения пакеты на уровне L7 - именно содержашие признаки начало установления тунеля L2TP.

 

Пока не осилил создать regexp Для микротика. есть дамп трафика. Вижу нужный пакет. Вижу hex значения - но пока не получается в тик его грамотно записать. Кто поможет, подскажет?

 

Даже отдельную тему создам рядом...

топег

[ivan999]

Регулярные выражения не прокатят - все тоже из-за UDP, контрэк и особенностей поиска регулярных выражений в потоке (только первые N пакетов потока....)

[littlesavage]

ivan999, фигней страдаешь. Не нужно тебе никаких черных списков и 15-минутных блокировок. Пусть роутеры долбятся, мешать они не будут.

[ivan999]

ivan999, фигней страдаешь. Не нужно тебе никаких черных списков и 15-минутных блокировок. Пусть роутеры долбятся, мешать они не будут.

Если бы так. Сам NAS - куда долбиться юзер - действительно не страдает никак - жует и не чихает. Но вот он делает запросы через радиус на биллинг. А там генерируются события, запускаются скрипты, делаются запросы в базу и потом отсылают результы опять на NAS. Вот на этом этапе и возникает постепенное запаздываение и накопление в очереди этих событий (они выстравиааются в очередь и выполняются последовательно). Т.е. биллинг медленнееобрабатывает факт логина - потому что ему нужно сделать больше операций. и тут страдают другие юзеры - задержка растет. Вот долбил глючный роутер несколько часов - через некоторое время очередь собралась такая, что радиус запросы превышали время таймаута - и тут уже лавниа - перезапросы от всех насов и юзеров. очередь сообщений вижу в биллинге в консоли - ipcs. В штатном режиме она пустая, либо там очень мало сообщений, которые быстро обрабатываются....

 

Ну, понятно, что нужно разбираться с биллингом а не с NASами - там нужно оптимизировать алгоритмы и там сделать защиту от DoS. А это именно и есть отказ в обслуживании - хоть и "нечайный".....