Мой нереализованный проект. Сеть из 200 маршрутизаторов MikroTik

Всем привет. Данная статья рассчитана на тех, у кого в парке находится много устройств микротик, и кому хочется сделать максимальную унификацию, чтобы не подключаться на каждое устройство в отдельности. В этой статье я опишу проект, который, к сожалению, не дошел до боевых условий из-за человеческих факторов. Вкратце: более 200 маршрутизаторов, быстрая настройка и обучение персонала, унификация по регионам, фильтрация сетей и определенных хостов, возможность легкого добавления правил на все устройства, логирование и контроль доступа.


То, что описано ниже не претендует на готовый кейс, но надеюсь пригодится вам при планировании своих сетей и минимизации ошибок. Возможно, некоторые пункты и решения вам покажутся не совсем правильными – если так, пишите в комментарии. Критика в данном случае будет опытом в общую копилку. Поэтому, читатель, загляни в комментарии, возможно, автор допустил грубую ошибку – сообщество поможет.
Количество маршрутизаторов 200-300, разбросаны по разным городам с разным качеством интернет соединения. Необходимо сделать все красиво и доступно разъяснить локальным админам, как будет все работать.

Итак, с чего же начинается любой проект. Конечно же, с ТЗ.
1. Организация плана сетей по всем филиалам согласно требованиям заказчика, сегментация сетей (от 3 до 20 сетей в филиалах в зависимости от численности устройств).
2. Настройка устройств в каждом филиале. Проверка реальной пропускной скорости провайдера в разных условиях работы.
3. Организация защиты устройств, управление по белому списку, автодектирование атак с автозанесением в черный список на определенный промежуток времени, минимализация использования различных технических средств, используемых для перехвата доступа управления и отказа от обслуживания.
4. Организация защищенных vpn соединений с фильтрацией по сетям согласно требованиям заказчика. Минимум 3 vpn соединения с каждого филиала до центра.
5. На основе пункта 1, 2. Выбрать оптимальные пути построения отказоустойчивых vpn. Технологию динамической маршрутизации при корректном обосновании может выбрать исполнитель.
6. Организация приоритезации трафика по протоколам, портам, хостам и другим специфичным сервисам которые использует заказчик. (VOIP, хосты с важными сервисами)
7. Организация мониторинга и логирования событий маршрутизаторов для реагирования сотрудников технической поддержки.

Как мы понимаем, в ряде случаев ТЗ составляется от требований. Эти требования я сформулировал самостоятельно, выслушав основные проблемы. Допускал возможность, что выполнением этих пунктов, может заняться кто- то другой.
Какие инструменты будут использоваться для выполнения данных требований:
1. Стэк ELK (спустя некоторое время, пришло понимание, что вместо logstash будет использоваться fluentd).
2. Ansible. Для удобства администрирования и разделения доступа будем использовать AWX.
3. GITLAB. Тут пояснять не надо. Куда без контроля версий наших конфигов.
4. PowerShell. Будет простенький скрипт для первоначальной генерации конфига.
5. Доку вики, для написания документации и руководств. В данном случаем, используем habr.com.
6. Мониторинг будет осуществляться через zabbix. Там же будет нарисована схема подключений для общего понимания.

Моменты настройки EFK.
По первому пункту опишу только идеологию, по которой будут строиться индексы. Есть много
прекрасных статей по настройке и приему логов с устройств под управлением mikrotik.
Остановлюсь на некоторых моментах:
1. Согласно схеме, стоит продумать прием логов с разных мест и по разным портам. Для этого мы будем использовать агрегатор логов. А также нам хочется сделать универсальные графики для всех маршрутизаторов с возможностью разделения доступа. Тогда индексы строим следующим образом:


Таким образом мы можем объединить роутеры и сегментировать согласно плана- mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Зачем так усложнять? Мы понимаем, что у нас будет 200 и более устройств. За всем не уследить. С 6.8 версии elasticsearch нам доступны настройки безопасности (без покупки лицензии), тем самым, мы можем распределить права на просмотр между сотрудниками тех.поддержки или локальными системными администраторами.
Таблицы, графики – тут уже надо просто договорится — либо использовать однообразные, либо каждый делает так, как будет удобно ему.

2. По логированию. Если в правилах firewall включаем log, то имена делаем без пробелов. Видно, что, использовав простой конфиг в fluentd, мы можем фильтровать данные и делать удобные панели. На картинке ниже- мой домашний роутер.

3. По занимаемому месту и логам. В среднем, при 1000 сообщений в час, логи занимают по 2-3 мб в сутки, что, согласитесь, не так много. Версия elasticsearch 7.5.

ANSIBLE.AWX
К нашему счастью у нас есть, готовый модуль для routeros
Я указал про AWX, но команды ниже только про ansible в чистом виде – думаю, для тех, кто работал с ansible, не возникнет проблем с использованием через gui awx.
Признаюсь честно, до этого смотрел другие гайды, где использовали ssh, и у всех были разные проблемы с временем ответа и еще куча других проблем. Повторюсь, до боя не дошло , воспринимайте данную информацию как эксперимент, не дошедший дальше стенда из 20 роутеров.
Нам необходимо использовать сертификат или учетку. Тут решать вам, я за сертификаты. Некоторый тонкий момент по правам. Даю права на write – хотя бы “reset config” сделать не получится.
По генерации, копированию сертификата и импорту не должно возникнуть проблем:




Как видно из приведенной выше конфигурации, составление своих playbook несложное дело. Достаточно хорошо освоить cli mikrotik. Представим ситуацию, когда на всех роутерах надо убрать address list с определенными данными, тогда:


Я намерено не вставил сюда весь листинг файрвола т.к. он будет индивидуален для каждого проекта. Но одно могу сказать точно, используйте только address list.

По GITLAB все ясно. Не буду останавливаться на этом моменте. Все красиво по отдельным tasks, templates, handlers.
Powershell.
Тут будут 3 файлика. Почему powershell? Инструмент для генерации конфигов можно выбирать любой, кому что удобнее. В данном случае у всех на пк стоит windows, поэтому зачем делать на bash, когда удобнее powershell. Кому что удобнее.



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




Я намеренно изменил адреса в примерах по понятным причинам.

Пропустил пункт по детектированию атак и аномальному поведению – это заслуживает отдельной статьи. Но стоит указать, что в данной категории можно использовать значения данных мониторинга с Zabbix + отработанные данные curl с elasticsearch.

На каких моментах необходимо заострить внимание:
1. План сетей. Лучше составить сразу в читаемом виде. Вполне хватит excel. К сожалению, очень часто вижу, что сети составляются по принципу «Появился новый филиал, вот вам /24». Никто не выясняет, сколько предполагается устройств в данном месте и будет ли дальнейший рост. Например, открылся небольшой магазин, в котором изначально понятно, что устройство будет не более 10, зачем выделять /24? По большим филиалам – наоборот, выделяют /24, а устройств становится 500 — просто добавить сеть можно, но хочется все продумать сразу.
2. Правила фильтрации. Если по проекту предполагается, что будет разделение сетей и максимальная сегментация. Best Practice со временем меняются. Ранее делили сеть ПК и сеть принтеров, сейчас вполне нормально не делить эти сети. Стоит использовать здравый смысл и не плодить множество подсетей там, где они не нужны и не объединять в одну сеть все устройства.
3. «Золотые» настройки на всех роутерах. Т.е. если вы определились с планом. Стоит сразу все предусмотреть и постараться сделать так, чтобы все настройки были идентичны- были только разные address list и ip адреса. В случае возникающих проблем, время на отладку будет меньше.
4. Организационные моменты не менее важны, чем технические. Часто ленивые сотрудники выполняют указанные рекомендации «вручную», не используя готовые конфигурации и скрипты, что по итогу приводит к проблемам на пустом месте.

По динамической маршрутизации. Использовался OSPF с зональным делением. Но ведь это тестовый стенд, в боевых условиях такие вещи настраивать интереснее.

Надеюсь никто не расстроился, что я не выложил конфигурации маршрутизаторов. Думаю, что вполне хватит ссылок, а далее все зависит от требований. И конечно тесты, необходимо больше тестов.
Желаю всем в новом году реализовать свои проекты. Да прибудет с вами access granted!!!