BiTel

Долго присматриваемся к вашему биллингу(хотим перебежать с другого)... все нравится но хотелка у нас такая...
Задача - авторизовать абонентов по DHCP opt.82 на доступе Dlink авторизация по номеру свича-порт- реализовано, согласен... но можно ли выдавать ип адрес динамически из пула адресов? просто дана АС реальных ип адресов, разделено на подсетки одна для народа с фиксированными ипами другая с динамически выдаваемыми реальными ип адресами... выдавать статически привязанные адреса не хочется... использовать PPP решения и радиус не хотим из принципа... доработаете - купим-перейдем на ваш биллинг без всяких вопросов …
PS пока не в каких биллингах это не реализовано..

а как привязывать выданный адрес к договору чтобы трафик считать?

Специально подождал пока ответят Админы но в ответ тишина...
вернемся к теме, точно также как и в модуле DialUp и VPN, либо его доработать чтобы он мог выполнять вункции вышеперечисленные функции...

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

А как вы это хотите считать? В Dialup есть понятие сессии - там идет привязка к сессии ..сессия начитается после авторизации ..в IPN - нет понятия сессии . Т.е как понять что этот ip-шник из лога принадлежит конкретному договору и какому ? .. вы сами можете придумать механизм как вы это видете ?

лично я не знаю как это видит топикстартер, но чисто теоретически можно считать так:

• клиент (в данном контексте - DHCP клиент) получает IP адрес от DHCP сервера - это своеобразный аналог Start пакета в РРР ... получив адрес клиент получает и Lease Time, т.е. время, которое, с натяжкой, можно считать таймаутом сессии в РРР ... аналогом логина тут служит либо hardware-address, т.е. МАС, либо информация полученная из Option 82 - иначе, IMHO, невозможно будет произвести точную идентификацию "юзер == адрес" ...
• по истечении Lease Time, либо раньше клиент обновляет IP адрес - это своеобразный аналог Update пакета в РРР ... т.е. подтверждается что адрес принадлежит такому-то конкретному клиенту ...
• клиент освобождает IP адрес - это аналог Stop пакета в РРР ... но, увы, не каждый DHCP клиент шлет пакет на освобождение адреса дабы точно знать где чей IP можно основываться на анализе Lease Time которое получая/обновляя IP адрес клиент всегда получает, т.е. время занятия IP адреса всегда известно и сервер не отдаст этот адрес никому другому ранее истечения Lease Time либо получения пакета (на который тоже можно смотреть, но он, повторюсь, не всегда приходит) освобождения IP адреса ...

т.е. получается что зная МАС либо данные из Option 82 можно сопоставить IP адрес полученный из пула с конкретным юзером, но это голая теория ...

P.S. ув. stark, ответьте, пожалуйста на ЛС ... очень нужно Ваше мнение!

snark Совершенно Верно и мы точно также как вы описали написали в ТЗ!!! в качестве "логина" параметры opt82 тоесть точный адресс юзверя(мак адресс свича номер влана, номер порта)...

Т.е идинтификатором клиента является - mac адрес свича + vlan + порт . Клиент запрашивает адрес - мы ему даем любой из пула. как заканичвается leasetime освобождаем адрес. Только вот клиенты разные попадаются , некторые могут слать запросы чаще чем leaseTime, а некоторые могут спокойно продолжать работать после того, как у них отобрали ip.
Ну допустим клиент у нас работает все-таки по стандарту (хотя это не факт) . Допустим мы как-то это реализуем . cледующий вопрос - как считать ? т.е будет отдельная таблица , в которой будет прописано, что с 12:03:02 по 14:05:01 ип 192.168.144.23 был на догворе с id=15, а с 17:09:05 по 18:55:11 ип 192.168.144.23 был на договоре c id=20.. Т.е ип будет привязан не просто к договору, а к периоду и договору .

Прошел год, что-нибудь поменялось? Мне тоже не помешала такая удобность.

DHCP всем была бы удобна и в разных видах. Я вот поднял его под FreeBSD 7.1 Все хорошо. Толкьо вот статическую выдачу адреса согласно мака приходится крутить ручками, в dhcpd.conf, а можно было бы и в биллинг несложный скриптец прикрутить? (киньте в меня камень если не прав)

читаем это и это, думаем что подходит и реализуем то что подошло


БГБ-шный dhcp вроде и сам умеет выдавать адрес на МАС, но ничто не мешает написать скрипт, например на шелле, который на основе данных из БГБ будет генерить dhcpd.conf

dhcp snooping + arp security не дадут работать тому, кто не продлит аренду DHCP адреса.

arp security - нам самим нужно организовывать или вы будите использовать какие-то другие средства ?

Подниму вопрос... прошло больше года, ТЗ вроде описано... разжевано, а воз и поныне там? просто уже нетап допек от меня требуют счет, вот и думаю что закладывать в счет ISG-dialup - оно неготово, судя по переписке в форуме еще долго не будет, если все оставить на прежнем уровне по какой схеме мы хотели то ipn- но он нехочет выдавать адреса из пула только статику... заказ и того и другого, при количестве 3000 юзверей это переплатить лишние 80тысч

dhcp snooping - на коммутаторе
arp security - раскройте что вы под этим понимаете? привязка мак компа к порту? если так то зачем? ну и пускай мак он поменяет, ип адрес выдается на основе мак адреса свича+влана+порта свича.

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

И вообще я не очень уверен что это будет работать . Алоритм, придуманный snark-ом не проверен . Я как-то помню тестил стандартные dhcp - клиенты линукса , им было плевать на leaseTime - они иногда продолжали работать по истечению этого времени и не посылали запроса на продление . Если закрыть досуп на этом порту после истчения leaseTime - то это тоже не факт что приведет к этому запросу ..

Или как вариант, возможно, нужно завязываться на конкретной оборудование . Какие возможности предеоствляют switch-и ? например моуг они сами слать dhcp запрос по окончанию времени аренды ip и закрывать порт если ip не обновился ?

ладно а DHCP opt 82+ модуль dialup такое реально?

а как ? Модуль dialup у нас пока работает с оборудованием только в рамках Radius - протокола.

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


вполне реально

http://www.netpatch.ru/dhcp2radius.html
тоже реальность...
сейчас как раз пробуем, положительные результаты есть...