MikroTik hAP ax и hAP ac2: настройка AmneziaWG и маршрутизации

hAP ax против hAP ac2: на что рассчитывать

hAP ax построен на четырёхъядерном ARM-процессоре с частотой около 800 МГц и поддерживает Wi-Fi 6, тогда как hAP ac2 — более старая двухъядерная модель на архитектуре MIPSBE с ограниченной вычислительной мощностью. Это принципиально важно для AmneziaWG, потому что контейнеры RouterOS v7 официально поддерживаются только на устройствах с архитектурой ARM или ARM64 — то есть hAP ac2 на MIPSBE технически не может запускать Container вообще.

Владельцам hAP ac2 придётся либо использовать сторонние обходные пути с ручной сборкой userspace-бинарника через доступные пакеты, либо рассматривать переход на модель с поддержкой ARM, либо ограничиться классическим WireGuard без обфускации, который в RouterOS v7 поддерживается нативно на уровне интерфейса.

Для hAP ax контейнеризация работает штатно, но стоит учитывать ограниченный объём оперативной памяти (обычно 256-512 МБ в зависимости от ревизии) — под запуск контейнера с Go-рантаймом и обработку трафика следует резервировать запас, не забивая память другими сервисами вроде большого количества правил firewall или логирования.

Подготовка RouterOS v7 к работе с контейнерами

Прежде всего нужно обновить RouterOS до актуальной версии седьмой ветки через System → Packages → Check for Updates, поскольку поддержка Container долгое время была экспериментальной функцией и стабилизировалась только в относительно свежих релизах. После обновления в System → RouterBOARD стоит проверить, что обновлена и загрузчик-прошивка (RouterBOOT).

Далее включается сама функция контейнеров системной переменной: в терминале выполняется команда /system/device-mode/update container=yes, после чего роутер попросит подтвердить включение физической кнопкой Reset (для устройств без кнопки — специальной комбинацией через консоль) и перезагрузится. Это защитный механизм MikroTik, предотвращающий удалённое включение потенциально небезопасной функции без физического доступа к устройству.

Также потребуется настроить виртуальный сетевой интерфейс veth, через который контейнер будет обмениваться трафиком с основной системой, и подготовить отдельный диск или раздел flash-памяти, если устройству не хватает встроенного хранилища для образа контейнера — для hAP ax обычно достаточно встроенной памяти при условии, что образ AmneziaWG собран компактно.

1. 1Обновить RouterOS до последней версии ветки v7
2. 2Выполнить /system/device-mode/update container=yes и подтвердить кнопкой Reset
3. 3Дождаться перезагрузки роутера
4. 4Создать veth-интерфейс для связи контейнера с основной системой
5. 5Проверить наличие свободного места для образа контейнера в /file

Разворачивание контейнера с AmneziaWG

Образ с amneziawg-go для ARM можно собрать самостоятельно через Docker на компьютере и выгрузить как tar-архив, либо использовать готовый образ из сообщества, если он опубликован в открытом реестре. Файл образа копируется на роутер через FTP или SFTP в корень файловой системы, после чего импортируется командой /container/add с указанием интерфейса veth, файла образа и точек монтирования для конфигурации.

Конфигурационный файл awg0.conf с ключами и параметрами обфускации размещается в отдельном каталоге на флеш-памяти роутера и монтируется внутрь контейнера как volume через /container/mounts/add, чтобы при обновлении образа не приходилось пересоздавать конфигурацию заново.

После создания контейнера он запускается командой /container/start и его состояние можно проверить через /container/print — статус running говорит о том, что процесс amneziawg-go внутри контейнера успешно поднял интерфейс на основе конфигурации. Логи контейнера доступны через /log/print с фильтром по топику container, что удобно для диагностики ошибок при старте.

1. 1Собрать или скачать образ amneziawg-go под архитектуру ARM
2. 2Загрузить образ на роутер через FTP/SFTP
3. 3Создать volume-каталог с конфигурацией awg0.conf
4. 4Импортировать контейнер командой /container/add с указанием veth и volume
5. 5Запустить контейнер: /container/start [find]
6. 6Проверить логи: /log/print where topics~"container"

/interface/veth/add name=veth-awg address=172.17.0.2/24 gateway=172.17.0.1
/container/mounts/add name=awg-config src-path=/awg-config dst-path=/config
/container/add remote-image=amneziawg-arm interface=veth-awg root-dir=disk1/awg mounts=awg-config
/container/start [find]

Маркировка трафика через mangle и routing mark

После того как контейнер с AmneziaWG работает и обменивается трафиком через veth-интерфейс, нужно решить, какие пакеты домашней сети направлять в туннель. В RouterOS для этого используется классическая связка mangle-правил в /ip/firewall/mangle, которые помечают пакеты routing mark на основе исходного адреса, и таблицы маршрутизации, где для этой метки прописан маршрут по умолчанию через veth-интерфейс контейнера.

Правило mangle создаётся с action=mark-routing и указанием new-routing-mark, а условие отбора трафика — src-address-list со списком адресов устройств, которым нужен VPN, либо конкретный src-address для одного устройства. Важно выставить passthrough=no для завершающего правила, если требуется, чтобы дальнейшие правила mangle его не переобрабатывали.

Отдельный маршрут добавляется в /ip/route с параметром routing-mark, равным значению из mangle-правила, и gateway, указывающим на IP-адрес veth-интерфейса со стороны контейнера. Такая архитектура позволяет гибко включать и выключать VPN для отдельных устройств простым редактированием address-list, не трогая остальные настройки сети.

1. 1Создать address-list с IP-адресами устройств для VPN
2. 2Добавить mangle-правило с action=mark-routing и new-routing-mark=to-awg
3. 3Добавить маршрут в /ip/route с routing-mark=to-awg и gateway на veth-контейнера
4. 4Проверить прохождение трафика через /tool torch на veth-интерфейсе
5. 5При необходимости добавить исключения через отдельный address-list с action=accept

/ip/firewall/address-list add list=vpn-clients address=192.168.88.50
/ip/firewall/mangle add chain=prerouting src-address-list=vpn-clients action=mark-routing new-routing-mark=to-awg passthrough=no
/ip/route add routing-mark=to-awg gateway=172.17.0.2 dst-address=0.0.0.0/0

NAT и правила firewall для клиентов

Чтобы трафик, ушедший в туннель, корректно возвращался клиентам домашней сети, на исходящем интерфейсе (либо на самом veth, либо непосредственно внутри конфигурации AmneziaWG, если контейнер сам выполняет NAT) должно быть настроено masquerade-правило. В большинстве схем проще всего добавить правило NAT в /ip/firewall/nat с action=masquerade и out-interface, указывающим на veth или WAN-интерфейс, через который контейнер выходит наружу.

Дополнительно стоит проверить, что основной firewall роутера не блокирует трафик между локальной сетью и veth-интерфейсом контейнера — по умолчанию RouterOS использует достаточно строгие правила для интерфейсов, не входящих в список LAN, и трафик к контейнеру может потребовать отдельного разрешающего правила в chain=forward.

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

Ограничения по CPU: особенно для hAP ac2

Даже если удалось обойти отсутствие поддержки Container на hAP ac2 альтернативным способом, стоит трезво оценивать возможности процессора MT7621 — при активной обфускации AmneziaWG и одновременной маршрутизации трафика нескольких устройств скорость шифрования может упереться в потолок в районе 30-60 Мбит/с, чего может не хватать для современных тарифов на 100+ Мбит/с.

На hAP ax производительность заметно выше благодаря четырём ядрам ARM, но и здесь обфускация с параметрами Jc, Jmin, Jmax потребляет дополнительные вычислительные ресурсы по сравнению с чистым WireGuard: типичная просадка составляет 15-30% по сравнению с обычным (необфусцированным) туннелем на том же оборудовании.

Для семей с несколькими одновременно активными устройствами (потоковое видео, видеозвонки, игры) имеет смысл тестировать конкретную нагрузку через /system/resource/print во время активного использования сети и при регулярной загрузке CPU выше 80% рассматривать перераспределение устройств между VPN и прямым подключением, а не пытаться завернуть в туннель абсолютно весь домашний трафик.

Мониторинг соединения и нагрузки

Базовый мониторинг состояния контейнера выполняется командой /container/print, которая показывает статус запуска и потребление ресурсов, а также /log/print для отслеживания ошибок перезапуска. Для контроля собственно VPN-соединения можно выполнить wg show внутри контейнера через /container/shell, если оболочка внутри образа это позволяет.

Загрузку процессора удобно наблюдать в реальном времени через /system/resource/cpu/print или графики в WinBox (Tools → Graphing), которые можно настроить на сбор статистики по интерфейсам, включая veth-интерфейс контейнера. Резкие скачки нагрузки при передаче больших файлов через VPN — ожидаемое поведение, а вот постоянная нагрузка на уровне 90-100% в состоянии покоя сигнализирует о проблемах конфигурации, например, о зацикленных mangle-правилах.

Дополнительно полезно настроить оповещения через встроенный The Dude или простые скрипты RouterOS, которые проверяют доступность внешнего адреса через туннель по расписанию (например, каждые пять минут) и присылают уведомление в Telegram-бот при обрыве соединения — это особенно актуально для сценариев, где роутер работает без постоянного присмотра.

Обновления RouterOS и откат контейнера

Обновление RouterOS на роутере с активным контейнером стоит планировать заранее: перед крупными обновлениями рекомендуется останавливать контейнер командой /container/stop, чтобы избежать конфликтов при перезагрузке системы, а после успешного обновления и проверки основных функций сети — запускать его снова.

MikroTik периодически меняет детали реализации Container между минорными версиями RouterOS v7, поэтому после обновления полезно свериться с журналом изменений (changelog) на предмет упоминаний container или veth перед тем, как оставлять систему без присмотра на длительное время.

Если после обновления образа AmneziaWG контейнер отказывается стартовать, самый быстрый путь восстановления — удалить контейнер командой /container/remove и создать заново с сохранённым volume-конфигурацией, поскольку сами ключи и параметры обфускации при этом не теряются и хранятся отдельно от образа.