Перейти к содержанию

Keenetic: не называйте всё WL — политика, сегмент, SSID и маршрут решают разные задачи

Статус: Confirmed (терминология и базовая модель KeeneticOS) + Observed (практический кейс с камерами и Mihomo)
Область применения: KeeneticOS 3.8+; Keenetic + MagiTrickle + Mihomo / ProxyN; сети с операторскими ограничениями «белых списков»
Проверено на: официальной документации Keenetic и текущей архитектуре saymer-alt/keenetic-auto-setup
Последняя проверка: 2026-09-23
Source of truth: документация Keenetic по политикам доступа, firewall/уровням доступа и SSID; saymer-alt/keenetic-auto-setup/ARCHITECTURE.md

Что решаем

В сложной схеме легко назвать одним словом несколько совершенно разных сущностей:

  • операторский режим белых списков — «WL»;
  • политику доступа в Интернет на Keenetic — тоже «WL»;
  • новый локальный сегмент — снова «WL»;
  • отдельный SSID — опять «WL».

После этого возникают логически естественные, но технически неправильные вопросы:

  • «Можно ли завести сам роутер в WL?»
  • «Если камера не прописана в маршрутах MT, как к ней зайти?»
  • «Если поставить второй роутер, он решит проблему WL?»
  • «Раз камера заработала после помещения в WL, значит WL открывает вход к камере?»

Проблема здесь не только в знаниях о маршрутизации. Одинаковые имена скрывают границы между слоями.

Эта статья фиксирует терминологию и предлагает простое правило именования:

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

Для примеров ниже используем локальную договорённость:

  • WL / БС — только состояние/ограничение у оператора;
  • Shadaev — политика доступа в Интернет Keenetic;
  • Cameras — локальный сегмент камер;
  • CamNet — имя беспроводной сети (SSID);
  • ProxyN / t2sN — технический вход Keenetic → Mihomo;
  • Mihomo — движок проксирования/выбора outbound.

Shadaev, Cameras и CamNet — примеры именования, а не требования KeeneticOS.

1. Что официально называется политикой доступа

В документации Keenetic для KeeneticOS 3.8+ используется термин «Политики доступа в Интернет». Ранее интерфейс назывался «Профили доступа в Интернет».

Keenetic описывает профиль/политику как набор правил policy routing, применяемых к трафику хостов, когда они обращаются в Интернет. В той же документации отдельно существует вкладка «Применение политик», где к политике можно привязать зарегистрированные устройства и локальные сегменты.

То есть политика отвечает на вопрос:

«Через какие подключения должен выходить в Интернет этот клиент или сегмент?»

Она не является:

  • Wi-Fi-сетью;
  • локальным сегментом;
  • операторским белым списком;
  • правилом входящего доступа с WAN;
  • синонимом Mihomo.

Поэтому вместо:

Политика доступа: WL

в нашей схеме понятнее:

Политика доступа: Shadaev

и уже внутри неё:

1. t2s0 / ProxyN → Mihomo
2. при необходимости — другие подключения / fallback

Почему Shadaev лучше, чем WL

Не потому, что это «правильное системное имя», а потому что оно не совпадает ни с одним другим уровнем.

При чтении схемы:

устройство назначено в Shadaev

сразу понятно, что речь идёт о политике маршрутизации.

Фраза:

устройство находится в WL

непонятна без контекста: это политика Keenetic, белый список оператора, SSID или сегмент?

2. Что такое сегмент сети

В документации Keenetic используются понятия домашнего, гостевого и дополнительных локальных сегментов. На уровне системы это отдельные локальные интерфейсы/bridge, для которых могут задаваться собственные:

  • IP-подсеть;
  • DHCP;
  • проводные порты и точки доступа;
  • ограничения доступа;
  • security level / правила firewall;
  • применение политики доступа в Интернет.

Сегмент отвечает на вопрос:

«Какие устройства находятся в одной локальной сетевой зоне и какие локальные правила к ним относятся?»

Это другой объект, чем политика доступа в Интернет.

Например:

Сегмент: Cameras
Подсеть: отдельная подсеть камер
Политика доступа: Shadaev

Здесь Cameras описывает кого мы группируем, а Shadaev — как эта группа выходит наружу.

Неудачный вариант

Оператор: WL
Политика: WL
Сегмент: WL

По такой схеме невозможно понять, что именно изменили, когда говорят «добавили в WL».

Удачный вариант

Операторское состояние: WL / БС
Политика доступа:      Shadaev
Сегмент:               Cameras

Теперь фраза:

«Сегмент Cameras назначен политике Shadaev»

однозначна.

3. SSID — это ещё одна отдельная сущность

Keenetic официально использует термин «Имя сети (SSID)» для имени беспроводной сети, которое видит клиент.

SSID отвечает на вопрос:

«Как называется точка/сеть Wi-Fi для пользователя?»

Он не обязан совпадать:

  • с названием сегмента;
  • с названием политики;
  • с названием VPN/прокси;
  • с названием операторского режима.

Пример:

SSID:      CamNet
    ↓
Сегмент:  Cameras
    ↓
Политика: Shadaev
    ↓
ProxyN / t2s0
    ↓
Mihomo

Такое именование позволяет открыть веб-интерфейс через месяц и без воспоминаний понять архитектуру.

4. Четыре уровня, которые особенно нельзя смешивать

Уровень Вопрос Пример имени
Внешнее условие у оператора Что происходит с доступностью Интернета? WL / БС
Политика доступа Keenetic Через какой egress выходит клиент/сегмент? Shadaev
Локальный сегмент Какие устройства объединены и изолированы? Cameras
Wi-Fi SSID Как клиент видит беспроводную сеть? CamNet

В схеме с Mihomo добавляются ещё два слоя:

Уровень Роль Пример
ProxyN / t2sN техническая точка Keenetic → SOCKS/Mihomo Proxy0, подпись mihomo t2s0
Mihomo выбирает конкретный proxy/outbound после попадания трафика в него proxy-group / сервер

Это и есть причина не называть всё одним WL.

5. Как выглядит нормальная цепочка для камеры

Если требуется, чтобы весь исходящий трафик камеры шёл через Mihomo, схема может быть такой:

IP-камера
   │
   ▼
сегмент Cameras
   │
   ▼
политика Shadaev
   │
   ▼
t2s0 / ProxyN
   │
   ▼
SOCKS 127.0.0.1:7890
   │
   ▼
Mihomo
   │
   ▼
proxy / VPN / доступный egress
   │
   ▼
Интернет / облако камеры

Это исходящий маршрут.

Если после такого назначения камера снова появляется в приложении производителя при операторских ограничениях, это означает как минимум, что нужные ей внешние соединения получили рабочий путь.

Но из этого не следует, что приложение установило прямое входящее TCP/UDP-соединение из Интернета на локальный IP камеры.

У камер часто используются облачные control-plane/P2P/relay-механизмы. Точная схема зависит от производителя и модели, поэтому универсальное утверждение «телефон всегда входит прямо на камеру» или «телефон всегда работает только через облако» делать нельзя.

Практически важный вывод другой:

восстановление доступности камеры после смены её исходящей политики не доказывает появление прямого входящего доступа к LAN.

6. Когда маршрутизировать всю камеру, а когда домены

Оба подхода допустимы, но решают разные задачи.

Выборочная маршрутизация через MagiTrickle

Подходит, когда известно, что обход нужен только конкретным сервисам:

камера
 ├─ локальный доступ      → DIRECT
 ├─ NTP                   → DIRECT
 ├─ update.example        → DIRECT
 └─ cloud.example         → Mihomo

Плюсы:

  • меньше лишнего proxy-трафика;
  • точнее контролируется egress.

Минусы для IoT/камер:

  • облако может использовать несколько доменов;
  • адреса/CDN могут меняться;
  • возможны P2P/relay/STUN/TURN и прямые IP;
  • полный список зависимостей не всегда документирован.

Политика на всё устройство или сегмент

Если задача звучит:

«При операторском WL камера должна просто оставаться доступной»

то назначение камеры/сегмента целиком в Shadaev может быть проще и надёжнее, чем попытка постоянно поддерживать полный список облачных доменов.

Цена — через Mihomo уйдёт больше трафика.

Поэтому здесь нет универсального правила «всегда маршрутизировать домены» или «всегда маршрутизировать устройство». Нужно явно зафиксировать цель.

7. MagiTrickle не создаёт входящий канал

В архитектуре keenetic-auto-setup MagiTrickle:

  1. видит DNS-запрос;
  2. классифицирует домен;
  3. связывает домен/IP с группой;
  4. через firewall marks / policy routing помогает направить уже существующий трафик в нужный интерфейс.

Условно:

Client
  ↓
DNS
  ↓
MagiTrickle
  ↓
решение DIRECT / ProxyN / mitun0
  ↓
Keenetic routing

Он не выполняет функцию:

Интернет
   ↓
создать новый входящий путь
   ↓
камера

Поэтому идея:

«Прописать адреса камер в MT, чтобы потом заходить на них извне»

смешивает маршрутизацию исходящих соединений и входящую доступность LAN.

Если входящее соединение не дошло до WAN-интерфейса роутера или было закрыто NAT/firewall/провайдером, MagiTrickle нечего классифицировать.

8. Доступ к камерам между локальными сегментами — это ещё третий вопрос

Если клиент уже находится внутри сети, но камера размещена в другом сегменте, проблема может быть не в Shadaev и не в MT.

Официальная документация Keenetic различает уровни доступа интерфейсов:

  • private;
  • protected;
  • public.

Например, protected разрешает выход в public, но по умолчанию не даёт доступ к самому роутеру и другим private/protected сегментам. Для гостевого сегмента Keenetic как раз использует такую модель, когда запрещён доступ к настройкам интернет-центра.

Отсюда важное диагностическое разделение:

«Камера не выходит в Интернет»
        → политика / маршрут / Mihomo / WAN

«Из соседнего сегмента не открывается IP камеры»
        → firewall / security-level / isolate-private

«Из Интернета не получается напрямую войти на камеру»
        → WAN reachability / NAT / firewall / public IP / port-forward /
          reverse tunnel / cloud

Это три разных класса проблем.

9. Почему «завести роутер в Shadaev» — неправильная модель

Политика доступа в документации Keenetic применяется к хостам и локальным сегментам, когда они обращаются в Интернет.

Сам роутер не стоит мысленно превращать в ещё одного клиента сегмента.

Для трафика, который генерирует сам Keenetic, могут существовать отдельные механизмы выбора политики/интерфейса у конкретных приложений. Например, в документации есть отдельное назначение политики встроенному BitTorrent-клиенту Transmission.

Поэтому вопрос должен быть не:

«Как положить весь роутер в Shadaev?»

а:

«Какой именно сервис роутера должен выйти через какой интерфейс и поддерживает ли он привязку к политике/интерфейсу?»

Это принципиально более точная постановка.

10. Почему второй и третий роутер сами по себе WL не исправляют

Рассмотрим цепочку:

Интернет / операторский WL
          │
          ▼
      Роутер 1
          │
          ▼
      Роутер 2
          │
          ▼
        камеры

Количество роутеров не меняет возможностей внешнего канала.

Если Роутер 1 не создал новый рабочий egress, то Роутер 2 всё равно выходит через тот же ограниченный канал.

Более того, при обычной схеме router-behind-router появляется дополнительный NAT:

Internet
   │
 NAT №1
   │
Router 1
   │
 NAT №2
   │
Router 2
   │
Camera

Это само по себе не создаёт входящий путь.

Когда второй роутер действительно может помочь

Например:

Router 2
   │
   │ его исходящий WAN-трафик
   ▼
Router 1
   │
политика Shadaev
   │
ProxyN → Mihomo
   │
рабочий proxy/tunnel
   ▼
Internet

Тогда трафик за Роутером 2 действительно может заработать.

Но причина — не наличие второго роутера.

Причина — то, что появился другой egress:

Shadaev → ProxyN → Mihomo → рабочий внешний путь

То же правило применимо к трём и десяти роутерам.

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

11. Входящий доступ: политика выхода не является обратным маршрутом

Keenetic по умолчанию защищает локальные устройства firewall/NAT. Для прямого входящего доступа нужны отдельные условия: доступный WAN, правила firewall/NAT/port-forward или другой механизм удалённого доступа.

Операторский NAT/CGNAT или иное внешнее ограничение также может сделать прямой вход невозможным.

Поэтому:

камера → Shadaev → Mihomo → Internet

не означает автоматически:

Internet → Mihomo → Shadaev → камера

Политика маршрутизации не «зеркалится» в обратную сторону как удалённый доступ.

Если нужен надёжный вход в сеть при недоступном прямом WAN, архитектурно это обычно отдельная задача: например, исходящий туннель из локальной сети к доступному внешнему узлу, через который затем организуется возвратный доступ.

12. Что произойдёт, если выключить Mihomo

Отключение Mihomo не превращает MagiTrickle в неработающий компонент само по себе.

MagiTrickle всё ещё может:

  • видеть DNS;
  • классифицировать домены;
  • выбирать группу/интерфейс.

Но если результат классификации:

YouTube → t2s0 / ProxyN → Mihomo

а Mihomo не слушает :7890, выбранный путь не имеет рабочего следующего узла.

Упрощённо:

MT → DIRECT                  → работает, если обычный WAN доступен
MT → ProxyN/t2s0 → Mihomo OFF → не работает

Если в политике есть дополнительные fallback-подключения, итог зависит от её реальных приоритетов и состояния интерфейсов. Поэтому проверять нужно не «жив ли MT вообще», а какой путь он выбрал для конкретного соединения.

13. Новый сегмент и MagiTrickle

В текущей архитектуре keenetic-auto-setup новый локальный сегмент не становится участником DNS-классификации MagiTrickle автоматически.

Для MagiTrickle важен список интерфейсов link:, например:

link:
  - br0
  - br1

Если создаётся новый сегмент Cameras на новом bridge и от его клиентов ожидается доменная классификация MT, интерфейс сегмента нужно добавить в конфигурацию MagiTrickle.

Но снова важно не смешивать задачи:

  • назначить всему сегменту политику Shadaev — одна операция;
  • включить для сегмента доменную классификацию MT — другая;
  • разрешить локальный доступ между сегментами — третья;
  • открыть вход из Интернета — четвёртая.

Одинаковое имя WL у всех четырёх объектов скрывает эту разницу.

14. Рекомендуемая схема именования

Для небольшого домашнего/полевого стенда достаточно:

Внешнее состояние:  WL / БС
Политика Keenetic:  Shadaev
Сегмент:            Cameras
SSID:               CamNet
Proxy interface:    ProxyN / mihomo t2sN
Mihomo group:       Proxy-Primary / Proxy-Secondary

Для более крупной сети можно добавить тип объекта прямо в имя:

POL-Shadaev
SEG-Cameras
SSID-CamNet
PX-Primary
PX-Secondary

Главное — не конкретные префиксы, а правило:

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

15. Минимальная карта для диагностики

Когда кто-то говорит «при WL не работает», сначала определить что именно не работает.

1. Клиент получил IP?
        ↓
2. Это нужный сегмент?
        ↓
3. Есть локальный доступ к роутеру / соседним сегментам?
        ↓
4. Какая политика доступа назначена клиенту/сегменту?
        ↓
5. Какой интерфейс первый в политике?
        ↓
6. Если это ProxyN/t2sN — слушает ли Mihomo :7890?
        ↓
7. Если используется MT — покрывает ли link: этот сегмент?
        ↓
8. Какой outbound выбрал Mihomo?
        ↓
9. Работает ли внешний канал у оператора?
        ↓
10. Требуется исходящий cloud/P2P путь или прямой вход с WAN?

Такой порядок не даёт перепутать:

  • локальную сегментацию;
  • policy routing;
  • MagiTrickle;
  • Mihomo;
  • внешнее ограничение оператора;
  • входящий удалённый доступ.

Что подтверждено, а что нет

Confirmed:

  • KeeneticOS использует отдельное понятие «Политики доступа в Интернет»; политика описывает policy routing для трафика хостов к Интернету.
  • Политики можно применять к зарегистрированным устройствам и локальным сегментам.
  • SSID — имя беспроводной сети, а не имя политики маршрутизации.
  • Уровни private / protected / public и firewall регулируют другой класс доступа, включая доступ к самому роутеру и между локальными интерфейсами.
  • В архитектуре keenetic-auto-setup MagiTrickle, ProxyN/t2sN, mitun0 и Mihomo — разные слои.
  • Для нового сегмента, который должен участвовать в DNS-классификации MagiTrickle, нужно обеспечить его присутствие в link:.

Observed / practical case:

  • назначение камер в отдельную политику с первым выходом через t2s0 / ProxyN → Mihomo восстанавливало их внешнюю доступность в условиях операторских ограничений;
  • одинаковое имя WL для внешнего режима и политики Keenetic приводило к путанице в обсуждении архитектуры.

Still research / depends on environment:

  • точная cloud/P2P/relay-схема конкретной камеры;
  • конкретный механизм операторского whitelist/DPI в каждой сети;
  • нужен ли конкретной камере селективный MT-список доменов или надёжнее целиком назначить её в policy;
  • поведение fallback зависит от фактического состава и приоритетов конкретной политики.

Источники и provenance

Официальная документация Keenetic

Связанные проекты

Короткий итог

WL / БС
= внешнее ограничение у оператора

Shadaev
= политика доступа в Интернет Keenetic

Cameras
= локальный сегмент устройств

CamNet
= SSID, который видят Wi-Fi-клиенты

MagiTrickle
= классификация и выбор маршрута для подходящего трафика

ProxyN / t2sN
= точка передачи трафика Keenetic → Mihomo

Mihomo
= proxy/outbound engine

И главный архитектурный вывод:

Хоть два роутера поставить, хоть три — само количество роутеров проблему операторских белых списков не решает. Решает изменение рабочего пути выхода или создание отдельного туннеля.

А главный вывод по именованию:

не называйте разные уровни одним WL. Правильные имена — это часть сетевой архитектуры, потому что они не дают перепутать сегментацию, policy routing, proxy и входящий доступ.