Представьте обычную ситуацию. Дома работает MikroTik, к нему подключены NAS, компьютер и несколько других устройств. Находясь в поездке, вы хотите открыть файлы на домашнем сервере или зайти в веб-интерфейс оборудования. Но подключение не работает, хотя интернет дома исправен. Провайдер выдаёт серый IP-адрес, а попытки настроить проброс портов ничего не меняют.
Проблему можно решить без покупки статического IP у домашнего провайдера. Понадобится небольшой виртуальный сервер с публичным адресом, на котором будет работать MikroTik Cloud Hosted Router, сокращённо CHR. Домашний роутер сам установит защищённое соединение с VPS, а ноутбук или смартфон смогут подключаться к домашней сети через облачный маршрутизатор.
Мы построим такую систему с нуля, установим RouterOS на VPS, создадим два отдельных туннеля WireGuard и настроим доступ к конкретному домашнему устройству. Причём весь домашний интернет продолжит работать через прежнего провайдера. Через VPS пойдёт только трафик, которому действительно нужен защищённый маршрут.
В результате пользователь сможет находиться в другой стране, подключиться с ноутбука к CHR и открыть домашний NAS по внутреннему адресу 192.168.60.20. При этом веб-интерфейс NAS не придётся публиковать в интернете.
Все действия выполняйте только со своими серверами и сетями либо с разрешения владельца. Установка CHR вместо существующей ОС уничтожает данные на системном диске VPS. Ошибки в конфигурации маршрутов и межсетевого экрана могут прервать удалённое управление. Перед изменениями проверьте аварийную консоль провайдера и сохраните резервные копии.
Как устроена схема и почему CHR удобнее обычного VPN-сервера
Технически задачу можно решить и без RouterOS. Например, установить WireGuard на обычный Linux-сервер и вручную настроить маршрутизацию через iptables или nftables. Для одного домашнего компьютера подойдут и готовые решения удалённого доступа.
Преимущество CHR проявляется, когда нужно управлять несколькими сетями, подключать новые устройства, ограничивать доступ отдельным пользователям и видеть правила маршрутизации в привычном интерфейсе MikroTik. Виртуальный маршрутизатор поддерживает те же базовые механизмы RouterOS, которые используются на физических устройствах производителя.
В нашем случае CHR станет центральным узлом, через который будут соединяться домашняя сеть и удалённые пользователи.
На CHR создадим два интерфейса WireGuard. Первый предназначен для постоянного соединения с домашним MikroTik. Второй будет принимать подключения с ноутбуков и смартфонов. Разделение позволит независимо управлять ключами, маршрутами и правилами доступа.
Каждая часть сети получит собственный диапазон адресов.
| Устройство или сеть | Адрес | Назначение |
|---|---|---|
| VPS | 198.51.100.30 | Пример публичного IPv4 |
| CHR, домашний туннель | 172.27.40.1/30 | Связь с роутером |
| Домашний MikroTik | 172.27.40.2/30 | Вторая сторона туннеля |
| CHR, клиентский туннель | 172.27.50.1/24 | Подключение пользователей |
| Удалённый ноутбук | 172.27.50.10 | Клиент WireGuard |
| Домашняя LAN | 192.168.60.0/24 | Локальная сеть |
| Домашний NAS | 192.168.60.20 | Устройство для удалённого доступа |
Адрес 198.51.100.30 принадлежит диапазону для документации. В реальной конфигурации вместо него потребуется публичный IPv4 вашего VPS. Остальные адреса можно использовать непосредственно, если такие подсети ещё не заняты в вашей инфраструктуре.
Подключение домашнего MikroTik через WireGuard не требует входящего порта со стороны квартиры. Роутер сам отправит UDP-пакеты на VPS, а провайдерский NAT сохранит сопоставление для обратного трафика. Именно такая организация позволяет работать даже при CGNAT.
Но есть обязательное условие. Интернет-провайдер должен пропускать исходящий UDP-трафик к VPS. Если UDP блокируется, одного изменения адресов или портов может оказаться недостаточно.
Выбираем VPS и учитываем лицензию CHR
Для небольшого личного узла достаточно виртуальной машины KVM/QEMU с одним vCPU и 1 ГБ оперативной памяти. Минимальные требования MikroTik ниже, но дополнительная память оставит запас для RouterOS 7, журналов и обновлений.
Проверьте, что хостер разрешает загрузку пользовательского дискового образа, предоставляет виртуальную консоль и поддерживает входящие UDP-соединения. Лучше, если доступен сетевой адаптер virtio-net. Контейнерный VPS на LXC или OpenVZ с общим ядром Linux не подходит для стандартной установки CHR.
Отдельный пункт расходов связан с лицензией. Бесплатный CHR работает без ограничения срока, однако исходящая скорость каждого интерфейса ограничена 1 Мбит/с. Для первичной проверки маршрутов хватит, но копировать большие файлы с NAS будет неудобно.
Лицензия P1 снимает проблему для большинства домашних сценариев, повышая лицензионный предел до 1 Гбит/с на интерфейс. MikroTik предлагает 60-дневный пробный период платных уровней. Более высокие тарифы нужны только после проверки реальной производительности VPS и домашнего канала. Актуальные условия лицензирования лучше проверить до покупки.
Устанавливаем RouterOS на виртуальный сервер
Для работы понадобится Cloud Hosted Router, а не обычный пакет RouterOS для физического устройства. Откройте раздел загрузки CHR, выберите Long-term или Stable и скачайте образ под свой гипервизор.
Для стандартного VPS на KVM подходит RAW disk. Некоторые облачные панели поддерживают готовые QCOW2-диски, VMware использует VMDK, Hyper-V работает с VHDX. Формат и режим загрузки виртуальной машины должны соответствовать образу.
Предпочтительный способ установки заключается в импорте диска через панель управления VPS. В результате не нужно запускать команды перезаписи на работающей машине. Однако далеко не все хостеры предоставляют такой механизм.
Вариант с загрузкой собственного диска
Если панель позволяет импортировать RAW, загрузите распакованный образ CHR и назначьте его системным диском. Старый диск с Linux отключите либо удалите после сохранения нужных данных. Затем проверьте порядок загрузки и запустите сервер.
Когда облачная платформа принимает только QCOW2, образ RAW можно преобразовать на компьютере с установленным qemu-img.
qemu-img convert -f raw -O qcow2
chr.img chr.qcow2
qemu-img info chr.qcow2После преобразования импортируйте полученный файл. Преобразование формата не исправляет несовместимость прошивки виртуальной машины, поэтому заранее уточните требования провайдера к BIOS и UEFI.
Вариант с аварийной Linux-средой
Если импорт недоступен, но провайдер поддерживает Rescue Mode, загрузите VPS в аварийный Linux. Системный диск обычной ОС при таком сценарии не должен использоваться самой аварийной средой.
В примере взят выпуск CHR 7.23.8 из ветки Long-term. При использовании другой версии замените номер на действительный выпуск с сайта MikroTik.
CHR_VER=7.23.8
curl -fL --retry 3
"https://download.mikrotik.com/routeros/${CHR_VER}/chr-${CHR_VER}.img.zip"
-o mikrotik-chr.zip
unzip -t mikrotik-chr.zip
unzip mikrotik-chr.zip
ls -lh chr-${CHR_VER}.img
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODELСначала убедитесь, что архив скачан полностью. При наличии опубликованной MikroTik контрольной суммы сравните SHA-256 файла с эталоном. Не используйте контрольные суммы со случайных зеркал.
Последняя команда покажет диски VPS. Нужно найти именно системный диск, предназначенный для CHR. Например, на KVM его часто называют /dev/vda, но у конкретного провайдера устройство может называться совершенно иначе.
Дальше выполняется необратимая операция. Пример ниже предназначен только для машины, где целевой диск точно определён как /dev/vda, все его разделы размонтированы, swap отключён, а данные сохранены отдельно.
dd if=chr-7.23.8.img
of=/dev/vda
bs=4M
status=progress
conv=fsync
syncЗаписывать образ нужно на весь диск, не на раздел /dev/vda1. После завершения выключите Rescue Mode и загрузите VPS с основного накопителя.
Если RouterOS не запускается, проверьте виртуальный контроллер диска, прошивку VM и порядок загрузки. Не пытайтесь исправить проблему повторной записью образа на другие устройства без проверки.
Первый вход и выход в интернет
Откройте консоль виртуальной машины в панели провайдера. У чистого официального CHR первоначальный пользователь называется admin, пароль отсутствует. При первом входе задайте сложный уникальный пароль.
Пока CHR не защищён, закройте внешний доступ правилами сетевого экрана провайдера. Для нашего проекта впоследствии понадобятся только два UDP-порта, 51820 и 51821. Открывать публичный WinBox и SSH не требуется.
Для начала посмотрите конфигурацию RouterOS.
/system resource print
/system package print
/system license print
/interface ethernet print detail
/ip address print
/ip dhcp-client print
/ip route print detailПроверьте MAC-адрес сетевого адаптера, сопоставьте его с настройками VPS и определите, какой интерфейс подключён к интернету. В дальнейшем будем считать, что внешний интерфейс называется ether1.
Если хостер выдаёт адрес через DHCP и клиент ещё не настроен, добавьте его.
/ip dhcp-client add
interface=ether1
add-default-route=yes
disabled=no
/ip dhcp-client print detailПри статической адресации понадобятся значения из панели провайдера. Следующий набор команд иллюстрирует обычную сеть с доступным шлюзом. Использовать указанные примерные IP-адреса на настоящем VPS нельзя.
/ip address add
address=198.51.100.30/24
interface=ether1
/ip route add
dst-address=0.0.0.0/0
gateway=198.51.100.1
/ip dns set
servers=1.1.1.1,9.9.9.9
allow-remote-requests=noСтатическую настройку выполняйте вместо DHCP, а не вместе с ним. У части облачных провайдеров используется маршрут через шлюз вне назначенной подсети или адрес с маской /32. Для подобных VPS нужны параметры маршрутизации конкретного хостинга, обычный пример с /24 не подходит.
Проверьте доступность внешней сети.
/ping 1.1.1.1 count=4
/ping example.com count=4Первый тест проверяет IP-связность, второй также зависит от корректной работы DNS. Отсутствие ответа на ICMP не всегда означает полную недоступность адреса, поскольку некоторые сети блокируют пинг. При необходимости проверяйте установление TCP-соединения к разрешённому серверу.
Создайте отдельного администратора, назначив ему собственный пароль.
/user add
name=cloud-admin
group=full
password="REPLACE_WITH_YOUR_PASSWORD"Проверьте вход новой учётной записью через консоль и только затем отключите стандартного пользователя.
/user disable admin
/system identity set name=home-access-gatewayОтключите неиспользуемые управляющие службы. SSH и WinBox оставим, но доступ к ним разрешим только через клиентский VPN.
/ip service disable
telnet,ftp,www,www-ssl,api,api-ssl
/tool mac-server set
allowed-interface-list=none
/tool mac-server mac-winbox set
allowed-interface-list=none
/tool mac-server ping set enabled=no
/ip neighbor discovery-settings set
discover-interface-list=noneВ RouterOS 7.23 ограничение разрешённых адресов для сервисов задаётся параметром address, а в более новых ветках начиная с 7.24 используется имя available-from. Даже при настройке разрешённых адресов основной защитой административных портов должен оставаться межсетевой экран.
В нашем примере используется только IPv4. Если провайдер назначил серверу IPv6, отдельно настройте фильтрацию IPv6 или отключите протокол, если IPv6 не требуется для связи.
/ipv6 settings set disable-ipv6=yesНе отключайте IPv6 на сервере, который использует его для основного интернет-подключения.
Создаём два туннеля WireGuard и соединяем VPS с домом
Перейдём к центральной части проекта. На виртуальном маршрутизаторе будут два WireGuard-интерфейса с разными UDP-портами и непересекающимися адресными диапазонами.
Первый интерфейс wg-home обслуживает постоянный канал от домашнего MikroTik. Второй wg-users принимает удалённых пользователей.
Создаём интерфейсы на CHR
В консоли VPS выполните команды.
/interface wireguard add
name=wg-home
listen-port=51820
mtu=1420
/interface wireguard add
name=wg-users
listen-port=51821
mtu=1420
/ip address add
address=172.27.40.1/30
interface=wg-home
/ip address add
address=172.27.50.1/24
interface=wg-usersRouterOS создаст для каждого интерфейса собственную пару ключей. Публичные ключи можно получить двумя командами.
:put [/interface wireguard get
[find name=wg-home] public-key]
:put [/interface wireguard get
[find name=wg-users] public-key]Сохраните оба публичных ключа и подпишите, к какому интерфейсу относится каждый. Закрытые ключи должны оставаться на соответствующем устройстве. Передавать закрытый ключ CHR на домашний MikroTik или телефон не требуется.
Настраиваем домашний MikroTik
Теперь откройте WinBox или терминал физического маршрутизатора. Домашний MikroTik должен использовать RouterOS 7, поддерживающую WireGuard.
Создайте отдельный интерфейс для постоянного канала с VPS.
/interface wireguard add
name=wg-to-cloud
listen-port=51999
mtu=1420
/ip address add
address=172.27.40.2/30
interface=wg-to-cloudПолучите публичный ключ домашнего устройства.
:put [/interface wireguard get
[find name=wg-to-cloud] public-key]Вернитесь в терминал CHR и зарегистрируйте домашний роутер как участника интерфейса wg-home.
/interface wireguard peers add
interface=wg-home
public-key="HOME_MIKROTIK_PUBLIC_KEY"
allowed-address=172.27.40.2/32,192.168.60.0/24
responder=yesПараметр allowed-address сообщает WireGuard, какие внутренние адреса принадлежат соответствующему участнику. В нашем случае за домашним MikroTik находятся адрес туннеля 172.27.40.2 и локальная сеть 192.168.60.0/24.
На CHR также потребуется маршрут к домашней сети.
/ip route add
dst-address=192.168.60.0/24
gateway=wg-homeТеперь настройте ответную сторону на физическом MikroTik. Подставьте публичный ключ интерфейса wg-home с VPS и настоящий внешний адрес виртуального сервера.
/interface wireguard peers add
interface=wg-to-cloud
public-key="CHR_HOME_PUBLIC_KEY"
allowed-address=172.27.40.1/32,172.27.50.0/24
endpoint-address=198.51.100.30
endpoint-port=51820
persistent-keepalive=25sДомашний MikroTik будет самостоятельно отправлять пакеты на VPS. Интервал persistent-keepalive помогает сохранять активное сопоставление NAT в периоды отсутствия пользовательского трафика.
Здесь появляется ещё одна подсеть, 172.27.50.0/24. Через неё позже будут приходить ноутбуки и телефоны. Домашнему роутеру нужно знать обратный маршрут к клиентам.
/ip route add
dst-address=172.27.50.0/24
gateway=wg-to-cloudНикакой замены маршрута по умолчанию на домашнем MikroTik не требуется. Компьютеры продолжат выходить в интернет через обычный WAN. Дополнительный маршрут затронет только адреса удалённых клиентов.
Защищаем CHR правилами firewall
До открытия UDP-портов на стороне провайдера настройте межсетевой экран RouterOS. У официального чистого CHR нельзя предполагать наличие такой же готовой защиты, как у домашнего MikroTik с заводской конфигурацией.
Следующий набор правил рассчитан на новый CHR без ранее созданных правил IPv4. На рабочем маршрутизаторе существующие правила нужно изучить и объединить с новой политикой. Просто добавлять второй набор в конце нельзя, поскольку более раннее правило может уже разрешать нежелательный трафик.
/ip firewall filter
add chain=input action=accept
connection-state=established,related,untracked
comment="Allow established input"
add chain=input action=drop
connection-state=invalid
comment="Drop invalid input"
add chain=input action=accept
in-interface=ether1
protocol=udp
src-port=67 dst-port=68
comment="DHCP replies if required"
add chain=input action=accept
in-interface=ether1
protocol=udp
dst-port=51820,51821
comment="WireGuard entry points"
add chain=input action=accept
in-interface=wg-home
src-address=172.27.40.2/32
protocol=icmp
comment="Home router diagnostics"
add chain=input action=accept
in-interface=wg-users
src-address=172.27.50.10/32
protocol=tcp
dst-port=22,8291
comment="Admin from VPN client"
add chain=input action=accept
in-interface=wg-users
src-address=172.27.50.10/32
protocol=icmp
comment="VPN diagnostics"
add chain=input action=drop
comment="Default deny input"Разрешение DHCP требуется только для виртуальных машин с динамической адресацией. При статическом WAN можно удалить соответствующее правило.
В отличие от конфигурации с открытым WinBox, административные подключения здесь принимаются исключительно от клиента 172.27.50.10 через WireGuard. Даже если злоумышленник обнаружит публичный адрес CHR, порт 8291 останется недоступен извне.
Теперь зададим правила пересылки пакетов. В качестве практического ограничения разрешим удалённому ноутбуку обращаться только к NAS 192.168.60.20 по HTTPS и отправлять ему ICMP-запросы для диагностики.
/ip firewall filter
add chain=forward action=accept
connection-state=established,related,untracked
comment="Allow established forwarding"
add chain=forward action=drop
connection-state=invalid
comment="Drop invalid forwarding"
add chain=forward action=accept
in-interface=wg-users
out-interface=wg-home
src-address=172.27.50.10/32
dst-address=192.168.60.20/32
protocol=tcp dst-port=443
comment="Remote HTTPS to NAS"
add chain=forward action=accept
in-interface=wg-users
out-interface=wg-home
src-address=172.27.50.10/32
dst-address=192.168.60.20/32
protocol=icmp
comment="NAS ping test"
add chain=forward action=drop
comment="Default deny forwarding"Последнее правило запрещает CHR пересылать весь прочий IPv4-трафик. Такой режим подходит для выбранного сценария, но не для виртуального маршрутизатора, который одновременно обслуживает другие сети или сервисы.
При этом NAT на CHR не требуется. Мы не собираемся выпускать клиентов в интернет через внешний адрес VPS. Задача заключается в передаче пакетов между двумя защищёнными туннелями с сохранением исходных адресов.
В панели облачного провайдера теперь разрешите входящий UDP на порты 51820 и 51821. Остальные входящие подключения можно оставить закрытыми. Убедитесь, что действующие правила облачной платформы не блокируют необходимый ответный трафик.
Ограничиваем доступ со стороны домашней сети
На домашнем MikroTik обычно уже работает собственный firewall. Сбрасывать его или отключать заводские правила не нужно.
Мы хотим разрешить ноутбуку доступ к одному NAS, а не ко всей домашней сети. Добавим два разрешающих правила и отдельный запрет остальных новых подключений из туннеля.
/ip firewall filter add
chain=forward
action=accept
in-interface=wg-to-cloud
src-address=172.27.50.10/32
dst-address=192.168.60.20/32
protocol=tcp
dst-port=443
comment="Cloud client to NAS HTTPS"
/ip firewall filter add
chain=forward
action=accept
in-interface=wg-to-cloud
src-address=172.27.50.10/32
dst-address=192.168.60.20/32
protocol=icmp
comment="Cloud client NAS ping"
/ip firewall filter add
chain=forward
action=drop
in-interface=wg-to-cloud
connection-state=new
comment="Block other new VPN connections"На стандартной домашней конфигурации без дополнительных глобальных разрешений разместите новые правила после правил обработки установленных соединений и до любых более широких разрешений или запретов, которые могут повлиять на трафик WireGuard.
Проверить порядок можно в WinBox через IP → Firewall → Filter Rules. Если на домашнем роутере присутствует пользовательское правило, разрешающее весь транзит до добавленных ограничений, три новых правила не обеспечат нужную изоляцию, пока не окажутся выше широкого разрешения.
Исходящие ответы NAS должны проходить через домашний MikroTik как через свой обычный шлюз. Если у сервера настроен другой шлюз, потребуется отдельный обратный маршрут.
Проверьте также существующий NAT. Типичное правило masquerade для выхода через интерфейс WAN не мешает описанной схеме. Слишком широкое правило, подменяющее адреса на всех интерфейсах, способно скрыть исходные адреса клиентов или изменить поведение туннеля.
После настройки у нас есть постоянная защищённая связь между CHR и домашним маршрутизатором. Но удалённый ноутбук пока не зарегистрирован, поэтому следующим шагом создадим ему собственный доступ.
Подключаем ноутбук, проверяем маршруты и устраняем ошибки
Для удалённых пользователей мы заранее подготовили интерфейс wg-users на CHR. Теперь к нему можно подключить ноутбук с Windows или Linux, а также телефон с Android либо iOS.
В качестве примера используем один ноутбук с адресом 172.27.50.10. На компьютере нужно установить приложение WireGuard и создать новую пару ключей. Закрытый ключ сохранится на устройстве, а публичный понадобится серверу.
Регистрируем удалённого пользователя
На CHR добавьте нового участника. Вместо LAPTOP_PUBLIC_KEY укажите публичный ключ, который создал WireGuard на ноутбуке.
/interface wireguard peers add
interface=wg-users
public-key="LAPTOP_PUBLIC_KEY"
allowed-address=172.27.50.10/32
responder=yes
comment="Personal laptop"Конфигурация клиентского WireGuard будет выглядеть следующим образом.
[Interface]
PrivateKey = LAPTOP_PRIVATE_KEY
Address = 172.27.50.10/24
[Peer]
PublicKey = CHR_USERS_PUBLIC_KEY
Endpoint = 198.51.100.30:51821
AllowedIPs = 172.27.50.0/24, 192.168.60.20/32
PersistentKeepalive = 25Подставьте настоящие ключи и внешний адрес VPS. Секретный ключ ноутбука должен оставаться только на ноутбуке. Не переносите в клиентскую конфигурацию закрытый ключ CHR.
Обратите внимание на параметр AllowedIPs. Здесь указаны только адреса клиентской подсети WireGuard и конкретный домашний NAS. По умолчанию браузер, мессенджеры и остальные приложения продолжат выходить в интернет через обычное подключение ноутбука.
Если добавить 0.0.0.0/0, получится совершенно другой сценарий. Система попытается направлять через WireGuard весь IPv4-трафик. В нашей конфигурации CHR такую пересылку не разрешает, поэтому интернет у клиента может перестать работать.
Для дополнительного устройства создавайте новую пару ключей и отдельный адрес, например 172.27.50.11. Не копируйте одну и ту же клиентскую конфигурацию на несколько телефонов и ноутбуков. Раздельные ключи позволяют отключить потерянное устройство, не затрагивая остальные.
Проверяем связь по этапам
Сначала проверьте постоянный канал между домашним MikroTik и CHR. На физическом роутере выполните команду.
/ping 172.27.40.1
src-address=172.27.40.2
count=5Если CHR отвечает, базовая маршрутизация туннеля работает. Затем посмотрите состояние участников WireGuard на обеих сторонах.
/interface wireguard peers print detailОбратите внимание на время последнего рукопожатия, поля rx и tx. Если рукопожатия нет, проверьте ключи, адрес VPS, UDP-порт и облачные правила безопасности.
Теперь подключите ноутбук к другой сети, например через мобильную точку доступа. Активируйте WireGuard и попробуйте обратиться к CHR по внутреннему IP 172.27.50.1.
Следующий шаг выполняется уже на самом ноутбуке.
ping 172.27.50.1
ping 192.168.60.20Если оба адреса отвечают, проверьте реальный прикладной сервис. Например, откройте в браузере адрес NAS.
https://192.168.60.20Для работы понадобится веб-интерфейс NAS, который действительно слушает TCP-порт 443. Если используется другой порт, замените порт и в клиентском URL, и в обоих правилах firewall.
При использовании HTTPS по IP браузер может предупредить о несоответствии имени сертификата. Такая ошибка сама по себе не указывает на проблему WireGuard. Для корректной проверки сертификата используйте доменное имя, на которое он выпущен, и настройте соответствующее разрешение DNS.
Нужно учитывать ещё одну особенность. Если домашний NAS запрещает обращения из других подсетей, разрешение на MikroTik проблему не устранит. Потребуется отдельно разрешить подключения с 172.27.50.10 в настройках самого устройства.
Самые частые проблемы
WireGuard подключается, но ничего не открывается. Успешное рукопожатие подтверждает обмен ключами и связь между участниками, но не правильность маршрутов. Проверьте, есть ли на CHR маршрут к 192.168.60.0/24, а на домашнем MikroTik маршрут к 172.27.50.0/24.
CHR видит домашний роутер, но ноутбук не видит NAS. Проверьте оба правила forward, обратный маршрут и локальный firewall NAS. Пинг с самого маршрутизатора не проверяет правила транзита пользовательского трафика, поскольку пакеты маршрутизатора проходят через другую цепочку обработки.
Дома всё работает, а через мобильный интернет нет. Убедитесь, что тест действительно идёт через VPN, а ноутбук или телефон не остался подключённым к домашнему Wi-Fi. Проверьте публичный адрес VPS и допустимость исходящего UDP в мобильной сети.
После подключения к VPN открываются не все домашние ресурсы. В нашей конфигурации разрешён только HTTPS к одному NAS. Для SMB, RDP, SSH и других сервисов понадобятся отдельные разрешения. Например, для доступа к SMB используется TCP-порт 445. Открывать сразу все порты и всю LAN только ради удобства не стоит.
Проблемы возникают лишь при передаче больших файлов. Возможной причиной становится MTU. Начальное значение 1420 может оказаться слишком большим для конкретного пути. Проверьте фактический MTU и при необходимости попробуйте меньший, например 1380, на соответствующих WireGuard-интерфейсах. Не меняйте MTU наугад, если причина связана с блокировкой ICMP или потерями в сети.
Скорость неожиданно ограничилась примерно одним мегабитом. Сначала посмотрите уровень лицензии CHR. Бесплатный вариант имеет соответствующий предел исходящего трафика на интерфейс. При платной лицензии проверяйте загрузку виртуального процессора, пропускную способность домашнего канала и ограничения VPS. Для измерений удобен iperf3 между конечными устройствами, а не генератор трафика на самой RouterOS.
У роутера есть рукопожатие, но передача пакетов не идёт. Проверьте allowed-address у всех участников. На одном интерфейсе WireGuard диапазоны разных участников не должны пересекаться. Также убедитесь, что адреса локальной сети не совпадают с диапазоном сети, к которой подключён удалённый ноутбук.
WinBox перестал подключаться после изменения firewall. Используйте консоль VPS из панели провайдера. Перед изменением правил на физическом MikroTik рекомендуется включать Safe Mode через Ctrl+X в терминале или кнопку Safe Mode в WinBox. Режим помогает откатить изменения при аварийной потере управляющего соединения, но не защищает от всех ошибок, в частности связанных с перезагрузкой.
Что проверить перед постоянной эксплуатацией
После запуска системы проверьте безопасность CHR с двух сторон. Из интернета должны быть доступны только два выбранных UDP-порта. Управление RouterOS через SSH или WinBox должно работать исключительно из разрешённой защищённой сети.
Далее убедитесь, что домашний MikroTik не принимает из туннеля произвольные подключения к локальной сети. Проверить ограничения можно попыткой открыть с удалённого ноутбука другой домашний адрес. Если правила настроены правильно, неразрешённые новые подключения не пройдут.
Резервную копию конфигурации сохраните за пределами VPS. Для текстового экспорта используйте следующую команду.
/export file=chr-configТекстовый экспорт удобен для чтения и переноса параметров, но не является полной копией всех секретов. Двоичный backup сохраняет гораздо больше чувствительной информации, включая параметры, которые нельзя оставлять в открытом виде.
Создайте зашифрованную резервную копию с отдельным паролем.
/system backup save
name=chr-protected
password="REPLACE_WITH_BACKUP_PASSWORD"После скачивания резервной копии на доверенное устройство удалите ненужные файлы с VPS. Двоичный backup лучше восстанавливать на той же виртуальной машине и совместимой версии RouterOS. При переносе между разными виртуальными машинами текстовый экспорт обычно безопаснее, поскольку двоичная копия содержит в том числе MAC-адреса интерфейсов.
Наконец, проверьте обновления RouterOS и состояние лицензии. Рабочая лицензия CHR требует периодического контакта с инфраструктурой MikroTik для обновления лицензионного статуса. При длительной недоступности лицензионного сервера могут ограничиться обновления системы, хотя маршрутизация продолжит работать.
Перед обновлением RouterOS сохраняйте резервную копию и проверяйте наличие доступа к консоли. Для домашнего роутера также учитывайте совместимость обновления с аппаратной платформой и установленными пакетами.
Частые вопросы
Обязательно ли покупать белый IP для домашнего MikroTik?
Нет. Домашний маршрутизатор устанавливает исходящий WireGuard-туннель к VPS с публичным адресом. Поэтому схема работает даже за CGNAT, если провайдер разрешает исходящий UDP-трафик.
Можно ли установить CHR на VPS с Ubuntu без переустановки системы?
CHR представляет собой самостоятельную операционную систему маршрутизатора. Стандартная установка на VPS заменяет существующий системный диск. Если требуется сохранить Ubuntu, можно запустить CHR как отдельную виртуальную машину внутри совместимого гипервизора, но вложенная виртуализация должна поддерживаться провайдером.
Почему лучше использовать два туннеля WireGuard вместо одного?
Два интерфейса позволяют отделить постоянный канал между маршрутизаторами от пользовательских подключений. Так проще контролировать права доступа и отслеживать трафик. Для небольших схем достаточно и одного интерфейса WireGuard, если правильно настроены адреса участников и правила фильтрации.
Нужен ли второй сетевой интерфейс у VPS?
Нет. Для рассмотренного сценария хватает одного виртуального сетевого адаптера с доступом в интернет. Интерфейсы WireGuard создаются программно и не требуют дополнительных виртуальных сетевых карт от хостинг-провайдера.
Можно ли подключить несколько квартир или офисов?
Да. Для каждой площадки можно создать отдельный туннель или участника WireGuard на CHR. Понадобятся уникальные адреса, маршруты к каждой локальной сети и правила межсетевого экрана. При совпадающих адресных диапазонах потребуется изменить адресацию либо использовать более сложную схему NAT или VRF.
Можно ли направить через CHR весь интернет-трафик ноутбука?
Да, но потребуется отдельная настройка полного туннеля. Нужно изменить маршруты клиента, разрешить пересылку к внешнему интерфейсу CHR и настроить NAT либо соответствующие маршруты. Описанная конфигурация специально ограничена доступом к домашнему NAS и не предназначена для выхода в интернет через VPS.
Что произойдёт, если VPS выключится?
Удалённые подключения к домашней сети через CHR перестанут работать. Домашний интернет при этом сохранится, поскольку основной маршрут физического MikroTik не менялся. Для критичных задач можно предусмотреть резервный VPS и второй туннель, но такая конфигурация потребует дополнительной настройки переключения маршрутов.
Какой самый простой способ проверить безопасность готовой схемы?
Проверьте доступность SSH и WinBox из внешней сети, убедитесь, что без WireGuard доступ к домашнему NAS отсутствует, а после подключения доступны только разрешённые адреса и порты. Отдельно проверьте, что отключение VPN немедленно прекращает доступ к внутренним ресурсам через этот маршрут.
Вывод. MikroTik CHR на VPS позволяет организовать удалённый доступ к домашней инфраструктуре без публичного адреса у домашнего провайдера. Такой сервер не обязан заменять основной маршрутизатор или пропускать через себя весь интернет. CHR может работать только как защищённая промежуточная точка для нужных сервисов.
Для первого проекта разумно ограничиться одним домашним MikroTik, одним удалённым клиентом и конкретным устройством в LAN. После проверки связи можно добавить пользователей, отдельные правила доступа, дополнительные площадки и резервные каналы.
Главный практический принцип заключается в разделении задач. Постоянный туннель связывает VPS с домом, пользовательский туннель принимает удалённые подключения, а маршруты и firewall определяют, какие ресурсы доступны каждому участнику. Такая конфигурация проще поддаётся диагностике и не требует открывать домашние серверы всему интернету.
Перед постоянным использованием проверьте реальную скорость с учётом лицензии CHR, сохраните конфигурацию и убедитесь, что управляющие порты VPS недоступны снаружи. Если требуется доступ только к одному компьютеру и не нужны функции маршрутизатора, более простое решение удалённого доступа может оказаться практичнее полноценного CHR.
