Биллинговая система Nodeny

Здравствуйте уважаемые форумчане!
 Кто как решает проблему управления NAS микротик ? Тот модуль что есть hw_mikrotik.pl управления через API mikrotik глючной сильно. Есть несколько  микротиков с авторизацией по ip, поскольку микротик не умеет работать с радиус сервером по ip, да и по pppoe не умеет передать параметры шейпера, необходимо как то управлять списками ip и шейперами.
 Собственно и вопрос кто как решает эту проблему.

Решаем очень просто - не используем RouterOS в качестве NAS

Это конечно суперовое решение только как быть есть NAS в виде микротика 450 висит на 50 метровой высоте принимает канал от провайдера и сразу его раздает юзерам? сервак завесить на мачту ?

использовать его в качестве каналообразующего оборудования.

эм? )

он может работать c ppp,dhcp + hotspot + wireless регистрация

Напишите как по dhcp с проверкой через радиус по базе билинга выдать ip юзеру и содать шейпер?

нужно создать dhcp-server с опцией Use Radius, дальше дело за вашими конфигами.
если нет опыта работы с sql и радиусом, то могу быть уверен, что не настроить не получится

Начать стоит с этого:
http://wiki.mikrotik.com/wiki/Manual:RADIUS_Client

еще сюда
http://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Server

и немного расстроиться

Точно в цель)
Но конечно же хочется одной опой сесть на 2 табуретка при минимальных расходах на оборудование.

Вот вы советуете использовать каналообразующее оборудование, и еще тянете прикола про жопу. Так вот будьте любезны поделитесь своим умом и напишите схему как можно притянуть все каналы с NAS в сервер если они разбросаны территориально по всей области на каждом свой канал от разных мобильных опсосов, L2 нету и быть не может. ТУ жесткие по установке оборудование как в контейнере так и на вышке опсоса, куда сервант втулить? в поле закопать в землю? ставить свой контейнер? это все ради того что никто не шарит как грамотно без глюков связать нодени и микротик?

Dhcp radiusd не умеет создать адрес лист. потому не получиться управлять доступом. Авторизирует, скорость нарежет, а как с правилами фаервола?  Выход видеться только 1 - юзать ssh для управление МТ....

не ssh, а api

и доставить ethernet фреймы вы можете с помощью ether over ip туннеля, это вариант №1
аналогично вы можете связать туннель микротика с freebsd, ip to ip туннель прекрасно работает в связке МТ + Фрибсд.

и в третьих у меня в todolist реализовать эту шляпу, правда на php.
3 месяца вроде работает, не глючит.

API тормознутое, вот в чем и все баги. Когда 100 человек не вопрос все четко, когда будет 1500 увидете как оно работает. Даешь команду добавить адрес лист не добавляет, удалить не удаляет. Все эти танцы с АРІ до сраки честно вам скажу проходил. Тунели тоже не выход зачем гонять трафик от БС к серваку и обратно? Каналы то не по 15 грн за мегабит, шибко дорогое удовольствие. Как не крути со всех сторон жопа... необходимо наверно перевести всех юзеров на pppoe и с помощью радиуса управлять NAS списками и скоростями.

так работало очень даже отлично, много настраивать не нужно

Очень плотно общались с Сергусом (тот кто отвечает на саппорте Тиков) на Московском MUM, потом долго объясняли где у Тика нужно делать по другому авторизацию. Они ограничились  DHCP-Relay и ничего больше не хотели слышать. Сейчас, вроде, обещали внедрить возможность управления через модуль DHCP-Radius акцесс-листами о Шейпером. Когда это будет, сказать сложно, да и навряд ли работать будет сразу нормально.

Проблема API не стоит, я писал в теме "Разработка" в таком же сабже. Мы тестировали API на другом очень простеньком биллинге, однако, там очень много сил потратили именно на стек с Тиком по API (биллинг MikroBill). Даже на 3000 пользователях синхронизация не глючит и не зависит от качества канала. К сожалению, разработчик писал всё на фраемворках под Виндовс и не смог перенести свою идею на отдельный модуль под НоДени и вообще на Линукс..
Так что, проблема точно не в API.

Тема открыта, нам тоже нужен модуль взаимодействия, могу предложить объединить финансовые затраты что бы разработка была привлекательной для девелопера.

Если поставишь грамотное ТЗ, то думаю, что напишу очень быстро. Более того, протестим в твоей сети и походу оптимизируем и избавимся от проблемных мест.

Естественно, только под NoDeny+

Прочитал, что модуль может управлять несколькими mikrotik`ами.
Как билинг понимает за каким из микротиков находится тот или иной абонент? Через назначения групп на странице клиента?
А если поменять группу, то интернет у клиента пропадет?
IP pool тоже назначается из билинга и как?

В свойствах группы, есть поле "Имя идентификационного поля, если не указано, то принимается «логин»", может через него? Где прописывать индификатор?

Сам отвечу: ;D
Модуль не разделяет клиентов по сетям, микротикам. Модуль отправляет данные всех клиентов, что созданны в билинге.
А именно:
1) IP+MAC, отправляется в Mikrotik в IP-DHCP Server-Leases - все IP и все MACи, что когда либо были созданы в билинге.
2) Firewall-Adress Lists - сюда отправляются IP адреса с подписью goodboys. Тоесть те, кому разрешен доступ в Интернет.
3) Queues - суда отправляются IP и скорости клиента. Скорость берется с Первой скорости(Входящая/Исходящая скорость 1) в услуге.

Что заметил:
а) Переключаю клиента с билинга(IP .155.240) в Микротик(IP .30.254).
Даже билинг както понимает, что клиент в сети. "Последнее обновление авторизации 13 сек назад" постоянно обновляется.
Пока в билинге у клиента светится "зеленый ключик" возле IP, в Mikrotik в Firewall-Adress Lists отправляется запись с IP и подписью goodboys. То есть доступ разрешен.
После того, как клиент пошел спать, выключил комп, он пропадает из поле зрения билинга. "Зеленый ключик пропадает", цифры растут в "Последнее обновление авторизации". В Mikrotik пропадает запись из Firewall-Adress Lists.
Клиент включает комп, а доступ в Интернет не получает. При поиске причины, выяснилось, что что в Firewall-Adress Lists не попадает запись с IP+goodboys. Если ее создать вручную, то уже через 5секунд клиент получает доступ в Интернет.
При последующем поиске определил, что запись в Firewall-Adress Lists попадают только о тех клиентов, которые в данный момент в билинге имеют "зеленый ключик".
А так как, клиент подключен к Mikrotik`у, билинг не может понять клиент в офлайне или онлайне. И доступа в Интернет он не получает.
Решение:
1) Научить билинг понимать, что за Mikrotik`ом, клиент в сети.
2) Отправлять IP в Firewall-Adress Lists тех у кого в билинге "Заблокирован:НЕТ", а не тех кто сейчас в сети(с зеленым ключиком)
3) ?

Ктото решил проблему с ping`ом из билинга на клиента за Mikrotik`ом?

йа )