Користувальницькькі налаштування

Налаштування сайту


Сайдбар

Розділи

Загальний опис
Історія змін
Рекомендації до оновлення
Плани на майбутнє
Відомі проблеми
Онлайн демо
Відео
Допомога проекту
Люди
Трохи про безпеку

FAQ



Редагувати сайдбар

mgmikrotikdhcp

Авторизація абонентів DHCP на MikroTik методом IP + MAC за допомогою КупаГен

Відразу слід зазначити, що інформація нижче створена більше для розважальних цілей в загальноосвітніх цілях і до застосування в реальному житті рекомендується не дуже. Тому ми приймаємо як даність, що всі, хто все ж таки наважиться застосувати це в продакшині, найімовірніше, розуміють усі можливі біль і безвихідь наслідки й обмеження, з якими вони неодмінно зіткнуться:

  • Абсолютна неможливість будь-якого управління абонентом після отримання ним DHCP lease від мікротіка. Ніяких CoA і PoD. Тільки таймаут виданого лізу може змінити стан підключення абонента.
  • Обов'язкове використання фаєрволла і address lists для надання/обмеження доступу абоненту. Ну або будь-яких інших хитрощів на ваш смак.
  • Ніякого Walled Garden та інших зручностей, як у того ж HotSpot. Так що, наприклад, перенаправлення боржників будете майструвати самі.

Водночас не можна не відзначити і позитивних моментів (такий собі острівець надії посеред темряви і смутку):

  • Простота реалізації. Застосування мозку глибоких розумових процесів практично не потрібно.
  • Дуже велика (практично ідентична) схожість у роботі Ubilling з Mikrotik за API і авторизацією IP + MAC. Тільки IPшки і address lists тепер видає радіус, а не Ubilling.

Конфігурація Ubilling

Вже має бути налаштований КупаГен.
Не забуваємо додати словник для Mikrotik в /usr/local/etc/raddb/dictionary

$INCLUDE        /usr/local/etc/raddb/dictionary_preset/mikrotik.dictionary

Після чого перезапускаємо FreeRADIUS

Налаштовуємо білінг стандартно як і для будь-яких інших пристроїв

у довіднику (мережі та послуги) додаємо мережі, створюємо послуги (тип мережі можете вказати як “DHCP static” або “Other type”)

додаємо NAS

У конфігурації КупаГен для нашого NAS налаштовуємо атрибути:

Як уже згадувалося вище - для NAS MikroTik + DHCP НЕ працюють Coa\PoD, тому відключаться\включаться абоненти будуть після закінчення lease time (Session-Timeout). Час виберіть відповідний для себе. У нашому прикладі абоненти, у яких баланс позитивний, отримуватимуть IP на 2 години.

Конфігурація Mikrotik

Вмикаємо RADIUS, і його роботу з DHCP

У полі Address вписуємо адресу нашого Ubilling (адже саме там живе наш радіус?). У полі Secret вводимо секрет, який можна подивитися в Ubilling:

На інтерфейс, який дивиться в бік клієнтів, вішаємо мережу:

І створюємо на цьому ж інтерфейсі dhcp-server (у полі Address Pool вказуємо static-only. У полі Use RADIUS ставимо yes):

В IP → DHCP Server → Networks Налаштовуємо, додаємо нашу абонентську мережу і вказуємо адреси Default gateway і DNS, які будуть видаватися клієнтам:

Базове мінімальне налаштування завершено. Тепер абоненти отримуватимуть IP з білінгу. Абоненти з позитивним станом рахунку будуть додані в IP → Firewall → Address-List, у список ALLOW, а з негативним, відповідно, в NOT_ALLOW. Список ALLOW логічно випустити в інет у фаєрволі, тоді як для NOT_ALLOW - заблокувати доступ в інет там же. Зробити це можна якось так:

Отримання графіків зі статистикою трафіку абонента з Mikrotik

Якщо ви дуже хочете отримувати графіки зі статистики трафіку абонента з Mikrotik так само, як під час роботи з Mikrotik через API, можете використати наступну костиль:

Вмикаємо опцію alter.ini

MULTIGEN_USE_ROS_TRAFFIC_GRAPHS=1

Далі:

Коли DHCP-сервером у нас сам Mikrotik NAS - DEPRECATED і наполегливо не рекомендується до використання

Отже, оскільки у цього методу раптово (за майже рік, ага) було виявлено ФАТАЛЬНИЙ НЕДОЛІК, який полягає в тому, що мікрот запускає цей скрипт тільки в момент БЕЗПОСЕРЕДНЬОГО отримання девайсом DHCP-лізу і НЕ запускає його під час автоподовження (автооновлення) лізу. Це призводить до того, що якщо у користувача девайс (скажімо, роутер) увімкнено постійно, а ліз він не переотримує, а автоматично подовжує, то, наприклад, у разі зміни тарифу у користувача зміни лімітів швидкості в шейпері не відбудеться НІКОЛИ. Ну, принаймні доти, доки його пристрій фактично не отримає DHCP-ліз заново .

У зв'язку з чим настійно рекомендується у всіх випадках використовувати оновлений і ретельно протестований (але це не точно) скрипт для Mikrotik NAS у режимі RELAY

Тобто - так - навіть коли DHCP-сервером у нас сам Mikrotik NAS - використовуємо методологію та скрипт для Mikrotik NAS у режимі RELAY.

А цю штуку залишимо суто для розуміння “яким чином хотілося б, щоб воно працювало”.“

в Mikrotik NAS НЕ додаємо

  • в System → Scripts скрипт приблизно такого змісту (назвемо його, скажімо, SimpleQueueRebuild)
  1. # getting global vars
  2. :global leaseBound;
  3. :global leaseActIP;
  4.  
  5. :local speed "";
  6. :local newSpeed "";
  7. :local queueRec "";
  8. :local alreadyExists false;
  9.  
  10. :if ($leaseBound = 1) do={
  11. /queue simple
  12. # looking for an "incorrect" queue simple rec with currently leased IP
  13. :foreach tQueue in=[/queue simple find where (target="$leaseActIP/32" && name!="mlg_$leaseActIP")] do={
  14. # if "incorrect" queue rec was found - then we need to get it's speed
  15. # 'cause it may be a tariff change and new speed settings may appear
  16. :set newSpeed [get $tQueue max-limit];
  17. remove $tQueue;
  18. }
  19.  
  20. # looking for a "correct" queue simple rec with currently leased IP
  21. :foreach tQueue in=[/queue simple find where (target="$leaseActIP/32" && name="mlg_$leaseActIP")] do={
  22. :set queueRec [$tQueue];
  23. :set speed [get $tQueue max-limit];
  24. :set alreadyExists true;
  25.  
  26. # if $newSpeed is still empty - then no incorrect record was found
  27. # and we need to make $newSpeed and $speed equal to avoid excess speed change action
  28. :if ($newSpeed = "") do={
  29. :set newSpeed [$speed];
  30. }
  31. }
  32.  
  33. # if any of "speeds" were set - we need to perform some actions
  34. # otherwise we can't do a thing
  35. :if ($speed != "" || $newSpeed != "") do={
  36. # if found queue has correct name - just check it's speed and correct if needed
  37. # else - create a new queue with correct name and speed
  38. :if ($alreadyExists) do={
  39. :if ($newSpeed != $speed) do={
  40. set $queueRec max-limit=$newSpeed disabled=no;
  41. } else={
  42. :log warning ("mlg_ changer: nothing to change for $leaseActIP - already exists with such speed");
  43. }
  44. } else={
  45. add name="mlg_$leaseActIP" max-limit=$newSpeed target="$leaseActIP/32";
  46. }
  47. }
  48. }
  • в IP → DHCP Server → DHCP у конфіг DHCP-сервера в секцію Lease script (вкладка Script у пізніших версіях ROS) назву щойно створеного скрипта SimpleQueueRebuild.

Логіка роботи цього скрипта така: у момент видачі DHCP-lease абоненту ми шукаємо в simple queues запис із таким самим IP, який ми ось зараз видаємо, і правимо цей запис під свої потреби: точніше - видаляємо і додаємо такий самий, але з потрібними нам параметрами. І так, дуже важливо зазначити, що наявність префікса mlg_ у найменуванні simple queue-запису - строго ОБОВ'ЯЗКОВО.
Звісно, це тільки приклад, і у своєму конкретному випадку ви можете модифікувати його під ваші завдання і реалії (наприклад, встановлювати burst'и та інше).


Коли DHCP-сервер у нас десь там, а сам Mikrotik NAS - всього лише relay

Цей спосіб, до речі, може підійти і для MikroTik IPoE (Hotspot)

Як і в попередньому випадку в Mikrotik NAS додаємо

  • у System → Scripts скрипт приблизно такого змісту (назвемо його, скажімо, SimpleQueueRebuild)
  1. :local qSpeed "";
  2. :local qTarget "";
  3. :local qIP "";
  4. :local currentSpeed "";
  5. :local leaseDynPrefix "dhcp-ds<";
  6.  
  7. /queue simple
  8. # get all of the simple queues which have no "mlg_" prefix in their names
  9. #:local tQueueList [find where (name~"^mlg_" = false)];
  10.  
  11. # get all of the simple queues which have no "mlg_" prefix in their names but do have $leaseDynPrefix
  12. :local tQueueList [find where (name~"^mlg_" = false && name~$leaseDynPrefix)];
  13. :local tQueueMLG "";
  14.  
  15. # if some of the simple queues with no "mlg_" prefix in their names found
  16. :if ([:len $tQueueList] > 0) do={
  17. :log warning ("Not mlg_ queues found: " . [:len $tQueueList]);
  18. # conditionally step through the list
  19. # get the necessary prameters into local vars
  20. # remove the "incorrectly" named queue rec
  21. :foreach tQueue in=$tQueueList do={
  22. :set qSpeed [get $tQueue max-limit];
  23. :set qTarget [get $tQueue target];
  24. :set qIP [:pick [:tostr $qTarget] 0 [:find [:tostr $qTarget] "/"]];
  25.  
  26. remove $tQueue;
  27.  
  28. # try to find simple queue with such IP address and "mlg_" prefix
  29. :set tQueueMLG [find where (name="mlg_$qIP")];
  30.  
  31. # as far as we can rely on that fact that simple queues names are unique
  32. # we can be sure that there will be only one rec with such IP address and "mlg_IP" prefix
  33. # and so if we found one - we can just change it's speed, enabled status and (just in case) - target IP
  34. # and not to create new one
  35. :if ([:len $tQueueMLG] > 0) do={
  36. :foreach eachQueueMLG in=$tQueueMLG do={
  37. :set currentSpeed [get $eachQueueMLG max-limit];
  38.  
  39. :if ($currentSpeed != $qSpeed) do={
  40. set $eachQueueMLG max-limit=$qSpeed target=$qTarget disabled=no;
  41. } else={
  42. :log warning ("mlg_ changer: nothing to change for $qIP - already exists with such speed $qSpeed");
  43. }
  44. }
  45. } else={
  46. # create a new queue with correct name and speed
  47. add name="mlg_$qIP" max-limit=$qSpeed target=$qTarget;
  48. }
  49. }
  50. }
  • далі йдемо в System → Scheduler і створюємо там завдання, яке запускатиме наш SimpleQueueRebuild, скажімо, раз на 30 сек. Можна й частіше. Можна і рідше - цілком на ваш смак.

По суті, ця штука слідує за тим самим принципом, що й попередня, тільки ось через те, що DHCP lease видається не нашим НАСом і “спіймати”, власне, цей момент ми не можемо - ми проводимо періодичну перевірку на наявність “неправильних” найменувань шейперів і робимо з них “правильні”….

Варто зазначити, що змінна leaseDynPrefix покликана відфільтрувати вибірку записів simple queue, обмеживши її лише тими, у найменуванні яких присутній префікс dhcp-ds< - саме так іменував динамічно створені записи simple queue мікротик, на якому цей скрипт тестували, і БАЖАНО ВЗЯТИ ДО УВАГИ, що у вашому конкретному випадку цей префікс може ВІДРІЗНЯТИСЯ. У принципі - ви взагалі можете не покладатися на цю змінну і не використовувати її, закоментувавши в скрипті рядок 12 і розкоментувавши рядок 9.

І звичайно ж, потрібно не забути про дуже важливий момент, а саме про те, що наявність префікса mlg_ у найменуванні simple queue-запису - строго ОБОВ'ЯЗКОВО.

Чи варто говорити, що якщо у вас на якомусь конкретному мікротикоНАСі в simple queue є якісь свої, потрібні вам записи - то наведений вище скрипт не зупиниться ні перед чим, аби переробити їх повністю. Тож - обережніше в продакшені, а додаткове фільтрування в нього впроваджуйте вже самостійно…


Вмикаємо самі графіки на Mikrotik NAS

Ну і, як показує практика, потрібно не забути ввімкнути ці самі графіки на кожному окремому Mikrotik NAS. Зробити це можна таким чином:

Tools → Graphing

Натискаємо “Graphing Settings

і встановлюємо бажану частоту збору та запису статистичних даних. Зазвичай це - 5 хвилин. Багатьом, напевно, хотілося б частіше, але Мікротік поки частіше не вміє.

Далі звертаємо увагу на вкладки “…. Rules

тут ми можемо вказати деталі збору статистики (для сутностей типу інтерфейси, правила шейперів і системні ресурси) і доступу до цієї статистики. Оскільки нас цікавлять графіки трафіку наших юзерів - нам потрібна вкладка “Queue Rules”. Тикаємо по ній, потім по кнопці з синім плюсом “Додати”:\

і додаємо правило для наших майбутніх графчиків:

  • Simple Queue - шейпери, для яких буде збиратися статистика. Тут логічно залишити all.
  • Allow Address - адреса/підмережа з яких буде дозволено доступ до цих графіків. Логічно вказати тут адресу нашого Убіллінг сервера. Значення 0.0.0.0.0/0, природно, дозволить доступ усім.
  • Store On Disk - чи зберігати дані статистики на диску. Краще ввімкнути - адже ми не хочемо, щоб під час кожного перезапуску НАСу в нас обнулялася стата?
  • Allow Target - дуже цікава опція, що визначає, чи дозволено користувачеві, чия стата збирається цим правилом, дивитися свою ж статистику. Якщо вашим користувачам дозволено доступ до http://ROS_NAS_IP/graphs/ і цю опцію ввімкнено - вони зможуть бачити кожен свій графік. ІРЛ таке, як правило, не практикується.

Тепер, коли “графічкова тулза” у нас налаштована і правило збору стати додано - можемо перейти на http://ROS_NAS_IP/graphs/ і споглядати там наші графічки. А якщо не споглядаємо - значить, щось не так і йдемо переробляємо, бо в такому разі в Убілінгу ми їх, найімовірніше, теж не побачимо. Ну або ми забули додати в Allow Address адресу свого хоста, з якого намагаємося ці графічки побачити.

Копірайт

Окрема подяка за допомогу у створенні цього мануала - mohax_kh_ua
Головний мікротико-скрипто-тестер - reductor

mgmikrotikdhcp.txt · Востаннє змінено: 2023/09/04 19:34 повз bobr