Потому как 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-Остальное -> Игнорим?
Ещё остаётся вопрос: как разруливать пулы? Попробовать прикрутить sql_ippool (никогда не юзал, не знаю, как работает), или своими силами так же, как лизы? типа select ... from pool where last_leased_time < (time-$lease_time+10) ? Тогда нужно таблицу со всеми возможными ипами держать, некрасиво
Собственно, у самого голова уже кругом и глаз замылен, хочу попросить у общественности посмотреть на возможные недостатки данной схемы и поискать подводные камни, которые мне в голову пока не пришли.
Кто заинтересован в развитии чего-то такого - буду рад любой помощи, Кто уже внедрил что-то по теме сабжа у себя - буду рад саветам и направлениям в нужное русло
Самому мне по условиям задачи нужно или поднять, оттестить и внедрить у себя option82 + IPoE в течение пары месяцев, или забыть надолго. Буду стараться внедрить
.