Настройка 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. По факту эксплуатации в условиях мобильного аплинка потребовалось ограничение проксируемых портов и подбор параметров XMUX. На первой версии базовый VLESS без TLS-маскировки (
security: none) требовал дополнительного внешнего туннеля (WireGuard) поверх мобильной сети — начиная с перехода на транспорт xhttp + TLS, маскировка обеспечивается самим VLESS-подключением, и необходимость в дополнительном туннеле отпала.Авторы: проблему решали Виталий Бурков и 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“.
- **Маскировка трафика реализована через транспорт “xhttp“ + TLS** (сертификат на IP-адрес сервера) — трафик выглядит как обычный HTTPS, дополнительный внешний туннель (WireGuard) поверх мобильной сети **больше не требуется**. Reality и постквантовое шифрование VLESS пробовали отдельно — не завелись, остаются отложенными как альтернативные варианты маскировки.
- Критично для xhttp под нагрузкой — параметр **XMUX** (“maxConcurrency“) в конфиге клиента, без него при бурст-нагрузке (много сайтов/устройств одновременно) соединение разваливается.
- В условиях мобильной сети также обязательны: ограничение проксируемых портов (иначе рост нагрузки и обрывы) и постоянные IP-адреса клиентов (иначе XKeen «плохо цепляет» устройства).
1. Подготовка внешнего накопителя
Отформатировать флешку в ext4 заранее, на компьютере (программой типа Hard Disk Manager / любой ext4-форматтер). Вставить флешку в роутер.
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).
Через 20 – 40 секунд в системном журнале должна появиться финальная строка:
[5/5] Установка системы пакетов "Entware" завершена!⚠️ Точное имя пакета установщика Entware (
aarch64-installer.tar.gzв нашем случае) зависит от архитектуры процессора конкретной модели — перед установкой уточните её в системном журнале роутера (строкаBoot CPU: ...) или в характеристиках модели, и подставьте соответствующий вариант установщика сbin.entware.net.
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.
Сразу сменить пароль:
passwd4. Обновление репозиториев и установка базовых утилит
opkg update
opkg upgrade
opkg install curl tar5. Установка 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 и данными сервера при этом уйдёт на сторонний сайт — используйте с осторожностью, если это принципиально.
Рекомендуемый вариант: xhttp + TLS (с маскировкой трафика)
На сервере (3X-UI) создаётся inbound с транспортом xhttp и security: tls. TLS-сертификат можно выпустить как на домен, так и на голый IP-адрес сервера (Let’s Encrypt это поддерживает) — в таком случае поля serverName/sni/host в конфиге остаются пустыми, обычный домен не нужен.
📜 /opt/etc/xray/configs/04_outbounds.json:
{
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "ВАШ_СЕРВЕР_IP",
"port": ВАШ_ПОРТ,
"users": [
{
"id": "ВАШ_UUID",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "xhttp",
"security": "tls",
"tlsSettings": {
"serverName": "",
"alpn": ["h2", "http/1.1"],
"fingerprint": "chrome"
},
"xhttpSettings": {
"path": "/",
"host": "",
"mode": "auto",
"xPaddingBytes": "100-1000",
"xmux": {
"maxConcurrency": 32
}
}
}
},
{ "tag": "direct", "protocol": "freedom" },
{ "tag": "block", "protocol": "blackhole" }
]
}⚠️ Обязательно: параметр XMUX (maxConcurrency)
Без явного xmux в клиентском конфиге транспорт xhttp в актуальных версиях Xray-core по умолчанию открывает по отдельному физическому HTTP/2-соединению почти на каждый проксируемый запрос, вместо переиспользования одного канала. При обычном браузинге незаметно, но при нагрузке (несколько устройств, много сайтов/вкладок одновременно) счёт параллельных запросов идёт на сотни — и роутер пытается открыть сотни отдельных TLS-хендшейков разом, что приводит к массовой недоступности сайтов, несмотря на то, что сам туннель поднят и работает.
"maxConcurrency": 32 — до 32 параллельных проксируемых запросов используют одно и то же соединение, прежде чем открывается новое. Мобильные VPN-клиенты (например, Happ) обычно задают эту настройку сами по умолчанию — при ручной сборке конфига для роутера её нужно прописать явно.
Важно: maxConnections и maxConcurrency — взаимоисключающие настройки, задавать нужно только одну из них.
Альтернативный/базовый вариант: tcp без шифрования (security: none)
Более простой в настройке (не нужен сертификат вообще), но без TLS-маскировки — DPI мобильного оператора может троттлить такой трафик как нехарактерный паттерн (см. раздел 8 — при этом варианте эксплуатационно потребовался дополнительный внешний туннель WireGuard).
{
"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 -xtest7. Запуск и проверка
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. Внешний защищённый слой (WireGuard) — актуально только для варианта без TLS
📌 Историческая находка (относится к базовому security: none, не к xhttp + TLS)
Сценарий использования — «в полях» (дача/огород): роутер подключается как Wi-Fi-клиент к смартфону, раздающему интернет от мобильного оператора (Tele2 и т.п.), то есть между Xray-клиентом на роутере и вышкой оператора есть промежуточное Wi-Fi/NAT-звено.
На первой версии конфигурации (голый VLESS, security: none, без TLS) на практике оказалось: без дополнительного защищённого слоя такое подключение работает нестабильно именно в мобильной сети — рукопожатие устанавливается, но доступность сайтов резко падает (в тестах — вплоть до «интернет не обнаружен»). Наиболее вероятная причина — операторский DPI не блокирует такой трафик полностью, а троттлит/подрезает его как нехарактерный паттерн, поскольку «голый» VLESS без TLS-обёртки заметно выделяется на общем фоне трафика.
Решение, которое использовалось на той версии: держать постоянно поднятым дополнительный защищённый туннель (WireGuard) как внешний слой, через который уже идёт весь трафик роутера, включая исходящий поток от Xray к серверу — это скрывало характерный паттерн VLESS от DPI на стороне оператора.
✅ После перехода на xhttp + TLS необходимость в этом слое отпала
Прямая проверка (curl/openssl s_client к серверу по TLS напрямую с той же мобильной сети Tele2, без WireGuard) показала: TLS-хендшейк проходит штатно, оператор его не блокирует и не троттлит — трафик, замаскированный под обычный HTTPS, не выделяется на общем фоне. Дополнительный внешний туннель для этого варианта транспорта не требуется, VLESS/XKeen работает напрямую поверх мобильной сети.
Если по какой-то причине используется базовый вариант без TLS (
security: none, раздел 6) — архитектурное требование остаётся в силе: защищённый внешний туннель должен быть поднят постоянно, VLESS/XKeen работает внутри него, а не вместо него.
9. Балансировка нагрузки: ограничение файловых дескрипторов и портов
⚠️ Проблема: рост числа подключённых устройств валит доступность
При подключении через политику xkeen сразу нескольких устройств (ноутбук, смартфон, IoT-колонка) доступность сайтов начинает резко падать (в тесте: с одного устройства — доступность в норме, при 2 – 3 одновременно — до 40 – 70% сайтов недоступны).
Диагностика:
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) работает через транспорт
xhttp+ TLS — трафик замаскирован под обычный HTTPS, сертификат выпущен на IP-адрес сервера - ✅ Параметр XMUX (
maxConcurrency: 32) настроен — соединение выдерживает бурст-нагрузку (несколько устройств, много сайтов одновременно) без развала - ✅ Дополнительный внешний туннель (WireGuard) поверх мобильной сети не требуется при этой схеме (см. раздел 8 — актуально было только для более раннего варианта без TLS)
- ✅ Split-tunneling по гео-принципу: российские адреса — напрямую, остальное — через сервер (подтверждено через
ipset test,iptablesсчётчики и внешние IP-чекеры) - ✅ Kill-switch: при потере маршрута в таблице политики трафик уходит в
blackhole, а не «утекает» в обход туннеля - ✅ IPv6 отключён на уровне KeeneticOS во избежание утечки реального IP
- ✅ Управление через штатный веб-интерфейс: политика
xkeenс привязкой к реальному подключению, назначение по устройствам из «Списки клиентов» с постоянным IP - ✅ Ограничение проксируемых портов (80÷443) и контроль файловых дескрипторов (
xkeen -fd) — обязательны при нескольких одновременно активных устройствах
Отложено / не завершено
- ⏸ Reality (маскировка под TLS-сайт через Reality-эмуляцию) — inbound создан, но при подключении «туннель поднимается, трафика нет»; причина не выявлена. Практическая нужда отпала — маскировка уже достигнута другим путём (
xhttp+ TLS), но как отдельный вариант транспорта остаётся неисследованной. - ⏸ Нативное постквантовое шифрование VLESS (
mlkem768x25519plus) — inbound создан, но клиентское приложение на смартфоне не устанавливало интернет-соединение (вероятно, неполная поддержка функции в клиенте) — не перенесено на роутер.
Текущая рабочая конфигурация (xhttp + TLS с XMUX) обеспечивает и работоспособность, и разделение трафика, и маскировку под HTTPS — без необходимости во втором туннеле поверх. Возврат к вопросу Reality/постквантового шифрования — по желанию, как альтернативные варианты транспорта, не как насущная необходимость.
Применимость решения к другим моделям
Инструкция не привязана к конкретному устройству — она построена на штатных механизмах 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 и аналогичные бюджетные версии).