VLESS Reality на OpenWrt: прозрачный прокси-шлюз для всей домашней сети

Зачем проксировать трафик на роутере, а не на каждом устройстве

Когда в доме больше двух-трёх устройств, установка VPN-клиента на каждое из них превращается в источник постоянных проблем. Smart TV, игровые консоли и IoT-устройства часто не поддерживают современные протоколы вроде VLESS, а на мобильных клиент может незаметно отключиться, оставляя трафик незащищённым. Кроме того, постоянный туннель на смартфоне заметно расходует батарею.

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

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

Выбор роутера: требования к железу и подводные камни

Не каждый роутер способен выполнять функции прокси-шлюза. Минимальные требования включают поддержку OpenWrt, достаточный объём оперативной памяти и производительный процессор. Xray-core написан на Go и потребляет около 100 МБ физической памяти, плюс geodata занимает примерно 85 МБ в tmpfs. Поэтому роутеры с 128 МБ RAM не подходят — минимум 256 МБ, комфортно 512 МБ.

Процессор также важен: ARM Cortex-A53 или мощнее справляется с шифрованием без заметных задержек, тогда как старые MIPS-роутеры с частотой около 580 МГц будут задыхаться. Хорошим выбором считается Cudy TR3000 v1 с SoC MediaTek Filogic MT7981B, 496 МБ DDR4 и двухъядерным Cortex-A53. Такой роутер обеспечивает запас производительности и поддерживает Wi-Fi 6.

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

Прошивка OpenWrt: пошаговый процесс и особенности

Прошивка OpenWrt на Cudy TR3000 выполняется в два этапа. Сначала из стоковой прошивки через веб-интерфейс загружается bin-файл промежуточной прошивки (intermediate firmware). После перезагрузки появляется LuCI от промежуточной версии OpenWrt, через который выполняется sysupgrade на финальную версию, например 25.12.2.

После прошивки доступ по SSH: ssh root@192.168.1.1. Важно учитывать, что начиная с OpenWrt ~25.x пакетный менеджер заменён с opkg на apk. Команды установки отличаются: apk update и apk add. Для работы прокси-шлюза потребуются пакеты: xray-core, kmod-nf-tproxy, kmod-nft-tproxy, kmod-nft-core, kmod-nft-nat, kmod-nft-fib, nftables-json и curl.

Каждый пакет выполняет свою функцию: xray-core — сам прокси-сервер, модули ядра обеспечивают работу TPROXY в netfilter/nftables, nftables-json нужен для управления правилами, а curl — для скачивания geodata и обновления подписок.

Архитектура решения: как всё работает вместе

Схема работы прокси-шлюза выглядит следующим образом. Устройство в локальной сети отправляет TCP-запрос к удалённому ресурсу. Роутер перехватывает этот трафик через nftables с TPROXY и направляет его в Xray на порт 12345. Xray анализирует трафик, определяет, нужно ли проксировать соединение, и принимает решение: либо отправить напрямую (для российских сайтов и локальных ресурсов), либо через VLESS+Reality-туннель.

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

Ключевое преимущество такой архитектуры — прозрачность для клиентских устройств. Они не знают о существовании прокси и продолжают работать как обычно, а весь трафик автоматически маршрутизируется согласно правилам.

Почему VLESS + Reality + XTLS-Vision: разбор технологий

VLESS — это легковесный прокси-протокол, наследник VMess из экосистемы V2Ray. Его главное отличие — отсутствие собственного шифрования: вся криптография делегируется TLS. Это снижает оверхед и упрощает протокол.

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

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

TPROXY против REDIRECT: почему выбор в пользу TPROXY

Существует два основных способа перехвата трафика на роутере: REDIRECT (DNAT) и TPROXY. REDIRECT подменяет адрес назначения на 127.0.0.1:порт, из-за чего оригинальный адрес теряется. Прокси вынужден восстанавливать его из заголовков протокола — HTTP Host или TLS SNI. Для чистого TCP без HTTP/TLS это невозможно.

TPROXY (Transparent Proxy) передаёт пакет приложению с сохранением оригинального IP назначения. Xray видит реальный адрес, куда клиент хотел подключиться, что критически важно для корректной маршрутизации. TPROXY сложнее в настройке — требуются модули ядра, policy routing и специальные правила nftables, — но он надёжнее и работает с любым TCP-трафиком.

В конфигурации Xray для TPROXY используется протокол dokodemo-door с параметрами followRedirect: true и tproxy: "tproxy". Это позволяет принимать перенаправленный трафик и сохранять оригинальный адрес назначения.

Настройка сети: PPPoE, MTU и DNS

Для полного контроля над трафиком роутер должен быть первым хопом в сети. Провайдерский оптический терминал переводится в режим моста (bridge), а PPPoE-сессию поднимает сам роутер. Это гарантирует, что весь трафик проходит через прокси-шлюз.

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

Такая топология обеспечивает стабильность и предсказуемость: роутер контролирует все соединения, а DNS-запросы шифруются через DoH, что предотвращает утечки и подмену.

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

Конфигурация Xray состоит из нескольких секций. Inbound — это «дверь куда угодно» (dokodemo-door), которая принимает перенаправленный трафик через TPROXY. Важные параметры: followRedirect: true для использования оригинального адреса назначения, sniffing с destOverride: ["http", "tls"] для извлечения домена из SNI или Host, и routeOnly: true, чтобы использовать домен только для маршрутизации, не подменяя адрес соединения.

Outbounds включают три типа: прокси-серверы VLESS+Reality, direct (протокол freedom) для прямых соединений и block (blackhole) для дропа трафика. Для прокси-сервера указываются адрес, порт, UUID, flow xtls-rprx-vision, а также параметры Reality: serverName, publicKey, fingerprint и shortId.

Маршрутизация строится на основе GeoIP и geosite. Например, трафик к российским доменам и IP-адресам идёт напрямую, а всё остальное — через прокси. Это позволяет оптимизировать скорость и обходить блокировки только там, где это необходимо.

Балансировка нагрузки и автоматическое восстановление

Для обеспечения отказоустойчивости Xray поддерживает пул из нескольких прокси-серверов. Используется механизм Observatory, который каждые 120 секунд проверяет доступность серверов, отправляя HTTP-запрос к контрольному URL (например, cp.cloudflare.com). Мёртвые серверы автоматически исключаются из ротации.

Балансировка нагрузки может быть настроена по принципу leastPing — выбирается сервер с наименьшей задержкой. Это особенно полезно при использовании 5–10 серверов от разных провайдеров.

Для автоматического восстановления после сбоев используются procd, watchdog и hotplug. Эти механизмы перезапускают Xray при падении процесса, восстанавливают правила nftables после перезагрузки и обеспечивают стабильную работу в течение недель без вмешательства.

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

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

При выборе роутера обращайте внимание не только на характеристики, но и на ревизию Flash-памяти. Проверяйте серийный номер и актуальность прошивки. Для Cudy TR3000 v1 с новым чипом ESMT F50L1G41LC требуется промежуточная прошивка, иначе устройство может выйти из строя.

Рекомендуется регулярно обновлять geodata и подписки серверов. В статье упоминается обновление списка серверов каждые 30 минут, что позволяет быстро реагировать на изменения. Также стоит настроить резервное копирование конфигурации, чтобы при сбое можно было быстро восстановить работоспособность.

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