- Доступ в инет.,
 Аноним, 16:14 , 17-Июн-19 (1)> Здравствуйте всем!
> Есть ~500 пользователей, которым нужно дать доступ в инет по логин/пароль. Компов
> около 300.
> Трафик считать не надо, только давать доступ / не давать.
> Есть ли что-то более-менее готовое на *nix системах?
> Может билингом каким бесплатным можно, посоветуйте.билинг ))))
достаточно будит прокси либо сквида либо 3прокси!
- Доступ в инет., Pofigist, 16:57 , 17-Июн-19 (2)
> Здравствуйте всем!
> Есть ~500 пользователей, которым нужно дать доступ в инет по логин/пароль. Компов
> около 300.
> Трафик считать не надо, только давать доступ / не давать.
> Есть ли что-то более-менее готовое на *nix системах?
> Может билингом каким бесплатным можно, посоветуйте.pfsense
- Доступ в инет., Ajavrik, 18:20 , 17-Июн-19 (3)
>> Здравствуйте всем!
>> Есть ~500 пользователей, которым нужно дать доступ в инет по логин/пароль. Компов
>> около 300.
>> Трафик считать не надо, только давать доступ / не давать.
>> Есть ли что-то более-менее готовое на *nix системах?
>> Может билингом каким бесплатным можно, посоветуйте.
> pfsense Да вспомнил про pfsense, когда-то давно его щупал, спасибо, посмотрю.
А вот прокси не прокатит, людям и VPN иногда нужен и что-либо экзотическое.
- Доступ в инет., Pofigist, 19:30 , 17-Июн-19 (4)
- Доступ в инет., Pofigist, 19:31 , 17-Июн-19 (5) –3
> А вот прокси не прокатит, людям и VPN иногда нужен и что-либо
> экзотическое.Прокси для таких целей это прошлый век. Просто кто-то в криокамере не заметил что кончается 2е десятилетие 21-го века :)
- Доступ в инет., Аноним, 10:43 , 18-Июн-19 (6) –1
> Прокси для таких целей это прошлый век. прокси для таких целей - это еще и оборонительный рубеж от атак снаружи и крыс внутри, так что курилка и в будущем веке послужит...
- Доступ в инет., Pofigist, 10:56 , 18-Июн-19 (7) –3
Я вижу глубокое непонимание значения термина proxy - использовать ее в качестве оборонительного рубежа это не самое умное решение.
- Доступ в инет., Аноним, 11:47 , 18-Июн-19 (8)
> Я вижу глубокое непонимание значения термина proxy - использовать ее в качестве
> оборонительного рубежа это не самое умное решение.Я вижу глубокое непонимание значения выражения "еще и".
Вижу непоколебимую веру в существовании только двух мнений - твоего и неправильного.
Здоровья те, бро. Пригодится в жизни.
- Доступ в инет., ыы, 12:44 , 18-Июн-19 (9) –4 [V]
>> Я вижу глубокое непонимание значения термина proxy - использовать ее в качестве
>> оборонительного рубежа это не самое умное решение.
> Я вижу глубокое непонимание значения выражения "еще и".
> Вижу непоколебимую веру в существовании только двух мнений - твоего и неправильного.
> Здоровья те, бро. Пригодится в жизни.Я вижу глубокое непонимание значения термина "оборонительный рубеж". Либо он ("оборонительный рубеж", хотя правильно он называется "периметр безопасности") у вас есть, и "еще и" - пятая нога собаке, скорее мешающая и создающая потенциальне лазейки чем от чего-то обороняющая, либо у вас есть только "еще и" - то есть периметра безопасности у вас НЕТ.
- Доступ в инет., Аноним, 12:59 , 18-Июн-19 (10)
> Я вижу глубокое непонимание значения термина "оборонительный рубеж". Либо он ("оборонительный Я вижу еще одного камрада с глубокими теоретическими... или терминологическими?.. знаниями...
Продолжайте держать нас в курсе, ваше мнение очень важно для нас...
- Доступ в инет., ыы, 13:08 , 18-Июн-19 (11) –2
>> Я вижу глубокое непонимание значения термина "оборонительный рубеж". Либо он ("оборонительный
> Я вижу еще одного камрада с глубокими теоретическими... или терминологическими?.. знаниями...
> Продолжайте держать нас в курсе, ваше мнение очень важно для нас...А ваше для меня - извините нет.
- Доступ в инет., Аноним, 13:23 , 18-Июн-19 (14)
>>> Я вижу глубокое непонимание значения термина "оборонительный рубеж". Либо он ("оборонительный
>> Я вижу еще одного камрада с глубокими теоретическими... или терминологическими?.. знаниями...
>> Продолжайте держать нас в курсе, ваше мнение очень важно для нас...
> А ваше для меня - извините нет.И те здоровья, бро
- Доступ в инет., Аноним, 13:18 , 18-Июн-19 (12)
> Я вижу глубокое непонимание значения термина "оборонительный рубеж". Либо он ("оборонительный
> рубеж", хотя правильно он называется "периметр безопасности") у вас есть, и
> "еще и" - пятая нога собаке, скорее мешающая и создающая потенциальне
> лазейки чем от чего-то обороняющая, либо у вас есть только
> "еще и" - то есть периметра безопасности у вас НЕТ.Совершенно безосновательное заявление... Межсетевые экраны экспертного уровня сочетают в себе элементы пакетного фильтра, сеансового шлюза и фильтра прикладного уровня.
И если не хватает средств на решения Cisco, где это реализуется в рамках одной железки, никто не запрещает использовать иные конструкции защитного периметра, состоящего из тех же элементов. В том числе, "еще и" прокси-сервера.
- Доступ в инет., ыы, 13:24 , 18-Июн-19 (15) –3
>[оверквотинг удален]
>> рубеж", хотя правильно он называется "периметр безопасности") у вас есть, и
>> "еще и" - пятая нога собаке, скорее мешающая и создающая потенциальне
>> лазейки чем от чего-то обороняющая, либо у вас есть только
>> "еще и" - то есть периметра безопасности у вас НЕТ.
> Совершенно безосновательное заявление...
> Межсетевые экраны экспертного уровня сочетают в себе элементы пакетного фильтра, сеансового
> шлюза и фильтра прикладного уровня.
> И если не хватает средств на решения Cisco, где это реализуется в
> рамках одной железки, никто не запрещает использовать иные конструкции защитного периметра,
> состоящего из тех же элементов. В том числе, "еще и" прокси-сервера. Вы, как и предыдущий Аноним, полагаете очевидно что периметр безопасности - это "Межсетевые экраны" в той или иной форме. То есть вот у вас есть ваша сеть, вот интернет - вот вы втыкаете между ними межсетевой экран- и вы сформировали периметр безопасности.. да? :)
- Доступ в инет., Аноним, 14:09 , 18-Июн-19 (18)
> То есть вот у вас есть ваша сеть, вот интернет - вот
> вы втыкаете между ними межсетевой экран- и вы сформировали периметр безопасности..
> да? :) Нет, это гораздо более обширный комплекс административно-технических мер. Включающий в себя помимо межсетевого экрана защиту данных, приложений, устройств, оборудования, каналов связи, рабочих мест, работу с персоналом, прогнозирование, etc... Однако в рамках рассматриваемого вопроса ваши словесные экзерсисы являются попыткой увести обсуждение в плоскость словоблудия, что лично мне совершенно неинтересно. P.S. Упомянутый выше pfsense, чье применение в рассматриваемом вопросе не вызвало у аудитории возражений, насколько я помню, также включает в себя прокси-сервер.
- Доступ в инет., ыы, 14:25 , 18-Июн-19 (20)
>> То есть вот у вас есть ваша сеть, вот интернет - вот
>> вы втыкаете между ними межсетевой экран- и вы сформировали периметр безопасности..
>> да? :)
> Нет, это гораздо более обширный комплекс административно-технических мер. Включающий
> в себя помимо межсетевого экрана защиту данных, приложений, устройств, оборудования, каналов
> связи, рабочих мест, работу с персоналом, прогнозирование, etc... Уже что-то... И так. Вот у вас есть межсетевой экран, пусть это будет чекпоинт, у вас есть файрвол приложений, пусть.. от позитив технолоджи... у вас есть политики устройств, оборудования, каналов
связи, рабочих мест, политики работы с персоналом, прогнозирование, etc. И тут появляется человек с идеей "еще и". Пусть это будет ваш начальник. и говорит
"- а давайте заменим все это проксей она ведь "ЕЩЕ И" безопасность нам поднимет." Ваша реакция как специалиста?
> Однако в рамках рассматриваемого вопроса
Вот что отнесли в периметру безопасности Вы:
> "межсетевого экрана защиту данных, приложений, устройств, оборудования, каналов связи, рабочих мест, работу с персоналом, прогнозирование, etc... " Вот что отнес к периметру безопасности неуважаемый аноним которому я возразил: >"еще и"
> ваши словесные экзерсисы являются попыткой увести обсуждение
> в плоскость словоблудия, что лично мне совершенно неинтересно. Вам должно быть стыдно
- Доступ в инет., Аноним, 14:42 , 18-Июн-19 (21)
> Вам должно быть стыдно за твое словоблудие?
- Доступ в инет., ыы, 14:49 , 18-Июн-19 (22) –3
>> Вам должно быть стыдно
> за твое словоблудие?Желаю Вам создавать периметры безопасности из проксей :)
- Доступ в инет., Pofigist, 13:19 , 18-Июн-19 (13) –1
Еще раз - в любом варианте прокси это прошлый век. Сейчас как бы достаточно много нормальных инструментов, и этот костыль - не нужен.
- Доступ в инет., Аноним, 13:26 , 18-Июн-19 (16)
> Еще раз - в любом варианте прокси это прошлый век. Сейчас как
> бы достаточно много нормальных инструментов, и этот костыль - не нужен. Хорошо, хорошо, не волнуйся ты так... - Доступ в инет., Pahanivo, 09:50 , 24-Июн-19 (25)
> Еще раз - в любом варианте прокси это прошлый век. Сейчас как
> бы достаточно много нормальных инструментов, и этот костыль - не нужен. Простите христа ради динозавра, подскажите, какие такие чудотворные инструменты нонче заменяют функционал прокси?
- Доступ в инет., Pofigist, 10:30 , 24-Июн-19 (27) –3
Хорошо, поставим вопрос иначе - что вы относите к функционалу прокси? А тут на нее взвалии и функции фаервола, ната, дпи и черта лысого...
- Доступ в инет., Аноним, 10:51 , 24-Июн-19 (28) +2
> тут на нее взвалии и функции фаервола, ната, дпи и черта
> лысого...Товарищ Пассажир, не надо так нахально передергивать, люди ж смотрят...
- Доступ в инет., Azudim, 13:59 , 18-Июн-19 (17)
> Есть ~500 пользователей, которым нужно дать доступ в инет по логин/пароль. Компов
> около 300.
> Трафик считать не надо, только давать доступ / не давать.
> Есть ли что-то более-менее готовое на *nix системах?
> Может билингом каким бесплатным можно, посоветуйте.Удобно использовать биллинг Abills. Подключение пользователей или PPPoE с автризацией по логину/паролю или учет по IP, если есть привязка к пользователю. PPPoE моментально подключается (можно прозрачно для пользователя в Win10), минимальные накладные расходы на канал. Основа биллинга - связка NAS + Radius + Логика биллинга.
NAS - может быть железка (Cisco, Mikrotik), а может линуксовый/BSD сервер, или в комбинации. Через NAS идет трафик от пользователя, после авторизации/aутентификации, и впроцессе аккаунтинг (подсчет). Radius - выдает на NAS резрешения и собирает с него статистику В Биллинге (Web интерфейс) заводятся пользователи, тарифы, указываются NASы Работаем с ним лет 15 уже. FreeBSD + MPD + Freeradius
- Доступ в инет., Ajavrik, 14:11 , 18-Июн-19 (19)
Спасибо!
Слышал про него, буду смотреть.>[оверквотинг удален]
> по логину/паролю или учет по IP, если есть привязка к пользователю.
> PPPoE моментально подключается (можно прозрачно для пользователя в Win10), минимальные
> накладные расходы на канал.
> Основа биллинга - связка NAS + Radius + Логика биллинга.
> NAS - может быть железка (Cisco, Mikrotik), а может линуксовый/BSD сервер, или
> в комбинации. Через NAS идет трафик от пользователя, после авторизации/aутентификации,
> и впроцессе аккаунтинг (подсчет).
> Radius - выдает на NAS резрешения и собирает с него статистику
> В Биллинге (Web интерфейс) заводятся пользователи, тарифы, указываются NASы
> Работаем с ним лет 15 уже. FreeBSD + MPD + Freeradius
- Доступ в инет., NetEye, 02:56 , 24-Июн-19 (23)
Если стоит задача по критерию "дать доступ в сеть N станциям по login / пароль, трафик станций не считать", то не вижу никаких проблем в использовании связки squid / squid helper на авторизацию / delay pools по вкусу. Если станции в домене AD то используется авторизация kerberos от AD и пользователь в этом плане прозрачно выходит в сеть, один раз авторизовашись в AD. Если платформы AD нет, то тут каждый сам себе велосипед - можно городить тот же сервис AAA в стиле free IPA и к ней прикручивать SQUID, либо класть логины / пароли в какую либо базы типа mysql и авторизоваться через БД.Это если искомая задача - "дать доступ и не делать аудит пользователя". Городить ради этого "биллинг" с тарифами , радиусом и пр. фантиками - НА - КУ - А ?
У вас задача делать аудит пользователей, играться "в провайдера" - или выпустить народ в сеть и обеспечить им минимальный уровень сервиса для серфинга сети? Вы уж определитесь. Если желаете прикрутить к сквиду отчеты о том , кто куда ходил - то мануалов по этому вопросу вагон и телега. При чем тут периметр сети и сетевые экраны - несколько непонятно - т.к. это другая задача.
Сам по себе железный firewal от cisco / jun / etc даст вам точку выхода в сеть + NAT. И более ничего.
Всё остальное - за $ к тому ПО, которое вам нужно будет отдать той же cisco. Да, на продуктах cisco можно построить "красиво" в плане авторизации / контроля / мониторинга - только один простой вопрос - денег то хватит ? Ну и тот же pfsence - тот же squid в комбайне для тех, кто хочет рулить этим всем мышкой. И как всякий комбайн такое решение имеет свои недостатки. Когда денег на cisco нет. Но очень хочется.... =А вот прокси не прокатит, людям и VPN иногда нужен и что-либо экзотическое.= "доступ извне к сети" и "доступ из локальной сети в инет" - это несколько разные задачи. Смешивать их в "одном флаконе" - это как ходить с расстёгнутой ширинкой. Ходить можно. Только люди будут смотреть и делать выводы. Если на выходе в сеть стоит ASA - то крутим cisco any connect.
Если асы нет - поднимаем все что душе угодно - openvpn/freeradius/daloradius/etc.
Это если вопрос безопасности имеет место быть.
А если банальная лень - то pfsence + далее мышкой клац-клац.
- Доступ в инет., Ajavrik, 09:20 , 24-Июн-19 (24)
Да, решений, конечно, масса. Вы описали много способов, можно просто заказать уже готовое что-то еще придумать. Если Вы отвечаете всем сразу, то да можно и так, но у меня вопрос был построение на *NIX системе и максимальный уровень доступа, я с этим определился давно. Мне достаточно было написать одну строчку - последнюю.
Спасибо!
>[оверквотинг удален]
> экзотическое.=
> "доступ извне к сети" и "доступ из локальной сети в инет" -
> это несколько разные задачи. Смешивать их в "одном флаконе" - это
> как ходить с расстёгнутой ширинкой. Ходить можно. Только люди будут смотреть
> и делать выводы.
> Если на выходе в сеть стоит ASA - то крутим cisco any
> connect.
> Если асы нет - поднимаем все что душе угодно - openvpn/freeradius/daloradius/etc.
> Это если вопрос безопасности имеет место быть.
> А если банальная лень - то pfsence + далее мышкой клац-клац.
- Доступ в инет., Azudim, 12:13 , 24-Июн-19 (29)
> Если стоит задача по критерию "дать доступ в сеть N станциям по
> login / пароль, трафик станций не считать", то не вижу
> никаких проблем в использовании связки squid / squid helper на авторизацию
> / delay pools по вкусу. Простите, давно не трогал Squid, это же прокси-сервер? А как у него дела с проксирвоанием торрентов, gre, нестандартных портов для какого ни будь steam'a ?
- Доступ в инет., Аноним, 12:52 , 24-Июн-19 (30)
> Простите, давно не трогал Squid, это же прокси-сервер? А как у него
> дела с проксирвоанием торрентов, gre, нестандартных портов для какого ни будь
> steam'a ?Никак. Это почти исключительно http(s) proxy. Поэтому заменить squid'ом все остальное не получится.
Но как часть системы - вполне годная вещь. Например, основное стадо хомячков, которым только вконтактик с педивикией нужен выпускаем через него, попутно запретив шастать по порносайтам; до кучи digest-аутентификацию поднять - и вообще ничего, кроме браузеров в инет не попадает, но это по вкусу. Более продвинутым делаем проброс портов либо выпускаем через vpn... ну и т.д.
- Доступ в инет., NetEye, 12:54 , 24-Июн-19 (31)
> Squid, это же прокси-сервер?Да. > А как у него дела с проксирвоанием торрентов, gre, нестандартных портов для какого ни будь steam'a ? Немного более, чем никак, хотя в сети подскажут как использовать torrent client over squid proxy. Но это костыли. Имхо , торренты лучше выносить в отдельную точку обмена трафиком через свой ретрекер, полоса у которого контролируется вами , нежели иметь счастье разгребать весь трафик в сквиде. Все это делается а уровне граничного firewall-a. Вообще, там , где начинается "нестандартность" а-ля "стим в корп. сети", там кончается безопасность.
- Доступ в инет., Ajavrik, 00:15 , 28-Июн-19 (32)
Остановился на pfsense с PPPoE на одном сервере.
А никто не может сказать как подсчитать количество пользователей PPPoE на один сервер.
У меня их около 300, могу их всех повесить на какую-нибудь мать с 16 Гигами памяти?
- Доступ в инет., Аноним, 16:35 , 29-Июн-19 (33)
> их около 300, могу их всех повеситьВешайте, вешайте..
- Доступ в инет., fantom, 10:39 , 08-Июл-19 (34)
> Остановился на pfsense с PPPoE на одном сервере.
> А никто не может сказать как подсчитать количество пользователей PPPoE на один
> сервер.
> У меня их около 300, могу их всех повесить на какую-нибудь мать
> с 16 Гигами памяти?Можете и с 1 гигом, вопрос не в количестве пользователей, а в количестве трансляций, скорости образования новых трансляций и общем ППС.
- Доступ в инет., Ajavrik, 10:44 , 08-Июл-19 (35)
>> Остановился на pfsense с PPPoE на одном сервере.
>> А никто не может сказать как подсчитать количество пользователей PPPoE на один
>> сервер.
>> У меня их около 300, могу их всех повесить на какую-нибудь мать
>> с 16 Гигами памяти?
> Можете и с 1 гигом, вопрос не в количестве пользователей, а в
> количестве трансляций, скорости образования новых трансляций и общем ППС.Да, я не правильно задал вопрос.
Вопрос такой: смогут ли одновременно 300 пользователей работать через этот сервер?
- Доступ в инет., fantom, 10:32 , 10-Июл-19 (36)
>>> Остановился на pfsense с PPPoE на одном сервере.
>>> А никто не может сказать как подсчитать количество пользователей PPPoE на один
>>> сервер.
>>> У меня их около 300, могу их всех повесить на какую-нибудь мать
>>> с 16 Гигами памяти?
>> Можете и с 1 гигом, вопрос не в количестве пользователей, а в
>> количестве трансляций, скорости образования новых трансляций и общем ППС.
> Да, я не правильно задал вопрос.
> Вопрос такой: смогут ли одновременно 300 пользователей работать через этот сервер?Если ваш канал > 100G то нет, если < 100М то да.
- Доступ в инет., Ajavrik, 10:52 , 10-Июл-19 (37)
>>>> Остановился на pfsense с PPPoE на одном сервере.
>>>> А никто не может сказать как подсчитать количество пользователей PPPoE на один
>>>> сервер.
>>>> У меня их около 300, могу их всех повесить на какую-нибудь мать
>>>> с 16 Гигами памяти?
>>> Можете и с 1 гигом, вопрос не в количестве пользователей, а в
>>> количестве трансляций, скорости образования новых трансляций и общем ППС.
>> Да, я не правильно задал вопрос.
>> Вопрос такой: смогут ли одновременно 300 пользователей работать через этот сервер?
> Если ваш канал > 100G то нет, если < 100М то да. Черт, опять не получил ответ. У меня канал не больше не меньше а ровно 100 Мб :)
А если серьезно, то я так понимаю Вы имеете ввиду что будет большая нагрузка на канал?
Ну одновременно все 300 врятли полезут. Волнует то, что 300 человек подсоединятся и образуют 300 интерфейсов. На что это повлияет?
- Доступ в инет., fantom, 15:13 , 11-Июл-19 (38)
>[оверквотинг удален]
>>>> количестве трансляций, скорости образования новых трансляций и общем ППС.
>>> Да, я не правильно задал вопрос.
>>> Вопрос такой: смогут ли одновременно 300 пользователей работать через этот сервер?
>> Если ваш канал > 100G то нет, если < 100М то да.
> Черт, опять не получил ответ. У меня канал не больше не меньше
> а ровно 100 Мб :)
> А если серьезно, то я так понимаю Вы имеете ввиду что будет
> большая нагрузка на канал?
> Ну одновременно все 300 врятли полезут. Волнует то, что 300 человек подсоединятся
> и образуют 300 интерфейсов. На что это повлияет?300 PPPoE интерфейсов лично у меня "тянул" AMD Athlon 1700Mhz, RAM 768Mb при скорости канала 50Мбит....
Тупо по количеству интерфейсов - там и 3000 можно было создать :) Небольшой ликбез для вас:
Каждое обращение к какому-либо ресурсу (ну пусть страничка в инете) - это вседнем от 3-4 до 10-15 трансляций, специальных записей в специальной таблице вашего сервера, без которой все это работать просто не будет.
У подавляющего большинства современных домашних бюджетных мыльниц-роутеров это значение 16000-64000, на линуксах зачастую по умолчанию сия таблица тоже 64000, НО оный размер легко и просто увеличивается. Второй момент - это ППС - ПакетПерСекунда, т.е. пакетов в секунду.
Маршрутизатор может совершенно спокойно обрабатывать 1Гиг/сек при размере пакета 9КБайт и "захлебнуться" при 50М/сек при размере пакета 48Байт... поэтому понормальному производительность у маршрутизаторов меряют НЕ в мегабитах-гигабитах, а в мегапакетах!! потолок 100М интерфейса - 144000 пакетов в секунду, с этим справиться даже celeron 847, 16Гигов памяти для описанных вами задач избыточно.
- Доступ в инет., Ajavrik, 15:34 , 11-Июл-19 (39)
>[оверквотинг удален]
> вашего сервера, без которой все это работать просто не будет.
> У подавляющего большинства современных домашних бюджетных мыльниц-роутеров это значение
> 16000-64000, на линуксах зачастую по умолчанию сия таблица тоже 64000, НО
> оный размер легко и просто увеличивается.
> Второй момент - это ППС - ПакетПерСекунда, т.е. пакетов в секунду.
> Маршрутизатор может совершенно спокойно обрабатывать 1Гиг/сек при размере пакета 9КБайт
> и "захлебнуться" при 50М/сек при размере пакета 48Байт... поэтому понормальному
> производительность у маршрутизаторов меряют НЕ в мегабитах-гигабитах, а в мегапакетах!!
> потолок 100М интерфейса - 144000 пакетов в секунду, с этим справиться даже
> celeron 847, 16Гигов памяти для описанных вами задач избыточно.Спасибо за ликбез. Я никогда не подсчитывал таких параметров.
Сейчас у меня эти 300-350 пользователей работают через маршрутизатор на FreeBSD 7.2, железо
CPU: Intel(R) Celeron(R) CPU E1400 @ 2.00GHz (1999.96-MHz 686-class CPU)
real memory = 2146304000 (2046 MB) канал в 100 Мб, статистика считается по ipcad самописными скриптами. Пока делал сам все ничего, а сейчас надо передать другим, вот и решил перейти на pfsense. По вебморде проще клацать.
Всё меня интересующее выяснил, всем спасибо!
|
Версия для распечатки
Доступ в инет., 
