[Wingman]

Предыстория: достаточно долго метался в поисках способа удобного запуска на сети dhcp+option 82.

Потому как ISC-DHCP - это:

- километровые неудобочитаемые конфиги;

- постоянные передергивания при изменениях;

- НЕ-риалтайм управление DHCP-сервером;

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

- Сложность с выдачей нескольких IP на порт.

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

 

Вместе с тем, кроме ISC-DHCP вроде как промышленно-стандартных dhcp-серверов и нету.

 

 

Но порыскав по инету, я наткнулся на несколько постов ув. Magnum72 в духе "юзайте freeradius as dhcp, и всё будет". А у него в сети вроде несколько десятков к. хомячков, так что можно и попробовать =) После нескольких дней, долгого ковыряния радиуса и одного багрепорта ;)) для себя в голове минимально-необходимое уложил:

 

- freeradius работает как DHCP с поддержкой Option82. И даже при некоторой удаче крутится и не падает.

- Реализован в freeradius практически только голый сетевой API. Содержимым пакетов, что когда и куда управлять - писать нужно самому. С одной стороны, оно и к лучшему.

- Реализовывается нужный функционал любым rlm_*, где есть хук post_auth(). Для себя я выбрал rlm_perl ;) С одной стороны, работать, конечно, будет помедленнее, чем бинарный сяшный dhcpd. С другой стороны, никто не мешает поднять хоть штук пять dhcp-серверов. И либо для разных сегментов в свитчах в разном порядке релеи прописывать, либо ещё как балансировать. Зато удобство и скорость разработки в разы возрастают. Ну и устаканив всё в перле, можно и свой rlm-модуль на сях написать.

 

 

Вывод - надо пробовать поднять всё на фрирадиусе ;)

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

 

 

Необходимые факторы работы DHCP вижу следующие:

1. Возможность выдачи нескольких IP на порт (читай на аккаунт).

2. Возможность дополнительной привязки к маку (Вдруг где-то в старом сегменте таки-останется тупой свитч)

3. Не должно быть проблем с моментальным перетыкиванием устройств на порту. Переткнул -- заработать должно сразу.

4. Должны выдаваться статические маршруты, поскольку гонять инет будем через PC, а локалку через железки.

5. В заблокированном состоянии в наших планах на порту прописывать другой влан. В этом влане выдавать всем IP из некого IP-пула "blocked" и заворачивать http-трафик на страничку "дай денег" ;))

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

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

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

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

в. Найдя мак на абонентском (1-24) порту, включить на нём untagged рабочий влан

г1. Найти в билинге привязки данного логина. Если есть - удалить.

г2. Привязать данный логин к найденному скриптом порту.

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

 

 

 

 

Алгоритм дхцп представляю как-то так:

Приходит DHCP-Discover/Request
    Смотрим, есть ли в нём информация Option82.
        Если option82_info {
            Если влан "заблокированные", выдаём IP-адрес из серого спецпула. Пишем в лизы.
            Если влан "неактивированные", выдаём из другого серого спецпула. Пишем в лизы.
            Иначе {
                выбрать ip, где port=X AND switch=Y AND (mac='x-x-x-x-x-x' OR mac='');
                Если rows > 1 {
                    // Если возможных ипов на свитче более одного
                    выбрать ip из lease_table где port=y and switch=z and last_leased_time > (now_time - $lease_time + 5)
                    Если есть лизы {

                        Возможно, юзер включил 2 компа параллельно. Смотрим лизы.
                        Если текущая лиза с таким же маком, как в запросе - возможно, просто ребут компа. Выдаём тот же ип.
                        Если текущая лиза с другим маком И лиза только одна - выдаём второй возможный ип.
                        Если активных лиз (с неистеченным lease_time) столько же, сколько возможных ипов для порта и такого
                            мака, как пришел в запросе - в них нет, затираем лизу с временем обновления старше остальных и
                            выдаём ип из неё по новой.

                        Обновляем last_leased_time в лизе.
                    } // if leases exists

                } // if rows>1

                Если возможный ип на порту только один { в любом случае, независимо от прошлых лиз выдаём один и тот же ип. }

            } // if !blocked && !unact
        } // if op82
        else {
            // Если запрос пришел без option82 инфы. По идее, это случается только когда IP уже получен, и требуется обновление
            // лизы. Ну или `ipconfig /renew`, например. Тогда комп обращается к dhcp по уникасту, и relay-инфо в пакет не вставляется.
            а. Из пришедшего пакета известен IP + MAC
            б. Выбрать из lease_table ГДЕ ip=$ip AND mac=$mac
            в. Если есть - отдаём ту же самую инфу и обновляем лизу
            г. Если нет -- шлём DHCPNAK ( [b]?[/b] ХЗ, в каких случаях может такое случиться кроме глюка клиента? По идее не должно )

        } // if !op82


DHCP-Release -> затираем лизу

DHCP->Inform -> Что с ними делать, зачем они могут понадобиться? 
DHCP-Остальное -> Игнорим?

 

Из этого пока у меня есть freeradius, перенаправляющий DHCP на rlm_perl, в котором есть привязка в коде одного ip для одного порта =)

 

 

Ещё остаётся вопрос: как разруливать пулы? Попробовать прикрутить sql_ippool (никогда не юзал, не знаю, как работает), или своими силами так же, как лизы? типа select ... from pool where last_leased_time < (time-$lease_time+10) ? Тогда нужно таблицу со всеми возможными ипами держать, некрасиво ;)

 

 

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

Кто заинтересован в развитии чего-то такого - буду рад любой помощи, Кто уже внедрил что-то по теме сабжа у себя - буду рад саветам и направлениям в нужное русло ;)

 

Самому мне по условиям задачи нужно или поднять, оттестить и внедрить у себя option82 + IPoE в течение пары месяцев, или забыть надолго. Буду стараться внедрить ;)

 

 

з.ы. Само IPoE хочу выпускать через Linux-ISG камрада Умника из соседнего треда. Беглым тестом - работает отлично ;)

Изменено 31 мая, 2010 пользователем Wingman

[Deac]

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

[Wingman]

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

1.

 

Как, например, нативно, без привлечения rlm_perl, из freeradius отправить информацию о статич. маршрутах?

На данный момент classless-routes даже в его словаре нет.

 

Перлом легко:

добавляем в словарь опцию DHCP 249;

пишем ф-ю для преобразования, например, "net 10.10.0.0/16, gw 1.2.3.4" в "16, 10, 10, 1, 2, 3, 4", и для преобразования получившегося в HEX. Далее загоняем в $RAD_REPLY{'DHCP-MS-Static-Routes'}, и готово.

 

 

2.

 

На данный момент радиус не парсит circuit-id. Т.е. приходит hex-строчка, в ней слитно в хексе влан и порт. Как вытащить нативно? Перлом - легко

Изменено 31 мая, 2010 пользователем Wingman

[shicoy]

- километровые неудобочитаемые конфиги;

- постоянные передергивания при изменениях;

- НЕ-риалтайм управление DHCP-сервером;

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

- Сложность с выдачей нескольких IP на порт.

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

Скажем так:

1) Конфиг на самом деле может быть очень простым если пользоваться командой include и длинный конфиг разбить на несколько частей

2) И что? Скажем так, у меня конфиг ~2Мбайта, время ребута менее 5 сек. Ни разу не критично, если не ребутить каждую минуту. К тому же конфигурация dhcp при правильном планировании доступа с opt82 более менее статична.

3) см п.2

4) Время лиза нужно сократить до приемлимых 15-60 минут, и тогда со сменой оборудования в порту абонента нет никаких.

В поддержку этой мысли скажу, что opt82 без поддержки dchp snooping на доступе по большей части бесмысленна, а время бинда связки ip+mac равно времени лиза.

5) Возможность выдачи нескольких IP на порт в isc-dhcp не проблема, в том числе и использованием opt82

6) Все зависит от биллинга и BRAS. У вас что? (про ISG от умника я уже понял). Какой биллинг? UTM5? Сочувствую.

[Deac]

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

 

Как, например, нативно, без привлечения rlm_perl, из freeradius отправить информацию о статич. маршрутах?

На данный момент classless-routes даже в его словаре нет.

 

Перлом легко:

добавляем в словарь опцию DHCP 249;

пишем ф-ю для преобразования, например, "net 10.10.0.0/16, gw 1.2.3.4" в "16, 10, 10, 1, 2, 3, 4", и для преобразования получившегося в HEX. Далее загоняем в $RAD_REPLY{'DHCP-MS-Static-Routes'}, и готово.

attr rewrite - всё что угодно, любые атрибуты из любых других и SQL модуля.

[Wingman]

2) И что? Скажем так, у меня конфиг ~2Мбайта, время ребута менее 5 сек. Ни разу не критично, если не ребутить каждую минуту. К тому же конфигурация dhcp при правильном планировании доступа с opt82 более менее статична.

Приходит монтажник к клиенту. Его выкидывает на страницу инициализации -- клиент только подключен, и его порт неизвестен. Вводит логин-пароль, в БД данные прописываются.

Дальше - либо ждать 10-30-60 минут до передёргивания конфига кроном, либо дёргать переформирование конфига exec'ом с веба? И стрёмно, и долго...

 

4) Время лиза нужно сократить до приемлимых 15-60 минут, и тогда со сменой оборудования в порту абонента нет никаких.

В поддержку этой мысли скажу, что opt82 без поддержки dchp snooping на доступе по большей части бесмысленна, а время бинда связки ip+mac равно времени лиза.

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

dhcp_snooping естественно нужен. Ну и что? Что мешает при этом юзеру перезапросить dhcp и тем самым переписать binding entry на свитче? На самом деле не сильно вникал -- даже если в течение времени бинда нельзя прописывать новую пару (хотя сомневаюсь), то ничто не мешает сделать лимит пар для бинда maxips+1 на порту.

 

6) Все зависит от биллинга и BRAS. У вас что? (про ISG от умника я уже понял). Какой биллинг? UTM5? Сочувствую.

Билинг да, UTM, и я временами сам себе сочувствую =) И тем не менее "маемо те, що маемо", и крутится на более чем 10к абонентов без проблем, хотя конечно от изначального УТМа мало что осталось =) Ну в общем это не тема для обсуждения в данной ситуации.

 

з.ы. а "идеальному билингу" isc как сообщил бы о том, что "юзеру №N" выдан ип "x.x.x.x" в date() ?

Изменено 31 мая, 2010 пользователем Wingman

[Wingman]

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

 

Как, например, нативно, без привлечения rlm_perl, из freeradius отправить информацию о статич. маршрутах?

На данный момент classless-routes даже в его словаре нет.

 

Перлом легко:

добавляем в словарь опцию DHCP 249;

пишем ф-ю для преобразования, например, "net 10.10.0.0/16, gw 1.2.3.4" в "16, 10, 10, 1, 2, 3, 4", и для преобразования получившегося в HEX. Далее загоняем в $RAD_REPLY{'DHCP-MS-Static-Routes'}, и готово.

attr rewrite - всё что угодно, любые атрибуты из любых других и SQL модуля.

А распарсить circuit-id как?

А перевести человеко-читабельные маршруты в стандарт dhcp и в hex? Есть вариант - держать в базе уже в "готовом" виде, но имхо неудобно

 

 

p.s. Товарищи, если я пишу где-то резко (всё же спор) -- прошу учесть, что и в мыслях нет никакой ни к кому неприязни! Наоборот, всё сказанное в этом треде и мной и, думаю, многими другими будет с благодарностью намотано на ус и где-то как-то применено =)

Изменено 31 мая, 2010 пользователем Wingman

[Deac]

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

 

Как, например, нативно, без привлечения rlm_perl, из freeradius отправить информацию о статич. маршрутах?

На данный момент classless-routes даже в его словаре нет.

 

Перлом легко:

добавляем в словарь опцию DHCP 249;

пишем ф-ю для преобразования, например, "net 10.10.0.0/16, gw 1.2.3.4" в "16, 10, 10, 1, 2, 3, 4", и для преобразования получившегося в HEX. Далее загоняем в $RAD_REPLY{'DHCP-MS-Static-Routes'}, и готово.

attr rewrite - всё что угодно, любые атрибуты из любых других и SQL модуля.

А распарсить circuit-id как?

А перевести человеко-читабельные маршруты в стандарт dhcp и в hex? Есть вариант - держать в базе уже в "готовом" виде, но имхо неудобно

 

 

p.s. Товарищи, если я пишу где-то резко (всё же спор) -- прошу учесть, что и в мыслях нет никакой ни к кому неприязни! Наоборот, всё сказанное в этом треде и мной и, думаю, многими другими будет с благодарностью намотано на ус и где-то как-то применено =)

Держать готовыми не надо, делай SQL модуль на PostgreSQL и формируй всё что надо соотв. функциями, по мере надобности и в том виде, как требуется.

 

[Wingman]

А таки как cirquit-id распарсить?

 

Ну а postgres (это, конечно, частный случай, но тем не менее) - UTM5 наш гораздо лучше себя чувствует на mysql, и переносить - не вариант ;(

[Deac]

Возвращаемся ко 2-ой ветке FreeRADIUS-а, условия там похожи на perl-овые, парси что угодно.

Ну а MySQL - далеко не лучший вариант, хотя и UTM - тоже.

Изменено 31 мая, 2010 пользователем Deac

[Wingman]

Возвращаемся ко 2-ой ветке FreeRADIUS-а, условия там похожи на perl-овые, парси что угодно.

Блин ;)

Фрирадиус второй ветки принимает Circuit-Id как, например, 012345abcdefgh

012345 отбрасываем.

vlan = unhex(abcd)

port = unhex(efgh)

 

а вот даааааааальше уже пойдут условия...

 

Как такое в радиусе сделать?

Изменено 31 мая, 2010 пользователем Wingman

[Deac]

http://wiki.freeradius.org/Adding,_Removin...ther_processing

[shicoy]

2Wingman я думаю, архитектурно, ты немного не правильно мыслишь. Или я что-то не до понимаю.

Попытаюсь объяснить почему:

Что первично? Порт доступа/Коммутатор, IP абонента? По чему идентифицировать абонента?

Если учесть, что UTM5 умеет только по IP, следовательно должно быть заранее распределенно по портам коммутатора предопределенные IP или IP range

Соотвественно нет проблем заранее написать статический dhcp конфиг, в котором на каждом agent-id/circuit-id свой IP (понятное дело что серый)

 

и давайте пока абстрагируемся от функций L4 редиректа и автоматизации процесса подключений монтажниками. это больше к функциям ISG или BRAS, чем к функциям сети доступа.

 

Таким образом ваша задача сводится заранее знать и расписать за каким портом какой IP, и соотвественно при подключении абонента привязать этот IP к нужному договору/тарифу.

 

Есть другие варианты, но они требуют серьезных BRAS с полноценными Subscriber Mangement

 

Я не против связки FreeRadius + dhcp просто хочу понять зачем этот "почти костыль", когда есть вполне стабильное решение.

Изменено 31 мая, 2010 пользователем shicoy

[Wingman]

http://wiki.freeradius.org/Adding,_Removin...ther_processing

Как это поможет преобразовать hex->dec и наоборот?

 

 

2shicoy

Да, в _идеальной_ сети и ситуации примерно так и должно быть, как ты расписал. Но так не бывает, к сожалению ;)

Но.

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

А поскольку за свитчем авторизация идёт уже только по IP -- последствия пугают.

Тут-то и вылазит крупным планом удобство динамической базы по сравнению с конфигом.

Опять же, внешняя динамика по dhcp -- когда-нибуть хотим и её. rlm_perl легко сообщит УТМу, что такому-то аккаунту выдан такой-то ип. Привяжет его, то бишь. А isc врядли, как мне кажется.

 

А если не абстрагироваться от всего остального - всё ещё более усугубляется...

Да, в _идеальной_ ситуации я купил бы asr и рулил бы всё на ней, настроив и забыв, но... ;)

 

 

 

Я не против связки FreeRadius + dhcp просто хочу понять зачем этот "почти костыль", когда есть вполне стабильное решение.

Если оно будет работать, и работать стабильно -- рано или поздно этот костыль, мне кажется, потеснит ISC (может быть для специфических условий/объёмов, но тем не менее). Просто потому, что работать с базой _УДОБНЕЕ_ по умолчанию. Точно так же никто не держит авторизацию в freeradius на файлах, а в основном на БД. Ну на определённых обьемах данных, конечно ;)

 

Ну и просто набери в гугле "dhcp sql". Это действительно не прихоть, это ОЧЕНЬ востребованно =) Сколько костылей вышло типа dhcp2radius, dhcp2sql в виде патчей. Куча провайдеров под себя dhcp-серверы и переписывали, и с нуля писали..

Изменено 31 мая, 2010 пользователем Wingman

[Deac]

Во первых - зачем вообще конвертить hex->dec, оно и так уникально, без конвертации.

Во вторых - на то тебе и SQL модуль даден, 1 хрен без него не обойдёшься, в любом SQL эта функция есть.

И вообще я сторонник VPN, like PPPoE, PPtP и пр. L2TP - порты можно "путать" как угодно и контроль над юзером полный.

 

Изменено 31 мая, 2010 пользователем Deac

[Wingman]

Во первых - зачем вообще конвертить hex->dec, оно и так уникально, без конвертации.

Во вторых - на то тебе и SQL модуль даден, 1 хрен без него не обойдёшься, в любом SQL эта функция есть.

Тогда набросай плз хоть примерно, как из virtual-сервера dhcp выполнить custom sql квери, принять от него результат и как-то обработать? Потом ещё раз, потом ещё. Это всё в одной секции (DHCP-Request, например)?

До этого rlm_sql юзал только как раз для ppp-авторизации; там просто - есть секции auth, accounting, например, и есть предефинед квери auth, accounting_start/stop, etc...

 

И вообще я сторонник VPN, like PPPoE, PPtP и пр. L2TP - порты можно "путать" как угодно и контроль над юзером полный.

Это-то да, но при dhcp+opt82 воткнул патчкорд - инет есть. При должной скурпулёзности в реализации в разы снизит нагрузку на саппорт, нагрузку на железо, и упростит жизнь обычному юзеру. Кражу аккаунтов, опять же, исключит (у нас она довольно часта).

[Deac]

Во первых - зачем вообще конвертить hex->dec, оно и так уникально, без конвертации.

Во вторых - на то тебе и SQL модуль даден, 1 хрен без него не обойдёшься, в любом SQL эта функция есть.

Тогда набросай плз хоть примерно, как из virtual-сервера dhcp выполнить custom sql квери, принять от него результат и как-то обработать? Потом ещё раз, потом ещё. Это всё в одной секции (DHCP-Request, например)?

До этого rlm_sql юзал только как раз для ppp-авторизации; там просто - есть секции auth, accounting, например, и есть предефинед квери auth, accounting_start/stop, etc...

 

И вообще я сторонник VPN, like PPPoE, PPtP и пр. L2TP - порты можно "путать" как угодно и контроль над юзером полный.

Это-то да, но при dhcp+opt82 воткнул патчкорд - инет есть. При должной скурпулёзности в реализации в разы снизит нагрузку на саппорт, нагрузку на железо, и упростит жизнь обычному юзеру. Кражу аккаунтов, опять же, исключит (у нас она довольно часта).

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

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

 

Кражу аккаунтов исключит привязка по MAC.

MPD, например, MAC отдаёт.

[shicoy]

2Wingman очень не хочется разводить архитектурную полемику в твоем топике, просто от себя замечу что если монтажники гоняют кабель туда-сюда, то тут проблема уж точно не в связке Freeradius+dhcp, а видимо в управлении монтажниками. А что если они сменят кабеля абонентов местами, а в схеме opt82 авторизация абонента это всегда agent-id + circuit-id. Или я опять чего-то не понимаю.

 

У нас кстати по причинам "монтажников" достаточно долго откладывается переход на IPoE, и его не будет пока не проинспектируем-документируем всю сеть и не выработаем регламенты работ для монтажников.

 

Я не говорю что связка dhcp+sql или dhcp+freeradius+sql плохая, наоборот, я тоже за, просто в том виде в котором оно вам надо, ну не могу понять смысл, когда любой джамшут может переткнуть кабель абонента и все... баста. Где-же у вас тогда аутентификация-валидация абонента будет происходить?

[Wingman]

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

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

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

Про плоды - я тоже так хочу :D

 

 

Кражу аккаунтов исключит привязка по MAC.

MPD, например, MAC отдаёт.

Если привязывать маки - мало смысла и с op82 трахаться...

Плюс -- у меня vpn-брасы в отдельном сегменте и маков не видят

 

 

2Wingman очень не хочется разводить архитектурную полемику в твоем топике, просто от себя замечу что если монтажники гоняют кабель туда-сюда, то тут проблема уж точно не в связке Freeradius+dhcp, а видимо в управлении монтажниками.

Абсолютно согласен. Неоспоримо. Но - не моя епархия ;(

Надежда только на одно: сейчас входим в некий новый пункт. Там будут свои монтажники. Надеемся выдрессировать их изначально, и op82 вводить именно там. А уже на их примере пере-дрессировывать старых.

 

Свитчи обходятся раз в полчаса-час скриптом. При изменении мака на порту (с условием, что он уже засвечен на другом порту) относительно несложно написать некий триггер, выводящий нам оповещение. Главное, чтобы это не было массово. На это тоже надежда ;)

Изменено 31 мая, 2010 пользователем Wingman

[wtyd]

А можно пример конфига dhcpd.conf, в котором мас свича (обычно там мак) указывается 1 раз ? Т.е. чтобы не писать в каждом условии, что "если мак такой-то и порт такой-то". Т.е. хотелось бы указывать идентификатор коммутатора доступа один раз в одном месте.

 

И ещё вопрос: в радиусе можно логировать всё, но вот в isc-dhcp не получается. Если есть ошибка в конфиге или просто забыл доконфигурить, то dhcpd напишет No free leases и всё, а на какой запрос (с какого порта какого свича) он это сделал, информации не будет и выцепить её скорее всего невозможно. Как вы решаете такую проблему ?

Изменено 1 июня, 2010 пользователем wtyd

[mikevlz]

Если постараться, то будет писать в логи в том числе и чей запрос заигнорен. В DHCPDISCOVER будут в логах(если настроите) opt82 данные и MAC, в NO FREE LEASES виден MAC, сопоставить можно.

[max1976]

Предыстория: достаточно долго метался в поисках способа удобного запуска на сети dhcp+option 82.

Потому как ISC-DHCP - это:

- километровые неудобочитаемые конфиги;

- постоянные передергивания при изменениях;

- НЕ-риалтайм управление DHCP-сервером;

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

- Сложность с выдачей нескольких IP на порт.

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

Я добился от isc dhcp сервера требуемого функционала, но основной упор у меня сделан на динамическом распределении адресов. Т.к. сервер работает с LDAP, то нет необходимости передергивать сервер, только если добавление/изменение пулов. Если будет интересно, могу поделиться некоторыми "секретами".

[rainbowirdi]

Предыстория: достаточно долго метался в поисках способа удобного запуска на сети dhcp+option 82.

Потому как ISC-DHCP - это:

- километровые неудобочитаемые конфиги;

- постоянные передергивания при изменениях;

- НЕ-риалтайм управление DHCP-сервером;

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

- Сложность с выдачей нескольких IP на порт.

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

Я добился от isc dhcp сервера требуемого функционала, но основной упор у меня сделан на динамическом распределении адресов. Т.к. сервер работает с LDAP, то нет необходимости передергивать сервер, только если добавление/изменение пулов. Если будет интересно, могу поделиться некоторыми "секретами".

Если не секрет можете показать как увязали isc dhcp с ldap ?

[wtyd]

Если постараться, то будет писать в логи в том числе и чей запрос заигнорен. В DHCPDISCOVER будут в логах(если настроите) opt82 данные и MAC, в NO FREE LEASES виден MAC, сопоставить можно.

Ну вот что-то не получилось до сих пор это сделать :-).

 

if exists agent.circuit-id

{

log ( info, concat(

"SMAC:",binary-to-ascii(16,8,":",suffix(option agent.remote-id,6)),

" VLAN:",binary-to-ascii (10, 16, "", substring( option agent.circuit-id, 2, 2)),

" PORT:",binary-to-ascii(10,8,".",suffix(option agent.circuit-id,1)),

" ip:",binary-to-ascii (10, 8, ".", leased-address)

));

}

 

В логи пишет такое (когда мак свича в конфиге был неправильно указан):

May 31 14:06:17 dhcpd: DHCPDISCOVER from 00:1f:c6:e9:0c:92 via eth0: network SHPOOL: no free leases

 

И вот такое (когда выдавался адрес):

 

May 31 14:08:02 dhcpd: SMAC:0:12:cf:a0:73:b2 VLAN:100 PORT:1 ip:192.168.70.18

May 31 14:08:02 dhcpd: DHCPDISCOVER from 00:1f:c6:e9:0c:92 via eth0

May 31 14:08:02 dhcpd: DHCPOFFER on 192.168.70.18 to 00:1f:c6:e9:0c:92 (ARCH1) via eth0

 

Хотелось бы видеть "SMAC:0:12:cf:a0:73:b2 VLAN:100 PORT:1" во всех строчках лога, где есть упоминание о МАС адресе клиента.

Изменено 1 июня, 2010 пользователем wtyd

[max1976]

Если не секрет можете показать как увязали isc dhcp с ldap ?

Я взял dhcp-4.1.0 и LDAP патч к нему http://wiki.github.com/dcantrell/ldap-for-dhcp/. У меня в сети есть одна особенность - я выдаю в аренду (на порт) ровно столько адресов, за сколько заплатил пользователь (1 адрес бесплатно). В связи с этим пришлось немного доработать ldap-patch, чтобы работали lease limit через ldap.

В самом конфиге isc dhcp все достаточно просто: создаются классы и пулы, а сабклассы уже берутся из ldap. Если есть пользователь на указаном коммутаторе в указаном порту, то он получит адрес из нужного пула, иначе получит адрес из пула, в котором есть доступ только к биллингу и сайту оператора.