vop

Наверно я плохо описал, зачем. Для идентификации подключения клиента. 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.

И да, там нет arp, ибо нет broadcast. Соответственно, нет arp proxy, бо не надо. Есть ndp. Иногда он весьма забавные вещи дискаверит.

Я когда-то пытался делиться идеями и наработками с авторами биллингов. Но почему-то они воспринимали меня конкурентом, и подозревали подвох. Хотя, в чем он, понять не могли... На общение не шли, и "крутили фиги в кармане". Ну как сказать? Ну, немного по другому. 1. В ipv6 нет броадкаста. Поэтому раскидывать адреса можно как угодно по одной штуке. 2. В ipv6 unnumbered как бы генетически заложено. Адреса еще биндятся к интерфейсам, но все они в одной куче с lo. Кстати, кто лет 25 назад настраивал на одном сервере slip/ppp и ether, не догадывались, что это называется unnumbered 3. На сабскрайберский линк внешние адреса можно вообще не давать. Да и не нужно. link-local достаточно. Если это vlan per user - то там вообще с клиентской стороны ставится дефолтный роутинг на fe80::1, а все остальное самонастроится. И последнее, опять же option 82. Готовьте ее правильно.

Под freebsd есть rtadvd и dhcp. Я не пробовал их. Попробуйте, расскажите - будет интересно людям. PS Или времена, когда народ делился опытом ушли в старину, и теперь не принято?

Зачем мне об этом спрашивать? Возможно, я совсем не точно выразился. Возможно я слишком лаконично написал. Если простенько. Приходит на микротик dhcp запрос с неизвестной ему option 82. Если есть парсинг, в какой реестр он занесет этот ресурс на дальнейшую идентификацию? Или просто пропустит мимо ушей? Мало кто знает, нафига придумывали option 82 - не все в RFC загялдывают. Да это и не важно, так-как на практике его используют для другого идентификации подключения. Но я встречал только два раза, когда эту опцию применяли не для костылей для стартового выбора ip-адреса из пула, а для нормальной автоматизации процесса идентификации подключения. PS Кстати, раз вы уже написали умных слов много в теме "про ipv6". Вы можете описать работы ipv6 unnumbered? Я на второй странице этого топика косвенно его вспоминал. А он довольно "полезный" для сетей ipv6.

Микротик умеет option82 parsing?

Ну, например, те провайдеры, которым я помогаю с биллингом, используют разную технику. От обычных компов со стандартными linux/freebsd в разных форм-факторах, и до железячных брасов, типа джунов, эриксонов и т.д. Правда, микротиков на доступе ни у кого нет. Что-то не очень они прижились. Когда-то были, сейчас нет.

У меня практических наработок мало. Я сейчас немного отдалился от провайдинга, а тестовый стенд состоит из двух телефонов, планшета и телевизора. Больше "клиентов" дома не нашлось. Как бы для написания плагинов хватает, а что посерьезней - уже не то... Хотя, подумаю.

Да, надо добавить, что при выдаче адресов клиентам по slaac надо выделить префикс /64 - там требуется 64 бита для того, что бы клиенты конструировали себе уникальные адреса. Каждый клиент, в общем случае, генерирует себе на интерфейсе 3 адреса - link-local - на основе мака, public на основе мака и public случайный, который и используется в общем случае. Это простокол для простой сети без саб-сетей. При выдаче по dhcpv6 -можно выдавать вообще отдельные адреса из разных сетей. В принципе. Если надо раздавать клиентам префиксы для их домашних сетей (а провайдеру это делать надо), то надо однозначно это делать при помощи DHCP. При этом как бы не важно, как будут раздаваться сами адреса для подключенных клиентов. Им можно вообще не раздавать, а оставить их работать на link-local (заодно из мира их не будет видно). А вот сам dhcp будет делегировать префиксы уже по клиентским DUID. Ваша задача, как провайдера с биллингом, поставить клиентский duid в соответствие с еего учетной записью. Т.е. тупо знать, кому принадлежит данный duid. Для этого есть все те же варианты - vlan, opt82... А по хорошему, надо бы написать текст, в котором описать возможные варианты работы сipv6 для провайдера. Все те "руководства" и блоги, которые есть в сети, в 90% описывать какие-то очень стандартные примитивы, которые тырят друг у друга.

У ipv6, опять же, свой собственный multicast. Он использует свой формат mac-адреса, если не ошибаюсь, 33:33:XX:XX:XX:XX и отличается от мультикаста в броадкатовой среде (FF:FF:FF:FF:FF:FF). Выдавать подсети клиентам, действительно, может DHCP. Так-что его ставить надо. А шейпить (говоря точнее, лкассифицировать) трафик можно по разным критериям - например по mac пакетов, по vlаn и т.д.

Попробую чуть "опрозрачнить" ситуацию.:) "Простой DHCP" - это уже как бы сложные навороты. Ибо slaac - это всего-лишь метод автоматического "само-по-себе-работающего" мехзанизма "само-придумывания" клиентами адресов. Со стороны абонента не надо делать вообще ничего, ибо оно само-конфигурируется на уровне ядра, и является, как бы, свойством стека v6. На стороне провайдера стовится достаточно простая программка radvd, которая мультикастит в сегмент обявление, что, мол, "я - роутер, префикс у меня для вас такой-то, а dns - такой-то". При этом ему пофиг, услышал ли его объявления кто-нибудь, или нет - абонентские устройства херачат сами по себе. А биллинг - он просто ведет учет, и ему пофиг, кто там чего поддерживает. Правда, в условиях "случайного" ip адреса у клиента, учет и управление его доступом надо делать, например, по MAC адресу, по vlan или по ppp-line interface. В общем-то, стандартный набор вариантов.

Для клиентских устройств этого достаточно. Насколько я в курсе, то не понимает. Не умеет ipv6-only. Только в компании с ipv4. Я думаю, затем же, зачем он нужен для любых других роутеров. Ну, ежели, использовать андроид для раздачи ipv6. slaac на данный момент не умеет делегировать префиксы... или я давно уже ничего не читал.:) Ну а для простого абонентского устройства - нет, не надо.

У меня андроид 9. Андроид умеет получать адреса по slaac. В свое время я пока до dhcp не дошел, не знал. Но потом выяснилось, что гугля считает, что там он не нужен. Можно поставить сторонний клиент на рутнутый андроид, но это уже не "свыстыть" https://issuetracker.google.com/issues/36949085 7 лет прошло, а поддержки так и нет.

Вы прямо как у меня дома побывали. Именно так и сделано, причем, "глухой" роутер - старый DSL-2640 наследство от укртелекомовских времен, заодно еще и wi-fi раздает.:) В принципе, нормальный подход. Такой себе switch+ap IPv6 раздает нормально. Когда я такое сделал, то у меня был цивилизационный шок от другого момента. Выяснилось, что Android не понимает ipv6-only и не умеет dhcpv6 от слова совсем.

Все зависит от клиентского устройства. 1. Современный путь - устройство поддерживает prefix delegation. Тогда ставится dhcpv6, и раздаются префиксы /64 /60 /56. 2. Полу-современный. Префиксы раздаются вручную, настраиваются в ручную, можно раздавать любые. Например /80. При этом сам роутер вообще может работать на ll-addr. 3. Совсем костыль - роутер умеет экзотический ipv6 bridge. Значить включается он, и устройства за роутером получают от браса адреса, так же, как и сами роутеры. Вроде ничего не пропустил. А в красивом случае, можно отставить только ipv6, поставив для хождения в 4-ю сеть dns64 и nat64.

А как через SLAAC вы пытались раздать сегменты /64 клиентским роутерам? PS И да, в ipv6 нет броадкастов. Там не надо настраивать /60 на vlan. Если я неправильно понял.

Хммм...

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

Пока самый толковый совет. Не сидел народ на спутниковом канале.:)

Дожились, уже без кина ничего не получается.:)

У меня достаточно тупо. Раздаются непубличные адреса, с которых можно только попасть в кабинет клиента. В кабинете проверяется, что клиент зашел из этой дежурной подсети, что opt82 никем не занята, после чего клиент подтверждает, что он хочет выходить в интернет с этого компа. И за ним регистрируется пара opt82, в конфиг прописывается class + host на время потухания изначальной лизы (либо адрес остается за ним, если ему не нужен реальный, то host не прописывается). Затем любые устройства, приходящие с парой opt82 автоматически подцепляются к клиентскому профайлу в качестве ресурсов. Если ресурс не использовался больше месяца после последней выдачи адреса, ресурс утилизируется.

Там бывает еще проблемка, что при назначении пары по opt82, сервер будет продлевать старую лизу. Deny не помогают. Ну так работает dhcp сервер. У меня это решается на добавлением в конфиг записи host с абонентским адресом на время, превышающее максимальный срок лизы.

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