КучаГен + MikroTik DHCP + (opt82)

[mstsc 7]

Доброго времени суток!

Осваивая функционал КучаГен больше всего привлек вариант описанный в мануале MikroTik DHCP (IP + MAC) http://wiki.ubilling.net.ua/doku.php?id=mgmikrotikdhcp 

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

В ходе тестовой реализации упираюсь в логический тупик. Не ясны два ключевых вопроса:

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

2. Как задействовать авторизацию на основе Option 82? Микротик без особого труда передает радиусу Remote-ID Circuit-ID но как их обработать в биллинге? 

[l1ght 377]

5 часов назад, mstsc сказал:

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

google it: users.conf DEFAULT

для понимания и вообще в принципе работы фрирадиуса

5 часов назад, mstsc сказал:

2. Как задействовать авторизацию на основе Option 82? Микротик без особого труда передает радиусу Remote-ID Circuit-ID но как их обработать в биллинге? 

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

авось и сами вразумеете, но подозреваю что как обычно с говнотиком не всё так просто ибо опт 82 это про DHCP, а там оно в связке с радиусом корявое донельзя

[mstsc 7]

8 часов назад, l1ght сказал:

users.conf DEFAULT

 

 

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

В мануале упоминается UHW_MLG. Один из пунктов в его описании "Ваш NAS/BRAS шлет radius accounting." Более менее развернутого описания нет. Не мой ли это случай?

Цитата

 в каких аТрибутах и как выглядят значения

 

Значения выглядят как и должны. И микротик эти данные передает без искажений и проблем. Если у Вас есть факт "корявости" работы этой связки, опишите в деталях. Я видел работающий вариант такой реализации на Abills. Тот же микрот, та же опция. 

rad_recv: Access-Request packet from host 10.1.2.7 port 44330, id=18, length=153
NAS-Port-Type = Ethernet
NAS-Port = 2207434909
Calling-Station-Id = "1:70:5a:b6:db:18:14"
Called-Station-Id = "server_B"
User-Name = "70:5A:B6:DB:18:14"
User-Password = ""
Agent-Remote-Id = 0x63656e7472616c5f3635
Agent-Circuit-Id = 0x30303032
NAS-Identifier = "MK"
NAS-IP-Address = 10.1.2.7

 

Відредаговано 2020-08-12 06:50:05 mstsc

[l1ght 377]

29 минут назад, mstsc сказал:

днако не затрет ли мне эти параметры сам Ubilling при регенерации базы

где база и где users.conf, ну

29 минут назад, mstsc сказал:

В мануале упоминается UHW_MLG. Один из пунктов в его описании "Ваш NAS/BRAS шлет radius accounting." Более менее развернутого описания нет. Не мой ли это случай?

ему как раз и нужен байпас авторизации (дефолт) в первую очередь, а дальше жертва уже ищется по аккаунтингу

30 минут назад, mstsc сказал:

Agent-Remote-Id = 0x63656e7472616c5f3635 Agent-Circuit-Id = 0x30303032

на основе чего я должен сгенирировать эти данные? как мне это увязать с конкретным абонентом?

31 минуту назад, mstsc сказал:

Если у Вас есть факт "корявости" работы этой связки

у меня есть факт корявости микротика и то что dhcp + radius наглухо игнорирует под и коа

[mstsc 7]

Цитата

на основе чего я должен сгенЕрировать эти данные? как мне это увязать с конкретным абонентом?

Agent-Remote-Id Agent-Circuit-Id вполне однозначно идентифицируют абонента, если, конечно, вы не пытаетесь через один порт авторизовать десяток человек. Попросту такая схема позволяет игнорировать конечный MAC адрес абона и позволяет безболезненно менять оборудование с сохранением IP. Вопрос безопасности такой схемы давайте опустим. Настройки устройств доступа позволяют избавляться от возможных проблем вроде два мака на порту и прочее. 

[l1ght 377]

ок, второй раз повторю

на основе чего я должен сгенирировать эти данные? как мне это увязать с конкретным абонентом?

или мне надо руками это назначать?

[mstsc 7]

8 минут назад, l1ght сказал:

ок, второй раз повторю

на основе чего я должен сгенирировать эти данные? как мне это увязать с конкретным абонентом?

или мне надо руками это назначать?

Мак свича доступа - константа. Даже в масштабной сети их не так много. Порт тоже совершенно предсказуемое значение будь то ethernet дырка или S/N онушки. Для радиуса эти данные нужно генерировать только в том случае, если они внесены руками в карточку абонента. В иных случаях - гостевой диапазон. 

К вопросу где увидеть фактические  Agent-Remote-Id Agent-Circuit-Id у не авторизованного абона. DHCP сервер микротика в Leases показывает эти данные.  

Відредаговано 2020-08-12 10:14:56 mstsc

[vop 370]

4 hours ago, l1ght said:

ок, второй раз повторю

на основе чего я должен сгенирировать эти данные? как мне это увязать с конкретным абонентом?

или мне надо руками это назначать?

 

Кхе... кхе...

 

В классике есть три варианта генерирования этих данных (т.е. закрепления за абонентом).

- монтажник на огрызке сигаретной пачки записывает, куда он воткнул абонента, а оператор потом заносит эти данные в настройки услуги абонента либо из заранее пре-конфигурированной базы, либо просто вручную набивает эти данные;

- монтажник при подключении абонента втыкает в порт свой ноут, нет, планшет/смартфон с ETH свистком, или соединяется через клиентский ви-фи, и в своей админке находит абонента и ставит галочку подтверждения работы с клиентского порта;

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

 

Так что у потребителя продукта надо бы выяснить пару восросов:

1. Он хорошо понимает, что он хочет получить?

2. Он знает, что могут быть другие варианты, которые можно понимать или хотеть?

Відредаговано 2020-08-12 14:27:28 vop

[mstsc 7]

Если я внесу opt82 руками в биллинг меня, как потребителя это устраивает. Если возможна автоматизация, Парсинг данных в том формате как сейчас это происходит для мак адресов - это уже перделки-свистелки. Основная проблема DHCP на микротике увязать с биллингом применяя опцию


Отправлено с моего iPhone используя Tapatalk

[vop 370]

И не забываем, что DHCP выдает адреса с привязкой к MAC-адресу. А тут могут быть варианты при втыкании нового оборудования. Их тоже три, но это уже другая песня.

[mstsc 7]

И не забываем, что DHCP выдает адреса с привязкой к MAC-адресу. А тут могут быть варианты при втыкании нового оборудования. Их тоже три, но это уже другая песня.

Если все настроено ориентируясь на опцию - новый мак получит IP абона и без вопросов заработает. Само собой есть тонкости. 1. Новый мак не получит сессию пока виза старого мака не закончится. 2. При появлении двух маков на порту это тоже превращается для DHCP в проблему.


Отправлено с моего iPhone используя Tapatalk

[vop 370]

Just now, mstsc said:

Если все настроено ориентируясь на опцию - новый мак получит IP абона и без вопросов заработает. Само собой есть тонкости. 1. Новый мак не получит сессию пока виза старого мака не закончится. 2. При появлении двух маков на порту это тоже превращается для DHCP в проблему.
 

 

В протоколе DHCP выдачи ip-адресов нет никаких опций 82. Сервер должен "знать" изначально, какой ip должен выдаваться каждому конкретному маку. Или выдавать свободный ip из пула неизвестному ему маку. Поэтому в этом случае есть три варианта:

 

1. DHCP выдает свободный адрес на новое оборудование, которое в дальнейшем остается за клиентом постоянно. MAC привязывается к клиентскому профайлу через opt92 (но это уже работа не DHCP сервера). Нормальный и канонический вариант.

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

3. Ставите DHCP сервер, которому вообще пофиг на все rfc, который не ведет лизы на duid, который является простой отвечалкой на набор данных (его можно у Вани взять). Ну тоже вариант, если он вам нравится и пока вас не начнут ломать, но это уже другая тема.

 

Ограничение на одну лизу на клиента или появление двух маков на порту - это не технологическая проблема. Это административная проблема своеобразного видения предоставления услуги, и тоже другая тема.

[mstsc 7]

49 минут назад, vop сказал:

 

В протоколе DHCP выдачи ip-адресов нет никаких опций 82. Сервер должен "знать" изначально, какой ip должен выдаваться каждому конкретному маку. Или выдавать свободный ip из пула неизвестному ему маку. Поэтому в этом случае есть три варианта:

 

1. DHCP выдает свободный адрес на новое оборудование, которое в дальнейшем остается за клиентом постоянно. MAC привязывается к клиентскому профайлу через opt92 (но это уже работа не DHCP сервера). Нормальный и канонический вариант.

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

3. Ставите DHCP сервер, которому вообще пофиг на все rfc, который не ведет лизы на duid, который является простой отвечалкой на набор данных (его можно у Вани взять). Ну тоже вариант, если он вам нравится и пока вас не начнут ломать, но это уже другая тема.

 

Ограничение на одну лизу на клиента или появление двух маков на порту - это не технологическая проблема. Это административная проблема своеобразного видения предоставления услуги, и тоже другая тема.

Спасибо за детальное разъяснение. Однако тема про другое. 

 

Изначальный вопрос стоит в следующем: При использовании связки Ubilling + DHCP сервер на устройстве Mikrotik возможно ли авторизовать абонента ориентируясь на Remote- и ID Circuit-ID?

 

[vop 370]

5 hours ago, mstsc said:

Спасибо за детальное разъяснение. Однако тема про другое. 

 

Изначальный вопрос стоит в следующем: При использовании связки Ubilling + DHCP сервер на устройстве Mikrotik возможно ли авторизовать абонента ориентируясь на Remote- и ID Circuit-ID?

 

 

Что значит про другое? Ответ на изначальный вопрос - конечно можно. Я как бы об этом и писал. Вам просто нужно выбрать вариант утилизации opt82 из перечисленных выше, либо придумать свой, и реализовать его. И в конце добавить необходимый инструментарий для реализации этого варианта хоть в рамках биллинга, хоть в виде отдельного модуля. Вон, у киевстара для этого сделана отдельная легковесная подсистема.

 

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

[mstsc 7]

 

2. DHCP выдает какой-то временный адрес на новый MAC, и после привязки этого мака к клиентскому профайлу ip-адрес заменяется на "правильный". Вариант имеет свои заморочки с перевыдачей адреса и немного некрасивый.
3. Ставите DHCP сервер, которому вообще пофиг на все rfc, который не ведет лизы на duid, который является простой отвечалкой на набор данных (его можно у Вани взять). Ну тоже вариант, если он вам нравится и пока вас не начнут ломать, но это уже другая тема.
 

А есть примеры реализации 2 варианта? Насколько далеко такая схема работы от штатных средств Ubilling?


Отправлено с моего iPhone используя Tapatalk

[Кеша 546]

Второй вариант работает из коробки в абилсе в связке с тем же accel-ppp.

Но accel это полноценный нас в отличии от....

Юбиллинг не изучал, но если он умеет radius pod, то также будет работать с ацелем очевидно на модном слове куча ген.

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

Третий вариант реализуется за день колупания с фрирадиусом, который умеет быть dhcp  сервером и также лазить в sql сам или с помощью perl. 

 

И учтите масштабируемость решения. Биллинг+accel лезет в базу только один раз при подключении, дальше accel сам продляет сессию, пока тело живое или пока не прилетит pod. Freeradius это не нас, он будет долбить биллинг каждый раз при продлении лизы. Что там микрот хз, надо проверять. 

Відредаговано 2020-08-15 05:29:10 Кеша

[mstsc 7]

В 12.08.2020 в 01:28, l1ght сказал:

google it: users.conf DEFAULT

для понимания и вообще в принципе работы фрирадиуса

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

авось и сами вразумеете, но подозреваю что как обычно с говнотиком не всё так просто ибо опт 82 это про DHCP, а там оно в связке с радиусом корявое донельзя

 

Как в конфигурации радиуса прописать гостевой пулл для неизвестных пользователей?

[mstsc 7]

Совместными усилиями решили задачу. Мануал добавлен на вики. http://wiki.ubilling.net.ua/doku.php?id=mgdefauth


Отправлено с моего iPhone используя Tapatalk

[vop 370]

Абзац в вики:

 

ВАЖНО: Перед DEFAULT не должно быть табуляций и пробелов, иначе при запуске RADIUS возникнет ошибка “Entry does not begin witch a user name Failed reading”

 

говорит о художественной натуре экспериментаторов.

 

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

[l1ght 377]

22 минуты назад, vop сказал:

говорит о художественной натуре экспериментаторов.

писал @mstsc, выложил почти как есть, главное - доходчиво

22 минуты назад, vop сказал:

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

спасибо за очень ценное мнение, мы обязательно учтем 

[nightfly 1 236]

1 час назад, l1ght сказав:

спасибо за очень ценное мнение, мы обязательно учтем 

[vop 370]

Страничка поэзии. Агния Барто. Фрагмент. Текст.

 

....

Мы с Тамарой ходим парой,
Санитары мы с Тамарой.

 

Если что-нибудь случится,
Приходите к нам лечиться.

 

Мы умеем класть компресс:
Мы с Тамарой Красный Крест.

....

 

[Vitaliy1984 5]

доброго времени суток пытаюсь настроить MikroTik DHCP (IP + MAC) по мануалу  http://wiki.ubilling.net.ua/doku.php?id=mgmikrotikdhcp  при вводе команд ниже указанных 

mysql -u root -p stg < ./docs/multigen/dump.sql

mysql -u root -p stg < ./docs/multigen/radius3_fix.sql

просит Enter password  пробовал вводить пароль от mysql   выдает ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
You have new mail.

подскажите что я делаю не так

 

[Інет.укр 112]

10 часов назад, Vitaliy1984 сказав:

доброго времени суток пытаюсь настроить MikroTik DHCP (IP + MAC) по мануалу  http://wiki.ubilling.net.ua/doku.php?id=mgmikrotikdhcp  при вводе команд ниже указанных 

mysql -u root -p stg < ./docs/multigen/dump.sql

mysql -u root -p stg < ./docs/multigen/radius3_fix.sql

просит Enter password  пробовал вводить пароль от mysql   выдает ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
You have new mail.

подскажите что я делаю не так

 

невірний пароль вводите

[Vitaliy1984 5]

А пароль вводиться от mysql ?