purestg2

[yKpon 8]

  В 09.10.2012 в 06:04, Alexey Osipov сказав:

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

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

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

[Alexey Osipov 38]

  В 09.10.2012 в 08:07, yKpon сказав:

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

Да.

 

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

[Alexey Osipov 38]

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

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

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

 

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

 

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

 

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

[yKpon 8]

всегда готов! завтра с утра начну. Спасибо!

[yKpon 8]

всё, в бою, наблюдаю

[yKpon 8]

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

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

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

[madf 279]

  В 30.11.2012 в 13:08, yKpon сказав:

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

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

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

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

[yKpon 8]

  В 30.11.2012 в 13:17, madf сказав:

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

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

[madf 279]

  В 30.11.2012 в 13:50, yKpon сказав:

  В 30.11.2012 в 13:17, madf сказав:

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

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

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

[Alexey Osipov 38]

  В 30.11.2012 в 13:08, yKpon сказав:

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

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

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

 

  В 30.11.2012 в 13:08, yKpon сказав:

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

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

[yKpon 8]

лучше сделаю эту проверку самим ip-up

[yKpon 8]

оффтоп:

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

[Роман Погосян 0]

Если есть возможность жить на инетаккесе , переходить на пппое это добавить время отклика клиенту

[yKpon 8]

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

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

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

 

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

Відредаговано 2013-03-06 10:53:27 yKpon

[Alexey Osipov 38]

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

 

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

 

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

[yKpon 8]

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

проблема с пересечением 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, надо проверить

Відредаговано 2013-03-07 04:53:21 yKpon

[Alexey Osipov 38]

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

 

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

 

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

[yKpon 8]

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

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

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

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

Відредаговано 2013-03-07 05:16:09 yKpon

[Alexey Osipov 38]

  В 07.03.2013 в 05:12, yKpon сказав:

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

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

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

[yKpon 8]

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

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

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

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

 

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

 

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

Відредаговано 2013-03-10 15:50:51 yKpon

[Alexey Osipov 38]

  В 10.03.2013 в 09:03, yKpon сказав:

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

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

 

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

 

  В 10.03.2013 в 09:03, yKpon сказав:

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

 

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

[yKpon 8]

с виндой ладно, но 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

Відредаговано 2013-03-11 13:20:16 yKpon

[Alexey Osipov 38]

  В 11.03.2013 в 13:04, 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 завершают работу? Хотя с другой стороны, даже если это не так, то ничего страшного из этого не следует: после ручного разрыва соединения пользователем повторное подключение должно пройти штатно.

[yKpon 8]

нет это лог при выключенном 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

 

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

Відредаговано 2013-03-11 18:40:10 yKpon

[Alexey Osipov 38]

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

 

В 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, авторизоваться не может".