Установка CHR на VPS отличается от обычной переустановки одной деталью: после записи образа SSH к Ubuntu исчезает вместе с самой Ubuntu, и единственным входом на сервер остаётся консоль провайдера. Её стоит проверить до того, как трогать диск. Если RouterOS не получит правильный адрес, исправлять сеть придётся именно оттуда.
CHR, Cloud Hosted Router – это RouterOS для виртуальных машин. В примере физический MikroTik соединяет свою локальную сеть с частной сетью VPS через туннель WireGuard, обе стороны работают на RouterOS 7. Импорт диска и устройство сети у каждого провайдера свои, так что эти детали лучше выяснить заранее.
Как записать образ CHR на диск VPS?
Импортируйте официальный образ CHR через панель провайдера или запишите распакованный RAW-образ на системный диск из rescue-среды. Во втором случае прежнее содержимое диска пропадёт, и сначала нужно сохранить данные и убедитесь, что выбрали правильное устройство. Без импорта в панели и без rescue поставить CHR так не получится.
Что выяснить до переустановки
Для установки MikroTik на VPS нужна полноценная виртуальная машина. KVM подходит, контейнер с общим ядром хоста нет. Ещё понадобятся загрузка своего диска или готовый шаблон CHR, консоль, которая работает независимо от сети гостя, и способ вернуться в rescue-режим.
Для схемы из статьи хватит маленькой VM x86-64 с 1 vCPU и 1 ГиБ RAM, сам образ CHR на диске почти ничего не занимает. Сетевой адаптер лучше брать virtio-net вместо эмуляции E1000, если его поддерживают гипервизор и образ: он быстрее и меньше грузит CPU. Сколько вытянет туннель, станет понятно только на замере.
У провайдера стоит уточнить правила частной сети: можно ли назначить CHR шлюзом для другой VM и пропустит ли площадка пакеты с чужими исходными адресами. При одном интерфейсе у VPS схему с ether2 придётся перестроить.
Про лицензию тоже лучше узнать до установки. Free ограничивает исходящий трафик каждого интерфейса до 1 Мбит/с, P1 – 1 Гбит/с, P10 – 10 Гбит/с, а у P-Unlimited лицензионного предела нет, и упираться вы будете уже в канал и CPU. Платные уровни можно 60 дней попробовать бесплатно. CHR с купленной лицензией должен периодически связываться с сервером MikroTik: если срок пропущен, роутер продолжит работать, но обновления и смена пакетов станут недоступны.
Какой файл скачивать
При установке CHR MikroTik на VPS берите образ диска из раздела CHR на официальном сайте. Пакет .npk для этого не годится, он обновляет уже установленную систему. Для KVM обычно подходит RAW-образ, некоторые панели принимают qcow2 после конвертации, так что формат уточните у провайдера.
На 14 октября 2026 года в канале Stable лежит RouterOS 7.23.8, она же сейчас помечена как Long-term. Точную версию и ссылку, по которой скачан образ, запишите в журнал установки. Команды сверяйте со своим выпуском, потому что документация на сайте может уже описывать более новую версию.
Архив сначала докачайте целиком, потом распаковывайте. Контрольную сумму с сайта MikroTik, когда она опубликована, сравните со своей. Собственный SHA-256 пригодится, чтобы убедиться, что файл не испортился при переносе на сервер, но откуда он взялся, по нему не узнать.
В готовом шаблоне CHR от провайдера проверьте версию, пользователей и стартовые настройки: этот образ собирал уже не MikroTik.
Импорт через панель или запись из rescue
С импортом всё проще. Образ подключают к тестовой VM первым в порядке загрузки, перед старым пустым диском, а до первого запуска закрывают внешним firewall провайдера все входящие подключения по IPv4 и IPv6. После этого VM запускают и проверяют RouterOS через консоль.
Запись из rescue рискованнее, потому что dd перезапишет диск целиком. Данные VPS сначала сохраните где-нибудь вне этого диска. Затем найдите его в списке устройств по размеру, серийному номеру и точкам монтирования, размонтируйте его разделы, отключите swap и остановите всё, что к нему обращается. Сама rescue-среда должна работать с другого диска или из памяти.
# Только в rescue, до выбора диска для записи. lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL findmnt swapon --show /dev/REPLACE_DISK замените проверенным устройством. Писать нужно на весь диск, а не в раздел вроде /dev/vda1. sudo dd if=./chr-7.23.8.img of=/dev/REPLACE_DISK \ bs=4M conv=fsync status=progress
Потом отключите rescue в панели и загрузитесь с записанного диска. Если приглашения RouterOS нет, проверьте формат образа, режим загрузки и контроллер диска.
Какие сетевые параметры задать после первого запуска RouterOS?
Задайте адрес и маску WAN, шлюз и DNS по данным провайдера или включите DHCP-клиент, если площадка раздаёт настройки сама. Виртуальный интерфейс сопоставьте с портом в панели по MAC-адресу. Для адреса /32 или шлюза вне подсети понадобится схема маршрутизации провайдера, а консольный доступ держите открытым.
Первый вход без открытого WinBox
У свежего CHR есть пользователь admin без пароля. Войдите через консоль и сразу задайте пароль, RouterOS сама попросит это сделать. Дальше создайте отдельного администратора, проверьте вход под ним и отключите admin. Группа full даёт полные права, и учётная запись у каждого администратора должна быть своя.
До сетевых изменений сохраните вывод с версией, лицензией и списком интерфейсов, а заодно начальный экспорт. Файл экспорта потом заберите из Files по защищённому каналу:
/system resource print /system package print /system license print /interface ethernet print detail /export file=before-network
Сетевые изменения по удалённому соединению делайте небольшими шагами в Safe Mode. Режим включается сочетанием Ctrl+X в терминале, повторное Ctrl+X сохраняет изменения и выходит из него. Если сессия оборвётся, RouterOS откатит всё, что сделано в этом режиме. От перезагрузки и восстановления backup Safe Mode не страхует, и на крупный импорт конфигурации тоже лучше не полагаться.
Новый вход проверяйте отдельным подключением с разрешённого адреса. Уже открытая сессия может пережить ошибочное правило firewall, потому что её пакеты проходят как established. Пока вход не защищён и не проверен, думать о том, как подключить роутер к VPS, рано.
Адреса и маршруты для двух сетей
После установки RouterOS на VPS интерфейсы придётся заново сопоставить с панелью по MAC-адресам, настройки Linux сюда не переносятся. В примере ether1 смотрит в интернет, ether2 подключён к отдельной частной сети. Адреса 203.0.113.0/24 и 198.51.100.0/24 зарезервированы для документации, подставьте свои.
Участок | CHR | Физический MikroTik |
WAN | 203.0.113.10/24, шлюз 203.0.113.1 | Действующее подключение к интернету |
WireGuard | 10.77.0.1/30 | 10.77.0.2/30 |
Локальная сеть | ether2: 10.20.0.1/24 | LAN: 192.168.50.1/24 |
Удалённая сеть | 192.168.50.0/24 через wg-site | 10.20.0.0/24 через wg-site |
Статическая схема на новом CHR выглядит так:
/ip address add address=203.0.113.10/24 interface=ether1 /ip address add address=10.20.0.1/24 interface=ether2 /ip route add dst-address=0.0.0.0/0 gateway=203.0.113.1 /ip dns set servers=1.1.1.1 allow-remote-requests=no /ip route print detai
В таблице маршрутов должны быть обе подключённые подсети и активный маршрут по умолчанию с достижимым шлюзом. При DHCP берите выданные настройки и не добавляйте поверх второй маршрут из примера. Шлюз вне подсети заменой маски на /24 наугад не исправить, для него нужна схема провайдера.
Связь удобно проверять по порядку: шлюз, любой внешний IP, доменное имя. Если IP отвечает, а имя нет, дело в DNS. Резолвер в этой схеме обслуживает только сам роутер, клиентам сети он ответы не раздаёт.
Что пропускать к роутеру и через него
В firewall цепочка input отвечает за обращения к самому CHR, а forward за пакеты, которые идут через него между сетями. Разрешив WinBox в input, вы открыли доступ к роутеру, а путь к серверу за ether2 по-прежнему закрыт.
Ниже начальные правила input для IPv4 на новом CHR, где других правил ещё нет. Вместо 198.51.100.20 подставьте свой внешний адрес администратора. Для WAN с DHCP разрешите ответы DHCP-клиенту до завершающего drop. На уже настроенном роутере блок нельзя просто дописать в конец, порядок правил меняет результат.
/ip firewall filter add chain=input action=accept connection-state=established,related add chain=input action=drop connection-state=invalid add chain=input action=accept protocol=icmp add chain=input action=accept protocol=tcp dst-port=22,8291 \ src-address=198.51.100.20/32 in-interface=ether1 add chain=input action=accept protocol=udp dst-port=13231 \ in-interface=ether1 add chain=input action=drop comment="A08 input deny"
Лишние службы лучше отключить, а SSH и WinBox ограничить разрешёнными адресами ещё и в /ip service, параметром address. Firewall это не отменяет, получается второй рубеж:
/ip service set telnet,ftp,www,www-ssl,api,api-ssl disabled=yes /ip service set ssh,winbox address=198.51.100.20/32
Схема рассчитана только на IPv4. Если IPv6 на VPS не нужен, его проще выключить целиком, а если нужен, ему понадобится своя политика input и forward. На публичных портах отключите ещё MAC-доступ и обнаружение соседей, а во внешнем firewall провайдера откройте только нужные подключения:
/ipv6 settings set disable-ipv6=yes /tool mac-server set allowed-interface-list=none /tool mac-server mac-winbox set allowed-interface-list=none /ip neighbor discovery-settings set discover-interface-list=none
Как безопасно подключить физический роутер к CHR?
1. Создайте WireGuard-интерфейсы и обменяйтесь публичными ключами, приватные оставьте на своих устройствах.
2. Откройте UDP-порт туннеля, задайте адреса и маршруты к нужным подсетям и ограничьте доступ правилами firewall.
3. Проверьте связь в обе стороны, MTU и новый вход администратора, прежде чем сохранять настройки и закрывать консоль.
Как подключить роутер к VPS-серверу
Для подключения MikroTik к VPS в этой схеме подходит WireGuard. Задача здесь в маршрутах между двумя IP-подсетями, объединять сети в общий Ethernet-сегмент не нужно. Обмен начинает роутер за NAT: он сам стучится на публичный адрес CHR. На всём пути между ними должен быть открыт UDP-порт туннеля. Подсети с двух сторон не должны пересекаться.
С обеих сторон создаётся интерфейс wg-site с UDP-портом 13231 и MTU 1420. Ключи RouterOS сгенерирует сам, публичный появится в выводе print. На CHR:
/interface wireguard add name=wg-site listen-port=13231 mtu=1420 /ip address add address=10.77.0.1/30 interface=wg-site /interface wireguard print
На физическом роутере команды те же, только адрес туннеля 10.77.0.2/30.
Затем каждой стороне добавляют peer с публичным ключом другой стороны. На CHR:
/interface wireguard peers add interface=wg-site \ public-key="ROUTER_PUBLIC_KEY" \ allowed-address=10.77.0.2/32,192.168.50.0/24
На физическом MikroTik:
/interface wireguard peers add interface=wg-site \ public-key="CHR_PUBLIC_KEY" \ allowed-address=10.77.0.1/32,10.20.0.0/24 \ endpoint-address=203.0.113.10 endpoint-port=13231 \ persistent-keepalive=25s
Keepalive раз в 25 секунд не даёт записи NAT по пути устареть, пока обычного трафика нет.
Allowed-address задаёт, с каких адресов peer может присылать пакеты и какому участнику WireGuard отправит пакет для этих адресов. Маршрут RouterOS к удалённой сети этим не создаётся, его добавляют отдельно. Такая настройка связи с VPS на роутере не трогает маршрут по умолчанию, интернет идёт через старый канал.
Маршрут на CHR:
/ip route add dst-address=192.168.50.0/24 gateway=wg-site
И на физическом MikroTik:
/ip route add dst-address=10.20.0.0/24 gateway=wg-site
В forward на новом CHR разрешите обмен только между этими подсетями, а остальной транзит закройте:
/ip firewall filter add chain=forward action=accept connection-state=established,related add chain=forward action=drop connection-state=invalid add chain=forward action=accept in-interface=wg-site out-interface=ether2 \ src-address=192.168.50.0/24 dst-address=10.20.0.0/24 add chain=forward action=accept in-interface=ether2 out-interface=wg-site \ src-address=10.20.0.0/24 dst-address=192.168.50.0/24 add chain=forward action=drop comment="A08 forward deny"
На физическом MikroTik такие разрешения ставьте перед существующими запретами, чтобы не сломать его защиту. NAT между сетями не нужен, но проверьте, не захватывает ли туннель широкое правило masquerade.
Серверам за CHR нужен шлюз 10.20.0.1 или хотя бы маршрут к 192.168.50.0/24 через него. С другой стороны то же самое, иначе ответ уйдёт через другой шлюз и потеряется.
Если маленький ping проходит, а передача файлов зависает, виноват обычно MTU, максимальный размер пакета на пути. 1420 здесь лишь стартовое значение. Проверяйте пакеты разного размера с запретом фрагментации и помните про внешние заголовки и сообщения ICMP, которые кто-то по дороге может резать.
После первого успешного ping
Туннель проверяют по нарастающей: адреса туннеля в обе стороны, шлюзы удалённых LAN, потом реальные узлы. Ping с самого роутера идёт мимо цепочки forward, поэтому клиентов проверяют отдельно. Таблицу маршрутов, счётчики firewall, время последнего рукопожатия и ошибки из журнала стоит сохранить:
/interface wireguard peers print detail /ip route print detail where dst-address=192.168.50.0/24 /ip firewall filter print stats /log print where topics~"wireguard"
Пропускную способность измеряют iperf3 между Linux-узлами за роутерами, одинаковыми прогонами в обе стороны. Следите за CPU роутеров и тестовых узлов, потерями и задержкой под нагрузкой, а в записи оставьте версию, лицензию, тариф, число потоков и длительность.
Самая обидная ловушка ждёт после установки Микротик на VPS с лицензией Free: ping ходит, а передача упирается в 1 Мбит/с. Так что сначала проверьте лицензию, а проблему в шифровании ищите потом. И не запускайте генератор трафика на самом маршрутизаторе, он съест его CPU и испортит замер.
Для резервных копий у RouterOS два формата. Текстовый export удобно читать и переносить, но по умолчанию он прячет чувствительные значения, а пароли пользователей, сертификаты и SSH-ключи придётся восстанавливать по отдельному плану. Binary backup сохраняет конфигурацию целиком, включая MAC-адреса. Его храните зашифрованным и восстанавливайте на том же устройстве и версии или в максимально похожей среде.
Перед обновлением сохраните обе копии вне CHR и проверьте восстановление на изолированной тестовой VM. Пока рабочий CHR в строю, клону нельзя выдавать его адреса и ключи туннеля, иначе он начнёт перехватывать трафик. Заодно уточните, что будет с лицензией при замене экземпляра, а после обновления повторите проверки доступа и маршрутов.
Последняя проверка самая простая: перезагрузите тестовый CHR, повторите передачу между конечными узлами и войдите администратором заново. Установка CHR на VPS закончена, когда всё это работает после перезагрузки. А путь в консоль провайдера держите под рукой и дальше: он не зависит от туннеля и выручит при первой же ошибке в маршрутах.
