Базовая конфигурация MikroTik (CLI) ( Создание простейшей конфигурации для обеспечения работы небольшого офиса с парой десятков пользователей. )

Hard: "MikroTik RB/CCR".
OS: "RouterOS v6".

Задача: создать простейшую конфигурацию маршрутизатора "MikroTik" для обеспечения работы типового небольшого офиса с парой десятков пользователей и двумя-тремя серверами.

Сразу после запуска ненастроенного (или сброшенного до заводского состояния) устройства для доступа к его конфигурации есть два пути: включиться в один из портов (обычно второй и следующие, в зависимости от модели) ethernet-порт (как правило по умолчанию на устройстве запущен DHCP-сервер, выдающий клиентам сетевой адрес) или воспользоваться более простым и надёжным RS-232 (через кабель DB-9). Я предпочитаю последний способ - это не вынуждает меня выключаться из сети, в которой я уже нахожусь:



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


Аналогичного эффекта сброса настроек до заводских можно достигнуть следующей последовательностью действий:


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

Ознакомиться с текущей конфигурацией проще всего посредством команды экспортирования всего набора команд для воссоздания таковой:


Обращаю внимание, что в версии "RouterOS v6.41" аппаратную L2-коммутацию полностью перенесли на bridge-интерфейсы, отменив ранее использовавшиеся switch-группировки (через опции "master port") - новая реализация "прозрачного моста" поддерживает "аппаратную разгрузку (hardware offload)". Настоятельно рекомендую обновиться до версии v6.41 и выше, так описываемая здесь конфигурация основана уже на новом функционале мостового интерфейса.

Первичные настройки доступа.

Устанавливаем пароль для текущего пользователя "admin":


Заводим дополнительного пользователя и выдаём ему полномочия суперпользователя:


Выключаем все сервисы управления устройством, кроме SSH, "winbox" и COM-порта:


Активируем повышенный уровень шифрования сеансов SSH и запрещаем транзитные подключения:


Ради повышения уровня пассивной безопасности разрешаем обращения к "winbox" только из локальной сети - для настройки извне достаточно SSH:


Настраиваем сетевое именование.

Задаём символическое сетевое имя (FQDN) устройству:


Задаём набор NS-серверов, к которым следует отправлять DNS-запросы (в примере Google и Yandex):


Разрешаем обслуживание маршрутизатором рекурсивных DNS-запросов от пользователей:


Устанавливаем точное системное время.

Наверняка изначально может потребоваться явно указать желаемый часовой пояс (пример для Новосибирска):


Задаём внешний источник данных для автоматической синхронизации времени:


Сразу по применению новых параметров даты и времени система попытается синхронизировать его с указанными time-серверами.

Позволяем маршрутизатору делиться сведениями о точном времени, активируя NTP-Server:


Об аппаратных чипах и логике коммутации.

Ранее (до "RouterOS v6.41") на большинстве "Mikrotik" в настройках по умолчанию была предустановлена схема из двух уровней коммутации: группа ethernet-интерфейсов собирается в "switch-group" (трафик которой обслуживается только в рамках подключения к физическому чипу коммутации, коих может быть несколько), а порты "switch-group" через произвольный "master-port" (таковым может быть назначен любой из портов группы) вводятся в мостовой виртуальный интерфейс "bridge", коммутирующий (уже на уровне центрального процессора) пакеты "switch-group", автономных ethernet-интерфейсов и беспроводного интерфейса, предоставляя им единое L2 адресное пространство.

С внедрением "hardware offload" в мостовых интерфейсах прослойка "switch-group" была исключена из схемы, что сильно упростило её с точки зрения первичного конфигурирования - теперь по умолчанию все сетевые интерфейсы (кроме WAN) введены в виртуальный "прозрачный мост".

Такая реализация упрощает запуск устройства в работу, но не обеспечивает хорошей сетевой производительности из-за узкого места - CPU, через который будет пропускаться вся паразитная широковещательная коммутация, которой в реальной сети с количеством узлов за пару десятков не избежать.

Рекомендую сразу разделить по разным группам коммутации проводные и беспроводные интерфейсы (помним, что по умолчанию они сведены в "прозрачный мост") с тем, чтобы иметь возможность подключающихся беспроводных клиентов в любых комбинациях изолировать от работающих в проводной сети пользователей, а порты последней распределить в соответствии с назначением, функционально изолировав их в рамках аппаратных чипов.

Планируем распределение сетевых интерфейсов по задачам.

В дальнейшей настройке будем исходить из потребности в следующих сущностях:


Если устройство начального уровня, то в нём немного физических портов и может статься, что каждый из них будет задействован в своей задаче с индивидуальной сетевой IP-адресацией. Если ethernet-портов больше, чем задач, что часть из них можно свести в группы коммутации, получив в итоге картину вроде нижеследующей:


Конфигурируем локальные сетевые подключения.

Переименовываем сетевые интерфейсы для удобства восприятия их функциональной привязки, в соответствие с вышеприведённой схемой:


Создаём "мостовые интерфейсы", которые будут играть роль виртуальных коммутаторов:


Подключаем к виртуальным "мостовым интерфейсам" соответствующие сетевые физические интерфейсы:


Проверяем, получилось ли задуманное распределение интерфейсов:



В следующем выводе сведений об участниках имеющихся "прозрачных мостов" хорошо видно, для каких интерфейсов (всех в примере) активна "аппаратная разгрузка (hardware offload)" - это значит, что между интерфейсами в рамках обоих групп коммутации пакеты будут передаваться с максимальной скоростью - обрабатываемые на аппаратном уровне, без привлечения медленного центрального CPU:



Назначаем "мостовым интерфейсам" локальных сетей IP-адреса:


Результат наших действий по назначению IP-адресов:



Конфигурируем беспроводное сетевое подключение.

Беспроводной интерфейс по умолчанию переведён под управление модуля CAPsMAN (Controlled Access Point system Manager) - контроллера беспроводных точек, призванного упростить настройку и управление единой Wi-Fi-сетью (аналог UniFi-сети на устройствах "Ubiquiti") с бесшовным роумингом:



Хорошо, но для одиночного устройства не нужно - отключаем привязку беспроводного интерфейса к системе CAP:


Создаём выделенный профиль, описывающий метод аутентификации пользователя в беспроводной сети:


Задаём параметры сети, обслуживаемой беспроводным интерфейсом, заодно привязав к нему заранее подготовленный профиль аутентификации:


Задаём IP-адрес беспроводному интерфейсу и включаем таковой:


Настраиваем автоматическую выдачу IP-адресов.

Запускаем DHCP-сервер для обслуживания клиентов локальной сети:


При необходимости фиксируем IP-адрес компьютера пользователя за его аппаратным MAC-адресом:


Запускаем DHCP-сервер для обслуживания клиентов беспроводной сети:


Удостоверяемся, что наши DHCP-серверы активны в заданной конфигурации:


А вот так можно просмотреть список выданных пользователям сетей IP-адресов:


Конфигурируем внешние сетевые подключения.

Задаём внешнему интерфейсу первого (основного) провайдера IP-адрес:


Объявляем маршрут "по умолчанию", отправляющий весь нераспределённый трафик в сеть первого провайдера "ISP1":


Задаём параметры подключения ко второму, резервному интернет-провайдеру (например через xDSL-модем, выдающего динамические адреса на линии связи). По логике маршрутизации мы не должный принимать от DHCP-сервера провайдера "маршрут по умолчанию", нам достаточно просто получить адресацию, чтобы интерфейс был активен - но в комбинации "DHCP + StaticRoute" Mikrotik не вполне корректно отрабатывает маршруты на стыке сетей - так что сразу заводим второй "маршрут по умолчанию", но делаем его менее приоритетным:


Просматриваем получившуюся таблицу простейшей статической маршрутизации:



Настраиваем трансляцию запросов из локальной сети в интернет.

Так как внутри "MikroTik" живёт "Linux", управление сетевым трафиком и модификация пакетов реализовано через подсистему ядра "netfilter", только вместо обвязки "iptables" здесь оперируют сущностью "firewall".

Для упрощения дальнейшего конфигурирования отношений между подсетями составляем списки таковых:


Задаём правила NAPT/PAT (NAT Overload/Port Address Translation) трансляции локальных сетевых адресов пользователей во внешние, при обращении за сетевые интерфейсы провайдеров:


Проверяем, применились ли правила организации доступа в интернет:



Настраиваем трансляцию запросов из внешней сети к локальным ресурсам.

Наверняка потребуется обеспечить доступность внутреннего сервиса, спрятанного за "MikroTik", извне.

Добавляем правила DNAT (Destination NAT), разрешающие пропуск трафика снаружи к определённым сервисам и портам:


Если нужно обеспечить как пропуск трафика извне, так и вывод такового наружу через определённый внешний IP-адрес, то к правилу DNAT добавим ещё и SNAT (Source NAT) - например, для всего сетевого узла в целом:


Более глубокую настройку защитного экрана, как такового рассмотрим в отдельной заметке.

Выключаем ненужное.

Деактивируем ненужные в простом офисе функциональные модули:


Выключаем сервисы мониторинга (Ping) и управления (Telnet, Winbox), принимающие подключения с указанием MAC-адреса, если IP-адрес интерфейсу не выдан:


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


Выключаем сервис, предназначенный для приёма подключений с целью тестирования пропускной способности:


Явно выключаем сервисы проксирования клиентских запросов:


LCD-экранчик у Mikrotik откровенно неудобный - выключаем, не особо разбираясь в его возможностях:


Всё, на данном этапе мы имеем устройство, готовое к обслуживанию сети небольшого офиса.