VLESS на MikroTik: как поднять современный прокси-туннель через контейнеры

Зачем VLESS на роутере MikroTik и какие проблемы он решает

Современный протокол VLESS с транспортом Reality стал одним из самых устойчивых к блокировкам и DPI-анализу. В отличие от классических OpenVPN или WireGuard, его трафик невозможно отличить от обычного HTTPS-запроса, поэтому скорость не падает даже на перегруженных каналах, а соединение редко режется провайдером.

Если установить VLESS не на отдельном устройстве, а прямо на роутере MikroTik, это открывает несколько важных возможностей:

• вся домашняя сеть оказывается под защитой — не нужно настраивать каждый телефон, телевизор или ноутбук;
• вы получаете гибкую маршрутизацию: можно направить через туннель только нужные ресурсы, а остальной трафик оставить напрямую;
• роутер работает круглосуточно и автоматически восстанавливает соединение после сбоев;
• не нужно включать компьютер или отдельный VPN-бокс — всё живёт внутри сетевого оборудования.

Однако у MikroTik нет встроенной поддержки VLESS в меню Interface. Именно поэтому приходится использовать контейнеризацию, доступную в RouterOS 7. По сути, вы запускаете на роутере два миниатюрных Linux-контейнера: один работает как клиент VLESS, а второй превращает его в tun-интерфейс для маршрутизации всего трафика.

Требования к оборудованию: какие модели MikroTik подходят для контейнеров

Прежде чем начинать настройку, важно убедиться, что ваше устройство вообще способно поднять контейнеры. В отличие от стандартных функций RouterOS, поддержка Docker/Container появилась не на всех моделях.

Официально контейнеры работают на устройствах с архитектурой ARM, ARM64 или x86 и под управлением RouterOS 7. Практика показывает, что старые модели на MIPSBE (например, hAP lite или hAP mini) не имеют нужной архитектуры и недостаточно памяти — VLESS там не поднять.

Владельцы hAP ax2 и hAP ax3 успешно запускают связку Xray-core и tun2socks, но есть нюанс с флеш-памятью. Внутренний накопитель у этих моделей небольшой, и активная запись контейнеров может быстро его износить. Поэтому опытные пользователи рекомендуют обязательно использовать USB-накопитель. На hAP ax3 можно установить контейнеры на USB-флешку и не переживать о ресурсе. Для hAP ac2, который тоже поддерживает контейнеры при наличии USB-порта, это особенно актуально — один из пользователей сообщил, что его устройство вышло из строя через год после перехода на RouterOS 7 из-за износа встроенной флешки.

Также обратите внимание на производительность процессора. VLESS и tun2socks требуют определённой мощности для шифрования и маршрутизации. Если у вас слабое устройство, скорость через туннель может быть заметно ниже прямого подключения.

Подготовка RouterOS: активация контейнеров и создание виртуальной сети

Допустим, ваше оборудование подходит. Тогда первым шагом нужно включить режим Container в RouterOS. В версиях 7.x это делается командой /system/device-mode/update container=yes. После этого потребуется перезагрузка — некоторые модели просят физически подтвердить действие, удерживая кнопку Reset при включении до мигания светодиода. В итоге в меню появится раздел Container — значит, всё готово.

Дальше создаётся сеть, в которой будут жить контейнеры. Обычно используют отдельный bridge и виртуальные пары veth. Пример из практики:

• /interface bridge add name=Dockers port-cost-mode=short — создаётся мост для всех виртуальных интерфейсов;
• для каждого контейнера создаётся veth с уникальным адресом из подсети 10.6.0.0/24;
• затем veth добавляются в bridge.

Популярная схема — три контейнера: AdguardHome для DNS, Xray-core как клиент VLESS и Tun2Socks для маршрутизации. Но можно обойтись и двумя: Xray-core, если запустить его в режиме TUN, способен сам создавать виртуальный интерфейс.

Важно заранее задать адресацию: например, xray получает 10.6.0.3, tun2socks — 10.6.0.4, а сам bridge — 10.6.0.1/24. Эта сеть будет изолирована от основной LAN, но роутер сможет маршрутизировать между ними.

Выбор и настройка Xray-core: создание конфига для подключения к VLESS-серверу

Xray-core — это основной инструмент для работы с VLESS. Существуют готовые образы для контейнеров, например teddysun/xray. После того как контейнер с Xray запущен в первый раз, необходимо отредактировать файл config.json, в котором хранятся параметры подключения к вашему серверу.

Основные поля, которые нужно заполнить: UUID вашего ключа, адрес сервера, порт, а также параметры Reality — SNI, public key, shortId, fingerprint. Чтобы трафик выглядел как обычный HTTPS-запрос, в конфиге рекомендуется указывать fingerprint: "chrome" — именно такую настройку советуют на форумах и в инструкциях.

Примерная структура конфига (минимально):

{
  "inbounds": [{
    "port": 1080,
    "protocol": "socks",
    "settings": {
      "auth": "noauth"
    }
  }],
  "outbounds": [{
    "protocol": "vless",
    "settings": {
      "vnext": [{
        "address": "server.example.com",
        "port": 443,
        "users": [{
          "id": "UUID",
          "encryption": "none"
        }]
      }]
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality",
      "realitySettings": {
        "fingerprint": "chrome",
        "serverName": "www.microsoft.com",
        "publicKey": "...",
        "shortId": "..."
      }
    }
  }]
}

В этом примере Xray слушает порт 1080 как SOCKS-прокси внутри своей сети. Важно, чтобы контейнер имел доступ к этому порту для tun2socks. Сами настройки сервера вы должны получить от своего VPN-провайдера или с собственного VPS с панелью 3X-UI.

Tun2Socks: превращаем SOCKS5 в виртуальный сетевой интерфейс

Xray выдаёт SOCKS5-прокси, но роутеру удобнее направлять трафик в tun-интерфейс. Именно для этого нужен второй контейнер — Tun2Socks. Он создаёт внутри себя виртуальный адаптер tun0, забирает весь трафик и передаёт его в SOCKS5 от Xray.

При первом запуске контейнера Tun2Socks нужно заменить его entrypoint — файл запуска. Вручную прописываются команды, которые поднимают tun0, назначают ему адрес и маршруты:

#!/bin/sh
ip tuntap add mode tun dev tun0
ip addr add 198.18.0.1/15 dev tun0
ip link set dev tun0 up
ip route del default
ip route add default via 198.18.0.1 dev tun0 metric 1
ip route add default via 10.6.0.1 dev eth0 metric 10
tun2socks -device tun0 -proxy socks5://10.6.0.3:1080 -interface eth0

Здесь 10.6.0.3 — адрес контейнера Xray, а 1080 — порт его SOCKS-прокси. Контейнер Tun2Socks получает адрес 10.6.0.4, и именно этот адрес будет указан как шлюз для маршрутизации.

Некоторые пользователи столкнулись с тем, что после долгого простоя или обновления образа Tun2Socks переставал отвечать на пинги. Решение нашлось простое: перед поднятием интерфейсов нужно перезапустить eth0 и tun0. В entrypoint добавляются команды ifconfig eth0 down, ifconfig eth0 up, затем аналогично для tun0 — после этого связка снова работает стабильно.

Маршрутизация трафика через VLESS: Mangle, Routing Tables и NAT

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

Сначала создаётся таблица маршрутов, например proxy_mark:

/routing table add disabled=no fib name=proxy_mark

Затем в таблицу добавляется маршрут по умолчанию через адрес контейнера Tun2Socks (10.6.0.4):

/ip route add dst-address=0.0.0.0/0 gateway=10.6.0.4 routing-table=proxy_mark

Теперь нужно пометить трафик, который должен пойти через этот маршрут. В цепочке prerouting создаётся правило mark-routing, которое присваивает нужным пакетам марку proxy_mark. Обычно для этого используют address-list с адресами сайтов, которые должны открываться через VPN. Например:

/ip firewall mangle add chain=prerouting dst-address-list=route_proxy action=mark-routing new-routing-mark=proxy_mark passthrough=yes

Не забудьте про NAT. Для того чтобы устройства из локальной сети могли общаться с контейнером, нужно правило masquerade для подсети 10.6.0.0/24. А если вы хотите, чтобы весь интернет-трафик с определённых устройств уходил в туннель, можно маркировать его по src-address.

Важно: если трафик попадает в Mangle, он исключается из FastTrack. FastTrack — это аппаратное ускорение, и его отключение для части трафика увеличивает нагрузку на процессор. Поэтому не стоит отправлять через VLESS абсолютно весь трафик, если у вас слабое железо — лучше выделить только список нужных доменов или IP.

Настройка DNS: DoH и AdGuard Home для защиты запросов

VLESS шифрует ваш интернет-трафик, но DNS-запросы при стандартной настройке могут уходить напрямую провайдеру, который увидит, какие сайты вы пытаетесь открыть. Чтобы избежать этого, нужно настроить безопасный DNS.

В RouterOS можно включить DoH (DNS over HTTPS) прямо в меню IP → DNS. Укажите серверы Cloudflare (1.1.1.1) или Google (8.8.8.8) и включите DoH-запросы. Это зашифрует DNS-запросы от роутера к резолверу.

Ещё один популярный вариант — использовать контейнер с AdGuard Home. Он работает как локальный DNS-сервер, который не только кэширует ответы, но и фильтрует рекламу и трекеры. В описанной выше схеме AdGuard Home подключается к bridge, и роутер перенаправляет все DNS-запросы (порт 53) с локальной сети на этот контейнер через dst-nat.

Пример правила:

/ip firewall nat add chain=dstnat dst-port=53 protocol=udp in-interface=Bridge action=dst-nat to-addresses=10.6.0.2

Это гарантирует, что даже если какое-то устройство жёстко прописало DNS 8.8.8.8, запрос всё равно уйдёт в AdGuard Home. А чтобы сервер не видел ваши DNS-запросы, сам AdGuard Home следует настроить на использование DoH или DoT.

Оптимизация, безопасность и уход за оборудованием

Когда связка VLESS-MikroTik заработала, стоит позаботиться о её стабильности и безопасности.

Kill Switch. Если контейнер с VLESS остановится, все устройства, которые должны были идти через него, могут начать выходить в интернет напрямую, раскрывая ваш реальный IP. Чтобы этого избежать, создайте правило firewall, которое блокирует такой «голый» трафик. Например, если вы маркируете устройства по src-address-list, можно добавить правило drop для этой же list, если контейнер недоступен.

Ограничение нагрузки. Как уже упоминалось, трафик, идущий через Mangle, не участвует в FastTrack. Это значит, что каждый пакет обрабатывается центральным процессором. Если ваш MikroTik не оснащён мощным CPU, скорость может проседать. Рекомендуется использовать address-list только для доменов, которым действительно нужен VPN, а не для всего подряд.

Обновление контейнеров. Xray и Tun2Socks развиваются, выходят новые версии. При обновлении образа обычно сохраняется примонтированный файл config.json или entrypoint.sh, но иногда меняется структура конфигурации. После обновления всегда проверяйте, что соединение устанавливается, и при необходимости корректируйте настройки.

Износ флеш-памяти. Это реальная проблема, особенно на моделях без USB-порта. Контейнеры постоянно пишут данные в файловую систему, и встроенный накопитель может выйти из строя. Рекомендуется по возможности использовать внешний USB-накопитель и следить за свободным местом. Если роутер начал сбрасывать конфигурацию после перезагрузки или выдаёт ошибки записи — это тревожный звонок.

Мониторинг. Проверяйте статус контейнеров через /container/print. Если контейнер с Tun2Socks перестал отвечать, может помочь перезапуск его интерфейсов, как в рецепте с ifconfig down/up.

Типичные ошибки и способы их решения

Даже при аккуратном следовании инструкции встречаются проблемы. Вот несколько ситуаций, описанных пользователями.

Контейнер Xray запускается и сразу останавливается. Чаще всего это означает ошибку в config.json. Проверьте, правильно ли вы экранировали спецсимволы и пути. Иногда помогает запустить контейнер с подключением к терминалу и посмотреть логи: /container/print detail и /log print where topics~"container".

Tun2Socks не пропускает трафик. Симптом: внутри контейнера интернет работает, но пакеты с локальных устройств не возвращаются. Вероятно, неправильно настроен маршрут по умолчанию. Проверьте, что в entrypoint указаны оба маршрута — через tun0 и через eth0, и что они не конфликтуют. Также причиной может быть отсутствие NAT для подсети контейнеров.

Маршрутизация работает, но скорость низкая. Если вы направили весь трафик локальной сети через VLESS, CPU может не справляться. Включите аппаратную маршрутизацию для того трафика, который идёт напрямую, а для VPN-трафика создайте более узкий список адресов.

Контейнеры перестали работать после долгого простоя. Такое случается при использовании устаревших образов. Попробуйте обновить образы до актуальных версий или перезаписать entrypoint с учётом изменений в самом образе.

Бесплатные ключи и сервисы: можно ли протестировать VLESS без своего сервера

Если у вас ещё нет собственного VLESS-сервера, вы можете протестировать работу связки на временном ключе. Некоторые сервисы предоставляют бесплатные VLESS-ключи на несколько дней, чтобы пользователи могли оценить стабильность протокола.

Обычно такой ключ содержит все необходимые параметры: UUID, адрес сервера, порт, SNI, publicKey и shortId. Эти данные вставляются в конфиг Xray, и после запуска контейнера у вас появляется рабочий туннель.

Важно учитывать, что бесплатные ключи часто имеют ограничение по скорости или трафику, поэтому для постоянного использования лучше арендовать VPS и установить на него панель 3X-UI. Схема настройки клиента будет точно такой же, независимо от того, кто предоставляет сервер — протокол VLESS остаётся единым стандартом.

Вопросы и ответы