Jump to content
Калькуляторы

IPoE + Web-авторизация Как?

Есть мысль перевести всю сеть на IPoE.

Привязку пользователей делать через DHCP запросы (MAC+opt82).

В качестве браса - пока Linux, позже SE100.

 

И все бы ничего, но хочется абонентов избавить от звонков в ТП при смене сетевой карты/компа.

Мысль такая: для неавторизованных пользователей редиректить все запросы на портал, где предлагается ввести логин и пароль (сейчас у всех наших абонентов они есть) и в биллинге создается привязка opt82+mac на нужный договор.

 

Проблема: SE100 (да и dhcp-сервер под linux) не выдают IP-адрес, если Radius биллинга ответит ACCESS_REJECT (т.е. связка opt82+mac в списке логинов не найдена), следовательно абонент на портал попасть не сможет.

 

Какие мысли у сообщества будут по этому поводу?)

 

P.S. Нечто подобное реализовано у МФТИ-Телеком. Хотелось бы узнать как)

Edited by Heggi

Share this post


Link to post
Share on other sites

Есть мысль перевести всю сеть на IPoE.

Привязку пользователей делать через DHCP запросы (MAC+opt82).

В качестве браса - пока Linux, позже SE100.

 

И все бы ничего, но хочется абонентов избавить от звонков в ТП при смене сетевой карты/компа.

Мысль такая: для неавторизованных пользователей редиректить все запросы на портал, где предлагается ввести логин и пароль (сейчас у всех наших абонентов они есть) и в биллинге создается привязка opt82+mac на нужный договор.

 

Проблема: SE100 (да и dhcp-сервер под linux) не выдают IP-адрес, если Radius биллинга ответит ACCESS_REJECT (т.е. связка opt82+mac в списке логинов не найдена), следовательно абонент на портал попасть не сможет.

 

Какие мысли у сообщества будут по этому поводу?)

 

P.S. Нечто подобное реализовано у МФТИ-Телеком. Хотелось бы узнать как)

Выдавать не известным ip из другого vlan, и фаерволом разрешить ходить этим адресам только на "портал". В dhcp поставить "время аренды" поменьше, что б после ввода правильной связки не перезагружать абонский комп.

Share this post


Link to post
Share on other sites

Выдавать не известным ip из другого vlan, и фаерволом разрешить ходить этим адресам только на "портал".

 

В этом случае вы предлагает менять vlan на порту абонента?

 

Вообще, надо отдавать ACCEPT и запускать внешний скрипт, который будет настраивать правило фаервола для редиректа tcp/80 на портал и блокировать остальной трафик. На linux это реализуемо.

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

 

Привязка mac+option82 вам зачем? Чтобы монтёры не путали порты?

Share this post


Link to post
Share on other sites

 

Проблема: SE100 (да и dhcp-сервер под linux) не выдают IP-адрес, если Radius биллинга ответит ACCESS_REJECT (т.е. связка opt82+mac в списке логинов не найдена), следовательно абонент на портал попасть не сможет.

 

 

считать абонента по умолчанию авторизованным, вешать HTTP redirect через CoA при отрицательном балансе.

Share this post


Link to post
Share on other sites

 

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

 

Привязка mac+option82 вам зачем? Чтобы монтёры не путали порты?

 

SE это умеет.

 

MAС+opt82 - против кривых монтажников, против любителей подключаться к чужим кабелям.

 

Зайти в гости к админам МФТИ-Телеком с пивом не проще?

 

Увы, ехать далеко...

Не все же в пределах МКАДа живут

Share this post


Link to post
Share on other sites

всё верно , SE100 всё это умеет, как отметил ingress, всегда отправляете абоненту accept, только с разными политиками и всякими там редиректами на портал и так далее. всё это возможно и ничего там невыполнимого нет.

Share this post


Link to post
Share on other sites

Значит главная проблема - допилить биллинг до нормального состояния)

Share this post


Link to post
Share on other sites

советую не связываться с mac, и оставить аутентификацию только на базе opt82. абоненты будут ставить себе рутеры и качать прошивки с интернета - результат duplicate маки. 82-ой опции имхо вполне достаточно.

Share this post


Link to post
Share on other sites

Чем помешает дублирование маков, если opt82 у них будет разный?

К тому же тот же SE100 в радиус-запросе в качестве User-Name посылает MAC абонента.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

"duplicate маки" вообще гадкая вещь. Поэтому в случае их появления идет звонок клиенту.

 

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

Если в разных, сказывается глюк ISC DHCP. Если мак A получил в влане адрес B, то при выдаче адреса маку A в другом вилане ICS считает что адрес B уже свободен.

И дает его периодически другим клиентам, в результате у обоих раз в 10-15 минут меняется ип и рвутся сессии.

Share this post


Link to post
Share on other sites

"советую не связываться с mac, и оставить аутентификацию только на базе opt82"

 

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

Брас открывает сессию только с одного IP, опция 82 одинаковая. Биллинг постоянно открывает доступ то виртуалке, то хост-машине.

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

 

Кейс №2 - купив новый компьютер/роутер при втыкании в сеть у пользователя возникает пачка вопросов. А в портале в FAQ сразу все ответы. -1 звонок в ТП.

Share this post


Link to post
Share on other sites

Если в разных, сказывается глюк ISC DHCP. Если мак A получил в влане адрес B, то при выдаче адреса маку A в другом вилане ICS считает что адрес B уже свободен.

И дает его периодически другим клиентам, в результате у обоих раз в 10-15 минут меняется ип и рвутся сессии.

не понимаю в чем проблема, разные вланы - разные подсети, в случае с se100, такие запросы, с одинаковых маков, но с разных вланов отличаются для dhcp сервера и для se100 полем giaddr. SE100 работает как dhcp-proxy, а не как realy. Так что адреса будут выданы разные - и ничего рваться не будет.

 

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

Брас открывает сессию только с одного IP, опция 82 одинаковая. Биллинг постоянно открывает доступ то виртуалке, то хост-машине.

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

предполагается схема когда у клиента должен быть один IP адрес на порту доступа. Клиент должен использовать рутер в таких случаях. Для того чтобы подобные деятели не забивали муором билинг на брасе включатся throttling на входяще dhcp запросы, который работает per-mac.

 

Кейс №2 - купив новый компьютер/роутер при втыкании в сеть у пользователя возникает пачка вопросов. А в портале в FAQ сразу все ответы. -1 звонок в ТП.

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

Share this post


Link to post
Share on other sites

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

 

 

SE100 не умеет инициализировать сессию по unknown source ip, только по DHCP.

Отсюда и пляшу :(

Share this post


Link to post
Share on other sites

"SE100 не умеет инициализировать сессию по unknown source ip, только по DHCP."

 

Надо их гонять, чтоб делали)

А что реально это даст? возможность переключать, в случае disaster, ручками на резервный брас, район, который отвалился с основного браса? А толку? на новом брасе все абоненты получат статус - not-authorized и будут выброшены на web-авторизацию, для того чтобы пройти аутентификацию снова. Весело. При этом, если район достаточно большой - то еще и личный кабинет положат минут на 30 ...

Сделайте lease равным 10 мин - переключение будет происходить в разы быстрее.

Edited by macharius

Share this post


Link to post
Share on other sites

"SE100 не умеет инициализировать сессию по unknown source ip, только по DHCP."

 

Надо их гонять, чтоб делали)

А что реально это даст? возможность переключать, в случае disaster, ручками на резервный брас, район, который отвалился с основного браса? А толку? на новом брасе все абоненты получат статус - not-authorized и будут выброшены на web-авторизацию, для того чтобы пройти аутентификацию снова. Весело. При этом, если район достаточно большой - то еще и личный кабинет положат минут на 30 ...

Сделайте lease равным 10 мин - переключение будет происходить в разы быстрее.

 

Купите алкатель, у него нет как проблемы с инициацией так и с мгновенным перещелкиванием на другой брас )

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

Edited by rus-p

Share this post


Link to post
Share on other sites

делать синхронизацию тяжело

 

в ALU все сессии абонентов синхронизированы между основным и бэкап брасом? какой механизм?

флов таблицы,трансляции нат тоже синхронизированы?

Share this post


Link to post
Share on other sites

"SE100 не умеет инициализировать сессию по unknown source ip, только по DHCP."

 

Надо их гонять, чтоб делали)

А что реально это даст? возможность переключать, в случае disaster, ручками на резервный брас, район, который отвалился с основного браса? А толку? на новом брасе все абоненты получат статус - not-authorized и будут выброшены на web-авторизацию, для того чтобы пройти аутентификацию снова. Весело. При этом, если район достаточно большой - то еще и личный кабинет положат минут на 30 ...

Сделайте lease равным 10 мин - переключение будет происходить в разы быстрее.

 

Купите алкатель, у него нет как проблемы с инициацией так и с мгновенным перещелкиванием на другой брас )

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

толсто троллите :))

 

В схеме, предлагаемой ALU (active/slave), тоже есть свои недостатки (как и везде) - отсутствие честной балансировки, возможность получить master на обе головы, асинхронный трафик (в худшем случае блекхол) и много чего ещё (в качестве dhcp giaddr используется router-id, а не адрес интерфейса, в radius сообщения от какого адреса отправляются? надо ли будет как-то менять логику в bss/oss системах для поддержки такой схемы?).

 

В схеме без синхронизации стейтов тоже есть свои недостатки, но обслуживать такую схему намного проще.

Edited by shefys

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this