emostar 06.01.2012 17:05
Есть вопрос! — Wi-Fi биллинг-интерфейс
В очередной раз обращаюсь к вам за помощью.Например есть слабенький комп с линуксом на борту, куда подключено 2 Wi-Fi модуля по USB, для раздачи инета людям за деньги.
Наверно вы видели точки доступа без пароля, при подключении к которым редиректит на страницу провайдера Wi-Fi, где можно оплатить услугу и тогда интернет открывается.
Подскажите, пожалуйста, как называется этот тип софта, какие есть варианты. и куда его ставить, на сам комп с вайфаем (их много) или на сервер с которого туда идет интернет?
Спасибо.
UPD: насчет предыдущего поста где я писал о работе - вакансия админа пока что приостановлена, нам всё еще нужен программист на Android, а так же сотрудники техподдержки.
Похожие
Поделиться
xtavras 07.01.2012 14:15 #
+ 2 -
Много слышал про Zeroshell, но сам опыта не имел.
cppmm
Я участвовал в создании такой схемы, правда только частично. Провайдер, в котором я работал отвечал за физическую часть и маршрутизацию, другой провайдер предоставлял биллинг и собственно доступ в интернет. Технологий, использовавшихся у наших партнёров я не знаю, но есть предположения. Постараюсь описать принцип работы, может это окажется полезным. Для того, чтобы не путаться, мой провайдер я в дальнейшем буду называть локальным, а тот второй - интернет.
Я ставил несколько точек доступа. На всех точках настраивался прямой маршрут к серверу интернет-провайдера и radius прокси.
При попытке выйти в интернет, траффик блокировался на сервере интернет-провайдера. После ввода логина с паролем, происходила авторизация и аутентификация клиента по протоколу radius, на сервер интернет-провайдера, от точек локального провайдера передавался мак-адрес клиента и присвоенный при подключении к wi-fi айпишник(для этого и ставился radius-прокси). Причём, ip-адреса клиенты получали от dhcp сервера интернет-провайдера.
Далее мои предположения. Предположим, клиенты получают адреса из сети 192.168.0.0/24, а конкретный подключившийся и авторизовавшийся клиент будет иметь айпи 192.168.0.100. Судя по всему, при авторизации в биллинге у них мак привязывался к айпи и к логину. Для этого ip открывался доступ в инет добавлением разрешающего правила в iptables. Сделать это можно так.
По умолчанию все политики установлены в DROP и висит редирект типа
iptables -t nat -A PREROUTING -s 192.168.0.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 80
или
iptables -t nat -A PREROUTING -s 192.168.0.0/24 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.1:80
Первое правило будет редиректить всех локальных клиентов, попытавшихся выйти в сеть на апач сервера, занимающегося блокированием. Второе правило необходимо, если апач и биллинг находятся на каком-то другом сервере.
После удачной авторизации в iptables добавляется исключение типа
iptables -t nat -I PREROUTING -s 192.168.0.100 -j MARK --set-xmark 0x10
Здесь я для примера выставил метку. Ключ -I добавляет правило вперёд цепочки, поэтому через него пакеты пройдут в первую очередь и уже не попадут на редирект. Метку потом можно использовать для сложной маршрутизации. Можно вообще не трогать. Главное, что пакет прошёл.
Одновременно с этим добавляются разрешающие правила в цепочке FORWARD таблицы filter.
Всё, клиент в интернете. В дальнейшем при работе биллинг с помощью radius'а считает траффик или время(в зависимости от того, какие ограничения стоят для данного клиента) и в случае достижения лимита, убирает эти правила, закрывая таким образом доступ.
Т.е. самое сложное - это биллинг. Раньше был неплохой FreeNIBS, работавший в связке с FreeRADIUS. Я использовал его у себя для тарификации клиентов моего провайдера на других точках. Но уже тогда его разработка шла не особо активно. Возможно, есть и другие, поддерживающие радиус, клиенты.
Отдельное замечание по поводу radius-прокси. Я делал всё это не на компах с линуксом, а на аппаратных wi-fi-роутерах с прошивкой dd-wrt. Там это есть из коробки.
В общей сложности, таким способом было накрыто вай-фаем несколько городов. В сочетании с WDS при такой схеме можно ещё и роуминг организовать(клиентам не придётся менять настройки wi-fi при переходе из зоны одной точки доступа в другую) - полезно для покрытия сетью крупных зданий(мне, например, понадобилось всего семь ТД для того, чтобы накрыть вайфаем территорию крупной гостиницы моего родного города).
Если что-то непонятно объяснил, спрашивайте. Правда, конкретных настроек я не предоставлю, потому как уже давно сменил работу.
Я ставил несколько точек доступа. На всех точках настраивался прямой маршрут к серверу интернет-провайдера и radius прокси.
При попытке выйти в интернет, траффик блокировался на сервере интернет-провайдера. После ввода логина с паролем, происходила авторизация и аутентификация клиента по протоколу radius, на сервер интернет-провайдера, от точек локального провайдера передавался мак-адрес клиента и присвоенный при подключении к wi-fi айпишник(для этого и ставился radius-прокси). Причём, ip-адреса клиенты получали от dhcp сервера интернет-провайдера.
Далее мои предположения. Предположим, клиенты получают адреса из сети 192.168.0.0/24, а конкретный подключившийся и авторизовавшийся клиент будет иметь айпи 192.168.0.100. Судя по всему, при авторизации в биллинге у них мак привязывался к айпи и к логину. Для этого ip открывался доступ в инет добавлением разрешающего правила в iptables. Сделать это можно так.
По умолчанию все политики установлены в DROP и висит редирект типа
iptables -t nat -A PREROUTING -s 192.168.0.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 80
или
iptables -t nat -A PREROUTING -s 192.168.0.0/24 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.1:80
Первое правило будет редиректить всех локальных клиентов, попытавшихся выйти в сеть на апач сервера, занимающегося блокированием. Второе правило необходимо, если апач и биллинг находятся на каком-то другом сервере.
После удачной авторизации в iptables добавляется исключение типа
iptables -t nat -I PREROUTING -s 192.168.0.100 -j MARK --set-xmark 0x10
Здесь я для примера выставил метку. Ключ -I добавляет правило вперёд цепочки, поэтому через него пакеты пройдут в первую очередь и уже не попадут на редирект. Метку потом можно использовать для сложной маршрутизации. Можно вообще не трогать. Главное, что пакет прошёл.
Одновременно с этим добавляются разрешающие правила в цепочке FORWARD таблицы filter.
Всё, клиент в интернете. В дальнейшем при работе биллинг с помощью radius'а считает траффик или время(в зависимости от того, какие ограничения стоят для данного клиента) и в случае достижения лимита, убирает эти правила, закрывая таким образом доступ.
Т.е. самое сложное - это биллинг. Раньше был неплохой FreeNIBS, работавший в связке с FreeRADIUS. Я использовал его у себя для тарификации клиентов моего провайдера на других точках. Но уже тогда его разработка шла не особо активно. Возможно, есть и другие, поддерживающие радиус, клиенты.
Отдельное замечание по поводу radius-прокси. Я делал всё это не на компах с линуксом, а на аппаратных wi-fi-роутерах с прошивкой dd-wrt. Там это есть из коробки.
В общей сложности, таким способом было накрыто вай-фаем несколько городов. В сочетании с WDS при такой схеме можно ещё и роуминг организовать(клиентам не придётся менять настройки wi-fi при переходе из зоны одной точки доступа в другую) - полезно для покрытия сетью крупных зданий(мне, например, понадобилось всего семь ТД для того, чтобы накрыть вайфаем территорию крупной гостиницы моего родного города).
Если что-то непонятно объяснил, спрашивайте. Правда, конкретных настроек я не предоставлю, потому как уже давно сменил работу.
мы сами себе разработали систему для раздачи анонимного вайфай интернета за деньгу. питон, мускуль, iptables. если интересно, дам контакт разработчика этой штуки.
pfSense - его родной CaptivePortal (Radius,Login-password,Voucher)
