Перейти к содержимому
Калькуляторы

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

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

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

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

 

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

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

 

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

 

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

 

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

Изменено пользователем Heggi

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

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

 

SE это умеет.

 

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если в разных, сказывается глюк 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 адрес.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Изменено пользователем macharius

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

 

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

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

Изменено пользователем rus-p

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

 

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

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

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

 

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

 

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

Изменено пользователем shefys

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас