yKpon 8 Опубликовано: 2012-10-09 08:07:42 Share Опубликовано: 2012-10-09 08:07:42 Я все-таки собираюсь вынести опцию. Поэтому вопрос: нужно ли отдельно иметь возможность отключить "запрет подключения по VPN, если пользователь не может выйти в инет" и "автоматическое отключение пользователя, когда его отключает старгейзер"? Или достаточно одной настройки? заметил что при блокировке/вычета в минус/заморозке VPN срывается но подключается снова, ИМХО наверно это ни к чему я не совсем понял "автоматическое отключение пользователя, когда его отключает старгейзер" или это есть что я написал выше? Ссылка на сообщение Поделиться на других сайтах
Alexey Osipov 38 Опубликовано: 2012-10-11 09:17:36 Автор Share Опубликовано: 2012-10-11 09:17:36 я не совсем понял "автоматическое отключение пользователя, когда его отключает старгейзер" или это есть что я написал выше? Да. Я тоже думаю, что одной настройки достаточно. И VPN срывается по той же причине. Надо закомментировать вызовы activateNotifier(user); и deactivateNotifier(user); везде по коду. Ссылка на сообщение Поделиться на других сайтах
Alexey Osipov 38 Опубликовано: 2012-11-11 05:27:06 Автор Share Опубликовано: 2012-11-11 05:27:06 В версии из git появилась поддержка новой опции - allownotinetable, при включении которой: - из условий аутентификации в pppd исключается проверка доступа пользователя в интернет старгейзером (игнорируется блокировка пользователя, наличие у него на балансе достаточного количества средств и т.п.; проверяется только пара логин/пароль и, если указано в конфиге, значение из ipparam); - когда старгейзер отключает пользователя (если закончились деньги, если пользователь заблокирован и т.п.), разрыв ppp-соединения не происходит. OnConnect() и OnDisconnect() при этом срабатывают в обычном режиме (при подключении/отключении пользователя старгейзером). Полезно, если, например, хочется показывать пользователю красивую страницу о том, что кончились денюшки, вместо того, чтобы просто разрывать ppp-соединение. Товарищ yKpon приглашается к тестированию. Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2012-11-12 06:20:18 Share Опубликовано: 2012-11-12 06:20:18 всегда готов! завтра с утра начну. Спасибо! Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2012-11-13 17:06:06 Share Опубликовано: 2012-11-13 17:06:06 всё, в бою, наблюдаю Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2012-11-30 13:08:00 Share Опубликовано: 2012-11-30 13:08:00 не знаю, возможно это просто совпадение: с локальным айпишником 192.168.0.99 подключил впн с учёткой такого же ip, итог сервер моментально завис не выдав ничего интересного в логи может добавить проверку? Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубликовано: 2012-11-30 13:17:24 Share Опубликовано: 2012-11-30 13:17:24 не знаю, возможно это просто совпадение: с локальным айпишником 192.168.0.99 подключил впн с учёткой такого же ip, итог сервер моментально завис не выдав ничего интересного в логи может добавить проверку? Завис весь сервер? Или только pppd или Stargazer? Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2012-11-30 13:50:44 Share Опубликовано: 2012-11-30 13:50:44 Завис весь сервер? Или только pppd или Stargazer? сервер, могу конечно воспроизвести в самый безболезненый для абонентов момент Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубликовано: 2012-11-30 13:56:35 Share Опубликовано: 2012-11-30 13:56:35 Завис весь сервер? Или только pppd или Stargazer? сервер, могу конечно воспроизвести в самый безболезненый для абонентов момент Так это проблема сервера. Ссылка на сообщение Поделиться на других сайтах
Alexey Osipov 38 Опубликовано: 2012-12-03 04:28:33 Автор Share Опубликовано: 2012-12-03 04:28:33 не знаю, возможно это просто совпадение: с локальным айпишником 192.168.0.99 подключил впн с учёткой такого же ip, итог сервер моментально завис не выдав ничего интересного в логи Я думаю, что сервер на самом деле не завис, а перестал отвечать на сетевые запросы, т.к. появление такого же IP на втором интерфейсе могло снести крышу маршрутизатору (из-за внесения дублирующей/противоречивой записи в таблицу маршрутизации) или фаерволу (по тем же причинам). может добавить проверку? Это надо будет городить огород с получением локальных IP сервера... Думаю, это одна из тех проблем, которая проще решается организационным методом, чем техническим - заводить абонентов в отдельной подсети. Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2012-12-03 14:01:19 Share Опубликовано: 2012-12-03 14:01:19 лучше сделаю эту проверку самим ip-up Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2013-01-10 19:18:40 Share Опубликовано: 2013-01-10 19:18:40 оффтоп: есть мысль плавно переводить на PPPoE, не могу додумать как не допустить авторизацию с логинами, которые для инетацесса, чтобы не получилось зависов описаных выше. Ссылка на сообщение Поделиться на других сайтах
Роман Погосян 0 Опубликовано: 2013-01-11 08:36:06 Share Опубликовано: 2013-01-11 08:36:06 Если есть возможность жить на инетаккесе , переходить на пппое это добавить время отклика клиенту Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2013-03-06 08:08:17 Share Опубликовано: 2013-03-06 08:08:17 (изменено) всё думаю как запретить учётной записи авторизоваться через purestg2 Алексей, может быть я сам смогу в коде дописать проверку одного из полей stg в учётке? или к примеру в конфиг может быть добавить разрешение авторизации к примеру 10.168.* или * , было бы замечательно и ещё открыт вопрос как исключить авторизацию с аналогичного ip со стороны LAN Изменено 2013-03-06 10:53:27 пользователем yKpon Ссылка на сообщение Поделиться на других сайтах
Alexey Osipov 38 Опубликовано: 2013-03-06 18:05:45 Автор Share Опубликовано: 2013-03-06 18:05:45 Поскольку нужно запрещать повторную авторизацию в обе стороны (и при попытке подключения через инетаксесс при активном пппое и при попытке подключения по пппое при активном инетаксессе), то правкой только лишь кода purestg2 здесь не обойтись. Как вариант, добавить в старгейзер опцию навроде "allowonlyoneauthorizator", запрещающий каждому пользователю авторизовываться более чем одним авторизатором. В этом случае, конечно, у пользователя остается возможность самому выбирать способ авторизации. Чтобы однозначно привязать пользователя к авторизатору, наверное, надо делать соответствующую настройку у каждого пользователя ("разрешить доступ через": "любой", "alwaysonline", "inetaccess", "purestg2") с соответствующей правкой XML RPC, sgconfig и прочих утилит, схемы данных. Могу попытаться реализовать, если меня немного финансово простимулировать. Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2013-03-07 04:51:04 Share Опубликовано: 2013-03-07 04:51:04 (изменено) да не, это слишком серьёзно =) проблема с пересечением 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 Опубликовано: 2013-03-07 05:02:31 Автор Share Опубликовано: 2013-03-07 05:02:31 Надо для VPN раздавать адреса из другой подсети, отличной от той, в которую входят IP пользователей, которые они помнят. Как вариант, указывать в конфигураторе для пользователя два разных IP (через запятую, вроде). purestg2 всегда выдает первый IP из списка, а inetaccess может авторизоваться с любого из перечисленных. Тогда если клиент впишет на сетевуху свой старый IP, который он помнит, а потом подключится через VPN, то конфликта адресов не будет, т.к. VPN-интерфейс получит другой IP. Конечно, пользователь может подсмотреть тот IP, который ему присвоили для VPN и вписать потом его же на сетевуху, но зачем ему это делать? Но даже если он так сделает, то VPN-ский IP будет из другой подсети, и локалка с ним у него вообще не будет работать. Следовательно, и у сервера с мозгами все будет в порядке - VPN-ский адрес на сетевухе клиента ему будет просто недоступен, как будто и нет его вовсе. Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2013-03-07 05:12:33 Share Опубликовано: 2013-03-07 05:12:33 (изменено) вариант со вторым айпи в учётке заинтересовал то есть прописываем первым адресом айпи для VPN, вторым локальный, правильно? получится он сможет авторизоваться через авторизатор по локальному адресу, а через туннель будет выдаваться первый Алексей спасибо, мне кажется это наилучший вариант Изменено 2013-03-07 05:16:09 пользователем yKpon Ссылка на сообщение Поделиться на других сайтах
Alexey Osipov 38 Опубликовано: 2013-03-08 10:29:22 Автор Share Опубликовано: 2013-03-08 10:29:22 то есть прописываем первым адресом айпи для VPN, вторым локальный, правильно? получится он сможет авторизоваться через авторизатор по локальному адресу, а через туннель будет выдаваться первый Да, теоретически так. Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2013-03-10 09:03:11 Share Опубликовано: 2013-03-10 09:03:11 (изменено) обнаружил 2 проблемы через PPPoE 1. выставил pppdtimeout = 30 и сессии начали подключаться и отваливаться и так по кругу, поставил 60 стало ровно, логи уже потёр, в принципе не критично, оставлю 60 2. после рестарта биллинга не переподключаются абоненты у которых авторизация на машине под маздай, в настройках подключения выставлено автоматическое переподключение через 1 секунду и бесконечное число попыток с роутерами такой проблемы нет сейчас одна железа ubiquiti отвалилась, ppp туннель упал, в stg статус online, авторизоваться не может пока выставил kickprevious, но думаю это временное решение Изменено 2013-03-10 15:50:51 пользователем yKpon Ссылка на сообщение Поделиться на других сайтах
Alexey Osipov 38 Опубликовано: 2013-03-11 05:21:05 Автор Share Опубликовано: 2013-03-11 05:21:05 обнаружил 2 проблемы через PPPoE 1. выставил pppdtimeout = 30 и сессии начали подключаться и отваливаться и так по кругу, поставил 60 стало ровно, логи уже потёр, в принципе не критично, оставлю 60 С опцией stg-плагина 'pppdtimeout' тесно связана опция pppd-плагина 'keepalivetimeout'. 'keepalivetimeout' определяет интервал, с которым плагин pppd пингует плагин stg. Естественно, если этот интервал будет больше, чем pppdtimeout, старгейзер будет сбрасывать соединение, подумав, что pppd умер. 2. после рестарта биллинга не переподключаются абоненты у которых авторизация на машине под маздай, в настройках подключения выставлено автоматическое переподключение через 1 секунду и бесконечное число попыток "не переподключаются" - слишком пространно. Как это конкретно выглядит на машине клиента? Как это конкретно выглдяит в логах pppd? Старгейзера? Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубликовано: 2013-03-11 13:04:50 Share Опубликовано: 2013-03-11 13:04:50 (изменено) с виндой ладно, но 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 Опубликовано: 2013-03-11 17:39:08 Автор Share Опубликовано: 2013-03-11 17:39:08 в логах вто что поймал 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 Опубликовано: 2013-03-11 18:37:03 Share Опубликовано: 2013-03-11 18:37:03 (изменено) нет это лог при выключенном 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 Опубликовано: 2013-03-12 02:09:19 Автор Share Опубликовано: 2013-03-12 02:09:19 Нормальные логи. В 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, авторизоваться не может". Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВойти
Уже зарегистрированы? Войдите здесь.
Войти сейчас