vop

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

Да там особо сложного ничего нет. Мне была интересна мультимаршрутность и устойчивость протокола. Сделал, протестировал, и отложил в сторону. Будут просьбы - буду включать. Актуален, например, для биллингов, при установке их в облаке "у черта на куличках".

У меня в сырцах агента сейчас это выглядит так: (*in_soc)->proto = IPPROTO_TCP; // Or IPPROTO_SCTP Комментарий там появился достаточно давно, после того, как я устал объяснять, что это за опция в конфиге. Никому "оно" не надо. Мало кто понимает, зачем оно надо. Работает нормально.

Знаете, что называют "котылями"? В ситуациях, когда задачу нельзя решить стандартными способами, придумывают нестандартный, с нарушением принятых протоколов. Обычно "костыль" решает определенную задачу, иногда даже не плохо, до определенного момента, в который стандартная мера могла бы справится сама. Работа с оцией 82 может быть какой угодно - даже на "побочных эффектах", но я бы назвал это каким-нибудь другим словом, а не "реализацией dhcp". И что бы не вставать два раза: Называется "развивать победное наступление" Дружище, мне, честно говоря, наплевать на проблемы "производственников". Мне не интересно заниматься скучной работой. поэтому я продал свой провайдер много лет назад после 15 лет провайдерства. Однако... Что-то я запутался - надо или не надо. Вообще, для авторизации не обязательно использовать логины и пароли. Для авторизации есть много других способов, которые не требуют введения пароля - от SMS и smartcard (payment-id) и до сканирования qr-code. И речь, будем честным, не о "дополнительной" авторизации, а о входе в свой кабинет клиента, не более того. Тут есть одна грустная история. Если вы используете костыль, то он, как тот же скрипт, о котором вы тут мне сообщили "новость", просто не хранит лизы и не хранит MAC-и. Поэтому тут можно только пожелать успехов в ручном труде персонала. Я даже не буду повторять фразу - вам больше нечем заняться? Я пытаюсь говорить о 21-м веке, а не о "нам и так не плохо".

Я вас услышал. Вы - о своем. Ну да ладно, не важно.

Вы сейчас описали совершенно другую ситуацию - другой MAC в тот же порт. А мы обсуждали ситуацию одного и того же MAC'а в другой порт. У Ивана сделано немного по другому. Он просто исполняет отказ от лизы и выдает новую. А опция 82 используется опять же для выбора политики выдачи ip адреса, точно так же, как и любые другие сервера. Немного грубо, и не совсем чисто, но для всех общих случаев подойдет.

Я про таких не слышал. Не подскажите, о каких реализациях идет речь? Те, немногие dhcp сервера, которые я в свое время пробовал, всегда продлевают ту же лизу даже при смене opt 82. Так-как это вообще не дело dhcp сервера их отслеживать. Пришла опция - выбрал политику выбора пула (если админ настроил его на это "беспокойство"), и забыл. Все остальное - это дело свича, как реагировать, на ответ с "неправильной" опцией 82 (для чего она, собственно говоря, и придумывалась). Большинство железа на это никак не реагирует. По большому счету, если эта опция не используется для защиты от тех двух видов dhcp-аттак, то и в dhcp-сервере про нее можно и не вспоминать особо. От сервера помимо стандартного ответа с опцией при начале делегирования адреса достаточно того, что бы он фиксировал пришедшие опции где-нибудь, даже в том же логе. Хотя, можно вообще поставить на порт отдельный парсер опции от биллинга, если таковой умеет.

Там не новый мак у Пети будет. Там будет Васин мак с другой опцией 82. Просто напомню, dhcp сервер выдает и хранит лизы по мак-адресам, и никак иначе. И если биллинг не следит за парами mac/82 - то начнется компот и "внеземные цивилизации".

Я передам ваши слова ребятам из райцентра... Хотя, я им уже давно сам все объяснил и пояснил.

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

(Анекдот) У логопеда: - Доктор, я плохо выговариваю букву Ч? - Ну как же, дружище! Совсем даже не плохо выговариваете! - Ну не чавчем.:) И так, схема такая. В одном месте оказываются человек и розетка (та, которую когда-то поставил монтажник). Просто не забываем, что в цивилизованном случае в квартире у человека электрические и ethernet розетки изначально давно установлены и куда надо подключены. Человек втыкает что-то интернет-кушающее в розетку. 1. Этот этап пропускам в описании, так-как для Украины не актуально (интеграторы последней мили в стране не прижились). 2. "Если вы у нас первый раз - зарегистрируйтесь, если вы наш клиент - залогиньтесь". Человек (в мире диджитализации) прикладывает свою id-card, (а в отсталом мире) вводит свое имя, телефон, адрес. Монтажник тут не при чем, ибо он был тут последний раз 3 года назад, когда строили район.:) 3. Если человек уже клиент, просто логинится, прикладывая какое-нибудь диджитализирующее устровйтсво к диждитализирующему идентификатору... Ну, например, сканирует qr-code. И это только в случае замены оборудования или других проблем. Иначе клиент никуда не заходит и ничего не вводит. 3. Если клиент новый - он заходит в свой профайл, выбирает услугу(-и), произовдит оплату в "ван клик" одним из 1072 доступных способов, и забывает об остальных отношениях своих с провайдером. Факт оплаты в цивилизованной стране является фактом подписывания договора. Вопрос адреса. Если дядя покупает в интернет магазине энциклопедию (или надувную тётку), он вводит там свой адрес для доставки товара. Тут то же самое - введите свой адрес, без которого мы не сможет пофиксить неисправности, если таковые возникнут. Не введет клиент свой адрес, работает все, платит - ну и слава богу, деньги поступают, мороки нет. Вот такая простенькая схема. И да, такая схема не нова. Она была запущена (сейчас посмотрю...) в мае 2005 года. С тех пор я слышал огромное количество "аргументов" со стороны украинских провайдеров, почему они это делать не хотят, им это не выгодно, это не правильно... Ну то дело такое.

Немного странно. У меня такая процедура потребовалась в Киевстаре только один раз, когдау них "паламался" свич, и они меня переткнули в другой. MAC (DUID) нужен всегда, так-как это основной id, на котором работает dhcp. Если порт висит в воздухе, то при подключении устройства DHCP выдает неизвестному MAC'у свободный адрес из пула (зачем его потом менять - неизвестно). Потом смотрит, на каом порту висит этот мак по opt82. И только после того, как клиент ввел свои кредиты, порт "закрепляется" за клиентом, и в дальнейшем все другие маки, пришедшие с этого порта, будут числиться за этим клиентом. Но изначальный ip выдан изначальному маку по лизе. Если лиза выдана, то она выдана уже МАКу. Какой бы влан не приехал, какой бы порт ни прискакал - это уже не имеет значения, так-как уже и политика выбора пула давно отработана, и лиза давно выдана, только продлевается. В этом костыль всех этих "неприродных" способов изначальной привязки политик и заключается. Поменялся порт, крендель зашел к соседу со своим ноутом, и т.д. Все опять начинается с мятой пачки от сигарет.:) duid - это в ipv6. Можно, по большому счету, это назвать mac unnumbered. Ну, в ipv6 решили не привязываться к маку, а придумали замену ему. Но сути это дело не меняет. Хотя, на практике, можно свой мак менять, лиза уже выдана на этот duid, который "в мирное время" всегда остается тем же.

Наверно я плохо описал, зачем. Для идентификации подключения клиента. optiоn 82 замечательно идентифицирует как порт подключения, так и vlan. В природе есть два способа идентификации физического подключения: 1. Монтажник записал на сигаретной пачке. 2. Клиент ввел свои id/secret. Других, как бы не существует. В первом случае 82-ю опцию часто используют для определения политики выбора пула в dhcp. Как и vlan. Тут действительно или vlan или opt82. Одновременно они не нужны. Нужно только заранее знать, кому принадлежит порт, или vlan. Но это "ручная бумажная технология". Во втором случае можно и vlan с opt82. А можно вообще без того и без другого. Ибо и то, и другое - надстройка над dhcp сервером, который ВСЕГДА выдает лизы по duid. У меня в маленькой тестовой сети клиенты напрямую регистрируются по duid'у, а dhcp тупо выдает ip без всякой классификации политик. PS Я там писал, что знаю 2 (или 3) провайдера, где реализована идентификация клиента. И Киевстар - один из них.

Ну если не поддерживается, то и ладно, можно без него. Я в свое время взялся писать софт под провайдера, с академической целью убрать максимально человеческий труд, там где он не нужен. Давно придумал схему, в которой офис для клиента совсем не нужен, реализовал. Но, похоже, никому "оно не надо". Или просто я плохо доношу свою мысль до коллег. Option 82 была придумана вообще, как механизм защиты от атак на DHCP из untrusted segments. Ну, поскольку она стала удобной для работы в крупных сетях, в том числе и провайдерской, то почему бы ее не использовать. Есть несколько схем ее использования. Та схема, которую многие считают единственной, выглядит примерно так: Монтажник, подключив розетку клиента, записал на кусочке мятой сигаретной пачки (условно) физический адрес, куда он его подключил. После этого он приходит в офис (условно) и сообщает оператору, куда подключен клиент. Оператор, заключив с клиентом договор, заносит параметры подключения в виде той самой опции 82, в профайл клиента, которые реализуются в виде настроек dhcp сервера. Возникает вопрос - вам больше нечем заняться, что бы таскаться туда-сюда с ручной работой. Компьютеризация (или, как модно говорить, диджиитализация) заключается не в наличие компьютеров и серверов, а в отсутствии "бумажной" работы. Если раньше человек что-то записывал в журнал, карточку, тетрадку, а потом поставили компьютер, он начал набивать туда - то это не "электронный документооборот", это та же бумажная технология. А вот если человеку поставили компьютер, и его услуги стали не нужны - это уже оно - диджитализация. В схеме, которую я реализовывал, монтажник тупо подключает розетку клиента к сети... и все. Уходит дальше работать. В этой схеме option 82 применяется только для одной функции - идентификации порта, к которому подключен клиент. Клиент заходит на портал со своими кредитами, система регистрирует ресурс клиента за его профайлом. DHCP сервер выдает лизы по mac/duid, хранит эти лизы по mac/duid. Лепить политику выделения пула по option 82 - дурацкая идея. Вместо этого ставится парсер dhcp пакетов (в любом варианте - dhcp-cap, dhcp-log). Парсер регистрирует автоматически выданные ip адреса за физическим адресом подключения, и заносит это дело в реестр биллинга. Все "ручные" (или "бумажные") технологии базируются на том, что монтажник/оператор/администратор изначально "где-та бирут" данные о физическом подключении клиента. Вот это "где-та бирут" - совершенно не нужные затраты и средств и добавление ненадежности в виде человеческого фактора. В "типичной" схеме с option 82 точно так же надо "где-то брать". Тут у меня подопечный провайдер месяц назад подключал пон сеть, принес в базу биллинга список из нескольких тысяч MАC адресов онушек. Спрашиваю - как будете узнавать, у кого какая онушка стоит? Говорит - у нас записано... В схеме vlan-per-user та же система. Монтажник впихнул клиента, "куда попало", и пошел домой. Клиент подключился, залогинился в портале, портал "посмотрел" по option 82, откуда клиент пришел, зафиксировал vlan за клиентом, и никому ничего не надо заранее на сигаретной пачке записывать. Хотя, эту схему можно и без option 82 реализовать, если есть преконфигурация vlan/ip-pool. Написал, наверно, длинно и бестолково. Если добавить сюда самостоятельную регистрацию клиента в биллинге, то надобность в офисе как бы и отпадает.

О! Вот оно. Именно при vlan-per-user оно очень полезно. Ежели, конечно, линейное оборудование умеет рассказывать про option 82.