Нативный Reverse Proxy в MikroTik RouterOS 7.22+: Полное руководство по настройке

Долгое время администраторы MikroTik сталкивались с классической архитектурной дилеммой. Представьте ситуацию: у вас есть один публичный IP-адрес, но за ним в локальной сети нужно опубликовать сразу несколько веб-сервисов, и все они должны работать по стандартному HTTPS-порту 443.

Например:

• cloud.example.com → Nextcloud
• wiki.example.com → База знаний BookStack
• pihole.example.com → Панель AdGuard Home или Pi-hole
• ha.example.com → Умный дом Home Assistant

Обычный Destination NAT (Port Forwarding) здесь бессилен. Он умеет перенаправлять порты только «вслепую»: весь трафик с порта WAN:443 улетит на какой-то один внутренний IP. NAT не умеет заглядывать внутрь пакета и анализировать доменные имена.

До выхода RouterOS 7.22 админам приходилось выкручиваться: разворачивать сторонние прокси-серверы (Nginx, HAProxy, Caddy, Traefik) на отдельных виртуальных машинах или упаковывать их в контейнеры прямо внутри роутера.

В RouterOS 7.22 MikroTik наконец-то представил встроенный, нативный Reverse Proxy. Это не превращает маршрутизатор в полноценную замену тяжеловесным веб-серверам, но дает простой и элегантный инструмент для базовой публикации HTTPS-сервисов.

Как это работает

Встроенный обратный прокси в RouterOS работает на уровне приложений (L7). Он принимает зашифрованный HTTPS-трафик из интернета, анализирует его и отправляет к нужным внутренним серверам или контейнерам приложений (RouterOS Apps).

Логика движения трафика выглядит так:

Клиент из интернета
        |
        | HTTPS (порт 443)
        v
MikroTik RouterOS (Сервис reverse-proxy)
        |
        | Анализ SNI из пакета TLS ClientHello
        v
Внутренний сервис в LAN (или локальный контейнер)

Важный нюанс: Поскольку трафик зашифрован, RouterOS не может прочитать обычные заголовки HTTP (например, Host:). Вместо этого роутер смотрит на SNI (Server Name Indication) — поле, которое клиент передает в открытом виде на самом первом этапе установления защищенного соединения (TLS Handshake). Сверяя этот SNI со своей таблицей правил, MikroTik мгновенно понимает, куда направить запрос.

Анатомия конфигурации

Настройка прокси-сервера в RouterOS разделена на два логических уровня:

1. Глобальный сервис (/ip/service/reverse-proxy) Это такой же системный сервис, как winbox, ssh или www-ssl. Он отвечает за запуск самого прокси-движка, выбор TCP-порта (по умолчанию 443) и привязку дефолтного SSL-сертификата.

2. Таблица правил (/ip/reverse-proxy) Здесь создается карта маршрутизации: какой домен (SNI) на какой внутренний IPv4-адрес и порт нужно переслать.

Пошаговое руководство по настройке

Шаг 1. Подготовка и резервное копирование

Перед изменением сетевых служб и файрвола обязательно сохраните конфигурацию:

/system/backup/save name=before-reverse-proxy
/export file=before-reverse-proxy

Шаг 2. Освобождаем порт 443

По умолчанию встроенный веб-интерфейс управления роутером (WebFig) работает по HTTPS на том же 443-м порту (www-ssl). Если их не развести, прокси-сервер просто не запустится из-за конфликта.

У вас есть два пути:

• Вариант А (Рекомендуемый): Перенести WebFig на альтернативный порт (например, 8443) и ограничить доступ только безопасной локальной сетью:

/ip/service/set www-ssl port=8443 address=192.168.88.0/24

• Вариант Б: Полностью отключить WebFig (как HTTP, так и HTTPS), если для администрирования вы используете только WinBox:

/ip/service/disable www
/ip/service/disable www-ssl

Шаг 3. Подготовка SSL-сертификатов

Чтобы браузеры пользователей не ругались на небезопасное соединение, прокси-серверу нужны валидные SSL-сертификаты.

Вариант 1. Использование собственного домена и Let’s Encrypt

Убедитесь, что ваши домены (cloud.example.com, pihole.example.com) в DNS направлены на публичный IP-адрес вашего MikroTik. Выпустить официальный бесплатный сертификат можно прямо через встроенный ACME-клиент роутера:

/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=cloud.example.com,pihole.example.com

RouterOS автоматически создаст сертификаты и сам обновит их, когда их срок действия подойдет к концу (при достижении 80% срока).

Вариант 2. Использование MikroTik Cloud DDNS

Если у вас нет своего домена, можно использовать бесплатное имя от MikroTik вида xxxxx.sn.mynetname.net:

# Включаем DDNS
/ip/cloud/set ddns-enabled=yes update-time=yes

# Запрашиваем Let's Encrypt сертификат для этого облачного имени
/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=[/ip/cloud/get dns-name]

Шаг 4. Включение глобальной службы Reverse Proxy

Посмотрите имя выпущенного сертификата с помощью команды /certificate/print и активируйте службу прокси:

/ip/service/set reverse-proxy port=443 certificate=letsencrypt_cloud.example.com disabled=no

Шаг 5. Создание правил проксирования

Теперь свяжем внешние доменные имена с внутренними серверами. Допустим, Nextcloud развернут на 192.168.88.10, а Pi-hole — на 192.168.88.20. Оба работают внутри сети по обычному HTTP (порт 80).

# Направляем cloud.example.com на Nextcloud
/ip/reverse-proxy/add sni=cloud.example.com ip-address=192.168.88.10 port=80 comment="Nextcloud proxy"

# Направляем pihole.example.com на Pi-hole
/ip/reverse-proxy/add sni=pihole.example.com ip-address=192.168.88.20 port=80 comment="Pi-hole proxy"

Если параметру certificate оставить значение none, MikroTik будет автоматически использовать глобальный сертификат, который мы указали в Шаге 4.

Шаг 6. Настройка файрвола

Поскольку Reverse Proxy работает на самом роутере, входящий трафик идет непосредственно к нему. Это значит, что правила нужно добавлять в цепочку input, а не в привычную forward.

Разрешаем входящий HTTPS-трафик на внешнем интерфейсе (WAN):

/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=443 in-interface-list=WAN comment="Allow HTTPS reverse-proxy from WAN"

Если вы используете Let’s Encrypt с проверкой через HTTP (HTTP-01 challenge), роутеру также понадобится открыть порт 80 для входящих запросов от серверов сертификации:

/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=80 in-interface-list=WAN comment="Allow HTTP for ACME challenge"

⚠️ Внимание: Убедитесь, что эти правила находятся в самом верху таблицы /ip/firewall/filter/print — обязательно до любых запрещающих правил (drop).

Шаг 7. Решение проблемы доступа изнутри сети (Split-Brain DNS)

Если сейчас вы попытаетесь открыть cloud.example.com, находясь внутри домашней или офисной сети, вы, скорее всего, увидите ошибку. Локальные клиенты будут пытаться уйти на внешний IP роутера, что часто блокируется файрволом или приводит к некорректной маршрутизации (петля NAT).

Чтобы все работало «бесшовно» как из интернета, так и изнутри сети, настройте Split-Brain DNS. Создайте локальные статические записи на MikroTik, чтобы внутри сети эти домены резолвились в локальный IP-адрес самого роутера:

/ip/dns/static/add name=cloud.example.com address=192.168.88.1
/ip/dns/static/add name=pihole.example.com address=192.168.88.1

Где 192.168.88.1 — это IP-адрес вашего MikroTik в локальной сети. Встроенный прокси перехватит этот локальный трафик на порту 443 точно так же, как и внешний.

Настройка бэкенд-приложений

После того как MikroTik примет зашифрованный HTTPS-сигнал, снимет с него защиту (произведет TLS-терминацию) и перенаправит на ваш внутренний сервер по обычному HTTP, бэкенд-приложение может растеряться. Сервисы безопасности веб-приложений часто блокируют запросы, если «думают», что к ним обращаются через сторонний прокси.

Встроенный Reverse Proxy в RouterOS автоматически добавляет к запросам стандартные заголовки X-Forwarded-For (передает реальный IP клиента) и X-Forwarded-Proto (указывает, что изначально запрос пришел по HTTPS). Вам остается лишь объяснить это самим приложениям.

Пример для Nextcloud (config.php)

Вам нужно добавить локальный IP роутера в список доверенных прокси, иначе вы получите ошибку безопасности:

'trusted_domains' => [
  'cloud.example.com',
],
'trusted_proxies' => [
  '192.168.88.1', // LAN-адрес вашего MikroTik
],
'overwritehost'     => 'cloud.example.com',
'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'https://cloud.example.com',

Интеграция с RouterOS Apps (Контейнеры)

В RouterOS 7.22 появилась надстройка над контейнерами — меню /app. Разработчики глубоко интегрировали её со встроенным прокси.

Если вы разворачиваете приложение прямо на роутере через меню приложений, вам достаточно активировать один параметр use-https=yes. RouterOS автоматически создаст динамическое правило в меню /ip/reverse-proxy, свяжет его с облачным сертификатом DDNS и сгенерирует готовый безопасный URL для доступа к контейнеру.

Ограничения: когда встроенного прокси мало

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

1. Только IPv4 для внутренних серверов. Поле ip-address в таблице правил принимает исключительно IPv4-адреса. Проксировать трафик на внутренние бэкенды по IPv6 пока нельзя.

2. Нагрузка на CPU. Процесс шифрования и дешифрования TLS ложится на плечи процессора роутера. На слабых устройствах (hEX, hAP) обилие тяжелых запросов может загрузить CPU под 100%. На современных ARM/ARM64 (hAP ax, RB5009, CCR) или CHR доступна аппаратная оптимизация HTTP/2.

3. Минимум веб-функций. В MikroTik нет глубокого манипулирования заголовками, продвинутого логирования, встроенного WAF, авторизации на уровне прокси или сложной балансировки трафика. Если вам нужны WebSocket, gRPC, sticky sessions или сложные правила распределения нагрузки — полноценный Nginx/Caddy/HAProxy по-прежнему незаменим.

Диагностика

Если магия не произошла, проверяйте цепочку по шагам:

• Проверка порта: убедитесь, что прокси активен и занял порт: /ip/service/print where name=reverse-proxy

• Проверка извне: curl -vk https://cloud.example.com

• Проверка сертификата: openssl s_client -connect cloud.example.com:443 -servername cloud.example.com

• Проверка бэкенда: /ping 192.168.88.10

Сводный чек-лист для быстрой настройки

# 1. Отключаем конфликтующий WebFig HTTPS
/ip/service/disable www-ssl

# 2. Выпускаем сертификаты на нужные домены
/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=cloud.example.com,pihole.example.com

# 3. Включаем прокси (укажите точное имя вашего сертификата из /certificate print)
/ip/service/set reverse-proxy port=443 certificate=letsencrypt_cloud.example.com disabled=no

# 4. Прописываем правила перенаправления трафика в LAN
/ip/reverse-proxy/add sni=cloud.example.com ip-address=192.168.88.10 port=80
/ip/reverse-proxy/add sni=pihole.example.com ip-address=192.168.88.20 port=80

# 5. Разрешаем входящий HTTPS-трафик на роутер из интернета
/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=443 in-interface-list=WAN comment="Allow HTTPS reverse-proxy"

# 6. Настраиваем Split-Brain DNS для работы внутри Wi-Fi/LAN сети
/ip/dns/static/add name=cloud.example.com address=192.168.88.1
/ip/dns/static/add name=pihole.example.com address=192.168.88.1