DHCP opt.82 - WEB-авторизация

[mlevel 52]

Подскажите как реализуется схема DHCP opt.82 с WEB-авторизацией при смене MAC-адреса?

 

Насколько я понимаю:

1. На DHCP-сервере реальный IP-адрес выдается при match DHCP opt.82 + MAC-адреса.

2. В остальных случаях выдается IP-адрес из другой подсети и делается редирект на

страницу авторизации, где после ввода логина и пароля пользователем на

DHCP-сервере удаляется старая запись match.

3. Далее на BRAS'e ищем MAC-адрес который соответствует IP-адресу с формы WEB-авторизации.

4. В БД ищем какая DHCP opt.82 соответствует етому пользователю.

5. Вносим ету запись на DHCP-сервер, удаляя старую dhcp-lease.

6. Ждем пока пользователь получит новые настройки.

[vop 366]

Постоянная привязка порта к клиенту делается?

[mlevel 52]

Делаеться. Но бывают ЧП когда есть проблемы с изменением абонентского порта.

[vop 366]

Есть одна проблема в предложенной схеме - если я (клиент) подключу к сети кофеварку, то я с нее не смогу зайти на свою веб-страницу. Поэтому, было бы разумно сделать, что бы все mac/ip приходящие с закрепленного порта, появлялись в личном кабинете клиента, где он смог бы отметить мышкой, мол, мой агрегат. А так - все верно. Один раз подтвердил связку opt82+mac - она постоянно и работает. Адреса в DHCP менять не обязательно. Что выдалось при первом подключении, то в базу и записалось (добавилось в DHCP сервер, как постоянная лиза).

[Abram 98]

Я у себя делаю на маршрутизаторе редирект неавторизаванных адресов. При этом адрес клиенту выдается всегда один и тот же - никаких гостевых пулов.

[alex_o 1 194]

Подскажите как реализуется схема DHCP opt.82 с WEB-авторизацией при смене MAC-адреса?

 

Насколько я понимаю:

1. На DHCP-сервере реальный IP-адрес выдается при match DHCP opt.82 + MAC-адреса.

2. В остальных случаях выдается IP-адрес из другой подсети и делается редирект на

страницу авторизации, где после ввода логина и пароля пользователем на

DHCP-сервере удаляется старая запись match.

3. Далее на BRAS'e ищем MAC-адрес который соответствует IP-адресу с формы WEB-авторизации.

4. В БД ищем какая DHCP opt.82 соответствует етому пользователю.

5. Вносим ету запись на DHCP-сервер, удаляя старую dhcp-lease.

6. Ждем пока пользователь получит новые настройки.

К чему провайдеру МАС абонента? К чему ему вообще какая-либо авторизация?

Вы провели абоненту кабель в квартиру, воткнули этот какбель в свой ФИКСИРОВАННЫЙ порт на КОНКРЕТНОМ свиче. Абонент не имеет возможности сменить порт на свиче доступа (или у кого-то это не так?). Стало быть, однозначно идентифицировать абонента достаточно по связке свич+порт - что и делает опция 82.

Объясните мне, тупому, - на кой после этого к этому порту абонента привязывать МАС????!!!! Хочет абонент пихать кабель провайдера в каждую подходящую дырку в своей квартире - ну и пусть себе на здоровье пихает до полного удовлетворения. Дырка, в которую воткнули кабель провайдера должна ВСЕГДА получить свой IP по DHCP. Условие для этого должно быть только одно - наличие достаточного бабла на счете абонента в билинге. К чему создавать абоненту сложности в этом процессе? Это ведь только стимулирует его слинять к тому провайдеру, где нет сложностей с настройками/авторизациями и прочими задрочками.

Единственное, что оправдано в некоторых случаях - привязка к порту доступа фиксированного IP. Это иногда приятно абонентам (хотя и не всем), это, безусловно, очень удобно провайдеру (статистику проще вести). Но даже и эта бадяга никчему, если у провайдера дефицит белых IP.

[stan77 14]

1

[Gang 5]

Подскажите как реализуется схема DHCP opt.82 с WEB-авторизацией при смене MAC-адреса?

 

Насколько я понимаю:

1. На DHCP-сервере реальный IP-адрес выдается при match DHCP opt.82 + MAC-адреса.

2. В остальных случаях выдается IP-адрес из другой подсети и делается редирект на

страницу авторизации, где после ввода логина и пароля пользователем на

DHCP-сервере удаляется старая запись match.

3. Далее на BRAS'e ищем MAC-адрес который соответствует IP-адресу с формы WEB-авторизации.

4. В БД ищем какая DHCP opt.82 соответствует етому пользователю.

5. Вносим ету запись на DHCP-сервер, удаляя старую dhcp-lease.

6. Ждем пока пользователь получит новые настройки.

К чему провайдеру МАС абонента? К чему ему вообще какая-либо авторизация?

Вы провели абоненту кабель в квартиру, воткнули этот какбель в свой ФИКСИРОВАННЫЙ порт на КОНКРЕТНОМ свиче. Абонент не имеет возможности сменить порт на свиче доступа (или у кого-то это не так?). Стало быть, однозначно идентифицировать абонента достаточно по связке свич+порт - что и делает опция 82.

Объясните мне, тупому, - на кой после этого к этому порту абонента привязывать МАС????!!!! Хочет абонент пихать кабель провайдера в каждую подходящую дырку в своей квартире - ну и пусть себе на здоровье пихает до полного удовлетворения. Дырка, в которую воткнули кабель провайдера должна ВСЕГДА получить свой IP по DHCP. Условие для этого должно быть только одно - наличие достаточного бабла на счете абонента в билинге. К чему создавать абоненту сложности в этом процессе? Это ведь только стимулирует его слинять к тому провайдеру, где нет сложностей с настройками/авторизациями и прочими задрочками.

Единственное, что оправдано в некоторых случаях - привязка к порту доступа фиксированного IP. Это иногда приятно абонентам (хотя и не всем), это, безусловно, очень удобно провайдеру (статистику проще вести). Но даже и эта бадяга никчему, если у провайдера дефицит белых IP.

 

Все так, полностью поддерживаю. Будь то option82 или cvlan.

 

Но маки собирать все равно нужно, просто собирать и хранить. Для случаев : вырезали всю витуху, все абоненты перепутались. Вот к этому система должна быть готова. Что если известный мак выпрыгнул с другого порта на том-же коммутаторе - не хорошо и надо поправить.

[anti-stels 21]

+1 усложняете жизнь себе и людям.

[morfey 82]

Или монтажник при ремонте попутал кабеля/порты И если на балансе обоих юзеров есть бабло, то в будущем будет неразбериха, т.к. оба получили ip, но не свои. Сам думаю как лучше реализовать. Т.к. кофеварку тоже могут подключить... Конечно все зависит от культуры монтажа, но все-таки хочется перестраховатся.

[stan77 14]

Но маки собирать все равно нужно, просто собирать и хранить.

 

Так для этого и существует аккаунтинг в радиусе. По сессиям в базе сразу вижу кто когда чего менял.

[Gang 5]

Но маки собирать все равно нужно, просто собирать и хранить.

 

Так для этого и существует аккаунтинг в радиусе. По сессиям в базе сразу вижу кто когда чего менял.

 

Я об этом и говорил. Только более автоматизировать.

[mlevel 52]

Ну наверное у всех идеальные монтажники, но например у меня не всегда получаеться точно идентифицировать абонента по порту коммутатора, по причинах:

1. Накосячили монтажники. И вообще после 7 лет работы без нужды точно знать порт куда включили абонента - сейчас ето трудно сделать.

2. Вырезали весь абонентский кабель.

3. Гроза. Сгорел свитч, поменяли оборудование. Особенно ночью.

[anti-stels 21]

Ну наверное у всех идеальные монтажники, но например у меня не всегда получаеться точно идентифицировать абонента по порту коммутатора, по причинах:

1. Накосячили монтажники. И вообще после 7 лет работы без нужды точно знать порт куда включили абонента - сейчас ето трудно сделать.

2. Вырезали весь абонентский кабель.

3. Гроза. Сгорел свитч, поменяли оборудование. Особенно ночью.

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

3. Гроза. Сгорел свитч, поменяли оборудование. Особенно ночью.

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

1. Накосячили монтажники.

Накосячили монтажники? Так пусть идут и справляют косяки, а не пользователь захотевший посидеть в одноклассниках смотрит удивлённо на неведомую ему страничку авторизации.

[buryanov 5]

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

[stan77 14]

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