Netcraze (ex-Keenetic) + XKeen-Xray: три режима для разных устройств — Direct – Split – Full через прокси-подключение

в 20:15, , рубрики: keenetic, NDMS, Netcraze, socks5, tproxy, vless, XKeen, xray, прокси

Привет! Хочу поделиться небольшой, но очень практичной настройкой для Netcraze/Keenetic: как сделать три режима выхода в интернет и переключать их на уровне роутера — просто переносом устройства между политиками использую XKeen/Xray.

Роутер: Netcraze Ultra (NC-1812)
Прошивка: NDMS 4.3.6.4
Целевая аудитория: “домашний продвинутый” (но я буду объяснять простыми словами)

Источники и база, от которой я отталкивался

Серверную часть и базовую установку/настройку XKeen/Xray здесь не разбираю — я использовал готовые инструкции и уже от них добавил “второй Full”.

Задача

Устройства дома разные: телефоны, ТВ, “умный дом”, ноутбуки. Хотелось управлять “как именно они выходят в интернет” централизованно на роутере.

В итоге нужны 3 режима:

  • Direct — устройство ходит напрямую через провайдера (режим по умолчанию).

  • Split — устройство в отдельной политике, и только часть трафика уходит в отдельный “канал выхода”, а остальное остаётся Direct (то есть выборочно по правилам).

  • Full — для пары устройств нужно, чтобы весь их трафик шёл через отдельный “канал выхода”. При этом важное требование: переключать режим переносом устройства между политиками, без правки конфигов при каждом переносе.

В статье я описываю сетевую архитектуру и управление маршрутами/профилями выхода. Не привожу перечней ресурсов и не разбираю сценарии обхода ограничений. Используйте в рамках применимого законодательства и правил вашего провайдера/организации.


Что уже было: Split через XKeen/Xray в прозрачном режиме

Split у меня уже работал через XKeen/Xray в “прозрачном режиме” (роутер перехватывает трафик выбранных устройств и отправляет его в Xray; устройства при этом ничего не настраивают).


Почему нельзя просто сделать вторую политику Split “для другого канала”

В прозрачной схеме устройства из политики Split приходят в Xray через одну и ту же “входную точку” (один и тот же перехват).
NDMS не передаёт в Xray информацию “из какой политики пришёл трафик”, поэтому Xray не сможет сам по себе выбрать разные каналы только по факту политики.

Вывод: чтобы разные политики вели в разные каналы, нужно сделать разные “входы” в Xray.


Решение: Full через proxy-подключение NDMS + отдельный SOCKS-вход в Xray

Идея такая:

  • Split оставляем как есть (прозрачный режим).

  • Для Full используем встроенный в NDMS Клиент прокси:

    • политика XkeenFull отправляет трафик устройств через proxy-подключение XRAY-FULL;

    • это proxy-подключение указывает на локальный SOCKS5-порт на роутере, например 127.0.0.1:1082.

  • В Xray поднимаем SOCKS-вход socks-full на 127.0.0.1:1082 и задаём правило: “всё, что пришло на этот вход — отправляй в отдельный выход vless-full”.

Схема (в одну строку):

  • Direct: устройство → провайдер

  • Split: устройство (в Xkeen) → перехват → Xray правила → direct или vless-reality

  • Full: устройство (в XkeenFull) → NDMS proxy (XRAY-FULL) → 127.0.0.1:1082 → Xray → vless-full


Шаг 1. Включаем компонент “Клиент прокси” в NDMS

Путь:

Управление → Параметры системы → Изменить набор компонентов → Сетевые функции → Клиент прокси


Шаг 2. Создаём proxy-подключение (SOCKS5 → 127.0.0.1:1082)

Путь:

Интернет → Другие подключения → Прокси-подключения → Добавить подключение

Параметры:

  • Имя: XRAY-FULL

  • Использовать для выхода в интернет : Да

  • Тип: SOCKS5

  • Адрес сервера: 127.0.0.1:1082


Шаг 3. Создаём политику XkeenFull и привязываем к XRAY-FULL

Сохраняем существующую политику Xkeen для Split и добавляем новую:

  • Xkeen — Split (как было)

  • XkeenFull — Full, подключение = XRAY-FULL


Шаг 4. Назначаем устройства в политики

Практическое правило, чтобы не ловить конфликты:

  • Устройство должно быть только в одной из политик:

    • либо Xkeen (Split),

    • либо XkeenFull (Full),

    • либо ни в одной (Direct).


Шаг 5. Конфиги Xray: добавляем второй канал для Full

Ниже три изменения в Xray-конфигах. Я показываю только то, что добавлялось.
Все чувствительные данные заменены на плейсхолдеры (<...>).

5.1. 03_inbounds.json: добавляем SOCKS-вход socks-full на 127.0.0.1:1082

Это локальная “точка входа”, куда NDMS будет отправлять трафик устройств из политики Full.

{
  "tag": "socks-full",
  "listen": "127.0.0.1",
  "port": 1082,
  "protocol": "socks",
  "settings": { "auth": "noauth", "udp": true },
  "sniffing": { "enabled": true, "destOverride": ["http", "tls"] }
}

Этот блок добавляем в inbounds рядом с уже существующими redirect и tproxy (они нужны для Split).

5.2. 04_outbounds.json: добавляем второй VLESS-выход vless-full

vless-reality у меня уже был и использовался для Split. Добавляем второй выход — для Full.

{
  "tag": "vless-full",
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "<SERVER_IP_OR_DOMAIN>",
        "port": 443,
        "users": [
          {
            "id": "<UUID>",
            "flow": "xtls-rprx-vision",
            "encryption": "none",
            "level": 0
          }
        ]
      }
    ]
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "publicKey": "<PUBLIC_KEY>",
      "fingerprint": "chrome",
      "serverName": "<SNI>",
      "shortId": "<SHORT_ID>",
      "spiderX": "/"
    }
  }
}

5.2. 05_routing.json: добавляем правило “socks-full → vless-full” в самый верх

Это связывает вход socks-full с выходом vless-full.

{
  "type": "field",
  "inboundTag": ["socks-full"],
  "outboundTag": "vless-full",
  "network": "tcp,udp"
}

Важно: правило должно стоять выше остальных, чтобы его не перебили правила для redirect/tproxy.

Шаг 6. Перезапускаем Xray/XKeen и проверяем

После изменения конфигов перезапускаем сервис (способ зависит от того, как установлен XKeen у вас).

Проверка:

  1. Берём устройство из политики XkeenFull.

  2. Открываем сайт проверки внешнего IP.

  3. Убеждаемся, что внешний IP соответствует “Full-каналу”.

Дополнительно:

  • устройство из политики Xkeen должно продолжать работать в Split (как раньше),

  • устройство вне политик — Direct.


Типовые грабли

1) Устройство в двух политиках

Если добавить устройство и в Xkeen, и в XkeenFull, поведение может быть непредсказуемым.
Надёжная схема: “одно устройство — один режим”.
Но честно говоря я даже не знаю как это сделать, но читал на форумах что кто-то так делал, поэтому напомню здесь что так не надо делать

2) NDMS не принимает 127.0.0.1

Иногда UI не позволяет указать loopback.
Тогда альтернатива: слушать SOCKS не на 127.0.0.1, а на LAN-IP роутера (например 192.168.1.1) и указать его в proxy-подключении.
(Это отдельная тема про безопасность и ограничения доступа к порту.)

3) UDP и некоторые приложения

В зависимости от приложения часть UDP-сценариев через proxy-подключение может работать ограниченно.
Если нужен Full “прямо для всего”, обычно рассматривают другие техники (например TUN), и это тоже уже отдельный материал.


Как добавить ещё один Full (Full-2, Full-3 и т.д.)

Масштабирование прямолинейное:

  • новый Full = новый SOCKS-вход на новом порту (например 1083)

  • новый outbound (vless-full-2)

  • новое правило routing (socks-full-2 → vless-full-2)

  • новое proxy-подключение в NDMS (127.0.0.1:1083)

  • новая политика (XkeenFull2)

То есть “одна политика = один proxy-порт = один канал выхода”.


Итог

Я получил управляемую схему из трёх режимов:

  • Direct — по умолчанию

  • Split — через прозрачный режим XKeen/Xray для выбранных устройств

  • Full — через отдельную политику NDMS и proxy-подключение на локальный SOCKS-порт Xray

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

Автор: Ksalador

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js