Настройка VLESS-клиента на MikroTik через контейнеры: Xray, Tun2Socks и маршрутизация

Зачем нужен VLESS-клиент на MikroTik

Современные протоколы VPN, такие как OpenVPN и WireGuard, всё чаще сталкиваются с деградацией скорости и блокировками со стороны провайдеров, особенно в регионах с активным DPI. VLESS с технологией Reality стал популярным решением благодаря своей способности маскировать трафик под обычные HTTPS-запросы, что делает его практически невидимым для систем анализа. Установка VLESS-клиента непосредственно на роутер MikroTik даёт несколько ключевых преимуществ.

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

Однако стоит учитывать, что нативная поддержка VLESS в RouterOS отсутствует, поэтому основным способом является использование контейнеров (Container), доступных на устройствах с архитектурой ARM, ARM64 или x86 и версией RouterOS 7.x. Это накладывает определённые требования к аппаратному обеспечению, но при правильной настройке результат оправдывает усилия.

Подготовка оборудования и RouterOS

Перед началом настройки необходимо убедиться, что ваше устройство соответствует минимальным требованиям. Для работы с контейнерами потребуется RouterOS версии 7.15 или выше, так как в более ранних версиях исправлены критические ошибки, связанные с маршрутизацией и управлением контейнерами. Архитектура процессора должна быть ARM, ARM64 или x86 — старые модели на MIPSBE, такие как hAP ac2, не поддерживают контейнеры, хотя для них существуют альтернативные методы.

Для моделей с ограниченным объёмом встроенной памяти (например, hAP ac3) обязательно наличие USB-накопителя, на котором будут храниться образы контейнеров и их данные. Рекомендуется использовать USB-флешку с достаточной скоростью чтения/записи, чтобы избежать задержек при запуске. Также понадобится VLESS-ключ от вашего сервера: UUID, адрес сервера, порт, SNI и ShortID — эти данные обычно предоставляются при покупке или настройке VPS с панелью 3X-UI.

Активация режима Container выполняется через терминал командой /system/device-mode/update container=yes, после чего требуется физическое подтверждение: выключите роутер, зажмите кнопку Reset, включите питание и отпустите кнопку при мигании светодиода. После перезагрузки в меню появится раздел Container, и можно приступать к созданию виртуальных интерфейсов.

Создание виртуальных интерфейсов и моста

Для работы контейнеров необходимо создать отдельную сеть, изолированную от основной LAN. В примерах из форумов используется мост Dockers с подсетью 10.6.0.0/24, к которому подключаются виртуальные интерфейсы veth для каждого контейнера. Типичная конфигурация включает три контейнера: AdguardHome (DNS-фильтрация), Xray-core (VLESS-клиент) и Tun2Socks (преобразование SOCKS5 в TUN-интерфейс).

Команды для создания моста и veth-интерфейсов выглядят следующим образом:

/interface bridge add name=Dockers port-cost-mode=short
/interface veth add address=10.6.0.2/24 gateway=10.6.0.1 name=VETH1-adguard
/interface veth add address=10.6.0.3/24 gateway=10.6.0.1 name=VETH2-xray
/interface veth add address=10.6.0.4/24 gateway=10.6.0.1 name=VETH3-tun
/interface bridge port add bridge=Dockers interface=VETH1-adguard
/interface bridge port add bridge=Dockers interface=VETH2-xray
/interface bridge port add bridge=Dockers interface=VETH3-tun

Важно назначить адрес мосту (например, 10.6.0.1/24) и добавить его в список интерфейсов LAN, чтобы контейнеры могли общаться с внешним миром через NAT. Также необходимо настроить DHCP-сервер для основной сети, указав в качестве DNS-сервера адрес AdguardHome (10.6.0.2), чтобы все устройства автоматически получали защищённый DNS.

Установка и настройка контейнера Xray-core

Xray-core — это основной компонент, который устанавливает VLESS-соединение с вашим VPS-сервером. Для MikroTik используется готовый образ, например teddysun/xray, который загружается из реестра контейнеров. После создания контейнера и его первого запуска необходимо остановить его и отредактировать файл config.json, в котором прописываются параметры подключения: адрес сервера, порт, UUID, SNI и другие настройки, включая fingerprint (рекомендуется chrome для маскировки под HTTPS).

Пример команды для создания контейнера:

/container add interface=VETH2-xray root-dir=usb1-part1/Containers/xray-core start-on-boot=yes workdir=/root dns=10.6.0.2

После редактирования конфига контейнер запускается, и Xray-core начинает слушать SOCKS5-порт (обычно 30804) на своём veth-интерфейсе. Проверить работоспособность можно, указав в настройках прокси на локальном компьютере socks5://10.6.0.3:30804 — если интернет открывается, значит, соединение с VPS установлено корректно. Важно помнить, что конфигурация Xray-core может меняться при обновлении образа, поэтому после апдейтов стоит проверять структуру config.json.

Роль Tun2Socks и его настройка

Tun2Socks — это утилита, которая преобразует SOCKS5-прокси в виртуальный TUN-интерфейс, позволяя маршрутизировать весь трафик через прокси на уровне IP. В контексте MikroTik это необходимо для того, чтобы направить трафик с локальных устройств в VLESS-туннель. Контейнер Tun2Socks создаётся аналогично Xray, но после первого запуска его нужно остановить и заменить файл entrypoint.sh на скрипт, который создаёт TUN-интерфейс и запускает tun2socks с указанием адреса SOCKS5-прокси (в нашем случае 10.6.0.3:30804).

Базовый скрипт выглядит так:

#!/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:30804 -interface eth0

Однако на практике могут возникать проблемы с инициализацией интерфейсов, особенно после перезагрузки роутера. Опытные пользователи рекомендуют добавить команды для перезапуска eth0 и tun0, чтобы стабилизировать работу:

sleep 2
ifconfig eth0 down
sleep 2
ifconfig eth0 up
ip tuntap add mode tun dev tun0
ip addr add 198.18.0.1/15 dev tun0
ip link set dev tun0 up
sleep 2
ifconfig tun0 down
sleep 2
ifconfig tun0 up

После запуска контейнера Tun2Socks должен появиться маршрут к сети 198.18.0.0/15, который будет использоваться для перенаправления трафика.

Маршрутизация трафика через Mangle и Policy Routing

Чтобы направить трафик с определённых устройств или на определённые сайты через VLESS-туннель, используется механизм policy routing на основе меток. В RouterOS это реализуется через правила 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

Далее создаётся правило Mangle, которое помечает пакеты, приходящие с устройств или адресов, которые должны идти через VPN. Например, для направления всего трафика с конкретного IP-адреса:

/ip firewall mangle add chain=prerouting src-address=192.168.1.100 action=mark-routing new-routing-mark=proxy_mark

Более гибкий подход — использование списка адресов route_proxy, в который можно добавлять домены или IP-адреса заблокированных ресурсов. Тогда правило Mangle будет выглядеть так:

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

Важно помнить, что трафик, помеченный для VPN, исключается из FastTrack, что увеличивает нагрузку на CPU. Поэтому рекомендуется включать в список только необходимые ресурсы, а не весь интернет.

Настройка NAT и DNS для корректной работы

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

/ip firewall nat add chain=srcnat out-interface-list=WANs src-address=10.6.0.0/24 action=masquerade
/ip firewall nat add chain=srcnat dst-address-list=route_proxy out-interface=Dockers action=masquerade

DNS-запросы от клиентов перенаправляются на AdguardHome с помощью правил dst-nat для порта 53:

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

Также рекомендуется настроить DoH (DNS over HTTPS) на самом роутере, чтобы провайдер не видел DNS-запросы. Для этого в разделе IP -> DNS укажите серверы 1.1.1.1 или 8.8.8.8 и включите use-doh-server с адресом Cloudflare или Google. Это повышает конфиденциальность и предотвращает подмену DNS.

Типичные проблемы и их решение

При настройке VLESS-клиента на MikroTik пользователи часто сталкиваются с рядом проблем. Одна из самых распространённых — отсутствие интернета при попытке направить трафик через туннель, хотя изнутри контейнеров всё работает. Причины могут быть в неправильной маршрутизации, ошибках в entrypoint.sh или конфликтах с rp-filter. Рекомендуется проверить настройки /ip/settings и при необходимости отключить rp-filter для интерфейсов Docker.

Другая частая проблема — нестабильная работа Tun2Socks после перезагрузки роутера. Как уже упоминалось, помогает добавление команд перезапуска интерфейсов в скрипт. Также стоит учитывать, что обновления образов контейнеров могут ломать совместимость, поэтому после обновления Xray-core или Tun2Socks нужно проверять конфигурацию.

Если скорость через VLESS ниже ожидаемой, это может быть связано с производительностью процессора роутера. На слабых моделях шифрование и инкапсуляция создают значительную нагрузку. В таких случаях рекомендуется использовать только выборочную маршрутизацию, а не весь трафик, или рассмотреть более мощное оборудование, например hAP ax3 или RB5001.

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

Для обеспечения стабильной и быстрой работы VLESS-туннеля на MikroTik следует придерживаться нескольких рекомендаций. Во-первых, используйте FastTrack только для трафика, который не идёт через VPN, чтобы снизить нагрузку на CPU. Во-вторых, настройте Kill Switch — правило firewall, которое блокирует интернет для устройств, если контейнер с VLESS остановился, предотвращая утечку реального IP.

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

/ip firewall filter add chain=forward src-address=192.168.1.100 out-interface=WAN action=reject

Также важно регулярно обновлять RouterOS и образы контейнеров, так как новые версии часто содержат исправления уязвимостей и улучшения производительности. При обновлении Xray-core следите за изменениями в структуре config.json, так как они могут потребовать корректировки.

Для дополнительной безопасности используйте DoH и убедитесь, что DNS-запросы не утекают через обычный DNS. AdguardHome может также блокировать рекламу и трекеры, что улучшает конфиденциальность. Наконец, храните конфигурационные файлы в примонтированных папках, чтобы они сохранялись при обновлении контейнера.

Альтернативные подходы и перспективы

Хотя контейнерный подход является основным для запуска VLESS на MikroTik, существуют и другие варианты. Некоторые пользователи экспериментируют с использованием sing-box вместо Xray-core, который объединяет несколько протоколов и может работать в режиме TUN напрямую. Однако такие решения требуют более глубоких знаний и часто менее стабильны.

Также стоит отметить, что RouterOS постоянно развивается, и в будущих версиях может появиться нативная поддержка VLESS или упрощённые механизмы для работы с прокси. Пока же контейнеры остаются наиболее гибким и надёжным способом.

При выборе оборудования для VLESS-туннеля обращайте внимание на производительность CPU и объём оперативной памяти. Модели с двухъядерными процессорами ARM, такие как hAP ax3, показывают хорошие результаты. Для более требовательных сценариев подойдут устройства линейки L009 или RB5001, которые обеспечивают достаточную мощность для шифрования на высоких скоростях.

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