Фичереквест на NoDeny+

[h1vs2]

Все правильно X-RAY говорит. При его количестве абонентов isc-dhcpd - одно из узких мест.
Это монстроузное и немашатабируемое решение.

Попробуйте, когда у вас от 15К абонентов, рестартить его номейком на каждых чих.

Крупные сети давно юзают либо написанный собственноручно dhcp сервер, или купленный у кого-то, который работает либо через радиус, либо напрямую c БД.
Без необходимости рестартов и тд.

[Rico-X]

Чтоб не заниматься перепостингом http://local.com.ua/forum/topic/29029-stgdhcpservermysql/
ИМХО писать новый лисапед, потом заниматься его отладкой, чтоб и с виндами и роутерами работал, а еще opt82 держал и нагрузку, а еще кучу баз поддерживал да желательно статику отдавал и работу разными диапазонами в одном вилане, еще обучить свой сервак работать с аппаратными relay - вы хотя бы представляете себе объем необходимой работы и кода? При том что при более 5К статических хостов рестарт isc-dhcp занимает менее секунды и нужен только при добавлении нового абонента. Если вы клиентов добавляете по сотне в час, рестарт можно делать по крону раз в сутки. Повторюсь это ИМХО

[h1vs2]

Чтоб не заниматься перепостингом http://local.com.ua/forum/topic/29029-stgdhcpservermysql/
ИМХО писать новый лисапед, потом заниматься его отладкой, чтоб и с виндами и роутерами работал, а еще opt82 держал и нагрузку, а еще кучу баз поддерживал да желательно статику отдавал и работу разными диапазонами в одном вилане, еще обучить свой сервак работать с аппаратными relay - вы хотя бы представляете себе объем необходимой работы и кода? При том что при более 5К статических хостов рестарт isc-dhcp занимает менее секунды и нужен только при добавлении нового абонента. Если вы клиентов добавляете по сотне в час, рестарт можно делать по крону раз в сутки. Повторюсь это ИМХО

Это все справедливо при не большом числе абонентов и скудном количестве предоставляемых сервисов.

Логично предположить, что чем, больше юзеров, тем больше эта задержка и в больших сетях она недопустима, как и рестарт раз в сутки.

С той-же opt82 у isc-dhcpd не все порядке из коробки, его нужно патчить. (дабы не отвечать еще на один пост : "у меня все работает" - если клиенту выделен определенный IP адрес, он вставит один комп, потом вставит 2-й, то получит шишь, пока не истичет время лизы. Правится патчем, после которого isc-dhcpd стает пригоден только в роли dhcp сервера под option82)

P.S.
Меня больше интересует наработки в сторону связки с брас-фунционалом через радиус для Cisco/Juniper/Ericsson из коробки , или в виде вменяемых модулей.

Так-же интересует переработка подходу к "Топология" и "Оборудование", то, что сейчас есть, сильно ограничивает даже в разработке собственных модулей. Ибо концепция "одна точка - одно устройство" - никуда не годится.

Биллинг всем хорош. Пока у тебя 1,2,3,n сервера на freebsd и куча мыльниц. Когда вырастаешь и у тебя уже брасы/бордеры железные, всюду управляемое железо и куча сервисов -  тут начинается интерестное - замечаешь, что он оброс на овер 9000 процентов своими и сторонними модулями и кроме того его архитектура ограничивает твой полет фантазий и возможности твоего программиста.

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

 

[Efendy]

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

[h1vs2]

ОФФТОП: 2 Efendy Хорошая статья на хабре. http://habrahabr.ru/post/140736/

[Andrey Zentavr]

ОФФТОП: 2 Efendy Хорошая статья на хабре. http://habrahabr.ru/post/140736/

Оффтоп: его же статья по ходу (см. кто автор) %)

[maxx]

Например, я сейчас уткнулся в невозможность радиусом дропнуть юзера. Есть, конечно средства, расширяющие возможности радиуса, например когда он может инициировать запрос к НАСу и сказать "дропни сессию".

абилс скриптом дропает с мпд телнетом. Помоему нормальное решение

[Efendy]

Например, я сейчас уткнулся в невозможность радиусом дропнуть юзера. Есть, конечно средства, расширяющие возможности радиуса, например когда он может инициировать запрос к НАСу и сказать "дропни сессию".

абилс скриптом дропает с мпд телнетом. Помоему нормальное решение

нормальное решение - это когда не нужно изобретать велосипедов. Те, кто придумывал протокол радиуса, не предусмотрели такой элементарной вещи, печалька

[Redmen]

на счёт фич, я би добавил встроеный планировщик заданий
єто могло б усовершенствовать у расширить функцыональность модулей
добавить гибкость нужную модулям
(new_month.pl, notise_mess.pl)
(можно организовать модулём)

[ser970]

клиенту выдается новый ип и надо реконнектить его. И .. фак.. я не могу тупо сказать насу "дропни сессию"

почему?
http://mpd.sourceforge.net/doc5/mpd32.html#32
походу можно и убить сесию и заставить перечитать.

з.ы. я не пробовал, но  судя по ману это реально

[Efendy]

А почитать, что такое disconnect-request? Есть расширение radius-а, позволяющее посылать запросы от радиуса к nas (в стандартном радиусе только nas посылает запросы). При аккаунтинге не предусмотрено в принципе ни каких атрибутов, которые может посылать радиус nas-у. вообще. Т.е невозможно в принципе ничего отослать nas-у, даже привет. Можно создать отдельное соединение (читай костыли/скрипты и т.д., которые будут просматривать очередь на отключение (нахуя мне нужно вести и синхронизировать какую-то очередь) и дропать юзеров)

[ser970]

А почитать, что такое disconnect-request? Есть расширение radius-а, позволяющее посылать запросы от радиуса к nas (в стандартном радиусе только nas посылает запросы). При аккаунтинге не предусмотрено в принципе ни каких атрибутов, которые может посылать радиус nas-у. вообще. Т.е невозможно в принципе ничего отослать nas-у, даже привет. Можно создать отдельное соединение (читай костыли/скрипты и т.д., которые будут просматривать очередь на отключение (нахуя мне нужно вести и синхронизировать какую-то очередь) и дропать юзеров)

а телнетом лезть на мпд лучше ?
или или все таки проще
в мпд
set radsrv peer
set radsrv open
и
/usr/local/share/freeradius/dictionary
....
и радиус сможет говорить мпд что нужно сделать.
это и есть протокол радиуса
или я всетаки чегото не понял ? вы же писали что

И .. фак.. я не могу тупо сказать насу "дропни сессию"

[Efendy]

Говорю же: не предусмотрена посылка этого (вернее, ЛЮБОГО) атрибута радиусом в эккаунтинге. Детальнее. Mpd поднял сессию pppoe. Регулярно шлет эккаунтинг пакеты на радиус.  Радиус их принимает и НИЧЕГО не шлет ответ! Это заложено протоколом:

 A RADIUS Accounting-Response is not required to have any  attributes in it. (http://www.ietf.org/rfc/rfc2866.txt)

Если в какой-то момент времени известно, что нужно отрубить клиента, нужно дернуть скрипт, который заставит радиус послать пакет, который, ДА, будет принят мпд и мпд распознает этот клевый атрибук, который не поддерживают многие насы, но мпд молодец. Юзер будет дропнут. А теперь сложность: Все в мире имеет инерцию. Если я буду держать очередь отключений, которую будет отрабатывать скрипт, возможна ситуация, когда уже не надо дпропать - клиент успел сам переконнектиться. Редко, но может случиться. Да и зачем это усложение, если бы... повторю:

 A RADIUS Accounting-Response is not required to have any  attributes in it.

[Efendy]

Почему надо дропать именно в эккаунтинге? Ситуация: клиент соединился. Админ взял и поменял ип. Нуна поменять ип клиенту. В эккаунтинге мы видим, что ip, который прислал НАС и ip, под которым авторизован клиент не совпадают. Значит шлем в ответ "дроп"

[h1vs2]

ОФФТОП: 2 Efendy Хорошая статья на хабре. http://habrahabr.ru/post/140736/

Оффтоп: его же статья по ходу (см. кто автор) %)

Я это и имел ввиду