{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Skurudo Blog(post): заметки с тегом RouterOS",
    "_rss_description": "Одним из продуктов MikroTik является RouterOS — сетевая операционная система на базе Linux. RouterOS предназначена для установки на маршрутизаторы MikroTik RouterBoard",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/skurudo.ru\/tags\/routeros\/",
    "feed_url": "https:\/\/skurudo.ru\/tags\/routeros\/json\/",
    "icon": "https:\/\/skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083",
    "authors": [
        {
            "name": "Pavel Galkin",
            "url": "https:\/\/skurudo.ru\/",
            "avatar": "https:\/\/skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083"
        }
    ],
    "items": [
        {
            "id": "265",
            "url": "https:\/\/skurudo.ru\/all\/open-gateways\/",
            "title": "Открыть шлюзы",
            "content_html": "<p>Сколько занятных вещей узнаешь с микротиками, не описать.. Одна из них — добавление шлюза или gateway. Обычно у нас шлюз в одной подсети и его добавление не вызывает никаких проблем, например:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">\/ip route add dst-address=0.0.0.0\/0 gateway=${GATEWAY}<\/code><\/pre><p>Но так вполне себе может не работать, если шлюз у вас из другой подсети или вообще условный 10.0.0.1. Конструкция наподобие того, что в линуксах в таких случаях будет не сработает, RouterOS так не умеет onlink.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">\/ip route add dst-address=0.0.0.0\/0 gateway=10.0.0.1%ether1<\/code><\/pre><p>Выход есть — использовать вариант со scope<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">\/ip route add dst-address=10.0.0.1\/32 gateway=ether1 scope=10\r\n\/ip route add dst-address=0.0.0.0\/0 gateway=10.0.0.1 target-scope=11<\/code><\/pre><p>RouterOS находит маршрут до 10.0.0.1 (scope=10, что ≤ 11), видит что он через ether1, и рекурсивно резолвит — весь трафик 0.0.0.0\/0 уходит через ether1 на адрес 10.0.0.1. Мы явно сказали системе, что шлюз 10.0.0.1 живёт на ether1, не требуя чтобы он был в одной IP-подсети.<\/p>\n",
            "date_published": "2026-02-03T07:51:39+03:00",
            "date_modified": "2026-02-03T12:28:45+03:00",
            "tags": [
                "Mikrotik",
                "RouterOS"
            ],
            "_date_published_rfc2822": "Tue, 03 Feb 2026 07:51:39 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "265",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "212",
            "url": "https:\/\/skurudo.ru\/all\/skript-dlya-obnovleniya-addresslist\/",
            "title": "Скрипт для обновления AddressList",
            "content_html": "<p>Соорудил скрипт для обновления адрес листа или листов более или менее автоматически. Давно хотел завести что-то подобное для автоматизации.<\/p>\n<p>Первоначальная задумка:<\/p>\n<ul>\n<li>* у нас удаленно лежит адрес лист (<i>где-то на веб сервере<\/i>);<\/li>\n<li>* мы по расписанию (<i>это шедулер<\/i>) забираем его к себе (<i>это фетч<\/i>);<\/li>\n<li>* далее смотрим не нулевой ли размер, если нулевой — то выходим (<i>пока не сделано, проверка идет по наличию файла<\/i>);<\/li>\n<li>* если все в порядке, то очищаем существующий адрес лист, импортируем новый и удаляем файл;<\/li>\n<\/ul>\n<p>Из ограничений:<\/p>\n<ul>\n<li>* пока не умеем работать с динамическими записями и очищать их;<\/li>\n<li>* список адресов — это по сути rsc;<\/li>\n<li>* список адресов там пока жестко задан адрес лист (непонятно получится ли это обратить в динамичный выбор);<\/li>\n<\/ul>\n<p>Ссылка на сам скрипт:<br \/>\n<a href=\"https:\/\/github.com\/skurudo\/mikrotik-alau\">https:\/\/github.com\/skurudo\/mikrotik-alau<\/a><\/p>\n",
            "date_published": "2019-12-04T14:52:41+03:00",
            "date_modified": "2020-02-03T18:10:45+03:00",
            "tags": [
                "Mikrotik",
                "RouterOS",
                "скрипт"
            ],
            "_date_published_rfc2822": "Wed, 04 Dec 2019 14:52:41 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "212",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "201",
            "url": "https:\/\/skurudo.ru\/all\/mikrotik-beginning\/",
            "title": "Mikrotik: Начало",
            "content_html": "<p>С оборудованием Mikrotik меня познакомил где-то полтора года назад один хороший камрад. Мол, отличная штука, говорит — полезно в хозяйстве очень хорошо идёт. Сперва открещивался, пока не очень была понятна логика и идеология работы с устройствами. Потому как логика весьма инженерная, после домашних или начальных офисных маршрутизаторов сразу во всем разобраться было не так просто. Но после посещения МУМ, послушав доклады, пообщавшись с адептами, почитав интернет стало весьма интригующе.<\/p>\n<p>Возможности устройства оказались весьма обширными,  как и возможности кастомизации теми же скриптами. Среда использования тоже была довольно широкой — идеально для небольших организаций и средних предприятий. Возможно и можно использовать в более крупных инсталляциях — слышал и используют провайдеры, но за это сказать не могу.<\/p>\n<p>Устройства исключительно радуют стабильностью работы. Из серии — настроил,  поставил, забыл. А поскольку они работают на единой операционной системе RouterOS на всех устройствах мы видим единообразие в настройках и меню. Грубо говоря, мы можем делать что-то или проводить эксперименты на самом дешёвом железе за 15 баксов и потом сразу пересесть на нечто на два порядка дороже — элементы управления и логика работы никак не поменяется.<\/p>\n<p>За прошедший год удалось внедрить Mikrotik на нескольких объектах,  что дало увеличение стабильности работы в первую очередь. А также смогло дать возможность оперативной диагностики доступности устройств и сети в целом.<\/p>\n<p>PS: Тогда же, чуть больше года назад я получил свой первый официальный сертификат :-)<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/skurudo.ru\/pictures\/mtcna-1811NA4177.jpg\" width=\"2054\" height=\"1425\" alt=\"\" \/>\n<\/div>\n",
            "date_published": "2019-11-30T12:17:47+03:00",
            "date_modified": "2021-04-07T10:22:28+03:00",
            "tags": [
                "Mikrotik",
                "MTCNA",
                "RouterOS"
            ],
            "image": "https:\/\/skurudo.ru\/pictures\/mtcna-1811NA4177.jpg",
            "_date_published_rfc2822": "Sat, 30 Nov 2019 12:17:47 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "201",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/skurudo.ru\/pictures\/mtcna-1811NA4177.jpg"
                ]
            }
        },
        {
            "id": "204",
            "url": "https:\/\/skurudo.ru\/all\/groups-in-mikrotik\/",
            "title": "Группы пользователей в Mikrotik",
            "content_html": "<p>С связи с расширением сети на даче появилась задача как-то группировать абонентов и что-то такое с ними вытворять — вводить ограничения и проводить мониторинг. Скорость и стабильность работы в связи со сменой оборудования и мобильного оператора возросла, но для спокойной жизни этого недостаточно. В задаче исходим из того, что у нас есть центральный маршрутизатор, в который сходятся несколько точек доступа. Сами точки доступа только передают подключение сразу в маршрутизатор без каких-либо затей. Если на Zyxel Keenetic функционал с двумя группами был из коробки в каком-то виде, то на Mikrotik нужно придумать что-то свое. Основная идея в том, что мы идентифицируем подключившегося по MAC-адресу и далее сопоставляем его с группой.<\/p>\n<p>Сначала виделось два пути — делать дополнительные бриджи и раскидывать клиентов или делать vlan’ы. Делать бриджи только казалось хорошей идеей, на деле в них не было интерфейсов. Было создано несколько бриджей, с отдельными DHCP-серверами и в зависимости от MAC-адреса пользователю выдавался адрес из пула того или иного сервера. Пользователей так поделить удалось, но локальная и внешняя сеть в таком варианте не работает. Далее была идея использовать mac-based vlan. Но здесь мы сталкиваемся с тем, что не слишком удобно привязывать MAC-адрес и все равно нужно цепляться к интерфейсам. Других идей не было.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/skurudo.ru\/pictures\/bridge_2019-06-17_13-38-59.jpg\" width=\"1280\" height=\"664\" alt=\"\" \/>\n<\/div>\n<p>Находясь в сомнениях, я поделился своими мыслями с одним грамотным товарищем, и он натолкнул меня на другую идею, сказав — «зачем ты все пытаешься решить на L2, почему не хочешь делать управление разными сетями сразу?» Дальше товарищ отвлекся, а на меня в свою очередь снизошло озарение. Нет нужды городить огороды и развивать лопатостроение. Мух от котлет, то есть подключившихся пользователей, разделит как и в варианте с бриджами DHCP-сервер. Нам нужно задать несколько разных подсетей для разных групп пользователей. Пользователей поделит по MAC-адресу наш DHCP-сервер, добавляя в нужную группу — читай нужную подсеть. А дальнейшие манипуляции уже делать в Firewall \/ Queues. Осталось только реализовать схему и разбавить немного ручным трудом в виде работы с Leases.<\/p>\n<p>Подготовка к внедрению, получаем аналоги групп:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/skurudo.ru\/pictures\/groups_2019-07-23-001.jpg\" width=\"1199\" height=\"689\" alt=\"\" \/>\n<\/div>\n<p>Делаем немного QoS на Simple Queues:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/skurudo.ru\/pictures\/groups_qos_2019-07-23-001.jpg\" width=\"609\" height=\"343\" alt=\"\" \/>\n<\/div>\n<p>И теперь в самое основное в Leases:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/skurudo.ru\/pictures\/groups_leases_2019-07-23-001.jpg\" width=\"1053\" height=\"774\" alt=\"\" \/>\n<\/div>\n<p>По результатам у нас пользователь попадает по умолчанию в Public сеть 192.168.1.0\/24 с определенными условиями и ограничениями, оттуда вручную мы его можем перенести в другую «группу» или сеть с другими условиями, с более мягкими или жесткими ограничениями. Достаточно удобно, если не считать ручную работу.<\/p>\n",
            "date_published": "2019-07-24T12:35:59+03:00",
            "date_modified": "2019-07-24T13:13:41+03:00",
            "tags": [
                "DHCP",
                "Keenetic",
                "L2",
                "L3",
                "MAC",
                "Mikrotik",
                "OSI",
                "RouterOS",
                "Zyxel"
            ],
            "image": "https:\/\/skurudo.ru\/pictures\/bridge_2019-06-17_13-38-59.jpg",
            "_date_published_rfc2822": "Wed, 24 Jul 2019 12:35:59 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "204",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/skurudo.ru\/pictures\/bridge_2019-06-17_13-38-59.jpg",
                    "https:\/\/skurudo.ru\/pictures\/groups_2019-07-23-001.jpg",
                    "https:\/\/skurudo.ru\/pictures\/groups_qos_2019-07-23-001.jpg",
                    "https:\/\/skurudo.ru\/pictures\/groups_leases_2019-07-23-001.jpg"
                ]
            }
        }
    ],
    "_e2_version": 4116,
    "_e2_ua_string": "Aegea 11.2 (v4116)"
}