Как настроить WireGuard на MikroTik (RouterOS 7)

Что нужно перед началом

MikroTik выбирают не за простоту, а за контроль: здесь можно с точностью до устройства решить, чей трафик уходит в шифрованный туннель, а чей — напрямую, и описать это правилами, которые переживут перезагрузку и смену провайдера. WireGuard в RouterOS реализован в ядре, поэтому нагружает процессор заметно меньше, чем OpenVPN или IKEv2, и спокойно живёт на устройствах уровня hAP ac², hEX и RB5009.

WireGuard в MikroTik работает только на RouterOS 7 и новее: на ветке 6.x такого интерфейса просто нет, и никакими пакетами он не добавляется. Поэтому первый шаг — обновление. Посмотрите текущую версию в System → Resources (или командой /system/resource/print) и при необходимости обновитесь через System → Packages. Если роутер идёт с ветки 6.x, сначала обновите RouterOS до последней 6-й версии, затем переключите канал обновлений на стабильную 7-ю и обновите ещё раз, а следом обновите и загрузчик — /system/routerboard/upgrade.

Второе, что понадобится, — конфигурационный файл .conf. В отличие от Keenetic или ASUS, RouterOS не умеет импортировать его целиком: значения из файла переносятся в команды руками. Ничего сложного тут нет, в конфиге всего шесть строк, которые нам интересны:

• PrivateKey из секции [Interface] — приватный ключ вашего роутера.
• Address из секции [Interface] — адрес роутера внутри туннеля.
• DNS из секции [Interface] — сервер имён, который стоит прописать роутеру.
• PublicKey из секции [Peer] — публичный ключ сервера.
• Endpoint из секции [Peer] — адрес и UDP-порт сервера через двоеточие.
• AllowedIPs из секции [Peer] — какие сети отправлять в туннель.

Что означает каждая строка, подробно разобрано в материале разбор конфига WireGuard. Конфиг для роутера выпускайте отдельный: одна пара ключей должна работать на одном устройстве, иначе сервер будет видеть два источника с одним ключом и рвать соединение обоим. В Muhomor VPN на доступе выпускается до пяти конфигов, роутеру выделяется свой профиль.

Все команды ниже вводятся в терминале Winbox, в WebFig или по SSH. Если вы предпочитаете графический интерфейс, те же параметры лежат в разделе WireGuard на вкладках Interfaces и Peers.

Шаг 1. Создаём WireGuard-интерфейс и переносим ключ

По умолчанию RouterOS генерирует новую пару ключей при создании интерфейса. Нам это не нужно: сервер ждёт именно тот ключ, который выдан в конфиге, поэтому приватный ключ задаём явно.

/interface/wireguard/add name=wg-muhomor private-key="ПРИВАТНЫЙ_КЛЮЧ_ИЗ_КОНФИГА" listen-port=51820 mtu=1420

Имя интерфейса может быть любым, но лучше говорящее — оно будет встречаться в маршрутах, NAT и правилах firewall. Параметр listen-port для клиента не критичен: исходящее соединение роутер инициирует сам, порт нужен только если кто-то будет подключаться к вам. Значение mtu=1420 — штатное для WireGuard, к нему мы ещё вернёмся.

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

/interface/wireguard/print

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

Шаг 2. Назначаем интерфейсу адрес из туннеля

Интерфейс создан, но у него нет адреса. Возьмите значение из строки Address в конфиге и перенесите его ровно как есть, вместе с маской:

/ip/address/add address=10.8.0.2/32 interface=wg-muhomor

Маска /32 в конфигах WireGuard встречается чаще всего: сервер выдаёт клиенту ровно один адрес, а маршруты описываются через allowed-address, а не через подсеть. RouterOS такую запись принимает без возражений. Если в вашем конфиге указана другая маска, например /24, используйте её — подменять значения не нужно.

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

/ip/dns/set servers=10.8.0.1 allow-remote-requests=yes

Адрес подставьте свой, из строки DNS. Опция allow-remote-requests нужна, чтобы устройства локальной сети могли использовать сам роутер как DNS-сервер — тогда их запросы уйдут в туннель вместе с остальным трафиком. Раздачу этого адреса клиентам настраивают в DHCP-сервере локальной сети.

Шаг 3. Добавляем peer с endpoint и публичным ключом

Peer описывает удалённую сторону: куда подключаться и чей ключ ожидать. Для клиентского сценария команда выглядит так:

/interface/wireguard/peers/add interface=wg-muhomor public-key="ПУБЛИЧНЫЙ_КЛЮЧ_СЕРВЕРА" endpoint-address=server.example.net endpoint-port=51820 allowed-address=0.0.0.0/0 persistent-keepalive=25s

Разберём поля. public-key — это PublicKey из секции [Peer], ключ сервера, а не ваш. endpoint-address и endpoint-port — две половинки строки Endpoint, разделённые двоеточием: слева хост или IP, справа UDP-порт. allowed-address — соответствие AllowedIPs: значение 0.0.0.0/0 означает «принимать и отправлять через этот peer любой трафик», а перечень конкретных подсетей описывает профиль с раздельным туннелированием.

persistent-keepalive=25s обязателен, если роутер стоит за NAT провайдера: без периодических пакетов таблица трансляций на стороне оператора «забывает» соединение, и туннель оживает только при вашей активности. Если в конфиге есть строка PresharedKey, добавьте её как preshared-key="…" — без неё сервер соединение не примет.

Параметры и значения по умолчанию всегда можно сверить в документации RouterOS.

Шаг 4. Маршрут: как отправить трафик в туннель

Peer добавлен, рукопожатие пройдёт, но трафик сам в туннель не пойдёт — нужен маршрут. Для сценария «весь трафик через туннель» добавляем маршрут по умолчанию, указывая шлюзом сам интерфейс:

/ip/route/add dst-address=0.0.0.0/0 gateway=wg-muhomor distance=1 comment="via wireguard"

Дальше внимание: у провайдерского маршрута по умолчанию, который приходит по DHCP, дистанция тоже равна единице. Чтобы приоритет достался туннелю, отодвиньте провайдерский маршрут:

/ip/dhcp-client/set [find interface=ether1] default-route-distance=2

Теперь основной маршрут — туннель, а провайдерский становится резервным и подхватит трафик, если WireGuard окажется недоступен.

Есть подводный камень, о который спотыкаются почти все: сам WireGuard отправляет свои UDP-пакеты на endpoint по общей таблице маршрутизации. Если маршрут по умолчанию ведёт в туннель, пакеты к серверу попытаются уйти внутрь этого же туннеля и соединение замкнётся само на себя. Лечится одним статическим маршрутом до адреса сервера через провайдерский шлюз:

/ip/route/add dst-address=203.0.113.10/32 gateway=192.168.1.1 comment="wg endpoint via WAN"

Подставьте IP сервера и адрес шлюза вашего провайдера. Если endpoint задан доменным именем, узнать его адрес можно командой /resolve server.example.net.

Шаг 5. NAT и правила firewall

Устройства локальной сети имеют адреса вида 192.168.88.x, а в туннеле у роутера один-единственный адрес. Чтобы ответный трафик находил дорогу назад, исходящие пакеты нужно транслировать в адрес туннеля:

/ip/firewall/nat/add chain=srcnat out-interface=wg-muhomor action=masquerade comment="NAT to wireguard"

Важно, что out-interface — именно WireGuard-интерфейс, а не WAN-порт. Правило для провайдерского интерфейса при этом оставьте на месте: оно продолжит работать для трафика, который идёт напрямую.

Со стороны firewall клиенту не нужен проброс портов — соединение роутер инициирует сам. Достаточно, чтобы в цепочке input стояло стандартное правило, разрешающее established и related соединения, а в цепочке forward — разрешение трафика из локальной сети в туннель. В типовой конфигурации MikroTik оба правила уже есть, но если вы собирали firewall вручную, проверьте их наличие:

/ip/firewall/filter/print where chain=forward

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

Выборочная маршрутизация: mangle и routing-mark

Отправлять в туннель весь трафик нужно далеко не всегда. Гораздо практичнее схема, когда через шифрованный канал ходят только выбранные устройства или подсети, а остальные выходят напрямую с провайдерского адреса — так банковские приложения и локальные сервисы не будут каждый раз переспрашивать, точно ли это вы.

В RouterOS 7 это делается через отдельную таблицу маршрутизации и метку в mangle. Сначала создаём таблицу:

/routing/table/add name=via-wg fib

Затем собираем список устройств, которым положен туннель, и помечаем их трафик:

/ip/firewall/address-list/add list=via-wg address=192.168.88.50

/ip/firewall/mangle/add chain=prerouting src-address-list=via-wg action=mark-routing new-routing-mark=via-wg passthrough=no

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

/ip/route/add dst-address=0.0.0.0/0 gateway=wg-muhomor routing-table=via-wg

Основной маршрут при этом остаётся у провайдера, поэтому отдельный маршрут до endpoint не нужен и петли не возникает. Добавить устройство в туннель теперь — одна строка в address-list. Про сам подход и его ограничения полезно прочитать материал что такое split tunneling.

Второй путь к тому же результату — не расписывать правила на роутере, а взять профиль с раздельным туннелированием: в этом случае список сетей, которые идут напрямую, лежит в самом конфиге, в строке AllowedIPs, и обновляется на стороне сервиса. Для MikroTik это означает, что allowed-address у peer будет содержать не 0.0.0.0/0, а перечень подсетей, и никакой mangle не понадобится. Минус в том, что решение принимается по адресам назначения, а не по устройствам, — если нужно разделение именно по клиентам локальной сети, вариант с routing-mark точнее.

Проверка туннеля на MikroTik, MTU и типичные ошибки

Главный индикатор исправности — свежее рукопожатие:

/interface/wireguard/peers/print

В выводе смотрите на last-handshake: значение в пределах пары минут означает, что ключи совпали и шифрованный канал живой. Там же видны счётчики rx и tx и поле current-endpoint-address — адрес, с которого реально приходят пакеты. Пустой last-handshake означает, что обмена ключами не было ни разу.

Дальше проверьте выход в сеть с самого роутера и с клиента локальной сети, а также убедитесь, что DNS-запросы уходят через туннель — как это делается, описано в статье проверка утечек DNS и IP.

Полезная привычка — включить на интерфейсе комментарии и завести отдельное правило в логах. Тогда при разборе неполадки видно, живёт ли туннель вообще, или отвалился в конкретный момент, например при переподключении провайдера по PPPoE.

Если проблема осталась, соберите вывод /interface/wireguard/peers/print и версию RouterOS — этого обычно достаточно для быстрого разбора. Общая диагностика собрана в материале WireGuard не подключается, а поддержка Muhomor VPN отвечает в Telegram-боте @muhomorvpn_bot. Пробный доступ на 3 дня оформляется на главной странице, дальше 30 дней стоят 320 ₽ без подписок и автопродлений.