[lllsergeyv]

Связка мак-ип, плюс информация из опции82.

IP-MAC-Port Binding? Выдаете юзеру по dhcp один и тот же адрес?

[Ivan_83]

IP-MAC-Port Binding?

Не везде управляемые порты на абонента, и свичи разные. Потому именно на порт не биндим. Те в самих коммутаторах нет привязок.

 

Выдаете юзеру по dhcp один и тот же адрес?

Пока да.

[lllsergeyv]

Выдаете юзеру по dhcp один и тот же адрес?

Пока да.

Я хочу раздавать разные, но еще не придумал как на коммутаторах заблочить самовольщиков(сейчас локалку вобще не предоставляем, схема - влан на дом, а между собой юзера разделены с помощью traffic_segmentation). Возможно проще сделать влан на юзера и использовать аннамберед (если на влане не прописан роут на адрес, который поставил сам себе юзер, то он нифига и не получит), но запилить демон дхцп, который будет навешивать роут при выдаче адреса, для меня очень сложная задача, в программировании не очень силен :(.

 

Вы сразу берете пул адресов который больше количества клиентов?

[Ivan_83]

В коммутаторах, некоторых, есть фича - пропускать с порта только пакеты с адреса выданного на этот порт по дхцп.

Вы сразу берете пул адресов который больше количества клиентов?

Да, у нас адресов больше, чем клиентов.

[~AsmodeuS~]

http://abills.net.ua/wiki/doku.php/abills:docs:modules:dhcphosts:ru#freeradius_dhcp

[Ivan_83]

DHCP во фрирадиусе не удобен.

Если нужно с базы то либо моим перловым сервером либо сишным, тоже на этом форуме есть.

[~AsmodeuS~]

DHCP во фрирадиусе не удобен.

Если нужно с базы то либо моим перловым сервером либо сишным, тоже на этом форуме есть.

чем не удобен ?

[Ivan_83]

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

[~AsmodeuS~]

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

 

Интересно Вам нужно решение под ключ или просто хочется с чемто поигратся

 

В нашем решении взят Freeradius за основу и доработан до полного соответвия запросам автора топика

 

 

интересно что в нем не гибко? скажите что нельзя в нём реализировать ?

[Ivan_83]

У нас уже была рабочая сетка и менять её под чьё то решение мы не собирались.

 

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

 

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

 

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

 

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

 

 

[~AsmodeuS~]

У нас уже была рабочая сетка и менять её под чьё то решение мы не собирались.

 

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

 

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

 

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

 

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

 

 

кстати наше решение какраз заключается в том что мын написал perl обвязку для радиуса,

пробовлаи теже решения на perl (работало медленей нашейо бвязки и требовало доработки), решение на C требовало еще большей доработки чтобы можно было учесть все нужды и поднять производительность

 

так что думаю не стоит расказывать что Freeradius dhcp плохое решение не приводя аргументов

[Ivan_83]

То что после появления дхцп во фри радиус двое человек независимо друг от друга сели и написали свои дхцп сервера на перле и сях - не спроста.

 

Я пробовал фрирадиус с дхцп и мне не понравилось как он работает.

 

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

 

Скорость работы почти всегда упирается во взаимодействие с базой.

 

 

[~AsmodeuS~]

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

 

 

1 многопоточность

2 исправленно множество косяков 4которые были в перл радиусе

3 интерфес высшего уровня для доабвления дополнительных параметров

 

я не говрю что Freeradius DHCP идеал и т д

но в нашем решении он работает стабыльно и в сетях на 10 000 абонентов он показывает очень хорошие результаты и разрешает очень гибко маштабировать сети

так что если выне знакомы с нашим решением не надо говорить что оно плохое потому что там freeradius dhcp

Мы не предлагаем конструктор купив который Вы еще пол года его допиливать будете, мы предлагаем законченное решение с максимальным действием для клиента это внесения тех или других правил конфигурации

 

перед выбором именно freeradius было проверенно perl ришение С и мы остановились именно на Radius так как в нём найменьше пришлось дорабатывать для наших задач

[Ivan_83]

1 многопоточность

 

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

 

так что если выне знакомы с нашим решением не надо говорить что оно плохое потому что там freeradius dhcp Мы не предлагаем конструктор купив который Вы еще пол года его допиливать будете, мы предлагаем законченное решение с максимальным действием для клиента это внесения тех или других правил конфигурации

 

У нас разное позиционирование близких решений.

 

 

[sirmax]

К ABILLS легко можно дописать свою обвязку что бы строить на ее основе конфиг сервера (да, знаю что криво генерить конфиг из базы - зато работает если легла база)

 

Я дописывал несколько скриптов, реализовав такую схему

1. Юзеру дают логин+пароль при заключении договора

2. При подключении ему дается фейк+редирект на самописную страничку с авторизацией

3. Если ввел правильный логин+парль + то проверяется что юзеру можно с этого порта этого свитча и что он еще не "авторизован" и баланс положительный.

(все детали юзера беруться из БД куда пишет сислог - а сислогу отдает логи дхцп. Самовольная установка ИПов исключена потому точно знаем что если человек пришел на страничку с определнного ипа тонайти его мак, порт и свитч - просто)

4. В случае успешной авторизации - заполняем базу абиллза ( dhcphosts_hosts если не изменяет память)

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

 

К плюсам отношу - все просто как для юзера так и для саппорта, ну и стабильно работает. Делал довольно давно, может у абиллза уже штатно есть такое.

[~AsmodeuS~]

К ABILLS легко можно дописать свою обвязку что бы строить на ее основе конфиг сервера (да, знаю что криво генерить конфиг из базы - зато работает если легла база)

 

Я дописывал несколько скриптов, реализовав такую схему

1. Юзеру дают логин+пароль при заключении договора

2. При подключении ему дается фейк+редирект на самописную страничку с авторизацией

3. Если ввел правильный логин+парль + то проверяется что юзеру можно с этого порта этого свитча и что он еще не "авторизован" и баланс положительный.

(все детали юзера беруться из БД куда пишет сислог - а сислогу отдает логи дхцп. Самовольная установка ИПов исключена потому точно знаем что если человек пришел на страничку с определнного ипа тонайти его мак, порт и свитч - просто)

4. В случае успешной авторизации - заполняем базу абиллза ( dhcphosts_hosts если не изменяет память)

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

 

К плюсам отношу - все просто как для юзера так и для саппорта, ну и стабильно работает. Делал довольно давно, может у абиллза уже штатно есть такое.

 

 

да есть AUTO_DISCOVERY c 2008 года