Перейти до

purestg2


Рекомендованные сообщения

Я все-таки собираюсь вынести опцию. Поэтому вопрос: нужно ли отдельно иметь возможность отключить "запрет подключения по VPN, если пользователь не может выйти в инет" и "автоматическое отключение пользователя, когда его отключает старгейзер"? Или достаточно одной настройки?

заметил что при блокировке/вычета в минус/заморозке VPN срывается но подключается снова, ИМХО наверно это ни к чему

я не совсем понял "автоматическое отключение пользователя, когда его отключает старгейзер" или это есть что я написал выше?

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 396
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

Вот это не имеет отношения к биллингу. Думаю гугл сможет подсказать, от чего это и как с этим бороться.     git на то и git, что из него можно взять любую версию. Вот здесь: https://github.com/l

Предположительно пофиксил. В git.   И начал пилить доставку calling number'а (MAC-адреса) в старгейзер, а также аутентификацию по нему.

я не совсем понял "автоматическое отключение пользователя, когда его отключает старгейзер" или это есть что я написал выше?

Да.

 

Я тоже думаю, что одной настройки достаточно. И VPN срывается по той же причине. Надо закомментировать вызовы activateNotifier(user); и deactivateNotifier(user); везде по коду.

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

В версии из git появилась поддержка новой опции - allownotinetable, при включении которой:

- из условий аутентификации в pppd исключается проверка доступа пользователя в интернет старгейзером (игнорируется блокировка пользователя, наличие у него на балансе достаточного количества средств и т.п.; проверяется только пара логин/пароль и, если указано в конфиге, значение из ipparam);

- когда старгейзер отключает пользователя (если закончились деньги, если пользователь заблокирован и т.п.), разрыв ppp-соединения не происходит.

 

OnConnect() и OnDisconnect() при этом срабатывают в обычном режиме (при подключении/отключении пользователя старгейзером).

 

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

 

Товарищ yKpon приглашается к тестированию.

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

не знаю, возможно это просто совпадение:

с локальным айпишником 192.168.0.99 подключил впн с учёткой такого же ip, итог сервер моментально завис не выдав ничего интересного в логи

может добавить проверку?

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

не знаю, возможно это просто совпадение:

с локальным айпишником 192.168.0.99 подключил впн с учёткой такого же ip, итог сервер моментально завис не выдав ничего интересного в логи

может добавить проверку?

Завис весь сервер? Или только pppd или Stargazer?

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

Завис весь сервер? Или только pppd или Stargazer?

сервер, могу конечно воспроизвести в самый безболезненый для абонентов момент :)

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

Завис весь сервер? Или только pppd или Stargazer?

сервер, могу конечно воспроизвести в самый безболезненый для абонентов момент :)

Так это проблема сервера.

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

не знаю, возможно это просто совпадение:

с локальным айпишником 192.168.0.99 подключил впн с учёткой такого же ip, итог сервер моментально завис не выдав ничего интересного в логи

Я думаю, что сервер на самом деле не завис, а перестал отвечать на сетевые запросы, т.к. появление такого же IP на втором интерфейсе могло снести крышу маршрутизатору (из-за внесения дублирующей/противоречивой записи в таблицу маршрутизации) или фаерволу (по тем же причинам).

 

может добавить проверку?

Это надо будет городить огород с получением локальных IP сервера... Думаю, это одна из тех проблем, которая проще решается организационным методом, чем техническим - заводить абонентов в отдельной подсети. :)

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

оффтоп:

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

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

всё думаю как запретить учётной записи авторизоваться через purestg2

Алексей, может быть я сам смогу в коде дописать проверку одного из полей stg в учётке?

или к примеру в конфиг может быть добавить разрешение авторизации к примеру 10.168.* или * , было бы замечательно :)

 

и ещё открыт вопрос как исключить авторизацию с аналогичного ip со стороны LAN

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

Поскольку нужно запрещать повторную авторизацию в обе стороны (и при попытке подключения через инетаксесс при активном пппое и при попытке подключения по пппое при активном инетаксессе), то правкой только лишь кода purestg2 здесь не обойтись.

 

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

 

Чтобы однозначно привязать пользователя к авторизатору, наверное, надо делать соответствующую настройку у каждого пользователя ("разрешить доступ через": "любой", "alwaysonline", "inetaccess", "purestg2") с соответствующей правкой XML RPC, sgconfig и прочих утилит, схемы данных. Могу попытаться реализовать, если меня немного финансово простимулировать. :)

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

да не, это слишком серьёзно =)

проблема с пересечением ip это не пересечение авторизации через inetaccess и purestg2, а просто машина с локальным ip когда авторизуется на такой же ip через рррое либо через рртр вешает сервер, как оградить рррое по MAC я уже сделал через ebtables.

 

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

возможно это оффтоп от этой темы, но пока не могу придумать как запретить поднятие pppX интерфейса с совпадающими ip в сети, были мысли в ip-pre-up делать проверку на arping -I eth_local $IP, где IP это выдаваемый айпи и смотреть есть ли такой же по arp, но результата не дало.

 

как вариант можно применить ip-sentinel, но надеяться на него тоже стрёмно

 

стоп, а если выдаваемый ip просто приколотить по маку через ARP к примеру 00:00:00:00:00:00, надо проверить

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

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

 

Как вариант, указывать в конфигураторе для пользователя два разных IP (через запятую, вроде). purestg2 всегда выдает первый IP из списка, а inetaccess может авторизоваться с любого из перечисленных. Тогда если клиент впишет на сетевуху свой старый IP, который он помнит, а потом подключится через VPN, то конфликта адресов не будет, т.к. VPN-интерфейс получит другой IP.

 

Конечно, пользователь может подсмотреть тот IP, который ему присвоили для VPN и вписать потом его же на сетевуху, но зачем ему это делать? :) Но даже если он так сделает, то VPN-ский IP будет из другой подсети, и локалка с ним у него вообще не будет работать. Следовательно, и у сервера с мозгами все будет в порядке - VPN-ский адрес на сетевухе клиента ему будет просто недоступен, как будто и нет его вовсе.

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

вариант со вторым айпи в учётке заинтересовал

то есть прописываем первым адресом айпи для VPN, вторым локальный, правильно?

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

Алексей спасибо, мне кажется это наилучший вариант :)

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

то есть прописываем первым адресом айпи для VPN, вторым локальный, правильно?

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

Да, теоретически так.

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

обнаружил 2 проблемы через PPPoE

1. выставил pppdtimeout = 30 и сессии начали подключаться и отваливаться и так по кругу, поставил 60 стало ровно, логи уже потёр, в принципе не критично, оставлю 60

2. после рестарта биллинга не переподключаются абоненты у которых авторизация на машине под маздай, в настройках подключения выставлено автоматическое переподключение через 1 секунду и бесконечное число попыток

с роутерами такой проблемы нет

 

сейчас одна железа ubiquiti отвалилась, ppp туннель упал, в stg статус online, авторизоваться не может

 

пока выставил kickprevious, но думаю это временное решение

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

обнаружил 2 проблемы через PPPoE

1. выставил pppdtimeout = 30 и сессии начали подключаться и отваливаться и так по кругу, поставил 60 стало ровно, логи уже потёр, в принципе не критично, оставлю 60

 

С опцией stg-плагина 'pppdtimeout' тесно связана опция pppd-плагина 'keepalivetimeout'. 'keepalivetimeout' определяет интервал, с которым плагин pppd пингует плагин stg. Естественно, если этот интервал будет больше, чем pppdtimeout, старгейзер будет сбрасывать соединение, подумав, что pppd умер.

 

2. после рестарта биллинга не переподключаются абоненты у которых авторизация на машине под маздай, в настройках подключения выставлено автоматическое переподключение через 1 секунду и бесконечное число попыток

 

"не переподключаются" - слишком пространно. Как это конкретно выглядит на машине клиента? Как это конкретно выглдяит в логах pppd? Старгейзера?

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

с виндой ладно, но ubiquiti роутер отвалился, в stg статус online, авторизоваться не может, пришлось рестартить биллинг

в логах вто что поймал

 

Mar 10 18:00:31 skyprox pppoe-server[16821]: Session 56 created for client 00:27:22:e2:7c:62 (10.0.0.185) on eth_local using Service-Name ''
Mar 10 18:00:31 skyprox pppd[16821]: Plugin purestg2.so loaded.
Mar 10 18:00:31 skyprox pppd[16821]: Stargazer (purestg2 2.4) auth plugin initialized.
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: Chap check is allowed.
Mar 10 18:00:31 skyprox pppd[16821]: pppd 2.4.5 started by root, uid 0
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: Connected to stargazer via /var/run/purestg2.sock.
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: ifunit set to 23.
Mar 10 18:00:31 skyprox pppd[16821]: Using interface ppp23
Mar 10 18:00:31 skyprox pppd[16821]: Connect: ppp23 <--> /dev/pts/13
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: Chap check is allowed.
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: Chap check is allowed.
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: CHAP started.
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: Got passwd for user semen.
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: IP choose started.
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: Allowed address.
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: Good address.
Mar 10 18:00:31 skyprox pppd[16821]: local  IP address 10.0.0.254
Mar 10 18:00:31 skyprox pppd[16821]: remote IP address 10.168.12.3
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: User semen connected.
Mar 10 18:00:32 skyprox pppd[16443]: Connection terminated.
Mar 10 18:00:32 skyprox pppd[16443]: Modem hangup
Mar 10 18:00:32 skyprox pppoe[16445]: read (asyncReadFromPPP): Session 33: Input/output error
Mar 10 18:00:32 skyprox pppd[16443]: Exit.
Mar 10 18:00:32 skyprox pppoe-server[25924]: Session 33 closed for client 00:27:22:e2:7c:62 (10.0.0.162) on eth_local
Mar 10 18:00:32 skyprox pppoe-server[25924]: Sent PADT
Відредаговано yKpon
Ссылка на сообщение
Поделиться на других сайтах

 

в логах вто что поймал

 

Mar 10 18:00:31 skyprox pppoe-server[16821]: Session 56 created for client 00:27:22:e2:7c:62 (10.0.0.185) on eth_local using Service-Name ''
Mar 10 18:00:31 skyprox pppd[16821]: Plugin purestg2.so loaded.
...
Mar 10 18:00:31 skyprox pppd[16821]: remote IP address 10.168.12.3
Mar 10 18:00:31 skyprox pppd[16821]: purestg2: User semen connected.
-----------------------------------------------------------------------
Mar 10 18:00:32 skyprox pppd[16443]: Connection terminated.
Mar 10 18:00:32 skyprox pppd[16443]: Modem hangup
Mar 10 18:00:32 skyprox pppoe[16445]: read (asyncReadFromPPP): Session 33: Input/output error
Mar 10 18:00:32 skyprox pppd[16443]: Exit.
Mar 10 18:00:32 skyprox pppoe-server[25924]: Session 33 closed for client 00:27:22:e2:7c:62 (10.0.0.162) on eth_local
Mar 10 18:00:32 skyprox pppoe-server[25924]: Sent PADT

Это уже при включенной kickprevious?

А можно лог подключения для pppd[16443]? А то здесь только его смерть.

 

Вообще, похоже на то, что при (плановом) рестарте старгейзера не убиваются активные pppd-подключения. Погляди, если остановить биллинг, все ли пользовательские pppd завершают работу? Хотя с другой стороны, даже если это не так, то ничего страшного из этого не следует: после ручного разрыва соединения пользователем повторное подключение должно пройти штатно.

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

нет это лог при выключенном kickprevious

вот лог pppd[16443]

 

Mar 10 17:10:07 skyprox pppd[16443]: Plugin purestg2.so loaded.
Mar 10 17:10:07 skyprox pppd[16443]: Stargazer (purestg2 2.4) auth plugin initialized.
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: Chap check is allowed.
Mar 10 17:10:07 skyprox pppd[16443]: pppd 2.4.5 started by root, uid 0
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: Connected to stargazer via /var/run/purestg2.sock.
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: ifunit set to 12.
Mar 10 17:10:07 skyprox pppd[16443]: Using interface ppp12
Mar 10 17:10:07 skyprox pppd[16443]: Connect: ppp12 <--> /dev/pts/3
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: Chap check is allowed.
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: Chap check is allowed.
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: CHAP started.
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: Got passwd for user semen.
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: IP choose started.
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: Allowed address.
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: Good address.
Mar 10 17:10:07 skyprox pppd[16443]: local  IP address 10.0.0.254
Mar 10 17:10:07 skyprox pppd[16443]: remote IP address 10.168.12.3
Mar 10 17:10:07 skyprox pppd[16443]: purestg2: User semen connected.
Mar 10 18:00:29 skyprox pppd[16443]: LCP terminated by peer (Peer not responding)
Mar 10 18:00:29 skyprox pppd[16443]: purestg2: User semen disconnected.
Mar 10 18:00:29 skyprox pppd[16443]: purestg2: Disconnected from stargazer.
Mar 10 18:00:29 skyprox pppd[16443]: Couldn't get PPP statistics: No such device
Mar 10 18:00:29 skyprox pppd[16443]: Couldn't get PPP statistics: No such device
Mar 10 18:00:29 skyprox pppd[16443]: ioctl (SIOCGIFFLAGS): No such device (line 2353)
Mar 10 18:00:29 skyprox pppd[16443]: ioctl(SIOCSIFADDR): No such device (line 2513)
Mar 10 18:00:32 skyprox pppd[16443]: Connection terminated.
Mar 10 18:00:32 skyprox pppd[16443]: Modem hangup
Mar 10 18:00:32 skyprox pppd[16443]: Exit.

оговорюсь, названия туннелей через ip-up именуются вида vpn_$LOGIN вместо pppX

 

при рестарте все туннели убиваются

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

Нормальные логи.

 

В 17:10:07 Семён подключился. В 18:00:29 pppd понимает, что Семён куда-то пропал (peer not responding) и начинает закрывать соединение. purestg2 в этом месте отрабатывает правильно, посылая сигнал старгейзеру отключить Семёна (purestg2: User semen disconnected), этот момент ещё можно проконтролировать логом самого старгейзера. Дальше, в 18:00:31, Семён подключается повторно, ему открывается новая pppoe сессия, стартует новый pppd[16821]. Опять же, судя по логам, purestg2 отрабатывает правильно и успешно подключает Семёна в старгейзере (purestg2: User semen connected). Это тоже можно проконтролировать логом старгейзера. Наконец, в 18:00:32, окончательно умирает старый pppd[16443].

 

Потенциальная грабля - то, что старый pppd окончательно умирает уже после установки нового соединения. Но я пока не могу придумать, почему это должно быть проблемой. Тем более, что purestg2 успевает сообщить старгейзеру об отключении старой сессии (в 18:00:29) ещё перед тем, как началась новая (в 18:00:31). Если бы он не успевал, то второе подключение бы не прошло и сообщения "pppd[16821]: purestg2: User semen connected." не было бы.

 

В любом случае, в приведенных логах не видно ничего похожего на "в stg статус online, авторизоваться не может".

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

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

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

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

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

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

Вхід

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

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...