[asdf27]

UPD: в теме указал DNS, имел ввиду шлюз :)

_________________________

 

Суть проблемы:

В свете нового закона о wi-fi, теперь нужна авторизация в виде указания мобильного телефона. Ранее я уже поднимал тему, в ней дали нужные ответы.

 

Нынешний вопрос следующий:

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

 

Механика:

1. Поднимаю сервер с соответствующим биллингом.

2. Поднимаю LAMP, делаю авторизацию вида POST[телефон] -> SEND[sms_с_кодом].

3. Ввели правильно, MAC сохранился. Установил время жизни.

---

4. На роутерах в качестве шлюза указываю ip своего сервера.

5. Запросы авторизации пишу в базу, историю сёрфинга в логи.

6. Прикручиваю веб-морду, даю доступ к истории авторизации.

7. Даю возможность явно указывать маки и срок жизни.

 

Смущает четвертый пункт.

Edited September 20, 2014 by asdf27

[GrandPr1de]

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

Может не сервер, роутер к примеру.

[asdf27]

Т.е. алгоритм верный?

[GrandPr1de]

Да. Только роутерам нужен шлюз вашего сервера в том случае - если он ещё и раздачей интернета займется, а не просто биллингом.

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

Подымаете сервер с биллингом, на него вешаете роутеры.

На роутерах подымается связка авторизации, допустим по радиусу или ещё по чём.

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

Срок услуги заканчивается - биллинг даёт команду отключить.

Edited September 20, 2014 by GrandPr1de

[asdf27]

Нет, это просто прокладка. Говоря прямо, я думаю на этом зарабатывать. Роутеры раскиданы по объектам и связь между ними может быть только по инету. Роутеры: кинетики, длинки, асусы и прочие бюджетные.

 

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

 

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

 

Правильно ли я понимаю, что при каждом пакете будет сверяться, авторизован ли клиент? Ширина канала 50 мбит, сколько в теории запросов в секунду удержит? Жесткий HDD, core i5.

[GrandPr1de]

Если у вас база не будет в пару гигабайт, то нагрузка на хдд большой не будет. Ну если конечно не будет адских выборок из базы, типо достать всё, а потом сортируем. Естественно с ростом базы данных нагрузка будет расти не линейно.

Если всё будет оптимизировано - то этого сервера вам хватит на очень долго.

Единственное что, конечно резервируйте данные, типо рейд 1 т.е. зекралить данные на другой винчестер.

Сколько запросов удержит - это уж как вы настроете сервер.

50 мегабит для раздачи команд роутерам должно хватить с головой, ещё и на себя останется.

Edited September 21, 2014 by GrandPr1de

[asdf27]

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

Т.е. если каждый коннект проверять запросом вида SELECT * FROM mac_table WHERE mac='мак_клиента' - это плохо?

 

Если время жизни доступа, скажем, 5 дней, и за это время будет собираться 30к записей, не критично делать SELECT по всем записям? Каждые 5 дней по крону перемещать в архивную таблицу. За рейды спасибо, сразу запланировал.

 

И может кто знает, объясните примитивным языком: если два канала инета, как работает балансировщик, как он определяет на какой канал прицепить клиента? Тут речь о гостинице, один канал не справляется. Буду вешать второй модем, хотелось бы чтобы сервер определял загрузка каждого канала и правильно раскидывал коннекты.

Edited September 23, 2014 by asdf27

[GrandPr1de]

То есть ваш сервер ещё и натом будет заниматся?

Ибо балансировка есть статичная по срц айпи,а есть динамичная.

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

Т.е. клиент при первом запросе в инет, выходит через какой-то 1 канал, и ходит через него и дальше.

30к записей конечно недурно, но выборка типа where облегчает ситуацию.

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

Лично мне в повседневной жизни хватает и простого where, из 1к строк выбирает за 0.1 секунды.

Edited September 23, 2014 by GrandPr1de

[asdf27]

Т.е. клиент при первом запросе в инет, выходит через какой-то 1 канал, и ходит через него и дальше.

Верно, так и есть. Балансировать инет будет другой сервер, он же будет и резать скорость.

 

Это я отвлекся. В продолжении темы. В конечном итоге я добиваюсь следующего:

 

1. Будет сервер, указанный шлюзом у сотни роутеров (простых, не микротиков), связь с ними через инет.

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

3. Сверяет мак клиента. Есть в списке - пустил в инет. Нет в списке или истекла сессия - запросил телефон и код подтверждения.

4. Все действия клиентов (каждый запрос, где сёрфили) пишется в лог на отдельный файловый сервер.

 

Делается это для того, чтобы в свете нового закона каждой мелкой кафешке или гостевому дому сэкономить на установке нового железа. Тот же микротик, цена + настройка + настройка на месте будет в 30 раз дороже месячного тарифа. + логирование на ftp тоже 200р в месяц (простой хостинг).

Edited September 23, 2014 by asdf27

[GrandPr1de]

Хм, ну я бы делал по другому.

Просто машина которая рулит роутерами и всё, шлюз не нужен, а инет будет от прова к котором подключен роутер.

Edited September 23, 2014 by GrandPr1de

[asdf27]

Значит мне надо подучить мат.часть, именно так мне и нужно. Сформулировал с ошибками. На роутере ip сервера я указываю в качестве dns?

[GrandPr1de]

Снова мимо. Хотя если вы собираетесь днс фильтровать, то да.

Опять вам говорю, вам достаточно что-то типо mikrotik hotspot + авторизация по радиусу (например FreeRadius).

Как конкретно эта связка работает обещать конечно не могу, ибо не проверял.

Можете поискать роутеры с возможности авторизации по радиусу.

Edited September 23, 2014 by GrandPr1de

[asdf27]

вам достаточно что-то типо mikrotik hotspot

А логи писать? FTP?

 

Радиус только поставил, разбираюсь...

[GrandPr1de]

вам достаточно что-то типо mikrotik hotspot

А логи писать? FTP?

 

Радиус только поставил, разбираюсь...

Логи писать сислогом.

Я бы на вашем месте подружился бы ещё с OpenWRT и все роутеры садить на это дело и дружить с радиусом.

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

Сделаете допустим, что каждый роутер будет писать свой лог в отдельный файл на сервере у вас.

[asdf27]

Спасибо, очень много времени мне экономите.

А как быть с МАКами клиентов? Роутер передаст при подключении через инет радиусу мак клиента? И с обработкой php, радиус передает какие-то переменные, чтобы их можно было обработать php и записать в таблицу? Или идентификатор клиента, свой, "радиусовский"?

[ayf]

вам достаточно что-то типо mikrotik hotspot

А логи писать? FTP?

 

Радиус только поставил, разбираюсь...

Логи писать сислогом.

Я бы на вашем месте подружился бы ещё с OpenWRT и все роутеры садить на это дело и дружить с радиусом.

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

Сделаете допустим, что каждый роутер будет писать свой лог в отдельный файл на сервере у вас.

 

Мелкие рутеры - это одной. А если стоят айсары? Их дергать все время тоже не есть гуд.

[GrandPr1de]

Спасибо, очень много времени мне экономите.

А как быть с МАКами клиентов? Роутер передаст при подключении через инет радиусу мак клиента? И с обработкой php, радиус передает какие-то переменные, чтобы их можно было обработать php и записать в таблицу? Или идентификатор клиента, свой, "радиусовский"?

Мак клиента передается через радус атрибут, называется Calling-Station-Id, в редких случаях там передается айпи клиента.

Примерчик такой.

Получаете биллингом мак клиента, кладете его в базу "ожидание авторизации" - клиент авторизуется, биллинг выбрасывает из той таблицы и кладет его в другую "авторизованные клиенты", после того как абон авторизовался и ещё раз просится выйти в инет от биллинга уже прилетает положительный ответ - в следствии абон получает инет.

Собсно связь выходит такая: ответ радиуса - reject: значит на авторизацию.

Ответ радиуса: accept - значит выпускаем в инет.

Такой себе, маленький ISG :)

Я конечно не знаю, как там дела обстоят с LISG и много ли он ресурсов требует, но работает он примерно так.

Так что если вы его упилите в ваши маленькие роутеры то получите имнно то о чём я говорю.

 

Как именно вы это реализовывать будете дело конечно ваше. Лично для меня это просто абстрактные соображения на тему "как бы делал я".

Edited September 23, 2014 by GrandPr1de

[asdf27]

Очень ценные советы.

На данный момент борюсь со связкой radius + chilli. Прописываю шлюзом сервер, но в ответ тишина... страницу авторизации не показывает. Только при пинге с клиента определяет ip хоста (ya.ru).

 

Радиус прикрутил, юзера прописал. Тестом из терминала reject'ит и accept'ит, а вот chilli никак себя не проявляет. Хотя нет, проявляет. Когда сервис запущен, на серваке инет падает :) Не прописывал его в радиусе. А вот в логи заглянуть не успел, рабочий день и даже чуть больше кончился.

 

----

Говоря о роутере, вы имеете ввиду шить wrt? Дело в том, что клиентские роутеры могут быть достаточно удаленными, на место выезжать далеко. Потому работаю над тем, чтобы всю связку поднять в одном сервере, а клиенту достаточно лишь прописать шлюз в роутере.

Edited September 23, 2014 by asdf27

[GrandPr1de]

Говоря о роутере, вы имеете ввиду шить wrt? Дело в том, что клиентские роутеры могут быть достаточно удаленными, на место выезжать далеко. Потому работаю над тем, чтобы всю связку поднять в одном сервере, а клиенту достаточно лишь прописать шлюз в роутере.

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

Если услуга предоставляется поверх других операторов, то ваш сервер в принципе не может быть шлюзом!

Вам нужно просто разделять клиентов которые подключены к роутеру на тех кому дать инет или не давать.

[asdf27]

Я понял... Значит единственный вариант, это в каждый роутер загонять chillispot и ссылать их на свой радиус... А время жизни сессии указывается в chilli, верно?

[GrandPr1de]

http://freehabr.ru/blog/networks/2831.html

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

Прочитайте и задавайте вопросы по новому :)

[asdf27]

Прочел статью, ссылки в её начале и комментарии к ней... из уважения к вам, что не перестаете отвечать на мои вопросы. Но это не то...

 

Нашли хорошую книгу как раз по связке Debian + freeradius + chilli на роутере, сейчас читаю.

 

Статья "не та", приведу сравнение:

 

Если объект ставит связку локально, ему нужно:

- купить компьютер (20к с монитором и прочим),

- поставить ось и биллинг (3-4к),

- прошить и настроить на сервер роутер (3к). Если роутер слабый, то купить новый (2-5к),

- прописать персонал на роутере (?)

- купить статичный ip (?)

- возможно, рейды сделать (2к)

Итого 26к + возможно 2-5к + возможно 2к + ? + ?. Ну и временные затраты на поиск того, кто всё это сделает.

 

Если наши услуги, то:

- прошить и настроить на сервер роутер (3к). Если роутер слабый, то купить новый (2-5к),

- оплатить год доступа (4,8к)

- депозит на оплату смс (2к)

- прописать персонал (?)

Итого 9,8к + возможно 2-5к + ?. И тут готовое решение, и урегулирование вопросов с контролирующими и самое главное, верификация по sms. Во-первых, гостиницы и кафе в общей своей массе дают бесплатный wi-fi; Во-вторых, генерация, печать, нарезка и раздача купонов ляжет на сотрудников.

 

Связка получается примитивной. Первичное видение по незнанию казалось куда более удобным. Ответ с минсвязи до сих пор не получен, прошла неделя. Ответ просил на электронку. Сегодня прозвонил, спросил можно ли обойтись sms-авторизацией. В ответ, мол, в законе разве не написано? Ответил что нет разъяснений, на что посоветовали отписать на электронку.

[GrandPr1de]

Прочел статью, ссылки в её начале и комментарии к ней... из уважения к вам, что не перестаете отвечать на мои вопросы. Но это не то...

 

Нашли хорошую книгу как раз по связке Debian + freeradius + chilli на роутере, сейчас читаю.

 

Статья "не та", приведу сравнение:

 

Если объект ставит связку локально, ему нужно:

- купить компьютер (20к с монитором и прочим),

- поставить ось и биллинг (3-4к),

- прошить и настроить на сервер роутер (3к). Если роутер слабый, то купить новый (2-5к),

- прописать персонал на роутере (?)

- купить статичный ip (?)

- возможно, рейды сделать (2к)

Итого 26к + возможно 2-5к + возможно 2к + ? + ?. Ну и временные затраты на поиск того, кто всё это сделает.

 

Если наши услуги, то:

- прошить и настроить на сервер роутер (3к). Если роутер слабый, то купить новый (2-5к),

- оплатить год доступа (4,8к)

- депозит на оплату смс (2к)

- прописать персонал (?)

Итого 9,8к + возможно 2-5к + ?. И тут готовое решение, и урегулирование вопросов с контролирующими и самое главное, верификация по sms. Во-первых, гостиницы и кафе в общей своей массе дают бесплатный wi-fi; Во-вторых, генерация, печать, нарезка и раздача купонов ляжет на сотрудников.

 

Связка получается примитивной. Первичное видение по незнанию казалось куда более удобным. Ответ с минсвязи до сих пор не получен, прошла неделя. Ответ просил на электронку. Сегодня прозвонил, спросил можно ли обойтись sms-авторизацией. В ответ, мол, в законе разве не написано? Ответил что нет разъяснений, на что посоветовали отписать на электронку.

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

Если вы оттуда почерпнули хотя бы 1% нового - это уже победа, без насмешек.

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

 

В принципе вы вольны делать так, как ВАМ удобно, а не так как Я считаю правильным :)

[DGM]

Если решитесь роутеры в WRT шить, посмотрите прошивку tomatousb Shibby. В ней есть Captive Portal и поддержка Radius авторизации.