Cudy TR3000 и VLESS: настройка прозрачного прокси-шлюза на OpenWrt

Зачем нужен прокси-шлюз на роутере, а не на каждом устройстве

Когда в доме несколько устройств — ноутбуки, смартфоны, Smart TV, игровые консоли, умные колонки — установка VPN-клиента на каждое из них превращается в источник постоянных проблем. Smart TV и IoT-устройства часто вообще не поддерживают современные протоколы вроде VLESS: на телевизоре Samsung не найти клиент для этого протокола, а на колонке с закрытой ОС его не установить в принципе. Даже там, где клиент есть, он может «молча» отключиться — например, после обновления приложения или смены сети, и трафик начнёт уходить напрямую, без шифрования, а пользователь этого не заметит. На мобильных устройствах постоянно работающий VPN-клиент заметно расходует батарею, поскольку обработка пакетов идёт в userspace и не даёт процессору уходить в глубокий сон.

Прокси-шлюз на роутере решает все эти задачи централизованно: любое устройство, подключённое к Wi-Fi или по кабелю, автоматически получает защищённый канал, ничего не зная о нём. Для клиентов роутер выглядит обычным интернет-шлюзом, поэтому не требуется установка или настройка дополнительного ПО. Обновление конфигурации происходит в одном месте, а не на полутора десятках устройств. Плата за такое удобство — более сложная первоначальная настройка, но она окупается, если устройств больше двух-трёх.

Ключевой сценарий, ради которого стоит строить такой шлюз, — прозрачный доступ к собственной удалённой инфраструктуре: тестовым серверам, частному Git, личным сервисам. Но схема подходит и для защиты трафика к внешним ресурсам, если вы используете собственный или арендованный VLESS-сервер.

Почему Cudy TR3000 — подходящее железо для такой задачи

Не каждый роутер способен выполнять функции прокси-шлюза. Требования жёсткие: во-первых, нужна поддержка OpenWrt — без неё невозможно установить Xray и настроить прозрачное проксирование. Во-вторых, Xray-core написан на Go и потребляет около 100 МБ физической памяти, плюс geodata для маршрутизации занимает ещё примерно 85 МБ в tmpfs. Роутеры с 128 МБ RAM не справятся, минимум — 256 МБ, комфортно — 512 МБ. В-третьих, процессор должен справляться с шифрованием: ARM Cortex-A53 или мощнее, тогда как старые MIPS-роутеры с частотой 580 МГц будут «задыхаться».

Cudy TR3000 v1 соответствует этим требованиям. Внутри — SoC MediaTek MT7981B (Filogic) с двухъядерным ARM Cortex-A53 на 1,3 ГГц, 496 МБ DDR4 RAM и 128 МБ NAND-флеш. Из портов: один 2.5GbE WAN, три 1GbE LAN, плюс Wi-Fi 6 в двух диапазонах (2,4 ГГц и 5 ГГц) с суммарной скоростью до 2402 Мбит/с на 5 ГГц и 574 Мбит/с на 2,4 ГГц. Есть порт USB 3.0 и питание через USB-C (5 В, 3 А), что делает роутер удобным для поездок — его можно запитать от пауэрбанка. Вес устройства — всего 160 граммов.

Полугигабайта RAM хватает с запасом для Xray и дополнительных сервисов вроде AdGuard Home, а два ядра A53 справляются с шифрованием без заметных тормозов. Порт 2.5GbE на WAN пригодится, если провайдер предоставит тариф выше гигабита. Производитель заявляет поддержку подключения более 70 устройств одновременно — для домашней сети более чем достаточно.

Подводный камень: ревизии NAND-флеша и совместимость с OpenWrt

При покупке Cudy TR3000 v1 важно обратить внимание на серийный номер. Роутеры с серийниками от 2544 и выше (примерно с ноября 2025 года) оснащаются новым чипом NAND-флеша — ESMT F50L1G41LC. Старые образы OpenWrt на таких устройствах не загружаются, и попытка прошить их напрямую может превратить роутер в «кирпич». Поддержка нового флеша появилась только в OpenWrt 24.10.5 и новее.

Для прошивки таких ревизий требуется специальная промежуточная прошивка (intermediate firmware) от Cudy — ZIP-архив с датой 20251118 на странице загрузок. Процесс двухэтапный: сначала из стоковой прошивки Cudy через веб-интерфейс (Firmware Upgrade) загружается bin-файл из этого архива. После перезагрузки появляется LuCI от промежуточной OpenWrt, через которую уже выполняется sysupgrade на финальную версию OpenWrt — например, 25.12.2. Без промежуточной прошивки на новых ревизиях роутер не загрузится, поэтому этот шаг критичен.

Если у вас роутер со старым серийным номером, можно прошиваться обычным способом. Но в любом случае стоит проверить актуальную версию OpenWrt на официальном сайте и следовать инструкции для конкретной модели.

Установка OpenWrt и базовых пакетов: от стока до рабочей системы

После прошивки OpenWrt на Cudy TR3000 вы получаете доступ по SSH: ssh root@192.168.1.1. Система работает на платформе mediatek/filogic, архитектура aarch64_cortex-a53. Важная деталь: начиная с OpenWrt ~25.x пакетный менеджер — apk, а не opkg, поэтому команды установки отличаются.

Для работы прокси-шлюза понадобятся следующие пакеты:

apk update
apk add xray-core kmod-nft-tproxy kmod-nf-tproxy nftables-json curl

Что зачем:

• xray-core — сам Xray, реализующий VLESS, Reality, маршрутизацию и Observatory.
• kmod-nf-tproxy и kmod-nft-tproxy — модули ядра для поддержки TPROXY в netfilter/nftables.
• kmod-nft-fib — модуль для FIB lookup, необходимый для policy routing в nftables (часто ставится автоматически, но лучше проверить).
• nftables-json — утилита nft с поддержкой JSON-вывода, удобная для отладки.
• curl — для скачивания geodata и обновления списка серверов из подписки.

Дополнительно может потребоваться kmod-nft-core, kmod-nft-nat — они обычно устанавливаются как зависимости, но при ручной сборке их стоит добавить явно.

Важно: после установки пакетов нужно перезагрузить роутер, чтобы модули ядра загрузились корректно.

Архитектура решения: TPROXY, Xray, AdGuard Home и сплит-роутинг

Прозрачный прокси-шлюз строится вокруг трёх ключевых компонентов: nftables с TPROXY для перехвата трафика, Xray для обработки и маршрутизации, и AdGuard Home для шифрования DNS. Схема работы выглядит так: устройство в локальной сети (ноутбук, телефон, ТВ) отправляет TCP-запрос к удалённому ресурсу. Роутер через nftables (TPROXY) перехватывает этот трафик с интерфейса br-lan и направляет его на порт 12345, где слушает Xray. Xray анализирует запрос, определяет destination с помощью sniffing, и принимает решение: если домен или IP входит в список прямых подключений (например, российские ресурсы по GeoIP), трафик идёт напрямую; в противном случае — через защищённый канал VLESS+Reality.

Параллельно DNS-запросы устройств (UDP 53) перехватываются AdGuard Home, который резолвит их через DNS-over-HTTPS (DoH) к проверенным серверам (Cloudflare, Google, Quad9) и дополнительно фильтрует рекламу и трекеры. HTTPS-трафик к DNS-серверам сам проходит через TPROXY и уходит через защищённый канал, так что ни один plaintext DNS-запрос не покидает роутер.

Почему TPROXY, а не REDIRECT? REDIRECT (DNAT) подменяет адрес назначения на 127.0.0.1, из-за чего оригинальный адрес теряется, и прокси вынужден восстанавливать его из заголовков HTTP или TLS SNI — для чистого TCP без этих заголовков это невозможно. TPROXY передаёт пакет приложению с сохранением оригинального IP назначения, поэтому Xray точно знает, куда клиент хотел подключиться. TPROXY сложнее в настройке (нужны модули ядра, policy routing, специальные правила nftables), но он надёжнее и работает с любым TCP-трафиком.

Стек протоколов: VLESS, Reality и XTLS-Vision — как это работает

Связка VLESS + Reality + XTLS-Vision — современный стандарт для производительных прокси. VLESS — это легковесный прокси-протокол, наследник VMess из экосистемы V2Ray, но без собственного шифрования: вся криптография делегируется TLS. Это снижает оверхед и упрощает реализацию.

Reality — технология установления TLS-соединения без собственного сертификата на стороне прокси-сервера. Вместо того чтобы покупать и настраивать сертификат для своего домена, сервер при TLS-хендшейке предъявляет клиенту сертификат выбранного публичного ресурса (через SNI). Аутентификация клиента выполняется через криптографическую пару (publicKey/shortId), что даёт корректный TLS-хендшейк без накладных расходов на управление сертификатами. Это также маскирует трафик под обычное посещение популярного сайта.

XTLS-Vision — оптимизация, при которой Xray «проваливает» внутренний TLS прямо во внешний TLS без двойного шифрования. Когда вы подключаетесь к HTTPS-сайту через VLESS+Reality, данные шифруются только один раз, а не дважды, как в классических прокси поверх TLS. Результат — почти нативная скорость, что особенно заметно на каналах с высокой пропускной способностью.

Транспорт в такой схеме — чистый TCP, без WebSocket или gRPC. TCP даёт минимальную задержку и не добавляет лишних заголовков. Однако важно понимать ограничение: текущая схема проксирует только TCP. UDP-трафик через TPROXY не проходит и идёт напрямую, за исключением DNS, который закрыт на уровне AdGuard Home + DoH. Это осознанное архитектурное решение, и для UDP-приложений (например, некоторые игры или видеозвонки) может потребоваться отдельная настройка.

Конфигурация Xray: разбор inbound, outbound и маршрутизации

Конфигурация Xray для прозрачного прокси-шлюза состоит из нескольких секций. Начнём с inbound — «двери», через которую приходит перенаправленный трафик.

Inbound использует протокол dokodemo-door — специальный режим Xray для приёма прозрачно перенаправленных пакетов. Ключевые параметры:

{
  "tag": "tproxy-in",
  "port": 12345,
  "protocol": "dokodemo-door",
  "settings": {
    "network": "tcp",
    "followRedirect": true
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  },
  "streamSettings": {
    "sockopt": {
      "tproxy": "tproxy"
    }
  }
}

• followRedirect: true — использовать оригинальный адрес назначения из пакета (восстановленный TPROXY).
• sniffing с destOverride: ["http", "tls"] — критически важно: Xray анализирует первые байты соединения, для TLS извлекает домен из SNI, для HTTP — из заголовка Host. Это позволяет маршрутизировать по доменам (geosite), а не только по IP.
• routeOnly: true — ключевой нюанс: без этого флага sniffing не только извлекает домен, но и подменяет адрес назначения в соединении, что ломает некоторые сценарии. С routeOnly: true домен используется только для принятия решения о маршрутизации, а соединение устанавливается по оригинальному адресу.
• tproxy: "tproxy" — включает режим TPROXY, сохраняющий оригинальный IP назначения.

Outbounds — это список исходящих соединений. Обычно их три типа:

1. Прокси-серверы VLESS+Reality — с параметрами address, port, id (UUID), flow: "xtls-rprx-vision", encryption: "none", а также streamSettings с security: "reality", где указываются serverName (SNI), publicKey, fingerprint: "chrome" и shortId.
2. Direct — для трафика, который должен идти напрямую.
3. Blackhole — для блокировки нежелательного трафика.

Маршрутизация (routing) определяет, какой трафик направить в какой outbound. Обычно используются правила:

• Если destination — домен из списка geosite (например, geosite:category-ru), или IP из geoip (например, geoip:ru) — direct.
• Весь остальной TCP — через proxy.

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

"routing": {
  "rules": [
    {
      "type": "field",
      "outboundTag": "direct",
      "domain": ["geosite:category-ru"]
    },
    {
      "type": "field",
      "outboundTag": "direct",
      "ip": ["geoip:ru"]
    },
    {
      "type": "field",
      "outboundTag": "proxy-1"
    }
  ]
}

Важно: geodata (файлы geosite.dat и geoip.dat) нужно скачать и разместить в доступном для Xray месте, обычно в /usr/share/xray/. Их можно обновлять автоматически по расписанию.

Настройка сети: PPPoE, MTU и особенности топологии

Для полноценного контроля над трафиком важно, чтобы роутер был первым хопом в сети. В примере с Cudy TR3000 используется следующая топология: провайдерский оптический терминал переведён в режим моста (bridge), а PPPoE-сессию поднимает сам роутер. Это даёт роутеру полный контроль над WAN-интерфейсом.

При PPPoE MTU уменьшается до 1480 байт (1500 − 8 байт PPP − 12 байт PPPoE). В nftables OpenWrt автоматически настраивает MSS clamping для корректной работы TCP, поэтому проблем с фрагментацией обычно не возникает. DNS-серверы провайдера, полученные по PPPoE, не используются — вместо них задаются Cloudflare (1.1.1.1) и Google (8.8.8.8) как вышестоящие для AdGuard Home.

Если у вас нет PPPoE (например, просто динамический IP от провайдера), настройка упрощается: WAN-порт работает в режиме DHCP, и MTU остаётся стандартным 1500. В любом случае важно, чтобы роутер выполнял NAT и был единственным шлюзом для клиентов локальной сети.

Для работы TPROXY необходима настройка policy routing. В nftables создаются правила, которые перехватывают TCP-трафик с интерфейса br-lan (кроме трафика, идущего на сам роутер) и направляют его на порт 12345. Также нужно добавить правило для UDP-трафика на порт 53, чтобы перенаправлять DNS-запросы в AdGuard Home.

Пример фрагмента nftables для TPROXY:

nft add rule inet fw4 mangle prerouting meta mark 0x1 tproxy to 127.0.0.1:12345 meta mark set 0x1

Но полная настройка требует создания отдельной таблицы, цепочек и policy routing через ip rule. Рекомендуется использовать скрипты или готовые конфигурации, которые можно адаптировать под свою сеть.

Шифрование DNS и фильтрация рекламы: AdGuard Home + DoH

Безопасный DNS — неотъемлемая часть защищённого интернета. Если DNS-запросы уходят в открытом виде, провайдер или злоумышленник может видеть, какие сайты вы посещаете, даже если сам трафик зашифрован. В рассматриваемой схеме эту проблему решает AdGuard Home, установленный на роутере.

AdGuard Home принимает DNS-запросы от устройств локальной сети на порту 53, резолвит их через DNS-over-HTTPS (DoH) к надёжным серверам — Cloudflare, Google, Quad9. Последний известен тем, что не ведёт журналов. Важно, что HTTPS-трафик к DNS-серверам сам проходит через TPROXY и уходит через защищённый канал VLESS+Reality, поэтому даже факт обращения к DNS-резолверу скрыт от посторонних.

Дополнительный бонус AdGuard Home — фильтрация рекламы и трекеров на уровне DNS. Это ускоряет загрузку страниц, экономит трафик и повышает конфиденциальность. Списки фильтров можно настраивать, добавляя свои правила или подключая готовые списки.

Настройка AdGuard Home включает:

• Установку пакета (в OpenWrt доступен как adguardhome).
• Настройку слушателя на порту 53 (или 5353, если порт занят).
• Указание вышестоящих DNS-серверов с DoH.
• Настройку nftables для перенаправления UDP-порта 53 с устройств на AdGuard Home.

После настройки важно проверить, что DNS-запросы действительно уходят через DoH, например, с помощью логов AdGuard Home или тестовых сервисов.

Автоматизация, отказоустойчивость и ограничения схемы

Прокси-шлюз на роутере должен работать стабильно неделями без перезагрузки. Для этого используются механизмы OpenWrt: procd, watchdog и hotplug. Например, можно настроить автоматический перезапуск Xray при сбое, а также обновление списка серверов из подписки каждые 30 минут.

Балансировка нагрузки между несколькими серверами достигается через встроенный механизм Observatory в Xray: он отслеживает доступность серверов и выбирает самый быстрый. В конфигурации можно указать несколько outbounds с тегами и настроить fallback.

Важно понимать ограничения схемы. Главное — проксируется только TCP. UDP-трафик (кроме DNS) идёт напрямую, что может быть проблемой для некоторых приложений: онлайн-игр, видеозвонков (если они используют UDP), VoIP. Для полного покрытия потребуется дополнительная настройка, например, через TUN-интерфейс или использование Xray в режиме full tunnel, но это выходит за рамки базовой схемы.

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

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

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