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

[ROOT]

Оглавление

---

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

---

(пример реальной конфигурации)
 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


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

---

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

При создании конфигурации было принято решение отказаться от поддержки legacy-режимов и использовать только современные стандарты IEEE 802.11n и 802.11ac. Это позволяет повысить пропускную способность сети и исключить влияние медленных клиентов на общую производительность точки доступа.

Для диапазона 2,4 ГГц рекомендуется использовать только каналы 1, 6 или 11, так как именно они не перекрываются между собой и обеспечивают минимальный уровень взаимных помех. Использование промежуточных каналов (например, 3, 5, 8 или 9) чаще всего лишь ухудшает ситуацию, увеличивая количество пересекающихся сетей.

Диапазон 5 ГГц менее загружен и обеспечивает значительно более высокие скорости передачи данных, поэтому при наличии поддержки со стороны клиентских устройств предпочтительно использовать именно его.

Приведённая ниже конфигурация не претендует на универсальность и отражает настройки, которые показали стабильную работу в реальных домашних условиях эксплуатации. Интерфейс wlan1 (2.4 GHz) отключен намеренно, но тем не менее он всё равно добавляется в мост.

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

/interface wireless
set [ find default-name=wlan1 ] comment="2.4 GHz" country=russia4 mode=ap-bridge ssid=BR0-2GHz
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40mhz-eC comment="5 GHz" country=russia4 disabled=\
    no installation=indoor mode=ap-bridge ssid=BR0-5GHz wps-mode=disabled
/interface wireless manual-tx-power-table
set wlan1 comment="2.4 GHz"
set wlan2 comment="5 GHz"
/interface wireless nstreme
set wlan1 comment="2.4 GHz"
set wlan2 comment="5 GHz"
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys supplicant-identity=MikroTik \
    wpa2-pre-shared-key=Pa$$w0rd

[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 comment="WS For Admin" interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 comment="Printer" interface=ether5
add bridge=bridge1 comment="2.4 GHz" interface=wlan1
add bridge=bridge1 comment="5GHz" interface=wlan2


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

• WAN_IF
• LAN_IF

Создадим необходимые нам списки и причислим к ним соответствующие интерфейсы:

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

/interface list
add comment="Interface to ISP" name=WAN_IF
add comment="Interface Bridge For LAN" name=LAN_IF
add comment="Interfaces For OSPF" name=OSPF-LAN

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

/interface list member
add comment="to isp" interface=ether1 list=WAN_IF
add comment="to bridge" interface=bridge1 list=LAN_IF
add interface=bridge1 list=OSPF-LAN

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

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

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

Ошибка на этом этапе приводит к нестабильной работе всей сети.

Резюме
Настройка `admin-mac`:

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

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

[ROOT]

 4. IPv4-адресация 
После создания 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
IP-адрес назначается не на физические интерфейсы, а на bridge — это и есть точка маршрутизации для всей локальной сети:
Это:

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

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

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

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

Если понадобится организовать доступ в сегмент сети с другой адресацией, то порт, через который подключается такой сегмент, вводить в бридж не нужно, так же как порт для подключения к провайдеру. Принцип тот же и с гостевыми сетями WiFi. При данной схеме можно довольно гибко ограничивать доступ между сетями через firewall.

DHCP-сервер IPv4
После создания bridge и добавления в него интерфейсов следующим шагом идёт назначение адресации.
Именно на этом этапе сеть "оживает" — появляется шлюз, DHCP и базовая связность.

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

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

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


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

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

/ip dhcp-server
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 — компромисс между стабильностью и обновлением

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 управляется вручную (см. следующий раздел)
• исключается "подмена" настроек от провайдера

---

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

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

/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 адрес (служебный) задан вручную (не обязательно, но даёт предсказуемость)
• глобальный префикс /64` — стандарт для LAN, без вариантов
• адрес `::254` используется как gateway (аналог IPv4 .254)

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

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

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

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

Резюме
IP-адрес на bridge — это фундамент всей конфигурации.
Если здесь ошибка — дальше ломается всё: от DHCP до firewall.

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

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

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


Это даёт:

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

Важно:

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

---

Prefix Delegation (DHCPv6-PD) на MikroTik: полный разбор
Что такое Prefix Delegation и зачем он нужен

Prefix Delegation (PD) — это механизм DHCPv6, позволяющий маршрутизатору запросить у вышестоящего провайдера (или другого роутера) не просто один адрес, а целую подсеть для использования на своих внутренних интерфейсах.

Если говорить просто: ваш роутер получает по WAN один IPv6-адрес для себя и делегированный префикс (например, `/56` или `/60`), который можно нарезать на `/64` и раздать клиентам в локальной сети.

Базовая настройка на основном роутере (DHCPv6-сервер)

Предположим, у вас есть блок `2a11:6c7:1202:6200::/56`. Создаём пул и DHCPv6-сервер:

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

/ipv6 pool
add name=DinamicPool prefix=2a11:6c7:1202:6200::/56 prefix-length=64

/ipv6 dhcp-server
add address-pool=DinamicPool interface=bridge1 name=server1

Параметр `prefix-length=64` жёстко определяет, что из этого пула будут выдаваться только `/64`. Это первая важная особенность RouterOS: один пул — одна длина префикса. Если клиент запросит `/62`, сервер просто проигнорирует запрос, потому что пул так не умеет.

Проблема: как выдать несколько префиксов одному клиенту
Допустим, к основному роутеру подключен тестовый роутер, у которого несколько внутренних интерфейсов. Каждому нужен свой `/64`. Как их получить?

Стандартный DHCPv6-PD использует для различения запросов от одного клиента поле IAID (Identity Association Identifier). Один клиент с одним DUID может запросить несколько префиксов, если использует разные IAID.

Но RouterOS не позволяет задать IAID вручную. Более того, нельзя создать два DHCPv6-клиента на одном физическом интерфейсе. Это программное ограничение.

Решение: делегирование крупного блока

Правильный путь — не пытаться получить несколько `/64` по отдельности, а запросить один более крупный префикс, которого хватит на все внутренние сети. Например, `/60` содержит 16 подсетей `/64`.

Шаг 1: Планирование адресного пространства

Сначала разбиваем `/56` на блоки `/60`, чтобы избежать пересечений:

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

/56 -> 16 блоков /60:
2a11:6c7:1202:6200::/60  <- для динамической раздачи
2a11:6c7:1202:6210::/60  <- для тестового роутера
2a11:6c7:1202:6220::/60  <- для следующего

Шаг 2: Настройка основного роутера

Создаём отдельный пул для делегирования `/60`:

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

/ipv6 pool
add name=Pool60 prefix=2a11:6c7:1202:6210::/60 prefix-length=60

Создаём статическую привязку (binding) для тестового роутера, где указываем его DUID и отдельный пул:

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

/ipv6 dhcp-server binding
add address=2a11:6c7:1202:6210::/60 duid=0x00030001080027feb9f8 iaid=0 pool=Pool60 server=server1

Параметр `pool=Pool60` — ключевой. Он переопределяет пул по умолчанию и позволяет выдать клиенту префикс другой длины, чем `DinamicPool`.

Шаг 3: Настройка тестового роутера (клиента)

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

/ipv6 dhcp-client
add add-default-route=yes interface=ether1 pool-name=P1 pool-prefix-length=64 request=prefix

Параметр `pool-prefix-length=64` указывает, что полученный префикс нужно нарезать на `/64` внутри пула `P1`.

Теперь назначаем адреса на внутренние интерфейсы:

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

/ipv6 address
add address=::1 from-pool=P1 interface=ether2
add address=::1 from-pool=P1 interface=ether3

Важный момент: RouterOS (начиная с версий 7.22+) автоматически раздаёт разные `/64` из пула на разные интерфейсы! Первый интерфейс получает первую подсеть (`6210::1/64`), второй — следующую (`6211::1/64`), и так далее. Ручная нарезка не требуется.

Тонкости и обнаруженные "грабли"

1. Prefix-length в пуле — жёсткое ограничение
   Если в пуле `prefix-length=64`, а клиент просит `/62` — сервер отказывает. Нельзя из одного пула выдавать префиксы разной длины. Нужны отдельные пулы.
2. Статическая привязка становится INVALID при смене пула
   Если изменить `prefix-length` в пуле, к которому привязан клиент, его статическая привязка становится INVALID без предупреждения.
3. Родительский пул не нужен
   Сам делегированный `/56` нигде не используется и не создаётся как отдельный пул. Он существует только как "граница ответственности" для планирования подсетей. RouterOS ничего о нём не знает.
4. Автоматическая нарезка работает
   В свежих версиях RouterOS конструкция `from-pool` + `pool-prefix-length` заставляет роутер автоматически нарезать делегированный префикс на `/64` и распределять по интерфейсам. Это поведение стало стабильным примерно с версий 7.22-7.23.
5. Два клиента на одном интерфейсе — нельзя
   Программное ограничение RouterOS. Обходится либо VLAN-костылями, либо (правильно) делегированием более крупного блока.
6. IAID задать вручную нельзя
   MikroTik вычисляет IAID автоматически из внутреннего ID интерфейса. В версиях 7.23+ разработчики активно дорабатывают гибкость управления пулами (появился `from-pool-policy`), возможно, в будущем появится и ручное управление IAID.

Что в итоге

Рабочая схема для раздачи нескольких префиксов через один кабель:

• На основном роутере: пул для динамической раздачи (`/60` с `prefix-length=64`) и отдельные пулы для делегирования крупных блоков (`/60` с `prefix-length=60`).
• Статическая привязка с явным указанием пула для каждого нижестоящего роутера.
• На тестовом роутере: один DHCPv6-клиент, `pool-prefix-length=64`, адреса через `from-pool` на каждом внутреннем интерфейсе.

Схема проверена на RouterOS 7.22.1 (основной) и 7.23rc4 (тестовый). Работает стабильно, адреса нарезаются автоматически.

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

/ipv6 dhcp-server
add address-pool=DinamicPool comment="For Dinamic Prefix" insert-queue-before=bottom interface=bridge1 name=server1 \
    prefix-pool=DinamicPool
/ipv6 dhcp-server binding
add address=2a11:6c7:1202:6200::/64 duid=0x00030001080027feb9f8 iaid=0 server=server1
add address=2a11:6c7:1202:6210::/60 duid=0x000300010c9504fd0000 iaid=2 life-time=3d prefix-pool=Delegation-TestRouter \
    server=server1

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

• единая L2 сеть (bridge)
• шлюз IPv4 и IPv6
• DHCP для IPv4
• DHCPv6 PD для раздачи префиксов для тестовых сетей
• 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:

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

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

/user ssh-keys import public-key-file=id_route.pub user=AdminUser

По умолчанию 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-сегментом

[ROOT]

 9. Настройка OSPFv2 и OSPFv3 основного роутера 
Для бесшовной маршрутизации между реальной сетью и виртуальными сегментами будем использовать OSPF для обеих версий протокола IP. Основной роутер будет раздавать маршруты виртуальным машинам и тестовым сетям, а также получать маршруты от них.

Подготовка интерфейсов
Создадим список интерфейсов OSPF-LAN, в который добавим все интерфейсы, участвующие в OSPF. На данном роутере используется бридж bridge1, объединяющий физические порты локальной сети, поэтому в список добавляем именно его. При необходимости список можно расширить, добавив другие интерфейсы — OSPF подхватит их автоматически.

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

/interface list
add comment="For Interface OSPF" name=OSPF-LAN
/interface list member
add interface=bridge1 list=OSPF-LAN

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

Запуск процессов OSPF
Для каждого протокола поднимаем отдельный процесс. Это обеспечивает изоляцию маршрутов IPv4 и IPv6 и упрощает управление.

• OSPFv2 (IPv4): используется originate-default=always — роутер всегда анонсирует себя как шлюз по умолчанию для всех соседей в зоне. redistribute=static позволяет автоматически пробрасывать статические маршруты (удобно для специфических сетей, VPN, заглушек).
• OSPFv3 (IPv6): шлюз по умолчанию не анонсируется через OSPF, так как его предоставляет Router Advertisement (RA) — все хосты и так получают дефолтный маршрут через SLAAC или DHCPv6. redistribute=static опущен намеренно: в IPv6 статические маршруты часто включают туннельные префиксы (например, WireGuard) и ULA-адреса, которые не должны утекать в общую маршрутизацию.

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

/routing ospf instance
add disabled=no name=ospf-Lan originate-default=always redistribute=static router-id=195.0.1.254
add disabled=no name=ospf-Lan-v6 router-id=195.0.1.254 version=3

Важно: по умолчанию RouterOS использует OSPFv2, поэтому для IPv6 необходимо явно указать version=3.

Привязка к областям
Каждый процесс связываем со своей областью (area). В данной конфигурации оба процесса работают в магистральной области 0.0.0.0 (backbone), которая является центральной для OSPF-домена. Имена областей заданы осмысленно для удобства администрирования.

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

/routing ospf area
add comment="Area 0 v4" disabled=no instance=ospf-Lan name=ospf-area-0
add comment="Area 0 v6" disabled=no instance=ospf-Lan-v6 name=ospf-area-0-v6

Шаблоны интерфейсов
Связываем области, списки интерфейсов и параметры аутентификации через шаблоны. Теперь любой интерфейс, добавленный в список OSPF-LAN, автоматически окажется в соответствующей OSPF-зоне с заданными настройками безопасности.

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

/routing ospf interface-template
add area=ospf-area-0 auth=md5 auth-key=pass comment="Real Network v4" disabled=no interfaces=OSPF-LAN
add area=ospf-area-0-v6 auth=md5 auth-key=pass comment="Real Network v6" disabled=no interfaces=OSPF-LAN

MD5-аутентификация защищает OSPF-сессии от несанкционированного соседства. В продакшене рекомендуется использовать более стойкие механизмы (SHA), но для HomeLab MD5 вполне достаточно.

Итог
При такой конфигурации достигается несколько целей:

• Автоматизация: добавление нового сегмента сети сводится к добавлению интерфейса в список OSPF-LAN — OSPF подхватывает его автоматически.
• Изоляция протоколов: IPv4 и IPv6 живут в отдельных OSPF-процессах, что исключает нежелательное смешивание маршрутов и упрощает диагностику.
• Безопасность: аутентификация предотвращает появление нежелательных соседей.
• Масштабируемость: можно без опаски поднимать дополнительные тестовые сети и виртуальные сегменты — маршрутизация между ними будет работать бесшовно.

[ROOT]

 10. Журналирование 

Настраиваем журналирование системы для удобного чтения логов. Выделяем значимые для нас сервисы и настраиваем им соответствующие буфера необходимой размерности. А так же указать сообщения каких типов будут попадать в созданные буферы. В приведённом примере исключён уровень debug поскольку он считается избыточным для нормально отлаженной системы. Считаю, debug следует применять при сложной диагностике неполадок какого-либо сервиса, для сбора необходимых данных.

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

/system logging action
add memory-lines=100 name=WG target=memory
add memory-lines=100 name=OSPF target=memory
add memory-lines=100 name=DNS target=memory
add memory-lines=100 name=DHCP target=memory
add memory-lines=100 name=NTP target=memory
add memory-lines=100 name=WIFI target=memory
add memory-lines=100 name=SSH target=memory

/system logging
add action=WIFI topics=wireless,!debug
add action=WG topics=wireguard,!debug
add action=OSPF topics=ospf,!packet,!debug
add action=DNS topics=dns,!packet
add action=DHCP topics=dhcp,!packet,!debug
add action=NTP topics=ntp,debug
add action=SSH topics=ssh,info,!state,!packet


теперь для просмотра лога по интересующей нас службе используем конструкцию:

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

/log/print where buffer=<action>

[ROOT]

 Firewall IPv4 
После настройки интерфейсов, маршрутизации и сервисов необходимо определить правила обработки трафика. Основной принцип данной конфигурации — разрешено только то, что действительно необходимо, всё остальное блокируется.

Для упрощения сопровождения используются `address-list`, а сами правила разделены на логические цепочки (`FWD`, `FWD_ALLOW`, `WAN_INPUT`, `WAN_INPUT_ALLOW`). Это делает конфигурацию более читаемой и позволяет быстро находить нужный участок.

Address Lists
Используемые списки адресов:

• `admin` — адреса, с которых разрешено администрирование маршрутизатора.
• `LAN_NET` — локальная сеть.
• `SRV_MAIN` — внутренний сервер, для которого публикуются сервисы в Интернет.
• `TEST_NET` — тестовые сети, используемые при лабораторных экспериментах и маршрутизации.

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

/ip firewall address-list
add address=195.0.1.3 comment="External management" list=admin
add address=195.0.1.3 comment="Forwarding ports on server" list=SRV_MAIN
add address=195.0.1.0/24 comment="Internal Net" list=LAN_NET
add address=10.0.0.0/8 comment="Networks For Test" list=TEST_NET

Такой подход избавляет от необходимости многократно повторять IP-адреса в правилах Firewall.

Цепочка Input
Цепочка `input` отвечает за доступ не к транзитному трафику, а непосредственно к самому маршрутизатору. Сначала обрабатываются уже установленные соединения (`established`, `related`), затем отбрасываются некорректные (`invalid`). Для новых соединений с WAN используется отдельная цепочка `WAN_INPUT_ALLOW`, где разрешаются только:

• SSH;
• WinBox;
• ICMP;
• WireGuard.

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

/ip firewall filter
add action=accept chain=input comment="Allow WG only from route64" dst-port=13830 in-interface-list=WAN_IF protocol=udp
add action=jump chain=input comment="WAN EST/REL" connection-state=established,related in-interface-list=WAN_IF jump-target=WAN_INPUT
add action=jump chain=input comment="WAN NEW" connection-state=new in-interface-list=WAN_IF jump-target=WAN_INPUT_ALLOW
add action=drop chain=input comment="Drop invalid input" connection-state=invalid
add action=accept chain=input comment="Allow LAN -> Router" in-interface-list=LAN_IF
add action=drop chain=input comment="Drop all WAN input" in-interface-list=WAN_IF
add action=accept chain=WAN_INPUT connection-state=established,related
add action=drop chain=WAN_INPUT connection-state=invalid
add action=return chain=WAN_INPUT
add action=accept chain=WAN_INPUT_ALLOW comment="Admin access" dst-port=22,8291 protocol=tcp src-address-list=admin
add action=add-src-to-address-list address-list="dns flood" address-list-timeout=1h chain=WAN_INPUT_ALLOW \
    connection-state=new dst-port=53 protocol=udp src-address-list=!LAN_NET
add action=drop chain=WAN_INPUT_ALLOW dst-port=53 protocol=udp src-address-list="dns flood"
add action=accept chain=WAN_INPUT_ALLOW comment="ICMP limit" connection-rate=0-128k packet-size=0-128 protocol=icmp
add action=drop chain=WAN_INPUT_ALLOW comment="Drop all other WAN NEW"


Все остальные попытки подключения со стороны Интернета блокируются.

Цепочка Forward
Цепочка `forward` отвечает за прохождение трафика через маршрутизатор.
В первую очередь пропускаются уже существующие соединения (`established`, `related`), после чего новые подключения передаются в `FWD_ALLOW`.

Разрешены:

• доступ локальной сети в Интернет;
• опубликованные сервисы внутреннего сервера (`SRV_MAIN`);
• обмен трафиком между лабораторными сетями (`TEST_NET`).

Любой другой новый транзитный трафик отбрасывается.

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

/ip firewall filter
add action=jump chain=forward comment="FWD -> EST/REL" connection-state=established,related jump-target=FWD
add action=drop chain=forward comment="Drop invalid forward" connection-state=invalid
add action=jump chain=forward comment="FWD -> NEW" connection-state=new jump-target=FWD_ALLOW
add action=drop chain=forward comment="Drop everything else forward"
add action=accept chain=FWD comment="Accept EST/REL" connection-state=established,related
add action=return chain=FWD
add action=accept chain=FWD_ALLOW comment="ALLOW LAN -> WAN baseline" in-interface-list=LAN_IF out-interface-list=\
    WAN_IF
add action=accept chain=FWD_ALLOW comment="ALLOW TCP -> SRV_MAIN" dst-address-list=SRV_MAIN dst-port=\
    80,443,4662-6265,8999 in-interface-list=WAN_IF out-interface-list=LAN_IF protocol=tcp
add action=accept chain=FWD_ALLOW comment="ALLOW UDP -> SRV_MAIN" dst-address-list=SRV_MAIN dst-port=\
    4662-4665,4672,8999,41641 in-interface-list=WAN_IF out-interface-list=LAN_IF protocol=udp
add action=accept chain=FWD_ALLOW comment="ALLOW LAN -> TEST_LAN" dst-address-list=TEST_NET src-address-list=LAN_NET
add action=accept chain=FWD_ALLOW comment="ALLOW TEST_LAN -> LAN\
    \n" dst-address-list=LAN_NET src-address-list=TEST_NET
add action=drop chain=FWD_ALLOW comment="Drop all other NEW forward"
add action=return chain=FWD_ALLOW

NAT
Для IPv4 используется статический `src-nat`, поскольку провайдер предоставляет постоянный публичный IPv4-адрес.
Публикация внутренних сервисов выполняется посредством `dst-nat`, что позволяет сделать доступными из Интернета только заранее определённые TCP- и UDP-порты.

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

/ip firewall nat
add action=src-nat chain=srcnat out-interface-list=WAN_IF src-address-list=LAN_NET to-addresses=213.141.132.190
add action=dst-nat chain=dstnat comment="DNAT TCP -> SRV_MAIN" dst-port=80,443,4662-4665,8999 in-interface-list=\
    WAN_IF protocol=tcp to-addresses=195.0.1.3
add action=dst-nat chain=dstnat comment="DNAT UDP -> SRV_MAIN" dst-port=4662-4665,4672,8999,41641 in-interface-list=\
    WAN_IF protocol=udp to-addresses=195.0.1.3

Service Helpers
Неиспользуемые встроенные помощники протоколов (`SIP`, `H323`, `PPTP`, `TFTP`) отключены.

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

/ip firewall service-port
set tftp disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes

Это уменьшает количество автоматически создаваемых соединений и делает работу Firewall более предсказуемой.

[ROOT]

 Firewall IPv6 
Несмотря на отсутствие NAT, логика фильтрации IPv6 практически полностью повторяет IPv4. Это позволяет использовать единый подход к сопровождению обеих стеков и не запоминать две разные модели работы.

Address Lists
Используются следующие списки:

• `admin` — адреса, которым разрешено администрирование маршрутизатора;
• `LAN_NET` — локальная сеть;
• `SRV_MAIN6` — внутренний сервер с опубликованными сервисами;
• `TEST_NETs` — тестовые сети внутри делегированного префикса `/56`.

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

/ipv6 firewall address-list
add address=2a11:6c7:1202:6200::/64 comment="Internal Net" list=LAN_NET
add address=2a11:6c7:1202:6200::254/128 comment="Internal IP for Router" list=LAN_IP
add address=2a11:6c7:1202:6200::3/128 comment="External management" list=admin
add address=2a11:6c7:1202:6200::3/128 comment="Forwarding ports on server" list=SRV_MAIN6
add address=2a11:6c7:1202:6200::/56 comment="Networks For Test" list=TEST_NETs

Цепочка Input
Как и в IPv4, сначала обрабатываются существующие соединения (`established`, `related`), затем отбрасываются `invalid`.
Для новых соединений из внешней сети используется отдельная цепочка `WAN_INPUT_ALLOW6`, где разрешены:

• SSH;
• WinBox;
• ICMPv6.

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

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

/ipv6 firewall filter
add action=jump chain=input comment="INPUT -> EST/REL" connection-state=established,related jump-target=WAN_INPUT6
add action=drop chain=input comment="Drop invalid input" connection-state=invalid
add action=jump chain=input comment="INPUT -> NEW" connection-state=new in-interface-list=WAN_IF jump-target=WAN_INPUT_ALLOW6
add action=accept chain=input comment="Allow LAN -> Router" in-interface=bridge1
add action=drop chain=input comment="Drop all WAN input" in-interface=wg-ipv6
add action=accept chain=WAN_INPUT6 comment="Accept EST/REL" connection-state=established,related
add action=drop chain=WAN_INPUT6 comment="Drop invalid" connection-state=invalid
add action=return chain=WAN_INPUT6
add action=accept chain=WAN_INPUT_ALLOW6 comment="Admin access" dst-port=22,8291 protocol=tcp src-address-list=admin
add action=add-src-to-address-list address-list="dns flood" address-list-timeout=1h chain=WAN_INPUT_ALLOW6 \
    connection-state=new dst-port=53 protocol=udp src-address-list=!LAN_NET
add action=drop chain=WAN_INPUT_ALLOW6 dst-port=53 protocol=udp src-address-list="dns flood"
add action=accept chain=WAN_INPUT_ALLOW6 comment="ICMP ALLOW" protocol=icmpv6
add action=drop chain=WAN_INPUT_ALLOW6 comment="Drop all other WAN NEW"

Цепочка Forward
Транзитный трафик организован по той же схеме.
Разрешены:

• выход локальной сети в Интернет через WireGuard;
• публикация сервисов внутреннего сервера (`SRV_MAIN6`);
• маршрутизация между сетями внутри делегированного префикса `/56`.

Любой другой новый транзитный трафик блокируется.

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

/ipv6 firewall filter
add action=jump chain=forward comment="FWD -> EST/REL" connection-state=established,related jump-target=FWD6
add action=drop chain=forward comment="Drop invalid forward" connection-state=invalid
add action=jump chain=forward comment="FWD -> NEW" connection-state=new jump-target=FWD_ALLOW6
add action=drop chain=forward comment="Drop everything else forward"
add action=accept chain=FWD6 comment="Accept EST/REL" connection-state=established,related
add action=return chain=FWD6
add action=accept chain=FWD_ALLOW6 comment="ALLOW LAN -> WAN baseline" in-interface=bridge1 out-interface=wg-ipv6
add action=accept chain=FWD_ALLOW6 comment="ALLOW TCP -> SRV_MAIN" dst-address-list=SRV_MAIN6 dst-port=\
    80,443,4662-6265,8999 in-interface=wg-ipv6 out-interface=bridge1 protocol=tcp
add action=accept chain=FWD_ALLOW6 comment="ALLOW UDP -> SRV_MAIN" dst-address-list=SRV_MAIN6 dst-port=\
    4662-4665,4672,8999,41641 in-interface=wg-ipv6 out-interface=bridge1 protocol=udp
add action=accept chain=FWD_ALLOW6 comment="Allow routing within delegated /56 block" dst-address-list=TEST_NETs src-address-list=TEST_NETs
add action=drop chain=FWD_ALLOW6 comment="Drop all other NEW forward"
add action=return chain=FWD_ALLOW6

Особенности IPv6
В IPv6 отсутствует NAT, поэтому маршрутизатор выполняет исключительно функции маршрутизации и фильтрации.
Для корректной работы через WireGuard дополнительно применяется изменение MSS (`change-mss`), позволяющее избежать проблем с фрагментацией TCP-пакетов при прохождении через туннель.

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

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

В результате структура IPv6 Firewall остаётся максимально близкой к IPv4, а различия сводятся лишь к особенностям самого протокола.

[ROOT]

 13. Скрипты и планировщик заданий 
Напишем не сложный скрипт на случай зависания Wireguard интерфейса.

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

:local target "2a11:6c7:f04:189::1"
:local iface "wg-ipv6"
:local count 5
:local running [/system script job print count-only where script="heal-wg-router64"]

:if ($running > 1) do={
   :log warning "WG: previous instance still running"
   :return ""
}

:delay 5s
:local replies [/ping address=$target count=$count interval=2s interface=$iface]

:if ($replies < ($count / 2)) do={
    :delay 5s
    :local secondCheck [/ping address=$target count=$count interval=1s interface=$iface]
    :if ($secondCheck < ($count / 2)) do={
        :log warning "WG: double-check failed, disabling"
        /interface wireguard disable [find where name=$iface]
        :delay 15m
        /interface wireguard enable [find where name=$iface]
        :log info ("WG: " . $iface . " raised after treatment")
    }
}

Алгоритм работы скрипта `heal-wg-router64` выглядит так:

1. Объявление переменных

• target — IPv6-адрес для проверки связности
• iface — имя WireGuard-интерфейса, который нужно контролировать
• count — количество ping-запросов для проверки (5)
• running — подсчёт запущенных экземпляров этого же скрипта

2. Защита от повторного запуска
Проверяется, сколько экземпляров скрипта `heal-wg-router64` уже выполняется. Если больше одного (текущий + ещё один), выводится предупреждение в лог, и скрипт немедленно завершается через `:return ""`. Это исключает наложение нескольких процессов лечения.

3. Первичная пауза
Выдерживается пауза 5 секунд — даёт время на возможное завершение предыдущих операций с интерфейсом.

4. Первый цикл проверки (ping)
Отправляется `$count` (5) ping-запросов на `$target` через интерфейс `$iface` с интервалом 2 секунды между запросами. Результат (количество успешных ответов) сохраняется в `replies`.

5. Оценка результата (первый порог)
Если количество успешных ответов меньше половины от `$count` (т.е. < 2.5, фактически 0, 1 или 2 из 5), связь считается подозрительной — переход ко второму этапу проверки.

6. Второй цикл проверки (double-check)

• Выдерживается ещё 5 секунд
• Повторный ping: 5 запросов с интервалом 1 секунда
• Результат сохраняется в `secondCheck`

7. Оценка второго результата и лечение
Если второй результат тоже меньше половины (0, 1 или 2 из 5), значит связь действительно потеряна:

• Запись в лог: `"WG: double-check failed, disabling"`
• Отключение WireGuard-интерфейса `wg-ipv6`
• Пауза 15 минут — даёт время удалённой стороне «забыть» старую сессию
• Включение интерфейса обратно
• Запись в лог: `"WG: wg-ipv6 raised after treatment"`

Если же второй ping показал хороший результат (≥ 3 из 5), первое ухудшение считается ложным срабатыванием — лечение не производится, скрипт молча завершается.

Логика в целом
Двойная проверка с разными интервалами и обязательная пауза в 15 минут между disable/enable страхуют от:

• ложных срабатываний при кратковременных сетевых флуктуациях
• частых переподключений, которые могли бы усугубить проблему

Добавляем скрипт в планировщик заданий с регулярностью запуска раз в пять минут

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

/system scheduler
add interval=5m name=watchdog-wg on-event="/system/script/run heal-wg-router64" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup