[BudushiyISP]

да он вообще не в России :)

Правильно человек отметил я не в России, поэтому здесь сертификат упразднили на биллинг.

 

[BudushiyISP]

Как делал я ( без привязки к биллингу вообще )

 

-Стоит отдельный сервер. На свитчах D-LINK включен IP-MAC-Binding на всех абонентских портах.

-При обнаружении свитчем неавторизованной связи MAC-IP-Port свитч отсылает SNMP Trap на выделенный сервер.

-Сервер проверяет связку по своей базе данных, и в случае если данный IP или MAC еще не занят каким-то абонентом - сохраняет информацию в базу данных и прописывает IP-MAC-связку в свитче.

 

То есть с точки зрения монтажника выглядит так -- он приходит к абоненту с уже прописанным в договоре IP и настраивает его на компьютере абонента. Дальше IP привязывается на свитче и в базе данных абсолютно прозрачно.

 

У технической поддержки есть страница поисковых запросов к базе с историй привязок IP к портам и коммутаторам ( вместе с геобазой коммутаторов ) , а так же история отказов в привязке. При обращении абонента у них есть единственная кнопка "разрушить привязку". Если абонент например сетевую плату поменял или его в другой порт переткнули.

 

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

Вообще конечно же, я лично забыл, что у клиентов могут быть роутеры. А их маки значит по любому придётся в ручную прописывать, да и порт тогда нужно будет точно сообщать, ибо в роутер логин и пароль не пропишешь как у меня по сценарию. Я ещё не пробовал, а можно ли сделать слудующее, после соединения по ПППоЕ тут же раздавать маршруты на локалку и всё локалка бегает через коммутаторы, а ПППоЕ через сервер? учтите доступ у меня управляемый.

 

[LostSoul]

Вообще конечно же, я лично забыл, что у клиентов могут быть роутеры. А их маки значит по любому придётся в ручную прописывать, да и порт тогда нужно будет точно сообщать, ибо в роутер логин и пароль не пропишешь как у меня по сценарию. Я ещё не пробовал, а можно ли сделать слудующее, после соединения по ПППоЕ тут же раздавать маршруты на локалку и всё локалка бегает через коммутаторы, а ПППоЕ через сервер? учтите доступ у меня управляемый.

Еще раз внимательно прочитайте мою схему. Роутер/не роутер --- не имеет никакого значения.

Приходит монтажник , настраивает на роутере IP адрес абонента из договора, втыкает в WAN-порт роутера кабель, связанный с абонентским портом операторского ( вашего ) свитча D-Link.

На порту коммутатора D-Link включен режим IP-MAC-Binding.

Соответствующей связки MAC-IP-Port нету.

Mac-адрес роутера заносится в blocked list.

Коммутатор отсылает SNMP TRAP на станцию управления. ( далее - Сервер Привязок )

На станции управления специальный скрипт смотрит что

а) данный IP-адрес согласно списку из биллинга разрешен к использованию в сети

б) данный IP-адрес не привязан ни в одном другом месте сети ( нет активной привязки )

в) данный MAC тоже еще нигде не привязан

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

На коммутатор отправляется набор SNMP-запросов, постоянно сохраняющих в конфигурации коммутатора привязку данного IP с данным MAC на данному порту коммутатора D-Link.

 

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

 

В случае замены роутера абонент звонит в службу поддержки.

Сотрудники поддержки делают поисковый запрос через web-интерфейс сервера привязок. Например по IP-адресу абонента.

В ответ на поисковый запрос им выводится ( например )

 

Адрес IP 10.10.15.10

MAC: 00-00-AA-BB-DD-EE

Событие : Зарегистрирована привязка

Дата : 01 мая 2009 года 16:45:00

Коммутатор : Тверская ул. д 5 2-ой подьезд чердак , порт 31

[ УДАЛИТЬ ПРИВЯЗКУ ]

 

Адрес IP 10.10.15.10

MAC: 00-00-33-33-33-33

Событие : Отказ доступа -- изменился MAC-адрес.

Дата : 2 минуты 10 секунд назад

Коммутатор : Тверская ул. д 5 2-ой подьезд чердак , порт 31

 

Прочитав такой результат запроса и сопоставив с описанием ситуации от абонента, сотрудник поддержки жмет кнопку "Удалить привязку".

 

Абонент пытается открыть любимый сайт "сиськи-ру". Сотрудник поддержки жмет в поисковой форме "обновить", получает следующий вывод

 

Адрес IP 10.10.15.10

MAC: 00-00-AA-BB-DD-EE

Событие : Ранее существовавшие связи

Период : 01 мая 2009 16:45:00 -- 30 сен 2009 20:46:20

Коммутатор : Тверская ул. д 5 2-ой подьезд чердак , порт 31

Связку удалил : оператор Петров А.В.

 

Адрес IP 10.10.15.10

MAC: 00-00-33-33-33-33

Событие : Отказ доступа -- изменился MAC-адрес.

Дата : 3 минуты 40 секунд назад

Коммутатор : Тверская ул. д 5 2-ой подьезд чердак , порт 31

 

Адрес IP 10.10.15.10

MAC: 00-00-33-33-33-33

Событие : Зарегистрирована привязка

Дата : 25 секунд назад

Коммутатор : Тверская ул. д 5 2-ой подьезд чердак , порт 31

[ УДАЛИТЬ ПРИВЯЗКУ ]

 

Вот и всё)

Без разницы стоит там роутер или пылесос с Ethernet-подключением)

Единственное ограничение такой системы 1 MAC = 1 IP , и то ограничение вытекает из удобства эксплуатации и может быть снято.

 

[КузярБ]

В случае замены роутера абонент звонит в службу поддержки.

Сотрудники поддержки делают поисковый запрос через web-интерфейс сервера привязок. Например по IP-адресу абонента.

В ответ на поисковый запрос им выводится ( например )

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

[LostSoul]

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

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

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

 

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

 

В принципе естественно нету никакой проблемы чтобы разрешить автоматическую замену MAC-адреса на новый , при совпадении комбинации IP-адрес/порт подключения

 

[XeonVs]

А оборудование на доступе однотипное?

[LostSoul]

А оборудование на доступе однотипное?

В сети, где я внедрял данное решение -- к счастью везде стояло управляемое железо D-Link с поддержкой функции IP-MAC-Binding.

Кроме того, были абонентские выносы на малоэтажные дома или труднодоступные подьезды , где стояли неуправляемые свитчи на 8 портов.

В этом случае порт на последнем управляемом свитче рассматривался как "коммунальный" , то есть на нем активировался IP-MAC-binding и просто не было ограничений по числу привязок на порт.

 

Собственно конкретно такой алгоритм внедрения привязок и работы с ними, был придуман мною с учетом вдумчивого анализа существовавшей на момент постановки задачи ситуации. Была бы другая вводная -- реализовал бы иначе.

Изменено 30 сентября, 2009 пользователем LostSoul

[jp1111]

Кстати, может подскажете, где в 152 ФЗ и связанной с ним нормативке написано хоть слово про обязательную сертификацию. Трижды всё прочитал - не нашел.

"всё прочитал" - завидую Вам, я уже год читаю, а вот _все_ прочитать не могу. Начал писать ... :)

 

А никто не говорил про обязательную. Колхоз дело добровольное. Но те операторы ПД, которые этой самой нормативке не удовлетворят отЪимеют. Начнут конечно с больших, но ведь и тут не все мелкие.

Вот недавно получил приглашение выступить на конференции от коллег. Текст понравился:

 

1 октября 2009 г. в гостинице "Рэдисон САС Славянская" состоится

II ежегодная конференция "Персональные данные".

 

Практически каждая компании сегодня хранит, обрабатывает, передает персональные данные (ПДн) сотрудников, клиентов, подрядчиков и т.п., а значит, является оператором ПДн и подпадает под действие ФЗ-152 "О персональных данных".

 

Как известно, до 1 января 2010 года ВСЕ операторы обязаны обеспечить защиту персональных данных. На 2009 г., по данным отчета Федеральной службы в сфере связи и массовых коммуникаций (Роскомнадзор), запланирована 321 плановая проверка, что в 4 раза больше прошлогоднего числа.

 

В общем читай между строк. Есть способы не аттестовать ничего, но это в известной степени гемор. Проще показать сертификаты.

Изменено 30 сентября, 2009 пользователем jp1111

[terrible]

купил - показал - забыл (если надо - ещё раз показал), а то, что в реале работает - вопрос совершенно другой :)

[XeonVs]

А оборудование на доступе однотипное?

В сети, где я внедрял данное решение -- к счастью везде стояло управляемое железо D-Link с поддержкой функции IP-MAC-Binding.

Кроме того, были абонентские выносы на малоэтажные дома или труднодоступные подьезды , где стояли неуправляемые свитчи на 8 портов.

В этом случае порт на последнем управляемом свитче рассматривался как "коммунальный" , то есть на нем активировался IP-MAC-binding и просто не было ограничений по числу привязок на порт.

 

Собственно конкретно такой алгоритм внедрения привязок и работы с ними, был придуман мною с учетом вдумчивого анализа существовавшей на момент постановки задачи ситуации. Была бы другая вводная -- реализовал бы иначе.

ясно, спасибо.

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

[BudushiyISP]

А оборудование на доступе однотипное?

DES-3028 и ничего другого.

 

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

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

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

 

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

 

В принципе естественно нету никакой проблемы чтобы разрешить автоматическую замену MAC-адреса на новый , при совпадении комбинации IP-адрес/порт подключения

Нет, в том и дело я хочу исплючить общение абонента по данному вопросу со службой поддержи. Поэтому привязку лучше делать явно по порту, а не маку + айпи и влан на коммутатор доступа.. Так явно будет меньше общения со службой поддержки. Переехал абонент на новое место, вводит свой логин и пароль регистрацию прошёл и все порядок.

Изменено 30 сентября, 2009 пользователем BudushiyISP

[XeonVs]

А оборудование на доступе однотипное?

DES-3028 и ничего другого.

 

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

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

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

 

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

 

В принципе естественно нету никакой проблемы чтобы разрешить автоматическую замену MAC-адреса на новый , при совпадении комбинации IP-адрес/порт подключения

Нет, в том и дело я хочу исплючить общение общение абонента по данному вопросу со службой поддержи. Поэтому привязку лучше делать явно по порту, а не маку + айпи и влан на коммутатор доступа.. Так явно будет меньше общения со службой поддержки. Переехал абонент на новое место, вводит свой логин и пароль регистрацию прошёл и все порядок.

т.е. хочется 802.1x но более секурное и гибкое?

[jab]

Нет, в том и дело я хочу исплючить общение абонента по данному вопросу со службой поддержи. Поэтому привязку лучше делать явно по порту, а не маку + айпи и влан на коммутатор доступа.. Так явно будет меньше общения со службой поддержки. Переехал абонент на новое место, вводит свой логин и пароль регистрацию прошёл и все порядок.

Ага, или сперли у него этот логин и пароль, пока он в отпуске был...

[LostSoul]

Да делается и то что ты хочешь аналогичным образом через гостевой vlan.

Просто на момент внедрения мной данного проекта поддержки гостевого vlan в прошивках еще не существовало.

 

[BudushiyISP]

Нет, в том и дело я хочу исплючить общение абонента по данному вопросу со службой поддержи. Поэтому привязку лучше делать явно по порту, а не маку + айпи и влан на коммутатор доступа.. Так явно будет меньше общения со службой поддержки. Переехал абонент на новое место, вводит свой логин и пароль регистрацию прошёл и все порядок.

Ага, или сперли у него этот логин и пароль, пока он в отпуске был...

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

 

[jab]

ну и в случае PPPoE логин и пароль могут спереть, это уже ответственность абонента.

А при чем тут PPPoE ? При port+IP binding ничего спереть нельзя.

 

 

[BudushiyISP]

ну и в случае PPPoE логин и пароль могут спереть, это уже ответственность абонента.

А при чем тут PPPoE ? При port+IP binding ничего спереть нельзя.

Вы хотите сказать что обязательно на самом коммутаторе вкючать port+IP binding ? зачем ?

Я включу на коммутаторе DHCP snooping и İP -Source Guard. А İP будет выдавать мой DHCP сервер причём каждый раз тот же самый.

Изменено 30 сентября, 2009 пользователем BudushiyISP

[LostSoul]

Port + IP binding и не бывает ИМХО в DES. это только ACL-ями если.

так как лочится всё по MAC-ам , а не по IP/портам.

 

[terrible]

Port + IP binding и не бывает ИМХО в DES. это только ACL-ями если.

так как лочится всё по MAC-ам , а не по IP/портам.

советую прочитать про функционал IP-MAC-Binding Permit Pool

Так-же функционал Port + IP binding есть на ES

[LostSoul]

Port + IP binding и не бывает ИМХО в DES. это только ACL-ями если.

так как лочится всё по MAC-ам , а не по IP/портам.

советую прочитать про функционал IP-MAC-Binding Permit Pool

Так-же функционал Port + IP binding есть на ES

Читал, и насколько я помню IP-MAC-Binding Permit Pool касается гостевого vlan.

А es это вы про что? ) Про каталисты что-ли?)

 

С Длинк ,если что, последний год не работал)

 

[Elisium]

ES - это наверное ЭджКоры ))

Только вот у топикстартера только Длинки))

[jab]

Port + IP binding и не бывает ИМХО в DES. это только ACL-ями если.

так как лочится всё по MAC-ам , а не по IP/портам.

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

[LostSoul]

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

По нарушению ACL не бывает SNMP TRAP к сожалению, что не позволяет реализовать мою такую стройную схему с "кибернетической обратной связью")))

 

А вот по блокировке IP-MAC-Binding в ядро сети идет шикарный TRAP. что позволяет "разучивать" новых абонентов на автопилоте.

 

И вообще нажать кнопку "удалить привязку" дурное дело не хитрое. Это поддержке сделать гораздо проще чем всякие маки без ошибок вбивать куда-то с паролями....

 

[jab]

По нарушению ACL не бывает SNMP TRAP к сожалению, что не позволяет реализовать мою такую стройную схему с "кибернетической обратной связью")))

А на кой они нужны ? Вы сеть строите ради SNMP TRAP ?

[LostSoul]

Я делаю изящные, удобные в работе и использовании решения.

 

Ваш вариант предложите. Есть сеть скажем на тысячу свитчей и X тысяч абонентов.

Нужно всех существуюших "привязать" прозрачно для абонентов, и всех новых тоже прозрачно подвязывать....