Netcraze Hopper 4G+ VLESS XKeen setup

Настройка Netcraze Hopper 4G+ (Keenetic/KeeneticOS) для VLESS через XKeen с разделением трафика

Задача: настроить роутер Netcraze Hopper 4G+ (Keenetic/KeeneticOS) для подключения к собственному серверу по протоколу VLESS (3X-UI) с разделением трафика — российские сайты напрямую, остальной трафик через защищённое соединение, — включая расширение памяти через OPKG/Entware и интеграцию с XKeen.

Решение: развёрнут Entware на внешнем накопителе, установлен XKeen (Xray-core) с автоматическим разделением трафика по гео-базам (Re:filter/v2fly/ZKeen), настроено управление через штатные политики доступа веб-интерфейса роутера, устранена утечка через IPv6. По факту эксплуатации в условиях мобильного аплинка потребовался дополнительный внешний слой (WireGuard) и ограничение проксируемых портов — оба пункта описаны отдельно ниже, по опыту реальной работы, а не только по кабинетной настройке.

Авторы: проблему решали Виталий Бурков и Claude (Anthropic) — в качестве технического консультанта и соавтора пошаговой диагностики.

Проверено на: Netcraze Hopper 4G+ (NC-2312, AArch64), KeeneticOS 5.1.1

📌 Результат (кратко, для тех, кто не хочет читать всё)

- Флешка → Entware → XKeen (Xray-core) → рабочий VLESS-туннель к своему серверу.
- Split-tunneling по гео-принципу: RU-адреса напрямую, остальное — через сервер, с kill-switch на случай обрыва.
- IPv6 отключён, чтобы не «протекал» реальный IP.
- Управление, кто из устройств ходит через туннель — прямо в штатном веб-интерфейсе роутера, через политику доступа “xkeen“.
- Шифрование сейчас базовое (“security: none“, без TLS/Reality) — работает, но нестабильно **без дополнительного внешнего защищённого слоя** поверх мобильного аплинка (см. раздел 8). Reality и постквантовое шифрование VLESS пробовали — не завелись, отложено.
- В условиях мобильной сети обязательны: ограничение проксируемых портов (иначе рост нагрузки и обрывы) и постоянные IP-адреса клиентов (иначе XKeen «плохо цепляет» устройства).

1. Подготовка внешнего накопителя

Отформатировать флешку в ext4 заранее, на компьютере (программой типа Hard Disk Manager / любой ext4-форматтер / имя|метку диска я задал NEWOPKG ). Вставить флешку в роутер.

2. Установка компонента OPKG в веб-интерфейсе

Настройки системы → Изменить набор компонентов:

Включить «Поддержка открытых пакетов»
Дополнительно включить «Модули ядра подсистемы Netfilter» (понадобится для iptables/ipset при split-tunneling)
Нажать «Обновить» — роутер перезагрузится

Накопители и устройства → OPKG: выбрать флешку в поле «Накопитель», сохранить.

⚠️ Проблема: автоматическая установка Entware не стартует

После выбора диска в логе видна только строка missing initrc "/opt/etc/initrc" ... trying default one, дальше тишина — скачивание архива Entware не запускается.

Решение — запустить установку вручную через CLI роутера (SSH на системный порт, admin@<router-ip>, приглашение (config)>):

opkg no disk
opkg disk NEWOPKG:/ https://bin.entware.net/aarch64-k3.10/installer/aarch64-installer.tar.gz

(имя диска NEWOPKG и архитектура aarch64 — подставить свои, архитектуру видно в системном логе по строке Boot CPU: AArch64 Processor).

⚠️ Точное имя пакета установщика Entware (aarch64-installer.tar.gz в нашем случае) зависит от архитектуры процессора конкретной модели — перед установкой уточните её в системном журнале роутера (строка Boot CPU: ...) или в характеристиках модели, и подставьте соответствующий вариант установщика с bin.entware.net.

Через 20 – 40 секунд в системном журнале должна появиться финальная строка:

[5/5] Установка системы пакетов "Entware" завершена!

3. Подключение к Entware по SSH

Entware поднимает отдельный SSH-сервер (dropbear), логин root, пароль по умолчанию keenetic.

⚠️ Проблема: порт по умолчанию (22) недоступен

Реальный порт может отличаться. Проверить и при необходимости запустить сервис вручную через CLI роутера ((config)>):

exec cat /opt/etc/config/dropbear.conf   # смотрим PORT=...
exec ps | grep dropbear                  # проверяем, что процесс запущен
exec /opt/etc/init.d/S51dropbear start   # если не запущен — стартуем

В нашем случае реальный порт оказался 222.

Подключиться: ssh root@<router-ip> -p 222, пароль keenetic.

Сразу сменить пароль:

passwd

4. Обновление репозиториев и установка базовых утилит

opkg update
opkg upgrade
opkg install curl tar

5. Установка XKeen (Xray + GeoSite/GeoIP + split-tunneling из коробки)

cd /tmp
curl -OL --connect-timeout 10 -m 60 "https://raw.githubusercontent.com/jameszeroX/XKeen/main/install.sh"
chmod +x install.sh
./install.sh

Ответы на вопросы установщика (для KeeneticOS ≤ 5.1.2):

Версия XKeen → 1 (Stable)
Ядро проксирования → 1 (Xray — соответствует серверу на 3X-UI)
Версия Xray → 1 (последняя доступная; версия клиента не обязана совпадать с версией сервера)
GeoSite → 1 (установить все доступные базы: Re:filter, v2fly, ZKeen — не помешают, дают гибкость в правилах маршрутизации)
GeoIP → 1 (аналогично, все базы)
Исключить российские IP из проксирования (GeoIPSET) → 1 — ключевой пункт для split-tunneling: российский трафик пойдёт напрямую, всё остальное — через защищённое соединение
Автообновление GeoFile/GeoIPSET → 1 (включить задачу по расписанию)

По завершении: XKeen добавлен в автозагрузку, конфиги Xray лежат в /opt/etc/xray/configs/.

6. Конфигурация подключения к серверу

Файлы конфигурации создаются/правятся напрямую в /opt/etc/xray/configs/:

03_inbounds.json — создаётся установщиком автоматически, трогать не нужно (теги redirect/tproxy, слушают локальный порт для перехвата трафика).
04_outbounds.json — сюда прописывается подключение к своему серверу.
05_routing.json — правило маршрутизации перехваченного трафика на прокси.

🧑‍💻🛡️Кому неудобно править конфиги руками, можно воспользоваться сервисом Outbound Generator — конвертер URI в конфигурации для Xray и Mihomo, рекомендованным самим установщиком XKeen. ⚠️ Обратите внимание: ссылка с UUID и данными сервера при этом уйдёт на сторонний сайт — используйте с осторожностью, если это принципиально.

📜 /opt/etc/xray/configs/04_outbounds.json:

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "ВАШ_СЕРВЕР_IP",
            "port": ВАШ_ПОРТ,
            "users": [
              {
                "id": "ВАШ_UUID",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "none"
      }
    },
    { "tag": "direct", "protocol": "freedom" },
    { "tag": "block", "protocol": "blackhole" }
  ]
}

📜 /opt/etc/xray/configs/05_routing.json:

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["redirect", "tproxy"],
        "outboundTag": "proxy"
      }
    ]
  }
}

Проверка конфига перед запуском

xkeen -xtest

7. Запуск и проверка

xkeen -start
xkeen -status

Ожидаемо: Прокси-клиент xray запущен в режиме Hybrid.

Проверка, что трафик реально идёт через сервер:

curl -s https://ifconfig.me

Должен показать IP вашего сервера, а не реальный IP провайдера/4G — это нормально и означает, что туннель работает.

Проверка, что российские сайты идут в обход туннеля (split-tunneling):

nslookup ya.ru
ipset test geo_exclude <IP_из_nslookup>

Ответ is in set geo_exclude подтверждает, что домен верно определён как российский и пойдёт напрямую.

8. Обязательный внешний слой поверх мобильного аплинка

⚠️ Проблема, выявленная в реальной эксплуатации: голый VLESS нестабилен на мобильной сети

Сценарий использования — «в полях»: роутер подключается как Wi-Fi-клиент к смартфону, раздающему интернет от мобильного оператора (Tele2 и т.п.), то есть между Xray-клиентом на роутере и вышкой оператора есть промежуточное Wi-Fi/NAT-звено.

На практике оказалось: без дополнительного защищённого слоя базовый VLESS (security: none) работает нестабильно именно в мобильной сети — рукопожатие устанавливается, но доступность сайтов резко падает (в тестах — вплоть до «интернет не обнаружен»), а при отключении дополнительного слоя ситуация повторяется. Наиболее вероятная причина — операторский DPI не блокирует такой трафик полностью, а троттлит/подрезает его как нехарактерный паттерн, поскольку «голый» VLESS без TLS-обёртки заметно выделяется на общем фоне трафика.

Решение, подтверждённое на практике: держать постоянно поднятым дополнительный защищённый туннель (в нашем случае — WireGuard) как внешний слой, через который уже идёт весь трафик роутера, включая исходящий поток от Xray к серверу. Это скрывает характерный паттерн VLESS от DPI на стороне оператора.

Как это выглядит в связке:

Основной постоянный туннель (WireGuard) поднят на роутере отдельным WAN-подключением, работает постоянно.
XKeen/Xray со своей политикой xkeen работает поверх — то есть исходящий трафик Xray тоже заворачивается в WireGuard по пути к серверу.
При отключении WireGuard — падает стабильность и самого VLESS-туннеля, это ожидаемо в такой схеме, а не повод считать её неисправной.

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

9. Балансировка нагрузки: ограничение файловых дескрипторов и портов

⚠️ Проблема: рост числа подключённых устройств валит доступность

При стресс-тесте одновременным запуском проверки ~100 сайтов (https://rootrouter.ru/online/) сразу на трёх устройствах, подключённых через политику xkeen (ноутбук, смартфон, Smart TV), доступность резко падала — с одного устройства тест проходит в норме, а при синхронном запуске на 2 – 3 устройствах падает до 40 – 70% недоступных сайтов. Причина — в кратной нагрузке: сам чекер открывает не одно, а несколько параллельных соединений на каждый проверяемый сайт (замерено xkeen -cfd: 361 открытый файловый дескриптор на одно устройство при ~103 сайтах, то есть на каждый сайт из теста примерно 3,5). При трёх одновременно тестирующих устройствах это уже около 1000 – 1200 параллельных соединений разом — по сути то же самое, что открыть в браузере больше тысячи вкладок одновременно и заставить каждую сразу же что-то загружать. Неудивительно, что Xray на роутере с этим не справляется без ограничения дескрипторов (xkeen -fd) и сужения проксируемых портов.

Диагностика:

xkeen -cfd

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

Решение 1 — включить встроенный контроль дескрипторов:

xkeen -fd

Обязательная настройка при более чем одном активном устройстве на политике xkeen — без неё дескрипторы накапливаются и часть новых соединений начинает отваливаться.

Решение 2 — сузить список проксируемых портов. По умолчанию после xkeen -start может быть активен режим «на всех портах» — то есть в туннель заворачивается вообще весь трафик (DNS, телеметрия, торренты и т.п.), а не только веб. Это резко увеличивает число параллельных соединений и, соответственно, нагрузку.

Проверить текущий режим:

xkeen -cp

Задать конкретные порты (базовый веб-браузинг — обычно достаточно):

xkeen -ap 80,443

Если через туннель также нужны голосовые звонки/видеосвязь в мессенджерах (WebRTC), потребуются дополнительные UDP-диапазоны — но помните: медиа-трафик звонков лучше вообще не заворачивать в туннель (см. ниже), задержка на лишний скачок роутер→сервер→обратно способна сама по себе провоцировать обрывы и джиттер.

После изменения списка портов:

xkeen -restart
xkeen -status

Наблюдение из практики: после сужения до 80,443 заметно снизилась нагрузка, доступность сайтов стала стабильной при одновременной работе нескольких устройств, а голосовые звонки в мессенджерах (шедшие раньше через сервер и страдавшие от обрывов) пошли напрямую — задержка снизилась. Если позже обнаружится нужный сервис, ходящий не по 80/443 — добавляйте порт точечно через xkeen -ap, а не открывайте диапазон целиком.

10. Устранение утечки через IPv6

⚠️ Проблема: внешние проверки IP иногда показывают реальный IP оператора вместо IP сервера

Причина — часть трафика уходит по IPv6 в обход прокси (Xray/XKeen проксирует преимущественно IPv4).

Решение:

xkeen -ipv6

(интерактивно отключает поддержку IPv6 на уровне KeeneticOS и iptables). Дополнительно стоит проверить в веб-интерфейсе (Интернет → соответствующее WAN-подключение → вкладка IPv6), что там стоит «Не использовать».

11. Диагностика (на будущее, при проблемах)

xkeen -diag                                  # общая диагностика XKeen
xkeen -cfd                                   # число открытых файловых дескрипторов прокси-клиента
ipset list -n                                # список наборов IP
ipset list geo_exclude | head -20            # проверка, что база RU-адресов не пустая
ip rule list                                 # правила маршрутизации по меткам пакетов
iptables -t mangle -L -n -v | head -40       # перехват/маркировка трафика, счётчики пакетов
top -n 1 | head -20                          # загрузка CPU/RAM, отдельно смотреть процесс xray
free -m                                      # свободная память роутера

Ненулевые счётчики пакетов в правилах TPROXY/REDIRECT/match-set geo_exclude подтверждают, что split-tunneling реально обрабатывает трафик, а не просто настроен «на бумаге».

12. Управление через веб-интерфейс роутера (выбор устройств для туннеля)

XKeen не имеет собственной страницы в веб-интерфейсе Netcraze/Keenetic, но интегрируется через штатный механизм политик доступа в интернет.

Мои сети и Wi-Fi → Приоритеты подключений → Политики доступа в интернет:

Добавить новую политику, имя — строго xkeen (без пробелов, точно так же).
Отметить все реальные подключения, через которые роутер физически выходит в интернет (Wi-Fi-аплинк/раздающее устройство, Ethernet, встроенные модемы операторов) — кроме самих туннелей (WireGuard-подключения) и прокси-подключений. Без реального подключения политика не сможет стартовать: xkeen -start в этом случае выдаёт ошибку У политики xkeen нет доступа в интернет.
Не включать «Многопутевая передача» (это режим суммирования пропускной способности нескольких провайдеров, не нужен для нашей задачи).
Сохранить.

Мои сети и Wi-Fi → Списки клиентов → [нужное устройство] → поле «Политика доступа»:

Выбрать xkeen — трафик этого устройства пойдёт через защищённое соединение (с учётом split-tunneling по гео-базам).
Остальным устройствам оставить «Политику по умолчанию».
Рекомендуется сразу включить «Постоянный IP-адрес» для каждого такого устройства. На практике XKeen может «плохо цеплять» клиента после переподключения/смены DHCP-адреса (помогает переключение политики или перезапуск — по сути пересборка правил), и постоянный IP убирает саму причину рассинхрона.

После изменения политик — перезапустить прокси:

xkeen -restart

⚠️ Важно: на устройствах, подключённых к политике xkeen, лучше отключить все прочие туннели, VPN-приложения и системные прокси — совместное использование с XKeen приводит к конфликтам маршрутизации.

Итоговое состояние

✅ Entware/OPKG развёрнут на внешней флешке
✅ XKeen + Xray-core установлены, автозапуск при перезагрузке подтверждён
✅ VLESS-подключение к собственному серверу (3X-UI) работает, security: none (без TLS/Reality — рабочий базовый вариант), при условии постоянно поднятого внешнего защищённого слоя поверх мобильного аплинка (см. раздел 8)
✅ Split-tunneling по гео-принципу: российские адреса — напрямую, остальное — через сервер (подтверждено через ipset test, iptables счётчики и внешние IP-чекеры)
✅ Kill-switch: при потере маршрута в таблице политики трафик уходит в blackhole, а не «утекает» в обход туннеля
✅ IPv6 отключён на уровне KeeneticOS во избежание утечки реального IP
✅ Управление через штатный веб-интерфейс: политика xkeen с привязкой к реальному подключению, назначение по устройствам из «Списки клиентов» с постоянным IP
✅ Ограничение проксируемых портов (80÷443) и контроль файловых дескрипторов (xkeen -fd) — обязательны при нескольких одновременно активных устройствах

Отложено / не завершено

⏸ Reality (маскировка под TLS-сайт) — inbound создан, но при подключении «туннель поднимается, трафика нет»; причина не выявлена, требует отдельной диагностики (логи сервера при подключении, проверка версии Xray-core, корректность dest/serverNames/short ID).
⏸ Нативное постквантовое шифрование VLESS (mlkem768x25519plus) — inbound создан, но клиентское приложение на смартфоне не устанавливало интернет-соединение (вероятно, неполная поддержка функции в клиенте) — не перенесено на роутер.

Текущая рабочая конфигурация (security: none + внешний защищённый слой поверх мобильного аплинка) обеспечивает работоспособность и разделение трафика, но не имеет собственной TLS-маскировки на уровне VLESS — эта задача решается пока что вторым туннелем, а не самим протоколом. Возврат к вопросу Reality/шифрования на стороне VLESS — по желанию, отдельной задачей.

Применимость решения к другим моделям

Инструкция не привязана к конкретному устройству — она построена на штатных механизмах KeeneticOS (OPKG/Entware, политики доступа) и на XKeen, который сам определяет архитектуру процессора при установке. Поэтому решение воспроизводимо на любом другом роутере линейки Netcraze и Keenetic (это один и тот же модельный ряд под разными названиями после ребрендинга — устройства полностью взаимозаменяемы по прошивке и функциям).

Обязательные условия:

Свободный USB-порт для внешнего накопителя.
Flash-память не менее 64 Мбайт (модели с Dual Image 32 Мбайт исключены — на них штатно не хватает места даже под системные нужды, мучить их OPKG не стоит).
KeeneticOS версии 5.1 и выше.

Модели Netcraze, подходящие при соблюдении условий выше (маршрутизаторы, не точки доступа и не чистые Mesh-ретрансляторы):

Название модели (артикул)
Netcraze Hopper 4G+ (NC-2312)
Netcraze Hopper (NC-3811)
Netcraze Hopper SE (NC-3812)
Netcraze Hopper DSL (NC-3611)
Netcraze Giga (NC-1012)
Netcraze Ultra (NC-1812)
Netcraze Hero 5G (NC-4110)
Netcraze Viva (NC-1913)
Netcraze Speedster DSL (NC-2113)

Не подходят: точки доступа (Stellar 6, Orbiter 6 — не являются маршрутизаторами), чистые Mesh-ретрансляторы (Buddy 4÷5÷6÷6 SE — работают только в режиме повторителя, без полноценного роутер-функционала), модели без USB-порта, модели с Flash-памятью 32 Мбайт (Extra, Carrier, Launcher и аналогичные бюджетные версии).