Alexey Osipov

Релиз 2.4: https://github.com/lion-simba/purestg2/releases/tag/2.4 PS. Проект переехал на github.

Сердечно благодарю за мнения! Я таки почти одумался и вернулся к рассмотрению варианта с привязкой IP/MAC. Авторизатор старгейзера хорош, но опять же дополнительное ПО на конечных машинах. +, но по условиям задачи у нас неизвестно какие свичи. ВО! Я теперь знаю, по какому слову гуглить. Спасибо! +, а ещё я внезапно вспомнил про CGI. Но вообще изначально хотел заюзать вот это: https://www.gnu.org/software/libmicrohttpd/Вроде как раз для этих целей. Не C++ правда, но. Always online как-раз не очень по причинам, озвученным нашим пытателем единорогов.

Всем привет! Есть небольшая компания, которая хочет контролировать использование интернета своими сотрудниками (~30 пользователей). Авторизация пользователей по IP/MAC ненадежна. Поднятие PPPoE приведет к трудностям как для пользователей (надо "подключать" интернет), так и для админа (шлюз по умолчанию для пользователей после подключения PPPoE изменится и трафик пойдет через него => на сервере придется специальным образом обрабатывать доступ к внутренним ресурсам). squid-авторизация решает вопрос только для http-трафика и только если squid непрозрачный (а непрозрачный squid опять же геморрой для пользователей). Поэтому есть мысль использовать веб-авторизацию. Значит идея следующая. Пишем для Stargazer новый модуль авторизации, который содержит в себе свой маленький https-сервер. Неавторизованный пользователь заходит на этот https-сервер и вводит там логин/пароль. Плагин аутентифицирует пользователя, и у последнего появляется интернет. Разлогинится можно на той же странице. Кроме того, после авторизации плагин помещает пользователя в специальный список и начинает следить за количетством потребляемого пользователем трафика. Если за последние N минут пользователь не потребил ни одного байта трафика, происходит автоматическое разлогинивание. На шлюзе при этом настроен автоматический редирект неавторизованных пользователей, которые ломятся на любой 80-й порт, на эту страницу авторизации. В итоге для пользователей никаких дополнительных настроек - захотел в инет, заходишь на сайт, тебя редиректит на страницу логина, логинишься там, тебя редиректит обратно на сайт. Я было собрался всё это запилить, но у меня странное ощущение, что задача-то вобщем не новая. Может быть есть какие-то типовые решения на этот счет?

Есть. Разбить имеющийся диапазон на несколько по количеству вланов не вариант? Насколько обязательно иметь отдельный pppoe-server для каждого влана? В мане pppoe-server написано, что опцию -I можно давать несколько раз с разными интерфейсами, и он будет слушать их все. Выдаст. Как вариант использовать опцию -p, которая позволяет задать файл со списком адресов, которые будут выдаваться абонентам. Исключить из этого файла статические адреса. Можно, опять же, чисто организационно, статические адреса выдавать из одного пула, а динамические - из другого. Или, например, статические выдавать с конца диапазона и каждый раз уменьшать параметр -N. Если всё это не подходит, то давай обсудим размер благодарности (в личке).

Логично. А почему -N 500 тогда? Можно сделать -N 254 и тогда не будет выходить за диапазон. Сделать реально, по аналогии с тем, как сейчас плагин отслеживает номера ppp-интерфейсов. Но мне кажется, что способ с -N 254 проще.

Как оно там?

Есть. Реализовано в git. Теперь, если у пользователя в настройках стоит "*", то purestg2 не будет пытаться назначать IP пользователю. IP будет выбирать сам pppd. При этом после подключения пользователя, выбранный IP-адрес будет видно в старгейзере, и именно он придет в скрипт OnConnect. Через какое-то время планирую выпустить релиз 2.4, уже достаточно изменений набралось.

Как как? Допиливать purestg2. =) Как и говорил - это несложно. Попробую запланировать на ближайшие выходные.

Выдается 0.0.0.0, что конечно же ни к чему хорошему не приводит. Так и есть. А звездочка в поле IP интерпретируется старгейзером как 0.0.0.0. В принципе можно доработать purestg2, чтобы он использовал IP, который предлагает pppd. Это несложно.

И я кажется понял, от чего дважды запрос на коннект пришел. Коннект зовется в тот момент, когда у pppd происходит событие ip_up ("Протокол IP сконфигурирован и готов к использованию"). Я прогулялся по исходникам pppd, и похоже, что это событие может происходить сколько угодно раз за время существования соединения, а именно всякий раз, когда клиент запрашивает переконфигурацию параметров соединения. Однако, перед ip_up в pppd честно возникает событие ip_down, но беда в том, что это событие purestg2 никак не обрабатывает. А дисконнект юзера происходит на link_down, т.е. после разрыва соединения. Почему я повесил отключение пользователя на link_down - не помню. В логе git так с самого начала было. Как бы то ни было, я поменял событие обработки отключения пользователя с link_down на ip_down. Изменения в git. Плагин собирается, работоспособность я не проверял. Бедный измученный yKpon может рискнуть обновиться. ВАЖНО: изменился порядок вызова скриптов при отключении пользователя: теперь purestg2'шный 'predownscript' будет зваться гарантированно ДО pppd'шного /etc/ppp/ip-down. /etc/ppp/ip-down, OnDisconnect и /etc/ppp/auth-down могут выполняться ОДНОВРЕМЕННО. Кроме того, выходит, что пользователь может переподключаться в СТГ несколько раз за время работы ppp-соединения. Для каждого из этих разов будут вызваны preupscript,OnConnect*,ip-up и predownscript,OnDisconnect*,ip-down. * - OnConnect и OnDisconnect будут вызваны только если между отключением и подключением пройдет некоторое (небольшое) количество времени. Если переподключение произойдет очень быстро, то они вызваны не будут.

madf, отличный анализ! Теперь бы ещё посмотреть логи pppd в окрестностях 2014-05-11 18:12:45.

А это вообще что-то жуткое и на первый взгляд не имеющее ни к Stargazer ни к тем более purestg2 никакого отношения. С этим разобрались? Или продолжает повторяться?

Вот это не имеет отношения к биллингу. Думаю гугл сможет подсказать, от чего это и как с этим бороться. git на то и git, что из него можно взять любую версию. Вот здесь: https://github.com/lion-simba/purestg2/commits/master можно выбрать понравившуюся версию, кликнуть рядом с ней Browse Code, а затем справа кнопочку Download ZIP. Кроме того, ни куда не делись стабильные релизы: http://code.google.com/p/purestg2/downloads/list

А это вообще что-то жуткое и на первый взгляд не имеющее ни к Stargazer ни к тем более purestg2 никакого отношения.

Не могу пока выделить достаточно времени. Тут надо вдумчиво смотреть. Желание есть, проект формально не остановлен. В качестве workaround предлагаю выключить в конфиге kickprevious.

Выложил в git, компилируется, но работоспособность я вообще не проверял. Если страшно, то жди, когда я проверю (на неделе).

Да, точняк. Поглядел код. Старгейзер запускает OnConnect и OnDisconnect асинхронно. И если после отключения пользователя, он снова подключится в пределах 0.1 с, то старгейзер будет считать, что пользователь никуда и не уходил, а следовательно OnDisconnect/OnConnect зваться не будут. В принципе, есть у меня одна идея, как это на уровне purestg2 можно разрулить. Попробую на выходных.

Такого не должно быть. Вставь в OnConnect/OnDisconnect в самое начало какие-нибудь логгеры типа echo "`date` User $user connected" >> /var/log/stgconnects.log в самое начало, чтобы убедиться, что эти скрипты выполняются. Заодно увидим, в каком порядке. Нет, эти таймауты точно ни при чем. Тут происходит какой-то race condition. Например, не гарантируется, что OnDisconnect будет выполнен до закрытия ppp-интерфейса. Однако OnConnect гарантированно выполняется после инициализации ppp-интрфейса. Но если ppp-интерфейс очень быстро отвалился, то OnConnect может отработать, когда интерфейса уже нет. А если уже успел подключиться другой пользователь на ppp-интерфейс с тем же номером, выходит, OnConnect будет выполнен для другого пользователя вообще. То же самое и к OnDisconnect кстати относится. Это если в OnConnect/OnDisconnect идентифицировать интерфейс через pppunitsave. А если по IP это делать (с условием, что IP у пользователей не повторяются), то не должно таких казусов происходить. По идее. В логах выше, у какого пользователя не назначился шейпер?

Нужен лог старгейзера за тот же промежуток времени.

Параметр keepalivetimeout добавляется к pppd модулем purestg2. Он опциональный. Если его не задать, то он считается равным 60 (секунд).

Это опция pppd. Откуда pppd берет конфиг с опциями - зависит от того, кто этот pppd запускает. Если, например, pppd запускается из pppoe-server, то эти опции лежат в /etc/ppp/pppoe-server-options

Нет, отключить совсем не получится. Если опцию убрать из конфига, то будет использоваться значение по умолчанию - 5 минут. Как watchdog он полезен. Я бы рекомендовал оставить значения по умолчанию.

В принципе любое больше нуля. Главное, чтобы pppdtimeout был больше (желательно минимум в 2 раза), чем keepalivetimeout в конфиге pppd. Слишком маленькие значения, впрочем, могут породить излишнюю активность соединения между pppd и stargazer'ом (через UNIX socket'ы). Не знаю чем это черевато. Если отклик старгейзера будет запаздывать, то процесс логина у пользователя будет тоже затягиваться. Думаю, если его черезчур сильно затянуть, то клиент (или его винда/линукс) не дождется ответа и сам разорвет ещё неустановленное соединение. Ещё это приведет к увеличению нагрузки на процессор, т.к. старгейзеру придется чаще лазить в список пользователей и проверять, разрешен ли ему выход в инет. Насколько возрастет - не готов сказать. И в конце концов, начиная с релиза 2.2 pppdtimeout скорее "навсякислучная" опция на случай, если "что-то пойдет не так". В штатном режиме, если pppd отваливается, то старгейзер сразу об этом узнает и отключает пользователя, не дожидаясь прошествия pppdtimeout. Аналогично, если старгейзер сам решает отключить пользователя, то pppd должно отключиться практически сразу же (единицы секунд).

Выложил.

Там довольно обширная переделка. В процессе. По поводу "2014-01-21 09:48:11 -- purestg2: BUG: can't find previous user socket for user "razor"" - предположительно пофиксил, ещё позавчера, но у меня слегка повредился локальный репозиторий с кодом, не смог сходу выложить на github. Это скорее всего завтра выложу.