WireGuard на MikroTik RouterOS (CHR) — это лёгкий и быстрый способ поднять VPN-шлюз/exit-node прямо на виртуальном роутере. Однако у CHR есть важный нюанс: лицензионные ограничения по скорости (Free — до ~1 Мбит/с на интерфейс), о которых обязательно нужно помнить при планировании нагрузки.
В этой статье разберём:
какую роль играет лицензия CHR в скорости WireGuard;
базовую схему «MikroTik CHR как VPN-роутер + exit-node»;
команды RouterOS CLI с пояснениями;
пример клиентского конфига WireGuard;
проверку и отладку производительности.
Статья ориентирована на администраторов, уже знакомых с базовыми концепциями IP-сетей и MikroTik (WinBox/WebFig/CLI).
Лицензирование MikroTik CHR и влияние на скорость WireGuard
Для облачных/виртуальных сред MikroTik предлагает Cloud Hosted Router (CHR). У него есть несколько уровней лицензий:
CHR Free — бесплатная лицензия, ограничение ~1 Мбит/с на каждый интерфейс (tx/rx). Подходит только для тестов или очень низкой нагрузки.
CHR P1 — до 1 Гбит/с.
CHR P10 — до 10 Гбит/с.
CHR P-Unlimited — без ограничений скорости.
Проверка текущей лицензии
/system license print
Что важно в выводе:
nlevel=free— это CHR Free (лимит 1 Мбит/с).nlevel=p1/p10/p-unlimited— лицензии с повышенными лимитами.
Вывод: если WireGuard «упирается» в 0.7–0.9 Мбит/с при корректных настройках NAT/маршрутизации, первым делом смотрим на nlevel. На CHR Free это ожидаемое поведение.
Обновление/активация лицензии
Общий алгоритм:
Регистрируем учётку на сайте MikroTik.
На CHR:
/system license print /system license renewRouterOS запросит логин/пароль от аккаунта MikroTik.
В личном кабинете MikroTik привязываем/покупаем нужную лицензию (например, P1).
На CHR снова:
/system license renew
5. После этого nlevel меняется, и лимит скорости увеличивается в соответствии с лицензией.
Базовая схема WireGuard на CHR
Классическая схема для CHR как VPN-роутера/exit-node:
WAN-интерфейс (например,
ether1) — получает публичный IP от провайдера/облака.WireGuard-интерфейс
wg1— внутренняя подсеть для VPN-клиентов, например10.0.88.0/24.NAT (masquerade) — исходящий трафик клиентов через
ether1.Firewall / mangle — при необходимости:
разрешение форвардинга wg1 ↔ ether1,
MSS clamping для избежания проблем с MTU.
Далее — всё в CLI для RouterOS v7 (где WireGuard встроен).
Настройка WireGuard на MikroTik CHR через CLI
Создание WireGuard-интерфейса
/interface wireguard
add name=wg1 listen-port=13231 comment="wg-iface"
Что делает команда:
создаёт интерфейс WireGuard с именем
wg1;listen-port=13231— порт, на котором CHR будет ждать входящие WG-подключения;comment— произвольная подпись для удобства.
Проверить результат:
/interface wireguard print detail
После создания RouterOS сам сгенерирует ключи (public/private). При необходимости можно задать private-key вручную.
Назначение IP-адреса на wg1
Предположим, что подсеть для VPN-клиентов — 10.0.88.0/24, а шлюзом будет сам CHR: 10.0.88.1.
/ip address
add address=10.0.88.1/24 interface=wg1 comment="wg-ip"
Что делает:
назначает IP
10.0.88.1интерфейсуwg1;задаёт маску
/24(от10.0.88.1до10.0.88.254под клиентов);позволяет CHR маршрутизировать трафик между этой подсетью и WAN.
Проверка:
/ip address print detail where interface~"wg"
Настройка peer (клиента WireGuard)
Сначала на CHR нужно знать public-key клиента. Его можно получить, сгенерировав пару ключей на стороне клиента (Linux/wg, Windows, Android и т.д.).
Пример добавления клиента с адресом 10.0.88.3/32:
/interface wireguard peers
add interface=wg1 name="client1" \
public-key="<PUBLIC_KEY_CLIENT>" \
allowed-address=10.0.88.3/32 \
persistent-keepalive=25s
Разбор параметров:
interface=wg1— привязка peer’а к нашему wg-интерфейсу;name="client1"— удобное имя peer’а;public-key— публичный ключ клиента;allowed-address=10.0.88.3/32— IP, который клиент будет использовать внутри туннеля;persistent-keepalive=25s— периодический keepalive, полезен при NAT.
Проверка:
/interface wireguard peers print detail
Важно:
На стороне CHR мы не прописываемallowed-address=0.0.0.0/0для клиента, чтобы не ломать таблицу маршрутизации самого роутера. Full-tunnel достигается настройкой на клиенте.
NAT (masquerade) для подсети WireGuard
Чтобы клиенты из 10.0.88.0/24 выходили в интернет через ether1, добавляем правила srcnat:
/ip firewall nat
add chain=srcnat src-address=10.0.88.0/24 out-interface=ether1 action=masquerade comment="WG->WAN masquerade"
Что делает:
берёт трафик от клиентов с адресом
10.0.88.0/24;подменяет исходный IP на IP интерфейса
ether1(masquerade);позволяет клиентам выглядеть как сам CHR снаружи.
Проверка:
/ip firewall nat print detail where chain=srcnat
Firewall и форвардинг
Если firewall на CHR включён и используются правила drop в цепочке forward, нужно явно разрешить трафик между wg1 и ether1.
Простейший вариант:
/ip firewall filter
add chain=forward in-interface=wg1 out-interface=ether1 action=accept comment="Allow WG->WAN"
add chain=forward in-interface=ether1 out-interface=wg1 action=accept comment="Allow WAN->WG (established/related)"
Часто также добавляют более строгие правила с использованием connection-state=established,related, но конкретная политика зависит от вашей общей схемы безопасности.
MSS clamping (решение проблем с MTU и низкой скоростью)
Виртуальные среды + VPN часто страдают от неправильного MTU, что приводит к фрагментации или сбросу пакетов, и в итоге — к «тормозам» TCP-соединений. На Mikrotik это решается правилом mangle с change-mss.
/ip firewall mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu \
passthrough=yes protocol=tcp tcp-flags=syn out-interface=wg1 \
comment="Clamp MSS for WG"
Что делает:
перехватывает TCP SYN-пакеты, выходящие через
wg1;автоматически подстраивает MSS под фактический путь (Path MTU);
помогает избежать проблем с «зависанием» или сильным падением скорости на больших пакетах.
Проверка:
/ip firewall mangle print detail where chain=forward
Пример клиентского конфига WireGuard (full-tunnel)
Допустим, CHR имеет публичный IP 203.0.113.10, wg1 слушает 13231, а клиенту мы назначили 10.0.88.3/32.
Конфиг клиента (Windows/Linux/macOS/Android)
[Interface]
PrivateKey = <PRIVATE_KEY_CLIENT>
Address = 10.0.88.3/32
DNS = 1.1.1.1, 8.8.8.8
MTU = 1320
[Peer]
PublicKey = <PUBLIC_KEY_CHR>
Endpoint = 203.0.113.10:13231
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
Ключевые моменты:
AllowedIPs = 0.0.0.0/0, ::/0— это делает full-tunnel: весь IPv4/IPv6-трафик клиента идёт через VPN.MTU = 1320— часто оптимальное значение для туннеля через виртуализацию; при проблемах со скоростью стоит поэкспериментировать.В клиентских приложениях обычно есть опции:
“Block untunneled traffic / Kill switch”;
“Route all traffic through VPN”.
Для строгого exit-node важно включить эти опции на стороне клиента — сервер не может заставить клиент не использовать локальный интернет, это задача его ОС/файрвола.
Тестирование и диагностика скорости
После базовой настройки CHR и клиента стоит проверить:
Маршрутизацию и IP:
с клиента зайти на любой сервис «what is my IP»;
IP должен совпадать с публичным IP CHR.
Скорость:
выполнить speedtest с клиента при включённом WireGuard;
сравнить со speedtest без VPN.
На стороне CHR:
/interface wireguard peers print detailОбратить внимание на поля:
rx/tx— растут ли счётчики трафика;last-handshake— актуален ли рукопожатие.
Проверить лицензию:
Если при идеальной конфигурации скорость стабильно около 0.7–0.9 Мбит/с, почти всегда причина — CHR Free:
/system license print
Если nlevel=free, то для 100–200 Мбит/с и выше понадобится минимум CHR P1.
Резюме
WireGuard на MikroTik CHR настраивается довольно просто:
создать интерфейс
wg1и назначить адрес;добавить peers с их
public-keyиallowed-address;настроить NAT (masquerade) для подсети WG на WAN;
при необходимости — firewall и MSS clamping.
Full-tunnel/exit-node реализуется за счёт:
AllowedIPs = 0.0.0.0/0на стороне клиента;kill-switch/route-all-traffic в VPN-клиенте.
Производительность WireGuard на CHR напрямую зависит от:
лицензии (Free vs P1/P10/P-Unlimited);
мощности CPU и виртуализационной платформы;
корректной настройки MTU/MSS.
Если при корректном конфиге VPN упирается в ~1 Мбит/с — первым делом нужно проверить
/system license printи убедиться, не работает ли CHR в режиме Free.
Такой подход позволяет строить как тестовые стенды, так и полноценные производительные VPN-узлы на базе MikroTik CHR, при этом понимая, где заканчивается конфигурация админа и начинаются ограничения лицензий и инфраструктуры.