DD-WRT => MikroTik — поэтапная настройка с нуля

[ROOT]

Оглавление

---

Темы
 0. Введение 
 1. Базовые настройки системы 
 2. Настройка интерфейсов 
 3. LAN (Bridge) 
 4. IP-адресация 
 5. DNS (локальная зона + DoH + статические записи) 
 6. IPv6 через WireGuard (Route64) 
 7. Сервисы RouterOS и ограничение доступа 
 8. NTP и дополнительные сервисы 
Дополнительные материалы
Истории умирающего роутера

---

(пример реальной конфигурации)
 0. Введение 
Здесь приведён результат рабочего конфига MikroTik который получился в результате вынужденного перехода DD-WRT. Настройка роутера разбита на логические этапы. Последовательность приближена к реальной процедуре конфигурирования устройства.
Firewall вынесен в конец, так как обычно дорабатывается в процессе эксплуатации.
Данная заметка является практической реализаций Истории умирающего роутера

[ROOT]

 1. Базовые настройки системы 
Настройка имени устройства для идентификации устройства при его администрировании. Часовой пояс крайне важный момент для правильного отображения времени в логах.

Код: выделить все

/system identity set name=gete.free-adm.ru

/system clock set time-zone-autodetect=no time-zone-name=Europe/Moscow


Теперь разберёмся с синхронизацией времени на роутере и узлами нашей сети с роутера. Настроим ntp client и ntp server на маршрутизаторе.

Код: выделить все

/system ntp client set enabled=yes

/system ntp client servers
add address=95.211.123.72
add address=212.1.224.6
add address=212.1.244.6
add address=195.0.1.3

/system ntp server set enabled=yes multicast=yes


Синхронизация времени на устройстве и возможность раздавать время внутрь сети хоть и базовая, но очень важная часть настройки так как взаимодействие с серверами DNS по защищённым протоколам завязано на использование сертификатов, а они имеют сроки действия.
Обратите внимание на заданные мной IP-адреса в качестве источников времени. Чтобы нормально поднялась связь с DNS-серверами время должно быть правильно выставлено

[ROOT]

 2. Настройка интерфейсов 
Теперь назначим роли портам. Интерфейс ether1 смотрит в сторону провайдера и для авторизации на оборудовании провайдера необходим MAC выведенного из эксплуатации роутера. Пример административно назначенного MAC приведён в качестве иллюстрации как можно без звонка в службу поддержки провайдера запустить новое оборудование в полноценную работу.

Код: выделить все

/interface ethernet
set ether1 comment=wan mac-address=84:1B:5E:7A:9D:CF
set ether2 comment="WS For Admin"
set ether5 comment=Printer


[ROOT]

 3. LAN (Bridge) 
Bridge объединяет LAN-интерфейсы в единую L2-сеть. Это базовый элемент всей внутренней топологии: через него работают DHCP, DNS, firewall и маршрутизация.
Важно: при создании моста необходимо сразу задать статический MAC-адрес (`admin-mac`).
Почему это критично
По умолчанию используется `auto-mac=yes`, при котором bridge автоматически получает MAC-адрес одного из интерфейсов. На практике это приводит к нестабильному поведению.

1. MAC-адрес может измениться после перезагрузки
   Порядок инициализации интерфейсов не гарантирован. После ребута bridge может получить MAC от другого порта.
   Это вызывает:
   
   • проблемы с DHCP (смена IP, сломанные static lease)
   • потерю доступа к устройству
   • сбои мониторинга (Netwatch, Dude)
   • временные обрывы из-за обновления ARP-кэша
2. MAC меняется при изменении конфигурации
   Если удалить или отключить интерфейс, от которого был унаследован MAC, bridge сразу выберет новый.
   Результат:
   
   • разрыв активных соединений
   • сброс ARP
   • нестабильность сети
3. Баги RouterOS 7
   В ряде версий (например 7.17) наблюдалось поведение, при котором MAC мог меняться постоянно, что фактически ломает сеть.
4. Зависимость L2-протоколов
   MAC используется в STP/RSTP (Bridge ID). Его изменение или дублирование может привести к:
   
   • петлям
   • неправильной топологии
   • broadcast storm

Практический вывод
`admin-mac` — это не рекомендация, а базовая гигиена конфигурации MikroTik.
Без него поведение сети становится непредсказуемым.
Как задать правильно
Используется LAA (Locally Administered Address):
меняется второй символ MAC на `2`, `6`, `A` или `E`.
Пример:

Код: выделить все

/interface bridge add name=bridge1 comment="For LAN" auto-mac=no admin-mac=EE:FD:74:7E:75:6B


Здесь первый байт MAC изменён на `EE`. Это позволяет не придумывать адрес с нуля.
Добавление интерфейсов в bridge

Код: выделить все

/interface bridge port
add bridge=bridge1 interface=ether2 comment="WS For Admin"
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5 comment=Printer


Роль этапа в общей схеме
Bridge — это точка сборки всей LAN-логики. На него опираются:

• IP-адрес роутера
• DHCP-сервер
• DNS
• Firewall (LAN → WAN)
• IPv6 (ND, адресация)

Ошибка на этом этапе приводит к нестабильной работе всей сети.
Резюме
Настройка `admin-mac`:

• устраняет плавающие изменения MAC
• делает поведение сети предсказуемым
• защищает от сбоев при ребутах и изменениях конфигурации

Это обязательный элемент корректной настройки bridge в MikroTik.

[ROOT]

 4. IP-адресация 
После создания bridge необходимо назначить ему IP-адрес. Это точка входа в управление роутером и основа для всех сервисов (DHCP, DNS, firewall).
IPv4 адрес на bridge

Код: выделить все

/ip address
add address=195.0.1.254/24 comment="ip on bridge" interface=bridge1 network=195.0.1.0


Здесь:

• 195.0.1.254 — адрес роутера в LAN
• /24 — маска сети
• bridge1 — интерфейс LAN

Практика: обычно шлюз делают первый или последний адрес сети — это не принципиально, важно соблюдать единообразие.

Почему адрес вешается именно на bridge

Bridge — это логический интерфейс, объединяющий все LAN-порты.
Назначая IP на него, мы автоматически делаем доступными все порты и Wi-Fi в том числе.

Если повесить IP на отдельный порт:

• часть сети станет «вне управления»
• DHCP не сможет корректно работать
• появятся странные баги с доступом

Подготовка IPv6 (базово)
IPv6 в этой конфигурации приходит через WireGuard (route64), но локальная адресация всё равно должна быть задана, поскольку WireGuard не поддерживает DHCP ни в каком виде.

Код: выделить все

/ipv6 address
add address=fe80::1 advertise=no comment="Manual address" interface=bridge1
add address=2a11:6c7:1202:6200::254 comment="Route64 For Bridge Lan" interface=bridge1


Здесь:

• fe80::1 — link-local адрес (служебный)
• глобальный префикс — для LAN

Что это даёт
После этого этапа:

• роутер доступен по IP
• есть точка для DHCP
• есть база для DNS
• готов фундамент для firewall

Типичные ошибки

• Назначение IP не на bridge, а на ether-порт
• Несовпадение сети и пула DHCP
• Отсутствие IPv6-адреса при использовании IPv6

Резюме
IP-адрес на bridge — это фундамент всей конфигурации.
Если здесь ошибка — дальше ломается всё: от DHCP до firewall.
4. IP-адресация и DHCP (IPv4 + IPv6)
После создания bridge и добавления в него интерфейсов следующим шагом идёт назначение адресации.
Именно на этом этапе сеть "оживает" — появляется шлюз, DHCP и базовая связность.
IPv4 адрес на LAN (bridge)
IP-адрес назначается не на физические интерфейсы, а на bridge — это и есть точка маршрутизации для всей локальной сети:

Код: выделить все

/ip address
add address=195.0.1.254/24 comment="ip on bridge" interface=bridge1 network=195.0.1.0


Это:

• шлюз для клиентов
• DNS (если используется локальный резолвер)
• точка, через которую пойдёт NAT и firewall

DHCP сервер (IPv4)
Сначала создаётся пул адресов:

Код: выделить все

/ip pool
add name=LanPool ranges=195.0.1.200-195.0.1.250 comment="pool for lan"


Затем сам DHCP-сервер:

Код: выделить все

/ip dhcp-server
[hr]
add name=dhcp1 interface=bridge1 address-pool=LanPool lease-time=3h comment="Server For LAN on Bridge1"


И сеть с параметрами:

Код: выделить все

/ip dhcp-server network
add address=195.0.1.0/24 \
    gateway=195.0.1.254 \
    dns-server=195.0.1.254 \
    domain=free-adm.ru \
    ntp-server=195.0.1.254 \
    comment="Main LAN"


Практические моменты:

• пул начинается не с .1 — нижняя часть диапазона оставлена под статику
• DNS указывает на сам роутер → удобно для локальной зоны
• lease-time = 3h — компромисс между стабильностью и обновлением

IPv6 адресация
В конфигурации используется статически назначенный /64 префикс:

Код: выделить все

/ipv6 address
add address=2a11:6c7:1202:6200::254 interface=bridge1 comment="Route64 For Bridge LAN"
add address=fe80::1 interface=bridge1 advertise=no comment="Manual link-local"


Что здесь важно:

• `/64` — стандарт для LAN, без вариантов
• адрес `::254` используется как gateway (аналог IPv4 .254)
• link-local задан вручную (не обязательно, но даёт предсказуемость)

Раздача IPv6 (RA / ND)
Вместо DHCPv6 для базовой сети используется Router Advertisement:

Код: выделить все

/ipv6 nd
set [ find default=yes ] interface=bridge1 advertise-dns=yes mtu=1412


Это даёт:

• автоматическую настройку адреса (SLAAC)
• раздачу DNS
• корректный MTU (актуально при туннелях, например WireGuard)

Важно:

• DHCPv6 здесь не используется — и это нормальная практика
• клиенты получают адреса сами, на основе префикса

DHCP клиент (WAN)
Интернет-интерфейс получает IPv4 от провайдера:

Код: выделить все

/ip dhcp-client
add interface=ether1 name=ether1 use-peer-dns=no use-peer-ntp=no comment="dhcp isp"


Отключение `use-peer-dns` и `use-peer-ntp` сделано осознанно:

• DNS управляется вручную (см. следующий раздел)
• исключается "подмена" настроек от провайдера

Резюме
На этом этапе у нас уже есть:

• единая L2 сеть (bridge)
• шлюз IPv4 и IPv6
• DHCP для IPv4
• SLAAC для IPv6

Сеть полностью работоспособна на уровне L3, и можно переходить к:

• DNS (локальная зона + DoH)
• либо сразу к firewall (если нужен минимальный базовый доступ)

[ROOT]

 5. DNS (локальная зона + DoH + статические записи) 

После настройки IP-адресации и DHCP логично перейти к DNS. В данной схеме MikroTik выполняет сразу несколько задач:

• DNS-резолвер для локальной сети
• кеширующий DNS-сервер
• обслуживание локальной зоны free-adm.ru
• DNS-over-HTTPS клиент

Базовая настройка DNS

Код: выделить все

/ip dns
set allow-remote-requests=yes servers=45.90.30.0,45.90.28.0 \
    use-doh-server=https://dns.nextdns.io/4a59c7 verify-doh-cert=yes


Описание параметров:

• allow-remote-requests=yes — разрешает клиентам LAN использовать роутер как DNS-сервер
• servers — резервные DNS-серверы
• use-doh-server — использование DNS-over-HTTPS
• verify-doh-cert=yes — обязательная проверка TLS-сертификата DoH сервера

Почему DNS-over-HTTPS (DoH)
Обычный DNS передаёт запросы в открытом виде.
DoH позволяет:

• шифровать DNS-трафик
• исключить подмену ответов провайдером
• использовать единый DNS для всей сети

При этом нужно учитывать:

• DoH немного увеличивает задержки при пустом кеше
• часть нагрузки компенсируется DNS-кешем MikroTik
• при недоступности DoH используются fallback DNS из параметра servers

Локальная DNS-зона
Для домашней лаборатории и внутренней инфраструктуры удобно держать собственную DNS-зону прямо на маршрутизаторе.
Пример:

Код: выделить все

/ip dns static
add address=195.0.1.3 comment="apex A" name=free-adm.ru type=A
add address=2a11:6c7:1202:6200::3 comment="apex AAAA" name=free-adm.ru type=AAAA

add address=195.0.1.254 comment="gateway DNS" name=ns1.free-adm.ru type=A
add address=2a11:6c7:1202:6200::254 comment="gateway DNS v6" name=ns1.free-adm.ru type=AAAA

add address=195.0.1.5 name=printer.free-adm.ru type=A
add address=2a11:6c7:1202:6200:3e4a:62ff:feb3:6e4c name=printer.free-adm.ru type=AAAA


Практический смысл:

• внутренние сервисы доступны по именам
• не требуется внешний DNS для локальной инфраструктуры
• удобно использовать как в IPv4, так и в IPv6
• проще сопровождать лабораторные стенды

CNAME-записи

Для алиасов используются CNAME:

Код: выделить все

add cname=sergey.free-adm.ru name=wiki.free-adm.ru type=CNAME
add cname=sergey.free-adm.ru name=blog-prog.free-adm.ru type=CNAME
add cname=sergey.free-adm.ru name=test.free-adm.ru type=CNAME


Это позволяет:

• не дублировать IP-адреса
• централизованно менять основной хост
• сохранять читаемость зоны

TXT-записи
RouterOS также поддерживает TXT:

Код: выделить все

add name=gate.free-adm.ru \
    text="TEXT record " type=TXT


Могут использоваться:

• для служебных записей
• SPF/DMARC/DKIM
• проверок владения доменом
• внутренних заметок и тестов

Практические замечания

• RouterOS не является полноценным DNS-сервером уровня BIND/PowerDNS
• все записи хранятся в flat-структуре `/ip dns static`
• при большом количестве записей конфигурация быстро разрастается
• важно следить за актуальностью A и AAAA записей

Резюме
На данном этапе маршрутизатор:

• раздаёт DNS клиентам LAN
• резолвит внешние запросы через DoH
• обслуживает локальную DNS-зону
• поддерживает dual-stack инфраструктуру IPv4/IPv6

[ROOT]

 6. IPv6 через WireGuard (Route64) 
Так как далеко не все провайдеры предоставляют полноценный IPv6, одним из самых удобных вариантов остаётся получение IPv6 через туннель.
В данной конфигурации используется WireGuard-туннель до Route64.
Преимущества такого подхода:

• полноценный глобальный IPv6
• простая настройка
• минимальный overhead
• хорошая стабильность
• WireGuard значительно проще классических 6in4/SIT туннелей

Создание WireGuard-интерфейса

Код: выделить все

/interface wireguard
add comment="route64 IPv6 over WG" listen-port=13830 mtu=1412 name=wg-ipv6

Описание:

• listen-port — UDP-порт WireGuard
• mtu=1412 — уменьшенный MTU для избежания фрагментации
• name=wg-ipv6 — отдельный интерфейс под IPv6

Настройка peer

Код: выделить все

/interface wireguard peers
add allowed-address=::/1,8000::/1 client-allowed-address=::/0  comment="to server route64" \
    endpoint-address=118.91.187.67 endpoint-port=20041 interface=wg-ipv6 persistent-keepalive=15s public-key="3e+..."

Что здесь важно:

• allowed-address=::/1,8000::/1 — split default route для IPv6
• endpoint-address — адрес WireGuard сервера
• persistent-keepalive=15s — поддержание NAT-сессии
• client-allowed-address=::/0 — разрешение полного IPv6-маршрута

Почему используется ::/1 и 8000::/1
В RouterOS такой способ часто применяется вместо прямого `::/0`.
Причины:

• избежание конфликтов маршрутизации
• более предсказуемая работа policy routing
• корректная установка default route через WG

Фактически:

• ::/1 — первая половина IPv6 пространства
• 8000::/1 — вторая половина

Вместе они эквивалентны `::/0`.
IPv6-адрес на WireGuard интерфейсе

Код: выделить все

/ipv6 address
add address=2a11:6c7:f04:189::2 advertise=no comment="My address tunnel Route64" interface=wg-ipv6

Параметр `advertise=no` отключает RA-анонсы на туннельном интерфейсе.
Маршрут по умолчанию

Код: выделить все

/ipv6 route
add comment="To Route64"  disabled=no distance=1 dst-address=::/0 gateway=wg-ipv6

После этого весь IPv6-трафик начинает уходить через WireGuard.

IPv6 в LAN

Префикс локальной сети уже был назначен bridge-интерфейсу на этапе IP-адресации. После появления default route через WireGuard клиенты автоматически получают полноценную IPv6-связность.
Теперь клиенты LAN:

• получают глобальные IPv6-адреса
• могут работать без NAT
• имеют полноценную IPv6-связность

Router Advertisement
Настройка ND:

Код: выделить все

/ipv6 nd
set [ find default=yes ] advertise-dns=yes interface=bridge1 mtu=1412

Что это даёт:

• автоматическая раздача IPv6 клиентам
• передача DNS через RA
• единый MTU для всей IPv6 сети

Почему MTU=1412 важен
WireGuard добавляет служебные заголовки.
Если оставить стандартный MTU 1500:

• появляется фрагментация
• часть сайтов может открываться нестабильно
• возможны проблемы с PMTU

Поэтому MTU уменьшается:

• на WG интерфейсе
• в Router Advertisement
• для всей IPv6 LAN

Резюме
На данном этапе:

• маршрутизатор получил глобальный IPv6
• IPv6 работает через WireGuard
• LAN получает IPv6 автоматически
• клиенты имеют полноценный dual-stack доступ

---

WireGuard и IPv6 через Route64
В данной конфигурации IPv6-подключение организовано через туннель WireGuard от Route64.
Подобная схема особенно удобна:

• если провайдер не выдаёт IPv6
• если native IPv6 нестабилен
• если требуется быстрое и предсказуемое подключение
• для домашних лабораторий

В RouterOS WireGuard работает стабильно и значительно проще в сопровождении, чем:

• 6to4
• GRE
• IPIP
• HE tunnelbroker

Создание WireGuard-интерфейса
Создаём интерфейс:

Код: выделить все

/interface wireguard
add comment="route64 IPv6 over WG" \
    listen-port=13830 \
    mtu=1412 \
    name=wg-ipv6


Здесь:

• listen-port — UDP-порт WireGuard
• mtu=1412 — уменьшенный MTU для избежания фрагментации
• name=wg-ipv6 — отдельный интерфейс под IPv6-трафик

Настройка peer
Добавляем peer провайдера:

Код: выделить все

/interface wireguard peers
add allowed-address=::/1,8000::/1 \
    client-allowed-address=::/0 comment="to server route64" \
    endpoint-address=118.91.187.67 endpoint-port=20041 \
    interface=wg-ipv6 name=peer2 \
    persistent-keepalive=15s public-key="3e+....="

Почему используются ::/1 и 8000::/1
Это распространённый приём для IPv6 через WireGuard.
Вместо:

Код: выделить все

::/0

используются две половины IPv6-пространства:

Код: выделить все

::/1
8000::/1

Это позволяет:

• корректно обрабатывать default route
• избежать некоторых конфликтов маршрутизации
• обойти ограничения отдельных клиентов и реализаций WG

Persistent Keepalive

Код: выделить все

persistent-keepalive=15s

Нужен для:

• NAT
• CGNAT
• нестабильных провайдеров
• удержания туннеля активным

Особенно полезно:

• в домашних сетях
• за NAT
• при мобильных подключениях

IPv6-адрес на WireGuard-интерфейсе
Назначаем адрес туннелю:

Код: выделить все

/ipv6 address
add address=2a11:6c7:f04:189::2 \
    advertise=no \
    comment="My address tunnel Route64" \
    interface=wg-ipv6

Параметр:

Код: выделить все

advertise=no

важен потому, что:

• туннельный интерфейс не должен участвовать в RA
• префикс объявляется только в LAN
• WireGuard здесь является transport-интерфейсом

Маршрут IPv6 по умолчанию
Добавляем default route:

Код: выделить все

/ipv6 route
add comment="To Route64" \
    disabled=no distance=1 \
    dst-address=::/0 gateway=wg-ipv6 \
    routing-table=main \
    scope=30 target-scope=10

Теперь весь IPv6-трафик отправляется через WireGuard-туннель.
MTU и MSS
Для IPv6 через WireGuard проблема MTU особенно критична.
Без корректировки MSS возможны:

• подвисания HTTPS
• обрывы крупных TCP-сессий
• частично открывающиеся сайты
• нестабильная работа QUIC

В конфигурации используется mangle:

Код: выделить все

/ipv6 firewall mangle
add action=change-mss \
    chain=forward comment="force MSS" \
    new-mss=1320 out-interface=wg-ipv6 \
    protocol=tcp tcp-flags=syn

Это принудительно уменьшает MSS TCP-соединений.
Подобная практика для IPv6-over-WireGuard фактически стала стандартной.
Router Advertisement (RA)
Для LAN включаем IPv6 ND:

Код: выделить все

/ipv6 nd
set [ find default=yes ] advertise-dns=yes interface=bridge1  mtu=1412

Здесь:

• клиенты автоматически получают IPv6-префикс
• раздаётся DNS через RA
• передаётся корректный MTU

Последний пункт крайне важен:
если MTU не объявить через RA — часть клиентов продолжит использовать 1500 и получит проблемы с фрагментацией.

Старый HE tunnelbroker (отключённый)

В конфигурации также остался старый HE-туннель:

Код: выделить все

/interface 6to4
add comment="HE IPv6 Tunnel" disabled=yes local-address=213.141.132.190 mtu=1280 name=sit1 remote-address=216.66.87.102


и связанные маршруты/адреса.

Он сохранён:

• как резерв
• для сравнения
• как пример альтернативного IPv6-подключения

Но основная рабочая схема сейчас построена именно на WireGuard.
Резюме
На данном этапе:

• поднят WireGuard-туннель
• IPv6 получен через Route64
• LAN получает IPv6 через RA
• настроен IPv6 default route
• исправлены проблемы MTU/MSS
• HE tunnelbroker выведен из эксплуатации

[ROOT]

 7. Сервисы RouterOS и ограничение доступа 
После настройки базовой сетевой инфраструктуры имеет смысл сразу ограничить доступ к службам самого маршрутизатора.
По умолчанию RouterOS поднимает несколько сервисов управления:

• WinBox
• SSH
• Web
• API
• Telnet
• FTP

Часть из них в современной сети либо не используется, либо считается небезопасной.
Отключение ненужных сервисов

Код: выделить все

/ip service
set ftp disabled=yes
set telnet disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl disabled=yes


Почему это важно:

• уменьшается поверхность атаки
• меньше открытых TCP-портов
• снижается вероятность эксплуатации уязвимостей

Ограничение доступа к управлению
Доступ к SSH и WinBox разрешён только из локальной сети:

Код: выделить все

/ip service
set ssh address=195.0.1.0/24,2a11:6c7:1202:6200::/64
set winbox address=195.0.1.0/24,2a11:6c7:1202:6200::/64


Здесь перечислены доверенные подсети, если нужны более строгие ограничения, то можно указать конкретные IP-адреса
Практически это означает:

• доступ к управлению невозможен извне
• службы слушают только доверенные подсети
• даже при ошибке firewall сервисы останутся ограниченными

Это важный момент:

• firewall фильтрует трафик
• параметр address в `/ip service` ограничивает сам сервис

То есть это дополнительный уровень защиты.
MAC-доступ к устройству
RouterOS поддерживает управление через MAC-протоколы:

• MAC-Telnet
• MAC-WinBox

Ограничиваем их только LAN:

Код: выделить все

/tool mac-server
set allowed-interface-list=LAN_IF

/tool mac-server mac-winbox
set allowed-interface-list=LAN_IF

Почему это важно:

• MAC-WinBox работает даже без IP
• при ошибочной настройке WAN можно случайно открыть доступ снаружи
• ограничение через interface-list предотвращает подобные ситуации

SSH hardening
RouterOS 7 поддерживает современные типы host key.

Код: выделить все

/ip ssh
set host-key-type=ed25519


Добавляем ключ для SSH на роутер

Код: выделить все

scp id_route.pub AdminUser@195.0.1.254:

Затем заходим на маршрутизатор и импортируем ключ под нужного пользователя.

Код: выделить все

/ip/ssh/

Почему ED25519:

• быстрее RSA
• меньше размер ключей
• лучше криптографическая стойкость
• современный стандарт де-факто

Практические замечания
Даже в домашней лаборатории желательно:

• не использовать admin
• создавать отдельного пользователя
• использовать длинные пароли
• не открывать WinBox наружу
• не публиковать API без необходимости

Если требуется внешний доступ:

• лучше использовать WireGuard
• либо address-list + firewall filter
• либо доступ только через VPN

Резюме
На данном этапе:

• отключены ненужные сервисы
• управление ограничено LAN
• MAC-доступ ограничен bridge-сетью
• SSH переведён на ED25519
• маршрутизатор стал заметно безопаснее

[ROOT]

 8. NTP и дополнительные сервисы 
После настройки базовой сети и управления можно переходить к вспомогательным службам RouterOS.
В данной конфигурации маршрутизатор используется:

• как NTP-клиент
• как локальный NTP-сервер
• как SMB-сервер для USB-накопителя

Настройка времени (NTP client)
Корректное время критично для:

• логирования
• сертификатов
• DoH
• WireGuard
• отладки
• планировщика

Сначала зададим временную зону:

Код: выделить все

/system clock
set time-zone-autodetect=no time-zone-name=Europe/Moscow

Далее включаем NTP-клиент:

Код: выделить все

/system ntp client
set enabled=yes

Добавляем серверы времени:

Код: выделить все

/system ntp client servers
add address=95.211.123.72
add address=212.1.224.6
add address=212.1.244.6
add address=195.0.1.3

В качестве источников используются:

• внешние публичные NTP-серверы
• локальный сервер в LAN

Подобная схема повышает устойчивость:

• роутер продолжит получать время даже при недоступности части серверов
• локальный NTP уменьшает количество внешних запросов
• внутренние машины могут синхронизироваться локально

NTP server на MikroTik
RouterOS может раздавать время клиентам локальной сети:

Код: выделить все

/system ntp server
set enabled=yes multicast=yes

Это удобно для:

• домашней лаборатории
• виртуальных машин
• сетевого оборудования
• изолированных сегментов

В небольшой сети MikroTik вполне способен выполнять роль локального stratum-сервера.
SMB-сервер RouterOS
RouterOS поддерживает простой SMB-сервер для USB-накопителей.
В данной конфигурации USB-диск экспортируется в LAN:

Код: выделить все

/ip smb
set domain=ENG enabled=yes interfaces=bridge1

Создаём пользователя:

Код: выделить все

/ip smb users
add name=serg

Публикуем каталог:

Код: выделить все

/ip smb shares
add comment="Shara On Mikritik" directory=/usb1 invalid-users=guest name=samba require-encryption=yes valid-users=serg

Что здесь важно:

• гостевой доступ отключён
• доступ разрешён только авторизованному пользователю
• включено SMB encryption
• служба доступна только через LAN

Практические замечания по SMB
SMB в RouterOS не заменяет полноценный NAS:

• нет RAID
• ограничена производительность
• минимальный набор возможностей

Но этого вполне достаточно для:

• временного файлового хранилища
• обмена файлами
• резервных копий
• небольшой домашней сети

Особенно удобно:

• на роутерах с USB 3.0
• при наличии внешнего SSD/HDD
• для лабораторных задач

Резюме
На данном этапе:

• маршрутизатор синхронизирует время через NTP
• локальная сеть получает единое время
• поднят SMB-сервер для USB-накопителя
• дополнительные сервисы ограничены LAN-сегментом