Группы насов с разными полями CID

[NiTr0]

Постепенно переходим с PPTP на PPPoE - собссно стал актуальным вопрос по поводу нескольких полей CID у одного юзера (как минимум - 2 группы насов, одно поле - для PPTP IP, другое - для PPPoE MAC).

Пока что это мне видится как опция "тип" в свойствах наса, и 2 поля CID у пользователя. Хотя 2й вариант - просто несколько полей CID либо в одном поле через разделитель несколько CID (хотя тогда с автозаполнением и прочими фичами хуже ситуация; разве что 2 поля: одно - основной CID, теперишний, и 2е - список дополнительных) - проще, с одной стороны - удобнее (можно несколько IP/MAC делать), с другой - есть кое-какие минусы.

Интересует стоимость и время данной доработки.

P.S. Кстати, попутно с этим пришла в голову идея, что неплохо было бы не глобальный флаг сохранения MAC юзать, а сделать флажок у каждого юзера (сохранять CID при коннекте). А его дефолтное значение, которое ставится при активации пакета (или лучше значения - для автозаполнения MAC и для автозаполнения не-MAC CID) уже хранить в конфиге... Хотя это - скорее пожелание, чем необходимость.

[ran]

я пока мыслю так:

1. имеется 2! базы: 1 - локалка, 2 - инет... имеется нас который по пппое пускает в локалку если есть положительный баланс 1-й базы если нет то только на личный кабинет

на инет - каптив портал авторизация (с радиусом разумеется через 2-ю базу с уже авторизованных ифейсоф/ип п.1

щаз отлаживаю... nas - pfsenese... я уже было начинал с ним работы потом разочаровался (я линухоид всёж ) терь продолжил потому как заказчик хороший есть в рот ему ноги

ну и себе попутно... и людям

[~AsmodeuS~]

Постепенно переходим с PPTP на PPPoE - собссно стал актуальным вопрос по поводу нескольких полей CID у одного юзера (как минимум - 2 группы насов, одно поле - для PPTP IP, другое - для PPPoE MAC).

Пока что это мне видится как опция "тип" в свойствах наса, и 2 поля CID у пользователя. Хотя 2й вариант - просто несколько полей CID либо в одном поле через разделитель несколько CID (хотя тогда с автозаполнением и прочими фичами хуже ситуация; разве что 2 поля: одно - основной CID, теперишний, и 2е - список дополнительных) - проще, с одной стороны - удобнее (можно несколько IP/MAC делать), с другой - есть кое-какие минусы.

через разделитель 20 $

автозаполнение тогда по первому признаку, дальше руками

[NiTr0]

я пока мыслю так:

Гнать весь траф по туннелю - ИМХО не есть гуд. Пока что - это только для доступа к инету, вместо пптп (бонус - нет проблем с резервированием серверов), а полный контроль над клиентским траффиком - будем вланами разруливать в перспективе. Обучить китайские абонентские мыльницы RRCP - проблемы не составит, а вот над написанием скрипта по управлению ними, и в первую очередь над организациолнными мероприятиями - прийдется подумать...

через разделитель 20 $

автозаполнение тогда по первому признаку, дальше руками

А если все же сделать еще одно поле дополнительных CID, где будет список через разделитель? ИМХО - меньше текущую логику биллинга прийдется править, да и в конфиге можно включать/отключать данную фичу...

[ran]

Гнать весь траф по туннелю - ИМХО не есть гуд.

почему? пппое прекрасно справляется...

полный контроль над клиентским траффиком - будем вланами разруливать в перспективе

ну разумеется... пппое - эт костыль... нужны управляемые свичи и авторизация 802.1x... но поменять в городской сетке несколько сотен свичей за раз нереально - пэтому пока так... дела в том что например у меня в сетке нашлись умники раздающие левый инет в сетку... а нафига мне это щастье?

[NiTr0]

ну разумеется... пппое - эт костыль... нужны управляемые свичи и авторизация 802.1x... но поменять в городской сетке несколько сотен свичей за раз нереально - пэтому пока так...

Я же говорю - достаточно RRCP железок + vlan на каждого юзера.

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

Такие умники неплохо отсеиваются при сегментации сети на мелкие подсети, машин по 30 - можно спокойно траф фильтровать/анализировать... Да и смотря как раздают - если через ВПН и иже с ним - по TTL легко претенденты определяются, прокси - сканирование портов и X-Forwarded-From... Ну и в комплексе со средней загрузкой канала...
Ессно если человек поднял линуксовый тазик, подтюнил сквид, прикрыл порты от окружающих - обнаружить его очень сложно... Но таких будут единицы (если вообще будут).
Ну а оргмеры - от показательной порки до ненавязчивого предложения покупать инет для продажи у конкурентов (если его услугами пользуются в основном "качки", которые в режиме 24/7 забивают весь канал)

[ran]

Я же говорю - достаточно RRCP железок + vlan на каждого юзера.

ну дык а я о чём? каждый усер в своём вилане и все виланы сходятся на насах... следствие - нада менять все мыльницы... а способ аутентификации не суть важен - просто 802.1х мне больше по вкусу

Такие умники неплохо отсеиваются при сегментации сети на мелкие подсети, машин по 30 - можно спокойно траф фильтровать/анализировать... Да и смотря как раздают - если через ВПН и иже с ним - по TTL легко претенденты определяются, прокси - сканирование портов и X-Forwarded-From... Ну и в комплексе со средней загрузкой канала...
Ессно если человек поднял линуксовый тазик, подтюнил сквид, прикрыл порты от окружающих - обнаружить его очень сложно... Но таких будут единицы (если вообще будут).
Ну а оргмеры - от показательной порки до ненавязчивого предложения покупать инет для продажи у конкурентов (если его услугами пользуются в основном "качки", которые в режиме 24/7 забивают весь канал)

ну и нафиг мне этот гемор? пппое + бан сети 0/0 ипсентинелом гораздо проще не панацея канешна... но

таких будут единицы (если вообще будут)

[NiTr0]

ну дык а я о чём? каждый усер в своём вилане и все виланы сходятся на насах... следствие - нада менять все мыльницы... а способ аутентификации не суть важен - просто 802.1х мне больше по вкусу

16-портовые мыльницы в основной массе менять не прийдется (большинство из них на RTL8316B) - достаточно еепромку впаять

ну и нафиг мне этот гемор? пппое + бан сети 0/0 ипсентинелом гораздо проще не панацея канешна... но

таких будут единицы (если вообще будут)

А что, траффик юзер-юзер получается прикрытым? или как тогда фильтровать тех, кто оплатил мин. пакет и пользуется соседским инетом через то же пппое халявно? не говоря уже о том, что внутри подсети юзвери могут легко поднять дополнительный ИП и организовать большую локальную сеть - если локалка не сегментирована

[Abram]

16-портовые мыльницы в основной массе менять не прийдется (большинство из них на RTL8316B) - достаточно еепромку впаять

Ану-ка поподробнее?..

[ran]

А что, траффик юзер-юзер получается прикрытым?

не прикрытым а подконтрольным на насе... а уж что разрешать а что нет - ограничивается только фантазией и пряморукостью админа

внутри подсети юзвери могут легко поднять дополнительный ИП и организовать большую локальную сеть - если локалка не сегментирована

пппое + бан сети 0/0 ипсентинелом

ну и пусть себе назначают... точнее пытаются - потому как будут при этом получать на любой ип "этот ип уже используется в сети" и как результат не работающий стек тсп/ип на изернете и выход у них будет 1 - отключить с изернета протокол тсп/ип нафиг... я уже писал что это не панацея - существуют другие протоколы ipx например которы забанить сложнее, да и статику арпа никто не отменял... но опять же до такого додумаются единицы...

Ану-ка поподробнее?..

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

[NiTr0]

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

Нет, вланы с конфигом в еепром поддерживают все свичи. А вот управление по сети, пускай даже на L1, без дополнительного "мозга" - только реалтеки 16/24-портовые. И то не все.
Советую заглянуть на http://openrrcp.org.ru/

[ran]

Советую заглянуть

да был я там... правда давно уже... и понял одно - сидеть с паяльником и вправлять мозги мыльницам лично я не буду (не по причине криворукости а по причине отсутствия здоровья)... нанимать для этого кого-то - выйдет дорое полноценных 8-портовых управляемых свичей за 80 уёв с виланами, 802.1х, встроенным шейпером и грозозащитой на каждом порту (грозу лично тестировал - РАБОТАЕТ)

[NiTr0]

Так имеем 16 портов - т.е. эквивалент 2х свичей по 80 у.е. - при цене 16-портового свича 40 у.е. + максимум 5 у.е. на чип и за работу какому-то студенту - можно и помучиться со скриптом, который бы этим всем хозяйством умно рулил...

[ran]

угу... если ты мне найдёшь студента который по 5 баков за чип всё это прикрутит

Возможности

- 8-м RJ-45 TX портов 10/100 Mbps Full/Half duplex c автоопределением скорости и функцией Auto-MDIX.
- Локальное управление через консоль и удалённое через SNMP/Http/Telnet.
- Функции контроля потока IEEE802.3X для предотвращения потери пакетов
- Поддержка на каждом порту 4 очереди приоритезации для QoS приложений
- Поддержка 802.1Q VLAN
- Поддержка доступа к портам по статическим MAC адресам.
- Управление скоростью на портах (“шейпинг”) раздельно для входящего/исходящего трафика (от 0 до 2Mbps с шагом 64Kbps, от 2Mbps до 100Mbps с шагом 1Mbps)
- Низкое энергопотребление (до 10Вт), отсутствие вентилятора.
- Возможность удаленного конфигурирования портов и мониторинга состояния (в т.ч. SNMP)
- Поддержка IEEE 802.1x Port Security
- Поддержка IP Multicast с функцией “IGMP snooping”

Коммутатор имеет встроенную защиту Ethernet-портов от импульсов высокого напряжения. Защита выполнена двухступенчатой.
Ее первая ступень обеспечивает защиту каналов до трансформаторов линии. Уровень срабатывания первой ступени защиты составляет 250В, максимальный ток 6А, время срабатывания 10мкС.
Вторая ступень дополняет действие первой и защищает непосредственно вход/выход Ethernet-контроллеров коммутатора от действия остаточного перенапряжения при его возможном проникновении через трансформаторы линии. Уровень срабатывания второй ступени защиты составляет 3,6В, максимальный ток 140 мА.
Защита испытана путем подачи импульсов высокого напряжения (16-18 кВ) непосредственно в порты работающего изделия в режиме прохождения пинга. При этом происходило кратковременное нарушение связи (потеря одного или нескольких пакетов), после чего работоспособность канала восстанавливалась. Обязательным условием успешного функционирования защиты, при нарушении которого изделие выйдет из строя - является надежное заземление корпуса коммутатора или заземляющего проводника для бескорпусного варианта исполнения!

то я его мало что на работу возьму так тебе ещё комиссионные отстегну )))))))))

[NiTr0]

Шейпинг - есть, хоть и не в таких широких пределах (там несколько ступеней скорости, и нет отдельно на исходящий/входящий - хотя для локальной сети это некритично, тут разве что локалку резать), 802.1q вланы - есть, удаленное управление (при наличии в сегменте сети умной железки типа роутера с линуксом) - есть, статистика по портам (->>-) - есть, удаленное отключение порта (->>-) - есть. Разве что 802.1х и 802.3х нет, и нет жесткой привязки мака (но есть возможность отключить mac learning на порту - итого имеем привязку к первому маку, который свич увидел).

При этом цена за абонентский порт получается 3$ (15 портов + 1 магистраль), + 3-4$ грозозащита на порт. А цена управляемых свичей - порядка 12$ на абонентский порт. Т.е. - разница в 2 раза.