Автоматический Zap ALL

[~AsmodeuS~]

Вот мое видение проблемы и ее решения (на примере МПД)

проблема вроде как решена год с лишним назад (или больше? не помню, когда свой биллинг синкал с транком): если появляется еще одна сессия с тем же CID, ей назначается тот же ип, старая же сессия отправляется в зап.

совершенно верно

[l30l3]

Нашел - интересное решение.
В принципе все здорово, кроме случаев, когда злоумышленник подменит и логин и пароль и сид юзера. Тогда он сможет запнуть юзера и воспользоваться его инетом до тех пор пока юзер не запнет злоумышленника ) Это бывает редко и решается.

Еще так можно использовать одну учетку на двоих по очереди. Но только будучи в разных широковещательных доменах, - а это мало вероятно.

Только у меня это все не работает при значении "Одновременно" 1 в тарифе (или учетке).
Недавно обновлялся, вот вчера проверил. CID у меня МАС-адрес в формате 00:0c:29:19:8b:9d - может поэтому? Сами МАС-и в ошибке и в мониторинге совпадают.
Второе подключение отбивает с ошибкой "More then allow login (1/1) CID: 00:0c:29:19:8b:9d" , а первое продолжает висеть пока его не закроет billd.
Работает если значение "Одновременно" стоит 2 (и больше) - тогда после второго подключения система пускает третье с IP-адресом первого, а первое в ЗАП.
Это должно работать при значении "Одновременно" 1?

[l30l3]

Что проверяется по "$active_nas{ $line->[2] } eq $line->[0]" ?

[~AsmodeuS~]

Нашел - интересное решение.
В принципе все здорово, кроме случаев, когда злоумышленник подменит и логин и пароль и сид юзера. Тогда он сможет запнуть юзера и воспользоваться его инетом до тех пор пока юзер не запнет злоумышленника ) Это бывает редко и решается.

Еще так можно использовать одну учетку на двоих по очереди. Но только будучи в разных широковещательных доменах, - а это мало вероятно.

Только у меня это все не работает при значении "Одновременно" 1 в тарифе (или учетке).
Недавно обновлялся, вот вчера проверил. CID у меня МАС-адрес в формате 00:0c:29:19:8b:9d - может поэтому? Сами МАС-и в ошибке и в мониторинге совпадают.
Второе подключение отбивает с ошибкой "More then allow login (1/1) CID: 00:0c:29:19:8b:9d" , а первое продолжает висеть пока его не закроет billd.
Работает если значение "Одновременно" стоит 2 (и больше) - тогда после второго подключения система пускает третье с IP-адресом первого, а первое в ЗАП.
Это должно работать при значении "Одновременно" 1?

1 если они будут на одном сервер доступа им система выдаст один и тот же ип никто работать не будет

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

[NiTr0]

а зачем к слову ограничение по серверам доступа, особенно если типичная ситуация - пул из N серверов, работающих параллельно?

[l30l3]

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

Тоесть если один НАС выключить, то пользователи с него не смогут сразу подключиться к другому НАСу?

[~AsmodeuS~]

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

Тоесть если один НАС выключить, то пользователи с него не смогут сразу подключиться к другому НАСу?

если корректно выключить он должен корректно закрыть все сессии

[l30l3]

Интересует какраз ситуация если не корректно выключить.

[~AsmodeuS~]

Интересует какраз ситуация если не корректно выключить.

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

[l30l3]

Интересует какраз ситуация если не корректно выключить.

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

Так я об этом и говорю.
По дефолту сессии попадут в зап через 15 минут - как можно уменьшить это время без дополнительной нагрузки на сервера?

[~AsmodeuS~]

если сервер не умеет accounting on/off никак

[l30l3]

А что насчет этого?

Изначально дано, что в ЗАП таблицу могут попадать только сессии того НАСа, который потерял связь с нашим Радиусом. Про отдельных отвалившихся клиентов живой НАС сам расскажет Радиусу намного раньше, чем billd, и сессия закроется мимо ЗАП таблицы. Выходит мы рассматриваем ситуацию, когда недоступен НАС.
Если полагаться на механизм $conf{ERROR_ALIVE_COUNT}, то сессии будут попадать в ЗАП довольно долго (15 минут при Алайв 300 и $conf{ERROR_ALIVE_COUNT}=3)

Проблема же заключается в том, что на протяжении этих 15 минут пользователь не может подключиться не смотря на то, что у нас есть резервные НАСы.
Решение проблемы заключается в том, чтобы уменьшить до минимума время, за которое сессии попадут в зап таблицу, затрачивая на это минимум ресурсов.
Нам не нужно знать от каких пользователей не приходят алайв-пакеты, и не нужно анализировать логи.
Нужно знать, что Радиус потерял связь с НАСом, и какой это НАС. Зная это, мы можем сразу переносить все сессии этого наса в ЗАП таблицу, и пользователи смогут подключиться к резервному НАСу.

Проверка доступности НАСа любым способом (пинги, или удаленная проверка процеса, или еще что..) потянет меньше ресурсов, чем анализ алайвов каждого юзера или парсинг логов, и ее можно выполнять хоть каждую секунду. Если же НАС не отвечает в течении 5-10 секунд, скорее всего у нас проблема (линки до НАСов обычно стабильные) и можнать делать ЗАП.

Поправьте, я наверное чего-то не знаю.

accounting on/off это что?

[~AsmodeuS~]

А что насчет этого?

Изначально дано, что в ЗАП таблицу могут попадать только сессии того НАСа, который потерял связь с нашим Радиусом. Про отдельных отвалившихся клиентов живой НАС сам расскажет Радиусу намного раньше, чем billd, и сессия закроется мимо ЗАП таблицы. Выходит мы рассматриваем ситуацию, когда недоступен НАС.
Если полагаться на механизм $conf{ERROR_ALIVE_COUNT}, то сессии будут попадать в ЗАП довольно долго (15 минут при Алайв 300 и $conf{ERROR_ALIVE_COUNT}=3)

Проблема же заключается в том, что на протяжении этих 15 минут пользователь не может подключиться не смотря на то, что у нас есть резервные НАСы.
Решение проблемы заключается в том, чтобы уменьшить до минимума время, за которое сессии попадут в зап таблицу, затрачивая на это минимум ресурсов.
Нам не нужно знать от каких пользователей не приходят алайв-пакеты, и не нужно анализировать логи.
Нужно знать, что Радиус потерял связь с НАСом, и какой это НАС. Зная это, мы можем сразу переносить все сессии этого наса в ЗАП таблицу, и пользователи смогут подключиться к резервному НАСу.

Проверка доступности НАСа любым способом (пинги, или удаленная проверка процеса, или еще что..) потянет меньше ресурсов, чем анализ алайвов каждого юзера или парсинг логов, и ее можно выполнять хоть каждую секунду. Если же НАС не отвечает в течении 5-10 секунд, скорее всего у нас проблема (линки до НАСов обычно стабильные) и можнать делать ЗАП.

Поправьте, я наверное чего-то не знаю.

accounting on/off это что?

ну можете сделать на свой страх и риск такую схему или мы можем сделать как отдельную программу я например не вижу в ней смысла еще нужно продумывать

accounting on/off єто пакеты которые отправляются насом когда он включается и когда выключается (Cisco, Juniper, Ericson)

[Makioro]

Вот мое видение проблемы и ее решения (на примере МПД)

проблема вроде как решена год с лишним назад (или больше? не помню, когда свой биллинг синкал с транком): если появляется еще одна сессия с тем же CID, ей назначается тот же ип, старая же сессия отправляется в зап.

Странно, у нас не так всё работает. MPD5(РРТР)+freeradius2+abills. Многие клиенты в связи с малой производительностью роутеров с РРТР настраивают на роутерах статик айпи, а на компах за ним РРТР-соединение. Итого может быть несколько сессий от клиентов с одинаковым CID (у нас CID'ом служит IP) и все работают нормально.

з.ы. у меня такой вопрос. Почему некоторые сессии могут оставаться в абиллсе при том, что в мпд5 они давно отвалились? При этом куча сессий на этом же НАС-сервере нормально аккаунтятся.

[~AsmodeuS~]

Вот мое видение проблемы и ее решения (на примере МПД)

проблема вроде как решена год с лишним назад (или больше? не помню, когда свой биллинг синкал с транком): если появляется еще одна сессия с тем же CID, ей назначается тот же ип, старая же сессия отправляется в зап.

Странно, у нас не так всё работает. MPD5(РРТР)+freeradius2+abills. Многие клиенты в связи с малой производительностью роутеров с РРТР настраивают на роутерах статик айпи, а на компах за ним РРТР-соединение. Итого может быть несколько сессий от клиентов с одинаковым CID (у нас CID'ом служит IP) и все работают нормально.

з.ы. у меня такой вопрос. Почему некоторые сессии могут оставаться в абиллсе при том, что в мпд5 они давно отвалились? При этом куча сессий на этом же НАС-сервере нормально аккаунтятся.

потому что от нас сервера не приходят радиус пакеты