Настраиваем биллинг UTM с Mikrotik
В этой статье мы опустим пояснение, что такое биллинг, как устроены системы учета трафика, что такое VoIP-биллинг или зачем это все необходимо. Мы остановимся на конкретно взятом программном и аппаратном обеспечении, достаточных для создания современной, мощной и масштабируемой системы учета работы пользователей в сети Интернет. Предполагается, что читатель уже знаком с общими понятиями, которыми мы будем оперировать дальше.
Классификация
Из всех представленных на современном рынке биллинг-систем можно выделить уже несколько устоявшихся и признанных решений среднепровайдерского уровня, к которым относятся следующие: Бесплатные или условно бесплатные:
-FreeNibs;
-http://netbilling.nm.ru;
-NeTAMS;
-Abills; и д.р.
Платные:
-NetUP UTM;
-IPSoft Billing;
-LANBilling;
-Traffic Inspector; и д.р.
Для лучшего понимания текущей классификации современных биллинг-систем взгляните на эту схему:
Общая структура биллинговых систем.
В случае с использованием авторизации пользователей, отличной от Radius, практически всегда в биллинг уже встроены средства снятия, обработки и записи наработанной статистики своими внутренними средствами. Если же NAS (Network Access Server) и сам биллинг разнесены на разные компьютеры, то для снятия статистики используются уже проверенные средства: с помощью Alive пакетов от NAS сервера, протокола SNMP (Simple Network Monitoring Protocol) или NetFlow. Использование протокола NetFlow (протокол, разработанный компанией Cisco специально для мониторинга сети) позволяет получать подробнейшую информацию о сетевой активности пользователей. Именно поэтому данный способ сбора статистики является основным для построения мощных и отказоустойчивых систем.
Поставленная задача
Нам необходимо установить и настроить систему учета работы пользователей Интернет, используя биллинг UTM5 и программно-аппаратную платформу FISC MTIK Mikrotik RouterOS, которая будет обслуживать одновременно до 300 пользователей. В нашем случае выбор UTM5 очевиден. За сравнительно малой ценой кроется высокий потенциал, который можно будет в полной мере раскрыть при создании тарифных планов, работе с клиентами, создании отчетов и другими аспектами работы системы. Для сбора статистики будем использовать технологию NetFlow, для хранения информации базу данных MySQL. В качестве операционной системы для биллинга выберем Debian Etch. Выбор операционной системы лучше останавливать на той, которую вы достаточно хорошо знаете.
Вкратце опишем схему работы нашей будущей системы:
Структура взаимодействия UTM c NAS
Сервер доступа при поступлении запроса от клиента на подключение обязан будет передать их Radius-модулю биллинга. Последний должен обратиться к ядру, чтобы получить от него разрешение на авторизацию, и в случае положительного ответа, другие параметры: адрес клиента и скорость. После подключения, сервер доступа будет в режиме реального времени передавать всю информацию о трафике с сетевых интерфейсов ядру биллинга, которое при наступлении условия отключения пользователя отправит сигнал в модуль Firewall, который получит доступ к командной строке сервера доступа и сбросит нужного клиента или заблокирует ему доступ.
Данная схема прозрачна и надежна, что подтверждает ее широкое применение на практике. Использование в качестве сервера доступа операционной системы Mikrotik во многом обусловлено низкой стоимостью одной лицензии, удобных способов настройки, надежностью. К тому же в ней изначально встроены средства для работы с NetFlow и авторизации пользователей по протоколу Radius.
Описание аппаратной части
Так как обычно число клиентов у суб-провайдеров относительно мало, то логично было бы использовать наиболее оптимальное оборудование в плане надежности и стоимости, позволяющее реализовать необходимый уровень предоставления услуг и охватывающий наибольшее количество решаемых задач. Учитывая то, что нам потребуется минимум два сервера, необходимо определиться с их конфигурацией, основываясь на спектре решаемых ими задач.
Для биллинг-сервера мы используем компьютер следующей конфигурации:-процессор: AMD Athlon XP 1700+;
-память: 2 Гбайт;
-жесткие диски: 3 х 200 Гбайт SATA в программном RAID 5;
-блок питания: 450 Вт;
-сетевая карта: любая, желательно с аппаратной обработкой пакетов на чипах 3com, Intel;
-корпус: любой с хорошей вентиляцией.
Такие системные требования обусловлены тем, что этот сервер будет нести основную нагрузку, а также являться "хранилищем" нашей системы. Ему придется обрабатывать большие объемы информации о наработанной статистике, авторизировать пользователей и отключать их в нужные моменты, предоставлять доступ к генерации отчетов в режиме реального времени.
Особое внимание стоит обратить на жесткие диски. Использование программного или аппаратного RAID строго обязательно, если вы не хотите в один прекрасный день потерять информацию о трафике или клиентах. Также стоит предусмотреть возможность резервного копирования данных на внешние носители. Не стоит экономить и на оперативной памяти, так как в нашем случае в именно от нее будет зависеть скорость работы сервера в целом.
В качестве серверов доступа (NAS) логичнее всего будет использовать уже готовые платформы, поставляемые самими разработчиками Mikrotik или же сторонними производителями. В нашем случае мы будем использовать платформы Lex, поставляемые компанией Ниеншанц - Телеком с предустановленной лицензионной версией RouterOS Mikrotik.
Выбор в пользу такого решения приведем следующие аргументы:- производительности платформы достаточно для решения наших задач;
- система имеет очень скромные габариты и может быть легко установлена даже в самом ограниченном пространстве;
- большая гибкость, масштабируемость и надёжность системы;
- отсутствие подвижных частей (кроме жесткого диска), и, как следствие, практическое отсутствие шумов и износа;
- достаточная устойчивость и проверенная временем надежность;
- наличие трех Ethernet-портов, что легко позволит в случае надобности организовать DMZ-зону или настроить маршрутизацию между сетями;
- малая потребляемая мощность;
- наличие лицензионной версии операционной системы Mikrotik на Flash карточке.
Этот список можно продолжать и дальше, однако давайте на самом деле убедимся, хватит ли нам производительности этой платформы и на чем основана сказанная выше "стабильность".
Аппаратная платформа
В нашей самой первой статье об операционной системе Mikrotik мы использовали для тестирования компьютер на базе процессора Pentium 166 МГц с поддержкой инструкций MMX. Остальная конфигурация также не блестала: 200 Мбайт жесткий диск, 128 Мбайт ОЗУ и две сетевые карты. Всего этого вполне хватало, чтобы передавать пакеты из одного места в другое. В связи с этим не стоит удивляться малой вычислительной мощности рассматриваемого маршрутизатора. В его арсенале числится 500 МГц процессор VIA C3 и системная плата, куда он впаян, остальные компоненты (модуль памяти, жесткий диск) вам придется установить самостоятельно.
Материнская плата от Lex System не позволит собрать на ее основе суперфункциональный "комбайн", как в случае обычной системной платы, но зато она отлично подходит для возложенных на нее задач. Рассмотрим характеристики платы более подробно:
процессор - VIA C3 (500 МГц, 376 PIN, EBGA);системная шина - 100/133 МГц;
чипсет - VIA PLE133 (VT8601 + VT82C686B);
интегрированное графическое ядро с возможностью выделения 8 Мбайт памяти;
один слот памяти PC133 SDRAM максимальным объемом до 512 Мбайт;
звуковой кодек AC'97 2.1;
-три сетевые карты 10/100 Мбит/с на основе контроллеров Realtek RTL8100B;
-один IDE-разъем для подключения двух устройств (с поддержкой UDMA100);
-один 44-жильный IDE-разъем для подключения жестких дисков форм-фактора 2.5";
-один разъем DOC(Disk-On-Chip);
-один 50-контактный разъем для подключения флэш-карт формата CompactFlash.
Процессор, как мы упоминали выше, заменить не удастся. Его производительность по современным меркам довольно низкая, однако для одновременного обслуживания 80-150 клиентов её хватит.
Материнская плата Lex CV860. Общий вид
И действительно, если взглянуть на роутер в разобранном виде, то обнаружить каких-либо движущихся частей не удастся. Процессор и чипсет прекрасно обходятся пассивным охлаждением, чего вполне достаточно и к тому же снижает конечную стоимость девайса.
Чипсет VIA PLE133 был представлен несколько лет назад, и может работать с процессорами Intel Pentium III, Intel Celeron (под Socket 370) и VIA C3. Что касается типа поддерживаемой памяти, то это SDRAM (вплоть до PC133), что в свете скорого перехода на DDR3 выглядит совсем уж архаично. И дело здесь не в низкой скорости (современные двухканальные контроллеры способны обеспечить в 12 раз большую пропускную способность), сколько в том, что найти в продаже SDRAM-планки памяти будет достаточно сложно. Причем она почти гарантированно будет из разряда б/у. Пожалуй, это единственный серьезный минус этого чипсета по отношению его использования в роутерах.+
Знать остальные возможности PLE133 для нас необязательно, но для интересующихся вкратце перечислим их. Чипсет содержит встроенное графическое ядро класса UniChrome. Имеется поддержка звуковых кодеков AC'97, до четырех портов USB 1.1 (через южный мост VIA VT82C686B), двух каналов UDMA100, а также 10/100 Мбит сетевой карты (при установке специального чипа-компаньона на плате).
Дизайн платы спроектирован полностью в соответствии возлагаемыми на роутер задачами.
Сетевые контроллеры Realtek RTL8100B
Сразу в глаза бросается три сетевых контроллера Realtek RTL8100B. При необходимости все их можно задействовать.
Разъемы IDE, DOC и CF
Еще из неординарных для обычного компьютера решений можно отметить возможность подключения ноутбучного жесткого диска без переходника. Специально для него распаян 44-контактный разъем IDE. Рядом с ним соседствует стандартный 40-контактный IDE, разъем DOC (Disk-On-Chip) и специальный слот для карт памяти CompactFlash. Присутствие последнего особенно радует, так как в системе он обозначен как еще один IDE-канал. Поэтому, устанавливая туда флэш-карту, она будет распознана как еще один жесткий диск. Следовательно, ничего не помешает установить на нее операционную систему. Таким образом в роутере вообще не будет никаких движущихся механизмов, что снижает не только шум, но и повышает надежность.
К сожалению, неизвестно, карта какого максимального объема поддерживается платой. Сегодня их емкость достигла 8 и более Гбайт, чего вполне хватит для установки роутерных операционных систем.
Разъем памяти SDRAM
На краю платы расположен единственный разъем для модуля памяти SDRAM.
Разъемы на задней панели платы
На заднюю панель плату выведены следующие разъемы:
-12-вольтовый разъем питания;
-два PS/2 для клавиатуры и мыши;
-два USB 1.1;
-три разъема RJ-45 (Ethernet);
-два разъема COM;
-один разъем LPT.
Как можно заметить, производитель задействовал все сетевые контроллеры, распаянные на плате.
Разъемы на передней панели платы
Спереди также выведено несколько разъемов, а также других элементов:
-один USB 1.1;
-аудио выход и аудио вход;
три индикатора, свидетельствующие о выполнении той или иной операции (роутер включен, идет передача данных, идет работа жесткого диска);
-кнопка включения/выключения.
Роутер. Общий вид
Все это упаковано в темно-синий корпус с вентиляционными отверстиями.
Роутер в полной сборке
При желании можно "одеть" роутер в специальные панели.
Комплект поставки
Осталось сказать несколько слов о комплекте поставки рассматриваемого устройства. Помимо его в коробке было обнаружено следующее:
-блок питания FSP;
крепление для ноутбучного жесткого диска к внутренней части крышки корпуса;
-44-жильный шлейф для подключения ноутбучного жесткого диска;
-термоинтерфейс для жесткого диска;
термопаста;
-набор винтов для закрытия корпуса роутера;
-диск с программным обеспечением;
-руководство пользователя.
Корпус роутера спроектирован таким образом, что внутри него поместится только 2.5-дюймовый жесткий диск. Не удивительно, что в комплектации для него присутствует столько компонентов. Если вы захотите подключить что-нибудь "покрупнее", то, вероятно, придется выносить это за пределы корпуса.
Производительность
Наверное, для многих будет интересен вопрос производительности операционной системы Mikrotik на вышеназванной платформе и его реальные требования к конфигурации компьютера.
Стоит отметить, что заявленные минимальные требования полностью соответствуют реальным. На 32 мегабайтах оперативной памяти и процессоре Pentium 133 система обслуживала одновременно около 20 подключенных по протоколу PPTP клиентов, динамически ограничивая скорость и фильтруя нежелательный трафик. Общая скорость канала составляла примерно 512/512 Кбит/с. При всём этом загрузка процессора редко когда доходила до 40% и в среднем равнялась 15-25%. В условиях, когда скорости измеряются мегабитами, системные требования заметно возрастают.
Хотелось бы обратить ваше внимание на то, что популярный нынче протокол VPN (PPTP) достаточно ресурсоёмок и во всех возможных случаях вместо него рекомендуется использовать альтернативный и лёгкий PPPOE, клиентская поддержка которого реализована уже в Windows XP. Для более ранних операционных систем его придется устновить отдельно. Так же в целях повышения производительности Mikrotik стоит очень аккуратно отнестись к настройке Firewall и шейпера, по возможности отключить встроенную генерацию графиков загрузки канала и ресурсов системы.
Тесты производительности
Наши заявления по поводу производительности подобных платформ были бы голословными без тестов производительности. Для Mikrotik существует специальная утилита, позволяющая примерно оценить максимальную пропускную способность системы. Из интересующих нас параметров в ней присутствует возможность задлания размера передаваемых пакетов в байтах, скорость входящего/исходящего потоков, направление пакетов. Полученные при тестировании результаты мы оформили в таблицу:
Ниже вы можете увидеть как проходило тестирование на примере нескольких скриншотов.
Тест 1
Тест 2
Тест 3
Тест 4
Тест 5
Тест 6
Перекачка больших файлов с FTP сервера
Закачка файлов на сервер
Нельзя учитывать эту информацию как абсолютно точную, так как проводилось синтетическое тестирование и оно кое-где привело к противоречивости информации. На последних двух графиках была показана загрузка системы при перекачке через маршрутизатор больших файлов на файл-сервер, подключенный по PPPOE к этому же серверу доступа. Как видим, загрузка процессора при этом составила около 90%, а реальная пропускная способность сетевых интерфейсов 65-79 Мбит/с, что, согласитесь, не мало. В расчете мощности оборудования, взяв за основу наше тестирование, необходимо учесть, что мы проводили тесты на одном физическом PPTP/PPPOE подключении. В реальных "боевых" условиях при 80-90 виртуальных подключениях значительно больше ресурсов процессора уйдёт на обсчёт служебной информации и пропускная способность окажется меньше указанной.
Рваные кривые на графиках обусловлены высокой загрузкой процессора клиентской программой. На практике такой маршрутизатор способен обслужить около ста одновременных пользователей, разделяя между ними полосу в 5-10 Мбит/с. Для большей устойчивости системы, мы порекомендовали бы использовать два сервера доступа и один резервный для горячей замены в случае проблем.
Займёмся NAS-ами
Предположим, что у нас уже есть 1-2 платформы или обычных компьютера с установленной RouterOS Mikrotik версии после 2.9.14. Такое условие обусловлено наличием ошибок в реализации протокола Radius в ранних версиях этой операционной системы. В идеальном случае, конечно, лучше всего использовать последнюю доступную лицензионную версию Mikrotik, однако если жажда приключений вас не покидает, постарайтесь всё-таки использовать любую условно-бесплатную стабильную версию.
Настройка серверов доступа будет заключаться в выполнении трёх действий: настройке его авторизации на биллинге, настройке экспорта информации о сетевой статистике посредством NetFlow и настройке доступа модуля биллинга для управления Firewall на Mikrotik. Если первые два шага вполне понятны, то третий нужно объяснить.
Биллинг UTM не предусматривает каких-либо встроенных средств для работы с удалённым Firewall серверов доступа, отличных от Cisco. Вместо этого в нём реализован механизм, позволяющий нам самим управлять поведением системы в зависимости от поступления определённых команд или наступления определённых условий. К примеру, при создании нового аккаунта клиента Firewall системы создаст на сервере доступа правило, разрешающее этому клиенту выход в Интернет. При необходимости блокировки доступа наш скрипт пошлёт нужные команды на Mikrotik, запрещающие клиенту работать.
Сначала настроим взаимодействие Mikrotik с Radius-сервером.
/radius add address=10.20.3.250 secret=radsecret
И отключим возможность управлять состоянием Radius-сервера, так как все манипуляции по отключению пользователей мы будем производить средствами Firewall.
/radius incoming set accept=no
Настройка RADIUS на Mikrotik
Теперь перейдём к настройке протокола NetFlow, который в Mikrotik назван TrafficFlow.
/ip traffic-flow target add address=10.20.3.250 version=5/ip traffic-flow set enabled=yes cache-entries=4k active-flow-timeout=00:01:00 inactive-flow-timeout=00:00:05 interfaces=all
Настройка NetFlow на Mikrotik
В первом правиле мы указали на какой адрес нужно отсылать всю статистику и в каком формате. Во втором правиле разрешили собирать статистику на всех интерфейсах с группировкой экспортируемых данных по 4 Кбайта. Сбор статистики по NetFlow работает следующим образом. Перед отправкой данных ядру биллинга система пытается сгруппировать статистику и делает это по следующему алгоритму: когда пользовать устанавливает постоянное подключение к удаленному серверу и начинает перекачивать данные, то наш сервер по прошествии active-flow-timeout циклически сбрасывает накопленную статистику на биллинг, и в случае, если через открытое активное подключение в течение времени inactive-flow-timeout не поступает новых данных, информация о нём посылается биллингу.
Сейчас приступим к настройке взаимодействия биллинга и Firewall нашего Mikrotik. Схема его работы достаточно проста - управление разрешением пользователей будет производиться с помощью редактирования src-list адресов клиентов в Firewall. Доступ к нашему NAS для этих операций будет осуществляться средствами ssh. Для простоты взаимодействия мы добавим пользователя без пароля, которому разрешен вход только с одного определенного IP-адреса.
/user group add name=ssh policy ssh,write
/user add name=USERNAME group=ssh address=UTM_IP_ADDRESS /p>
Вместо USERNAME необходимо вписать любое имя пользователя, а вместо UTM_IP_ADDRESS IP адрес нашего сервера с UTM.
И разрешим forward только списку разрешенных адресов. Когда вы увидите, как это всё вместе работает, возможно, у вас возникнут другие предложения по реализации отключением пользователей и вы их сможете достаточно легко реализовать.
/ip firewall filter add chain=forward action=accept dst-address-list=allow_ip/ip firewall filter add chain=forward action=accept src-address-list=allow_ip
/ip firewall filter add chain=forward action=drop
С настройкой сервера доступа на этом покончено. При использовании графической утилиты Winbox у вас уйдёт на это буквально несколько минут.
Установка UTM5
К сожалению, разработчики UTM по какой-то причине не работают с распространёнными дистрибутивами, отличными от RedHat/SuSe, поэтому для установки пакета rpm в системе debian нам потребуется установить утилиту alien или рассовать файлы по системе вручную, чего мы делать не будем.
utm:/etc/init.d# apt-get install alien
Еще нам нужен сервер баз данных и инструменты для работы самобо биллинга
apt-get install ssh mysql-server-5.0 proftpd mc apache2 libssl0.9.7 libstdc++5
Сейчас скопируем пакет utm на машину с debian. Для этого воспользуемся любым FTP-клиентом. Не забудьте скопировать файл с регистрационной информацией, если он у вас есть.
Воспользуемся утилитой alien, чтобы установить utm-5.2.1-001.i386.rpm
utm:/etc/init.d# alien utm-5.2.1-001.i386.rpm
В результате чего мы получим пакет utm-5.2.1-001.i386.deb, установить который можно одной командой
utm:/etc/init.d# dpkg -i utm-5.2.1-001.i386.deb
Сейчас создадим базу данных.
utm:/etc/init.d# mysqladmin create UTM5;
И создадим в нём нужные таблицы
utm:/etc/init.d# mysql -u root UTM5</netup/utm5/UTM5_MYSQL.sql
Если вы планируете использовать базу данных PostgreSQL, то вам потребуется файл UTM5_PG.sql, который можно найти в директории с программой. Также нужно изменить путь к сокету mysql в файле /netup/utm/utm5.cfg:
database_sock_path=/var/run/mysqld/mysqld.sock
При желании вы можете изменить и другие параметры: имя пользователя для доступа к базе данных, тип используемой базы данных и некоторые другие, отвечающие за поведение биллинга.
Немного отредактируем стартовые скрипты utm5_core, utm5_radius и utm5_rfw., но сначала скопируем из каталога /etc/rc.d/init.d/ файлы utm5_core, utm5_radius и utm5_rfw в каталог /etc/init.d/. Меняем содержимое строки в файле utm5_core c
utm_exec=safe_utm5_core
на
utm_exec=utm5_core
в utm5_radius c
utm_exec=safe_utm5_radius
на
utm_exec=utm5_radius
и в utm5_rfw c
utm_exec=safe_utm5_rfw
на
utm_exec=utm5_rfw
Сейчас настроим автозапуск скриптов при старте системы
utm:/etc/init.d# update-rc.d utm5_core defaultsutm:/etc/init.d# update-rc.d utm5_radius defaults
utm:/etc/init.d# update-rc.d utm5_rfw defaults
При запуске каждой из команд вы увидите нечто вроде этого
Adding system startup for /etc/init.d/utm5_core .../etc/rc0.d/K20utm5_core -> ../init.d/utm5_core
/etc/rc1.d/K20utm5_core -> ../init.d/utm5_core
/etc/rc6.d/K20utm5_core -> ../init.d/utm5_core
/etc/rc2.d/S20utm5_core -> ../init.d/utm5_core
/etc/rc3.d/S20utm5_core -> ../init.d/utm5_core
/etc/rc4.d/S20utm5_core -> ../init.d/utm5_core
/etc/rc5.d/S20utm5_core -> ../init.d/utm5_core
Нужно не забыть создать несколько файлов и папок, так как при конвертации пакета .rpm в .deb все установочные скрипты потерялись и нам придётся возложить на себя их работу
utm:/etc/init.d# mkdir /netup/utm5/log/
utm:/etc/init.d# touch /netup/utm5/log/utm5_radius.log
utm:/etc/init.d# mkdir /netup/utm5/db/
Всё остальное система создаст сама. Нам осталось только зарегистрировать UTM5, а делается это следующим образом: разработчики не стали себя утруждать какими-либо удобными механизмами и вместе с самим биллингом поставляют файл с SQL-запросом, который нужно импортировать в нашу базу данных.
utm:/etc/init.d# mysql -u root UTM5</home/utm5/utm_reg.sql
Если всё прошло без заминки, то можно запускать биллинг и приступать к его настройке.
utm:/etc/init.d#/etc/init.d/utm5_coreutm:/etc/init.d#/etc/init.d/utm5_radius
utm:/etc/init.d#/etc/init.d/utm5_rfw
utm:/etc/init.d# ps aux | grep utm5
root 4613 0.2 4.8 85368 9268 pts/2 Sl 14:49 0:00 /netup/utm5/bin/utm5_core start
root 4629 0.5 1.0 32340 2100 pts/2 Sl 14:52 0:00 /netup/utm5/bin/utm5_radius start
root 4638 0.5 1.0 12392 2016 pts/2 Sl 14:52 0:00 /netup/utm5/bin/utm5_rfw start
Не забудьте взглянуть в файлы, размещенные в /netup/utm5/log/ на предмет ошибок.
Запуск консоли управления и настройка на работу с NAS
UTM5 конфигурируется с помощью специальной утилиты utm_admin, написанной на Java, поэтому перед её запуском вам потребуется установить виртуальную машину. После запуска (javaw UTM_admin.jar) утилита выглядит следующим образом
Утилита UtmAdmin
Имя и пароль вы можете подсмотреть в файле UTM5_MYSQL.sql. В нашем случае это init/init.
Главное окно UtmAdmin
Первое, что сейчас нужно сделать, - это настроить UTM на работу с нашим NAS, то есть добавить его в список разрешенных. Это делается следующим образом: Настройки-> Список NAS ->Добавить. В поле NAS ID пишем IP-адрес нашего NAS. В поле Auth Secret то, что мы указали в настройке Radius на Mikrotik. У нас это radsecret. Теперь настроим UTM, чтобы он мог управлять Firewall на сервере доступа.
Внесем изменения в файл /netup/utm5/rfw.cfg
firewall_type=localfirewall_path=/usr/local/bin/mikrotik_rfw.sh
rfw_name=127.0.0.1
core_host=127.0.0.1
core_port=11758
rfw_login=init
rfw_password=init
log_level=3
log_file_main=/netup/utm5/log/rfw_main.log
log_file_debug=/netup/utm5/log/rfw_debug.log
log_file_critical=/netup/utm5/log/rfw_critical.log
Сейчас создадим файл /usr/local/bin/mikrotik_rfw.sh и внесем в него следующее содержимое:
utm:/etc/init.d#mcedit /usr/local/bin/mikrotik_rfw.sh:#!/bin/sh
ssh USERNAME @ UTM_IP_ADDRESS "$*"
Где USERNAME и UTM_IP_ADDRESS - параметры, указанные в шаге конфигурирования сервера доступа. Сделаем этот файл исполняемым:
utm:/etc/init.d#chmod +x /usr/local/bin/mikrotik_rfw.sh
И обязательно запустим его в первый раз сами, для того, чтобы сохранился сертификат:
utm:/etc/init.d#sh /usr/local/bin/mikrotik_rfw.sh
У вас должно спросить разрешение на подключение, на что ответьте утвердительно. Вернёмся в utm_admin и внесем ещё несколько изменений в конфигурацию. Зайдите в Настройки -> Список брандмауэров, удалите оттуда все записи. нажмите на кнопку Добавить.
Тип - LocalИмя - 127.0.0.1
IP-адрес - 127.0.0.1
Логин - LOGIN_UTM
Пароль - PASSWORD_UTM
Комментарии - NAS Mikrotik
Где LOGIN_UTM и PASSWORD_UTM соответственно имя и пароль для доступа на сервер UTM. В нашем случае это init/init, однако их настоятельно рекомендуется сменить после того, как всё заработает и вы разберетесь как это правильно сделать.Запомните ID, который система присвоила записи и переедите в Настройки->Правила Firewall. Опять же удалите все предустановленные записи и нажмите на кнопку Добавить.
Сейчас укажем какие команды должны поступать на Mikrotik в случае, если клиенту нужно разрешить доступ в Интернет и когда нужно запретить.
Все пользователи - +ID пользователя - 0
ID группы - 0
ID тарифа - 0
Включение - /ip firewall address-list add address=UIP list=allow_ip comment=UID
Выключение - /ip firewall address-list remove UID
ID брандмауэра - ID записи из предыдущего шага
На этом настройку связки можно считать законченной. Mikrotik будет полностью "повиноваться" биллингу и остаётся дело только за настройкой временных интервалов, классов трафика и тарифных планов.
Классы трафика
В биллинговой системе UTM присутствует такое понятие как класс трафика. На практике это означает группировку трафика по направлениям, адресам получателя или отправителя или некоторым другим характеристикам, к примеру, TOS, адресу маршрутизатора и интерфейса. Каждому классу присваивается свой идентификатор. При анализе идентификаторы просматриваются от большего к меньшему и если какой-либо пакет совпадает по условию с первым попавшимся правилом, ему присваивается указанный в правиле идентификатор. таким образом один пакет не может попасть сразу в два или более разных типов трафика. При этом правила "Входящий трафик", "Исходящий трафик" и "Локальный трафик" должны иметь наименьший приоритет и охватывать абсолютно все возможное адресное пространство и при этом не пересекаться в зонах действия.
К примеру, если у нас все клиенты при подключении по VPN будут получать адреса из сети 10.10.0.0/16 и нам нужно классифицировать только входящий и исходящий трафик без деления, то классы трафика будут выглядеть следующим образом:
10 Входящий: из 0.0.0.0 с маской 0.0.0.0 на сеть 10.10.0.0 с маской 255.255.0.0 направление На получателя
20 Исходящий: из 10.10.0.0 с маской 255.255.0.0 на 0.0.0.0 с маской 0.0.0.0 направление На получателя
30 Локальный: из 10.10.0.0 с маской 255.255.0.0 на 10.10.0.0 с маской 255.255.0.0 направление На получателя
Класс "Локальный трафик" здесь присутствует для того, чтобы можно было межклиентскому трафику указать нулевую цену.
Настройка классов трафика
Услуги
Для создания первого тарифного плана нам нужно определиться с услугами, которые мы будем в него включать. В системе UTM существует такое понятие, как фиктивная услуга. Впоследствии все типы услуг, которые не являются действием прямого вмешательства специалистов (к примеру, выезд и настройка вашего ADSL-модема или протяжка кабеля), будут называться фиктивными (установка подключения, передача трафика).
Для тарифного плана "Передача платного трафика" создадим фиктивную услугу "Передача трафика"
Добавление фиктивной услуги
Добавление услуги "Передача IP-трафикка"
Установка лимитов трафика
Добавление услуги "Передача IP-трафика" с установленными значениями
Здесь мы указываем цену классов трафика.
В результате у вас должно получиться вот так.
Создаём тариф
После добавления новой фиктивной услуги создадим основанный на ней тарифный план Тарификация->Тарифные планы->Добавить.Вводим имя тарифного плана, срок до которого он действует и нажимаем OK. После этого выбираем его в списке и нажимаем на кнопку Редактировать.
Создание тарифного плана
В открывшемся окне нажимаем Добавить и выбираем созданную в предыдущем шаге услугу. Если есть какая-то необходимость, то её можно сразу же и отредактировать. Не забудьте в этом окне отметить флажок Подключать услугу по умолчанию. Это избавит вас от лишних действий при создании клиентов.
Добавим клиентов
В данный момент система настроена на подсчёт трафика и списание денежных средств с лицевых счетов пользователей согласно нашему тарифному плану. Нам осталось только создать пользователя и проверить правильность поведения системы. Переходим на вкладку Пользователи и группы->Пользователи и нажимаем Добавить.
Указываем логин и пароль для авторизации на UTM. Не путайте их с логином и паролем для подключения к Интернет. Нажимаем на кнопку "Применить" и в появившемся внизу блоке вкладок переходим на Тарифные планы.
Создание нового аккаунта
Создание пользователя для подключения по VPN
Выбираем наш тарифный план в обоих списках, расчётный период и нажимаем Применить, после чего добавляем IP-группу, где указываем:-IP-адрес, который нужно выдать клиенту при подключении;
-ID брандмауэра - сервер, к которому будет подключаться пользователь;
-логин и пароль - соответственно его имя и пароль;
-на VPN - снимите галочку.
Задание параметров пользователя
Для надёжности перезагрузите сервер с UTM и попробуйте подключиться. Если что-то не так - смотрите в лог.
Заключение
В заключении хотелось бы отметить, что в некоторых сборках UTM мы столкнулись с явными проблемами и ошибками, которые не поддавались никакой логике К примеру, во время тестирования у двух из шести клиентов почему-то не считался трафик, хотя настройки у всех были абсолютно идентичны. Возможно, это связано с тем, что нам в руки попадались проблемные версии, однако впечатление о продукте было несколько испорчено. Не смотря на этот факт стоит заметить, что функционал системы на высоте. Многие вещи сделаны удобно и весьма продуманно, что избавит вас от возможной головной боли. Если вы захотите построить хорошую, функциональную и вместе с тем бюджетную систему учёта трафика, обратите внимание на уже зарекомендовавшую себя связку UTM и Mikrotik.
20 апреля 2007 Автор: Александр Кузьмицкий