WireGuard-клиент на MikroTik с RouterOS 7: полный туннель, выборочная маршрутизация и проверка

MAATRIX · Обновлено 24 октября 2026

Если на MikroTik работает WireGuard-клиент, устройства домашней сети выходят в интернет через ваш VPN-сервер, и ставить приложение на каждое из них не нужно. В статье описан порядок настройки на RouterOS 7: перенос конфигурации, интерфейс и peer, NAT и firewall, затем один из двух вариантов маршрутизации. В конце проверяются внешний IP, DNS, IPv6 и поведение сети при обрыве туннеля.

Подготовьте роутер и конфигурацию сервера

WireGuard встроен в RouterOS начиная с ветки 7. В ветке 6 его нет, и отдельным пакетом его не добавить. Версию можно посмотреть в System → Resources или командой /system resource print. В окне System → RouterBOARD отображается версия загрузчика RouterBOOT. Это другой номер, не путайте его с версией RouterOS.

Если на роутере ветка 6, сначала сохраните backup и текстовый экспорт конфигурации на компьютер. Переход выполняется так: обновление в пределах ветки 6, затем канал Upgrade до предложенной версии 7, затем стабильный выпуск 7. Канал Stable внутри ветки 6 на седьмую версию не переводит. Порядок действий описан в документации MikroTik: обновление и установка и переход на v7. Удалённый роутер, к которому у вас нет запасного доступа, лучше не обновлять.

Нужен также работающий WireGuard-сервер. На VPS MAATRIX с автоматической установкой WireGuard после создания сервера в личном кабинете появляется файл .conf для первого клиента. Если сервер вы поднимаете сами, порядок описан в статье «Как установить и настроить WireGuard на VPS». Файл конфигурации выглядит примерно так (ключи здесь вымышленные, адрес взят из документационного диапазона):

[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_PLACEHOLDER
Address = 10.66.66.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY_PLACEHOLDER
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

PrivateKey — секретный ключ роутера. Его нельзя пересылать, публиковать или показывать на скриншотах. Address задаёт адрес роутера внутри VPN-сети. PublicKey в блоке Peer — открытый ключ сервера. Endpoint содержит публичный адрес и порт сервера, а AllowedIPs определяет, какие адреса считаются принадлежащими туннелю.

Один конфиг рассчитан на одного клиента. Если тот же файл одновременно используют роутер и телефон, они будут мешать друг другу. Сейчас автоустановка MAATRIX выдаёт один клиентский конфиг. Его хватает на роутер, за которым работают все домашние устройства. Второму независимому клиенту нужны отдельные ключи и отдельный peer на сервере.

Перед началом работы откройте Winbox из локальной сети и включите Safe Mode. Если связь с роутером пропадёт, изменения, сделанные в этом режиме, откатятся.

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

В актуальных выпусках RouterOS есть команда /interface/wireguard/wg-import, а параметр config-string у неё появился в 7.19. Какие поля она понимает, зависит от версии, поэтому сверяйтесь с официальной документацией по WireGuard. Ниже описан ручной способ, при котором каждое значение видно и его легко проверить.

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

/interface wireguard
add name=wg-maatrix private-key="CLIENT_PRIVATE_KEY_PLACEHOLDER" listen-port=13231

/ip address
add address=10.66.66.2/32 interface=wg-maatrix

listen-port — локальный порт самого MikroTik. С портом сервера он может не совпадать. Пробрасывать его на WAN для клиентского подключения обычно не нужно: роутер сам начинает соединение, а ответы сервера проходят по правилу для установленных соединений.

Затем добавьте сервер как peer. Адрес и порт берутся из Endpoint, где они разделены двоеточием:

/interface wireguard peers
add interface=wg-maatrix public-key="SERVER_PUBLIC_KEY_PLACEHOLDER" \
    endpoint-address=203.0.113.10 endpoint-port=51820 \
    allowed-address=0.0.0.0/0 persistent-keepalive=25s

Если в выданном файле есть PresharedKey, перенесите его в поле preshared-key этого peer: удалять дополнительный ключ из клиентской схемы нельзя.

Параметр persistent-keepalive раз в 25 секунд отправляет серверу короткий пакет. Без него запись о соединении в NAT провайдера может устареть, пока трафика нет, и туннель перестанет принимать входящие пакеты.

На этом этапе маршруты ещё не менялись, и интернет идёт напрямую. Это удобный момент убедиться, что связь с сервером есть:

/interface wireguard peers print detail

Поле last-handshake должно показывать недавнее время, а счётчики rx и tx должны расти оба. Если handshake не происходит, проверьте публичный ключ сервера, адрес и порт Endpoint, а также не блокирует ли исходящий UDP firewall роутера или провайдер. Когда растёт только tx, пакеты уходят, но ответа нет. Обычно причина в неверном ключе или в закрытом порту на сервере. Маршруты стоит менять только после того, как handshake стабильно обновляется.

Настройте NAT и разрешения firewall

Сервер знает адрес роутера в VPN-сети, но ничего не знает о вашей домашней подсети. Поэтому трафик LAN, уходящий в туннель, нужно маскировать. Добавьте одно правило, а не оба. Первое маскирует всё, что выходит через интерфейс:

/ip firewall nat
add chain=srcnat action=masquerade out-interface=wg-maatrix

Второе ограничивает маскировку одной подсетью. Оно подходит, если, например, гостевую сеть в туннель пускать не нужно:

/ip firewall nat
add chain=srcnat action=masquerade out-interface=wg-maatrix src-address=192.168.88.0/24

Дальше посмотрите цепочку forward:

/ip firewall filter print chain=forward

В стандартной конфигурации MikroTik новые соединения из LAN в WireGuard не попадают ни под одно правило drop, поэтому отдельное разрешение не требуется. Если же в конце вашей цепочки стоит общий запрет, правило accept должно находиться выше него. В этом случае добавьте разрешение и укажите в place-before номер первого подходящего правила drop из только что полученного вывода:

/ip firewall filter
add chain=forward action=accept in-interface-list=LAN out-interface=wg-maatrix \
    comment="LAN to WireGuard" place-before=НОМЕР_ИЗ_ВЫВОДА

Номер правила берите из свежего вывода print в той же сессии, после любых изменений он может сдвинуться. Не меняйте правила через [find ...] по примеру из интернета, если не уверены, что условие выберет ровно одно нужное правило. Разрешать входящие новые соединения из туннеля в LAN для этой схемы не нужно. Защитные правила, которые отбрасывают invalid-пакеты и трафик с WAN, оставьте на месте.

Дальше нужно выбрать один из двух вариантов. Полный туннель отправляет через VPN весь IPv4-трафик роутера и сети. Выборочная маршрутизация отправляет туда только трафик отдельных устройств. Смешивать их не нужно: у каждого свои маршруты и свои ловушки.

Вариант 1: весь IPv4-трафик через туннель

Сохраните маршрут до сервера через WAN

Если отправить в туннель весь интернет, роутер начнёт посылать в туннель и пакеты самого WireGuard, адресованные серверу, и соединение оборвётся. Поэтому сначала создаётся отдельный маршрут к Endpoint через провайдера. Узнайте текущий шлюз:

/ip route print detail where dst-address=0.0.0.0/0

Затем добавьте маршрут /32. В примере 203.0.113.10 — адрес-заглушка, вместо него нужен реальный IPv4 из Endpoint. 198.51.100.1 тоже заглушка, вместо неё укажите шлюз провайдера из вывода выше:

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

Если подключение идёт через PPPoE, шлюзом обычно служит имя PPPoE-интерфейса, например pppoe-out1. Когда WAN получает адрес по DHCP, шлюз может смениться, а статический маршрут останется со старым значением. В таком случае маршрут нужно обновлять вместе с WAN, поэтому пример нельзя просто скопировать. Убедитесь, что маршрут активен и handshake продолжает обновляться.

Добавьте маршруты в туннель

Из локальной сети, с включённым Safe Mode, добавьте два маршрута:

/ip route
add dst-address=0.0.0.0/1 gateway=wg-maatrix comment="VPN IPv4 lower half"
add dst-address=128.0.0.0/1 gateway=wg-maatrix comment="VPN IPv4 upper half"

Вместе две половины покрывают весь IPv4-интернет. Маршрут с более длинным префиксом выигрывает, поэтому они получают приоритет над обычным 0.0.0.0/0 провайдера, и его не приходится удалять или менять ему distance. Путь к серверу через WAN эти маршруты не сохраняют, это делает только отдельный /32 из предыдущего шага. Если в сети уже есть routing rules или mangle-правила с mark-routing, они могут направить часть трафика в другую таблицу. Просмотрите их до применения.

Если после добавления маршрутов пропал интернет, сначала проверьте маршрут /32 до Endpoint. Откатиться можно, отменив изменения Safe Mode сочетанием Ctrl+D в терминале (повторное Ctrl+X, наоборот, сохраняет изменения) или удалив маршруты по их комментариям.

Вариант 2: в туннель идут только выбранные устройства

Здесь основной маршрут через провайдера не трогается. Отдельно создаются таблица с маршрутом через WireGuard и правило, которое отправляет в неё трафик нужных адресов. Endpoint и так доступен через основную таблицу, поэтому отдельный /32 в этом варианте не нужен. Адреса в примере условные, подставьте реальные адреса своих устройств:

/routing table
add name=via-vpn fib

/ip firewall address-list
add list=via-vpn address=192.168.88.50
add list=via-vpn address=192.168.88.51

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

Перед маркировкой перечислите в списке local-subnets все свои локальные подсети: основную LAN, гостевую сеть и VLAN. Иначе обращения к другой локальной сети могут уйти в туннель. Для одной LAN пример выглядит так:

/ip firewall address-list add list=local-subnets address=192.168.88.0/24

Затем пометьте соединения этих устройств и назначьте их пакетам таблицу:

/ip firewall mangle
add chain=prerouting action=mark-connection new-connection-mark=via-vpn \
    src-address-list=via-vpn dst-address-type=!local dst-address-list=!local-subnets connection-state=new passthrough=yes
add chain=prerouting action=mark-routing new-routing-mark=via-vpn \
    connection-mark=via-vpn in-interface-list=LAN passthrough=no

Обязательно разберитесь с FastTrack. Соединения, которые попали в FastTrack, обходят mangle, и часть пакетов уйдёт мимо туннеля. Найдите действующее правило:

/ip firewall filter print where action=fasttrack-connection

Выше него поставьте правило accept для помеченных соединений. Метка соединения относится к обоим направлениям, поэтому FastTrack не подхватит ни исходящие пакеты, ни ответы:

/ip firewall filter
add chain=forward action=accept connection-state=established,related connection-mark=via-vpn \
    comment="Exclude VPN policy routing from FastTrack" place-before=НОМЕР_ИЗ_ВЫВОДА

Если в вашей конфигурации исключение сделано по спискам адресов, условие должно срабатывать в обе стороны: и по src-address-list, и по dst-address-list. Учтите, что соединения, уже попавшие в FastTrack, останутся там до своего завершения. Кроме того, трафик без FastTrack сильнее нагружает процессор роутера.

Отдельно продумайте, что произойдёт, если туннель не работает. Некоторые администраторы добавляют в таблицу via-vpn blackhole-маршрут с большим distance, чтобы трафик этих устройств не уходил напрямую. Синтаксис зависит от версии RouterOS, поэтому сверяйтесь с документацией и обязательно проверяйте поведение тестом обрыва, описанным ниже. Как пакет проходит через mangle, маршрутизацию и FastTrack, показано в разделе Packet Flow in RouterOS.

Настройте DNS и IPv6 отдельно

Устройства, которые получают DNS от роутера, используют серверы из /ip dns. Если DNS провайдера через туннель недоступны, сохраните текущие настройки и задайте публичные резолверы:

/ip dns set servers=1.1.1.1,1.0.0.1

Это изменит DNS только самого роутера. В варианте выборочной маршрутизации его собственные DNS-запросы по-прежнему идут через основную таблицу, то есть обычно через провайдера. Если DNS должен идти строго через VPN, выбранным устройствам нужен резолвер, доступный по их VPN-маршруту, либо отдельная проверенная маршрутизация запросов роутера. На устройствах может быть настроен собственный DNS или DoH, и такие настройки проверяются на самих устройствах. Если роутер отвечает на DNS-запросы клиентов, доступ к этой службе должен оставаться открытым только для LAN. Открывать DNS на WAN нельзя.

Ручная схема из этой статьи настраивает только IPv4. Если провайдер выдаёт IPv6, устройства будут ходить по нему напрямую, мимо туннеля. Есть два варианта: отключить раздачу IPv6 в LAN для устройств, которые должны работать через VPN, или настроить IPv6 через туннель целиком, с адресами, маршрутами и firewall. Второй вариант возможен, только если сервер поддерживает IPv6.

Если сайты загружаются частично

Когда handshake есть, мелкие страницы открываются, а крупные зависают, причина может быть в MTU. Начните со значения из выданного конфига, у MAATRIX сейчас это 1380. Для проверки попробуйте 1280, указав интерфейс по точному имени:

/interface wireguard set [find where name="wg-maatrix"] mtu=1280

Сравните загрузку тех же сайтов. Значение 1240 подходит только для диагностики IPv4-туннеля: для IPv6 MTU не может быть меньше 1280 по RFC 8200. Если улучшения нет, верните исходное значение и ищите причину в DNS, firewall, маршрутах или ограничениях UDP.

Проверьте результат и поведение при обрыве

Начните с туннеля: last-handshake обновляется, rx и tx растут вместе. Потом откройте 2ip.ru или whoer.net с устройства, которое должно работать через VPN. Сайт должен показать адрес сервера. В варианте 2 откройте его же с устройства, не входящего в список: там должен остаться адрес провайдера.

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

Для IPv6 проверьте, есть ли у устройства IPv6-адрес и какой внешний IPv6 видят тестовые сайты. Если IPv6 работает напрямую через провайдера, этот трафик идёт в обход туннеля.

Обрыв проверяется так: временно отключите peer командой disable в /interface wireguard peers, затем откройте сайт, который ещё не загружался на этом устройстве, или выполните новый запрос. Обновить уже открытую вкладку недостаточно, браузер может показать страницу из кеша. Посмотрите, пропадает ли доступ или трафик уходит через провайдера, и оцените, допустимо ли это для вашей задачи. Схема с маршрутами /1 сама по себе не является гарантированным kill switch, и её поведение при отказе нужно проверить на своём роутере. После теста включите peer обратно и дождитесь нового handshake.

Если вы ещё выбираете устройство или настраиваете VPN на роутере другой марки, пригодится обзор «Какой роутер выбрать для WireGuard VPN».