[AlKov]

Дано: сеть с ~2К вечерним он-лайн. В настоящий момент доступ полностью на PPTP с привязкой к MAC. IP, DNS, маршруты выдаются по DHCP. Есть своеобразная "локалка" в виде локального торрент-трекера.

После очередного "апгрейда тарифов", в полный рост встала проблема с клиентскими роутерами - загибаются уже на 6 Мбит/с.

Соответственно появилась необходимость в реконструкции сети в плане изменения типа доступа.

Сразу оговорюсь - IPoE не рассматривается однозначно, т.к. в сети уйма неуправляемого железа. Поэтому на данный момент вижу только одно решение - переходить на PPPoE, вернее даже не "переходить", а "вводить дополнительно", т.к по-любому сменить тип подключения ВСЕМ клиентам однозначно не получится. Соответственно придётся юзать и PPTP и PPPoE(на выбор).

В связи с этим возникает куча вопросов:

1. Возможно ли предоставить клиенту на выбор тип подключения (PPTP или PPPoE) без "шаманства" на его PC, т.е. простым "выбором иконок" - надо PPTP - жмём "картинку А", PPPoE - "картинку В" соответственно. И стОит ли такое вообще реализовывать?

2. Возможно ли при PPPoE одновременно использовать и IP конфигурацию? И аналогично вопрос - а надо ли оно вообще?

3. Как весь этот "винегрет" разруливать в АЦЛ (DES-3200)? Сейчас например, в АЦЛ для не заблокированного юзера создаётся правило, разрешающее ему доступ к роутеру по связке MAC/IP. Что станется с этим правилом в случае с PPPoE? Как и чтО вообще фильтровать для PPPoE?

4. Доступ клиента к NAS-ам осуществляется через Linux-роутер, соответственно для PPPoE потребуется pppoe relay на роутере. Здесь всё вроде бы понятно и без проблем, но.. В случае с pppoe relay на NAS-ы (вернее - в биллинг) приходит МАС роутера, а не клиента. Соответственно при авторизации разрушается связка login+password+IP (остаётся только логин/пароль). В случае "разборок" с клиентом, или ФСБ/Роскомнадзором этот момент создаёт определённые трудности в идентификации клиента..

5. другие неучтённые подводные камни..

 

Посему прошу помощи у коллег, кто уже проходил через "ЭТО", или знает "всё, что нужно" в данном случае.

[Negator]

1. Возможно ли предоставить клиенту на выбор тип подключения (PPTP или PPPoE) без "шаманства" на его PC, т.е. простым "выбором иконок" - надо PPTP - жмём "картинку А", PPPoE - "картинку В" соответственно. И стОит ли такое вообще реализовывать?

Возможно конечно. Реализовывать не стоит.

 

 

2. Возможно ли при PPPoE одновременно использовать и IP конфигурацию? И аналогично вопрос - а надо ли оно вообще?

Вы имеете ввиду локалку не в туннеле? Возможно, но на практике оным пользуются не все. Все таки 2 сетевых интерфейса у клиентов - неправильно. Запаритесь настраивать всякие DUAL ACCESS в роутерах, да и с другими вещами намучаетесь.

 

3. Как весь этот "винегрет" разруливать в АЦЛ (DES-3200)? Сейчас например, в АЦЛ для не заблокированного юзера создаётся правило, разрешающее ему доступ к роутеру по связке MAC/IP. Что станется с этим правилом в случае с PPPoE? Как и чтО вообще фильтровать для PPPoE?

Ничего не станется, PPPoE пройдет прозрачно, т.к. это не IP.

Как и что фильтровать - вопрос к Вам -что надо -то и фильтруйте.

 

 

4. Доступ клиента к NAS-ам осуществляется через Linux-роутер, соответственно для PPPoE потребуется pppoe relay на роутере. Здесь всё вроде бы понятно и без проблем, но.. В случае с pppoe relay на NAS-ы (вернее - в биллинг) приходит МАС роутера, а не клиента. Соответственно при авторизации разрушается связка login+password+IP (остаётся только логин/пароль). В случае "разборок" с клиентом, или ФСБ/Роскомнадзором этот момент создаёт определённые трудности в идентификации клиента..

 

Воткните клиентов напрямую в роутер.

 

 

5. На мой взгляд вы хотите поменять шило на мыло. PPPoE конечно имеет право на жизнь, и оно сильно лучше PPTP. Но рано или поздно все равно придется идти дальше в сторону IPoE.

Изменено 15 сентября, 2012 пользователем Negator

[Saab95]

На коммутаторах настраиваете сегментацию трафика, что бы клиенты могли общаться только с магистральными портами.

 

В центре перед вашим роутером втыкаете PPPoE концентратор - на нем и будут авторизовываться PPPoE клиенты.

 

Если используется Radius сервер - просто подключаете концентратор к нему и все дела. Два типа подключения будут нормально жить вместе, дадите месяц или два на перенастройку клиентских роутеров и компов - потом PPTP отключите.

 

После перехода на PPPoE окончательно, на всех портах заблокируете трафик отличный от PPPoE-Session и PPPoE-Discovery.

[disappointed]

Переводил с pptp на pppoe несколько лет назад, с такой же дуал акссес схемы. Использовал паралельное внедрение (поднимал пппое на всех вланах к клиентам).

 

Для перенастройки раздавались под подпись письма с настроечками и максимальным сроком перевода на них. После пптп было остановлено, ацл на доступе выставлен в ethertype 0x8863 0x8864.

 

Привязка логин пароль к маку не подразумевалась, мак сохраняется в базе сессий и в базе авторизаций для дальнейшего возможного анализа/разборок.

 

Внутренний трафик ходит через брас ("локалка" давно потеряла смысл, в связи с высокими скоростями в мир).

 

 

 

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

[NiTr0]

Пробрасываете все вланы до пппое браса, на нем поднимаете пппое, получаете всеобщее счастье.

Рилеи городить не стоит - криво это ибо в юзерленде крутится.

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

[snark]

Доступ клиента к NAS-ам осуществляется через Linux-роутер

Супер! А теперь, как верно подмечено выше - заранее объявляете о переходе с РРТР на РРРоЕ и во время Ч "выключаете" свои РРТР сервера (закрываете ТСР 1723 например) и, это важно, вешаете на этом сервере nginx, который при запросе любой странички будет рисовать "Мы перешли с РРТР на РРРоЕ. Вам необходимо сделать: blah blah blah" (обязательно укажите, что нужно удалить РРТР подключение (-: ) и после этого абоненту, который НЕ перенастроился, ТП достаточно будет сказать "наберите в адресной строке браузера любой адрес и получите настройки". Разумеется Вы должны выдать DNS и сделать так, чтобы все пакеты с dst port = 80 шли на Ваш nginx.

Сам так переводил. Поставил сервачок и выдал, через DHCP, его IP адрес дефолтным шлюзом и на доступе запретил общаться в локалке ни с кем, кроме него, в результате - все пакеты посыпались на него, он рисовал всем страничку и в ТП звонили только те, кто даже по картинкам не мог настроить, но таких было очень мало. Дабы "поймать всех блох" сервачок простоял месяц или два, после чего его убрали и в сети ничего кроме РРРоЕ не смогло ходить. Читай:

ацл на доступе выставлен в ethertype 0x8863 0x8864

[AlKov]

2. Возможно ли при PPPoE одновременно использовать и IP конфигурацию? И аналогично вопрос - а надо ли оно вообще?

Вы имеете ввиду локалку не в туннеле? Возможно, но на практике оным пользуются не все. Все таки 2 сетевых интерфейса у клиентов - неправильно. Запаритесь настраивать всякие DUAL ACCESS в роутерах, да и с другими вещами намучаетесь.

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

3. Как весь этот "винегрет" разруливать в АЦЛ (DES-3200)? Сейчас например, в АЦЛ для не заблокированного юзера создаётся правило, разрешающее ему доступ к роутеру по связке MAC/IP. Что станется с этим правилом в случае с PPPoE? Как и чтО вообще фильтровать для PPPoE?

Ничего не станется, PPPoE пройдет прозрачно, т.к. это не IP.

В том-то и дело! Вместе со всем "сопутствующим мусором". Плюс "хлам" от заблокированных. Оно мне не надо!!

Как и что фильтровать - вопрос к Вам -что надо -то и фильтруйте.

Хорошо. Спрошу по-другому - а чтО обычно фильтруется для PPPoE.

4. Доступ клиента к NAS-ам осуществляется через Linux-роутер, соответственно для PPPoE потребуется pppoe relay на роутере. Здесь всё вроде бы понятно и без проблем, но.. В случае с pppoe relay на NAS-ы (вернее - в биллинг) приходит МАС роутера, а не клиента. Соответственно при авторизации разрушается связка login+password+IP (остаётся только логин/пароль). В случае "разборок" с клиентом, или ФСБ/Роскомнадзором этот момент создаёт определённые трудности в идентификации клиента..

 

Воткните клиентов напрямую в роутер.

Эммм... А это как??

 

5. На мой взгляд вы хотите поменять шило на мыло. PPPoE конечно имеет право на жизнь, и оно сильно лучше PPTP. Но рано или поздно все равно придется идти дальше в сторону IPoE.

Возможно, но скорее всего не в этой (моей) жизни. :) Хотя я и являюсь сторонником IPoE. Ну вообщем, уже писал - не обсуждается..

[NiTr0]

Вместе со всем "сопутствующим мусором". Плюс "хлам" от заблокированных. Оно мне не надо!!

Какой "мусор" и "хлам" имеете ввиду? Что, запросы коннекта? Ну и пускай...

[snark]

"Локалку" хотелось бы оставить, хотя бы для доступа в личный кабинет.

Ключевое слово - ACL.

 

 

Вместе со всем "сопутствующим мусором". Плюс "хлам" от заблокированных. Оно мне не надо!

Еще раз: ключевое слово - ACL.

 

 

чтО обычно фильтруется для PPPoE

На вкус и на цвет фломастеры разные.

 

Можно например так:

DES-1228ME / DES-3028

# ----------------------------------------------------------------------------
# DHCP Relay
config dhcp_relay add ipif System IP.адрес.DHCP.сервера
config dhcp_relay option_82 state enable
enable dhcp_relay


# ----------------------------------------------------------------------------
# PPPoE Circuit Id Insertion
config pppoe circuit_id_insertion ports 25-28 state disable
config pppoe circuit_id_insertion ports 1-24 state enable
config pppoe circuit_id_insertion state enable


#------------------------------------------------------------------------------
# ACL

# PPPoE
create access_profile                                        ethernet ethernet_type        profile_id 1
config access_profile profile_id 1 add access_id auto_assign ethernet ethernet_type 0x8863 port all permit
create access_profile                                        ethernet ethernet_type        profile_id 2
config access_profile profile_id 2 add access_id auto_assign ethernet ethernet_type 0x8864 port all permit

# DHCP
create access_profile                                        ip udp src_port_mask 0xffff dst_port_mask 0xffff profile_id 3
config access_profile profile_id 3 add access_id auto_assign ip udp src_port          68 dst_port          67 port 1-24 permit

# deny all
create access_profile                                        ethernet source_mac 00-00-00-00-00-00 profile_id 4
config access_profile profile_id 4 add access_id auto_assign ethernet source_mac 00-00-00-00-00-00 port 1-24 deny

DES-3526

# ----------------------------------------------------------------------------
# DHCP Relay
config dhcp_relay add ipif System IP.адрес.DHCP.сервера
config dhcp_relay option_82 state enable
enable dhcp_relay


# ----------------------------------------------------------------------------
# PPPoE Circuit Id Insertion
config pppoe circuit_id_insertion ports 25-26 state disable
config pppoe circuit_id_insertion ports 1-24 state enable
config pppoe circuit_id_insertion state enable


#------------------------------------------------------------------------------
# ACL

# PPPoE
# 0x8863 разрешается в profile_id 1 который создается при включении PPPoE Circuit Id Insertion
create access_profile                                        ethernet ethernet_type        profile_id 2
config access_profile profile_id 2 add access_id auto_assign ethernet ethernet_type 0x8864 port 1-24 permit

# DHCP
# на 3526 DHCP разрешать не надо, т.к. DHCP Relay работает ДО механизма ACL
# этот грязный хак нужен только на DES-3526 чтобы DHCP пакеты не размножались в VLAN default
# при включении создается ACL
enable dhcp_local_relay

# deny all
create access_profile                                        ethernet source_mac 00-00-00-00-00-00 profile_id 4
config access_profile profile_id 4 add access_id auto_assign ethernet source_mac 00-00-00-00-00-00 port 1-24 deny

DHCP Relay работает только чтобы венда не выключала сетевушку, когда некоторое время не может получить IP адрес.

 

 

А это как?

РРРоЕ сервер интерфейсом, на котором он "принимает" РРРоЕ подключения от клиентов, должен "смотреть" в каждый VLAN с клиентами. Так понятнее?

IP адрес на этом интерфейсе не нужен.

 

 

уже писал - не обсуждается

Воля Императора - это понятно.

Изменено 15 сентября, 2012 пользователем snark

[AlKov]

К сожалению, все предложенные варианты предусматривают полный переход на PPPoE, а мне надо

 

... только одно решение - "вводить дополнительно", т.к по-любому сменить тип подключения ВСЕМ клиентам однозначно не получится. Соответственно придётся юзать и PPTP и PPPoE(на выбор).

Причина на тО имеется и не одна.. Поэтому давайте попробуем вернуться к сабж..

 

Пробрасываете все вланы до пппое браса, на нем поднимаете пппое, получаете всеобщее счастье.

Во-первых PPPoE BRAS-а у меня нет. Как уже и писал, есть три NAS-а на mpd5, которые без проблем поддерживают одновременно и PPTP и PPPoE.

Как в них завернуть клиентские влан, пока не представляю..

Рилеи городить не стоит - криво это ибо в юзерленде крутится.

Полностью согласен. Но похоже в моём случае других вариантов не предвидится. Или я что-то упустил?

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

Тарифы до 20 Мбит, но востребованы в-основном 5-6 Мбит. После увеличения скоростей, локалка почти умерла. Поэтому скорее всего "IP- вариант" останется только для PPTP, доступа в ЛК, ну и к локальным сайтам.

Переводил с pptp на pppoe несколько лет назад, с такой же дуал акссес схемы. Использовал паралельное внедрение (поднимал пппое на всех вланах к клиентам).

А каким образом? К NAS-ам как vlan-ы прокидывали?

После пптп было остановлено, ацл на доступе выставлен в ethertype 0x8863 0x8864.

И всё?

.. мак сохраняется в базе сессий и в базе авторизаций для дальнейшего возможного анализа/разборок.

Именно это мне и нужно, но с pppoe relay в базу пишется МАС роутера... Кроме того, в биллинге есть привязка к "номеру" при авторизации. Для PPTP это IP, для PPPoE - соотв. MAC. Т.е. та самая "связка" логин+пароль+IP(MAC).

Какой "мусор" и "хлам" имеете ввиду? Что, запросы коннекта? Ну и пускай...

Да хотя бы и это. Или 5-6 сотен клиентских роутеров, "забывших заплатить", пущай долбят NAS-ы и Radius?

ИМХО, логичнее их пристрелить на доступе.

Ну и наверное, есть что-то еще, что также логичнее прибить на доступе?

[Saab95]

Вот вы загоняетесь.

 

Есть примеры с 10 тысячами пользователей, с 5-7 насами на микротике, влан на дом, из фильтрации только зарезка всего кроме PPPoE. Постоянно долбятся клиентские роутеры с не правильными логинами и паролями, по 10-15 раз в секунду и все нормально работает.

 

 

[lan-viper]

AlKov, да хрень полная у вас там будет... в своё время держал колхоз из одновременно pptp, pppoe и l2tp. Вовремя одумался на счёт pppoe и избавился от него, после этого веселее пошла сегментация сети на L3. Если-бы я оставлял pppoe, то пришлось-бы в где-то в одном месте терминировать L2 для pppoe сервера, висящего на куче vlan-интерфейсов. На данный момент, благодаря ранее проделанной сегментации своих сетей на более мелкие L3 подсети, приспокойно перехожу на IPoE!

 

Я бы на Вашем месте попробовал l2tp на accel-ppp (или mpd5, смотря что за NAS-ы у Вас).

Изменено 15 сентября, 2012 пользователем lan-viper

[snark]

Как в них завернуть клиентские влан, пока не представляю.

У сервера есть РРТР_interface на котором Вы терминируете РРТР и который смотрит на Ваш "Linux-роутер"(с).

Что мешает создать РРPoE_interface_<client_VLAN>_A, РРPoE_interface_<client_VLAN>_B, РРPoE_interface_<client_VLAN>_C и т.д., каждый из которых будет смотреть в свой клиентский VLAN и на которых будет терминироваться РРРоЕ но МИНУЯ "Linux-роутер"(с)?

Что именно у Вас в голове не укладывается?

 

К NAS-ам как vlan-ы прокидывали?

Вы, простите, вообще читаете то что Вам пишут?

Еще раз: каждый интерфейс РРРоЕ сервера должен находится в каждом клиентском VLAN.

 

5-6 сотен клиентских роутеров, "забывших заплатить", пущай долбят NAS-ы и Radius?

Да, т.к. на Вашем MPD это, к сожалению, невозможно. На цисках для РРРоЕ есть PPPoE Connection Throttling, на SE100 есть аналог, но не помню как звать.

 

логичнее их пристрелить на доступе

Это невозможно ни в случае с РРРоЕ ни в случае с РРТР (сюрприз!), т.к. для этого свич должен уметь ограничивать кол-во ААА сессий и, насколько я знаю, ни один свич доступа это не умеет. Да чего там - даже Ваш MPD, повторюсь, этого не умеет.

 

все предложенные варианты предусматривают полный переход на PPPoE, а мне надо

А Вам надо дорисовать приведенные ACL под поддержку РРТР.

Если для Вас это сложно, то тут найдется масса желающих сделать это за Вас, но уже за деньги.

[s.lobanov]

Да хотя бы и это. Или 5-6 сотен клиентских роутеров, "забывших заплатить", пущай долбят NAS-ы и Radius?

 

Всё НАМНОГО проще. Клиентов, забывших заплатить просто помещаете в гостевую сеть из которой доступ только к DNS, ЛК, вашему сайту и т.п. + редирект на страницу "дай денег". Тогда проблем с большим кол-вом сигнализации от таких клиентов не будет. А клиентов с неправильными логинами/паролями на порядок меньше, но если всё-таки мешают, то и их можно авторизовывать в гостевую сеть(вместо странички "дай денег" сделать им "неверный логин/пароль")

[snark]

Клиентов, забывших заплатить просто помещаете в гостевую сеть из которой доступ только к DNS, ЛК, вашему сайту и т.п. + редирект на страницу "дай денег".

Если под "и т.п." подразумевается, помимо прочего, РРТР/РРРоЕ сервер, то да, мысль здравая, а если нет, то владельцы роутеров вынесут ТП моск.

[Saab95]

Забывших заплатить надо не в гостевую сеть перемещать, а просто на страничку переадресовывать. Смысл какой учетные записи блокировать?

 

 

[s.lobanov]

Клиентов, забывших заплатить просто помещаете в гостевую сеть из которой доступ только к DNS, ЛК, вашему сайту и т.п. + редирект на страницу "дай денег".

Если под "и т.п." подразумевается, помимо прочего, РРТР/РРРоЕ сервер, то да, мысль здравая, а если нет, то владельцы роутеров вынесут ТП моск.

 

да, подразумевается

 

Забывших заплатить надо не в гостевую сеть перемещать, а просто на страничку переадресовывать. Смысл какой учетные записи блокировать?

 

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

[NiTr0]

Во-первых PPPoE BRAS-а у меня нет. Как уже и писал, есть три NAS-а на mpd5, которые без проблем поддерживают одновременно и PPTP и PPPoE.

Как в них завернуть клиентские влан, пока не представляю..

Точно так же как и на роутер. В чем проблема-то?

 

А каким образом? К NAS-ам как vlan-ы прокидывали?

Ручками, ручками... Или у вас в ядре неуправляемая гигабитная мыльница?

 

Или 5-6 сотен клиентских роутеров, "забывших заплатить", пущай долбят NAS-ы и Radius?

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

А вообще - на брасах (том же accel-ppp) обычно настраивается лимит частоты PADI от каждого юзера. Ну или файрволом режется. Как с этим в MPD дела обстоят - мне неведомо.

 

ИМХО, логичнее их пристрелить на доступе.

На неуправляемом? :)

[Дегтярев Илья]

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

 

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

 

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

[AlKov]

Как в них завернуть клиентские влан, пока не представляю.

У сервера есть РРТР_interface на котором Вы терминируете РРТР и который смотрит на Ваш "Linux-роутер"(с).

Что мешает создать РРPoE_interface_<client_VLAN>_A, РРPoE_interface_<client_VLAN>_B, РРPoE_interface_<client_VLAN>_C и т.д., каждый из которых будет смотреть в свой клиентский VLAN и на которых будет терминироваться РРРоЕ но МИНУЯ "Linux-роутер"(с)?

Что именно у Вас в голове не укладывается?

Вот ЭТО (выделено в вашей цитате) укладывается без проблем.

А вот ЭТО -

Воткните клиентов напрямую в роутер.

да еще к тому же не очень удачно (как бы подтверждая сказанное) прокомментированное Вами здесь -

А это как?

РРРоЕ сервер интерфейсом, на котором он "принимает" РРРоЕ подключения от клиентов, должен "смотреть" в каждый VLAN с клиентами. Так понятнее?

поставило в полный ступор..

Ну слава Богу, сейчас всё прояснилось! :-) Даже поигрался на тестовом сервачке (кстати, пишу сей мессадж на желанном PPPoE :-)).

 

5-6 сотен клиентских роутеров, "забывших заплатить", пущай долбят NAS-ы и Radius?

Да, т.к. на Вашем MPD это, к сожалению, невозможно.

логичнее их пристрелить на доступе

Это невозможно ни в случае с РРРоЕ ни в случае с РРТР (сюрприз!), т.к. для этого свич должен уметь ограничивать кол-во ААА сессий и, насколько я знаю, ни один свич доступа это не умеет. Да чего там - даже Ваш MPD, повторюсь, этого не умеет.

Стоп-стоп! Вы меня неправильно поняли. Ну тут я сам виноват..

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

А вот те, которые "забыли заплатить" после 15-го числа и при этом ещё "забыли выключить роутер", пристреливаются на доступе, простым удалением разрешающего правила

3. ... Сейчас например, в АЦЛ для не заблокированного юзера создаётся правило, разрешающее ему доступ к роутеру по связке MAC/IP.

вот такого

config access_profile profile_id 8  add access_id 4  packet_content   destination_mac 00-01-02-03-04-05  mask FF-FF-FF-FF-FF-FF source_mac 00-1A-4D-8A-FB-12
mask FF-FF-FF-FF-FF-FF offset2 0x0a00   mask 0xffff offset3 0xd012   mask 0xffff port 3 permit

При этом "выше" есть правило, разрешающее доступ к DNS и ЛК. Вот что-то подобное мне хотелось бы организовать для PPPoE.

все предложенные варианты предусматривают полный переход на PPPoE, а мне надо

А Вам надо дорисовать приведенные ACL под поддержку РРТР.

Ровно наоборот. :) Надо "дорисовать существующие ACL для PPTP под поддержку PPPoE и PPTP одновременно".

 

ИМХО, логичнее их пристрелить на доступе.

На неуправляемом? :)

Ага. :)

Ну а если серъёзно, реальный "доступ" у меня действительно неуправляемый, или НЕДОуправляемый (DES-1008D/RV, DES-2108 и DES-1100-16). Это железо находится в подъездах. На нём только изоляция портов. А вот собственно управляемый "доступ" начинается "выше" - на домовом свитче (DES-3200). Там и живут ACL. И вот всё это "глупое" и "полу-умное" железо и создаёт основную проблему для перехода на "цивилизованный доступ"..

 

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

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

Эх! Ваши слова да Богу шефу в уши! Увы, я технарь, а не владелец бизнеса...

Ну это, как говорит Леонид Каневский в своей телепрограмме, совсем другая история. Печальная..

Изменено 15 сентября, 2012 пользователем AlKov

[NiTr0]

Надо "дорисовать существующие ACL для PPTP под поддержку PPPoE и PPTP одновременно".

 

В чем проблема? Берете RFC по PPPoE, смотрите структуру PADI пакета, думаете как его зарезать ACL'ями. Ну либо если заворачиваете должников в отдельный влан - то не слушаете там пппое и все, пускай себе бесятся как хотят...

Хотя, опять же, как по мне - правильнее лимитировать кол-во запросов в единицу времени на самом брасе.

[AlKov]

Надо "дорисовать существующие ACL для PPTP под поддержку PPPoE и PPTP одновременно".

В чем проблема? Берете RFC по PPPoE, смотрите структуру PADI пакета, думаете как его зарезать ACL'ями.

В моём случае ("запрещено всё, кроме разрешенного") надо не "резать", а наоборот - "разрешать" доступ не заблокированным клиентам. Вот и думаю, может быть будет достаточно просто убрать из правила проверку source ip? Ну где-то так: вместо этого

config access_profile profile_id 8  add access_id 4  packet_content   destination_mac 00-01-02-03-04-05  mask FF-FF-FF-FF-FF-FF source_mac 00-1A-4D-8A-FB-12
mask FF-FF-FF-FF-FF-FF offset2 0x0a00   mask 0xffff offset3 0xd012   mask 0xffff port 3 permit

для PPPoE клиентов создавать такое правило -

config access_profile profile_id 8  add access_id 4  packet_content   destination_mac 00-01-02-03-04-05  mask FF-FF-FF-FF-FF-FF source_mac 00-1A-4D-8A-FB-12
mask FF-FF-FF-FF-FF-FF offset2 0x0 mask 0x0 offset3 0x0  mask 0x0 port 3 permit

т.е. просто убрать проверку source ip.

Или этого будет недостаточно?

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

Хотя, опять же, как по мне - правильнее лимитировать кол-во запросов в единицу времени на самом брасе.

Нет, должники как жили в своём vlan, так и будут там. Необходимый доступ в ЛК им будет обеспечен по IP. А вот доступ к NAS-ам хотелось бы закрыть всем, кому это не положено. Не только должникам, а также всем желающим "поиметь халяву".

 

To snark, если не сложно, поясните пожалуйста, вот здесь

DHCP Relay работает только чтобы венда не выключала сетевушку, когда некоторое время не может получить IP адрес.

и надо ли мне для DES-3200 вот это -

# ----------------------------------------------------------------------------
# DHCP Relay
config dhcp_relay add ipif System IP.адрес.DHCP.сервера
config dhcp_relay option_82 state enable
enable dhcp_relay


# ----------------------------------------------------------------------------
# PPPoE Circuit Id Insertion
config pppoe circuit_id_insertion ports 25-28 state disable
config pppoe circuit_id_insertion ports 1-24 state enable
config pppoe circuit_id_insertion state enable


#------------------------------------------------------------------------------
# ACL

# PPPoE
create access_profile                                        ethernet ethernet_type        profile_id 1
config access_profile profile_id 1 add access_id auto_assign ethernet ethernet_type 0x8863 port all permit
create access_profile                                        ethernet ethernet_type        profile_id 2
config access_profile profile_id 2 add access_id auto_assign ethernet ethernet_type 0x8864 port all permit

# DHCP
create access_profile                                        ip udp src_port_mask 0xffff dst_port_mask 0xffff profile_id 3
config access_profile profile_id 3 add access_id auto_assign ip udp src_port          68 dst_port          67 port 1-24 permit

# deny all
create access_profile                                        ethernet source_mac 00-00-00-00-00-00 profile_id 4
config access_profile profile_id 4 add access_id auto_assign ethernet source_mac 00-00-00-00-00-00 port 1-24 deny

В частности по dhcp relay и PPPoE Circuit Id Insertion. Я правильно понимаю, что эти фичи нужны только для того, чтобы "слить инфу" биллингу и заменить этим привязку к МАС-у на привязку к порту, или ошибаюсь?

И по 0x8863 и 0x8864 вопрос - может их лучше прикрутить к "персональному разрешающему правилу"? Ну по тому же принципу, как с IP.

Изменено 15 сентября, 2012 пользователем AlKov

[NiTr0]

В моём случае ("запрещено всё, кроме разрешенного") надо не "резать", а наоборот - "разрешать" доступ не заблокированным клиентам. Вот и думаю, может быть будет достаточно просто убрать из правила проверку source ip?

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

 

 

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

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

 

Я правильно понимаю, что эти фичи нужны только для того, чтобы "слить инфу" биллингу и заменить этим привязку к МАС-у на привязку к порту, или ошибаюсь?

А смысл вам этим заморачиваться, если у вас все равно тупари на доступе? Как привязывались к маку - так и привязывайтесь далее.

[s.lobanov]

Необходимый доступ в ЛК им будет обеспечен по IP. А вот доступ к NAS-ам хотелось бы закрыть всем, кому это не положено.

 

Вам заняться чтоль больше нечем, как мучать техподдержку(или себя?) звонками абонентов? Делайте как сотовые операторы - нет денег - нет платных услуг, но при этом телефон регистрируется в сети и думает, что всё в порядке.

[AlKov]

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

Например?