DHCP server with SQL support on Perl

[Ivan_83]

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

Именно.

Нет, в планах нет.

Если что и будет в планах такой же только с перламутровым IPv6.

Но мне нынче нет времени и мотивации это делать, фидбэка от вас (провайдеров) не дождёшься пока сам к вам не устроишься.

 

Напомню, изначально оно писалось для провайдера, там этих релеев ну просто завались с коммутаторов, а заодно они нужную опцию 82 добавляют.

Есть и всякие софтовые релеи, которые можно ставить куда то на писюки, если есть такая потребность, а перловый демон вроде и на 127.0.0.1 может повисеть без последствий.

Да, такая конструкция выглядит немного громоздко когда это офисный роутер в сетке на 2-50 компов, но зато и кода сильно меньше и он легче понимается: вот тут пакет пришёл из этого сокета, мы его прожевали, посовещались вон там с базой и вот тут отправим ответ. Никакой магии.

 

 

А FreeRadius dhcp научился в броадкаст? Он же тоже только через релей умел.

Кажется он на фре его не умел.

Но это по моим данным года 2011 :)

 

 

Отнюдь.. Он давно уж умел. Только были какие то нарекания о сырости, и не полноценности решения. Но это было давно оч. Сам такой метод не использовал. Alex/AT GrandPr1de Кто пользовался FreeRadius в роли dhcp? Поделитесь впечатлениями, реализацией.

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

Я же начинал это всё именно с фрирадиуса, и у меня был в общем рабочий конфиг который делал тоже самое, потом я посмотрел на него и выкинул лишнее - фрирадиус.

[bomberman]

Если что и будет в планах такой же только с перламутровым IPv6.

Вот это совсем не плохо было бы.

Там весь прикол что с базой он работает прилично опять же если всё пускать через перловый код

Вот и я о том же, когда говорил о нареканиях и сырости решения. Но наивно пологал, что времени от первого релиза прошло достаточно, чтоб избавиться от perl-овых костылей. Хатя... Как я понял, разрабочики реализовали DHCP там по стольку, по скольку, в классическом варианте, дабы показать возможность работы этого протокола совместно с RADIUS, и реализовали возможность отдавать опции атрибутами. Большего никто и не обещал. Как где то слышал "FreeRADIUS - это фреймворк для протокола RADIUS." (с) Отсюда и костыли, для нужной логики работы. Да и провайдеру мало такая реализация подойдёт в том виде, в котором оно реализовано там, особенно, когда нужно ещё из пакета получить нужные опции, кроме 82й (на сколько я помню это было возможно там), как например номер vlan-а опцией. Для этих целей accel вполне, как по мне.

[pppoetest]

Но мне нынче нет времени и мотивации это делать, фидбэка от вас (провайдеров) не дождёшься пока сам к вам не устроишься.

Ну какой фидбек, если оно из серии: сконфигурил БД, перепилил логику выдачи адресов под себя, и оно работает годами безперебойно?

 

ПЫСЫ. Реквестирую ипв6, донат опять же за свой счёт, начальство стало ещё более жадным (((

[Alex/AT]

А FreeRadius dhcp научился в броадкаст? Он же тоже только через релей умел.

Мммм... может очень давно не умел. Я на нём на броадкаст респондил ещё 3 с лишним года назад :)

 

Насчёт поделиться опытом - сейчас покопаюсь, может найду старые скрипты и конфиги - в связи со сменой места деятельности стали не актуальны и свалены в архив.

С тех пор FR, правда, сильно доработали - возможно, можно сделать гораздо проще.

 

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

[Alex/AT]

Вот, собрал то, что работало как раз под броадкаст (там и релеи были, но отличия только в части конфига "сайта" FR).

Собственно разбором и форматированием протокола занимается FreeRADIUS, PHP'шник же реализует исключительно логику выдачи/регистрации адресов и параметров.

Для меня основным подвигом в сторону FR+PHP стало то, что благодаря FR не нужно самостоятельно реализовывать собственно DHCP, только логику отдачи адресов.

Возможно сейчас и логику можно на унланге в FR реализовать или на хранимках в (whatever)SQL, не знаю, давно не требовалось.

 

Нужно учесть, что это всё конкретное старьё, работало на FR 2.2.0, сейчас могут быть отличия. Конфиг FR очевиден, схема БД должна быть очевидна, пример заполнения тоже.

Если что-то не совсем очевидно или нужно понять, как написать своё - смотрите собственно в PHP'шник (который как раз логика выдачи адресов/параметров в связке с БД).

 

Что по части разбора FR протокола и сбора его обратно из вывода скрипта - никаких особых проблем не возникало, всякие октетстринги типа opt82 в скрипт уходят в hex-виде, кастомные атрибуты вполне себе добавляются через словарь.

 

fr-dhcp-example.zip

[GrandPr1de]

Благодарю, обязательно погляжу как там сделано.

[kopMuk]

Привет, подскажите, с какой целью сделано:

if (index($_[0], DHO_NTP_SERVERS()) != -1) {
    $_[1]->addOptionValue(DHO_NTP_SERVERS(), "$NTP");
}

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

[pppoetest]

Если в запросе есть опция ntp, в ответ вставляется данный параметр.

[Ivan_83]

13 часов назад, kopMuk сказал:

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

Клиент передаёт список опций который он хочет и может.

Насколько помню в RFC было сказано не пихать в ответ то, про что не спрашивали.

[hiller]

похоже пришло время добавить сюда поддержку IPv6 )

[Ivan_83]

Что, уже?)

Именно DHCPv6 или rtadv/rtsol тоже?

 

PS: проще написать на базе этого отдельный демон чем расширять этот, всё равно в протокольной части ничего общего.

[andryas]

6 hours ago, Ivan_83 said:

PS: проще написать на базе этого отдельный демон чем расширять этот, всё равно в протокольной части ничего общего.

+

[Ivan_83]

Появилась тут мысль написать универсальное решение для IPv4, IPv6.

 

Демон на Си будет ловить DHCP, перепаковывать их в JSON и слать на вебсервер по HTTP, ответы в JSON перепаковывать обратно в DHCP и отправлять на релей агента откуда пришёл запрос.

Всю логику выдачи адресов и работы с базой любой желающий в такой архитектуре сможет накодить на любом языке сам, плюс есть все возможности по балансировке и прочему.

Может быть будут простейшие фильтры скопипащены из перловой реализации чтобы демон мог отбрасывать мусорные запросы.

 

Что скажите?

[alibek]

JSON, да еще поверх HTTP.

Разве что в исследовательских или экспериментальных целях.

[Ivan_83]

В 18.03.2022 в 16:45, alibek сказал:

JSON, да еще поверх HTTP.

А что такого?

 

На сях такое генерится и парсится очень быстро.

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

XML думаю уже мёртв.

 

Возможность откусить HTTP и слать только JSON я легко организую.

 

Отработать 1-5к/сек запросов по веб нынче дело житейское, и по прошлому опыту оно упиралось в базу данных.

Плюс возможность лёгкой горизонтальной балансировки - запросы можно раскидать на кластер любого размера.

 

На самом деле технически чуть проще было бы реализовать DHCP<->RADIUS прокси - они оба stateless, но там есть фрирадиус с одной стороны, с другой нужно будет мутить какой то нечеловеческий конфиг чтобы опции дхцп мапить в радиус аттрибуты, и теряются все преимущества HTTP который нынче так легко масштабировать и обрабатывать.

[alibek]

В 18.03.2022 в 19:57, Ivan_83 сказал:

А что такого?

Оверхед дикий.

А если читать ответы, то сериализации мало, надо еще и парсить JSON.

[Cramac]

ничего не понятно, но оч интересно....

 

П.С. Пока не ясно плюсы/минусы и для чего, кроме как добавить в6.

[alibek]

Простота кастомизации и тюнинга.

Да и масштабировать проще.

[Ivan_83]

В 18.03.2022 в 17:01, alibek сказал:

Оверхед дикий.

А если читать ответы, то сериализации мало, надо еще и парсить JSON.

Он не был диким даже во времена когда это было сделано не перле.

Реализация на перле получилась такой в следствии эволюции или напилинга.

Эта реализация изначально так сдизайнена.

Парсинг мелких JSON ну вообще не проблема, наверное даже на ARM, и это не большая плата за гибкость.

 

 

В 18.03.2022 в 17:53, Cramac сказал:

П.С. Пока не ясно плюсы/минусы и для чего, кроме как добавить в6.

Потому что нужно расти дальше, привязка к перлу тоже ограничивающий фактор, да и сама архитектура, когда нужно править код проекта под каждую инсталляцию не очень.

 

[Cramac]

@Ivan_83 это да, зато работает ведь :) стоит и не жужжит по сей день

[pppoetest]

В 18.03.2022 в 22:41, Ivan_83 сказал:

Появилась тут мысль написать универсальное решение для IPv4, IPv6.

Для многих, думаю, будет актуально, хотя хттп+джысон мне кажется сомнительным. Я же переехал на аксель, решение на перле верой и правдой проработало как часы почти 10 лет.

 

В 19.03.2022 в 00:08, Ivan_83 сказал:

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

Не согласен, именно тем что на перле и возможность безграничной кастомизации меня и привлекли.

[Ivan_83]

В 19.03.2022 в 02:42, pppoetest сказал:

Не согласен, именно тем что на перле и возможность безграничной кастомизации меня и привлекли.

Так и тут такая же фигня по желанию легко мутится: поднимаем либо сокет и ловим json либо там же с хттп, либо где то в контексте спавнера по fcgi ловим опять json, отрабатываем, генерим json и выплёвываем в сокет.

В общем то unix way в полный рост, ну или как теперь модно - микросервисная архитектура.

[hiller]

Оставить бы поддержку my/pg sql, было бы хорошо. Чтобы не включать в цепочку еще и web-сервер с интерпретатором какого-нибудь языка.

 

Из насущного: стоит и работает, но есть проблемки с форматами Option 82 - поддерживается только bin.

[edo]

ну оверхед будет приличный конечно, ну и фиг с ним. согласен, что не те нагрузки, чтобы на него смотреть.

 

пара вопросов:

1. почему си? ИМХО сегодня писать на си — уже моветон. есть golang, если хочется чего-то нежирного — есть rust и более экзотические языки вроде vlang;

2. предполагается ответ в том же соединении, что и запрос? с учётом скриптовости языка, запроса к БД, возможного разнесения по разным хостам и т.п. задержки могут быть относительно большими. стоит ли держать соединение открытым в ожидании ответа?

 

В 18.03.2022 в 19:57, Ivan_83 сказал:

Плюс возможность лёгкой горизонтальной балансировки - запросы можно раскидать на кластер любого размера.

с учётом того, что кластер должен работать с общей БД, вряд ли в нём особый смысл есть.

[sol]

В 20.03.2022 в 13:58, edo сказал:

с учётом того, что кластер должен работать с общей БД,

Репликация же...